炎上プロジェクトの原因は認識齟齬。PM2人の新卒時代の体験談

すぅさんは炎上プロジェクトの話をしたいと切り出しました。各PMがどんな炎上を経験したかを聞くと、その人のプロジェクトの進め方が見えてくるからだといいます。

すぅさんは新卒でITコンサルの会社に入り、約2年間、ずっと炎上プロジェクトに入っていたそうです。火消し隊員として放り込まれ続けた結果、炎上への耐性がついたと話しています。

特に思い出深いのは、メーカー向けの会計パッケージの移行プロジェクトです。リリース後、ボタンを押してから次の画面に切り替わるまでに1分以上、ものによっては10分かかる状態でした。

原因調査では、SQLファイルを目視で読み、どのテーブル同士が結合しているかを確認して、自力でER図を作りました。この間、当時のプロジェクトリーダーは夜中に倒れて救急搬送されたといいます。

自力で調べたため、すぅさんは現状と原因に詳しくなりました。顧客からの信頼も少しずつ得られ、炎上の中でも評価されたそうです。この経験は、現場感を大事にする今の姿勢につながっているといいます。

やましょーさんは、炎上した瞬間にチームのモチベーションが下がり、スケジュールを組み直す大変さがあると話します。一貫してポジティブだったのかと、すぅさんに尋ねました。

すぅさんは、1年目で責任がなかったため、責任感をあまり感じず作業を進められたと答えます。

やましょーさんは、炎上と自分の責任を切り離したほうが精神衛生上よいと考えています。すぅさんも強く同意しました。

すぅさんはこの評価がきっかけで、炎上プロジェクトばかり任される状況になったと話します。「地獄のフラグ」と冗談めかしています。

やましょーさんの上司には、炎上案件が嫌いではないという人がいたそうです。理由は、炎上案件にアサインされた時点で評価が底に決まっていて、あとは上がるだけだからでした。

その上司は、解決策にひねりは要らず、馬力を出せばプロジェクトが良い方向に進むので、不確実性が少ないとも話していたといいます。

すぅさんは、やるべきことが明確だという点に納得しました。たとえば先ほどの例では、ボタンを押したら2〜3秒以内に返る当たり前の状態に戻せばよいという話です。

ただし、やましょーさんは、打ち手がシンプルであることと、やりたいことは別物だと付け加えました。

やましょーさんの炎上の火種は、若手ゆえの至らなさでした。大企業の機能組織で広告商品の開発を担当していた新卒時代の話です。

事業組織から出た広告商品の要望をそのまま開発側に伝えたところ、開発側の場で厳しく詰められました。事業側と開発側の間で板挟みになったといいます。

「そんなので本当に売上が立つと思うのか」と問われても、やましょーさんには意味がわかりませんでした。相手先の上司は怒り始め、お土産として食パンを買って送ったこともあったそうです。

すぅさんは、これを「まともな上司」だと評します。やましょーさんも、今思えばよい上司だったと認めつつ、当時は味方になってほしかったと振り返りました。

この経験から、やましょーさんはあらゆるミーティングに自分の仮説を持って臨むようになり、準備にも時間をかけるようになったといいます。

別の上司からは、広告の設定まで一から百まで知っておくよう、各論に強くなることを繰り返し言われていました。すぅさんは、若手が価値を出せるのは仕様に詳しいことだと共感しています。

すぅさんは、2年間の経験から、炎上プロジェクトの原因は認識齟齬にあると考えています。炎上は起こるべくして起こるといいます。

認識のズレには、目的やゴール、責任者、スケジュール、要件などの種類があります。細かなズレが積み重なるほど、最終的に期待値との差が大きくなって燃えるという考えです。

やましょーさんは、Xでよく見かける、顧客・リーダー・アナリストの理解が食い違うブランコの絵を例に挙げました。言葉だけで認識をそろえるのは難しく、言い換えや繰り返しで形を合わせる必要があると話します。

すぅさんは、要件を伝える窓口の部長クラスと実際の現場がずれている例を挙げました。その人が本当に正しいかまで深掘らないと、ズレは防げないといいます。

やましょーさんは、苦労して読み込んだ資料が実は古いバージョンだった経験を話しました。ただ、新旧の違いを知ったことで、プロジェクトの思想がわかり、知識の血肉になったとも振り返っています。

スケジュールについても、すぅさんは「いつまでに何が終わっているか」がふわっとしがちだと指摘します。顧客、ユーザー、メンバーそれぞれとの認識のズレをなくすことが大切だという考えです。

日々の連絡で状況のズレを細かく共有していれば、要件を満たせなくても「仕方ないよね」となり、うまくいくことがあるといいます。

やましょーさんは、炎上の手前には、ヒヤリハットのような認識齟齬がシグナルとして必ずあるはずだと話します。日々のコミュニケーションで認識を確認するだけでも、かなり防げるという考えです。

すぅさんは、誰も完璧を求めてはおらず、最初から計画どおりにいかない前提で動くことが大切だといいます。PMが「ちゃんとしなきゃ」と無理をするとズレやすいとも話しました。

すぅさんは、ボタンを押して何時間も返らない状態で、よくリリースできたと今も不思議に思っています。推測として、テスト時はデータが少なくうまくいったが、本番はデータが多すぎたのではないかと話しました。

やましょーさんは、その場合はテストケースが不十分だと指摘しています。

すぅさんは、AIで素早くモックを作れるようになり、完成イメージの認識齟齬は減ったと見ています。今後は成果物以外の認識齟齬に力を入れたいと話しました。

すぅさんは、顧客側にも明確なイメージはなく、「可愛い感じ」「かっこいい感じ」程度のことが多いと話します。大量の選択肢でイメージをそろえたり、実物に触れてもらったりできるのがこの時代のよさだといいます。

やましょーさんは、一旦自分の中の答えを出しやすくなった分、それを基に議論するとギャップが見えやすくなると話します。大外しした場合も、方向を変えやすいといいます。

まとめ

PM2人の新卒時代の炎上体験から、炎上の原因は関係者間の認識齟齬にあるという考えが語られました。日々の確認とAIによる早い試作が、ズレを減らす手立てになります。

• すぅさんは新卒で炎上プロジェクトに入り、全ボタンの反応時間測定やER図の自作で現状と原因に詳しくなった
• 炎上を自分の責任と切り離すと、精神衛生上よいと2人は語った
• やましょーさんは上司に「お前はどうしたいんだ」と問われ続け、仮説を持って臨む習慣がついた
• 炎上の原因は、ゴール・責任者・スケジュール・要件などの認識齟齬にある
• AIで試作品をすぐ作れるようになり、完成イメージのズレは早めに見つけやすくなった