# プロジェクトゴールとマイルストーンを設定する
プロジェクトゴールとマイルストーンの設定は、Project Sprintにおけるプログレスドメインにあたります。ただし、各チームメンバーが自律的に行動するためには、プロジェクトゴールやマイルストーンに納得感と達成への現実味が持てていることが重要なので、プロジェクトゴールやマイルストーンの設定とその後の見直しは、チーミングドメインにも大いに関わってくるトピックです。
## **プロジェクトゴールの設定**
プロジェクトチームが目指すのはプロジェクトゴールを達成することですから、まずはこれを定義する必要があります。そして、プロジェクトゴール達成のために必要な状態や作成物とそれを作っていくための道のり（これらをマイルストーンと呼びます）を設定します。
これからあなたが取り組むプロジェクトは、何を目指しているのでしょうか？新規事業のコンセプトを開発して、新しい価値を創出することでしょうか。それとも、システムの効率化など、決まった価値を実現するために取り組むことでしょうか。いずれにせよ、プロジェクトで目指すこと = プロジェクトゴール を明確にしましょう。
[Project Sprint 101](https://github.com/copilot-jp/project-sprint/blob/master/JA/v3.1/tutorial/broken-reference/README.md)で述べたように、Project Sprintではプロジェクトを「全体」に対する「部分」であると捉えており、プロジェクトゴールは「大きなゴール」の達成に近づくために必要な一歩としての「小さなゴール」です。従って、プロジェクトゴールは全体ゴールに対してどういう位置づけにあり、どういう役割を果たすのかを、プロジェクト内外に明確に示しておく必要があります。
### **プロジェクトゴールへの合意形成**
プロジェクトゴールは、プロジェクトチームとして合意され、チームメンバーの共通認識を得たものであることが大切です。プロジェクトチームとしてプロジェクトゴールへの合意形成を行うことで、各チームメンバーがその達成に現実味と納得感を持ってプロジェクトに参画できるのです。
プロジェクトゴールは、プロジェクトチームが主体的に0から設定することができる場合もあれば、プロジェクトの外部で設定されたものが与えられることもあります。外部から与えられたものである場合には、それをそのままプロジェクトゴールとして置くのではなく、まずはプロジェクトチームでそのプロジェクトゴールが明確で納得感のあるものかどうかを確認し、必要に応じて調整を加えます。
プロジェクトは、最初からプロジェクトゴールや目的が明確な状態で立ち上がるのではなく、緩やかな方向性が示されたり外部からプロジェクトゴールの原型を提示されたりしてスタートすることがほとんどです。チームメンバーが最初に集まった時点で、プロジェクトゴールやプロジェクトの範囲・内容が適切に共有されていることはありえません。仮に各チームメンバーが自分なりの理解をしていたとしても、他のチームメンバーとの認識の擦り合わせができていないからです。プロジェクトチーム全体としての理解や納得を得て初めて、プロジェクトゴールが設定されたと言えるのです。
### **具体的な設定方法**
プロジェクトゴールは、チームメンバー全員で話し合いながら作っていくのが理想です。ただし実際には、最初に全員で発散的に意見を出し合ったのち、誰かがその内容を取りまとめて明文化する、という流れを辿ることが多いものです。
このとき、かたちにする作業は、
* プロジェクトの背景（関連する事業計画など）
* プロジェクトで取り組む事業に関する予備知識
* 予算や期限といった制約・イベント（後述）
といった、プロジェクトを取り巻く基本的な情報について理解が深い人が行うとスムーズでしょう。その後、それがチームメンバー全員に明文化されたかたちで共有・推敲され、最終的には全員が納得している状態になるまで議論されなければいけません。
プロジェクトゴールは、後述するマイルストーンを作ることができる程度に具体的なものである必要があります。つまり、明文化されたプロジェクトゴールをもとに、具体的な作成物とそれに紐づく期限を分解してイメージできる程度に具体的なものにします。
明確なゴールを作れないときは、「ゴールを作ること」そのものをゴールとする事前プロジェクトを立ち上げ、集中的に検討することがあります。具体的な進め方は、[プロジェクトゴールやマイルストーンの設定が難しいときの始め方](https://github.com/copilot-jp/project-sprint/blob/master/ja-v3.1/tutorial/section2-1-1.md)を参照してください。
## **マイルストーンの設定**
マイルストーンとは、プロジェクトにおける特定の地点について、具体的な作成物とそれに紐づく期限をセットにして記述したもののことです。マイルストーンはプロジェクトゴールから逆算して必要な分だけ設定するものであり、複数あることがほとんどです。マイルストーンを明示化し常に意識することで、最終的な状態・作成物に向かう道筋の確からしさを確認し、現在の地点からチームが何をするべきか、またその後何を目指していくべきかを見通すことができます。
Project Sprintにおいて、プロジェクトゴールに向けての進捗は、現在のステータス(As-Is)とあるべきステータス(To-Be)の距離として捉えられます。 As-Is時点からTo-Beを描くとき、チームメンバーによってはあまり確度が高くないこともあります。
この原因は、大きく二つに分けられます。
* As-IsやTo-Beに関して、チームメンバー間で認識が揃っていないこと (**ズレの問題**)
* As-IsやTo-Beに関して、実際にタスクをリスト化し具体的に取り組んでいかなければ明らかにならない部分が多いこと (**粗さの問題**)
Project Sprintでは、プロセスでの認識合わせとマイルストーンの設定によってこれらの問題を解決します。
**▼プロジェクトゴールとマイルストーンの関係**
### **設定における注意点**
マイルストーンもプロジェクトゴール同様、チームメンバー全員で話し合いながら作っていくのが理想です。ただしこれも実際には、最初は全員で発散的に意見を出し合ったのち、誰かがその内容を取りまとめて明文化する、という流れを辿ることが多いものです。もちろん、最終的には全員が納得している状態になっている必要があります。そのため、全員が理解しやすいように、極力シンプルなものになるよう心掛けてください。
マイルストーンの粒度や抽象度は、プロジェクトゴールとの距離感によってばらつきが出てもかまいません。通常、直近のマイルストーンは期日・作成物ともに具体的なものになり、プロジェクトゴールに近いものほど抽象的で大まかな記載になります。ただし、マイルストーンを見たチームメンバーがそれぞれ自分で意思決定をして行動できる程度には、具体性のあるものである必要があります。そのマイルストーンに直接関わっているメンバーが理解できることはもちろん、直接関わっていないメンバーが見たときにもそれに応じて自身で必要な行動を取れるようなものにしてください。また、プロジェクト外のステークホルダー（例えば、プロジェクトの結果を報告するべき人や、プロジェクトの結果を受けて業務に影響が出る人）が客観的に見たときに、何を作成物として作ろうとしているのかすんなり理解できるかどうかも、適切なマイルストーン設定のための一つの判断基準になるでしょう。
マイルストーンがうまく作れないときは、プロジェクトゴールを見直す必要があるかもしれませんし、マイルストーン設定の前提となるチームメンバー同士の認識合わせがまだ十分でないのかもしれません。この際の対処方法は、[プロジェクトゴールやマイルストーンの設定が難しいときの始め方](https://github.com/copilot-jp/project-sprint/blob/master/ja-v3.1/tutorial/section2-1-1.md)を参照してください。
### **マイルストーンマップの利用**
マイルストーンは、チームメンバー全員で共有・合意される必要があります。また、プロジェクトの進行中常に意識できるよう、いつでも参照できるようにしておきましょう。
この作業を助けるためのツールとして、「マイルストーンマップ」を利用することをおすすめします。
マイルストーンマップとは、プロジェクト内のマイルストーンの全体像を把握するためのシートのことです。あるべき姿や状態を分かりやすくシンプルに表現することで、チームメンバー全員が共通認識を持てるようになります。また、複数のマイルストーンを横断的に記載することで、マイルストーン間の関係や設定の背景を含めたより深い理解を可能にします。
マイルストーンマップには次のような要素を、ゴールまでのマイルストーン全体を俯瞰して見られるような形で盛り込みます。各要素はプロジェクトの変化に応じて常に更新し、形骸化させないことが重要です。
* ステップ名: マイルストーン達成までの期間の意味的な位置づけ（このステップで実際に何をするのかを分かりやすく記載する）
* 期日の開始日: 通常は直前のマイルストーン終了日の翌日
* 期日の終了日（必須）: マイルストーン完了の期日
* 作成物（必須）: マイルストーン完了時に必要な作成物
* あるべき姿: マイルストーン完了時点でプロジェクト内部がどのような状態になっていてほしいか、またはプロジェクトの作成物を受けてプロジェクトの外部がどのような状態になっていてほしいか、を記述
* メモ: 補足情報を自由に記載する
#### **マイルストーンマップの具体的な記入要素と入力内容サンプル**
例えば「ある問題を解決できる新規サービスを立ち上げる」というゴールを持ったプロジェクトがあり、このためにいくつかのマイルストーンを設定した場合、マイルストーンマップを表形式で作成すると以下のようになります。
| マイルストーン | 顧客の定義とリスト化の完了 | 必要な機能の検討完了 | リリースのための環境整備 |
| ------- | --------------------------------------------------------- | -------------------------------------------- | ---------------------------------------- |
| 期間 | 6/1〜6/30 | 7/1〜8/31 | 9/15〜11/14 |
| ステップ名 | 【調査】顧客の存在を確かめる | 【企画】このサービスで問題を解決できるか確かめる | 【実現】市場価値があるサービスか確かめる |
| 作成物 | ・顧客定義シート
・顧客リスト
| ・UXマップ
・サービス機能リスト
・顧客ヒアリング（5人分）
| ・クラウドファンディング実験結果まとめ
・ユーザーアンケート
|
| あるべき姿 | ・顧客に今回の問題があることをメンバーが確信できている
・どこに顧客が存在するのかわかっている
| ・必要な最小限の機能が把握できている | ・次のステップとしてリリースできる機能の範囲が決まっている |
| メモ | | | |
### **トラック：プロジェクト遂行の単位**
プロジェクトゴール達成を目指す過程を、それぞれが依存関係を持たず自律的に作業を進めることができる単位にまでブレイクダウンしたものを、トラックと呼びます(トラックについて詳しくは[プロジェクト遂行の単位](https://github.com/copilot-jp/project-sprint/blob/master/ja-v3.1/tutorial/section2-1-2.md)を参照してください)。
トラック間が疎結合であることで各トラックの自律性が保たれます。そのためには、マイルストーンを設定する際に、相互の依存関係・影響関係を判断できるような粒度・抽象度が必要です。具体的には、あるトラックのマイルストーンの達成のために別のトラックのマイルストーンを調整することができたり、他のチームメンバーが「このマイルストーン達成のためにはこのようなアウトプットを提供してあげたほうがいいな」と自発的に提案できたりするような記述になるように心がけましょう。
## **制約・イベント**
プロジェクトの外部環境にあって、プロジェクトに影響を与えるためプロジェクトメンバーが意識しなければならないものを、「制約」と呼びます。特に、プロジェクトゴールやマイルストーンの設定の前提となるものを「イベント」と呼びます。なお、プロジェクトの内部にあってマイルストーンやゴールの変動をもたらすものは、プロジェクトの一部として捉え、イベントとは呼びません。
制約は、社内の稟議スケジュールや予算など、所与のものであることが多いですが、プロジェクトを取り巻くさまざまな制約のうちどれを、実際にプロジェクトに影響を与える**イベント**として採用しプロジェクトゴール設定の前提とするかをプロジェクトチームで判断する必要があることもあります。この場合にも、プロジェクトチームとして納得感のある意志決定をすることが大切です。
イベントの典型的な例は、プロジェクトの外で日々行われている、組織の定常業務です。具体的には取締役会などがこれにあたります。これ自体がプロジェクトの作成物を生み出すわけではありませんが、プロジェクトに関する何らかの報告や決済がなされるため、こうしたイベントに合わせてプロジェクトゴールやマイルストーンを設定する必要があることがあります。また、こうしたイベントからフィードバックされた情報がプロジェクトの前提条件を変え、マイルストーンや、ときにはプロジェクトゴールそのものを変える必要が生じることもあります。
単発のものや定期的なものだけでなく、「商戦期」のような期間をもったものも、イベントとして認識します。それに合わせてプロジェクトのマイルストーンを設定したり、その結果を受けてマイルストーンやゴールを調整したりする必要があるという点は、特定の日付であっても期間であっても変わらないからです。
## **設定後の扱い**
設定したゴールとマイルストーンは、チームメンバーがいつでも参照できる状態にしておきます。こうすることで、チームメンバーがプロジェクト中にタスクを実行する際やチームメンバー間で議論を行う際に、マイルストーンやその先のプロジェクトゴールへの認識がずれていないか、すぐに確認することができるようになります。
また、マイルストーンやゴールは状況に合わせて変えてもよいものだと意識してください。プロジェクトを取り巻く環境の変化や実際にタスクを遂行する中でわかってきたことを踏まえて、マイルストーンやゴールはプロジェクト中にいつでも変更することが可能です。
実際の変更の流れは[プロジェクトのゴールとマイルストーンを見直す](https://www.projectsprint.org/ja/v3.1/tutorial/section4-2)で解説します。