速く作るチームほど、先に「作らないもの」を増やしている

問題は、開発速度ではなく入口にある

ソフトウェア開発が遅いとき、私たちはたいていコードを書く速度を疑う。エンジニアを増やし、ツールを新しくし、会議を減らし、納期を短く区切る。しかし、本当に詰まっているのは開発工程ではなく、その手前の入口かもしれない。

誰も欲しがらない機能、解くべき課題を取り違えた機能、成功条件が曖昧な機能。こうしたものを大量にパイプラインへ流し込めば、チームは忙しくなる。けれど、忙しさは価値の証拠ではない。むしろ、誤った仕事を完成させるための総コストが増えているだけである。

ここには、プロダクト開発における重要な逆説がある。速く作るためには、まず作る候補を減らさなければならない。しかも、その削減は直感や上司の好みで行うのではなく、探索と検証を通じて行う必要がある。

この視点に立つと、問題発見と解決策の設計を二つのダイヤモンドで捉える考え方と、ソフトウェアのパイプラインへ高品質な入力を供給する考え方は、同じ原理を別の角度から説明していることが見えてくる。前者は思考の形を示し、後者はその思考が組織の生産性をどう変えるかを示している。

開発チームの生産性は、どれだけ多く作ったかだけでなく、どれだけ早く「作る価値のないもの」を入口で止められたかによって決まる。

二つのダイヤモンドは、発想法ではなく流量制御である

問題探索の最初の段階では、観察、インタビュー、データ分析、現場の声を通じて視野を広げる。これが最初の拡散である。ここで「原因はこれだ」と早々に決めてしまうと、最初に見つけた症状を問題そのものだと誤認してしまう。

たとえば、ネット通販の利用者から「検索機能を改善してほしい」という声が多く届いたとする。要求をそのまま受け取れば、検索窓の改修やフィルターの追加が解決策になる。しかし観察を進めると、利用者が困っているのは検索精度ではなく、商品ページを比較しにくいことかもしれない。あるいは、配送日が見えないために、検索結果を何度も行き来しているだけかもしれない。

そこで必要になるのが最初の収束である。集めた情報を一つの答えに急いで圧縮するのではなく、誰が、どの状況で、何を達成できずにいるのかという形で課題を定義し直す。ここで初めて、チームは「機能」ではなく「解くべき仕事」を扱えるようになる。

その後、再び解決策を拡散させる。検索アルゴリズムの改善だけでなく、比較表、推薦、配送日の表示、購入前の不安を減らす説明など、多様な可能性を並べる。そして最後に、効果、実現可能性、検証結果を踏まえて収束させる。

この構造を単なる創造的思考の手順と見ると、実務上の価値を小さく見積もることになる。二つのダイヤモンドは、実はパイプラインへ入れる情報の流量を制御する装置である。前半では、思い込みによる早すぎる決定を防ぐ。後半では、開発コストをかける前に、実行すべき案を絞り込む。

つまり、拡散は無駄を増やす行為ではない。後工程に誤った仕事を流さないための、前工程における保険である。収束も、アイデアを殺す行為ではない。限られた開発能力を、最も検証価値の高い場所へ配分するための判断である。

機能の数を増やすほど、価値が減ることがある

ソフトウェアチームの成果は、リリースした機能の数で測られがちである。しかし、機能数を増やすほど成果が増えるとは限らない。機能には、実装コストだけでなく、説明、テスト、保守、問い合わせ対応、将来の変更制約が付随するからだ。

一つの機能を建物にたとえると、完成した瞬間に仕事が終わるわけではない。建物には修繕や維持管理が必要だが、ソフトウェアではさらに、他の機能との相互作用やデータ構造への影響が積み重なる。短期的な要求に応えるために急いで追加した仕様は、後から変更しにくい構造として残りやすい。

ここで重要なのは、技術的負債だけをコードの問題として扱わないことである。曖昧な課題を、曖昧な成功条件のまま開発へ渡すことも、プロダクト上の負債を生む。何を作るかが不明確なら、エンジニアは実装の詳細を埋めるしかない。結果として、意思決定の不在がコードの複雑さに変換される。

反対に、良い入力は設計や実装を過剰に指定しない。良い入力とは、「この画面をこの技術で作ること」ではなく、「利用者がこの状況でこの結果を得られること」を明確にする。たとえば、次の二つを比べてみよう。

「購入画面におすすめ商品を三件表示する」

「購入を迷っている利用者が、追加で必要な商品を一度の比較で判断できる」

前者は実装指示であり、後者はユーザーにとっての成功条件である。後者なら、推薦表示が最適とは限らない。セット提案、比較表、購入履歴の提示など、複数の解決策を検討できる。開発チームに裁量を残しながら、判断の方向性は明確になる。

この差は小さく見えるが、組織の流量を大きく変える。入力が「機能の要求」だけなら、開発チームは要求されたものを作る。入力が「課題、仮説、成功の観測方法」まで含むなら、開発チームは価値を生むための選択ができる。

良いパイプラインは、前工程で何を捨てるかを設計している

開発組織が抱える典型的な問題は、仕事が少なすぎることではない。仕事が多すぎることである。優先順位の低い依頼が並び、緊急案件が割り込み、検討不十分な機能が着手され、途中で前提が崩れる。それでも新しい要求が追加される。

この状態を、エンジニアの処理能力不足と診断するのは危険である。パイプラインが過負荷になれば、個々の人が努力しても全体の流れは改善しない。待ち行列が増え、切り替えコストが発生し、レビューやテストが後回しになり、最終的にはリリース後の修正作業が増える。

ここで使える考え方が、意思決定のボトルネックを前倒しするという原則である。開発後に「本当に必要だったか」を調べるのではなく、開発前に小さく確かめる。完成した製品を評価するのではなく、仮説の弱い部分を評価する。

たとえば、医療予約サービスが「予約キャンセルを減らすために、リマインダー機能を追加したい」と考えたとする。いきなり複雑な通知設定を実装する必要はない。まず、対象者への手動メッセージ、簡単な予約確認ページ、キャンセル理由の聞き取りを組み合わせ、どの障壁が最も大きいかを調べられる。

この実験で、「忘れている」のではなく「変更方法が分からない」ことが判明すれば、必要なのは通知機能ではなく、予約変更の導線かもしれない。数日間の調査と小さな試作によって、数週間の開発を回避できる可能性がある。

このとき、検証は開発を遅らせるための追加作業ではない。誤った開発をしないために、開発能力を守る作業である。チームの能力を、コードを書く時間だけでなく、考え、試し、学ぶ余白として捉え直す必要がある。

仮説は、チームを縛る仕様書ではなく、判断を揃えるレンズである

プロダクト開発では、ユーザーストーリーや仕様書が細かくなりすぎることがある。画面の配置、ボタンの文言、処理手順まで事前に固定すると、要件は明確になったように見える。しかし、細部を決めるほど、現場で得た学習を反映しにくくなる。

ここで役立つのが、ユーザーに何が起こってほしいかを記述する「小さな物語」である。これは完成形を指定するものではなく、行動と結果の仮説を示すものだ。

たとえば、「利用者が請求書をダウンロードできるボタンを追加する」ではなく、「経理担当者が月末の五分間で、必要な請求書を迷わず確認し、社内共有できる」と書く。この表現なら、ボタンの追加以外にも、検索、まとめて出力、共有リンクなどの案が開かれる。同時に、評価すべき指標も見えてくる。完了までの時間、検索の失敗回数、共有まで到達した割合などである。

良い仮説には、少なくとも四つの要素がある。

1. 対象者: 誰が困っているのか。
2. 状況: どの場面で問題が起きるのか。
3. 望ましい変化: 利用者に何ができるようになってほしいのか。
4. 観測方法: その変化を、何によって確かめるのか。

この四つが揃うと、企画、デザイン、エンジニアリング、分析の会話がつながる。企画は目的を説明でき、デザインは選択肢を広げられ、エンジニアは実現方法を判断でき、分析担当者は学習の証拠を設計できる。

反対に、「競合が追加したから必要」「顧客が欲しいと言ったから必要」だけでは、判断の軸が足りない。顧客の要望は重要だが、それは問題の存在を示す証拠であって、解決策の正しさを保証するものではない。

要求は答えではない。要求は、まだ正しく質問されていない問いの入口である。

今日から変えられる、入口の品質管理

この考え方を実務に落とすには、プロセスを複雑にする必要はない。むしろ、開発へ渡す前に最低限の判断を揃えるだけでよい。

Key Takeaways

1. 機能ではなく、解決すべき仕事から書き始める 「何を追加するか」ではなく、「誰が、どの状況で、何を達成できていないか」を一文で記述する。

2. 開発前に、最も危険な仮説を一つ検証する 需要があるか、問題が頻繁に起きるか、提案した解決策で行動が変わるかを分けて考える。すべてを調べるのではなく、失敗したら最も大きな損失になる仮説から試す。

3. 成功条件と実装方法を分離する 成功を利用者の行動や成果で定義し、画面や技術の詳細はチームの裁量に残す。明確さと自由度は両立できる。

4. パイプラインに入れる仕事の量に上限を設ける 未検証の案件を無制限に蓄積しない。着手中の仕事を減らし、考える時間、検証する時間、品質を高める時間を確保する。

5. リリース数ではなく、学習と成果を測る 作った機能の数だけでなく、仮説がどう変わったか、利用者の行動がどう変わったか、不要な開発をいくつ止めたかを記録する。

最も大きな変化は、会議の数を減らすことではなく、会議で扱う対象を変えることから始まる。仕様を承認する会議ではなく、問題の理解を深める会議にする。アイデアを競わせる会議ではなく、仮説の弱点を見つける会議にする。進捗を報告する会議ではなく、次に何を学ぶべきかを決める会議にする。

開発チームを速くするのは、急かすことではない

ソフトウェアを作ることは、物理的な建物を建てることとは違う。完成した設計図を受け取り、決められた手順で組み立てれば終わる仕事ではない。実装を進めるほど、技術的な制約、利用者の予想外の行動、データの問題、運用上の現実が見えてくる。

だからこそ、開発チームに必要なのは、細部まで命令されることではない。目的と制約を理解したうえで、最善の方法を選べることだ。そのためには、上流が責任を放棄して「後は任せる」と言うのでは足りない。課題を深く理解し、成功の意味を具体化し、検証可能な仮説として渡さなければならない。

生産性とは、手を止めずに作り続ける能力ではない。正しい問いに、チームの知性と時間を集中させる能力である。拡散と収束を丁寧に行うことは、遠回りに見える。しかし、それによって誤った仕事が工程へ流れ込むのを防ぎ、結果として本当に必要なものを速く届けられる。

プロダクトチームが問うべきなのは、「今月、いくつの機能を出せるか」だけではない。次の問いも同じくらい重要である。

「今月、いくつの誤った前提を、安く発見できるか」

この問いを持てた瞬間、開発速度の意味が変わる。速いチームとは、最も速くコードを書くチームではない。最も早く学び、最も早く捨て、価値のある仕事だけを実装へ送り込めるチームである。