プロジェクトを管理するときに大事にしていること
特に出典とかはありませんが僕の経験から大事にしていることなどを書きました。社内向けのドキュメントに書いていましたが、外にも出せるかなと思い少しだけ修正しつつ記事にしました。
全体像をきちんと理解する
- 全体像を理解するとはプロジェクトの5W1Hを理解するということ
- Why: なぜそれが必要なのか、誰が喜ぶのか
- What: 何をつくるのか、何が必要なのか
- When: いつまでにつくりたいのか
- Who: 誰が関わり、誰がつくるのか
- Where: どこにつくるのか、どこでつくるのか
- How: どういう方法でつくるのか
- 全体像を把握しないと詳細に落とし込むことができない
- 理解してない状態で詳細に落とし込むと認識違いの手戻りや仕様変更の確率があがる
- 疑問点は知ってる人に聞きまくって理解する
- 把握した上でだいたいのスケジュール感でどこまでのものが提供できるのか想像する
なぜ自分がこのプロジェクトに参加しているのかを考える
- どういう役割を求められているのか
- 自分の何がプロジェクトに活かせるのか
- 自分がこのプロジェクトを完了させたときに何が得られているのか
- 何をモチベーションにしていくか
- 「自分のやりたいこと」と「リリースまでのスケジュール」の交わる点がプロジェクトのゴール
- 「自分のやりたいこと」だけやってもスケジュールが伸びるだけ
- 「リリースまでのスケジュール」だけを優先してもモチベーションが上がらない
- ちょうどいい感じのポイントを探す
管理する = 偉いではない
- プロジェクト管理することは偉いことではない
- 単純にそういう立場であるだけ
- 求められているものがプロジェクトを管理することであるだけ
- 人を管理するではない、タスクを管理する
- 上からの操り人形みたいなイメージではなくむしろ下から押し上げていくイメージ
不確実性コーンを意識する
- どんなに仕様を理解して全体を把握していても考慮漏れや仕様変更が必ずどこかである
- 今まで完璧にタスク分解できて考慮漏れがなかったことは一度もない
- 人間はリリースが先であるほど余裕をカマすのでスケジュールが巻くことはまずない
- 不確実性コーンで言えば下半分はほぼない
- もし余裕があれば（だいたいないけど）
- テストの拡充や自動化で品質を上げる
- リファクタリングなどで技術的負債を少なくする
定期的にスケジュールを見直す
- スケジュールは基本遅れるものとして考える
- スケジュールをわざと遅らせてやろうと思っている人間はいない
- 遅れることは仕方がないのでそこから未来のことを考える
- 遅れが発生した時に都度スケジュールを見直す
- 「スケジュールを見直す」とは
- プロジェクトの開始から見て見積り精度がどうだったかを見直す
- タスクの漏れがないかどうか見直す
- タスクの優先度を見直す
- メンバーのアサインを見直す
- スケジュールを引き直す
- 見直しをしないといつまでも不確実性が小さくならない
- 見直したスケジュールは共有する
ツールはなんでもいい
- 定期的に見直すことさえすれば正直なんでもいい
- ツールにこだわりすぎるとツール自体に時間をかけてしまったり逆に制限がかかったりする
- 要は第三者に遅れているのか、順調なのか、間に合うのかが説明できればいい
- あとは自分が見直しやすい感じで
決して無理をしない
- 今いるメンバーで可能な範囲でつくる、スケジューリングする
- リリースまでに間に合うか
- レビューが可能か
- リリース後のメンテナンスが可能か
- 背伸びしすぎない
- 「今流行りらいしこれ使おうぜ」
- 誰もメンテナンスできなくて最悪みたいなことが起こる
- 今いるメンバーがちょっと学びがあるくらいがちょうどいい
- 人間がこなせるタスク量は限界がある
- 無理をすると絶対にどこかがほころぶ
- 身体的、精神的な疲労は慢性的に蓄積する
情熱みたいなものも時には必要
- 人間は感情で動く生き物
- 情熱や熱意は人に影響を与える
- 「あなたがそう言うなら」といかに人に思ってもらえるか
- スキルも大事だけど最終的には人間性がものをいう