自分のプロジェクトが炎上しない理由について整理する - HIRAエンジニアブログ

自分のプロジェクトが炎上しない理由について整理する

私は自慢では無いですがプロジェクトを炎上させたことがありません。 (炎上案件に途中から突っ込まれたことはありますが)

炎上案件の経験や上司からのアドバイス、書籍からの学びによるものが大きいです。 ただ、しっかり言語化して自分のものにしたいと思い、整理しようと考えました。 これを他のPLやメンバーに共有することで炎上プロジェクトが減っていくことを期待したい。

プロジェクトマネジメントする上で、意識していること、大事にしていること

小さな火を消し続ける

 → 課題管理の徹底、朝会でメンバーと課題を共有し、期日と優先順位を決めて通常タスクより優先して取り組む。

やらないことを決める

 → 顧客が求めてないこと、成果物に直結しない作業を極力やらない。(とくに過剰な品質管理、プロジェクト管理資料の作成など)

受注前の見積もりの段階で、案件リスクを見極めて、リスクを下げるか受注しない対応をとる

 → 見積もりに人一倍時間をかける。リスクを徹底的に抽出する。リスクに合わせたバッファを工数に計上する。

受注前の見積もりの段階で、前提条件を顧客としっかりすり合わせる。

 → 疑問点、あいまいなことを無くす。リスクを下げるに通じる作業。ここに時間をとにかくかける。

  → 要件が明確になれば妥当な工数算出ができる。 (ここを適当にやる人が多い)

PLとは別に参謀を必ず確保する

 → 要員調整の段階で参謀役を必ず確保し、いない場合はメンバーの誰かを参謀に引き上げる

メンバーに課題に対する責任感を持たせる

 → 課題を自分ごとにする。課題の担当にして毎日朝会で進捗を確認する。

できない人のレベルに合わせない

 → できる人ができない人をフォローすることがあるが、時間をかけすぎない。成長の見込みを早い段階で判断する。

  場合によってはドライに切り捨てる。他プロジェクトと要員調整する。

  いない方がマシ。いることがプロジェクトにとってメンバー全員にとって良く無いことも現実にあり得る。

リーダーはメンバータスクに着手しない

 → WBSのタスクに存在しない調整ごとなどの仕事が山ほどあるので、そこに注力する。

  メンバー作業を支援するシーンもあるが、時間を取られすぎないこと。そこは参謀メンバーに担ってもらう。

大きいタスクは分割(小さく)して、進捗がわかりやすいようにする

 → 例えば1週間以上かかる作業を約2〜3日単位で分割する。

  経験上、長すぎるタスクは序盤から全力を出さないことでだいたい終盤で間に合いませんとなってしまう場合が多い。

朝会の報告が順調で、日中連絡や相談がないメンバーに声をかける

 → 本人が気づいていないがプロジェクトとして問題になり得る火種を隠しもっているケースが多い。

  おそらく問題意識の低いメンバーかもしれない。会話の中で課題が見つかることが多々あるので、1日1回は会話する。

大きなリスク(課題)が見つかったらすぐに顧客を巻き込んで打開策を一緒に考え解決にあたる

 → 課題に対する責任共有と責任転嫁という目的も含む。「じゃあ大変だからやらなくていいですよ」となることもしばしばあるため、課題は抱え込まずに顧客側に投げ込むことも重要。

  やらなくてよかったことに無駄に検討する時間を削減できる。

メンバーに好かれようとしない。

 → ドライにメンバーを公平に扱い、進捗をもって冷静に判断する。誰もがやりたくないタスクも公平に割り振る。

  反発する場合は、理由を根気強く伝え説得するが、それでもやらなければチームの士気に悪影響を及ぼすため、要員調整する。

メンバーから聞いたことを信じず、一度疑って自分の目で確認する

 → できない、難しい理由について報告がある場合、本人の言う理由を鵜呑みにしてはいけない。

  深堀質問をしたり、必ずエビデンスを自分の目で確認して納得できるまで会話する。ここで濁すと後々大きな火になることが多い。

他にもありそうですが、日々無意識レベルにやってきたことをまとめてみました。 言語化できたので、自分でも定期的に見直して振り返るようにしたい。