2021-10-31 仕事でプロジェクトを任せられたときの私の計画方法
仕事でプロジェクトを任せられたときに私が実施している計画方法です。
プロジェクトというと規模が曖昧ですが、システムを開発して納品する案件ひとつとかを想定しています。大体 1, 2ヶ月で終わるようなボリューム感です。
流れ
- ゴールを確認する
- 期日を確認する
- 成果物を確認する
- 成果物の作成に必要なプロセスを洗い出す
- テスト仕様書を作成する
- プロセスをタスクに分割する
- 時間にタスクを割り当てる
- 計画に沿って実施する
ゴールを確認する
ゴールを確認します。
納品案件であれば、「〇〇システムを納品する」などと書きます。
製品の開発であれば、「バージョン〇〇をリリースする」「〇〇機能を実装する」などと記載します。
期日を確認する
いつまでに実施しないといけないのかを確認します。
成果物を確認する
何を満たさなければいけないのかを網羅的に書きます。
納品案件であれば、
- テスト仕様書を実施し、全て OK となったシステム
- 操作マニュアル
- アプリケーション仕様書
などと網羅的に書き出します。
これを行うのは、後から「マニュアル必要なの忘れてた！」となってスケジュールに大きな遅れが出ることを防ぐためです。
成果物の作成に必要なプロセスを洗い出す
成果物の作成に必要なプロセスを洗い出します。
- テスト済みアプリケーション
- テスト仕様書の作成
- 実装
- テストの実施
- レビューを受ける
- パッケージング
- 本番環境
- 〇〇に依頼する
- 操作マニュアル
- 作成
- レビューを受ける
などです。
テスト仕様書を作成する
スケジューリングを行う前に、テスト仕様書を作成します。
スケジューリングより先にこれを行うのは、アプリケーションの仕様を網羅的に洗い出すためです。特にエラー処理を洗い出すのに役立ちます。
また、テスト実施にかかる時間も見積もりやすくなります。
プロセスをタスクに分割する
「成果物を作成するためのプロセスを洗い出す」過程で洗い出したプロセスを、見積もることのできる単位に分割していきます。タスクと呼んでいます。
時間にタスクを割り当てる
時間にタスクを割り当てていきます。
Google カレンダーに時間を割り当てていきます。
プライベートでもやっているんですが、今日であればこんな感じです。
実際にはこんなに細かくスケジュールすることは少なく、半日単位でタスクを割り当てることが多いです。
計画に沿って実施する
計画が済んだら、計画に沿って実施していきます。
振り返りを行う
定期的に振り返りを行います。見積もりと実際にずれが生じている場合、見積もり時の想定と異なる状況になっているということなので、そのズレを認識して次に活かします。
遅れについては、以下のブログの考え方を取り入れています。
終わりに
以上、現状の計画方法でした。
まだまだ洗練させる余地はあると思います。繰り返し適用して、振り返りを行うことによってこの方法もより洗練させていければいいなと考えています。
