『炎上案件から学ぶ』開発プロジェクトのPMに必要な能力とは？

こんばんは。it-daxです。

SIerに勤める私ですが、炎上プロジェクトというものに度々出会ってきました。
真横で　おいおいボヤが発生してるっぽいけど大丈夫か？　と心配していたら倉庫一棟火災くらいの損失を出した炎上プロジェクトも見たことがあります。

なぜプロジェクトが炎上してしまうのか？
私は炎上の原因の8割がPMにあると考えています。
わたしが過去に見聞きしてきた炎上のケースと原因を考えていきたいと思います。

ちなみにわたしがPMのプロジェクトでは一度も炎上などしたことないのでご安心ください。

ケース1 : 開発したものが使えない

これはとあるECサイトの開発で、1年の開発期間を予定していました。
PMは初PMで、メインの開発メンバーが全て外注のフリーランスやSESのメンバーでした。（おいおい…と思いながら見てました）

問題はプロジェクト開始から約半年経った頃に起こります。
なんといま開発中のシステムを全て作り直すというのです。

結局本当に作り直して、プロジェクト開始から約2年経ってから開発が完了となりました。
延長した期間の費用はPMの責任が大きいとのことで、クライアントと折半となり赤字プロジェクトになってしまいました。

なぜそんなことになったのでしょうか。
一見クライアントとの関係は良好でしたし、定例報告では順調であるという報告を受けていました。

しかし内容を見てみるととてもひどい進め方となっていたのです。

問題 : 要件定義が分からない

PMは外注のPLに要件定義や開発管理を全て任せていたそうです。
なぜそうなっていたかというと、PMが要件定義の進め方を知らなかったのです。
そしてなんと、PLも要件定義の進め方を知らなかったのです。

ここで何が起きたかというと、なんとなくやりたいことをリストにまとめて、よく分からないパワポに書くような図でそれぞれの機能の概念を書いてエンジニアに指示を出していました。
それによりデザインはバラバラ、ソースもバラバラ、まともに動かない、全く欲しい機能じゃない、というプログラミングスクールに通っているレベル以下のシステムが出来上がったのです。
決済やCMSなど技術的な難易度の高さもあり、メンバーも何も言い出せなかったようです。

解決策 : 分からないなら分からないと周囲に助けを求める

初のPMであれば要件定義が分からないというのもあると思います。
そういったときに周囲に助けを求めることができるかできないかで大きく結果が変わります。

先輩PMや社内のシステムアーキテクトをアサインしたり、サポートしてもらったり、さまざまな手段を講じることができたはずです。

このケースから学ぶPMとして必要なスキル

• プロジェクトに合った要件定義とは何か考え、計画し、遂行できる

当たり前ですが、開発プロジェクトであれば要件定義とは何か？どうやってやるのか？知っていることが必要です。
さらにコストやスケジュール、規模感などを考慮し何をどこまで作成すべきか検討できる能力も必要です。

• プロジェクトのリスクを発見し、対応できる

開発フェーズでは特に技術リスクが多いです。
例えば今回のケースでは、決済やCMSのような難易度の高い外部サービスを活用しているので、早期の検証や計画にバッファを持たせなければいけませんでした。

• 不明点を周囲に聞き、解決できること

人間1人ではできることが限られます。
分からないところは素直に分かる人に聞く。相談する。
当たり前のコミュニケーションができなければPMは難しいでしょう。

余談ですが、このプロジェクトを横で見ているときに　「分からないことがあれば聞いてくださいね」　と毎週のように言っていて、上長にも危険度が高いことを報告し続けていました。結局何も対応されなかったので炎上してしまいましたが…。
自分自身ももっと踏み込んでいけばよかったと後悔しています。

ケース2 : 成果物が検収されない

クライアントとの成果物の認識が合わせられず、検収間際に揉めてしまうケースです。
これ、よくあるパターンだと思います。

開発プロジェクトでは特に要件定義書や設計書の作成は非常に難易度が高いです。
お客様が非ITの場合、特に分かるように説明をしなければいけません。

クライアントと良好な関係性を築けているので大丈夫、とか思っていると足元を掬われます。

問題1 : 成果物の詳細を定義していない / 共通認識が合っていない

そんなことある！？と思う方もいらっしゃるかもしれませんが、よくあることです。
私の経験では3割くらいのプロジェクトが成果物の定義ができていないです。
それなのになぜかプロジェクトは進み、検収間近にあれが必要だ、これが必要だと言われてしまうことになります。

そもそも成果物の定義がない＝ゴールがない状態ですので、プロジェクトとして赤信号です。基本中の基本なので、必ず成果物を定義して、どのような内容で作っていくのか認識を合わせてスタートしましょう。

もちろん途中で変わることはあると思いますので、その都度ゴールを再設定していけば問題ありません。

問題2 : 成果物の中間レビューをやっていない

成果物を定義していても、最後に　できました！検収してください！　と言って提出しても検収されることはまず有り得ません。
クライアントにはクライアントの考えがあります。

一定のタイミングで中間レビューを開催して、クライアントの求めているものを反映しながら納得感・満足感のある成果物を作成しましょう。
1回だけやればいいとかではなく、できればこまめに、週次などで開催できると良いかもしれません。

クライアントと伴走してプロジェクトを進めること、これが重要です。

このケースから学ぶPMとして必要なスキル

• プロジェクトのゴールを常に明確にできる

• プロジェクトの道筋を常に明確にできる

プロジェクトのゴールを常に見据え、そこに至る道筋を明確にすること。
そしてプロジェクトメンバーや、ステークホルダーに常に共有すること。
PMとして一番当たり前で、一番重要なスキルであると私は考えます。

正直に言います。私が今まで関わってきた様々なSIerを含め、4割のPMはできていません。
できているつもりになっている人も沢山います。
具体性のなさや他の人の理解があまり得られていないのに、できていると思っていることが多いです。

私自身もできているつもりになっていないか、定期的に俯瞰で見ることをしています。

• クライアントの立場になって進め方を考えることができる

• こまめな報連相

クライアントが望むもの、望み以上のものを作りあげていくには常にコミュニケーションが重要です。
自分がいいと思ったものがクライアントにとっていいものとは限りません。
きちんと報連相を行い、クライアントの考えや価値観をトレースし、ブラッシュアップされた成果物を提供する。
これがPMのあるべき姿だと考えています。

ただ要求を聞いて書き起こすのであればPMがいる必要はないでしょう。
スケジュール管理や予実管理だけなら誰でもできます。

プロジェクトの成功に責任を持つ者として、より良い価値を提供できる能力がPMには必要です。

おわりに

炎上、嫌ですよね。
冒頭でわたしは炎上させたことがないと記載しましたが、大炎上したプロジェクトのPMを引き継いだことはあります。
毎日が地獄でしたね…。メンバーで鬱になった人も6人くらいいました。

そんなことにならないよう、日々の学びを大事に丁寧にプロジェクトを進めていきましょう。