「なぜ」を失ったプロジェクトは、正しく失敗する

「ちゃんと作ったのに、なぜかうまくいかなかった」

プロジェクトに関わっていると、この違和感に一度は当たる。

要件通りに実装した。テストも通った。リリースした。なのに、ユーザに使われなかった。KPIが動かなかった。プロジェクトが終わった後に「これ、本当に必要だったんだろうか」という虚無感が残った。

この違和感の正体を、多くの人は「要件が甘かった」「実装に問題があった」と説明しようとする。しかし何度振り返っても、明確な間違いが見つからない。

それもそのはずで、誰も間違っていなかった。

プロジェクトが動き始めると、議論はすぐに「どう作るか」「何を作るか」に収束する。

それ自体は間違っていない。

ただ、多くの現場で見落とされていることがある。

「なぜやるのか」——この問いだけが、いつの間にか誰も口にしなくなる。

「何を作るか」が正しくても、失敗する

プロジェクトの失敗は、間違いの積み重ねではなく前提のズレで起きる。

要件は正しい。実装も正しい。それでも失敗する。

私はこれを「正しく失敗する」と呼んでいる。

この種の失敗は、間違いが見えない分、組織に残る。

原因は、「なぜやるのか」が最初から欠けていることだ。whyが曖昧なままプロジェクトが動き出すと、判断の拠り所が「正論」になる。「データは正確に扱うべき」「ユーザに確認を取るべき」「セキュリティは担保すべき」——こういった正論は、whyがないときに力を持つ。反論しにくいし、誰も否定できない。だから採用される。

人は「正しいこと」ではなく、「判断軸」で意思決定している。正論は、判断軸がないときの"デフォルト"になる。

問題は、その正論がプロジェクトの目的と合っているかどうか、誰も確認していないことだ。

議論が「できるかどうか」に流れていく構造

プロジェクトの初期段階で何が起きているかを振り返ると、パターンがある。

最初は目的の話をしている。「このプロジェクトで何を達成したいか」「ユーザにどういう状態になってほしいか」が議題に上がる。

しかし数回の会議を経るうちに、議論の重心がシフトしていく。「それは技術的に実現可能か」「工数はどのくらいかかるか」「既存のシステムとどう連携するか」——こういった話が中心になる。

これは自然な流れでもある。プロジェクトを実行するためには、実現可能性を検討しなければならない。工数見積もりは必要だ。

ただ、このシフトの過程で何かが失われる。「なぜやるのか」という問いが、「どうやるのか」という問いに静かに置き換わっていく。

そして、工数や実装可能性の文脈で議論が進むと、要件は膨らみやすい。「どうせやるなら、これも入れよう」「技術的にはできるし、念のため対応しておこう」——こういった判断が積み重なっていく。その一つ一つは決して間違っていない。しかし積み重なった要件の優先順位は崩壊している。なぜなら、削る基準がないからだ。

削る基準を持つには、whyが必要だ。「これはプロジェクトの目的に貢献するか」という問いに答えるためには、まず目的が言語化されていなければならない。

whyが曖昧なプロジェクトでは、要件の取捨選択ができない。結果として、すべてを「とりあえず入れる」方向に進む。

これはプロダクト開発だけの話ではない。社内システムの刷新でも、業務プロセスの改善でも、マーケティングキャンペーンの設計でも、同じ構造は起きる。「何をやるか」を精緻化していく過程で、「なぜやるか」が薄れていく。

ただ、より根本的な問いがある。なぜwhyは現場に届かないのか。

whyはたいてい、誰かの頭の中にある。
それが実行チームに渡る瞬間、「言葉」になる。

言葉は文脈を失う。

チームに届くころには、キックオフ資料の一行になっている。

whyを定義した人間と、whyを使って判断する人間が分離している。

これが構造的な問題だ。

あるプロダクト移行プロジェクトでの話

以前、プロダクトの移行プロジェクトに関わったことがある。

既存のサービスから新しいプラットフォームへ、ユーザのデータを移行するというプロジェクトだった。ユーザ数は数万人規模で、各ユーザが長期間にわたって蓄積したデータを持っていた。

プロジェクトの目的として掲げられていたのは「スムーズな移行体験の提供」だった。言葉としては存在していた。おそらくプロジェクトを立ち上げた側の人間が持っていた意図だった。しかしそれが実行チームに「判断の軸」として機能する形で渡されることはなかった。キックオフ資料に一行あっただけで、議論の場で参照されることはほとんどなかった。

移行設計の議論が始まると、話はすぐに「データの完全性」に向かった。議論は数回の会議で、この方向に収束していった。

「データは正確に移行すべきですよね」

この一言で、議論はほぼ終わっていた。

「ユーザのデータを欠損なく移行すること」「移行後のデータが正確であることをユーザ自身が確認できること」——この方針は、議論の中で自然に合意された。議論の場で、これに明確に反対する人はいなかった。むしろ「それはそうだよね」という空気だった。なぜなら、誰が聞いても正しいことを言っているからだ。

その方針に基づいて設計されたのが、ユーザが自分のデータを一つ一つ確認しながら移行を進めるUXだった。移行対象のアイテムがリスト表示され、ユーザは各アイテムをチェックしながら「移行する」「移行しない」を選択していく。確認が完了したものだけが新しいプラットフォームに移行される。

設計として、これは一貫していた。「データの完全性を担保する」という方針と、「ユーザが確認する」というUXは、整合している。

実装も、仕様通りに完成した。テストも問題なかった。リリースした。

結果は、ユーザ離脱の増加だった。

移行フローに入ったユーザの多くが、途中で離脱した。移行を完了したユーザの割合は、想定を大きく下回った。

何がズレていたのか

ズレはシンプルだった。

判断軸が違っていた。最初から。

プロジェクトの本来のwhyは「ユーザの移行ハードルを下げること」だった。新しいプラットフォームに移ってほしい。そのために、移行の体験をできるだけ簡単にしたい——それが出発点であるはずだった。

しかし実際の判断軸は「データの完全性」にすり替わっていた。

データを正確に移行することは、手段であるはずだった。「ユーザに移行してもらう」という目的を達成するための、一つの手段。しかし議論の中で、それが目的になっていた。

「データの完全性を担保すること」が目的になった瞬間、「ユーザに一つ一つ確認させるUX」は正しい答えになる。整合性がある。論理的だ。だから誰も疑わなかった。

しかし、本来のwhyに立ち返れば、この設計が間違っていることは明らかだった。ユーザに確認作業を強いれば、移行のハードルは上がる。データが正確に移行されることと、ユーザが移行を完了することは、別の話だ。

当時、違和感を持った人間がいなかったわけではない。「このUX、ちょっと重くないか」という声は出ていた。しかし、「でもデータの確認はユーザにとっても重要でしょう」という反論に、誰も答えられなかった。

whyが言語化されていないと、正論に負ける。

そして厄介なのは、その正論が間違っているわけではないことだ。「データは正確に移行すべき」は正しい。ただ、それはこのプロジェクトの判断軸ではなかった。正しさと適切さは別の問題だ。しかしwhyがなければ、その区別ができない。

要件定義が「作れるかどうか」で進む問題

このプロジェクトで起きたことは、構造的な問題でもある。

多くのプロジェクトで、要件定義は「何が作れるか」「どう作るか」を整理するプロセスになっている。機能の洗い出し、ユーザーストーリーの作成、優先度付け——これらは「作れるかどうか」の文脈で進む。

その文脈の中では、「なぜこの機能が必要か」という問いは立ちにくい。すでに「この機能を作る」という前提で議論が進んでいるからだ。

結果として、要件は膨張しやすい。「それも入れよう」「これも必要そう」という判断が積み重なる。一つ一つの判断は合理的でも、全体として「何のために作っているか」から離れていく。

そして、優先順位が崩壊する。

優先順位をつけるためには「捨てる基準」が必要だ。「これはやらなくていい」と言うためには、何かの基準に照らし合わせなければならない。その「何かの基準」がwhyだ。

whyがないプロジェクトでは、削ることができない。すべてが「やった方がいい」に見える。要件は膨らみ続け、スコープはコントロールを失う。

「それは何のため？」という問いを止まって入れる

では、どうすればいいか。

フレームワークを導入しようとか、ドキュメントのテンプレートを作ろうとか、そういう話をするつもりはない。もっと地道な話をする。

議論がhow/whatに流れた瞬間に、止める。

「それは何のため？」という問いを一つ入れる。それだけだ。

タイミングは、議論が実装の話や工数の話に寄ったときだ。「このデータをどう移行するか」「この機能にどれくらいかかるか」という議論が始まった瞬間が、問いを入れるタイミングだ。

言い方は、否定ではなく問いにする。「それ、いらないんじゃないですか」は機能しない。いきなり切りにいくと反発が生まれる。「それは何のためにやるんでしたっけ？」という問い方が有効だ。

この問いは、議論の前提を一段上に引き戻す。whatやhowの議論は、そのまま続けることができる。ただ、その判断軸だけを上書きすることができる。

もちろん、この問いは歓迎されないこともある。議論の流れを止めるし、場合によっては「またそれか」と思われる。

それでも入れるしかない。

ただ、「またそれか」という空気が常態化しているなら、それは問いの問題ではない。whyを問うことが歓迎されない組織になっているということだ。問える文化と権限を設計するのは、個人ではなく、経営とリーダーシップの仕事だ。

whyは、一度決めれば終わりではない。
使われ続けているかどうかがすべてだ。

プロジェクトはwhyを守る仕事だ

プロジェクトは「何を作るか」を決める仕事ではない。
「なぜやるか」を守る仕事だ。

その責任は、現場だけにあるのではない。whyを定義した人間が、whyを使える形で渡し、使われ続けることを確認する——ここまでが、whyを守ることだ。

これを外した瞬間、プロジェクトは正しく失敗する。

そして、その失敗は、誰の間違いにもならない。

だから、繰り返される。