ソフトウェア開発において「技術的に正しいか」を議論することは重要である。しかし、それだけでは不十分である。技術的な正解というものは、技術のトレンドや実行環境、あるいはビジネスフェーズの変化によって容易に変容するからである。
論理が整っていることは大前提だが、変化の激しい開発現場において、チームが一貫性のある評価軸を持ち続けるためには、拠り所となる「価値観」が必要不可欠である。
MVV（Mission, Vision, Values）には多様な解釈が存在するが、本記事ではピーター・ドラッカーの組織論をベースにしつつ、ソフトウェア開発チームの実務レベルで機能するようにその解釈を再定義する。経営レベルの壮大なスローガンではなく、「自分たちのドメインにおいて、誰に、何を提供する専門集団なのか」にフォーカスすることが重要である。
MVVはリーダーが独断で決めるものではない。チームを一つの「人格」として定義するためには、メンバー全員の認識を同期させるプロセスが必要である。
このプロセスを通じて定義された「チーム人格」は、人が入れ替わっても継承されるべきアイデンティティとなる。また、MVVは一度定めたら固定するのではなく、状況の変化に応じて柔軟に変更していくことが重要である。
チームは個人の集合体であるが、一つの「人格」として機能すべき存在である。チームという人格は、そのチームが向き合うドメインやコンテキストによって規定される。
メンバーの入れ替えがあったとしても、チームが提供する価値や振る舞いに一貫性がなければ、周囲からの信頼は得られない。MVVを定めることは、いわば「チーム人格のアイデンティティ」を定義する作業である。この軸があることで、人が入れ替わってもドメインに対する向き合い方は継承され、一貫性のあるチームであり続けることが可能になる。
設計や技術選定において、最後の一手を決めるのはチームの「思想」である。もちろん、論理的な正しさ、定量的なデータ、あるいは定性的な判断軸といった多角的な判断要素は重要であり、これらを軽視すべきではない。
しかし、複数の「論理的に正しい選択肢」が並んだ際、共通の思想（Value）がなければ議論は空転する。
これらに対し、MVVを通じて考え方の共通認識を持っておくことで、チーム人格としての意思決定がスムーズになり、不毛な議論の空転を防ぐことができる。
自律的なチームとは、チーム人格として自ら意思決定し、作業を完結させられるチームを指す。
個々のメンバーがバラバラに動くのではなく、チームという主体（人格）が「今の開発プロセスは最適か？」「目指している方向性は正しいか？」を常に問い直し、自ら柔軟にアップデートし続けられることが重要である。MVVは、この自律的な改善サイクルを回すための羅針盤となる。
MVVを生きた指針とするためには、日常の風景に溶け込ませる工夫が有用である。
筆者の経験に基づき、基盤開発（プラットフォームエンジニアリング）を担うチームにおけるMVVのモデルケースを例示する。チームの注力ポイントによって、その構成は変化する。
| パターン | Mission（任務） | Vision（未来像） | Values（信念） |
|---|---|---|---|
| 開発者体験重視 | 複雑さを抽象化し、開発者が実装に没頭できる環境を作る | 誰もがアイデアを即座にソフトウェアとしてデリバリーできる世界 | 利用者起点の設計 / 手間ゼロの体験 |
| 安全性・統制重視 | セキュリティをデフォルト化し、自由と統制を両立させる | 全エンジニアが意識せずとも、最速でアクセルを踏み続けられる状態 | 既定で安全 / 透明性の確保 |
| 信頼性・規模重視 | 100倍のスケールにも耐えうる堅牢な土台を維持する | あらゆるプロダクトが、最小コストで最大のスケールを享受できるインフラ | 信頼性を最優先 |
エンジニアリングは論理の世界だが、その論理をどの方向に働かせるかを決めるのはチームの意志である。技術的正しさが環境によって変動するからこそ、チーム人格としての共通認識を持ち、一貫性がありつつも柔軟な開発を推進するためにMVVを定義すべきである。そして定めた言葉を羅針盤として、チーム自らがその在り方を磨き続けることが、結果としてプロダクトの価値を最大化させる近道となる。
関連書籍