第20話｜この不具合、誰の責任ですか？｜東央ソリューションズ―― 実務統合型PM論・連載小説

午前八時四十分。

高梨が出社すると、Teamsの通知が止まらなかった。

未読。

四十八件。

メール。

二十三件。

不具合管理表。

更新あり。

「またか……」

小さく息をつく。

席に着く間もなく、白石が駆け寄ってきた。

「高梨さん。」

「昨夜の総合テストですが……。」

その表情だけで、何が起きたのか分かった。

「重大不具合です。」

会議室には、東和物流の田辺もオンラインで参加していた。

画面には不具合一覧が映る。

赤い行が並んでいる。

物流センターへの出荷データ。

在庫更新。

配送実績。

どれも業務影響が大きい。

田辺が静かに口を開く。

「昨日までは問題ないと聞いていました。」

誰も返事ができない。

開発リーダーが説明する。

「調査したところ、仕様どおり動作しています。」

田辺が眉をひそめる。

「現場では動いていません。」

「ですが設計書では……」

「現場は設計書で仕事をしているわけではありません。」

部屋が静まり返る。

別の担当者が口を開く。

「こちらは他システムから渡されるデータ形式が想定と違っています。」

田辺が資料をめくる。

「その仕様は、いつ決まりましたか。」

「要件定義時です。」

「現場は知りません。」

また沈黙が流れた。

白石が小さくつぶやく。

「DX推進室では了承いただいた認識でした……。」

田辺は首を横に振る。

「DX推進室と物流センターは別組織です。」

「現場責任者は、この仕様を見ていません。」

その一言で、高梨は目を閉じた。

まただ。

誰も嘘はついていない。

それぞれの部署では、確かに合意している。

しかし、

全体としては誰も合意していなかった。

午後。

不具合対策会議。

ホワイトボードには不具合番号が並ぶ。

No.521。

No.522。

No.523。

その横には、

「担当」

という欄だけが空白のままだった。

「これは開発でしょう。」

「いや、仕様です。」

「仕様は顧客承認済みです。」

「現場では承認していません。」

「インフラの問題では？」

「連携先のデータです。」

「運用手順では？」

言葉だけが飛び交う。

不具合は、一件も減らない。

高梨はホワイトボードを見つめていた。

不具合番号。

担当未定。

対応期限。

すべて空白。

誰も「直します」と言わない。

いや。

言えないのだ。

責任が決まらないから。

黒田が静かに立ち上がる。

マーカーを手に取り、

「担当」

の欄へ一つずつ名前を書き始めた。

「原因は後でいい。」

「まず、誰が直すか決める。」

部屋の空気が少しだけ変わる。

「責任と対応は違う。」

「対応者がいなければ、不具合は一件も減らない。」

誰も反論しなかった。

夕方。

高梨は不具合一覧を更新していた。

午前中。

重大不具合。

十二件。

現在。

重大不具合。

十二件。

件数は、一つも変わっていない。

修正が進まなかったからではない。

議論ばかりで、

誰も作業できなかったからだ。

帰り際。

田辺からチャットが届く。

高梨は画面を見つめた。

今日、一番救われた言葉だった。

夜。

オフィスには、まだ多くの席の明かりが残っていた。

誰も帰らない。

誰も諦めていない。

それでも、

不具合一覧の数字だけは変わらない。

不具合は、人を責めていても減らない。

直して初めて、一件減る。

その当たり前のことに気付くまで、

プロジェクトはまた、一日を失った。

ケーススタディ

第20話では、不具合そのものよりも、「誰が対応するのか」という議論が前に進まない様子が描かれました。

開発は、

「設計どおりに作っています。」

顧客は、

「現場では使えません。」

DX推進担当は、

「合意済みの認識でした。」

それぞれの発言は間違っていません。

しかし、その間にある認識のズレが、リリース直前になって一気に表面化しました。

そして会議では、

「誰が悪いのか。」

という議論ばかりが続き、

「誰が対応するのか。」

が決まりませんでした。

実際のプロジェクトでも、不具合が多発する終盤では、このような状況に陥ることは珍しくありません。

では、PMはこの状況をどのようにマネジメントすべきだったのでしょうか。

ケーススタディ

Q1

リリース前に不具合が多発した際、最初に議論すべきことは何でしょうか。

A1｜解答例

最初に議論すべきなのは、

「誰の責任か」ではなく、「誰が対応するか」です。

リリース直前は、一時間、一日という時間が品質へ直結します。

責任の所在を整理することは重要ですが、それは緊急対応の最優先事項ではありません。

まずは、

• 誰が原因調査を行うのか

• 誰が修正するのか

• 誰が影響範囲を確認するのか

• 誰が顧客へ説明するのか

を明確にし、対応を開始する必要があります。

責任論だけが先行すると、会議だけが長くなり、不具合は一件も減りません。

だからこそ黒田は、

「責任と対応は違う。」

という考え方を示しました。

これは炎上案件ほど重要になるPMの基本原則です。

Q2

なぜ「仕様どおりに作った」のに、「現場では使えない」という状況が起きるのでしょうか。

A2｜解答例

要件定義や設計書で合意した内容が、そのまま現場業務に適合するとは限らないためです。

特に大規模プロジェクトでは、

• DX推進部門

• 情報システム部門

• 現場部門

• ベンダー

など、多くの関係者が存在します。

ある部署では合意していても、

別の部署には十分に共有されていないことがあります。

その結果、

「仕様どおりに開発した」

「でも現場では運用できない」

という認識のギャップが生まれます。

このような不具合は、プログラムの品質ではなく、

コミュニケーションや合意形成の品質によって発生するケースも少なくありません。

Q3

PMはリリース直前の不具合対応をどのように管理すべきでしょうか。

A3｜解答例

リリース直前では、不具合管理を「一覧表」だけで終わらせてはいけません。

重要なのは、

一件ごとのオーナーを明確にすることです。

最低限、

• 不具合ID

• 優先度

• 対応担当

• 原因調査担当

• 修正予定日

• 確認担当

• ステータス

を管理し、

日次で更新する必要があります。

また、

重大な不具合ほど、

「誰が持っているか分からない」

状態を絶対に作ってはいけません。

PMは、技術的な修正を自ら行う立場ではありません。

しかし、

「対応が止まらない仕組み」を維持することは、PMの重要な役割です。

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

プロジェクトが炎上すると、

原因究明や責任の整理に多くの時間が費やされます。

もちろん、再発防止のためには必要な取り組みです。

しかし、

リリース直前という限られた時間の中では、

最優先すべきことが変わります。

それは、

「責任を決めること」ではなく、「不具合を減らすこと」です。

誰が悪いのか。

どの部署の責任なのか。

それらを議論している間も、不具合は一件も減りません。

だからこそPMには、

「責任」と「対応」を切り分けて考える冷静さが求められます。

対応を止めない。

判断を止めない。

そして、現場を止めない。

それが、炎上プロジェクト終盤におけるPMの最も重要な役割です。