第13話｜レビューは順調です｜東央ソリューションズ―― 実務統合型PM論・連載小説

SEASON 3｜開発炎上

開発フェーズに入ってから一か月が過ぎた。

高梨は週次進捗会議の資料を眺めていた。

画面には緑色のステータスが並んでいる。

要件定義。

基本設計。

インターフェース設計。

AI需要予測機能。

すべて順調。

少なくとも資料の上では。

「レビュー状況はどうですか？」

高梨が尋ねる。

会議室のモニターに共有されたWBSを見ながら、

開発リーダーの村瀬が答えた。

「予定通り進んでいます」

「設計書レビューも完了しています」

「指摘件数も少なくて、かなり品質は良さそうです」

画面には数字が表示されていた。

レビュー対象件数。

完了件数。

指摘件数。

未解決件数。

どれも問題なさそうに見える。

「そうですか」

高梨は頷いた。

黒田は腕を組んだまま資料を見ていた。

何も言わない。

しかし表情は硬い。

会議終了後。

高梨は声を掛けた。

「何か気になりますか」

黒田は少し考えた。

「指摘件数が少ないな」

「品質が良いってことじゃないですか？」

高梨が言う。

黒田は首を横に振った。

「そうかもしれない」

「そうじゃないかもしれない」

「どっちですか」

「まだ分からん」

黒田は資料を閉じた。

「設計書を見たか？」

高梨は少し黙った。

「全部は見てません」

「俺も全部は見てない」

黒田は窓の外を見た。

夜の街の灯りが広がっている。

「レビューしたって言うならいいんだ」

「でも何をレビューしたんだろうな」

高梨は答えられなかった。

翌週。

顧客との定例会。

白石が明るい声で報告していた。

「レビューも順調です」

「大きな問題は出ていません」

田辺も安心したように頷く。

「それは良かったです」

「現場も期待していますので」

神谷も機嫌が良さそうだった。

「いい流れですね」

「このまま行きましょう」

会議は予定より早く終わった。

誰も反対しなかった。

誰も問題を挙げなかった。

会議室を出たあと、

高梨は一人でレビュー記録を開いた。

レビュー議事録。

レビュー結果一覧。

承認履歴。

どれもきれいだった。

指摘件数は少ない。

未解決事項も少ない。

順調そのものだ。

ふと、

ある設計書を開いた。

需要予測AI機能。

顧客が最も期待している機能だった。

ページをめくる。

画面設計。

データ連携。

外部IF。

そして予測ロジック。

高梨は眉をひそめた。

「……あれ？」

説明が足りない。

いや、

ほとんど書かれていない。

レビュー記録を見る。

承認済み。

指摘なし。

高梨は別の設計書を開いた。

こちらも同じだった。

承認済み。

指摘なし。

承認済み。

指摘なし。

承認済み。

指摘なし。

静かな違和感が広がる。

そのとき、

チャットが鳴った。

村瀬からだった。

『レビュー完了率100％になりました』

『順調です』

高梨は画面を見つめた。

順調。

確かに数字はそう言っている。

だが、

何かがおかしい。

何がおかしいのか。

まだ言葉にはできない。

ただ、

レビュー記録だけが増えていく。

承認済み。

承認済み。

承認済み。

誰も反対しない。

誰も止めない。

だから、

プロジェクトは前へ進む。

静かに。

確実に。

そして誰も気付かないまま。

ケーススタディ

第13話では、

レビュー会は開催されているにもかかわらず、

本来見つかるべき問題が見つからない状態が描かれました。

議事録には

「レビュー実施済」

と記録されています。

しかし、

実際には成果物の中身まで十分に確認されていませんでした。

これは多くのプロジェクトで発生する典型的な問題です。

あなたがPMならどう判断するでしょうか。

ケーススタディ

Q1

レビューが定期的に開催されているにもかかわらず、品質問題が後工程で発覚する場合、まず疑うべきことは何でしょうか。

A1｜解答例

「レビューが実施されたか」

ではなく、

「レビューで何を確認したか」

を確認するべきです。

レビュー会議が開催されていることと、

レビューが機能していることは別問題です。

実務では、

• 会議は開催された

• 出席者もいた

• 議事録もある

にもかかわらず、

成果物の内容がほとんど確認されていないケースがあります。

レビュー実績ではなく、

レビュー品質を確認することが重要です。

例えば、

• レビュー観点は定義されていたか

• 指摘事項は記録されているか

• 指摘が解消されたことを確認したか

などを確認する必要があります。

Q2

レビュー指摘件数が少ないことは、品質が高いことを意味するのでしょうか。

A2｜解答例

必ずしもそうではありません。

むしろ、

大型案件では

「指摘件数が異常に少ない」

こと自体がリスクシグナルになる場合があります。

品質が高いから指摘が少ないのか、

誰も深く見ていないから指摘が少ないのか、

区別しなければなりません。

実際には、

• レビュー時間不足

• レビュアーのスキル不足

• レビュアーの責任感不足

• 多忙による流し読み

などによって、

問題が見逃されるケースもあります。

PMは件数そのものではなく、

レビューの深さや妥当性を確認する必要があります。

Q3

PMはレビュー結果をどのように監視すればよいのでしょうか。

A3｜解答例

レビュー完了報告だけを見るのでは不十分です。

PMはレビューのプロセスそのものを確認する必要があります。

例えば、

• レビュー対象範囲

• レビュー時間

• 参加者

• 指摘内容

• 指摘密度

• 未解決事項

などを定期的に確認します。

特に重要なのは、

レビュー結果よりも

「レビューの健全性」

です。

レビューが形だけになった瞬間、

プロジェクトは品質問題を後工程へ送り込むことになります。

そして後工程で発見された問題は、

修正コストが何倍にも膨れ上がります。

レビューは儀式ではありません。

品質を作り込むための重要な工程なのです。

このケースで本当に学んでほしかったこと

レビュー会議が開催されていることと、

品質が担保されていることは同じではありません。

プロジェクトでは、

「実施した」

という事実が目的化しやすくなります。

しかし本来重要なのは、

レビューを実施したことではなく、

問題を発見できたかどうかです。

レビューが形骸化すると、

組織は安心感だけを得て、

実際のリスクを見失います。

そして誰も異常を認識しないまま、

問題は静かに積み上がっていきます。

レビューとは、

成果物を承認するための儀式ではありません。

未来の炎上を未然に防ぐための、

最後の防波堤なのです。