スケジュールを見ればマネージャのレベルが分かる
@hatsanhatさんから「スケジュールを見ればマネージャがどこまでリスクを見通しているかが分かる」という指摘を聞いて考えたことをメモ。
【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に一元化されることによって、リーダーはチケットの最新化や棚卸しに注力すれば、作業の進捗や品質を過去から未来まで追跡できる。更には課題もバグも同様に追跡できる。
「チケットの取捨選択が本来のマネジメント」というフレーズは多分そういう意味なのだろうと理解している。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
- プロセス設計はどの範囲を指すのか?~プロマネの仕事はテーラリングにある(2022.06.19)
「Redmine」カテゴリの記事
- 第25回東京Redmine勉強会の感想 #redminet(2023.11.05)
- 第24回redmine.tokyo勉強会の感想 #redmineT(2023.06.03)
- 「Redmineハンドブック」は良い本です(2022.12.17)
- 第23回東京Redmine勉強会の感想~コミュニティは仲間から生まれて続く #redmineT(2022.11.06)
- 第22回東京Redmine勉強会の感想 #redmineT(2022.05.29)
「ソフトウェア工学」カテゴリの記事
- 「ソフトウェアアーキテクチャ・ハードパーツ」の情報リンク~マイクロサービスの設計技法の課題は何なのか(2023.11.12)
- パッケージ原則とクラス原則の違いは何なのか(2023.10.14)
- パッケージ設計の原則の意義は変化しているのか(2023.09.30)
- QAエンジニアの役割は開発チームのガードレールみたいなものという考え方(2023.08.21)
- テストアーキテクチャ設計モデルとJSTQB概念モデルの比較(2023.07.02)
「プロジェクトファシリテーション」カテゴリの記事
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 「世界を動かすプロジェクトマネジメントの教科書」の概念図(2022.01.16)
- 【資料公開】チケット駆動開発の解説~タスク管理からプロセス改善へ #redmine(2022.01.14)
- 昭和の管理者の承認処理は判子押印、令和の管理者の承認処理はいいねボタンを押すこと(2021.12.31)
- チケット駆動開発のプロセスとチケット管理システムの全体像 #Redmine(2021.12.28)
「チケット駆動開発」カテゴリの記事
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
- タスク分割は親子チケットにすべきか、それともチェックリストにすべきか #redmine(2022.03.04)
- Redmineにメンション機能が入るらしい(2022.01.15)
「Agile」カテゴリの記事
- 概念モデリングや設計原則は進化しているのか(2023.10.21)
- パッケージ設計の原則の意義は変化しているのか(2023.09.30)
- 日本のアジャイル開発の先人による話が良かった(2023.07.15)
- JSTQBのテストプロセスの概念モデルを描いてみた(2023.05.26)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
コメント