俺式4.0 tkDocs


Updated at: 2016-07-06

プロジェクト・マネジメント

本で読んだ内容と、実際に仕事でプロジェクトに関わった経験から得た知見のまとめ。

参考文献

はじめに

覚えておこう

  • 見積もりは確率の掛け算、正確に見積もることは到底無理
  • 色んなものはトレードオフになる
    • QCD (Quality / Cost / Delivery)
    • CPU とメモリ
  • 完璧な解など無い。エンジニアの仕事の多くは、その時々で最適な解決法を選ぶこと
  • 「やれたらやる」はまずやらない

プロジェクトの 3 つの真実

  1. プロジェクトの初めに、全てのことは分からない
  2. 要求は途中で変わるものである
  3. やるべきことは常に、与えられた時間・資金よりも多い

代表的なプラクティス

  • 大きな問題は小さくする
    • 大きいとよくわからない。小さければ何をすればいいか明確になる
    • 大きいプロジェクトは小さいプロジェクトの連続と考える
  • 「やらないこと」を決めるのも大事
  • マルチタスクは遅くなる（コンテキストスイッチには時間がかかる）ので避ける

アジャイル / スクラム

もはやポピュラーなものになってるので、キーワードだけ：

  • バックログ（ユーザーストーリーリスト）
  • 相対サイズでの見積もり（日数ではなくポイント）
  • プランニングポーカー
  • バーンダウンチャート / ベロシティ
  • スプリント

※ スクラムは試行錯誤したい系の開発には適しているが、 ある程度固いものを一定の期間で作りたい場合にはそうでもない。 プロジェクトに適した手法を選ぶとよいね

アジャイル開発のイテレーション・ゼロ

  • ストーリーの実現に入る前に済ませておくべき段取り
    • ソースコードのバージョン管理
    • ビルドの自動化
    • 開発環境、テスト環境

CCPM

CCPM が解決できる部分

  • 見積もりの大きさの個人差
  • 見積もりのサバ読み
    • （信頼を失わないために、人はバッファを大きく見積もりやすい）
  • パーキンソンの法則
    • 1. 仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する
    • 2. 支出の額は、収入の額に達するまで膨張する
    • （早く終わる仕事でも、なんやかや余った時間を使い切っちゃう）
  • 学生症候群
    • 納期が近づくほど本気出すパターン
  • 遅れだけが伝播すること（早さが伝播しないこと）

割とよかった見積もりと予実管理

これまでに仕事した中で、CCPM に基づいた以下のやり方は結構よかった：

50％-90％見積もり

タスクの洗い出し

  • やるべきことを洗い出す
  • 「50％の確率で終わる」 工数と 「90％の確率で終わる」 工数で 2 点見積もりをする
    • （終わるかどうか五分五分というチャレンジ時間と、この時間ならまあ終わるだろう、という無難な時間で見積もる）
    • （90 ％程度にしているのは、100 ％に近づけるほど予測不能に急速に近づくため、バッファを多くとりすぎるから）
  • 1〜2 日くらいの扱いやすい粒度でタスクを分けるとよい
  • みんなのタスクを並べてガントチャートを作る
    • このとき、タスクは 50％見積もり の方の時間で並べていく
    • タスクの依存関係と、担当者が時系列的に重ならないかを気にする
    • クリティカルチェーン を見つける

【用語】クリティカルチェーン
タスクに関連するリソース（人とか設備）まで考慮したクリティカルパスのこと

親方バッファ

  • 50 ％見積もりでつないだクリティカルチェーンの長さを A とする
  • クリティカルチェーン上の全タスクの 90 ％バッファ の合計を B とする
    • （ここで 90 ％バッファとは、90 ％見積もりの工数から 50 ％見積もりの工数を引いた時間）
  • A + (B / 2) で算出される期間が、「開発全体が終わるまでの妥当な工数」と見なせる

50 ％見積もりでつなげたタスクは、言うなればそれぞれ「2 分の 1 の確率で 90 ％バッファを使う」 ことになるはず。だから 90 ％バッファを半分にして足している

  • この A + (B / 2) の時間は「プロジェクト全体でみんなが共有するバッファ」として扱う
    • これを プロジェクトバッファ または 親方バッファ などと呼ぶ
  • クリティカルチェーン上にいる人が 50 ％見積もりの時間で終わらなかった時に、 この親方バッファを消費していく形になる

スケジュールの予実管理

  • プロジェクトの経過時間に対する親方バッファの消費ペースを見て、 現在のプロジェクトが余裕を持っているのか危険信号なのかを判断する

これを可視化するものとしては バッファ傾向グラフ がある

  • メンバーは今やっているタスクと、「それがあと何日で終わるか」 を明示する
    • （進捗率 xx ％、と言うよりも「あと何日」と言うほうが、いつ終わるかが明確になりやすい。 また、遅れそうな時に早めに気づきやすくなる）
  • （プロジェクト終了時に親方バッファを ちょうど消費しきるくらいが「妥当」 な開発速度であることに注意）
    • 親方バッファがたくさん余った場合は、めっちゃ頑張ったか「攻めの見積もり」ができていなかったかのどちらか
  • 基本的にクリティカルチェーン上の遅れが無いか（バッファ傾向が危険でないか）を気にしていればいい
    • ただしチェーン上になかった他のタスクが遅れて、そちらがクリティカルチェーンに切り替わるということはある

ガントチャートやバッファの管理ツール

  • 意外とこれ、ってのが無い実情
  • 綺麗にガント引けるツールはあるけど、開発始まってからの予実管理や変更、その共有に弱かったりする
  • 結局 Google スプレッドシートでセルに色塗ってみんなで編集、が無難だったり

カンバン的なもの

  • よくやる「ToDo / Doing / Done」に付箋はったりするタスクの可視化手法
  • 期間や依存関係が見やすいガントとは別に、これを併用することも有用
  • こちらは遅れや割り込みタスクなどがあったときに、「じゃあ俺がこれ代わりにやろうか」 みたいなコミュニケーションをする場として機能する

カンバンだけでやる場合

  • 小規模でストーリー重視な（締め切り重視ではない）チームなら、Trello とか使って ToDo 管理するだけでも十分だろう
    • 「ToDo / Doing / Done」 のリストを作るのが基本
    • 「要調査 / 誰か待ち」を加えると状態管理がしやすくなるのでオススメ
    • Trello は Chrome 拡張入れれば一応ガント表示したりもできる

振り返り

なぜ振り返りをやるのか

一番大事な目的

  • チームが 目指すべきものの認識を合わせる ため
    • 普段一緒に仕事している人でも、振り返りの場を設けて話してみると 「お、そんな問題あったん」「認識ズレてたわ」みたいな発見があるもの

それ以外の目的

  • これまでの仕事を思い返して改善ポイントに気づく
  • よかったことをチームに定着させる・外に広げる
  • メンバーの多様性を受け入れて信頼関係を築く

KPT

  • ポピュラーな振り返り手法
  • 3 つ書き出す
    • KEEP : よかったので今後も続けたいこと
    • PROBLEM : 問題があるのでやめたいこと
    • TRY : PROBLEM をなくすためにやってみたいこと

よくある手順

  • まず「何のための振り返りか」というテーマを決めて明示
    • 開発効率について、とかコミュニケーションの円滑化について、とか
  • 前回にも KPT をやっていたなら、その TRY ができていたかなどをサッとおさらい
  • アナログでやるならボード（or でかい紙）と付箋を用意
  • 人数多いと大変なので 6〜7 人くらいのグループに分けることが多い（分割統治）
  • 時間決めて（数分とか）KEEP を洗い出す
    • グループ内でシェア
    • 似たものはまとめる
    • その後、グループどうしでシェア。ボードに貼っていく
    • 似たものはまとめる
  • PROBLEM についても同様に
    • PROBLEM は「A が原因で B になる」みたいに原因まで書けると話が早い
  • PROBLEM が洗い出せたら「どれが特に重要な問題か」投票を行う
    • 投票が多かったものを優先的に対象にして、それを解決する TRY をみんなで書き出す
    • （基本的に TRY には対応する PROBLEM がないとおかしい）
  • TRY が出てきたら似たものをまとめて、「本当にやるか」「誰がやるか」などを決める
    • 多すぎるとまずやらない感じになるので、2, 3 個くらいに絞ってもよいと思う

注意点

  • KPT をしても、TRY のうち時間がかかるもの、面倒なものなどは放置されやすい
    • 解決すべき問題はよく目につくようにしておくとよい
    • 毎日の朝会で残 ToDo をチェックするとか、チケットをアサインしておくとか

使えるツール・テクニック

  • 円グラフアジェンダ


Copyright © 2016 Tatsuya Koyama. All rights reserved.