全員が正しいのに、プロジェクトが失敗する理由

リリース直前に起きる「あれ、違う」の正体

リリース直前。

チケットはすべて完了している。
テストも通っている。
コードレビューも終わっている。
進捗表の上では、プロジェクトは順調に見える。

そこで、完成した画面を顧客に見せる。

すると、顧客がこう言う。

「すみません。これって、そういう意味だったんですか？」

その瞬間、空気が変わる。

エンジニアは仕様書を開く。
PMは進捗表を見直す。
顧客は「当然こうなると思っていた」と言う。

誰も嘘をついていない。
誰もサボっていない。
誰も悪意を持っていない。

それでも、プロジェクトは壊れる。

なぜなら、全員が同じ言葉を使っていたのに、頭の中では別々の完成形を見ていたからだ。

プロジェクトは、コードを書く前に壊れていることがある。
正確に言えば、コードを書く前に、関係者の認識がすでにズレていることがある。

そして、そのズレは進捗率には出ない。
チケット管理ツールにも出ない。
テスト結果にも出ない。

だから怖い。

この記事では、ソフトウェア開発で起きる失敗を、コードや工数ではなく、関係者の頭の中にある「見えない仕様書」のズレとして考えてみたい。

プロジェクトには、人数分の「見えない仕様書」がある

ソフトウェア開発では、仕様書が重要だと言われる。

それは正しい。

ただ、現場で本当に厄介なのは、紙やドキュメントに書かれた仕様書だけではない。

もっと厄介なのは、関係者それぞれの頭の中にある「見えない仕様書」だ。

顧客には、顧客の見えない仕様書がある。
PMには、PMの見えない仕様書がある。
エンジニアには、エンジニアの見えない仕様書がある。
デザイナーには、デザイナーの見えない仕様書がある。
運用担当には、運用担当の見えない仕様書がある。

この見えない仕様書には、いろいろなものが含まれている。

過去の経験から来る思い込み。
「普通はこうだろう」という前提。
わざわざ言わなかった期待。
本人も自覚していない業務ルール。
現場では当たり前になっている手順。
開発側が当然だと思っている技術的制約。
顧客が当然だと思っている使い勝手。

こうしたものが混ざり合って、1人1人の頭の中に完成イメージを作っている。

問題は、この見えない仕様書が共有されていないことだ。

しかも、頭の中にあるので差分を取れない。
Gitのようにdiffを確認できない。
レビューコメントも付けられない。
CIで落とすこともできない。

だから、ズレていても気づきにくい。

そして、気づいたときには、すでに実装が進んでいる。

同じ言葉を使っていても、同じものを見ているとは限らない

会議で、PMがこう言う。

「まずは検索機能を作りましょう」

顧客がうなずく。
エンジニアもうなずく。
議事録にはこう残る。

「検索機能を実装する」

一見、何も問題はない。

全員が同じ言葉を使っている。
全員が理解したように見える。
誰も反対していない。
会議も予定通り終わった。

しかし、この時点ですでにズレていることがある。

PMは、一覧画面に検索フォームを付ければよいと考えている。
エンジニアは、DBの項目に対してwhere句を書けばよいと考えている。
顧客は、Googleのように曖昧な言葉でも見つかるものを想像している。
運用担当は、古い表記や入力ミス、略称でも探せることを期待している。

全員が「検索」と言っている。

でも、見ているものは違う。

検索機能には、実は多くの論点が隠れている。

完全一致なのか。
部分一致なのか。
曖昧検索なのか。
複数条件を組み合わせられるのか。
日付範囲で絞り込めるのか。
権限によって検索結果が変わるのか。
0件のときに何を表示するのか。
1万件ヒットしたときにどうするのか。
CSV出力まで必要なのか。
表記揺れを吸収するのか。

「検索機能」という言葉は簡単に見える。

しかし、その中身はかなり広い。

だから、検索機能を軽く見積もったあとで、後から要件が増えたように見えることがある。

でも、本当は要件が増えたのではない。

最初から顧客の頭の中にはあった。
ただ、それが外に出ていなかっただけだ。

チケットは緑でも、プロジェクトは赤信号かもしれない

Jira、Backlog、Redmine、Notion、Asana。

どのツールを使っていても、プロジェクト管理は基本的に「見えるもの」を扱う。

チケットが作られる。
担当者が決まる。
期限が入る。
ステータスが更新される。
進捗率が上がる。
バーンダウンチャートが下がる。

これは重要だ。

ただし、ここに大きな落とし穴がある。

チケット管理ツールが測っているのは、多くの場合、作業の消化状況であって、認識の一致度ではない。

チケットが完了していることと、顧客が期待していた価値が実装されていることは、同じではない。

レビューが通っていることと、利用者の頭の中にある完成形に近づいていることも、同じではない。

テストが通っていることと、業務上の意味が満たされていることも、同じではない。

ここを取り違えると危険だ。

チケットは緑。
テストも緑。
レビューも完了。
進捗率も順調。

それでも、プロジェクトは赤信号かもしれない。

なぜなら、進捗率は「作業がどれだけ進んだか」は教えてくれるが、「関係者の認識がどれだけ揃っているか」は教えてくれないからだ。

見積もりが外れるのは、時間ではなく対象を間違えているから

見積もりが外れると、よくこう言われる。

「もっと細かく見積もるべきだった」
「バッファを取るべきだった」
「過去実績を使うべきだった」
「エンジニアの見積もりが甘かった」

もちろん、それらが必要なこともある。

しかし、見積もりが大きく外れるとき、本当の原因は工数計算ではなく、対象物の認識違いにあることが多い。

小さなログイン機能だと思って見積もった。
しかし実際には、権限管理、監査ログ、外部連携、パスワードリセット、アカウントロックまで含まれていた。

簡単な一覧画面だと思って見積もった。
しかし実際には、複雑な検索条件、CSV出力、権限別表示、件数制限、パフォーマンス要件まで含まれていた。

軽い改修だと思って見積もった。
しかし実際には、既存業務フロー全体に影響する変更だった。

この場合、見積もり能力だけの問題ではない。

見積もった対象が、そもそも人によって違っていたのだ。

エンジニアが見積もったものと、顧客が期待していたものが違う。
PMがスケジュールに置いたものと、現場が必要としていたものが違う。

対象物が違えば、見積もりが合うはずがない。

だから、見積もり精度を上げるには、タスクを細かくする前に、まず認識を揃える必要がある。

進捗管理より前に、認識管理がある。

「分かりました」は合意ではなく、保留かもしれない

会議で一番怖い言葉の1つが、「分かりました」だ。

もちろん、本当に理解している場合もある。
しかし、そうではない場合もある。

「分かりました」の裏側には、いろいろな状態が隠れている。

なんとなく理解した。
細かいところは後で考えようと思った。
質問すると会議が長くなりそうだから黙った。
自分だけ理解できていないと思われたくなかった。
相手も同じものを想像していると思った。
今は決めなくても何とかなると思った。
そもそも何を質問すればいいかわからなかった。

つまり、「分かりました」は必ずしも合意ではない。

ただの保留かもしれない。
曖昧さの先送りかもしれない。
沈黙による仮の合意かもしれない。

プロジェクトで危険なのは、意見が対立することではない。

むしろ、対立が見えているならまだよい。
議論できるからだ。

本当に危険なのは、全員が分かったふりをしたまま進むことだ。

表面上は合意している。
議事録にも残っている。
チケットも作られている。

しかし、頭の中の完成形はズレたまま。

この状態で実装に入ると、ズレはコードになって固定される。

必要なのは、コードレビューの前の「認識レビュー」

コードレビューは大切だ。

実装の誤りを見つける。
可読性を上げる。
保守性を高める。
セキュリティ上の問題に気づく。
設計の歪みを見つける。

しかし、コードレビューだけでは見つけられないものがある。

それは、そもそも作ろうとしているものが合っているかどうかだ。

コードレビューは、実装を見る。
認識レビューは、前提を見る。

認識レビューとは、コードを書く前に、関係者が同じ完成イメージを持っているかを確認する作業である。

たとえば、次のようなことを確認する。

• この機能は誰のためのものか

• 何ができれば完成なのか

• どの業務を楽にするのか

• どの画面で、誰が、いつ使うのか

• 正常系だけでなく異常系はどうなるのか

• 権限によって見えるものは変わるのか

• 失敗したときに誰へ何を伝えるのか

• 「普通」「柔軟」「いい感じ」は具体的に何を指すのか

認識レビューは、難しい儀式である必要はない。

完璧な仕様書を作ることでもない。
分厚いドキュメントを増やすことでもない。

目的はただ1つ。

関係者の頭の中にある「見えない仕様書」を、少しでも外に出すことだ。

認識レビューで聞くべき5つの質問

認識のズレを早く見つけるために、会議では次の5つを確認するとよい。

1. ここで言う「ユーザー」は誰か

「ユーザー」という言葉は広い。

一般利用者なのか。
管理者なのか。
社内担当者なのか。
取引先なのか。
承認者なのか。
閲覧だけする人なのか。

ユーザーが違えば、必要な画面も権限も導線も変わる。

2. 完成した状態を、全員が同じ画面で説明できるか

言葉だけで合意しない方がよい。

できれば、簡単な画面モックや手書きの図で確認する。

きれいなデザインである必要はない。
むしろ、荒い段階で見せた方がよい。

早く見せれば、早くズレる。
早くズレれば、早く直せる。

3. 正常系だけでなく、異常系を確認したか

仕様の話は、正常系に偏りやすい。

しかし、実際の現場では例外が起きる。

入力ミスしたらどうするのか。
通信に失敗したらどうするのか。
データが存在しなかったらどうするのか。
権限がなかったらどうするのか。
途中で処理が止まったらどうするのか。

異常系を確認すると、認識のズレが見えやすい。

4. 「普通」「柔軟」「いい感じ」を具体化したか

会議で次の言葉が出たら注意した方がよい。

普通に。
いい感じに。
柔軟に。
使いやすく。
簡単に。
自動で。
必要に応じて。
一般的な形で。
管理できるように。

これらは便利な言葉だ。
しかし、人によって意味が違う。

「普通」とは何か。
「柔軟」とはどこまでか。
「使いやすい」とは誰にとってか。

ここを具体化しないまま進むと、後でズレる。

5. 違っていたら一番困る前提は何か

最後に、この質問をするとよい。

「もしここが違っていたら、一番困る前提は何ですか？」

この質問は、重要なリスクを見つけやすい。

たとえば、

利用者数の前提。
権限の前提。
業務フローの前提。
データ量の前提。
外部連携の前提。
運用体制の前提。
セキュリティ要件の前提。

プロジェクトを壊すのは、細かい仕様漏れだけではない。

大きな前提のズレだ。

早くズレるチームほど、後で燃えにくい

認識のズレは、完全には避けられない。

人間はそれぞれ違う経験を持っている。
違う立場で仕事をしている。
違う制約を見ている。
違う期待を持っている。

だから、最初から完全に一致することを期待しすぎない方がよい。

大事なのは、ズレないことではない。
早くズレに気づくことだ。

完成後にズレると、手戻りは大きい。
リリース直前にズレると、関係者の信頼も傷つく。
運用開始後にズレると、現場が混乱する。

しかし、モックの段階でズレれば直せる。
業務フロー図の段階でズレれば話し合える。
サンプルデータの段階でズレれば設計を変えられる。

早く見せる。
早く聞く。
早く違和感を出す。
早く間違える。

これが、プロジェクトを守る。

プロジェクトにおいて本当に危険なのは、間違えることではない。
間違いに気づくのが遅れることだ。

全員が正しく間違えている

認識のズレは、静かに育つ。

誰も怒っていない。
誰もサボっていない。
会議も開かれている。
議事録もある。
チケットも更新されている。
コードも増えている。

それでも、プロジェクトはズレていく。

なぜなら、全員が自分の認識の中では正しく動いているからだ。

開発者は正しく実装している。
PMは正しく管理している。
顧客は正しく期待している。

しかし、それぞれの正しさが、同じ場所を向いていない。

だから最後に、あの言葉が出る。

「それって、そういう意味だったんですか？」

この1言を防ぐために、私たちはコードレビューだけでなく、認識レビューをしなければならない。

進捗確認だけでなく、前提確認をしなければならない。

仕様を読むだけでなく、相手が何を見ているのかを見に行かなければならない。

プロジェクトは、コードで失敗する前に、認識で失敗する。

そして、その亀裂は今日もどこかの会議室で生まれている。