私自身これまで複数の開発案件でプロジェクトマネジメントをしてきました（開発もするプレイングマネージャー的な感じで）
※マネジメント規模は数人～60人規模まで様々（システム開発・ソーシャルゲーム開発が主）
これまでプロジェクト炎上案件の立て直しを何件も実施してきました（立て直しは一番やりたくない…）
今回は「なぜ炎上するのか・どうしたら炎上しないのか」に焦点を当てて、炎上案件について共通点や回避策など実際の実例を交えて複数回に分けて纏めておこうと思います（※現職がゲーム開発なので、ゲーム開発を例にして記述します）
みなさんの周りに何も解決できない「なんちゃってPM」はいませんか・・・？
※スカウターの話は後半で出て来ます
##プロジェクトが炎上する理由
いきなりですが、プロジェクトが炎上する理由は
プロジェクトマネジメントしている人間のマネジメントスキルが低いから
です。
「そんなの当たり前だろ！」と思われる方もいるかと思いますが、
誰だって炎上したいと思って、プロジェクトマネジメントしている訳ではないはずです。
プロジェクトマネジメントが難しい理由は、
全く同じプロジェクト（人・物も同じ）が存在せず、絶対に勝てる方程式が事前に立てられないからです。
「じゃあ行き当たりばったりで頑張るしかないし、炎上してもしょうがないか・・・ははは・・・」
そんな考え方しているプロジェクトマネージャーがいたら、一刻も早くそのプロジェクトから抜け出しましょう。
炎上しておきながら、
「あれはXXと〇〇の要因があったから、炎上したのはしょうがないよねー。不可抗力だよ。」
なんて発言を聞いたことはありませんか？残念ながら私はあります・・・
そんな訳ないのです。
断言できますがプロジェクトが炎上したらプロジェクトマネージャーの責任です。
どんな大規模で複雑なプロジェクトであっても、炎上してもしょうがないプロジェクトなんてないはずです。
※天災など本当の不可抗力は除きます
##プロジェクトマネジメントで一番大切な事
マネジメントスキルが高ければ炎上し辛いわけですが、それはどのようなスキルなのでしょうか？
この記事をご覧になっている方であれば、PMBOKやWBSやCCPM…など様々なプロジェクト管理手法についてご存知かもしれません。
実際に私もプロジェクトマネジメントスキルを向上させる為に、様々な開発手法・人間の心理について学んだりしました。
今回は難しい話は抜きにして「プロジェクトを炎上させないために重要なことは何か」を自分なりに記述します。
私がプロジェクトマネジメントで最も重要だと思う事は
「どんな時でも常にゴールを描けているか（あらゆる障害があったとしても）」という事です。
抽象的な書き方ですが、例えば
・開発する機能に対して期日が圧倒的に足りない・・・
その時PMはその問題に対してどんなゴールを描く？
・チームメンバーの衝突がありチームビルドに悪影響が・・・
その時PMはその問題に対してどんなゴールを描く？
・クライアント(または社内の企画者)が無茶なことを言ってきた・・・
その時PMはその問題に対してどんなゴールを描く？
・メンバーの士気を上げ開発速度を上げたい・・・
その時PMはその問題に対してどんなゴールを描く？
…etc
プロジェクトに障害はつきもので、開発中は毎日なにかしらの障害が発生します。それも複数！大量に！
障害を解決しチームをゴールに導くのがプロジェクトマネジメントですので、毎日発生する障害たちと戦っていく必要があります。
忌々しい障害達をパーフェクトに打ち負かすことができれば、プロジェクトが炎上する事なんてないのです。
ではプロジェクトマネジメントする上で「日々の障害と戦うこと」が重要だと分かったところで、
障害達と戦うにはどんなスキルが必要なのでしょうか？
##日々の障害との闘い。その時あなたはどうする・・・
では実例を挙げてみましょう（一部ぼかしています）
忌々しいプロジェクト障害：その1
障害概要：メンバーの相性問題
障害レベル：Easy？
ZZプロジェクトのプロジェクトマネージャーをしていたある日、
エンジニアのAくんの担当している機能開発に遅れがある事に加えて、なにやら元気がない事を察知した。
Aくんのやる気低下がチーム全体に悪影響をおよぼしかねないと判断し、Aくんにヒアリングを実施すると
どうやら同じチーム内のエンジニアBくんとそりが合わない模様。
◆Aくんからのヒアリング内容
・Bくんとペアで開発しているXX機能(遅延している機能)の設計について話をして方針を決めたが、決めたことを守って実装してくれない
・自分は何度も伝えているが、Bくんは分かってくれない
・もうBくんと一緒に開発するのは難しいと思っている
簡単に纏めると上記のような話を聞きだしました。
さて、Aくんから話を聞きだしたこの段階で重要な事はなんでしょう？
Aくんの意見を尊重し、Bくんに対してダメな部分をPMが注意する事をAくんに約束し、その場をなだめる
のような解決策はこの場合パーフェクトな解ではありません。
一般的な解法の例としては、
その場ではAくんの意見を真摯に受け止め解決する旨を伝えたうえで、
さらにBくんにヒアリングを行いお互いの意見を総合的に判断し解決策を練る
だと思われます。
両者の意見を総合的に判断し解決策を見出す事が重要だ。とマネジメントの教科書には書いてありそうです。
が、残念ながら文章で書けるほど簡単ではない場合が、実際のプロジェクトでは往々にしてあります。
難しくなる理由は、上の条件に加えてAくんBくんそれぞれの「スキル」「性格・思考」「特性」「体調」「相性」…等あらゆる条件が加わるからです。
実際に私が上記障害に出会ったときの問題の真因は下記のような物でした。
◆問題の真因
XX機能の実装難易度が高く、AくんとBくんの間にXX機能開発に必要な知識の差が大きく、
Aくんは知識差のある人に対して、上手く伝える方法を理解していなかった事（伝えたつもり ＝ Aくんにとって相手が理解したかは関係ない）
Aくんの性格は「はっきり物を言うタイプ」だったのに対して、Bくんの性格は「心優しくできない事でも頑張ろうとするタイプ」だった事
※Aくんが説明してくれた事に対してBくんは何度か質問し直したが、何度も説明してもらうのが申し訳なくなってしまい、自分なりに理解した方法で実装を開始した。
※その他要因もありましたが、複雑にし過ぎない為に割愛します
解決するために行ったことは、
- XX機能の設計についてAくんへヒアリング行い、設計方針について確認する
- Bくんに対してXX機能の設計方法を理解できるように伝える（Bくんのスキルを考慮した上で教えた所、理解できた）
- Aくんに対して「伝え方(エンジニア特有な部分有り)」「アサーション：相手(Bくんのようなタイプ)を理解する事を重点的に」について伝える（Aくんを尊重しつつ）
- Bくんに対して「伝える事の重要性」「アサーション：相手(Aくんのようなタイプ)を理解する事を重点的に」について伝える（Bくんを尊重しつつ）
- 3, 4の時点で考え方に変化が見られた為、二人を交えてMTGを行いリスケして二人でXX機能開発を進める事を約束させる
上記の対応を行い、無事にxx機能の開発を終了しました。
その後、Aくん、Bくんは別機能開発でもペアを組んでスムーズに開発をこなせています。
今回の例では、人が持つ実力・特性を見抜く能力、通称スカウター（と勝手に名付けました…）がとても重要なのです！
AくんとBくんの特性や実力を見抜けなかったら、解決が遅れたり、最適ではない対策を選んでしまった可能性が高かったでしょう。
人はみな違うのです。
スカウターはプロジェクトマネジメントの色々な局面で役に立ちますので、意識しておいて損はないはずです。
スカウターが壊れた人が上の立場にいると、適材適所の人員計画が難しくなり、
間違った人材を重要なポジションに配置してしまう事で、極端にプロジェクトの成功確率(炎上しないって意味の)が低下します。
今回の話はプロジェクト全体からすると小さく局所的な障害を例に挙げましたが、
このような小さな事でもきちんと解決していかないと、積もり積もってプロジェクトの炎上に近づいていくと私は思っています。
別の視点からこのケースを考えると、スケジュールも押していたので、マネジメントの仕方によっては、Aくん or BくんをXX機能開発から外して別の人員を入れるという決断もできたでしょう。
では「リスケしてでも関係修復を実施した解決策」or「スケジュール順守して別人員で対応」どちらが正しかったのでしょう？
私のケースではXX機能をリスケしても他で巻き返せる算段が付いていたので、前者を選択しました。
どっちが正しかったかは正直判断が難しいです。
一つ言えるのは、プロジェクトマネージャーは必ず「チームにとって最善の解決策」を選択すべきだという事です。
今回の例はチーム全体に対する影響度が小さい人事関係の障害したが、絶対に対策を誤ってはいけない障害も多々発生します。
大分長くなってしまったので、またの機会に・・・
次回はもっとプロジェクトマネジメントの本質的な部分について触れてみたいと思います。
いままで一度も完璧なマネジメントができた！と思えたプロジェクトはありません。
「いつも違うから難しい。でも、いつも違うから面白い」それがプロジェクトマネジメントなのかな・・・と思っています。
みなさんの会社のマネージャーはプロジェクトで障害が発生したときにゴール(最善の解決策)を描けてますか？
追記：続編 [なぜプロジェクトは炎上するのか？vol.2～スカウターの真意～](https://qiita.com/J_Shell/items/af9595db5f89e7ac8deb)