# マイルストーンの設定

## マイルストーンの設定

トラックが設定できたら、続いてマイルストーンを設定しましょう。マイルストーンも[プロジェクトゴールの設定](https://www.projectsprint.org/ja/v3.3/practices/project_goals)と同様、当該トラックの推進を担うメンバー全員で話し合いながら作っていくのが理想です。ただしこれも実際には、最初は全員で発散的に意見を出し合ったのち、誰かがその内容を取りまとめて明文化する、という流れを辿ることが多いものです。もちろん、最終的には全員が納得している状態になっている必要があります。そのため、全員が理解しやすいように、極力シンプルなものになるよう心掛けてください。

制約やイベントを意識しながら、「いつまでにどのような作成物が必要か/どういう状態になっている必要があるか」がある程度具体的にイメージできる場合には、プロジェクトゴールを見据えながらバックキャストでマイルストーンを設定していきます。具体的なイメージがまだ持ちにくい場合には、まず取り組めるところからフォアキャストでマイルストーンを設定することになります。

マイルストーンがうまく設定できないときは、トラックの設定やプロジェクトゴールを見直す必要があるかもしれませんし、マイルストーン設定の前提となるチームメンバー同士の認識合わせがまだ十分でないのかもしれません。必要に応じて、前の工程に戻って議論をしましょう。

## マイルストーンの粒度・抽象度

各トラックの自律性を保つには、トラック間が疎結合である必要があります。そのため、マイルストーンを設定する際には、相互の依存関係・影響関係を判断できるような粒度・抽象度を意識しましょう。具体的には、あるトラックのマイルストーンの達成のために別のトラックのマイルストーンを調整することができたり、他のトラックを担っているメンバーが「あのトラックのマイルストーン達成のためにはこのようなアウトプットを提供してあげたほうがいいな」と自発的に提案できたりするような記述が理想です。

マイルストーンの粒度や抽象度は、プロジェクトゴールとの距離感によってばらつきが出てもかまいません。通常、直近のマイルストーンは期日・作成物ともに具体的なものになり、プロジェクトゴールに近いものほど抽象的で大まかな記載になります。ただし、マイルストーンを見たチームメンバーがそれぞれ自分で意思決定をして行動できる程度には、具体性のあるものである必要があります。そのマイルストーンに直接関わっているメンバーが理解できることはもちろん、直接関わっていないメンバーが見たときにもそれに応じて自身で必要な行動を取れるようなものにしてください。また、プロジェクト外のステークホルダー（例えば、プロジェクトの結果を報告するべき人や、プロジェクトの結果を受けて業務に影響が出る人）が客観的に見たときに、何を作成物として作ろうとしているのかすんなり理解できるかどうかも、適切なマイルストーン設定のための一つの判断基準になるでしょう。

## 設定後の扱い

設定したマイルストーンは、チームメンバーがいつでも参照できる状態にしておきます。こうすることで、チームメンバーがプロジェクトの進行中にタスクを実行する際やチームメンバー間で議論を行う際にマイルストーンやその先のプロジェクトゴールを常に意識し、認識がずれていないかすぐに確認することができるようになります。

また、マイルストーンはプロジェクトを取り巻く環境の変化や実際にタスクを遂行する中で分かってきたことを踏まえて、プロジェクト中にいつでも変更することが可能です。ただし、変更についてプロジェクトチームで納得することが必要です。

実際の変更の流れは[プロジェクトゴールとマイルストーンの見直し](https://www.projectsprint.org/ja/v3.2/practices/reviewing_project_goals_and_milestones)で解説します。

### マイルストーンマップの利用

マイルストーンを共有し参照可能にしておくためのツールとして、「マイルストーンマップ」を利用することをおすすめします。

マイルストーンマップとは、プロジェクト内のマイルストーンの全体像を把握するためのシートのことです。あるべき姿や状態を分かりやすくシンプルに表現することで、チームメンバー全員が共通認識を持てるようになります。また、複数のマイルストーンを横断的に記載することで、マイルストーン間の関係や設定の背景を含めたより深い理解を可能にします。

マイルストーンマップには次のような要素を、ゴールまでのマイルストーン全体を俯瞰して見られるような形で盛り込みます。各要素はプロジェクトの変化に応じて常に更新し、形骸化させないことが重要です。

* ステージ名: マイルストーン達成までの期間の意味的な位置づけ（このステージで実際に何をするのかを分かりやすく記載する）
* 期日の開始日: 通常は直前のマイルストーン終了日の翌日
* 期日の終了日（必須）: マイルストーン完了の期日
* 作成物（必須）: マイルストーン完了時に出力されていなくてはならない作成物
* 達成したい状態: マイルストーン完了時点でプロジェクト内部がどのような状態になっていてほしいか、またはプロジェクトの作成物を受けてプロジェクトの外部がどのような状態になっていてほしいか、といったあるべき姿や理想の状態を記述
* 達成の基準・目標値：どうなっていればマイルストーン達成と言えるかを具体的に記述
* メモ: 補足情報を自由に記載する

### マイルストーンマップの具体的な記入要素と入力内容サンプル

例えば「ある問題を解決できる新規サービスを立ち上げる」というゴールを持ったプロジェクトがあり、このためにいくつかのマイルストーンを設定した場合、マイルストーンマップを表形式で作成すると以下のようになります。

| マイルストーン | 顧客の定義とリスト化の完了               | 必要な機能の検討完了                                   | リリースのための環境整備                             |
| ------- | --------------------------- | -------------------------------------------- | ---------------------------------------- |
| 期間      | 6/1〜6/30                    | 7/1〜8/31                                     | 9/15〜11/14                               |
| ステップ名   | 【調査】顧客の存在を確かめる              | 【企画】このサービスで問題を解決できるか確かめる                     | 【実現】市場価値があるサービスか確かめる                     |
| 作成物     | <p>・顧客定義シート<br>・顧客リスト</p>   | <p>・UXマップ<br>・サービス機能リスト<br>・顧客ヒアリング（5人分）</p> | <p>・クラウドファンディング実験結果まとめ<br>・ユーザーアンケート</p> |
| 達成したい状態 | ・顧客に今回の問題があることをメンバーが確信できている | ・問題解決のために必要な機能が把握できている                       | ・このサービスの市場価値に定量的な根拠がある                   |
| 達成の基準   | ・どこに顧客が存在するのかわかっている         | ・リリースに含めるべき最低限の機能が特定できている                    | ・次のステップとしてリリースできる機能の範囲が決まっている            |
| メモ      |                             |                                              |                                          |