ミクロ地獄図とは？
開発タスクの依存関係を描きだした図です。
以下にミクロ地獄図のサンプルを示します。
こちらはFigJamで描かれていますが、図が描けるツールなら何でも良いと思います。
描くのが地獄のように大変なところから「ミクロ地獄図」と命名されましたが、実際はそこまで大変ではありません。
なぜミクロ地獄図を使うのか？
弊社ではスクラム開発を取り入れていて、開発タスクの管理にGitHub Projectsを使用していますが、以下のような課題が上がっていました。
- 開発タスクの依存関係がパッと見てわかりにくい
- 今現在のタスクの進捗がパッと見てわかりにくい
- 開発以外のタスクとの依存関係が表現しにくい
- 締め切りまでに完了させなければいけないタスクが漏れることがある
このようなの欠点を補間するために、ミクロ地獄図を活用しています。
ミクロ地獄図の運用例
イメージが掴みやすいように、弊社で実際に運用している流れを書いてみます。
登場人物は、プロダクトマネージャ(PdM)、開発者(Dev)、カスタマーサクセス(CS)、UIデザイナー(UI)です。
------------------------------------------------------
PdM「新しいプロジェクトとして『すごい掲示板』を作りましょう！これが仕様書です」
Dev「（仕様書を読む）これはすごい！早速ミクロ地獄図にざっくりとした開発タスクを書いてみます」
PdM「ありがとう！それぞれのタスクがどれくらいかかるか、見積もり会をやりましょう！」
PdM「Tシャツサイズでざっくりと見積もりしました！」
PdM「最後まで完成させてからリリースすると時間がかかりそうですね。記事を書けるところまでをMVPとして、コメント機能は追加リリースにしましょう。それぞれをグループ化してみます」
PdM「締め切りを一旦仮で書いてみます」
PdM「これで行けそうですか？」
UI「大丈夫です！」
Dev「大丈夫です！」
PdM「リリース前に顧客にお知らせしたいけど大丈夫ですか？」
CS「はい。大丈夫ですが、リリース前に少し触っておきたいです」
PdM「確かに。CSも含めてQA会を開きましょう。フィードバックがあったら直す期間も入れてと。すこし締め切りを伸ばしますね」
PdM「よし、これでスケジュール確定！」
Dev「了解です。開発タスクの依存関係を引きますね」
PdM「いいですね！早速MVPから開発を進めてください」
Dev「はい。まずはGitHub Projectsにissueを作ってミクロ地獄図に インポート します」
Dev「GitHub Projectsのほうで開発を進めて行きます」
PdM「開発が終わったタスクは済マークをつけてください」
PdM「どこまで終わったか一目瞭然で良いですね！ところで、この欠けた済マークは何ですか？」
Dev「しかかり中のissueですね。UIは7割、APIは3割完了ってところです」
GitHub Projectsとの使い分け
ミクロ地獄図は、GitHub Projects を補間する目的で使います。
- ミクロ地獄図で管理すること
- プロジェクト全体の流れ
- タスク同士の依存関係
- チーム外タスクとの依存関係
- 全体的な進捗状況
- GitHub Projects で管理すること
- タスクの詳細な仕様
- 開発内での進捗状況（Sprint Backlog, In Progress, レビュー待ちなど）
その他 QA
- ガントチャートじゃダメなの？
- → ガントチャートは自由度が低く、依存関係も書きにくい
- GitHub Projects との二重管理が面倒じゃない？
- → Figma の GitHub連係 などのツールを使って手間を減らすようにしている
おわりに
ミクロ地獄図によって開発開始時のコストは少し増えますが、それを遥かに超えるリターンがあると日々感じています。
ミクロ地獄図を考え出した始祖は私ではなく、弊社のぬぬきさんです。感謝です。
他に時系列のロードマップを描き出した「マクロ地獄図」というのもありますので、機会があったらご紹介したいと思います。
