以前、主に座学で勉強したことをベースにプロジェクトマネジメントについて で書いたのですが、ここ２年ぐらい比較的大きめのプロジェクトを色々と経験させてもらったのでそこで得たことなどを。
ゴールの設定
- 当たり前かもしれませんが、なるべく短い期間で設定されているか。(できれば２週間、数ヶ月(2-3ヶ月)、プロジェクト全体(年単位))
- かつ具体的か(単体テストを完了させる、のではなく、ドキュメント「xx」の単体テスト項目1000個が完了済みなど。)
タスクの分割と可視化
ゴールの達成までにタスクを細かく分ける必要があるかと思いますが、以下のような点など
- ゴールまでに必要なタスクがなるべく細かく分けられているか(各人の作業ができるレベルにまで落とし込めているか)
- タスクの依存や関連(Aという作業が完了しないとBというタスクの着手ができないなど)などがわかっているか。
- タスクの完了が具体的に定義されているか
- タスクの関連、完了とも似た話しだがインプット(タスク実行の必要な情報)とアウトプット(タスクの完了)の定義が明確か
- ある程度バッファをとっているか
- 現実的に達成可能な期日が設定されているか
- またその状態が一覧で共有できるようになっているか(一般的にはRedmineやBacklog、GitHub Projectなど)
リスク要因と対策
- それにおけるリスク要因の洗い出し(類似で失敗したプロジェクト経験が大切)ができているか
- 目に見えない大変な作業(結合テストをやる前にそもそもテストデータを作ることが大変)などがないか
- そもそもゴールの達成に必要かの検討がされているか
- メンバーから問題点が上がりやすい仕組みができているか
会議
- メンバーの時間を拘束するので前提としてまず開催意義があるかを検討し、惰性でやらない
- 前提となる知識をあらかじめ共有する
- 話し合いたい内容をあらかじめ決めておき、話が飛ばないようにする
- ゴールと時間を決める
- メンバー間で議事をとって、聞いているだけのメンバーがいないようにする
- 疑問点や理解度を確認する必要あるかも
情報共有
- プロジェクト内でよく使われる言葉の定義が明確か
- 各人の頭の中だけに情報がある・・・というような状態になっていないか
- wikiなどで必要な情報がまとまっているか
- ルールが多すぎないか。見方が単純か。
KPI管理
- ガントチャートなどで作業の期日が決まっており、それに対する進捗管理ができているか
- 危険ゾーンに入っていることを認識できているか
- タスクを進捗を管理するのに作業量を数値化するようなことが必要か
- ノルマみたいになるとメンバーの心理を圧迫するのでどこまでやるかは難しいかも
ルール、文化の育成
- 適用するルールが多すぎないか
- 禁止事項などを除くと、業務改善的な推進したいルールはトップダウンだと根付かないことが多い
- そのため、問題意識のあるメンバーが行動を始め、形になった段階で、ルール化する、形にするなどが良い。
- 感情的なしこりがうまないような仕組みづくりやそういった問題を起こしそうな人間を排除できているか
