hrfmmr's blog

テコ入れ検査可能なプロジェクト管理を考える

Posted on | 105 words | ~1 min

Context

  • (ソフトウェア)プロジェクト管理もといスケジュール管理のあり方について
  • 比較的規模のある開発計画を引くとき、人は全体像と着地予想を立てる上でガントチャートを引く
    • 全体像や依存関係/クリティカルパスを把握する可視化ツールとしては有用なのは違いない
    • 一方で、これをベースに進行管理していくと、「間に合うか/間に合わないか」でしか状況評価できない側面があり、むずかしい
    • 想定通りに推移しない場合、「間に合わない」時点で問題が発覚しがち
    • リカバリの初動がとりづらく、その時点で手遅れの場合も
    • INFO->INFO->INFO->SIGSEGV🫠 👀👀👀!!?
  • 状況共有も「ガント上のここをやっている。ここまで出来た」に終始しがちで、個別具体なタスクレベルの調整/問題解決のコミュニケーションはできるものの、スケジュール管理という観点では「ふーん」で済まされがち
  • 「ふーん」を超えたい

「ふーん」の超え方

  • INFOからSIGSEGVに落ちる前でWARNやERRORを吐けること
  • 「テコ入れの必要性」「抱え込んでいる不確実性/不安量」を観測/検査したい

2つの不確実性の見える化

  • a.) スケジュール不安
  • b.) プロジェクトの不確実性の所在

スケジュール不安の可視化

我々は順調なのかどうか、をどう検査するか

バッファ消費率という考え方

  • CCPMにおけるバッファマネジメント
    • 不確実性管理のために、タスクの終了期限ではなくプロジェクトバッファの管理にフォーカスを当てる
    • タスク毎にバッファを設定せず、プロジェクト全体で1つのバッファをもつ
    • 進捗に応じて、バッファ消費率を観測する
    • バッファ消費率の観測のなにがうれしいか
      • バッファ消費率の見える化によって、進行状況がgreenかyellowかredかを検査できる

  • 赤線: redゾーン境界のバッファ消費率(完了時点90%消費)

    • これより上にプロットされていると、危険域
    • テコ入れの検討を行う

  • 黄線: greenゾーン境界のバッファ消費率(完了時点40%消費)

    • これより下にプロットされていると、安全域

  • ガントチャートとの違い

    • ガントでも「遅れている」状況自体は把握できる

  • 早期検知できるかどうか

    • ガントだとバッファが消費されきった時点で「遅れ」に気付く
    • バッファ消費率ベースの観測では、消費しきる前の段階で「遅れ」具合を検知してリカバリのアクションがとれる

  • バッファ消費率の算出

    • 消費バッファ量 / 全体のバッファ量 * 100
      • 消費バッファ量
        • あるタスクが計画では2日で完了する予定だったが、実際には3日かかった場合、1日分の遅れが発生し、これがバッファ消費とみなされる
    • プロジェクト全体の工数が10日で25%のバッファを設定していた場合、バッファ消費率は(1/(10*0.25)) * 100 = 40%

  • 進捗率の算出

    • どう進捗率を評価するか
    • 完成度(「どこまでできているか」)ベースの評価
      • 「10の内7までdoneしているので70%」?
    • 70%に至るまでの推移と残りの推移は果たしてリニアな関係性(逆算可能といえる)か
    • 結局のところ「残り3」がどれくらいかに依る
      • 「残り3」の係数がわからないことには着地予想がつかない(70%という数字を正しく評価できない)
      • 完成度ベースで定量的に「残り3」だとしても、「(全体工数10日タスクに対して)日数的にはあと1週間かかりそう」という状況なら、70%と捉えてよいものか?
      • 完成度で進捗率評価しても、スケジュール管理する上ではミスリードを招きかねない
    • 不安量を可視化/管理する上では、「どこまでできているか」より「あとどれくらいかかるか」の方が都合が良い
      • 都合が良いwhat
        • 織り込まれている情報量が違う
          • 「どこまでできているか」ベースの進捗評価は、およそ当初計画に対しての完成度にとどまる
          • モノづくりにおいては、完成度が高まるにつれ、作り変える余地や直しどころもまた必然的に発生してくるもの
          • 進行途中に生まれた当初計画外の「やるべきこと」は、完成度ベースの進捗評価には織り込まれていない(がち)
          • 「あとどれくらいかかるか」ベースの進捗評価では、最新のステータスがすべて反映された上で出されるので、その分信頼が置ける
      • 「あとどれくらいかかるか」ベースの進捗評価方法
        • 予定工数10日に対して「あと3日」という状況なら70%と解釈できる
        • (完了の定義の話はここでは割愛)

  • バイアスがかかりづらく且つ答えやすいように、楽観/平均/悲観の3点で見積るとよい

    • 楽観と悲観の差が「不安量」といえる
      • 差が顕著に大きい場合、「何が明らかになると、差が縮まるか」という問いから、抱え込んでいる不確実性をブレークダウンしていける

プロジェクトの不確実性の所在

前提として、「プロジェクトの不確実性をなるたけ早期に解決できていることが望ましい」という考え方をもつとして (「どう転ぶかわからない」要素がなく、「やるだけ。作業。」なタスクのみで構成されていればいるほど、見通しが立てやすく、着地させやすい)

スケジュール不安の可視化の他、プロジェクトが抱え込む不確実性がうまく削減していけてるかについても観測/テコ入れ検査可能にしたい
プロジェクト後半に差し掛かる時点で不確実度の高いタスクが多く残っている状況では、スケジュール予測の幅が収束せず、リリース時期と照らし合わせた事業上の判断が難しくなることがある
進捗に応じて予測の幅が収束していくのが望ましい

「あとどれくらいか」についての楽観/平均/悲観の3点見積の時系列プロットから、「不安量」の変化を観測できる
楽観と悲観の差の変化が不確実性の収束度を表す

トレンドラインとして進捗率に応じて減少傾向にあればうまく収束していっているといえるし、そうでなければ不確実性を抱え込んだままになっている(リスクの所在を明らかにするムーブとその対策について要検討という解釈になる)

見える化どうやるか

任意の時点で「あとどれくらいかかりそうか」を入力することで、上記の可視化が行えるシートを作成してみた https://docs.google.com/spreadsheets/d/1eoZDk0yx5jwQupLD6Yzhm_ZKpn8LmEprWP5wSttfVV4/edit#gid=417401277

  • (※CCPMを引用したものの、その作法に精通している者によるアレではない点注意)

まとめ

  • プロジェクト進行にあたり2つの不確実性の見える化を図ることで、テコ入れ検査可能なプロジェクト管理が行える(のではないか)
  • a.) スケジュール不安
    • バッファ消費率を観測することで、スケジュール不安を見える化
    • 「危険域にプロットされないか」観点での検査が行える
  • b.) プロジェクトの不確実性の所在
    • 楽観/悲観見積の差を定期観測することで、不確実性の収束具合を見える化
    • 「進捗に応じて不安量が削減されていないか」観点での検査が行える

参考