プログラマの思索

@hatsanhatさんから「スケジュールを見ればマネージャがどこまでリスクを見通しているかが分かる」という指摘を聞いて考えたことをメモ。

【元ネタ】
Twitter / @akipii: Redmineによるチケット駆動開発を成功させるには全てのタスクを1人日以下まで分割しきれるかどうかが鍵。詳細レベルまで落とし込めれば作業手順もリリースサイクルもリスクもほとんど見通せているから。スケジュールを見ればPMがどこまでリスクを見通せているかすぐに分かる。

Twitter / @akipii: @dproject21 Redmineもチケット駆動開発も銀の弾丸じゃないんですよね。プログラミングやモデリングでシステム開発をどこまで解決できるか。アジャイル開発は作業を手抜きできると思う人がいるけど結局正攻法しかないんですよね。

【1】Redmineでチケット駆動開発を運用していると、チケットの粒度はどれくらいがいいのか、という質問はよく聞く。
チケットは作業指示書であり、成果物というアウトプットを要求している。
僕が過去4年間運用して実感したことは、チケットは1人日以下のタスクまで詳細化した方がいい。

開発者の観点では、成果物が半日から1日の間で作れるレベルならば、とても作業しやすい。
開発者のリズムは、朝一番にタスク一覧から最優先のタスクを担当し、夕方までにコミットして、退社前にチケットをCloseして帰るイメージ。
1日のうちに必ず1枚のチケットが終わるリズムがあると、気分的にも楽だし、達成感がある。
何よりも、毎日の朝会で「昨日やったこと」という実績を皆に確実に報告できるのがいい。

駄目な開発者は作業の進捗が90％のまま停滞しているパターンが多い。
毎日の朝会で90％の進捗を報告するが、実際にレビューしてみると、全く動かないソースだったり、設計書の穴が多すぎるパターンがとても多い。
つまり、自分自身はほとんど出来上がっていると思っているけれども、タスクの完了基準を満たしていないのだ。

アジャイル開発の観点では、リリースできない成果物は、たとえ90％の進捗でも、実際の進捗は0％という厳しいルールがある。
その意味では、進捗率は、完了か未完了かというBooleanでいいのかもしれない。

【2】リーダーとしても、1人日以下で終わるタスクをメンバーに任せたリスクはかなり小さくなると思う。
例えば、4時間で終わると見積もったタスクをメンバーが完了報告してレビューしてみると、バグが見つかったとすれば、即座にフィードバックして修正してもらえばいい。
当初の予定工数4時間ではなく実績工数が8時間になったとしても、1日で一つの成果物を生み出した事になる。

逆に、5人日で見積もったタスクが進捗90％のまま報告され続けて、最終日にレビューしたら穴だらけだったら、5日分の工数が結局無駄になったのと同じだ。
5日かかっても完了できなかった実績を考慮すると、完成品になるまで2倍ぐらい工数がかかると思った方が良い。
リリースできない成果物、納品できない成果物はたとえ進捗90％だったとしても、完成品でないから、顧客にとって価値がない。

【3】リーダーの観点では、WBSの最下層のタスクや成果物が1人日以下のレベルまで詳細化できているならば、納品までにどのタスクをどんな順番で進めればいいか、リスクはどこにあるか、をほとんど見通せているだろう。

駄目なプロジェクトリーダーは、スケジュールという計画プロセスの成果物がとても雑だ。
ガントチャートを単に作っているだけで、そのスケジュールの実現可能性まで深く考えていないからだ。
WBSを詳細化するほど、作業や成果物の曖昧さをどんどん除去していけるし、それでも不明なものはリスクや課題として浮き上がってくる。

すると、実際のタスクはチケット一覧にあるチケットを上から順にメンバーが粛々とこなせばいいから、リーダーの仕事はそれら課題やリスクに対処するのが主な仕事になってくる。
すなわち、メンバーが解決できない課題は顧客や会社の上司、他チームへ調整したり、リスクに対して予防や是正対策などを準備したりする作業が多くなるだろう。
リーダーはメンバーの進捗管理を行う管理者ではなく、チームをどの方向へリードするか、メンバーが作業しやすい環境をいかに作るか、といったファシリテーターのような役割へ変化する。

長期の計画は将来にわたる複数のイテレーション、短期の計画は直近のイテレーションでタスクを管理すればいい。
将来のイテレーションのタスクまで詳細化できればいいが、実際はそう簡単ではない。
まずは直近のイテレーションで、1ヶ月後までのタスクを詳細化することに専念すればいい。
そうすれば、1ヶ月後には必ずアウトプットが出るし、作業した結果から、自分たちチームがどこが弱いのか、どれが強みなのか、を知ることによって、リスクや課題に対して対策を立てやすくなる。

【4】RedmineやTracはチケット集計機能が優れているので、タスクだけでなくバグも課題もリスクも全てチケット化しておけば、いくらでも好きなように抽出できる。

課題一覧はトラッカー＝課題で抽出すればいいし、障害一覧はトラッカー＝バグで抽出すればいい。
直近のイテレーションのタスク一覧は、該当バージョンでトラッカー＝タスクで抽出すればいい。
自分のタスク一覧が欲しいならば、担当者を自分でフィルタリングすればいい。
つまり、欲しい情報のSQLを投げればいいだけのことだ。

プロジェクト内部で発生する全ての作業や課題、リスクがチケット化してDBに一元化されることによって、リーダーはチケットの最新化や棚卸しに注力すれば、作業の進捗や品質を過去から未来まで追跡できる。更には課題もバグも同様に追跡できる。
「チケットの取捨選択が本来のマネジメント」というフレーズは多分そういう意味なのだろうと理解している。