はじめに
プロジェクトマネジメントをしていて、自分が思った以上に負荷を感じたのが「説明」である。
タスク管理はしている。
議事録も残している。
資料も作っている。
それでも、会議や報告のたびに、毎回自分の頭の中から状況を取り出して説明している感覚があった。
例えば、次のような場面である。
- プロジェクトの目的を何度も説明する
- 現在地を毎回整理し直す
- 決定事項と未決事項が混ざる
- 会議のたびに前提確認から始まる
- Excel、PowerPoint、議事録、タスク表がバラバラに増える
- 全体像が特定の人の頭の中に寄ってしまう
もちろん、これはすべてのプロジェクトに当てはまる話ではない。
ただ、自分の場合は、資料を作っているはずなのに、説明の負荷があまり減っていない感覚があった。
そこで、仕様駆動開発の考え方を、プロジェクトマネジメントにも応用できないかと考えた。
仕様駆動開発をPMに置き換えて考える
仕様駆動開発は、ざっくり言えば「仕様を基準にして開発を進める考え方」だと理解している。
いきなり実装するのではなく、先に次のようなことを整理する。
- 何を作るのか
- 何を満たせば完成なのか
- どんな制約があるのか
- どういう振る舞いを期待するのか
この考え方をPMに置き換えると、対象はコードではなく「プロジェクトそのもの」になる。
つまり、次のような内容を仕様書として整理しておく。
- このプロジェクトは何のためにやるのか
- 何が課題なのか
- あるべき姿は何か
- 何が決定済みで、何が未決なのか
- どんな制約があるのか
- 次に何を決める必要があるのか
この記事では、便宜上このやり方を「仕様駆動プロジェクトマネジメント」と呼ぶ。
仕様駆動プロジェクトマネジメントとは
自分が考えている仕様駆動プロジェクトマネジメントとは、プロジェクトの目的・前提・課題・制約・完了条件・論点を仕様書として整理し、それを共通の起点として進行する方法である。
この仕様書をもとにAIで資料や整理表を作成することで、関係者間の認識合わせや説明にかかる負担を軽減する。
| 出力形式 | 役割 |
|---|---|
| 仕様書 | プロジェクトの正本に近いもの |
| Excel | 進捗・課題・タスクを俯瞰する管理表 |
| PowerPoint | 目的・論点・設計思想を共有する説明資料 |
| 議事録 | 決定事項・未決事項・次アクションの記録 |
| WBS | 作業分解とスケジュール管理 |
ExcelやPowerPointは、仕様書から切り出した「ビュー」として扱うイメージである。
実際の進め方
実際には、次のような流れで進めている。
メモ
↓
ChatGPTなどで仕様書化
↓
仕様書を正本に近いものとして扱う
↓
仕様書からExcel管理表を作る
↓
追加メモや論点が出る
↓
仕様書 × 追加メモ × 今回伝えたいこと
↓
PowerPoint・議事録・課題表などに変換
まず、打ち合わせメモ、作業メモ、気づき、課題、決定事項などをまとめる。
それらをそのまま管理表や資料にするのではなく、一度ChatGPTなどに読み込ませて、プロジェクト仕様書として整理する。
仕様書には、例えば次のような内容を入れる。
- プロジェクトの目的
- 背景
- 現在の状況
- 決定事項
- 未決事項
- 論点
- 追加タスク
- 制約条件
- 次に確認したいこと
メモを単なる記録で終わらせるのではなく、プロジェクト全体を説明しやすい形に変換する。
仕様書からExcel管理表を作る
次に、仕様書をもとにExcel形式のプロジェクト管理表を作る。
自分の場合は、Excel帳票を出力するための自作GPTsを使っている。
※以前書いた記事(https://qiita.com/makotodaxi5/items/6ad9f4b3adcc689a52c0 )のプロンプトをそのままGPTsにした。
Claudeなどでも似たことはできるが、個人的には自作GPTsの方が安定して良い結果が出やすかった。
おそらく、出力形式や列構成、見たい観点をあらかじめ固定しているからだと思う。
例えば、仕様書から次のような項目に変換する。
- タスク
- 説明
- 担当
- 期限
- 優先度
- ステータス
- 関連する論点
- リスク
- 次アクション
毎回ゼロから「いい感じの管理表」を作るのではなく、仕様書を決まった型に変換する。
この方が、自分の場合は扱いやすかった。
追加情報が出たら仕様書に戻す
プロジェクトが進むと、新しい論点、追加タスク、説明すべき内容が出てくる。
そのとき、いきなりPowerPointやExcelを直接更新するのではなく、基本的には次の形でアウトプットを作るようにしている。
仕様書 × 追加メモ × 今回伝えたいこと
関係者に説明したい場合はPowerPointにする。
進捗を見せたい場合はExcelに反映する。
会議の整理をしたい場合は議事録や確認事項リストにする。
追加情報が出るたびに、仕様書を中心にしてアウトプットを更新する。
こうすると、Excel、PowerPoint、議事録、課題表が完全にバラバラな資料として増えていくのではなく、同じ仕様書から派生した資料として扱いやすくなる。
このやり方で変わったこと
自分の中で一番大きかったのは、毎回ゼロから説明しなくてよくなったことだ。
プロジェクトの目的、背景、現在地、未決事項を、その場で毎回組み立てて説明するのは負担が大きい。
しかし、仕様書を中心に置いておくと、用途に応じて必要な形に切り出しやすくなる。
- 進捗を見せたいならExcel
- 背景や設計思想を伝えたいならPowerPoint
- 決定事項を確認したいなら議事録
- 作業分解を見せたいならWBS
すべてを口頭で説明するのではなく、資料が説明を補助してくれる状態に近づく。
また、仕様書を見れば、目的、課題、あるべき姿、スケジュール、論点をまとめて確認しやすい。
タスク単位だけでなく、プロジェクト全体を俯瞰しやすくなる。
会議でも、前提確認に時間を使うより、次のような論点に集中しやすくなった。
- 今日は何を決めるのか
- 何が判断待ちなのか
- どこが詰まっているのか
仕様書を中心に置くことで、説明、確認、判断の起点をそろえやすくなる。
まとめ
仕様駆動開発では、仕様を基準にして実装を進める。
これをプロジェクトマネジメントに応用すると、プロジェクト仕様書を基準にして、進捗管理、課題管理、認識合わせ、会議資料作成を円滑に進める形に近づけられた。