# TOP
このページは、2024年1月をもって更新を停止しています。\
最新版の Project Sprint は [こちら](https://github.com/ProjectSprintOrg/projectsprint.org) (GitHub) をご覧ください。（2025.2.27）
### Project Sprint とは
Project Sprint は、定例会議を活用したプロジェクト推進のためのフレームワークです。本ドキュメントは、Project Sprint をオープンソースのメソッドとして公開しているものです。
Project Sprint 及び本ドキュメントは、2020年のリリース以降大小さまざまなアップデートを繰り返し、今現在も進化し続けています。
### こんな方におすすめ
Project Sprint は、「チームがプロジェクトを規定する」という価値観に基づいて構築されています。もしあなたが、従来の価値観によるプロジェクトの固定的な枠組みの中で何らかの不自由さを感じているのなら、Project Sprint はあなたをそこから解放する手助けができるかもしれません。
* チームが主体として自由にプロジェクトを規定しつづけられるという価値観に共感する
* 従来の予測型のプロジェクトにおける管理的・中央集権的なアプローチがうまくいっていない
* 今までの自分のプロジェクトの進め方に迷いがあり、もっとよいやり方がないだろうかと悩んでいる
そんな方はぜひ一度、Project Sprint がご案内する適応型のプロジェクトの世界へ飛び込んでみませんか？
※Project Sprint におけるプロジェクトの捉え方について、さらに詳しくは[こちら](/ja/v4.3/definitions)をご覧ください。
### はじめての方へ
本ドキュメントは、個々のプロジェクトチームの自律性や創造性の発揮を支援するための本質的な概念や価値観に重点を置きたいとの思いで記述されています。v4の公開に当たって、フレームワークとしての強度を高めることと文書管理をしやすくすることを目的として、v3までは本ドキュメントに含まれていた各概念の詳細な説明や実践の際の指針を、本ドキュメントから分離しました。
Frameworkの記述内容は抽象度が高く、厳密さを重視しているので、はじめての方にとっては少しとっつきにくいと感じられることもあるかと思います。理解を助けるため、必要に応じて過去バージョンを参照し、実践する際の具体的な行動をイメージしながらお読みいただければと思います。
1. Project Sprint からの提案の概要や、その基盤となる価値観を把握する\
☞ [Introduction](/ja/v4.2/introduction)
2. Project Sprint におけるプロジェクト観と用語の定義を理解する\
☞ [Definitions](/ja/v4.3/definitions)
3. Project Sprint の核となる概念や価値観に触れる\
☞ [Framework](/ja/v4.3/framework)
4. 過去版を参照し、各概念の詳細や実践の際の指針を把握する\
☞ [Theories](/ja/v3.3/theories) and [Practices](/ja/v3.3/practices) (v3.3.3)
5. Frameworkを再読し、内容をより深く理解する\
☞ [Framework](/ja/v4.3/framework) (再読)
### フィードバックを歓迎します！
Project Sprint は、プロジェクトの現場で得られた実践知のフィードバックを受けることにより、アップデートを繰り返してきました。
* 不確実で変化の多いプロジェクトが増える中、プロジェクトに関わる人の苦悩を少しでも減らしたい
* プロジェクトに関わるすべての人が、プロジェクトで自分の能力を最大限活かせるようしたい
メンテナーはそんな思いで、今現在もProject Sprint を進化させるべく、試行錯誤を繰り返しています。
プロジェクトに関わる方それぞれがご自身の実践知をフィードバックしてくださることで、Project Sprint はより使いやすく、多くの人にとって価値のあるものになってゆくでしょう。
どのようなかたちや内容であれ、このメソッドに関心やご意見、共感をお寄せいただけることを嬉しく思います。また、Project Sprintの発展に貢献したいと考えてくださる方も歓迎します。
**＜フィードバックの方法＞**
[こちら](https://github.com/ProjectSprintOrg/projectsprint.org/wiki/Question-and-Suggestion)をご参照ください。
# Project Sprint (Ja)
## Version 4
* [v4.3](/ja/v4.3)
* [v4.2](/ja/v4.2)
* [v4.1](/ja/v4.1)
* [v4.0](/ja/v4.0)
v4では、Project Sprint がこれまでも重視してきた「作成物を生む」という行為により重点を置き、プロジェクトを「出力」と「成果」の関係から捉えなおしました。このことにより、以下のような効果を期待しています。
* 作成物を小さく確実に生み出し続けることを重視することで、プロジェクトの推進と最適化がよりスムーズに行えるようになる
* 出力を成果との1対1の対応関係から解き放ち、より幅広く価値を生み出すことができるようにする
* 予測型・適応型両方のプロジェクトに対応できるようになる
* プロジェクトをよりチームメンバー全員のものとして捉えることができるようになる
## Version 3
* [v3.3](/ja/v3.3)
* [v3.2](/ja/v3.2)
* [v3.1](/ja/v3.1)
* [v3.0](/ja/v3.0)
## Version 2
* [v2.2](/ja/v2.2)
# v4.3
## コンテンツ
* [**Introduction**](/ja/v4.2/introduction) はじめにお読みいただきたい文書です。Project Sprint からの提案の概要を紹介した上で、その基盤となっている価値観を簡単に紹介します。
* [**Definitions**](/ja/v4.3/definitions) Project Sprint を理解するための前提を示す文書です。Project Sprint におけるプロジェクト観を説明し、その他の用語を定義します。
* [**Framework**](/ja/v4.3/framework) Project Sprint の核となる概念や価値観を示す文書です。Project Sprint におけるプロジェクト推進の構造と、そのための価値観や推奨される振る舞いが記述されています。
## 関連情報
* [**Practical Guide**](https://miro.com/app/board/uXjVMX-zl6s=/) Project Sprint のフレームワークを実際のプロジェクトに導入し使いこなすためのガイドブックです。諸概念を図解し、分かりやすく説明しています。
★Project Sprint の内容に疑問やご意見を持たれた方は、[こちら](https://github.com/copilot-jp/project-sprint/discussions)のGitHub Discussionへお寄せください。
# Introduction
Project Sprint は、プロジェクトチーム自らがプロジェクトの主体となり、小さな成果を繰り返し確実に生み出すことを通じて、環境の変化を捉えつづけながら自律的にプロジェクトを推進するためのフレームワークです。
この Introduction では、 Project Sprint がどういった意図で構築され、どういったチームやプロジェクトに適したフレームワークなのかを解説します。また、Project Sprint をどのような性質のものとして捉え、どのようなスタンスで臨んでいただくとよいかをご案内します。
1. Project Sprint を提案する時代的背景
2. Project Sprint が目指す状態
3. Project Sprint における「プロジェクト」
4. Project Sprint のスタンス
5. Project Sprint のフレームワーク
## 1. Project Sprint を提案する時代的背景
プロジェクトの推進に関しては、これまでも多くの知見が蓄えられ、活用されてきました。しかし、近年の社会ではプロジェクトを取り巻く環境は目まぐるしく変化しており、それに伴って状況が刻一刻と変わる、予測の難しいプロジェクトが増えています。
Project Sprint は、プロジェクトチームがこうしたプロジェクトに対応できるようにするためのフレームワークとして考案されました。
環境の変化の少ない時代においては、当初の条件を不変のものとしてプロジェクトを定義したり計画したりすることができ、最終的に達成したいゴールから単純に逆算して計画的に成果を積み重ねていくことができました。
しかし環境の変化が激しく不確実性の高い現代においては、プロジェクトを取り巻く状況は刻一刻と変わっていきます。すべての活動は取り組んでみないと誰にも把握できないものであり、当初の条件や見通しは当然に変化するものであると捉えなくては、プロジェクトの本質的な成功に近づくことができません。
そのため、プロジェクトを小さな実験の繰り返しと捉え、プロジェクト内外で起きる変化やステークホルダーの要求に応じて、真に実現すべきゴールとそこまでの道筋を短いサイクルでアップデートしつづけていくことが求められます。
こういったプロジェクトでは、プロジェクトチームが自律的に活動できる必要があります。多様なメンバーが、それぞれの専門性と状況に応じて行動を自己決定・実行し、チームで素早く検証するというサイクルを繰り返すのです。
## 2. Project Sprint が目指す状態
上で述べたような要求に応えるために、Project Sprint が目指すのは、以下のような状態です。
* プロジェクトチームが、さまざまな変化に応じて自律的に行動できる
* プロジェクトチームにおいて、プロジェクトを推進するための行動が習慣化されている
前者の目的は変化を素早くキャッチして対応することであり、後者の目的は小さなサイクルで実験と検証を繰り返すことです。
この2つの状態を維持し改善しつづけることができる仕組みとして利用されるのが、定例会議です。
## 3. Project Sprint における「プロジェクト」
プロジェクトは、社会に変化をもたらすためにチームが自発的に行う活動です。
具体的には、次のような特徴をもつ活動が「プロジェクト」であるとProject Sprint では考えています。
* 短く期間を区切った探索的な活動が、反復継続される
* チームに環境の変化を捉えつづける意思がある
とはいえ、これは必要最低限の要素であり、個別具体的な活動がこの特徴にあてはまるかどうかや、 Project Sprint のフレームワークを導入するのに適しているかどうかは、なかなか判断が難しいものです。
判断を助けるために、Project Sprint におけるプロジェクトの捉え方と相反する活動を以下に挙げておきます。こういった活動は、Project Sprint のフレームワークよりも適した進め方が他に存在したり、Project Sprint のフレームワークを取り入れることが構造上困難であったりするものと言えます。
* 環境の変化を考慮しなくてよい活動
* 3か月で完全に終了しチームが解散してしまうなど、活動自体が短期間で終了し非連続的である
* 成果物やゴールまでの過程が詳細に決まっているなど、不確実性が高くなく全体を計画することができる
* 環境の変化に即して行動できない活動
* チームに決定権がなく承認プロセスに時間がかかるなど、素早い意思決定ができない
* チームに環境の変化を捉えつづけようとする意思がない
## 4. Project Sprint のスタンス
Project Sprint は、[「Adopt & Adapt (採用と適応)」](#user-content-fn-1)[^1]のスタンスで構築されています。
Project Sprint は、多様なプロジェクトに汎用的に適用することが可能です。しかし、 Project Sprint を自分たちのプロジェクトのフレームワークとして採用するかどうか、さらにどの部分をどういった形で採用するかは、個々のプロジェクトチームの意思に委ねられています。重要なのは、プロジェクトチームがどのような価値観に拠ってプロジェクトに取り組みたいかです。
以下のような価値観に共感を覚えるプロジェクトチームは、 Project Sprint との親和性が高く、 Project Sprint のフレームワークによる効果が上がりやすいでしょう。逆に、この価値観への共感が難しい場合、Project Sprint からの提案がプロジェクトチームに混乱を生じさせてしまう可能性があります。
* 所与の条件にとらわれず、チームの自己決定を重視する
* 予測型か適応型かにとらわれず、状況に応じて柔軟に使い分ける
* 最初に決めた目標の達成にとらわれず、小さな実験を日々繰り返し成果と改善を積み重ねる
こういった価値観を反映し、 Project Sprint においてプロジェクトをどのようなものとして捉えるとよいかは、 [Definitions](/ja/v4.1/definitions) に改めて詳しく記述しています。
また、 Project Sprint はあくまで実践知を一般化したフレームワークなので、個々のプロジェクトとその置かれた状況に適応するようにテーラリングした上で導入する必要があります。
自分たちがどのようなプロジェクトチームでありたいか、そして自分たちのプロジェクトの実情に最適なのはなにかを、まずは考えてみてください。その上で、 Project Sprint が提案する価値観が、より多くのプロジェクトを自由で創造的なものにすることを願っています。
## 5. Project Sprint のフレームワーク
Project Sprint は、実践知を集めて体系化することによってかたちづくられたフレームワークです。
堅牢な理論に立脚して構築された揺るぎないものではなく、プロジェクトの現場から日々新たな実践知を取り込みながら更新が続けられており、大きな進化の可能性も秘められています。
現在の Project Sprint の中でももっとも本質的な価値と言える内容を、 [Framework](/ja/v4.1/framework) にまとめています。Project Sprint の根幹をなすものとしての厳密さを重視しているため、具体的な実践内容やその手順というより、プロジェクト推進の構造やそのための価値観といった、抽象度の高い内容が記述されています。 Project Sprint における各概念の捉え方・考え方や、プロジェクトにおいて推奨される振る舞いを読み取っていただければと思います。
[^1]: [ITIL](https://en.wikipedia.org/wiki/ITIL)の精神に共感し、そのまま採用しています。
# Definitions
Project Sprint は、プロジェクトチーム自らがプロジェクトの主体となり、小さな成果を繰り返し確実に生み出すことを通じて、環境の変化を捉えつづけながら自律的にプロジェクトを推進するためのフレームワークです。
この Definitions では、Project Sprint を理解するための前提として読者の皆さんと共有したい、Project Sprint の世界観を説明し、その他の用語を定義します。
## 1. Project Sprint の世界観
**i) プロジェクトチームの意思にもっとも重きを置く**
Project Sprint は、プロジェクトチームがプロジェクトの中心であり、プロジェクトチームの意思がプロジェクトにおけるあらゆる事柄を決定するという世界観に立ちます。この世界観の下では、プロジェクトチームはプロジェクト内外の変化を自らの意思に基づいて解釈し、それに応じて自律的に行動することができます。
プロジェクトチームは、プロジェクトにおける唯一の決定権者かつ実行主体として自らの意思に基づいてプロジェクトを定義し、その後も状況の変化に応じてプロジェクトの再定義を繰り返しながらプロジェクトを推進していきます
プロジェクトゴールを変更の余地のない所与の条件と捉え、それに規定された「プロジェクト」を活動の固定的な枠組みとして受け入れることもできます。しかしそういった場合、プロジェクトチームはあくまで、与えられた定義や枠組みに従ってプロジェクト達成の条件を満たすために活動する、プロジェクトの構成要素のひとつでしかありません。そのため、プロジェクトメンバーという生身の人間がプロジェクト推進の最前線で活動しつづける中で感じる違和感や閃き、そしてプロジェクトチームの個性は、プロジェクトの枠組みや推進過程に十分に反映されず、プロジェクトチームの行動に不自由さが生じることがありました。
Project Sprint におけるプロジェクトチームは、所与の条件にそのまま従う参加者ではなく、プロジェクトを取り巻く状況を意思を持って解釈し納得した上でプロジェクトを定義する主体でなくてはなりません。そのことにより、プロジェクトチームはプロジェクトの実行主体として、プロジェクトを構想し定義しつづけていく責任とプロジェクト外部の環境の変化を捉えつづけていく責任、さらに外部のステークホルダーと自ら調整を行っていく責任を負うことになります。それはときに、プロジェクトチームにとって大きな挑戦になるかもしれません。
しかし、この考え方により、プロジェクトチームは固定的な枠組みに押し込められることなく、自らの意思で自由にプロジェクトを定義し、環境の変化を素早く捉えながら自律的にプロジェクトを推進することができるようになります。
**ii) 状況に応じて最適なアプローチを自由に決定する**
Project Sprint は、どのようなアプローチでプロジェクトを進めるかをその時々の状況に応じて自由に決定できるという世界観に立ちます。この世界観の下では、プロジェクトチームは状況の変化をキャッチすることにどの程度能動的でいるかを自らの意思に基づいて決定し、それに応じて最適な進め方を取ることができます。
プロジェクト進行のアプローチには、大きく分けて予測型（ウォーターフォール）と適応型（アジャイル）の二つがあります。
予測型は、変化の少ない環境を前提とし、予め設定した最終ゴールを目指してロードマップを組み立て、それに従ってプロジェクトを進めるというアプローチです。予測型で進められるプロジェクトは図1-1のように、プロジェクトの大枠が固定されており、達成すべきゴールはプロジェクト開始時点から明確です。プロジェクトチームはそれらの要求に応じた計画を立て、ゴールに向かって順を追って成果を積み上げていきます。
一方適応型は、環境は変化するものだということを前提とし、その変化を捉えて能動的に最終ゴールとロードマップを変化させながら進んでいくというアプローチを取ります。適応型で進められるプロジェクトは図2-2のように、不確実性と変動性が高く、プロジェクト開始時点では最終ゴールすらも曖昧模糊としたものであることもありますが、反復的・漸進的な取り組みの中で、先々のゴールやロードマップは自ずと詳細化・明確化されてゆきます。
個々のプロジェクトについて、予測型なら予測型、適応型なら適応型で進めるものと捉えることもできます。しかし、ひとつのプロジェクトの中でも、工程が予め明確になっており予測型で計画的に進めることができる部分と、未知の部分が多く適応型で柔軟に進めたほうがよい部分が混在することが多いものです。また、予測型と適応型はそもそも二項対立で切り分けられるものではなく、予測型と適応型の間には変化に対してどの程度能動的であるかにおいて無数のパターンがグラデーション状に存在します。
そのため Project Sprint は、プロジェクトへのアプローチを固定する必要はなく、状況に応じて適切なアプローチを柔軟に選択すればよいというハイブリッド型の考え方を取ります。
この考え方により、プロジェクトチームは、ロードマップの詳細さや厳密さに強弱をつけながら、効率的にプロジェクトを推進することができるようになります。
**iii) 探索的な小さな実験の繰り返しとしてプロジェクトを進める**
Project Sprint は、プロジェクトを探索的な小さな実験と検証の繰り返しと捉えるという世界観に立ちます。この世界観の下では、プロジェクトチームは将来にわたる計画を立てることに必要以上に囚われず、目の前の具体的な課題に取り組んで小さくとも確実にプロジェクトを推進することができます。
プロジェクトは、全体を一気に定義したり計画したりするものではなく、小さなサイクルの繰り返しであると捉えられます。最終的に達成すべき成果のために必要な要素を小さな成果に分割し、分割したひとつひとつの成果に対して仮説を立てて実行した上で、その検証をもとに以降のフェーズの軌道修正を行います。こうして反復的かつ漸進的にプロジェクトを進めていくのです。
プロジェクトにおける最終的な成果の達成までの一連の流れを、できるだけ失敗や手戻りが生じないように計画的に推進していこうと考えることもできます。しかし、計画を綿密に立ててもその後大幅に修正が必要になったり、プロジェクト全体を同じ精度で捉えつづけようとすることでメンバーの認知負荷が高くなりすぎたりすることもあります。
そのためProject Sprint では、仮説の設定とその仮説に沿った行動を、短いタイムスパンで小さく実験的に繰り返すという進め方を取ります。
個々の実験において重要なのは実験結果を振り返って次のフェーズに生かすことであって、仮説が正しかったかどうかはさほど重要なことではありません。「正しい仮説を立てる」ことにこだわって行動の速度が鈍ったり保守的になったりするよりは、「取り組んでみることで見えてくるものもある」と捉えて前向きに挑戦し、得られた結果を次のフェーズの改善材料にしていくのです。また、仮説が間違っていたとしても、実験の結果がプロジェクト全体の成功につながる成果を実現することもあります。ただし、行動を起こしやすく軌道修正を容易にするため、個々の実験のサイズは小さければ小さいほどよいということに留意する必要があります。
このようにプロジェクトを進めることで、プロジェクトチームは、創造性豊かに小さな挑戦を重ね、仮説を検証して小さく軌道修正を繰り返すことで、複雑な問題を素早く解決して最終的な成果に向けてプロジェクトを推進していくことができます。
## 2. 用語集
このセクションの用語は、Project Sprint の前提を理解し、Framework の記述をスムーズに読み進めるために定義したものです。
図3は、用語の全体像をおおまかに示したものです。個々の用語の詳細や相互の関係については、[Framework](/ja/v4.3/framework) などで別途記述されます。
* **チーム** 共通の目的をもってプロジェクト内の会議体に参加し、目的に向かって出力を行うメンバーの集まり。
* **プロジェクトチーム** プロジェクトの目的に対する共通了解をもち、プロジェクトの達成に向けて自律的に協働するメンバーの集まり。チームの一種だが、例外的に、全メンバーが参加する会議体を持たない場合や、出力を行わないアドバイザー的な立ち位置のメンバーを持つ場合がある。
* **プロジェクト** プロジェクトチームが、プロジェクト外部の社会に何らかの変化や価値を提供するために、自発的に行う活動。
* **活動** チームや個人が、意思や目的をもって、何ごとかをある状態から別の状態に変化させるために、何らかの出力を伴う身体的な行動をすること。
* **フェーズ** チームがある目的をもって活動する期間。
* **プロジェクトストーリー** プロジェクトチームが次の行動を決定するための指針として、目的達成までの過程をシンプルに時系列で表現したもの。各チームのフラッグが集まることで表現される。
* **フラッグ** チームが、外部からの制約や実現したい価値・成果を踏まえ、ある目的をもって設定した到達点。以下の要素を持つ。
* **成果** チームが、プロジェクトにおいて実現を目指す価値を踏まえ、プロジェクト内の他チームやプロジェクト全体に向けて生み出す所産。
* **価値** プロジェクト外部のステークホルダーが、プロジェクトが実行された結果として受け取る便益。便益の有無や軽重の評価はステークホルダーの認識に委ねられるので、プロジェクトチームが創出を目指す価値はあくまで仮説である。
* **ゴール** フラッグのチームがある期日において達成していたい状態。要素として、あるべき状態・成果物・完了日の3つをもつ。
* **あるべき状態** その状態に至ることで成果を達成したと判断できる、状態や定性的な捉え方。
* **成果物** 出力・作成されることで成果を達成したと判断できる、有形的なものや定量的な値。
* **理由** プロジェクトの成立や推進に関して、過去に存在する背景や経緯。
* **目的** プロジェクトにおいて達成したい事柄に関するプロジェクトチームの意思。
* **制約** プロジェクトの外部環境にありプロジェクトチームの意思で調整することができない、プロジェクトチームの行動に制限を与える事柄。または、プロジェクトチームがステークホルダーから必ず達成することを期待されている事柄。
* **イベント** プロジェクトチームの行動が制限される出来事や期日。
* **出力** チームメンバーが作成物を産出すること。
* **作成物** チームメンバーによって生み出され、チームに対して共有されて他のチームメンバーが意見を述べたり助言をしたりといったリアクションを取ることが可能な、かたちあるもの。
* **実験** 行動を起こしやすく軌道修正を容易にするため、相対的に小さな規模で行われて次の行動の改善材料となる、作成物の産出を伴う成果の仮説構築・実行・検証のサイクル。
* **定例会議** チームが、短期的・定期的なサイクルで反復的に実施する対話の場。各メンバーが自身の次の行動を自己決定できる状態を目指して他のメンバーと同期し対話を行い、共通了解の形成、問題の共同解決、アイデアの共同創造、意思決定などを行う。
# Framework
## 1. Project Sprint は何を可能にするか
Project Sprint は、定例会議を活用して行動を習慣化することでプロジェクトを推進するフレームワークである。
変化の激しい環境の中で複雑なプロジェクトを推進し、よりよい成果をもたらすには、多様なメンバーが自律的に活動できなくてはならない。そのためには、個々のメンバーの活動を可能な限り疎結合にし、各自が行動を自己決定できるようにする必要がある。
定例会議を活用することで、各メンバーの行動の前提となるチームとしての共通了解を形成しつづけることができる。また、定例会議によって生み出されるリズムは、プロジェクトを推進したり見直したりするチームの行動を習慣化することができる。
## 2. Project Sprint が理想とする状態
プロジェクトの推進は、個々のチームメンバーがプロジェクトの目的にかなうと信じる作成物を出力しつづけることから生まれる。そのため Project Sprint では、「チームメンバーの自律的な活動により、プロジェクトの目的達成を目指した作成物が出力されつづけている状態」を、プロジェクトチームの理想的な状態と定義する。
環境の変化に合わせてプロジェクトを変化させながら小さな実験を繰り返し、目的に沿った作成物を生み出しつづけるために、Project Sprint のフレームワークは構築されている。
## 3. プロジェクト推進の構造
### 3.1 出力と対話の反復
プロジェクトは、出力と対話の反復によって推進される。出力とは、各メンバーが自律的に活動して作成物を生み出すことである。対話とは、チームで集まって状況を把握し、各々が次の出力に向かうことができるようにすることである。
* **出力：各メンバーの活動** :
1. 各メンバーが、納得をもって自律的に行動を起こす
2. 身体的な行動で具体的な作成物を出力し、その過程で多様な気づきを得る
3. 作成物自体やその出力に伴って得られた気づきを材料に、次の対話に向けて準備をする
* **対話：チームでの活動** :
1. 各メンバーが、タスクの実践を通して出力された作成物と得られた気づきをチームに共有する
2. チームとして環境を固定して現状認識を共有した上で、アイデアの共同創造や問題の共同解決を行い、プロジェクトの方向性に対する共通了解を形成する
3. チームの共通了解を前提として、各メンバーが次の対話までにどう行動すべきかを自覚し納得できるようにする
この出力と対話の反復をスムーズにするために、以下の3つの仕組みがある。
### 3.2 仕組み① 定例会議でパターンとリズムをつくる
Project Sprint の軸となるのは、上で述べた対話をプロジェクトのタイムラインに定期的に出現させること、つまり**定例会議**を設定することである。短い一定のタイムスパンで、同一のプロセスでの処理を繰り返すことで、各メンバーが自律的に行動できる環境と習慣をつくりだせる。
定例会議は、以下の3つの条件を満たしている必要がある。
* 短期的: プロジェクト全体のスケジュール感から見て相対的に短期であること
* 定期的: 人間の既存の習慣に沿った一定の期間が置かれること（日次、週次、隔週等）
* 反復的: 一定の型が存在すること（進行方法、アジェンダの種類や形式等）
定例会議を置き、決められたタイムスパンの中で反復的に行動することで、プロジェクトに一定のリズムが生まれる。そのことには、以下のようなメリットがある。
* 生産性が向上する（作成物生成の期日が明確化される）
* 計画しやすくなる（過去の実績を判断材料にすることで、タスクの粒度を揃えたり作業計画を立てたりしやすくなる）
* 分析して改善しやすくなる（行動が習慣化される）
Project Sprint における定例会議の仕組みは、各メンバーの習慣的行動を導くものであり、各メンバーに習慣的行動が根付くことにより、チームや組織に変革がもたらされる。習慣化された行動により作成物が定期的・反復的に生み出されつづけ、それがプロジェクトを推進したり見直したりする材料となる。
また、会議の進行方法やアジェンダの型を決め、それに沿って定期的に対話することにより、以下のようなメリットが生まれる。
* チームが納得した意思決定をしやすくなる（全員の環境を一時的に固定して認識を揃える）
* プロジェクトを観測しやすくなる（定点観測で状況を理解しやすくなる）
* 分析して改善しやすくなる（反復するたびに効率が良くなる）
### 3.3 仕組み② プロジェクトストーリーとロールの共通了解をつくる
プロジェクトにおける**共通了解**とは、対話や議論を通してチーム内で形成され共有されている認識のことを指す。ものごとの認識の仕方はメンバーごとに異なり、まったく同じ認識を共有できるわけではないという大前提に立ちながらも、各メンバーがプロジェクトをどのように認識しているかを定期的に確認し、チームとして目指すところを常に調整しつづけることで、統合的な行動が取れるようになる。
出力と対話のサイクルが回っていたとしても、チーム内で環境の認識にずれが生じていれば、各メンバーの行動はそのプロジェクトに相応しくないものになってしまう可能性がある。そうならないように、以下のような事柄については共通了解を形成しておく必要がある。
* プロジェクトストーリー（プロジェクトチームが何を目指しているかの認識を揃えることで、統合的な行動が取れる）
* チームメンバーの役割・期待（チームの中で自分が何をすべきかを納得することで、自信を持って行動できる）
これらをチームの納得に基づいて設定し共有しておくことは、共通の目的に向かってチームが自律的に行動しつづけるために非常に重要である。
### 3.4 仕組み③ 多様な観点から見直しを行う
チームメンバー全員の目線を使って、プロジェクトをよりよい状態にするべく定期的・継続的に見直し改善しつづけるための仕組みとして、**継続的改善アプローチ**を用いる。
定例会議と活動のサイクルが回ることでプロジェクトは常に調整されているが、必ずしもすべての改善点が洗い出されているわけではない。また、これまでに述べた2つの仕組み自体を改善していく必要もある。フェーズの開始・終了時や大きな変更があったときなどプロジェクトの成果で区切って改善を行うだけでなく、月次・週次等定期的に見直しを行うことが重要である。
継続的改善アプローチの代表的なアクションとしては「定期的に過去の振り返りを実施してアイデアや問題をチームのものとして顕在化し、プロジェクトをよりよい状態にするための改善策を検討する」ということになるが、「過去」だけではなく「現在」にも目を向けることが重要だ。各メンバーが今現在感じている違和感や閃きを、リアルタイムでアイデアや問題に昇華して共有することが、チームの状況を改善するために不可欠だからである。
「過去」を見る振り返りだけを実施する場合、問題が共有されるのはその問題が起こってしまった後である可能性が高いが、「現在」を見ることで、問題が顕在化もしくは拡大する前に共有し対処することができるようになる。また、もやもやを解消できる場があることで、メンバーのプロジェクトへの参加意欲の向上にも繋がる。そのため Project Sprintでは、定例会議の中での違和感や閃きの共有という形で、定期的に現在の心境を出し合うことを推奨している。
### 3.5 すべては作成物の出力から始まる
出力と対話の反復において重要なのは、**チームメンバーがタスクを実践して作成物を出力する**ことである。
作成物は、個人として実践した各メンバーの活動を、チームとして遂行するプロジェクトに統合する際の媒介となる。言語だけの対話では認識が揃いにくい場合も、具体的に目に見える作成物が対話の場に持ち込まれることで問題意識や課題が共有され、共通了解が形成されやすくなる。出力と対話のサイクルで、個人の活動の結果が他のメンバーの認識を小さく変容させることを繰り返して、プロジェクトチームとしての共通了解が揃ってゆく。
プロジェクトの前進につながる作成物が出力されること自体も重要ではある。しかし、より重要なのは、各メンバーがタスクの実践という具体的な行動を通して、プロジェクトや環境の情報、多様な視点からのひらめきや違和感を得て、それらの気づきをチームに共有することである。こうした気づきがチームに供給されつづけることで、個人の気づきからチームとしての新たなタスクを生み、次の出力につなげるという流れを作り出すことができる。
対話は、個人の活動の範囲内では個人のものでしかなかった作成物や気づきを、チームに共有することでチームのものにするプロセスでもある。個人の出力による作成物や気づきは、チームのもの、ひいてはプロジェクトのものになることによって成果や価値、プロジェクトの見直しにつながっていく。
また、対話は、出力に事後的な意味付けを行うという意味でも重要である。各メンバーが自身の行動の意味を前もって正確に理解したり、自己完結的に振り返って評価したりすることは難しい。出力の後にチームでの対話を行うことで初めて意味付けがなされ、自分の行動がプロジェクトの中で占める位置や重要性が認識できる。そのことによって得られる納得感が、さらに次の行動を自己決定する際の補助線になる。
## 4. 価値と成果の構造
### 4.1 価値
価値とは、プロジェクト外部のステークホルダーが、プロジェクトが実行された結果として、意味や有用性を認識して受け取る便益である。
Project Sprint では基本的に、実現を目指す価値もそのために達成すべき成果も固定的なものではなく、設定時の環境を前提とした可変的なものであると捉える。プロジェクトチームは小さな実験を繰り返して結果を検証し、環境の変化を捉えて価値や成果を更新してゆく。
また、プロジェクトからもたらされる便益に意味や有用性があるかどうかはあくまでステークホルダーの評価に委ねられるため、プロジェクトチームが意図し提供する便益と、ステークホルダーの認識する価値にずれが生じることもある。
この２つの理由から、Project Sprint においてはプロジェクトチームがプロジェクトにおける各時点で認識する価値はあくまで仮説であり、真に価値と言えるかどうかはステークホルダーを含む対話を通してのみ検証可能であることを念頭に置いておく必要がある。
なお、変化を前提とせず、当初設定した最終ゴールにまったく変更の余地がないという完全にウォーターフォール型のプロジェクトにおいては、プロジェクトチームが価値に関してステークホルダーと共通認識を持つことができる。そのため、この場合においてはプロジェクトチームが認識する価値は真の価値と同一のものといえる。
各メンバーの出力という個人単位の実験については真の価値に関する検証を含む必要はないが、プロジェクト単位では最終的に真の価値を提供できたかどうかの検証が必ずなされる必要がある。プロジェクト遂行中に部分納品を複数回行うようなアジャイル型のプロジェクトにおいては、デリバリーごとにステークホルダーからのフィードバックを得ることで、真の価値に関する検証を段階的に行っているといえる。
### 4.2 成果
成果とは、プロジェクト内のチームが、プロジェクト外部のステークホルダーに提供したい価値を踏まえ、プロジェクト内部のステークホルダー（当該成果の達成を担うチーム以外の別チーム）やプロジェクト全体に向けて生み出す所産である。
プロジェクトチームは、次の行動を決定する指針とするために、目的達成までの過程をプロジェクトストーリーとして表現する。プロジェクトストーリーは各チームのフラッグの集積によって表現され、プロジェクト内外に共有される。
フラッグとは、チームが外部からの制約や実現したい価値・成果を踏まえ、ある目的をもって設定した到達点であり、以下のような要素を持つ。
また、フラッグは以下のようなものでなくてはならない。
* 外部に依存せず、そのフラッグの達成に責任を持つチーム内で自己完結して行動できるものでなくてはならない
* そのフラッグを達成することが、フラッグの達成に責任を持つチームのみならず、プロジェクト内の他チームやプロジェクト全体に資する（＝成果となる）ものでなくてはならない（後述する成果物やあるべき状態は、当該成果の達成を担うチームを主語として設定されるが、成果は当該成果の達成を担うチームのみに便益を与えるものであってはならない）
* 環境の変化の影響を受けにくいように、開始から達成までの期間は長くとも2か月以内とする
* 直近の2か月程度を完了日とするものは必ず達成するとチームが外部に宣言するコミットメントでなくてはならないが、それ以降を期日とするものは仮説であってよい
フラッグの達成のために設定されるゴールは、プロジェクトやプロジェクト内の一定のフェーズの完了の定義となる。ゴールには、完了日の他に、次の2つの要素が含まれる。
* **あるべき状態** : その状態に至ることで成果を達成したと判断できる、状態や定性的な捉え方。
* 誰が何をできる状態なのか
* ステークホルダーがどんな状態なのか
* プロジェクトがどんな状態なのか
* **成果物** : 出力・作成されることで成果を達成したと判断できる、有形的なものや定量的な値。
* 機能が付与されたサービス
* ボリューム・内容イメージの資料
* 目標として設定した測定値
ゴールをこの2つの要素両方を用いて表現することで、要素が相互に補完し合いチームの共通了解が形成されやすくなる。この2要素は共通かつ一定の価値仮説と成果を前提に設定され、プロジェクトが推進され完了日が近づいてくるにつれ、段階的に内容が更新されて精度が高まっていく。
フラッグの各要素もまた、相互に影響を与え合いながら精度を増していく。成果物やあるべき状態が段階的に精度を高めていくのに伴い、成果や価値仮説も変容することがある。また、成果や価値仮説が何らかの原因で変容したことにより、成果物やあるべき状態が変容することもある。
### 4.3 出力
出力とは、チームメンバーが作成物を産出することである。
成果と出力の関係は、次のようなものである。
1. プロジェクトチームは、外部に提供したい価値を踏まえ、実現すべき成果の仮説を立てる。
2. プロジェクトチームは、1で立てた仮説に従って、直近のフラッグを目指して出力に取り組む。
3. それぞれのチームメンバーは、目標を達成するための行動を自律的に設定し遂行する。
4. チームメンバーによる出力は小さな実験として、次の二つのインパクトを持ちうる。
* 出力に取り組むことで得られた成果が、最終的な成果の実現に貢献する
* 出力に取り組むことで得られた環境情報が、成果の仮説を更新する材料になる
5. プロジェクトチームは、上のインパクトに従って成果の仮説を更新し、目標やタスクの設定を最適化する。
この関係に則ってプロジェクトに取り組むことにより、プロジェクトチームは変化する環境と目的を捉えつづけながら、最新の仮説に従った成果を生み出すべく行動を最適化することができる。
## 5. チームの自律性の構造
Project Sprint においては、プロジェクト内外の変化を素早く捉えつづけることのできる自律的なチームである事が求められる。「自律的」とは、チームメンバーが自発的・主体的に考え、行動ができている状態をいう。つまり、ある事柄に対して自分がチームのために何をすべきかを各メンバーが判断でき、かつ実際に行動できる状態のことである。
### シェアド・リーダーシップ
Project Sprint では、プロジェクト内外の変化を素早く捉えつづける自律的なチームであるために必要なものとして、シェアド・リーダーシップの考え方を取り入れている。
シェアド・リーダーシップとは、プロジェクトがある特定のリーダーの指揮のもとで進むのではなく、メンバー全員がそれぞれ必要なときに必要なリーダーシップを発揮する状態のことを指す。
シェアド・リーダーシップの状態であるためには、**分化**と**統合**が同時に達成されている必要がある。つまり、各メンバーは自らの納得と決定に基づいて自律的・自発的に行動しながら（分化）、チームとしては同じ目標に向かって協調・連携している（統合）状態といえる。目標の共有によりチームとしての方向性が定まり、それを前提に各メンバーが行動を自己決定できるようになる。
分化的な行動のためには、各メンバーがチームの中での自身の責任や役割を自覚して納得したうえで相互に期待する内容を共有し、自信を持って行動できなくてはならない。
統合的な行動のためには、メンバーそれぞれがもつプロジェクトに対する認識を定期的に擦り合わせ、チームとして何を目指しているのかを調整しつづけて、協調・連携しながら行動できなくてはならない。
この分化と統合という一見相反することがらを同時に達成するためには、メンバー間の信頼関係を築くことが重要である。信頼関係が構築されると、
* 失敗を恐れず前向きに行動を自己決定できる → 分化の促進
* 協力をリスクと捉えず助け合うようになる → 統合の促進
### 活動がチーミングに与える効果
信頼の構築に最も効果的なのは活動と対話の繰り返し、特に具体的な作成物を生み出してそれをもとに対話を行うことである。個々人の活動の結果を踏まえて対話することで、各メンバーが納得できるかたちでチームとしての認識を揃えていくことができる。
活動、すなわち作成物への取り組みは、成果を実現したり仮説を変容させる材料を得たりする手段であるのと同様に、役割を引き受けてチームへの貢献と誠実さを示すことによって信頼関係を醸成する手段でもある。作成物そのものや作成物への取り組み方から、それを生み出したメンバーの経験やスキル、置かれている状況を見て取ることができる。他のメンバーの作成物を率直かつ公正に受けとめることもまた、相互の信頼の構築に大きく役立つ。
チームメンバー間の信頼関係がベースにあることで、相互の期待に対する共通了解が生まれ、各々が自分の活動を自己決定しやすくなる。各メンバーが自分の持ち場を自分で認識し、その場においてリーダーシップを発揮することで、「みんなでプロジェクトを進める」状態が実現される。
## 6. Project Sprint におけるプロジェクトの認識
Project Sprint においては、便宜上プロジェクトをプログレス、チーミング、プロセスという3つのドメインに分けて認識する。プロジェクトにおける個々の実践を、これらの3つの側面それぞれから解釈することで、個々の実践がプロジェクトの中で持つ意義や効果をより正確かつ多面的に認識できる。この認識をプロジェクトチームで共有することにより、個々のメンバーは実践に対する各自の具体的な行動を必要に応じて自律的に最適化することができるようになる。
この Framework における以下のセクションは、それぞれのドメインに対応したものである。 3. プロジェクト推進の構造 ⇒ プロセス 4. 価値と成果の構造 ⇒ プログレス 5. チームの自律性の構造 ⇒ チーミング
以下の表は、それぞれの側面における認識のしかたを整理したものである。
| | プログレス | チーミング | プロセス |
| ------------------------------- | ----------------------------------------------------------- | -------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- |
| 何に焦点を当てるか | 成果 | チームメンバー相互の関係 | 作成物の出力と定例会議のサイクル |
| 何を目指すか | 成果の実現 | 自律的なチームの形成 | プロジェクトを推進・改善しやすい環境の構築 |
| どのような観点から
プロジェクトを捉えるか
| 最終的に目指す成果までのプロジェクトストーリーを描く | 信頼関係を築き、分化的かつ統合的な自律的活動をチーム全員で行えるようにする | 作成物の出力と定例会議のサイクルで、自律的に行動できる環境・習慣をつくる |
| 重視される実践 | 成果の進捗・達成
成果の仮説の設定と更新
| 価値・成果の認識共有と納得
各自の責任・役割の自覚と引き受け
| 作成物の出力による一次情報の獲得
定例会議での問題の共同解決
|
| 重視される価値観 | 着実なタスクの実践による作成物の出力
環境の変化への能動的な追従
| メンバー相互の信頼関係の構築
チーム全員でのプロジェクト推進
| 各メンバーが次の行動を自己決定する
短期的・定期的・反復的な同期、継続的改善
|
# v4.2
## コンテンツ
* [**Introduction**](/ja/v4.2/introduction) はじめにお読みいただきたい文書です。Project Sprint からの提案の概要を紹介した上で、その基盤となっている価値観を簡単に紹介します。
* [**Definitions**](/ja/v4.2/definitions) Project Sprint を理解するための前提を示す文書です。Project Sprint におけるプロジェクト観を説明し、その他の用語を定義します。
* [**Framework**](/ja/v4.2/framework) Project Sprint の核となる概念や価値観を示す文書です。Project Sprint におけるプロジェクト推進の構造と、そのための価値観や推奨される振る舞いが記述されています。
## 関連情報
* [**Practical Guide**](https://miro.com/app/board/uXjVMX-zl6s=/) Project Sprint のフレームワークを実際のプロジェクトに導入し使いこなすためのガイドブックです。諸概念を図解し、分かりやすく説明しています。
★Project Sprint の内容に疑問やご意見を持たれた方は、[こちら](https://github.com/copilot-jp/project-sprint/discussions)のGitHub Discussionへお寄せください。
# Introduction
Project Sprint は、プロジェクトチーム自らがプロジェクトの主体となり、小さな成果を繰り返し確実に生み出すことを通じて、環境の変化を捉えつづけながら自律的にプロジェクトを推進するためのフレームワークです。
この Introduction では、 Project Sprint がどういった意図で構築され、どういったチームやプロジェクトに適したフレームワークなのかを解説します。また、Project Sprint をどのような性質のものとして捉え、どのようなスタンスで臨んでいただくとよいかをご案内します。
1. Project Sprint を提案する時代的背景
2. Project Sprint が目指す状態
3. Project Sprint における「プロジェクト」
4. Project Sprint のスタンス
5. Project Sprint のフレームワーク
## 1. Project Sprint を提案する時代的背景
プロジェクトの推進に関しては、これまでも多くの知見が蓄えられ、活用されてきました。しかし、近年の社会ではプロジェクトを取り巻く環境は目まぐるしく変化しており、それに伴って状況が刻一刻と変わる、予測の難しいプロジェクトが増えています。
Project Sprint は、プロジェクトチームがこうしたプロジェクトに対応できるようにするためのフレームワークとして考案されました。
環境の変化の少ない時代においては、当初の条件を不変のものとしてプロジェクトを定義したり計画したりすることができ、最終的に達成したいゴールから単純に逆算して計画的に成果を積み重ねていくことができました。
しかし環境の変化が激しく不確実性の高い現代においては、プロジェクトを取り巻く状況は刻一刻と変わっていきます。すべての活動は取り組んでみないと誰にも把握できないものであり、当初の条件や見通しは当然に変化するものであると捉えなくては、プロジェクトの本質的な成功に近づくことができません。
そのため、プロジェクトを小さな実験の繰り返しと捉え、プロジェクト内外で起きる変化やステークホルダーの要求に応じて、真に実現すべきゴールとそこまでの道筋を短いサイクルでアップデートしつづけていくことが求められます。
こういったプロジェクトでは、プロジェクトチームが自律的に活動できる必要があります。多様なメンバーが、それぞれの専門性と状況に応じて行動を自己決定・実行し、チームで素早く検証するというサイクルを繰り返すのです。
## 2. Project Sprint が目指す状態
上で述べたような要求に応えるために、Project Sprint が目指すのは、以下のような状態です。
* プロジェクトチームが、さまざまな変化に応じて自律的に行動できる
* プロジェクトチームにおいて、プロジェクトを推進するための行動が習慣化されている
前者の目的は変化を素早くキャッチして対応することであり、後者の目的は小さなサイクルで実験と検証を繰り返すことです。
この2つの状態を維持し改善しつづけることができる仕組みとして利用されるのが、定例会議です。
## 3. Project Sprint における「プロジェクト」
プロジェクトは、社会に変化をもたらすためにチームが自発的に行う活動です。
具体的には、次のような特徴をもつ活動が「プロジェクト」であるとProject Sprint では考えています。
* 短く期間を区切った探索的な活動が、反復継続される
* チームに環境の変化を捉えつづける意思がある
とはいえ、これは必要最低限の要素であり、個別具体的な活動がこの特徴にあてはまるかどうかや、 Project Sprint のフレームワークを導入するのに適しているかどうかは、なかなか判断が難しいものです。
判断を助けるために、Project Sprint におけるプロジェクトの捉え方と相反する活動を以下に挙げておきます。こういった活動は、Project Sprint のフレームワークよりも適した進め方が他に存在したり、Project Sprint のフレームワークを取り入れることが構造上困難であったりするものと言えます。
* 環境の変化を考慮しなくてよい活動
* 3か月で完全に終了しチームが解散してしまうなど、活動自体が短期間で終了し非連続的である
* 成果物やゴールまでの過程が詳細に決まっているなど、不確実性が高くなく全体を計画することができる
* 環境の変化に即して行動できない活動
* チームに決定権がなく承認プロセスに時間がかかるなど、素早い意思決定ができない
* チームに環境の変化を捉えつづけようとする意思がない
## 4. Project Sprint のスタンス
Project Sprint は、[「Adopt & Adapt (採用と適応)」](#user-content-fn-1)[^1]のスタンスで構築されています。
Project Sprint は、多様なプロジェクトに汎用的に適用することが可能です。しかし、 Project Sprint を自分たちのプロジェクトのフレームワークとして採用するかどうか、さらにどの部分をどういった形で採用するかは、個々のプロジェクトチームの意思に委ねられています。重要なのは、プロジェクトチームがどのような価値観に拠ってプロジェクトに取り組みたいかです。
以下のような価値観に共感を覚えるプロジェクトチームは、 Project Sprint との親和性が高く、 Project Sprint のフレームワークによる効果が上がりやすいでしょう。逆に、この価値観への共感が難しい場合、Project Sprint からの提案がプロジェクトチームに混乱を生じさせてしまう可能性があります。
* 所与の条件にとらわれず、チームの自己決定を重視する
* 予測型か適応型かにとらわれず、状況に応じて柔軟に使い分ける
* 最初に決めた目標の達成にとらわれず、小さな実験を日々繰り返し成果と改善を積み重ねる
こういった価値観を反映し、 Project Sprint においてプロジェクトをどのようなものとして捉えるとよいかは、 [Definitions](/ja/v4.1/definitions) に改めて詳しく記述しています。
また、 Project Sprint はあくまで実践知を一般化したフレームワークなので、個々のプロジェクトとその置かれた状況に適応するようにテーラリングした上で導入する必要があります。
自分たちがどのようなプロジェクトチームでありたいか、そして自分たちのプロジェクトの実情に最適なのはなにかを、まずは考えてみてください。その上で、 Project Sprint が提案する価値観が、より多くのプロジェクトを自由で創造的なものにすることを願っています。
## 5. Project Sprint のフレームワーク
Project Sprint は、実践知を集めて体系化することによってかたちづくられたフレームワークです。
堅牢な理論に立脚して構築された揺るぎないものではなく、プロジェクトの現場から日々新たな実践知を取り込みながら更新が続けられており、大きな進化の可能性も秘められています。
現在の Project Sprint の中でももっとも本質的な価値と言える内容を、 [Framework](/ja/v4.1/framework) にまとめています。Project Sprint の根幹をなすものとしての厳密さを重視しているため、具体的な実践内容やその手順というより、プロジェクト推進の構造やそのための価値観といった、抽象度の高い内容が記述されています。 Project Sprint における各概念の捉え方・考え方や、プロジェクトにおいて推奨される振る舞いを読み取っていただければと思います。
[^1]: [ITIL](https://en.wikipedia.org/wiki/ITIL)の精神に共感し、そのまま採用しています。
# Definitions
Project Sprint は、プロジェクトチーム自らがプロジェクトの主体となり、小さな成果を繰り返し確実に生み出すことを通じて、環境の変化を捉えつづけながら自律的にプロジェクトを推進するためのフレームワークです。
この Definitions では、Project Sprint を理解するための前提として読者の皆さんと共有したい、Project Sprint の世界観を説明し、その他の用語を定義します。
## 1. Project Sprint の世界観
**i) プロジェクトチームの意思にもっとも重きを置く**
Project Sprint は、プロジェクトチームがプロジェクトの中心であり、プロジェクトチームの意思がプロジェクトにおけるあらゆる事柄を決定するという世界観に立ちます。この世界観の下では、プロジェクトチームはプロジェクト内外の変化を自らの意思に基づいて解釈し、それに応じて自律的に行動することができます。
プロジェクトチームは、プロジェクトにおける唯一の決定権者かつ実行主体として自らの意思に基づいてプロジェクトを定義し、その後も状況の変化に応じてプロジェクトの再定義を繰り返しながらプロジェクトを推進していきます
プロジェクトゴールを変更の余地のない所与の条件と捉え、それに規定された「プロジェクト」を活動の固定的な枠組みとして受け入れることもできます。しかしそういった場合、プロジェクトチームはあくまで、与えられた定義や枠組みに従ってプロジェクト達成の条件を満たすために活動する、プロジェクトの構成要素のひとつでしかありません。そのため、プロジェクトメンバーという生身の人間がプロジェクト推進の最前線で活動しつづける中で感じる違和感や閃き、そしてプロジェクトチームの個性は、プロジェクトの枠組みや推進過程に十分に反映されず、プロジェクトチームの行動に不自由さが生じることがありました。
Project Sprint におけるプロジェクトチームは、所与の条件にそのまま従う参加者ではなく、プロジェクトを取り巻く状況を意思を持って解釈し納得した上でプロジェクトを定義する主体でなくてはなりません。そのことにより、プロジェクトチームはプロジェクトの実行主体として、プロジェクトを構想し定義しつづけていく責任とプロジェクト外部の環境の変化を捉えつづけていく責任、さらに外部のステークホルダーと自ら調整を行っていく責任を負うことになります。それはときに、プロジェクトチームにとって大きな挑戦になるかもしれません。
しかし、この考え方により、プロジェクトチームは固定的な枠組みに押し込められることなく、自らの意思で自由にプロジェクトを定義し、環境の変化を素早く捉えながら自律的にプロジェクトを推進することができるようになります。
**ii) 状況に応じて最適なアプローチを自由に決定する**
Project Sprint は、どのようなアプローチでプロジェクトを進めるかをその時々の状況に応じて自由に決定できるという世界観に立ちます。この世界観の下では、プロジェクトチームは状況の変化をキャッチすることにどの程度能動的でいるかを自らの意思に基づいて決定し、それに応じて最適な進め方を取ることができます。
プロジェクト進行のアプローチには、大きく分けて予測型（ウォーターフォール）と適応型（アジャイル）の二つがあります。
予測型は、変化の少ない環境を前提とし、予め設定した最終ゴールを目指してロードマップを組み立て、それに従ってプロジェクトを進めるというアプローチです。予測型で進められるプロジェクトは図1-1のように、プロジェクトの大枠が固定されており、達成すべきゴールはプロジェクト開始時点から明確です。プロジェクトチームはそれらの要求に応じた計画を立て、ゴールに向かって順を追って成果を積み上げていきます。
一方適応型は、環境は変化するものだということを前提とし、その変化を捉えて能動的に最終ゴールとロードマップを変化させながら進んでいくというアプローチを取ります。適応型で進められるプロジェクトは図2-2のように、不確実性と変動性が高く、プロジェクト開始時点では最終ゴールすらも曖昧模糊としたものであることもありますが、反復的・漸進的な取り組みの中で、先々のゴールやロードマップは自ずと詳細化・明確化されてゆきます。
個々のプロジェクトについて、予測型なら予測型、適応型なら適応型で進めるものと捉えることもできます。しかし、ひとつのプロジェクトの中でも、工程が予め明確になっており予測型で計画的に進めることができる部分と、未知の部分が多く適応型で柔軟に進めたほうがよい部分が混在することが多いものです。また、予測型と適応型はそもそも二項対立で切り分けられるものではなく、予測型と適応型の間には変化に対してどの程度能動的であるかにおいて無数のパターンがグラデーション状に存在します。
そのため Project Sprint は、プロジェクトへのアプローチを固定する必要はなく、状況に応じて適切なアプローチを柔軟に選択すればよいというハイブリッド型の考え方を取ります。
この考え方により、プロジェクトチームは、ロードマップの詳細さや厳密さに強弱をつけながら、効率的にプロジェクトを推進することができるようになります。
**iii) 探索的な小さな実験の繰り返しとしてプロジェクトを進める**
Project Sprint は、プロジェクトを探索的な小さな実験と検証の繰り返しと捉えるという世界観に立ちます。この世界観の下では、プロジェクトチームは将来にわたる計画を立てることに必要以上に囚われず、目の前の具体的な課題に取り組んで小さくとも確実にプロジェクトを推進することができます。
プロジェクトは、全体を一気に定義したり計画したりするものではなく、小さなサイクルの繰り返しであると捉えられます。最終的に達成すべき成果のために必要な要素を小さな成果に分割し、分割したひとつひとつの成果に対して仮説を立てて実行した上で、その検証をもとに以降のフェーズの軌道修正を行います。こうして反復的かつ漸進的にプロジェクトを進めていくのです。
プロジェクトにおける最終的な成果の達成までの一連の流れを、できるだけ失敗や手戻りが生じないように計画的に推進していこうと考えることもできます。しかし、計画を綿密に立ててもその後大幅に修正が必要になったり、プロジェクト全体を同じ精度で捉えつづけようとすることでメンバーの認知負荷が高くなりすぎたりすることもあります。
そのためProject Sprint では、仮説の設定とその仮説に沿った行動を、短いタイムスパンで小さく実験的に繰り返すという進め方を取ります。
個々の実験において重要なのは実験結果を振り返って次のフェーズに生かすことであって、仮説が正しかったかどうかはさほど重要なことではありません。「正しい仮説を立てる」ことにこだわって行動の速度が鈍ったり保守的になったりするよりは、「取り組んでみることで見えてくるものもある」と捉えて前向きに挑戦し、得られた結果を次のフェーズの改善材料にしていくのです。また、仮説が間違っていたとしても、実験の結果がプロジェクト全体の成功につながる成果を実現することもあります。ただし、行動を起こしやすく軌道修正を容易にするため、個々の実験のサイズは小さければ小さいほどよいということに留意する必要があります。
このようにプロジェクトを進めることで、プロジェクトチームは、創造性豊かに小さな挑戦を重ね、仮説を検証して小さく軌道修正を繰り返すことで、複雑な問題を素早く解決して最終的な成果に向けてプロジェクトを推進していくことができます。
## 2. 用語集
このセクションの用語は、Project Sprint の前提を理解し、Framework の記述をスムーズに読み進めるために定義したものです。
図3は、用語の全体像をおおまかに示したものです。個々の用語の詳細や相互の関係については、[Framework](/ja/v4.2/framework) などで別途記述されます。
* **チーム** 共通の目的をもってプロジェクト内の会議体に参加し、目的に向かって出力を行うメンバーの集まり。
* **プロジェクトチーム** プロジェクトの目的に対する共通了解をもち、プロジェクトの達成に向けて自律的に協働するメンバーの集まり。チームの一種だが、例外的に、全メンバーが参加する会議体を持たない場合や、出力を行わないアドバイザー的な立ち位置のメンバーを持つ場合がある。
* **プロジェクト** プロジェクトチームが、プロジェクト外部の社会に何らかの変化や価値を提供するために、自発的に行う活動。
* **フェーズ** チームがある目的をもって活動する期間。
* **プロジェクトストーリー** プロジェクトチームが次の行動を決定するための指針として、目的達成までの過程をシンプルに時系列で表現したもの。各チームのフラッグが集まることで表現される。
* **フラッグ** チームが、外部からの制約や実現したい価値・成果を踏まえ、ある目的をもって設定した到達点。以下の要素を持つ。
* **成果** チームが、プロジェクトにおいて実現を目指す価値を踏まえ、プロジェクト内の他チームやプロジェクト全体に向けて生み出す所産。
* **価値** プロジェクト外部のステークホルダーが、プロジェクトが実行された結果として受け取る便益。便益の有無や軽重の評価はステークホルダーの認識に委ねられるので、プロジェクトチームが創出を目指す価値はあくまで仮説である。
* **ゴール** フラッグのチームがある期日において達成していたい状態。要素として、あるべき状態・成果物・完了日の3つをもつ。
* **あるべき状態** その状態に至ることで成果を達成したと判断できる、状態や定性的な捉え方。
* **成果物** 出力・作成されることで成果を達成したと判断できる、有形的なものや定量的な値。
* **理由** プロジェクトの成立や推進に関して、過去に存在する背景や経緯。
* **目的** プロジェクトにおいて達成したい事柄に関するプロジェクトチームの意思。
* **制約** プロジェクトの外部環境にありプロジェクトチームの意思で調整することができない、プロジェクトチームの行動に制限を与える事柄。または、プロジェクトチームがステークホルダーから必ず達成することを期待されている事柄。
* **イベント** プロジェクトチームの行動が制限される出来事や期日。
* **出力** チームメンバーが作成物を産出すること。
* **作成物** チームメンバーによって生み出され、チームに対して共有されて他のチームメンバーが意見を述べたり助言をしたりといったリアクションを取ることが可能な、かたちあるもの。
* **実験** 行動を起こしやすく軌道修正を容易にするため、相対的に小さな規模で行われて次の行動の改善材料となる、作成物の産出を伴う成果の仮説構築・実行・検証のサイクル。
* **定例会議** チームが、短期的・定期的なサイクルで反復的に実施する対話の場。各メンバーが自身の次の行動を自己決定できる状態を目指して他のメンバーと同期し対話を行い、共通了解の形成、問題の共同解決、アイデアの共同創造、意思決定などを行う。
# Framework
## 1. Project Sprint は何を可能にするか
Project Sprint は、個々のメンバーの意思と相互の信頼関係を前提に、価値の創出を目指して協働する自律的な主体でありたいプロジェクトチームのためのフレームワークである。
Project Sprint の考え方を取り入れることで、プロジェクトチームはプロジェクトをより主体的に定義し、プロジェクトの中でより自由に振る舞い、より柔軟に選択し、より創造的に成果を生み出すことができるようになる。
このフレームワークは、プロジェクトチームが創造性豊かに小さな挑戦を重ね、仮説を検証して小さく軌道修正を繰り返すことで、複雑な問題を素早く解決して最終的な成果に向けてプロジェクトを進められるようにするためのものである。
## 2. Project Sprint におけるプロジェクト推進の構造
Project Sprint では、チームが実験を繰り返し小さな成果を生み出しつづけることを通して、プロジェクトの最終的な成果の実現に徐々に、そして着実に近づいていくことを、「プロジェクトの推進」と定義する。
そのためにプロジェクトの中では、プロジェクトゴールに至るまでの道のりを大小の成果の積み重ねの仮説として構築し、ひとつひとつの成果に対して実際に作成物を生み出してみて検証するという探索的な小さな実験が、チームによって繰り返し行われる。
プロジェクトを円滑に推進するためには、チームが自律的であることが重要である。チームとしての一貫性を前提に各メンバーが自発的に活動することで、必要な行動を自己決定して素早く実践し、結果を検証することができる。
## 3. Project Sprint におけるプロジェクトの認識
Project Sprint においては、便宜上プロジェクトをプログレス、チーミング、プロセスという3つのドメインに分けて認識する。プロジェクトにおける個々の実践を、これらの3つの側面それぞれから解釈することで、個々の実践がプロジェクトの中で持つ意義や効果をより正確かつ多面的に認識できる。この認識をプロジェクトチームで共有することにより、個々のメンバーは実践に対する各自の具体的な行動を必要に応じて自律的に最適化することができるようになる。
以下の表は、それぞれの側面における認識のしかたを整理したものである。
| | プログレス | チーミング | プロセス |
| ------------------------------- | ----------------------------------------------------------------------- | --------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ |
| 何に焦点を当てるか | 成果 | チームメンバー相互の関係 | 定例会議 |
| 何を目指すか | 成果の実現 | 自律的なチームの形成 | プロジェクトを推進・改善しやすい環境の構築 |
| どのような観点から
プロジェクトを捉えるか
| 最終的な成果を達成するまでの行程を小さな成果の積み重ねに細分化して、軌道修正を繰り返しながら徐々に達成する | メンバー相互の信頼関係をベースに、チームの一貫性と個人の自律性をもちチーム全員で進める | 定例会議を起点にした環境構築により実験とフィードバックのサイクルを習慣化・活性化させ、プロジェクトやチームの状態をよりよくする |
| 重視される実践 | 成果の進捗・達成
成果の仮説の設定と更新
| 価値・成果の認識共有と納得
各自の責任・役割の自覚と引き受け
| 各自の出力による作成物やアイデアの共同創造
定例会議での問題の共同解決
|
| 重視される価値観 | 反復的・漸進的な成果の実現
環境の変化への能動的な追従
| メンバー相互の信頼関係の構築
チーム全員によるプロジェクト推進
| 各メンバーの自己決定による自律的な行動
定期的・反復的な同期、継続的・漸進的な改善
|
以下に、各側面からみたプロジェクト推進の構造を詳述する。
## 4. 実験の構造 - プロセス
### 4.1 出力を軸にした活動と対話
プロジェクトは、活動と対話の短期的・定期的な反復によって推進される。そのサイクルを維持する要となるのは、チームメンバーが作成物を産出すること、すなわち**出力**である。活動によって出力をもたらすことと、具体的な出力に伴って得られた気づきを用いて対話を行うことが重要である。
* **活動** :
1. 各メンバーが、自ら**納得**した上で行動を起こす
2. 行動により具体的な**作成物**を生み出し、その過程で気づきを得る
3. 作成物自体やその出力に伴って得られた気づきを材料に、次の対話に向けて準備をする
* **対話** :
1. 各メンバーが活動報告をし**作成物を共有**することで、プロジェクトやチームの**状況を把握**する
2. チームとして現状の共通了解を形成した上で、アイデアの共同創造や問題の共同解決を行い、次に必要な活動を洗い出す
3. 次の対話までにどう行動すべきかを各メンバーが自覚し納得できるようにする
この活動と対話を短期的・定期的なサイクルで繰り返すことにより、まずは各自で行動してからチームとして現状を把握して共通了解を形成し、各メンバーが自ら納得した上で次の行動を取ることができる。
活動と対話のサイクルは、プロジェクトの最終ゴール達成のために解決すべき問題を徐々に見極めていく、探索的な実験の繰り返しであると言える。活動から得られる情報を活用して環境の変化を小さなサイクルで素早く捉え、プロジェクトを理解・改善することで、次の活動をよりよいものにしていくことが可能になる。
このサイクル、ひいてはプロジェクト推進の根幹を担うのは、活動による作成物の出力である。作成物が出力されなければ、プロジェクトゴールの達成に寄与する成果が生まれることも、プロジェクトを改善するための気づきが得られることもない。将来にわたる計画を立てようとするより、まず目の前の具体的な課題に取り組むことで実験的にプロジェクトを動かしてみるという実践こそが、プロジェクトを前に進める。
対話は、活動に事後的な意味付けを行うという意味でも重要である。各メンバーが自身の行動の意味を前もって正確に理解したり、自己完結的に振り返って評価したりすることは難しい。活動の後にチームでの対話を行うことで初めて行動に意味付けがなされ、自分の行動がプロジェクトの中で占める位置や重要性が認識できる。そのことによって得られる納得感が、さらに次の行動を自己決定する際の補助線になる。
また、対話は、個人の活動の範囲内では個人のものでしかなかった作成物を、チームに共有してプロジェクトのものにするプロセスでもある。個人の出力による作成物は、プロジェクトのものになることによって成果や価値につながっていく。
### 4.2 3つの仕組み
プロジェクトは、活動と対話の短期的・定期的・反復的なサイクルによって推進される。このサイクルを維持し改善しつづけるために必要な3つの仕組みについて、順に記述する。
#### ① 定例会議で推進しつづける仕組み
これまでに述べてきた通り、Project Sprint のプロジェクト推進プロセスは、活動（個人単位での作成物の生成）を踏まえた対話（チーム単位での共有）により、次の活動に向かう前提を揃えてチームの自律性を高め、次の活動へ向かわせるというものだった。
この対話の場となるのが**定例会議**である。
定例会議とは、チームが短期的・定期的なサイクルで反復的に実施する会議のことである。
* 短期的: プロジェクト全体のスケジュール感から見て相対的に短期であること
* 定期的: 人間の既存の習慣に沿った一定の期間が置かれること（日次、週次、隔週等）
* 反復的: 一定の型が存在すること（進行方法、アジェンダの種類や形式等）
定例会議を置き、決められたタイムスパンの中で定期的に活動を行うことで、プロジェクトに一定のリズムが生まれる。そのことには、以下のようなメリットがある。
* 生産性が向上する（作成物生成の期日が明確化される）
* 計画しやすくなる（過去の実績を判断材料にすることで、タスクの粒度を揃えたり作業計画を立てたりしやすくなる）
* 分析して改善しやすくなる（行動が習慣化される）
習慣化された行動により作成物が定期的・反復的に生み出され、それがプロジェクトを推進・アップデートしつづける材料となる。Project Sprint における定例会議の仕組みは、各メンバーの習慣的行動を導くものであり、各メンバーに習慣的行動が根付くことにより、チームや組織に変革がもたらされる。
また、会議の進行方法やアジェンダの型を決め、それに沿って定期的に対話することにより、以下のようなメリットが生まれる。
* チームが納得した意思決定をしやすくなる（全員の環境を一時的に固定して認識を揃える）
* プロジェクトを観測しやすくなる（定点観測で状況を理解しやすくなる）
* 分析して改善しやすくなる（反復するたびに効率が良くなる）
#### ② 共通了解をつくる仕組み
プロジェクトにおける**共通了解**とは、対話や議論を通してチーム内で形成され共有されている認識のことを指す。ものごとの認識の仕方はメンバーごとに異なり、まったく同じ認識を共有できるわけではないという大前提に立ちながらも、各メンバーがプロジェクトをどのように認識しているかを定期的に確認し、チームとして目指すところを常に調整しつづけることで、統合的な行動が取れるようになる。
定例会議と活動のサイクルが回っていたとしても、チーム内で環境[^1]の認識にずれが生じていれば、各メンバーの行動はそのプロジェクトに相応しくないものになってしまう可能性がある。そうならないように、以下のような事柄については共通了解を形成しておく必要がある。
* プロジェクトストーリー（プロジェクトチームが何を目指しているかの認識を揃えることで、統合的な行動が取れる）
* チームメンバーの役割・期待（チームの中で自分が何をすべきかを納得することで、自信を持って行動できる）
これらをチームの納得に基づいて設定し共有しておくことは、達成すべき成果を予測する精度を上げ、チームが自律的に行動しつづけるために非常に重要である。
プロジェクトストーリーは、プロジェクトチームが次の行動を決定するための指針として、目的達成までの過程をシンプルに時系列で表現したものであり、各チームのフラッグが集まることで表現されてプロジェクト内外に共有される。
チームメンバーの役割・期待については、「6. チームの自律性の構造 - チーミング」のセクションで詳述する。
#### ③ 継続的に改善する仕組み
**継続的改善アプローチ**は、チームメンバー全員の目線を使って、プロジェクトをよりよい状態にするべく定期的・継続的に改善しつづけるための仕組みである。
定例会議と活動のサイクルが回ることでプロジェクトは常に調整されているが、必ずしもすべての改善点が洗い出されているわけではない。また、これまでに述べた2つの仕組み自体を改善していく必要もある。
継続的改善アプローチは、フェーズの開始・終了時や大きな変更があったときなどプロジェクトの成果で区切って実施するだけでなく、月次・週次等定期的に実施することが重要である。
代表的なアクションとしては「定期的に過去の振り返りを実施してアイデアや問題をチームのものとして顕在化し、プロジェクトをよりよい状態にするための改善策を検討する」ということになるが、「過去」だけではなく「現在」にも目を向けることが重要だ。各メンバーが今現在感じている違和感や閃きを、リアルタイムでアイデアや問題に昇華して共有することが、チームの状況を改善するために不可欠だからである。
「過去」を見る振り返りだけを実施する場合、問題が共有されるのはその問題が起こってしまった後である可能性が高いが、「現在」を見ることで、問題が顕在化もしくは拡大する前に共有し対処することができるようになる。また、もやもやを解消できる場があることで、メンバーのプロジェクトへの参加意欲の向上にも繋がる。そのため Project Sprintでは、定例会議の中での違和感や閃きの共有という形で、定期的に現在の心境を出し合うことを推奨している。
## 5. 価値と成果の構造 - プログレス
### 5.1 価値
価値とは、プロジェクト外部のステークホルダーが、プロジェクトが実行された結果として、意味や有用性を認識して受け取る便益である。
Project Sprint では基本的に、実現を目指す価値もそのために達成すべき成果も固定的なものではなく、設定時の環境を前提とした可変的なものであると捉える。環境の変化を捉えつづけながら最終的な成果に向けてプロジェクトを推進していくため、プロジェクトチームは小さな実験で小さく成果を積み重ね、仮説を検証しながら軌道修正を繰り返す。
また、プロジェクトチームは当然、ステークホルダーに価値を提供することを目指してプロジェクトを推進するが、プロジェクトからもたらされる便益に意味や有用性があるかどうかはあくまでステークホルダーの評価に委ねられるので、プロジェクトチームが意図し提供する便益と、ステークホルダーの認識する価値にずれが生じることもある。
この２つの理由から、Project Sprint においてはプロジェクトチームがプロジェクトにおける各時点で認識する価値はあくまで仮説であり、真に価値と言えるかどうかはステークホルダーを含む対話を通してのみ検証可能であることを念頭に置いておく必要がある。
なお、変化を前提とせず、当初設定した最終ゴールにまったく変更の余地がないという完全にウォーターフォール型のプロジェクトにおいては、プロジェクトチームが価値に関してステークホルダーと共通認識を持つことができる。そのため、この場合においてはプロジェクトチームが認識する価値は真の価値と同一のものといえる。
各メンバーの出力という個人単位の実験については真の価値に関する検証を含む必要はないが、プロジェクト単位では最終的に真の価値を提供できたかどうかの検証が必ずなされる必要がある。プロジェクト遂行中に部分納品を複数回行うようなアジャイル型のプロジェクトにおいては、デリバリーごとにステークホルダーからのフィードバックを得ることで、真の価値に関する検証を段階的に行っているといえる。
### 5.2 成果
成果とは、プロジェクト内のチームが、プロジェクト外部のステークホルダーに提供したい価値を踏まえ、プロジェクト内部のステークホルダー（当該成果の達成を担うチーム以外の別チーム）やプロジェクト全体に向けて生み出す所産である。
プロジェクトチームは、価値仮説を踏まえて最終的に達成したい成果をいくつかのフラッグに分解し、それぞれのフラッグの達成に取り組む期間を個々のフェーズとして出力に取り組む。価値仮説に対して予測した成果が正しければ、プロジェクトに**進捗**がもたらされる。逆に、実験と検証の結果、価値仮説と成果の関係性が予測通りでなかったことが判明した場合には、その結果をもとに以降の成果に対する仮説を組み立てなおすことで、プロジェクトに**変容**がもたらされる。
この際の目標到達点としてのフラッグは、以下のようなものとなる。
* 外部に依存せず、そのフラッグの達成に責任を持つチーム内で自己完結して行動できるものでなくてはならない
* そのフラッグを達成することが、フラッグの達成に責任を持つチームのみならず、プロジェクト内の他チームやプロジェクト全体に資する（＝成果となる）ものでなくてはならない（後述する成果物やあるべき状態は、当該成果の達成を担うチームを主語として設定されるが、成果は当該成果の達成を担うチームのみに便益を与えるものであってはならない）
* 環境の変化の影響を受けにくいように、開始から達成までの期間は長くとも2か月以内とする
* 直近の2か月程度を完了日とするものは必ず達成するとチームが外部に宣言するコミットメントでなくてはならないが、それ以降を期日とするものは仮説であってよい
フラッグの達成のために設定されるゴールは、プロジェクトやプロジェクト内の一定のフェーズの完了の定義となる。ゴールには、完了日の他に、次の2つの要素が含まれる。
* **あるべき状態** : その状態に至ることで成果を達成したと判断できる、状態や定性的な捉え方。
* 誰が何をできる状態なのか
* ステークホルダーがどんな状態なのか
* プロジェクトがどんな状態なのか
* **成果物** : 出力・作成されることで成果を達成したと判断できる、有形的なものや定量的な値。
* 機能が付与されたサービス
* ボリューム・内容イメージの資料
* 目標として設定した測定値
ゴールをこの2つの要素両方を用いて表現することで、要素が相互に補完し合いチームの共通了解が形成されやすくなる。この2要素は共通かつ一定の価値仮説と成果を前提に設定され、プロジェクトが推進され完了日が近づいてくるにつれ、段階的に内容が更新されて精度が高まっていく。
フラッグの各要素もまた、相互に影響を与え合いながら精度を増していく。成果物やあるべき状態が段階的に精度を高めていくのに伴い、成果や価値仮説も変容することがある。また、成果や価値仮説が何らかの原因で変容したことにより、成果物やあるべき状態が変容することもある。
### 5.3 出力
出力とは、チームメンバーが作成物を産出することである。
成果と出力の関係は、次のようなものである。
1. プロジェクトチームは、外部に提供したい価値を踏まえ、実現すべき成果の仮説を立てる。
2. プロジェクトチームは、1で立てた仮説に従って、直近のフラッグを目指して出力に取り組む。
3. それぞれのチームメンバーは、目標を達成するための行動を自律的に設定し遂行する。
4. チームメンバーによる出力は小さな実験として、次の二つのインパクトを持ちうる。
* 出力に取り組むことで得られた成果が、最終的な成果の実現に貢献する
* 出力に取り組むことで得られた環境情報が、成果の仮説を更新する材料になる
5. プロジェクトチームは、上のインパクトに従って成果の仮説を更新し、目標やタスクの設定を最適化する。
この関係に則ってプロジェクトに取り組むことにより、プロジェクトチームは変化する環境と目的を捉えつづけながら、最新の仮説に従った成果を生み出すべく行動を最適化することができる。
## 6. チームの自律性の構造 - チーミング
Project Sprint における理想的なチームとは、プロジェクト内外の変化を素早く捉えつづけることのできる自律的なチームである。Project Sprint では、ある事柄に対して自分がチームのために何をすべきかを各メンバーが判断でき、かつ実際に行動できる状態のことを、自律的な状態であると定義する。
### シェアド・リーダーシップ
Project Sprint では、プロジェクト内外の変化を素早く捉えつづける自律的なチームであるために必要なものとして、シェアド・リーダーシップ[^2]の考え方を取り入れている。
シェアド・リーダーシップとは、プロジェクトがある特定のリーダーの指揮のもとで進むのではなく、メンバー全員がそれぞれ必要なときに必要なリーダーシップを発揮する状態のことを指す。
シェアド・リーダーシップの状態であるためには、**分化**と**統合**が同時に達成されている必要がある。つまり、各メンバーは自らの納得と決定に基づいて自律的・自発的に行動しながら（分化）、チームとしては同じ目標に向かって協調・連携している（統合）状態といえる。目標の共有によりチームとしての方向性が定まり、それを前提に各メンバーが行動を自己決定できるようになります。
分化的な行動のためには、各メンバーがチームの中での自身の責任や役割を自覚して納得したうえで相互に期待する内容を共有し、自信を持って行動できなくてはならない。
統合的な行動のためには、メンバーそれぞれがもつプロジェクトに対する認識を定期的に擦り合わせ、チームとして何を目指しているのかを調整しつづけて、協調・連携しながら行動できなくてはならない。
この分化と統合という一見相反することがらを同時に達成するためには、メンバー間の信頼関係を築くことが重要である。信頼関係が構築されると、
* 失敗を恐れず前向きに行動を自己決定できる → 分化の促進
* 協力をリスクと捉えず助け合うようになる → 統合の促進
### 活動がチーミングに与える効果
信頼の構築に最も効果的なのは活動と対話の繰り返し、特に具体的な作成物を生み出してそれをもとに対話を行うことである。個々人の活動の結果を踏まえて対話することで、各メンバーが納得できるかたちでチームとしての認識を揃えていくことができる。
活動、すなわち作成物への取り組みは、成果を実現したり仮説を変容させる材料を得たりする手段であるのと同様に、役割を引き受けてチームへの貢献と誠実さを示すことによって信頼関係を醸成する手段でもある。作成物そのものや作成物への取り組み方から、それを生み出したメンバーの経験やスキル、置かれている状況を見て取ることができる。他のメンバーの作成物を率直かつ公正に受けとめることもまた、相互の信頼の構築に大きく役立つ。
チームメンバー間の信頼関係がベースにあることで、相互の期待に対する共通了解が生まれ、各々が自分の活動を自己決定しやすくなる。各メンバーが自分の持ち場を自分で認識し、その場においてリーダーシップを発揮することで、「みんなでプロジェクトを進める」状態が実現される。
[^1]: ここで言う環境とは、プロジェクトやメンバーの状況はもちろん、プロジェクトの外部にある社会や組織など、プロジェクトやメンバーに影響を及ぼすすべての要素を含む。環境の変化がどのようにプロジェクトに影響を及ぼすかは、メンバーの感知・解釈によって決定される。
[^2]: 本セクションの記述に当たっては、以下の書籍を参照している。
石川淳（2016）「シェアド・リーダーシップ：チーム全員の影響力が職場を強くする」中央経済社
# v4.1
## [Introduction](/ja/v4.2/introduction)
Introduction では、Project Sprint からの提案の概要を紹介した上で、その基盤となっている価値観を簡単に紹介します。
## [Definitions](/ja/v4.1/definitions)
Definitionsでは、Project Sprint を理解するための前提となる、Project Sprint におけるプロジェクト観を説明し、その他の用語を定義します。
## [Framework](/ja/v4.1/framework)
Frameworkは、Project Sprint の核となる概念や価値観を示すものです。Project Sprint におけるプロジェクト推進の構造と、そのための価値観や推奨される振る舞いが記述されています。
v4では、Project Sprint がこれまでも重視してきた「作成物を生む」という行為により重点を置き、プロジェクトを「出力」と「成果」の関係から捉えなおしました。このことにより、以下のような効果を期待しています。
* 作成物を小さく確実に生み出し続けることを重視することで、プロジェクトの推進と最適化がよりスムーズに行えるようになる
* 出力を成果との1対1の対応関係から解き放ち、より幅広く価値を生み出すことができるようにする
* 予測型・適応型両方のプロジェクトに対応できるようになる
* プロジェクトをよりチームメンバー全員のものとして捉えることができるようになる
★Project Sprint の内容に疑問やご意見を持たれた方は、[こちら](https://github.com/copilot-jp/project-sprint/discussions)のGitHub Discussionへお寄せください。
# Introduction
Project Sprint は、プロジェクトチーム自らがプロジェクトの主体となり、小さな成果を繰り返し確実に生み出すことを通じて、環境の変化を捉えつづけながら自律的にプロジェクトを推進するためのフレームワークです。
この Introduction では、 Project Sprint がどういった意図で構築され、どういったチームやプロジェクトに適したフレームワークなのかを解説します。また、Project Sprint をどのような性質のものとして捉え、どのようなスタンスで臨んでいただくとよいかをご案内します。
1. Project Sprint を提案する時代的背景
2. Project Sprint が目指す状態
3. Project Sprint における「プロジェクト」
4. Project Sprint のスタンス
5. Project Sprint のフレームワーク
## 1. Project Sprint を提案する時代的背景
プロジェクトの推進に関しては、これまでも多くの知見が蓄えられ、活用されてきました。しかし、近年の社会ではプロジェクトを取り巻く環境は目まぐるしく変化しており、それに伴って状況が刻一刻と変わる、予測の難しいプロジェクトが増えています。
Project Sprint は、プロジェクトチームがこうしたプロジェクトに対応できるようにするためのフレームワークとして考案されました。
環境の変化の少ない時代においては、当初の条件を不変のものとしてプロジェクトを定義したり計画したりすることができ、最終的に達成したいゴールから単純に逆算して計画的に成果を積み重ねていくことができました。
しかし環境の変化が激しく不確実性の高い現代においては、プロジェクトを取り巻く状況は刻一刻と変わっていきます。すべての活動は取り組んでみないと誰にも把握できないものであり、当初の条件や見通しは当然に変化するものであると捉えなくては、プロジェクトの本質的な成功に近づくことができません。
そのため、プロジェクトを小さな実験の繰り返しと捉え、プロジェクト内外で起きる変化やステークホルダーの要求に応じて、真に実現すべきゴールとそこまでの道筋を短いサイクルでアップデートしつづけていくことが求められます。
こういったプロジェクトでは、プロジェクトチームが自律的に活動できる必要があります。多様なメンバーが、それぞれの専門性と状況に応じて行動を自己決定・実行し、チームで素早く検証するというサイクルを繰り返すのです。
## 2. Project Sprint が目指す状態
上で述べたような要求に応えるために、Project Sprint が目指すのは、以下のような状態です。
* プロジェクトチームが、さまざまな変化に応じて自律的に行動できる
* プロジェクトチームにおいて、プロジェクトを推進するための行動が習慣化されている
前者の目的は変化を素早くキャッチして対応することであり、後者の目的は小さなサイクルで実験と検証を繰り返すことです。
この2つの状態を維持し改善しつづけることができる仕組みとして利用されるのが、定例会議です。
## 3. Project Sprint における「プロジェクト」
プロジェクトは、社会に変化をもたらすためにチームが自発的に行う活動です。
具体的には、次のような特徴をもつ活動が「プロジェクト」であるとProject Sprint では考えています。
* 短く期間を区切った探索的な活動が、反復継続される
* チームに環境の変化を捉えつづける意思がある
とはいえ、これは必要最低限の要素であり、個別具体的な活動がこの特徴にあてはまるかどうかや、 Project Sprint のフレームワークを導入するのに適しているかどうかは、なかなか判断が難しいものです。
判断を助けるために、Project Sprint におけるプロジェクトの捉え方と相反する活動を以下に挙げておきます。こういった活動は、Project Sprint のフレームワークよりも適した進め方が他に存在したり、Project Sprint のフレームワークを取り入れることが構造上困難であったりするものと言えます。
* 環境の変化を考慮しなくてよい活動
* 3か月で完全に終了しチームが解散してしまうなど、活動自体が短期間で終了し非連続的である
* 成果物やゴールまでの過程が詳細に決まっているなど、不確実性が高くなく全体を計画することができる
* 環境の変化に即して行動できない活動
* チームに決定権がなく承認プロセスに時間がかかるなど、素早い意思決定ができない
* チームに環境の変化を捉えつづけようとする意思がない
## 4. Project Sprint のスタンス
Project Sprint は、[「Adopt & Adapt (採用と適応)」](#user-content-fn-1)[^1]のスタンスで構築されています。
Project Sprint は、多様なプロジェクトに汎用的に適用することが可能です。しかし、 Project Sprint を自分たちのプロジェクトのフレームワークとして採用するかどうか、さらにどの部分をどういった形で採用するかは、個々のプロジェクトチームの意思に委ねられています。重要なのは、プロジェクトチームがどのような価値観に拠ってプロジェクトに取り組みたいかです。
以下のような価値観に共感を覚えるプロジェクトチームは、 Project Sprint との親和性が高く、 Project Sprint のフレームワークによる効果が上がりやすいでしょう。逆に、この価値観への共感が難しい場合、Project Sprint からの提案がプロジェクトチームに混乱を生じさせてしまう可能性があります。
* 所与の条件にとらわれず、チームの自己決定を重視する
* 予測型か適応型かにとらわれず、状況に応じて柔軟に使い分ける
* 最初に決めた目標の達成にとらわれず、小さな実験を日々繰り返し成果と改善を積み重ねる
こういった価値観を反映し、 Project Sprint においてプロジェクトをどのようなものとして捉えるとよいかは、 [Definitions](/ja/v4.1/definitions) に改めて詳しく記述しています。
また、 Project Sprint はあくまで実践知を一般化したフレームワークなので、個々のプロジェクトとその置かれた状況に適応するようにテーラリングした上で導入する必要があります。
自分たちがどのようなプロジェクトチームでありたいか、そして自分たちのプロジェクトの実情に最適なのはなにかを、まずは考えてみてください。その上で、 Project Sprint が提案する価値観が、より多くのプロジェクトを自由で創造的なものにすることを願っています。
## 5. Project Sprint のフレームワーク
Project Sprint は、実践知を集めて体系化することによってかたちづくられたフレームワークです。
堅牢な理論に立脚して構築された揺るぎないものではなく、プロジェクトの現場から日々新たな実践知を取り込みながら更新が続けられており、大きな進化の可能性も秘められています。
現在の Project Sprint の中でももっとも本質的な価値と言える内容を、 [Framework](/ja/v4.1/framework) にまとめています。Project Sprint の根幹をなすものとしての厳密さを重視しているため、具体的な実践内容やその手順というより、プロジェクト推進の構造やそのための価値観といった、抽象度の高い内容が記述されています。 Project Sprint における各概念の捉え方・考え方や、プロジェクトにおいて推奨される振る舞いを読み取っていただければと思います。
[^1]: [ITIL](https://en.wikipedia.org/wiki/ITIL)の精神に共感し、そのまま採用しています。
# Definitions
Project Sprint は、プロジェクトチーム自らがプロジェクトの主体となり、小さな成果を繰り返し確実に生み出すことを通じて、環境の変化を捉えつづけながら自律的にプロジェクトを推進するためのフレームワークです。
この Definitions では、Project Sprint を理解するための前提として読者の皆さんと共有したい、Project Sprint の世界観を説明し、その他の用語を定義します。
## 1. Project Sprint の世界観
**i) プロジェクトチームの意思にもっとも重きを置く**
Project Sprint は、プロジェクトチームがプロジェクトの中心であり、プロジェクトチームの意思がプロジェクトにおけるあらゆる事柄を決定するという世界観に立ちます。この世界観の下では、プロジェクトチームはプロジェクト内外の変化を自らの意思に基づいて解釈し、それに応じて自律的に行動することができます。
プロジェクトチームは、自由な主体として自らの意思に基づいてプロジェクトを定義し、その後も状況の変化に応じてプロジェクトの再定義を繰り返しながらプロジェクトを推進していきます。
プロジェクトゴールを変更の余地のない所与の条件と捉え、それに規定された「プロジェクト」を活動の固定的な枠組みとして受け入れることもできます。しかしそういった場合、プロジェクトチームはあくまで、与えられた定義や枠組みに従ってプロジェクト達成の条件を満たすために活動する、プロジェクトの構成要素のひとつでしかありません。そのため、プロジェクトメンバーという生身の人間がプロジェクト推進の最前線で活動しつづける中で感じる違和感や閃き、そしてプロジェクトチームの個性は、プロジェクトの枠組みや推進過程に十分に反映されず、プロジェクトチームの行動に不自由さが生じることがありました。
Project Sprint におけるプロジェクトチームは、所与の条件にそのまま従う参加者ではなく、プロジェクトを取り巻く状況を意思を持って解釈し納得した上でプロジェクトを定義する主体でなくてはなりません。そのことにより、プロジェクトチームはプロジェクトの実行主体として、プロジェクトを構想し定義しつづけていく責任とプロジェクト外部の環境の変化を捉えつづけていく責任、さらに外部のステークホルダーと自ら調整を行っていく責任を負うことになります。それはときに、プロジェクトチームにとって大きな挑戦になるかもしれません。
しかし、この考え方により、プロジェクトチームは固定的な枠組みに押し込められることなく、自らの意思で自由にプロジェクトを定義し、環境の変化を素早く捉えながら自律的にプロジェクトを推進することができるようになります。
**ii) 状況に応じて最適なアプローチを自由に決定する**
Project Sprint は、どのようなアプローチでプロジェクトを進めるかをその時々の状況に応じて自由に決定できるという世界観に立ちます。この世界観の下では、プロジェクトチームは状況の変化をキャッチすることにどの程度能動的でいるかを自らの意思に基づいて決定し、それに応じて最適な進め方を取ることができます。
プロジェクト進行のアプローチには、大きく分けて予測型（ウォーターフォール）と適応型（アジャイル）の二つがあります。
予測型は、変化の少ない環境を前提とし、予め設定した最終ゴールを目指してロードマップを組み立て、それに従ってプロジェクトを進めるというアプローチです。予測型で進められるプロジェクトは図1-1のように、プロジェクトの大枠が固定されており、達成すべきゴールはプロジェクト開始時点から明確です。プロジェクトチームはそれらの要求に応じた計画を立て、ゴールに向かって順を追って成果を積み上げていきます。
一方適応型は、環境は変化するものだということを前提とし、その変化を捉えて能動的に最終ゴールとロードマップを変化させながら進んでいくというアプローチを取ります。適応型で進められるプロジェクトは図2-2のように、不確実性と変動性が高く、プロジェクト開始時点では最終ゴールすらも曖昧模糊としたものであることもありますが、反復的・漸進的な取り組みの中で、先々のゴールやロードマップは自ずと詳細化・明確化されてゆきます。
個々のプロジェクトについて、予測型なら予測型、適応型なら適応型で進めるものと捉えることもできます。しかし、ひとつのプロジェクトの中でも、工程が予め明確になっており予測型で計画的に進めることができる部分と、未知の部分が多く適応型で柔軟に進めたほうがよい部分が混在することが多いものです。また、予測型と適応型はそもそも二項対立で切り分けられるものではなく、予測型と適応型の間には変化に対してどの程度能動的であるかにおいて無数のパターンがグラデーション状に存在します。
そのため Project Sprint は、プロジェクトへのアプローチを固定する必要はなく、状況に応じて適切なアプローチを柔軟に選択すればよいというハイブリッド型の考え方を取ります。
この考え方により、プロジェクトチームは、ロードマップの詳細さや厳密さに強弱をつけながら、効率的にプロジェクトを推進することができるようになります。
**iii) 探索的な小さな実験の繰り返しとしてプロジェクトを進める**
Project Sprint は、プロジェクトを探索的な小さな実験と検証の繰り返しと捉えるという世界観に立ちます。この世界観の下では、プロジェクトチームは将来にわたる計画を立てることに必要以上に囚われず、目の前の具体的な課題に取り組んで小さくとも確実にプロジェクトを推進することができます。
プロジェクトは、全体を一気に定義したり計画したりするものではなく、小さなサイクルの繰り返しであると捉えられます。最終的に達成すべき成果のために必要な要素を小さな成果に分割し、分割したひとつひとつの成果に対して仮説を立てて実行した上で、その検証をもとに以降のフェーズの軌道修正を行います。こうして反復的かつ漸進的にプロジェクトを進めていくのです。
プロジェクトにおける最終的な成果の達成までの一連の流れを、できるだけ失敗や手戻りが生じないように計画的に推進していこうと考えることもできます。しかし、計画を綿密に立ててもその後大幅に修正が必要になったり、プロジェクト全体を同じ精度で捉えつづけようとすることでメンバーの認知負荷が高くなりすぎたりすることもあります。
そのためProject Sprint では、仮説の設定とその仮説に沿った行動を、短いタイムスパンで小さく実験的に繰り返すという進め方を取ります。
個々の実験において重要なのは実験結果を振り返って次のフェーズに生かすことであって、仮説が正しかったかどうかはさほど重要なことではありません。「正しい仮説を立てる」ことにこだわって行動の速度が鈍ったり保守的になったりするよりは、「取り組んでみることで見えてくるものもある」と捉えて前向きに挑戦し、得られた結果を次のフェーズの改善材料にしていくのです。また、仮説が間違っていたとしても、実験の結果がプロジェクト全体の成功につながる成果を実現することもあります。ただし、行動を起こしやすく軌道修正を容易にするため、個々の実験のサイズは小さければ小さいほどよいということに留意する必要があります。
このようにプロジェクトを進めることで、プロジェクトチームは、創造性豊かに小さな挑戦を重ね、仮説を検証して小さく軌道修正を繰り返すことで、複雑な問題を素早く解決して最終的な成果に向けてプロジェクトを推進していくことができます。
## 2. 用語集
このセクションの用語は、Project Sprint の前提を理解し、Framework の記述をスムーズに読み進めるために定義したものです。
図3は、用語の全体像をおおまかに示したものです。個々の用語の詳細や相互の関係については、[Framework](/ja/v4.1/framework) などで別途記述されます。
* **プロジェクトチーム** プロジェクトに対する共通了解をもち、プロジェクトの達成に向けて相互に協力し合うメンバーの集まり。プロジェクトにおける唯一の決定権者かつ実行主体として意思を持ち、プロジェクトを定義しつづけていく責任と、プロジェクト外部のステークホルダーとの調整を行う責任を負う。
* **プロジェクト** プロジェクトチームが、プロジェクト外部の社会に何らかの変化や価値を提供するために、自発的に行う活動。
* **価値** プロジェクト外部のステークホルダーが、プロジェクトが実行された結果として受け取る便益。便益の有無や軽重の評価はステークホルダーの認識に委ねられるので、プロジェクトチームが創出を目指す価値はあくまで仮説である。
* **成果** プロジェクト内のチームが、プロジェクトが実現を目指す価値を踏まえ、プロジェクト内の他チームやプロジェクト全体に向けて作り出す所産。
* **ゴール** プロジェクトチームが、プロジェクト内の一定のフェーズにおいて目指す到達点。要素として成果物・あるべき姿・完了日の3つをもつ。プロジェクト自体の到達点を最終ゴールと呼び、プロジェクト内におおまかに置かれた中間到達点を中間ゴールと呼ぶ。
* **成果物** 出力・作成されることで成果を達成したと判断できる、有形的なものや定量的な値。
* **あるべき姿** その状態に至ることで成果を達成したと判断できる、状態や定性的な捉え方。
* **フェーズ** プロジェクトチームが、ある目的をもって活動する期間。
* **ロードマップ** プロジェクトチームが次の行動を決定するための指針として、各フェーズにおいて達成すべき成果やタスクを時系列でマッピングしたもの。
* **出力** チームメンバーが作成物を産出すること。
* **作成物** チームメンバーによって生み出され、チームに対して共有されて他のチームメンバーが意見を述べたり助言をしたりといったリアクションを取ることが可能な、かたちあるもの。
* **実験** 行動を起こしやすく軌道修正を容易にするため、相対的に小さな規模で行われて次の行動の改善材料となる、作成物の産出を伴う成果の仮説構築・実行・検証のサイクル。
* **定例会議** プロジェクトチームが、短期的・定期的なサイクルで反復的に実施する対話の場。各メンバーが自身の次の行動を自己決定できる状態を目指して他のメンバーと同期し対話を行い、共通了解の形成、問題の共同解決、アイデアの共同創造、意思決定などを行う。
# Framework
## 1. Project Sprint は何を可能にするか
Project Sprint は、個々のメンバーの意思と相互の信頼関係を前提に、価値の創出を目指して協働する自律的な主体でありたいプロジェクトチームのためのフレームワークである。
Project Sprint の考え方を取り入れることで、プロジェクトチームはプロジェクトをより主体的に定義し、プロジェクトの中でより自由に振る舞い、より柔軟に選択し、より創造的に成果を生み出すことができるようになる。
このフレームワークは、プロジェクトチームが創造性豊かに小さな挑戦を重ね、仮説を検証して小さく軌道修正を繰り返すことで、複雑な問題を素早く解決して最終的な成果に向けてプロジェクトを進められるようにするためのものである。
## 2. Project Sprint におけるプロジェクト推進の構造
Project Sprint では、プロジェクトチームが実験を繰り返し小さな成果を生み出しつづけることを通して、プロジェクトの最終的な成果の実現に徐々に、そして着実に近づいていくことを、「プロジェクトの推進」と定義する。
そのためにプロジェクトの中では、プロジェクトゴールに至るまでの道のりを大小の成果の積み重ねの仮説として構築し、ひとつひとつの成果に対して実際に作成物を生み出してみて検証するという探索的な小さな実験が、プロジェクトチームによって繰り返し行われる。
プロジェクトを円滑に推進するためには、プロジェクトチームが自律的であることが重要である。チームとしての一貫性を前提に各メンバーが自発的に活動することで、必要な行動を自己決定して素早く実践し、結果を検証することができる。
## 3. Project Sprint におけるプロジェクトの認識
Project Sprint においては、便宜上プロジェクトをプログレス、チーミング、プロセスという3つのドメインに分けて認識する。プロジェクトにおける個々の実践を、これらの3つの側面それぞれから解釈することで、個々の実践がプロジェクトの中で持つ意義や効果をより正確かつ多面的に認識できる。この認識をプロジェクトチームで共有することにより、個々のメンバーは実践に対する各自の具体的な行動を必要に応じて自律的に最適化することができるようになる。
以下の表は、それぞれの側面における認識のしかたを整理したものである。
| | プログレス | チーミング | プロセス |
| ------------------------------- | ----------------------------------------------------------------------- | --------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ |
| 何に焦点を当てるか | 成果 | チームメンバー相互の関係 | 定例会議 |
| 何を目指すか | 成果の実現 | 自律的なプロジェクトチームの形成 | プロジェクトを推進・改善しやすい環境の構築 |
| どのような観点から
プロジェクトを捉えるか
| 最終的な成果を達成するまでの行程を小さな成果の積み重ねに細分化して、軌道修正を繰り返しながら徐々に達成する | メンバー相互の信頼関係をベースに、チームの一貫性と個人の自律性をもちチーム全員で進める | 定例会議を起点にした環境構築により実験とフィードバックのサイクルを習慣化・活性化させ、プロジェクトやプロジェクトチームの状態をよりよくする |
| 重視される実践 | 成果の進捗・達成
成果の仮説の設定と更新
| 価値・成果の認識共有と納得
各自の責任・役割の自覚と引き受け
| 各自の出力による作成物やアイデアの共同創造
定例会議での問題の共同解決
|
| 重視される価値観 | 反復的・漸進的な成果の実現
環境の変化への能動的な追従
| メンバー相互の信頼関係の構築
チーム全員によるプロジェクト推進
| 各メンバーの自己決定による自律的な行動
定期的・反復的な同期、継続的・漸進的な改善
|
以下に、各側面からみたプロジェクト推進の構造を詳述する。
## 4. 実験の構造 - プロセス
### 4.1 出力を軸にした活動と対話
プロジェクトは、活動と対話の短期的・定期的な反復によって推進される。そのサイクルを維持する要となるのは、チームメンバーが作成物を産出すること、すなわち**出力**である。活動によって出力をもたらすことと、具体的な出力に伴って得られた気づきを用いて対話を行うことが重要である。
* **活動** :
1. 各メンバーが、自ら**納得**した上で行動を起こす
2. 行動により具体的な**作成物**を生み出し、その過程で気づきを得る
3. 作成物自体やその出力に伴って得られた気づきを材料に、次の対話に向けて準備をする
* **対話** :
1. 各メンバーが活動報告をし**作成物を共有**することで、プロジェクトやチームの**状況を把握**する
2. チームとして現状の共通了解を形成した上で、アイデアの共同創造や問題の共同解決を行い、次に必要な活動を洗い出す
3. 次の対話までにどう行動すべきかを各メンバーが自覚し納得できるようにする
この活動と対話を短期的・定期的なサイクルで繰り返すことにより、まずは各自で行動してからプロジェクトチームとして現状を把握して共通了解を形成し、各メンバーが自ら納得した上で次の行動を取ることができる。
活動と対話のサイクルは、プロジェクトの最終ゴール達成のために解決すべき問題を徐々に見極めていく、探索的な実験の繰り返しであると言える。活動から得られる情報を活用して環境の変化を小さなサイクルで素早く捉え、プロジェクトを理解・改善することで、次の活動をよりよいものにしていくことが可能になる。
このサイクル、ひいてはプロジェクト推進の根幹を担うのは、活動による作成物の出力である。作成物が出力されなければ、プロジェクトゴールの達成に寄与する成果が生まれることも、プロジェクトを改善するための気づきが得られることもない。将来にわたる計画を立てようとするより、まず目の前の具体的な課題に取り組むことで実験的にプロジェクトを動かしてみるという実践こそが、プロジェクトを前に進める。
対話は、活動に事後的な意味付けを行うという意味でも重要である。各メンバーが自身の行動の意味を前もって正確に理解したり、自己完結的に振り返って評価したりすることは難しい。活動の後にチームでの対話を行うことで初めて行動に意味付けがなされ、自分の行動がプロジェクトの中で占める位置や重要性が認識できる。そのことによって得られる納得感が、さらに次の行動を自己決定する際の補助線になる。
また、対話は、個人の活動の範囲内では個人のものでしかなかった作成物を、チームに共有してプロジェクトのものにするプロセスでもある。個人の出力による作成物は、プロジェクトのものになることによって成果や価値につながっていく。
### 4.2 3つの仕組み
プロジェクトは、活動と対話の短期的・定期的・反復的なサイクルによって推進される。このサイクルを維持し改善しつづけるために必要な3つの仕組みについて、順に記述する。
#### ① 定例会議で推進しつづける仕組み
これまでに述べてきた通り、Project Sprint のプロジェクト推進プロセスは、活動（個人単位での作成物の生成）を踏まえた対話（チーム単位での共有）により、次の活動に向かう前提を揃えてチームの自律性を高め、次の活動へ向かわせるというものだった。
この対話の場となるのが**定例会議**である。
定例会議とは、プロジェクトチームが短期的・定期的なサイクルで反復的に実施する会議のことである。
* 短期的: プロジェクト全体のスケジュール感から見て相対的に短期であること
* 定期的: 人間の既存の習慣に沿った一定の期間が置かれること（日次、週次、隔週等）
* 反復的: 一定の型が存在すること（進行方法、アジェンダの種類や形式等）
定例会議を置くことにより、決められたタイムスパンの中で定期的に活動を行うことになり、以下のようなメリットが生まれる。
* 生産性が向上する（作成物生成の期日が明確化される）
* 計画しやすくなる（過去の実績を判断材料にしやすくなる）
* 分析して改善しやすくなる（行動が習慣化される）
また、会議の進行方法やアジェンダの型を決め、それに沿って定期的に対話することにより、以下のようなメリットが生まれる。
* チームが納得した意思決定をしやすくなる（全員の環境を一時的に固定して認識を揃える）
* プロジェクトを観測しやすくなる（定点観測で状況を理解しやすくなる）
* 分析して改善しやすくなる（反復するたびに効率が良くなる）
定例会議はプロジェクトに一定のリズムを生み出す。このリズムがあることで、タスクの粒度を揃えたり作業計画を立てたりすることが容易になり、各メンバーの行動の習慣化が促される。習慣化された行動により作成物が定期的・反復的に生み出され、それがプロジェクトを推進・アップデートしつづける材料となる。
#### ② 共通了解をつくる仕組み
プロジェクトにおける**共通了解**とは、対話や議論を通してプロジェクトチーム内で形成され共有されている認識のことを指す。ものごとの認識の仕方はメンバーごとに異なり、まったく同じ認識を共有できるわけではないという大前提に立ちながらも、個々人の活動の結果を踏まえて対話することで、各メンバーが納得できるかたちでプロジェクトチームとしての認識を揃えていくことができる。
定例会議と活動のサイクルが回っていたとしても、プロジェクトチーム内で環境の認識にずれが生じていれば、各メンバーの行動はそのプロジェクトに相応しくないものになってしまう可能性がある。そうならないように、以下のような事柄については共通了解を形成しておく必要がある。
* プロジェクトストーリー（チームが何を目指しているかを揃えることで、統合的な行動が取れる）
* チームメンバーの役割・期待値（チームの中で自分が何をすべきかを納得することで、自信を持って行動できる）
これらをプロジェクトチームの納得に基づいて設定し共有しておくことは、達成すべき成果を予測する精度を上げ、プロジェクトチームが自律的に行動しつづけるために非常に重要である。
なお、ここで言う環境とは、プロジェクトやメンバーの状況はもちろん、プロジェクトの外部にある社会や組織など、プロジェクトやメンバーに影響を及ぼすすべての要素を含む。環境の変化がどのようにプロジェクトに影響を及ぼすかは、メンバーの感知・解釈によって決定される。
#### ③ 継続的に改善する仕組み
**継続的改善アプローチ**は、チームメンバー全員の目線を使って、プロジェクトをよりよい状態にするべく定期的・継続的に改善しつづけるための仕組みである。
定例会議と活動のサイクルが回ることでプロジェクトは常に調整されているが、必ずしもすべての改善点が洗い出されているわけではない。また、これまでに述べた2つの仕組み自体を改善していく必要もある。
継続的改善アプローチは、フェーズの開始・終了時や大きな変更があったときなどプロジェクトの成果で区切って実施するだけでなく、月次・週次等定期的に実施することが重要である。
代表的なアクションとしては「定期的に過去の振り返りを実施してアイデアや問題をチームのものとして顕在化し、プロジェクトをよりよい状態にするための改善策を検討する」ということになるが、「過去」だけではなく「現在」にも目を向けることが重要だ。各メンバーが今現在感じている違和感や閃きを、リアルタイムでアイデアや問題に昇華して共有することが、チームの状況を改善するために不可欠だからである。
「過去」を見る振り返りだけを実施する場合、問題が共有されるのはその問題が起こってしまった後である可能性が高いが、「現在」を見ることで、問題が顕在化もしくは拡大する前に共有し対処することができるようになる。また、もやもやを解消できる場があることで、メンバーのプロジェクトへの参加意欲の向上にも繋がる。そのため Project Sprintでは、定例会議の中での違和感や閃きの共有という形で、定期的に現在の心境を出し合うことを推奨している。
## 5. 価値と成果の構造 - プログレス
### 5.1 価値
価値とは、プロジェクト外部のステークホルダーが、プロジェクトが実行された結果として、意味や有用性を認識して受け取る便益である。
Project Sprint では基本的に、実現を目指す価値もそのために達成すべき成果も固定的なものではなく、設定時の環境を前提とした可変的なものであると捉える。環境の変化を捉えつづけながら最終的な成果に向けてプロジェクトを推進していくため、プロジェクトチームは小さな実験で小さく成果を積み重ね、仮説を検証しながら軌道修正を繰り返す。
また、プロジェクトチームは当然、ステークホルダーに価値を提供することを目指してプロジェクトを推進するが、プロジェクトからもたらされる便益に意味や有用性があるかどうかはあくまでステークホルダーの評価に委ねられるので、プロジェクトチームが意図し提供する便益と、ステークホルダーの認識する価値にずれが生じることもある。
この２つの理由から、Project Sprint においてはプロジェクトチームがプロジェクトにおける各時点で認識する価値はあくまで仮説であり、真に価値と言えるかどうかは最終的なステークホルダーの受け取り方次第であることを念頭に置いておく必要がある。
なお、変化を前提とせず、当初設定した最終ゴールにまったく変更の余地がないという完全にウォーターフォール型のプロジェクトにおいては、プロジェクトチームが価値に関してステークホルダーと共通認識を持つことができる。そのため、この場合においてはプロジェクトチームが認識する価値は真の価値と同一のものといえる。
各メンバーの出力が価値に資するものであるかどうかは、プロジェクトチームによる対話を通して判断されるが、ここで見出されるのもあくまで仮説としての価値である。プロジェクトチームが提供する便益が真に価値と言えるかどうかは、ステークホルダーを含む対話を通して検証されなくてはならない。
実験は、仮説としての価値を提供することで終了とするのではなく、真の価値を提供できたかどうかの検証を含んだほうがよい。上述のような各メンバーの出力という個人単位の実験については真の価値に関する検証を含む必要はないが、プロジェクト単位では最終的に必ず価値の検証がなされる必要がある。プロジェクト遂行中に部分納品を複数回行うようなアジャイル型のプロジェクトにおいては、デリバリーごとにステークホルダーからのフィードバックを得ることで、真の価値に関する検証を段階的に行っているといえる。
### 5.2 成果
成果とは、プロジェクト内のチームが、プロジェクトが実現を目指す価値を踏まえ、プロジェクト内の他チームやプロジェクト全体に向けて作り出す所産である。
プロジェクトチームは、実現を目指す価値を踏まえて最終的に達成したい成果をいくつかの中間成果に分解し、それぞれの中間成果達成に取り組む期間を個々のフェーズとして出力に取り組む。この際の目標としての中間成果は、以下のようなものとなる。
* 外部に依存せず、その成果の達成に責任を持つチーム内で自己完結して行動できるものでなくてはならない
* その成果を達成することが、成果の達成に責任を持つチームのみならず、プロジェクト内の他チームやプロジェクト全体に資するものでなくてはならない
* 環境の変化の影響を受けにくいように、開始から達成までの期間は長くとも2か月以内とする
* 直近の2か月程度を期日とするものはプロジェクトチームが必ず達成すると外部に宣言するコミットメントでなくてはならないが、それ以降を期日とするものは仮説であってよい
成果の達成のために設定されるゴールには、次の二つの要素が含まれる。
* **成果物** : 出力・作成されることで成果を達成したと判断できる、有形的なものや定量的な値。
* 機能が付与されたサービス
* ボリューム・内容イメージの資料
* 目標として設定した測定値
* **あるべき姿** : その状態に至ることで成果を達成したと判断できる、状態や定性的な捉え方。
* 誰が何をできる状態なのか
* ステークホルダーがどんな状態なのか
* プロジェクトがどんな状態なのか
ゴールをこの2つの要素両方を用いて表現することで、要素が相互に補完し合いチームの共通了解が形成されやすくなる。この2要素は共通かつ一定の価値仮説と青果を前提に設定され、プロジェクトが推進され完了日が近づいてくるにつれ、段階的に内容が更新されて精度が高まっていく。
ゴールは、プロジェクトやプロジェクト内の一定のフェーズの完了の定義となる。設定の際には、まずはプロジェクト外部のステークホルダーに提供したい価値仮説を参照しながら、プロジェクト内部のステークホルダー（当該成果の達成を担うチーム以外の別チーム）に提供したい便益を成果とする。成果物やあるべき姿は、当該成果の達成を担うチームを主語として設定されるが、成果は当該成果の達成を担うチームのみに便益を与えるものであってはならない。
これらの要素は相互に影響を与え合いながら精度を増していく。成果物やあるべき姿が段階的に精度を高めていくのに伴い、成果や価値仮説も変容することがある。また、成果や価値仮説が何らかの原因で変容したことにより、成果物やあるべき姿が変容することもある。
価値仮説に対して予測した成果が正しければ、プロジェクトに**進捗**がもたらされる。逆に、実験と検証の結果、価値仮説と成果の関係性が予測通りでなかったことが判明した場合には、その結果をもとに以降の成果に対する仮説を組み立てなおすことで、プロジェクトに**変容**がもたらされる。
### 5.3 出力
出力とは、チームメンバーが作成物を産出することである。
成果と出力の関係は、次のようなものである。
1. プロジェクトチームは、外部に提供したい価値を踏まえ、実現すべき成果の仮説を立てる。
2. プロジェクトチームは、1で立てた仮説に従って、直近の中間成果を目標に据えて出力に取り組む。
3. それぞれのチームメンバーは、目標を達成するための行動を自律的に設定し遂行する。
4. チームメンバーによる出力は小さな実験として、次の二つのインパクトを持ちうる。
* 出力に取り組むことで得られた成果が、最終的な成果の実現に貢献する
* 出力に取り組むことで得られた環境情報が、成果の仮説を更新する材料になる
5. プロジェクトチームは、上のインパクトに従って成果の仮説を更新し、目標やタスクの設定を最適化する。
この関係に則ってプロジェクトに取り組むことにより、プロジェクトチームは変化する環境と目的を捉えつづけながら、最新の仮説に従った成果を生み出すべく行動を最適化することができる。
## 6. チームの自律性の構造 - チーミング
Project Sprint における理想的なプロジェクトチームとは、プロジェクト内外の変化を素早く捉えつづけることのできる自律的なチームである。Project Sprint では、ある事柄に対して自分がチームのために何をすべきかを各メンバーが判断でき、かつ実際に行動できる状態のことを、自律的な状態であると定義する。
### シェアド・リーダーシップ
Project Sprint では、プロジェクト内外の変化を素早く捉えつづける自律的なチームであるために必要なものとして、シェアド・リーダーシップ[^1]の考え方を取り入れている。
シェアド・リーダーシップとは、プロジェクトがある特定のリーダーの指揮のもとで進むのではなく、メンバー全員がそれぞれ必要なときに必要なリーダーシップを発揮する状態のことを指す。
シェアド・リーダーシップの状態であるためには、**分化**と**統合**が同時に達成されている必要がある。つまり、チームメンバーは自らの納得と決定に基づいて自律的・自発的に行動しながら（分化）、プロジェクトチームとしては同じ目標に向かって協調・連携している（統合）状態といえる。目標の共有によりチームとしての方向性が定まり、それを前提に各メンバーが行動を自己決定できるようになります。
分化的な行動のためには、各メンバーがチームの中での自身の責任や役割を自覚して納得したうえで相互に期待値を共有し、自信を持って行動できなくてはならない。
統合的な行動のためには、メンバーそれぞれがもつプロジェクトに対する認識を定期的に擦り合わせ、チームとして何を目指しているのかを調整しつづけて、協調・連携しながら行動できなくてはならない。
この分化と統合という一見相反することがらを同時に達成するためには、メンバー間の信頼関係を築くことが重要である。信頼関係が構築されると、
* 失敗を恐れず前向きに行動を自己決定できる → 分化の促進
* 協力をリスクと捉えず助け合うようになる → 統合の促進
この信頼の構築に最も効果的なのは活動と対話の繰り返し、特に具体的な作成物を生み出してそれをもとに対話を行うことである。作成物への取り組みは、成果を実現したり仮説を変容させる材料を得たりする手段であるのと同様に、役割を引き受けてチームへの貢献と誠実さを示すことによって信頼関係を醸成する手段でもある。作成物そのものや作成物への取り組み方から、それを生み出したメンバーの経験やスキル、置かれている状況を見て取ることができる。他のメンバーの作成物を率直かつ公正に受けとめることもまた、相互の信頼の構築に大きく役立つ。
チームメンバー間の信頼関係がベースにあることで、相互の期待値に対する共通了解が生まれ、各々が自分の活動を自己決定しやすくなる。各メンバーが自分の持ち場を自分で認識し、その場においてリーダーシップを発揮することで、「みんなでプロジェクトを進める」状態が実現される。
[^1]: 本セクションの記述に当たっては、以下の書籍を参照している。
石川淳（2016）「シェアド・リーダーシップ：チーム全員の影響力が職場を強くする」中央経済社
# v4.0
## [Introduction](/ja/v4.0/introduction)
Introduction では、Project Sprint からの提案の概要を紹介した上で、その基盤となっている価値観を簡単に紹介します。
## [Definitions](/ja/v4.0/definitions)
Definitionsでは、Project Sprint を理解するための前提となる、Project Sprint におけるプロジェクト観を説明し、その他の用語を定義します。
## [Framework](/ja/v4.0/framework)
Frameworkは、Project Sprint の核となる概念や価値観を示すものです。Project Sprint におけるプロジェクト推進の構造と、そのための価値観や推奨される振る舞いが記述されています。
v4では、Project Sprint がこれまでも重視してきた「作成物を生む」という行為により重点を置き、プロジェクトを「出力」と「成果」の関係から捉えなおしました。このことにより、以下のような効果を期待しています。
* 作成物を小さく確実に生み出し続けることを重視することで、プロジェクトの推進と最適化がよりスムーズに行えるようになる
* 出力を成果との1対1の対応関係から解き放ち、より幅広く価値を生み出すことができるようにする
* 予測型・適応型両方のプロジェクトに対応できるようになる
* プロジェクトをよりチームメンバー全員のものとして捉えることができるようになる
★Project Sprint の内容に疑問やご意見を持たれた方は、[こちら](https://github.com/copilot-jp/project-sprint/discussions)のGitHub Discussionへお寄せください。
# Introduction
Project Sprint は、小さな成果を繰り返し確実に生み出すことを通じて、環境の変化を捉えつづけながら価値の創出を目指すためのフレームワークです。
この Introduction では、 皆さんが Project Sprint に触れる際に、Project Sprint をどのような性質のものとして捉え、どのようなスタンスで臨んでいただくとよいかをご案内します。
1. Project Sprint の提案
2. Project Sprint の精神
3. Project Sprint のフレームワーク
## 1. Project Sprint の提案
Project Sprint は、プロジェクトチームがプロジェクトの中心であり、プロジェクトチームの意思がプロジェクトにおけるあらゆる事柄を決定するという相対主義的なプロジェクト観を提案します。このプロジェクト観を採用することで、プロジェクトチームはさまざまな不自由さから解放され、より自由かつ創造的にプロジェクトを進めることが可能になります。
プロジェクトの推進に関しては、これまでも多くの知見が蓄えられ、活用されてきました。しかし、近年の社会ではプロジェクトを取り巻く環境は目まぐるしく変化しており、それに伴って状況が刻一刻と変わる、予測の難しいプロジェクトが増えています。 Project Sprint は、プロジェクトチームがこうしたプロジェクトに対応できるようにするためのフレームワークとして考案されました。
Project Sprint のフレームワークを取り入れることにより、プロジェクトチームは自らがプロジェクトの主体となり、環境の変化を捉えつづけながら、プロジェクトをうまく推進できるようになります。
## 2. Project Sprint の精神
Project Sprint は、[「Adopt & Adapt (採用と適応)」](#user-content-fn-1)[^1]のスタンスで構築されています。
Project Sprint は、多様なプロジェクトに汎用的に適用することが可能です。しかし、 Project Sprint を自分たちのプロジェクトのフレームワークとして採用するかどうか、さらにどの部分をどういった形で採用するかは、個々のプロジェクトチームの意思に委ねられています。重要なのは、プロジェクトチームがどのような価値観に拠ってプロジェクトに取り組みたいかです。
以下のような価値観に共感を覚えるプロジェクトチームは、 Project Sprint との親和性が高く、 Project Sprint のフレームワークによる効果が上がりやすいでしょう。逆に、この価値観への共感が難しい場合、Project Sprint からの提案がプロジェクトチームに混乱を生じさせてしまう可能性があります。
* 所与の条件にとらわれず、チームの自己決定を重視する
* 予測型か適応型かにとらわれず、状況に応じて柔軟に使い分ける
* 最初に決めた目標の達成にとらわれず、小さな実験を日々繰り返し成果と改善を積み重ねる
こういった価値観を反映し、 Project Sprint においてプロジェクトをどのようなものとして捉えるとよいかは、 [Definitions](/ja/v4.0/definitions) に改めて詳しく記述しています。
また、 Project Sprint はあくまで実践知を一般化したフレームワークなので、個々のプロジェクトとその置かれた状況に適応するようにテーラリングした上で導入する必要があります。
自分たちがどのようなプロジェクトチームでありたいか、そして自分たちのプロジェクトの実情に最適なのはなにかを、まずは考えてみてください。その上で、 Project Sprint が提案する価値観が、より多くのプロジェクトを自由で創造的なものにすることを願っています。
## 3. Project Sprint のフレームワーク
Project Sprint は、実践知を集めて体系化することによってかたちづくられたフレームワークです。
堅牢な理論に立脚して構築された揺るぎないものではなく、プロジェクトの現場から日々新たな実践知を取り込みながら更新が続けられており、大きな進化の可能性も秘められています。
現在の Project Sprint の中でももっとも本質的な価値と言える内容を、 [Framework](/ja/v4.0/framework) にまとめています。Project Sprint の根幹をなすものとしての厳密さを重視しているため、具体的な実践内容やその手順というより、プロジェクト推進の構造やそのための価値観といった、抽象度の高い内容が記述されています。 Project Sprint における各概念の捉え方・考え方や、プロジェクトにおいて推奨される振る舞いを読み取っていただければと思います。
[^1]: [ITIL](https://en.wikipedia.org/wiki/ITIL)の精神に共感し、そのまま採用しています。
# Definitions
ここでは、Project Sprint を理解するための前提として、Project Sprint のプロジェクト観を説明し、その他の用語を定義します。
## 1. Project Sprint のプロジェクト観
環境の変化の少ない時代においては、当初の条件を不変のものとしてプロジェクトを定義したり計画したりすることができました。しかし環境の変化が激しく不確実性の高い現代においては、すべての活動は取り組んでみないと誰にも把握できないものであり、当初の条件や見通しは当然に変化するものであると捉えなくては、プロジェクトの本質的な成功に近づくことができません。
そのためProject Sprint では、プロジェクト全体を一気に定義したり計画したりするのではなく、小さく切り分けて捉え、そのひとつひとつのフェーズにおいてどのようなアプローチを取りどう行動するのが適切かをプロジェクトチームが決めていくのがよいという考え方を取っています。
この考え方を取り入れるために読者の方と共有したいプロジェクト観を、以下の3つの特徴から説明します。
**i) なにに基づいてプロジェクトを定義するか**
Project Sprint において、プロジェクトはプロジェクトチームの意思に基づいて定義されます。
Project Sprint では、まずプロジェクトチームが自由な主体としてその意思に基づいてプロジェクトを定義し、その後もプロジェクトチームによる再定義を繰り返しながらプロジェクトを推進していくと捉えます。この捉え方は、Project Sprint の主柱をなすものであり、Project Sprint をもっともよく特徴づけるものでもあります。
最終的に達成すべき成果をはじめから所与の条件と捉え、それに規定された「プロジェクト」を活動の固定的な枠組みとして受け入れることもできます。しかしそういった場合、プロジェクトチームはあくまで、与えられた定義や枠組みに従ってプロジェクト達成の条件を満たすために活動する、プロジェクトの構成要素のひとつでしかありません。そのため、プロジェクトメンバーという生身の人間たちが日々感じるプロジェクトの現場での状況や小さな気付き、そしてプロジェクトチームの個性は、プロジェクトの枠組みや推進過程に十分に反映されず、プロジェクトチームの行動に不自由さが生じることがありました。
Project Sprint は、この不自由さを解消するために、制約ありきではなくプロジェクトチームの意思ありきのプロジェクト観を提案します。
Project Sprint におけるプロジェクトチームは、プロジェクトに対する所与の条件にそのまま従う参加者ではなく、プロジェクトを取り巻く制約を意思を持って解釈し納得した上でプロジェクトを定義する主体でなくてはなりません。そのことにより、プロジェクトチームはプロジェクトの実行主体として、プロジェクトを構想し定義しつづけていく責任とプロジェクト外部の環境の変化を捉えつづけていく責任、さらに外部のステークホルダーと自ら調整を行っていく責任を負うことになります。それはときに、プロジェクトチームにとって大きな挑戦になるかもしれません。
しかし、このプロジェクト観により、プロジェクトチームは固定的な枠組みに押し込められることなく、自らの意思で自由にプロジェクトを定義し、環境の変化を柔軟に捉えながら自律的にプロジェクトを推進することができるようになります。
**ii) どのようにプロジェクトへのアプローチを選択するか**
Project Sprint において、プロジェクトへのアプローチはその時々のプロジェクトの状態に応じて自由に選択されます。
プロジェクトへのアプローチには、大きく分けて予測型（ウォーターフォール）と適応型（アジャイル）の二つがあります。予測型のアプローチでは、変化の少ない環境を前提とし、予め設定した最終成果を目指してロードマップを組み立て、それに従ってプロジェクトを進めます。一方適応型のアプローチでは、環境は変化するものだということを前提とし、その変化に応じて能動的に最終成果とロードマップを変化させながら進んでいきます。
 
個々のプロジェクトについて予測型なら予測型、適応型なら適応型で進めるものと捉えることもできます。しかし、ひとつのプロジェクトの中でも、工程が予め明確になっており予測型で計画的に進めることができる部分と、未知の部分が多く適応型で柔軟に進めたほうがよい部分が混在することが多いものです。また、予測型と適応型はそもそも二項対立で切り分けられるものではなく、予測型と適応型の間には変化への能動性において無数のパターンがグラデーション状に存在します。
そのため Project Sprint は、プロジェクトへのアプローチを固定せず、状況に応じて適切なアプローチを柔軟に選択できるプロジェクト観を提案します。
プロジェクトチームは、自らプロジェクトの状態を判断し、そのときの状況に最も適したアプローチを選択します。そのことにより、ロードマップの詳細さや厳密さに強弱をつけながら、効率的にプロジェクトを推進することができるようになります。
**iii) どのようにプロジェクトを進めるか**
Project Sprint において、プロジェクトは小さな実験の繰り返しとして進められます。
最終的に達成すべき成果のために必要な要素を小さな成果に分割し、分割したひとつひとつの成果に対して仮説を立案して実行した上で、その検証をもとに以降のフェーズの軌道修正を行います。こうして反復的かつ漸進的にプロジェクトを進めていくのです。
プロジェクトにおける最終的な成果の達成までの一連の流れを、できるだけ失敗や手戻りが生じないように計画的に推進していこうと考えることもできます。しかし、計画を綿密に立ててもその後大幅に修正が必要になったり、プロジェクト全体を同じ精度で捉えつづけようとすることでメンバーの認知負荷が高くなりすぎたりすることもあります。
そのためProject Sprint では、仮説の設定とその仮説に沿った行動を、短いタイムスパンで小さく実験的に繰り返すという進め方を取ります。
個々の実験において重要なのは実験結果を振り返って次のフェーズに生かすことであって、仮説が正しかったかどうかはさほど重要なことではありません。「正しい仮説を立てる」ことにこだわって行動の速度が鈍ったり保守的になったりするよりは、「取り組んでみることで見えてくるものもある」と捉えて前向きに挑戦し、得られた結果を次のフェーズの改善材料にしていくのです。また、仮説が間違っていたとしても、実験の結果がプロジェクト全体の成功につながる成果を実現することもあります。ただし、行動を起こしやすく軌道修正を容易にするため、個々の実験のサイズは小さければ小さいほどよいということに留意する必要があります。
このようにプロジェクトを進めることで、プロジェクトチームは、創造性豊かに小さな挑戦を重ね、仮説を検証して小さく軌道修正を繰り返すことで、複雑な問題を素早く解決して最終的な成果に向けてプロジェクトを推進していくことができます。
## 2. 用語集
Project Sprint におけるプロジェクトは、プロジェクトチームの出力によって成果が生み出され、その成果が外部に提供できる価値となることにより達成されます。以下の用語は、Project Sprint の前提を理解し、Framework の記述をスムーズに読み進めるために定義したものです。
* **プロジェクトチーム** プロジェクトに対する共通認識をもち、その達成に向けて相互に協力し合うメンバーの集まり。プロジェクトを定義・再定義することのできる、プロジェクトの実行主体。
* **プロジェクト** プロジェクトチームが、外部に何らかの価値を提供するために実行する活動。プロジェクトチームは、プロジェクトの実行主体としてプロジェクトを構想し定義しつづけていく責任と、外部のステークホルダーに対する説明責任を負う。
* **プロジェクトゴール** プロジェクトチームが、プロジェクトにおいて最終的な達成を目指すもの。目的・成果・期日という3つの要素をもつ。
* **フェーズ** プロジェクトゴールをいくつかの成果に分解したとき、個々の成果とそれを達成すべき期日が属する、プロジェクト内の一定の段階。
* **ロードマップ** チームが次の行動を決定するための指針として、プロジェクトにおいて達成すべき成果やタスクを時系列でマッピングしたもの。
* **価値** プロジェクトの外部に存在するステークホルダーが、プロジェクトチームによる成果を意味や有用性があると認識して受け取ったもの。価値の有無や軽重は最終的にステークホルダーの認識に委ねられるため、プロジェクトチームが認識する価値はあくまで仮説的なものである。
* **成果** チームが、プロジェクトやプロジェクト内の一定のフェーズで達成を目指し、最終的に生み出すもの。具体的な成果物と、達成したい状態としてのあるべき姿の両方を含む。
* **成果物** プロジェクトやプロジェクト内の一定のフェーズを完了するために必要な作成物。プロジェクトチームにとって、成果の実現に資すると認識できるものでなければならない。
* **出力** チームメンバーが作成物を産出すること。
* **作成物** チームメンバーによって生み出され、チームに対して共有されて他のチームメンバーが意見を述べたり助言をしたりといったリアクションを取ることが可能な、かたちあるもの。
* **実験** 行動を起こしやすく軌道修正が容易な規模で行われて次の行動の改善材料となる、作成物の産出を伴う成果の仮説構築・実行・検証のサイクル。
* **定例会議** チームメンバーが、自身の行動を自己決定する際の前提を得るために他者と同期することを求めて、定期的・反復的に集まる機会。個々の定例会議が終わった時点で各メンバーが自身の次の行動を自己決定できる状態になっていることを目指して、認識合わせ、問題の共同解決、アイデアの共同創造、意思決定などを行う。
# Framework
## Project Sprint は何を可能にするか
Project Sprint は、個々のメンバーの意思と相互の信頼関係を前提に、価値の創出を目指して協働する自律的な主体でありたいプロジェクトチームのためのフレームワークである。
Project Sprint の考え方を取り入れることで、プロジェクトチームはプロジェクトをより主体的に定義し、プロジェクトの中でより自由に振る舞い、より柔軟に選択し、より創造的に成果を生み出すことができるようになる。
このフレームワークは、プロジェクトチームが創造性豊かに小さな挑戦を重ね、仮説を検証して小さく軌道修正を繰り返すことで、複雑な問題を素早く解決して最終的な成果に向けてプロジェクトを進められるようにするためのものである。
## Project Sprint におけるプロジェクト推進の構造
Project Sprint においては、プロジェクトチームが小さな成果を生み出しつづけることを通して、プロジェクトの最終的な成果の実現に徐々に、しかし着実に近づいていくことを、「プロジェクトの推進」と定義する。
そのためにプロジェクトの中では、プロジェクトゴールに至るまでの道のりを大小の成果の積み重ねの仮説として構築しなおし、ひとつひとつの成果に対して実際に作成物を生み出してみるという小さな実験が、プロジェクトチームによって繰り返し行われる。
この実験には、二つのインパクトがある。
* **進捗**: 実験の中で生み出された作成物が成果と認識されれば、プロジェクトの達成に一歩近づく。
* **変容**: 実験結果の検証をもとに、以降の成果に対する仮説を組み立てなおすことができる。
環境の変化が少ない場合においては、実験を行わずとも当初の条件を不変のものとし、最終的に達成したい成果から単純に逆算して計画的に成果を積み重ねていくことができる。しかし、変化の激しい時代にあって、実現すべき成果はその時々の外部環境の変化やステークホルダーの要求に応じて変容する。プロジェクトチームはその変化にどう対処するかを自己決定し、変化を捉えつづけると決めた場合にはその決定に基づいて成果の仮説を変容させていくことになる。
したがって、Project Sprint では、実現を目指す価値もそのために達成すべき成果も固定的なものではなく、あくまで設定時の環境を前提とした可変的な仮説である。そのため、小さな実験で小さく成果を積み重ね、仮説を検証しながら軌道修正を繰り返すことで、環境の変化に遅れることなく最終的な成果に向けてプロジェクトを推進していくことができる。
## Project Sprint における成果と出力の関係
プロジェクトチームは、プロジェクトやプロジェクト内の一定の成果ストリームにおいて、最終的に目指す成果をいくつかの中間成果に分解し、それぞれの中間成果を目標に据えて出力に取り組む。この際の目標としての中間成果は、以下のようなものとなる。
* 外部に依存せず、その成果に関与するチーム内で自己完結的に達成できるものでなくてはならない
* 環境の変化の影響を受けにくいように、長くとも2か月以内を期日とする
* 直近の2か月程度を期日とするものはプロジェクトチームが必ず達成すると外部に宣言するコミットメントでなくてはならないが、それ以降を期日とするものは仮説であってよい
成果と出力の関係は、次のようなものである。
1. プロジェクトチームは、外部に提供したい価値を踏まえ、実現すべき成果の仮説を立てる。
2. プロジェクトチームは、1で立てた仮説に従って、直近の中間成果を目標に据えて出力に取り組む。
3. それぞれのチームメンバーは、目標を達成するための行動を自律的に設定し遂行する。
4. チームメンバーによる出力は小さな実験として、次の二つのインパクトを持ちうる。
* 出力に取り組むことで得られた成果が、最終的な成果の実現に貢献する
* 出力に取り組むことで得られた環境情報が、成果の仮説を更新する材料になる
5. プロジェクトチームは、上のインパクトに従って成果の仮説を更新し、目標やタスクの設定を最適化する。
この関係に則ってプロジェクトに取り組むことにより、プロジェクトチームは変化する環境と目的を捉えつづけながら、最新の仮説に従った成果を生み出すべく行動を最適化することができる。
## Project Sprint におけるプロジェクトの認識
Project Sprint では、プロジェクトを3つの側面から認識する。
プロジェクトにおける個々の実践を、これらの3つの側面それぞれから解釈することで、それぞれの実践がプロジェクトの中で持つ意義や効果をより正確かつ多面的に認識できる。この認識をプロジェクトチームで共有することにより、個々のメンバーは実践に対する各自の具体的な行動を必要に応じて自律的に最適化することができるようになる。
以下の表は、それぞれの側面における認識のしかたを整理したものである。なお、このFrameworkではここまで主にプログレス的側面を取り上げてきた。チーミング的側面及びプロセス的側面については、それぞれこの後のセクションで取り上げる。
| | プログレス | チーミング | プロセス |
| ------------------------------- | ----------------------------------------------------------------------- | --------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ |
| 何に焦点を当てるか | 成果 | チームメンバー相互の関係 | 定例会議 |
| 何を目指すか | 成果の実現 | 自律的なプロジェクトチームの形成 | プロジェクトを推進・改善しやすい環境の構築 |
| どのような観点から
プロジェクトを捉えるか
| 最終的な成果を達成するまでの行程を小さな成果の積み重ねに細分化して、軌道修正を繰り返しながら徐々に達成する | メンバー相互の信頼関係をベースに、チームの一貫性と個人の自律性をもちチーム全員で進める | 定例会議を起点にした環境構築により実験とフィードバックのサイクルを習慣化・活性化させ、プロジェクトやプロジェクトチームの状態をよりよくする |
| 重視される実践 | 成果の進捗・達成
成果の仮説の設定と更新
| 価値・成果の認識共有と納得
各自の責任・役割の自覚と引き受け
| 各自の出力による作成物やアイデアの共同創造
定例会議での問題の共同解決
|
| 重視される価値観 | 反復的・漸進的な成果の実現
環境の変化への能動的な追従
| メンバー相互の信頼関係の構築
チーム全員によるプロジェクト推進
| 各メンバーの自己決定による自律的な行動
定期的・反復的な同期、継続的・漸進的な改善
|
## Project Sprint におけるプロジェクトチーム
Project Sprint では、プロジェクトは特定のリーダーの指揮のもとで進むものではなく、メンバー全員で進めるものだと考えている。それは単に作業を分担するということにとどまらず、プロジェクトが外部に提供したい価値への認識をチームで共有し、メンバー全員がプロジェクト内での活動とその先にあるべき価値を結びつけて捉え自律的に行動できるということを指す。変化しつづける環境や目的に適応するためには、個々人が自身の行動を自己決定できる必要があるからである。
Project Sprint におけるプロジェクトチームの理想の状態とは、チームとしての一貫性を持ちながら、各メンバーが相互の信頼をベースに自律的・主体的に思考・行動できる状態を指す。Project Sprint では、ある事柄に対して自分がチームのために何をすべきかを各メンバーが判断でき、かつ実際に行動できる状態のことを、自律的な状態であると定義する。自律的であるためには、次のようなことが必要である。
* 最終的に達成したい成果がプロジェクトチーム全員によって合意・納得され、環境の変化に応じた成果の仮説の更新も都度共有されて認識が揃っていること
* 各メンバーが自身の責任や役割を自覚して納得の上で引き受け、相互の期待値を共有していること
特に後者の根底にあるのはメンバー間の信頼であり、この信頼の構築に最も効果的なのは出力に取り組むこと、つまり作成物を生み出すことである。作成物への取り組みは、価値を実現したり環境情報を取得したりする手段であるのと同様に、役割を引き受けてチームへの貢献と誠実さを示すことによって信頼関係を醸成する手段でもある。他のメンバーの作成物を率直かつ公正に受けとめることもまた、相互の信頼の構築に大きく役立つ。
チームメンバー間の信頼関係がベースにあるからこそ、メンバー個人の多様性が尊重されるとともにチームとしての目的が共有され、結果としてプロジェクトを全員で進めることが可能になる。
プロジェクトチームは、プロジェクトが実現したい成果の仮説（プログレスのストーリー）と、プロジェクトチームにおいて推奨される価値観や態度（チーミングのストーリー）を緩やかに共有し、それを個々のメンバーが思考や行動の拠りどころとすることで、チームとしての一貫性を持つ。プロジェクトチームはこのことにより全体の方向性を揃え、さらに相互に信頼し合うことで、プロジェクトを全員で進めていく。
## Project Sprint のプロジェクト推進プロセス
Project Sprint においてプロジェクトの推進とは、ここまで述べてきたような実験と最適化を繰り返し行って、プロジェクトの最終的な成果の達成に向けて小さく確実に成果を積み重ねていくことを指す。
そのためには、プロセス的側面がうまく機能してプログレス的側面とチーミング的側面が最適化されている必要がある。この三つの要素すべてに共通して最適化の材料になるのは、個人の活動とチームの対話である。
個人の活動においては、各メンバーが納得の上で行動を起こし、作成物を生み出し、その過程でさまざまな違和感や閃きを得ることで、対話の準備を行う。個人の活動により得られるのは、以下のような結果である。
* プロジェクトの漸進的な進捗が得られる（小さな成果が積み重なる）
* プロジェクトの現在地を把握するための情報が得られる（仮説の更新の材料となる）
* 各メンバーの観点で課題やアイデアを提案する材料が得られる（チーム全員の観点を活用する）
チームの対話においては、各メンバーから持ち寄られた活動報告や作成物を共有することでプロジェクトの現状を把握し、次の対話までに各自が新たな行動を行うために必要な前提をチームで決定する。
この活動と対話を、**定例会議** として定期的・反復的に繰り返すことで、プロジェクトチームからの期待を理解した各メンバーがそれぞれの活動を自己決定し自律的な行動を起こしやすい環境が生まれる。その結果として新たな違和感や閃きが生まれやすくなるとともに、環境の変化を小さなサイクルで素早く捉えながらプロジェクトを軌道修正し推進していくことが可能になる。
定例会議において重要なのは、チームメンバー全員が一時的に同一の環境に固定されてリアルタイムで会話をすることにより、素早く効率的な認識合わせと全員にとって納得感のある意思決定という、同期的な会議でしか生まれない効果を生むことだ。定例会議により得られるのは、以下のような結果である。
1. 環境情報や相互の役割への認識が揃うことで、価値観や信念を共有し共通の成果の実現を目指すプロジェクトチームとしての結びつきと一貫性が生まれる
2. アイデアの共同創造や問題の共同解決により、各メンバーの行動の前提となるプロジェクトチームとしての意思決定が下せる
3. 全員参加で会話することで、メンバーそれぞれがプロジェクトチームとしての意思決定に納得し、具体的なイメージを共有して、自律的に次の行動に向かうことができる
また、定例会議はプロジェクトに一定のリズムを生み出す。このリズムがあることで、タスクの粒度が揃えやすくなったり作業計画が立てやすくなったりするため、各メンバーの行動の習慣化も促される。習慣化された行動により作成物が定期的・反復的に生み出され、それがプロジェクトをアップデートしつづける材料となる。
# v3.3
## .png)
## **CODEとは**
**CODE**とは、Project Sprintについて説明したドキュメント群の総称です。
### [Theories](/ja/v3.3/theories) and [Practices](/ja/v3.3/practices)
このドキュメント群では、Project Sprintの基本的な概念の説明と実践方法が順を追って説明されます。理論編であるTheories及び実践編であるPracticesから成り、それぞれを上から順番に読み進めていくことで、Project Sprintを概念として理解した上で、実際のプロジェクトに取り入れて使うための知識を得ることができるようになっています。
すでにプロジェクトマネジメントの経験がある方が新しい方法論としてProject Sprintをインプットするために読むことはもちろん、すでにProject Sprintを導入している方も、効果的な活用のための基盤固めとして読むことができます。
### [Essentials](/ja/v3.2/essentials)
Project Sprintの核となる行動規範がシンプルに述べられており、そこからProject Sprintが立脚する思想や価値観を理解することができます。Theoriesの通読後に改めてEssentialsをお読みいただくと、Project Sprintの最重要箇所をより把握しやすくなるでしょう。
### [Reference](/ja/v3.3/reference)
Project Sprintの背景にある諸メソッド・概念・文献について記載されており、Project Sprintの効率的な理解が可能になり、また今後のメソッドのアップデートに関わりそうな情報を知ることができます。さらに、背景を知ることでメソッドの応用も可能になります。
## **ドキュメントの比較表**
| ドキュメント名 | Theories | Practices | Essentials | Reference |
| ------- | ---------------------------- | ----------------------------- | ------------------------------- | -------------------------------------------------------- |
| 記載内容 | 基本的な概念や考え方の説明 | 具体的な実践方法 | 核となる行動規範 | 背景にある諸メソッド・概念・文献 |
| 効果 | 理論体系としてのProject Sprintが理解できる | Project Sprintの具体的なノウハウが理解できる | Project Sprintが立脚する思想や価値観が理解できる | 効率的なProject Sprintの理解、メソッドのアップデートに関わりそうな情報、応用のための知識が得られる |
# Theories
このドキュメント群では、Project Sprintの基本的な概念の説明と実践方法が順を追って説明されます。理論編であるTheories及び実践編であるPracticesから成り、それぞれを上から順番に読み進めていくことで、Project Sprintを概念として理解した上で、実際のプロジェクトに取り入れて使うための知識を得ることができるようになっています。
すでにプロジェクトマネジメントの経験がある方が新しい方法論としてProject Sprintをインプットするために読むことはもちろん、すでにProject Sprintを導入している方も、効果的な活用のための基盤固めとして読むことができます。
| Contents | Theories | Practices |
| ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Project Sprint 101 | [Project Sprint 101](/ja/v3.2/theories/101) | WIP |
| プロジェクトライフサイクル | [5つのサイクル](/ja/v3.3/theories/project_lifecycle) | WIP |
| プロジェクトゴールとマイルストーン | プロジェクトゴールとは
マイルストーンとは
制約・イベント
| プロジェクトゴールの設定
マイルストーンの設定
プロジェクトゴールとマイルストーンの見直し
|
| トラック | [トラックとは](/ja/v3.3/theories/tracks) | [トラックの設定](/ja/v3.3/practices/tracks) |
| 期待値とロール | [期待値とロール](/ja/v3.2/theories/rolls) | チームメンバーの理解とロールシートの利用
ロールの確認
|
| 定例ミーティング | [定例ミーティングの重要性](/ja/v3.3/theories/meetings) | ミーティングの設計
ミーティングの進行方法
タスクの設定
ミーティングロールの確認
ミーティング環境についてのノウハウ
|
| アジェンダ | [アジェンダとは](/ja/v3.3/theories/agenda) | [アジェンダアイテムの要素](/ja/v3.2/practices/agenda) |
| プロジェクトの環境整備 | [プロジェクトの環境整備](/ja/v3.3/theories/project_environments) | 情報共有環境の構築
スタンドアップの導入
|
| 継続的改善アプローチ | [継続的改善アプローチ](/ja/v3.2/theories/continuous_improvement_approach) | 振り返り
テンショントリアージ
ロールセッション
|
| Project Sprintの成功指標 | [Project Sprintの成功指標](/ja/v3.1/tutorial/section4-4) | - |
| Project Sprintの発展 | - | [コントリビューターとしての参加の方法](https://github.com/copilot-jp/project-sprint/blob/master/JA/v3.3/theories/broken-reference/README.md) |
# Project Sprint 101
Project Sprintは、プロジェクトチームがプロジェクトゴールを設定したりプロジェクトゴールに向かって進んだりするのを助けるために、ものごとの捉え方・考え方や、最適化を促進するための仕組みを提供します。
Project Sprintの基本のメカニズムは、「定期的・反復的なミーティングで各メンバーの取り組みの成果や作成物を共有し環境に対する認識を揃えることによって、各メンバーが同じプロジェクトゴールを目指して自律的に各自の次の行動に向かうことができるようにする。この繰り返しがプロジェクトを現在の状態から理想の状態に漸進的に近づけ、結果としてプロジェクトゴールが達成される。」というものです。
ここでは、このメカニズムをうまく取り入れるためのコアとなるアクションとその前提を説明し、Theories及びPracticesにおける個別のドキュメントの内容を理解しやすくします。
### 前提
* プロジェクトは、変化しつづける環境と目的に常に追随するための小さな実験である。
* プロジェクトとは、「全体」としての課題に取り組む過程のうち、現状のプロジェクトチームで推進・達成に現実味が持てる「部分」を切り出したものである。
* プロジェクトゴールは、「全体ゴール」の達成に寄与する「部分ゴール」である。
* プロジェクトは、プログレス、チーミング、プロセスの3要素からなる。
* プログレスは、プロジェクトの成果物やゴールにフォーカスした活動である。
* チーミングは、チームメンバーの関係性にフォーカスした活動である。
* プロセスは、プロジェクトチームがプロジェクトゴールに向かって進んでいくための手続きにフォーカスした活動である。
* プロジェクトには、プロジェクトチームとプロジェクトゴールが不可欠である。
* プロジェクトチームは、プロジェクトゴールに対する共通認識をもち、その達成に向けて相互に協力し合うメンバーの集まりである。
* プロジェクトチームの役割は、よりよい形でプロジェクトゴールに向かっていくために、個々のメンバーの活動の前提を与えることである。
* プロジェクトゴールは、プログレスゴールとチーミングゴールから成り、いずれもプロジェクトチームによって定められる。
* プログレスゴールとは、プロジェクトの成果として目指すべき状態が達成されたり作成物が出力されたりすることである。
* チーミングゴールとは、相互に期待値を共有し合う自律的なプロジェクトチームが形成されることである。
* プロジェクトチームがプロジェクトゴールに近づくために最も重要なのは、ミーティングとそこにおけるアジェンダの議論である。
* ミーティングとは、チームメンバーが一時的に同一の環境に固定されてリアルタイムで会話をすることにより、素早く効率的な認識合わせと、全員にとって納得感のある意思決定をする場である。
* アジェンダとは、個人から出力されたアイデアや問題を、他のメンバーと共有し次の行動を決定するために明文化したものである。
* プロジェクトの理想の状態とは、次に述べるコア・アクションがプロジェクトチームとしても個人としても円滑に実行され、プロセスがサイクルとして繰り返されている状態である。
### コア・アクション
* プロジェクトチームは、自身の意思を反映させたプロジェクトゴールを設定し共有する。
* そのために、ミーティングで環境への認識を揃え、各メンバーが納得できるプロジェクトゴールを設定する。
* その結果、各メンバーは個人としてプロジェクトゴールに対する納得感と達成への現実味を持ち、自律的にアクションできる。
* プロジェクトチームは、メンバー間で各々の期待値に対する共通認識を持ち、チームにおける自身の役割や責任に納得してプロジェクトに取り組む。
* そのために、自身の役割や他のメンバーへの期待をミーティングで共有し認識を揃える。
* その結果、各メンバーが自分はチームのために何をすべきかを自律的に判断し実際にアクションできる。
* プロジェクトチームは、作成物を生み出すことにより、自ら設定したプロジェクトゴールに向かい漸進的に進む。
* そのために、各メンバーが作成物の出力に取り組み、その中で他のメンバーに伝えたいひらめきや違和感に出会う。
* その結果、ミーティングのアジェンダとして提出された各メンバーのひらめきや違和感をもとに、プロジェクトチームとしての意思決定が行われ、それを前提に各メンバーが自律的にさらに次のアクションに向かうことができる。
* プロジェクトチームは、プロジェクトゴールに向けた進捗や全体像を常に見直し、継続的に改善を行う。
* そのために、プロジェクトを一定の期間で区切って定期的・反復的なミーティングを実施する。
* その結果、環境の変化に応じ、納得感と共通認識を持ってプロジェクトやプロジェクトゴールを再定義し、適切な軌道修正をすることができる。
# プロジェクトライフサイクル
プロジェクトライフサイクルとは、プロジェクトが構想されてから完了に至るまでにプロジェクトチームが辿る一連のフェーズのことを指します。
Project Sprintにおいては、プロジェクトライフサイクルは構想期、形成期、自律準備期、自律推進期、結合期の5つのフェーズから成ると捉えます。プロジェクトチームが現在どのフェーズにあるのかによって、取るべき行動や達成すべき状態は異なります。そのため、このプロジェクトライフサイクルを理解し意識することによって、プロジェクトを効率よく進めることが可能になります。
## 構想期
プロジェクトの発案者が抱いた希望を叶えるためのツールとして、プロジェクトを立ち上げようとするフェーズ。
**行動**：
* 発案者の希望を明確化する。
* プロジェクト立ち上げの理由や目的、目指すべき理想の状態を整理する。
* プロジェクトがどのようなものになるべきかの仮説を立てる。
* 仮説に従って最適なチームメンバーを決定し、プロジェクトチームを組成する。
**達成したい状態**：
* 発案者の希望や要望が把握できている。
* プロジェクトに関する情報が整理されている。
* プロジェクトチームが現時点において最適なメンバー構成になっている。
## 形成期
構想期で組成されたプロジェクトチームが主体となり、プロジェクトが達成を目指す成果を一旦明確にするフェーズ。
**行動**：
* プロジェクトチームの環境に対する認識を揃え、意思を反映してプロジェクトゴールを設定する。
* 設定されたプロジェクトゴールを達成するために必要なリソースを把握する。
**達成したい状態**：
* プロジェクトの目的や価値が明確になっている。
* プロジェクトチームとしてプロジェクトゴールに合意・納得し、認識が揃っている。
* プロジェクトゴールを達成するために何が必要かが明確になっている。
* プロジェクトチームのメンバーが確定している。
## 自律準備期
プロジェクトを自律的に推進するために必要な境界をつくり環境を整えるフェーズ。
**行動**：
* プロジェクトゴールを分解して漸進的に達成するための中間成果を設定する。
* 中間成果を達成するために必要な要素を整理し、それぞれの要素において自律的に行動できるようなトラック分けと会議体の設計を行う。
* プロジェクトの進め方を改善しつづけられるよう、継続的改善アプローチを導入する。
**達成したい状態**：
* トラックが複数設定され、それぞれで定例ミーティングが運用されている。
* トラックは相互依存関係ができるだけ少なくなるよう設定されている。
* 定例ミーティングの方法やアジェンダのテンプレートなどが準備されプロジェクトチーム全体で共有されている。
## 自律推進期
自律的に行動を重ねて漸進的に成果を生み出し、認識合わせと再定義を繰り返すことでプロジェクトの進化に適応しつづけるフェーズ。
**行動**：
* 定例ミーティングを軸とした隔週～3か月程度の小さなサイクルを反復継続する。
* 作成物に取り組むことで生まれたひらめきや違和感を持ち寄って認識を合わせる。
* 認識を合わせた上でチームとして意思決定を行い、それを前提に各メンバーが自律的に次のアクションに向かう。
**達成したい状態**：
* プロジェクトに関する情報の透明性が高い。
* 定期的にプロジェクト全体やトラックごとの認識合わせが行われている。
* 各トラックのマイルストーンが可視化され、状況に応じて更新されている。
* それぞれのトラックで、定期的な成果物の出力と継続的改善アプローチによる最適化が行われている。
## 結合期
全体ゴールを見据えつつ、プロジェクトゴールに向けてプロジェクトの成果をまとめるフェーズ。
**行動**：
* プロジェクト完了の定義を決定する。
* 完了の定義に向かってプロジェクトを収束させていく、または次のプロジェクトへの継承を進める。
* 全体ゴールに対する部分ゴールの達成として出力できる形でプロジェクトの成果を整え、外部に示せるようにする。
**達成したい状態**：
* 漸進的に全体ゴールを達成するためになにが求められるかを把握できている。
* プロジェクトが集約され、誰かのリードを中心に進むようになる。
## 各サイクルにおけるProject Sprintの価値
Project Sprintの基本メカニズムが最もその効力を発揮するのは、プロジェクトチームが自律推進期にあるときです。定例ミーティングによる認識合わせと意思決定を経て、各メンバーが自律的に次の行動に向かっていくというサイクルの繰り返しが、プロジェクトチームを漸進的・安定的にプロジェクトゴールに向かわせるからです。 しかし、プロジェクトゴールやマイルストーン、トラックなどを設定し、プロジェクトの骨組みを作り軌道に乗せていく形成期や自律準備期においても、その段階におけるプロジェクトやそれを取り巻く環境の不確実性の高さゆえに、定例ミーティングで都度環境に対する認識を揃えプロジェクトを再定義するというProject Sprintのメカニズムは、高い効果を発揮します。 また、Project Sprintは、自律準備期をできるだけ短縮し、スムーズに自律推進期に入れるような考え方や仕組みを提供します。
# プロジェクトゴールとは
## プロジェクトゴールとは
プロジェクトゴールとは、プロジェクトにおいてプロジェクトチームが達成したい成果を指します。成果はある一定の状態であることもあれば、具体的な作成物であることもあります。
[Project Sprint 101](/ja/v3.2/theories/101)で述べたように、Project Sprintではプロジェクトを「全体」に対する「部分」であると捉えており、プロジェクトゴールは「大きなゴール」の達成に近づくために必要な一歩としての「小さなゴール」です。この漸進的な進捗のための成果だけでなく、「相互に期待値を共有し合う自律的なプロジェクトチームを形成する」というチーミングにおける理想の状態を達成することも、プロジェクトゴールに含まれます。漸進的な進捗のための成果とチーミングにおける理想の状態いずれの達成に比重が置かれるかは、プロジェクトによって様々です。
プロジェクトゴールはプロジェクトチームによって定義され、プロジェクトチームとして認識が揃っており、プロジェクトチームによって必要に応じて再定義しうるものでなくてはなりません。これらが実現していることにより、各チームメンバーがプロジェクトゴールの達成に現実味と納得感を持ってプロジェクトに参画できるのです。
プロジェクトチームは、プロジェクトが進むべき方向を適切に見定められるよう、プロジェクトゴールが全体ゴールに対してどういう位置づけにあり、どういう役割を果たすのかを常に認識しておく必要があります。また、このプロジェクトチームとしての認識は、プロジェクトの外部に対しても明確に示せる状態にしておきます。
## プロジェクトゴールの設定
プロジェクトはプロジェクトソースの希望を源として立ち上がり、まずはプロジェクトソース主導の下で、目指すべきゴールの仮説に基づいてプロジェクトチームが組成されます。プロジェクトチームが組成されてからは、プロジェクトチームが主体となり、自身の意思に基づいて改めてプロジェクトを定義しプロジェクトゴールを設定します。
具体的な設定方法については、実践編「[プロジェクトゴールの設定](/ja/v3.2/practices/project_goals)」をご覧ください。
# マイルストーンとは
## マイルストーンとは
マイルストーンとは、プロジェクト内のある時点において、具体的な作成物とそれに紐づく期限をセットにして記述したもののことです。あるマイルストーンを達成するまでの期間のことをステージと呼びます。
マイルストーンは[トラック](/ja/v3.3/theories/tracks)ごとに設定され、ひとつのトラックに複数置かれることがほとんどです。各トラックにおけるマイルストーンの達成の集積がメインのトラックにおけるマイルストーンの達成となり、メインのトラックにおけるマイルストーンを順次達成していくことがプロジェクトゴールの達成への道です。
マイルストーンもプロジェクトゴールと同様に、当該マイルストーンが置かれるトラックの進行を担うチームによって定義され、当該チームとして認識が揃っており、当該チームによって必要に応じて再定義しうるものでなくてはなりません。また、当該チームは自らが達成すべきマイルストーンがプロジェクトゴールに対してどういう位置づけにあり、どういう役割を果たすのかを常に認識し、それをプロジェクトチーム全体に対して明確に示せる状態にしておく必要があります。
## マイルストーンの価値
マイルストーンを明示化し常に意識することで、最終的な状態や作成物に向かう道筋の確からしさを確認し、現在の地点からチームが何をするべきか、またその後何を目指していくべきかを見通すことができます。
Project Sprintにおいて、プロジェクトゴールに向けての進捗は、現在のステータス(As-Is)とあるべきステータス(To-Be)の距離として捉えられます。 As-Is時点からTo-Beを描くとき、チームメンバーによってはあまり確度が高くないこともあります。
この原因は、大きく二つに分けられます。
* As-IsやTo-Beに関して、チームメンバー間で認識が揃っていないこと (**ズレの問題**)
* As-IsやTo-Beに関して、実際にタスクをリスト化し具体的に取り組んでいかなければ明らかにならない部分が多いこと (**粗さの問題**)
Project Sprintでは、定例ミーティングでの認識合わせとマイルストーンの設定によってこれらの問題を解決します。最終的なプロジェクトゴール（To-Be）より距離の近いTo-Be'としてのマイルストーンを設定することで未来に対する予測の粗さを軽減するとともに具体的な取り組みに落とし込みやすくするのです。
# トラックとは
## トラックとは
トラックとは、それぞれが強い依存関係を持たず、設定した役割や目標に沿って自律自走できるプロジェクト内の単位です。プロジェクトゴール達成を目指す過程を、それぞれが強い依存関係を持たず自律的に作業を進めることができる単位にまでブレイクダウンしたものを、トラックと呼びます。
[Project Sprint 101](/ja/v3.2/theories/101)で説明したように、Project Sprintではプロジェクトを「全体」の達成に寄与するひとつの「部分」として捉えます。トラックも同様に、プロジェクトという全体の達成に必要なそれぞれの部分といえます。トラックごとに目的や目指すべき成果（理想の状態・成果物）が存在し、それらが達成されることでプロジェクトゴールの達成に漸進的に近づいてゆきます。
必要なトラックの数や種類はプロジェクトごとに、またプロジェクトのフェーズにより異なります。一般的には、プロジェクト全体の状態を把握するためのメインのトラックをまず設定してマイルストーンを置き、そのマイルストーンの達成のために必要なものを要素ごとに分割することで、その他のトラックが置かれます。
プロジェクトの構想期はまだプロジェクトゴールが明確化されていないため、トラックへのブレイクダウンも進まないことが多いでしょう。その後の形成期や自律準備期において、プロジェクトゴールやマイルストーン、必要な成果物などが明確になってくるにつれて、トラックの分割が進みます。
## トラックの分化と統合
トラックを設定する際、まずは「このようなトラックが必要だろう」という仮説を立て、チームメンバーを決めます。この段階ではマイルストーンが置かれておらず、定例ミーティングのみのトラックになるかもしれません。その後定例ミーティングで認識合わせと意思決定を重ねることによってトラックのゴールやマイルストーンが明文化されていきます。
トラック同士は、依存関係が少ない疎結合な状態になるように設定します。トラック同士の依存関係は、個々のトラックの自律的な動きの妨げとなるからです。
とはいえ、最初にトラックを設定する場合やひとつのトラックを複数に分割する場合においては、他のトラックとの境界が曖昧で依存関係が比較的強く残り、他のトラックと密接に協力して作業する必要が出ることもあります。このような場合は、トラックごとの情報を整理して透明性を高め、定期的なミーティングで認識合わせを行いながら、最小限の協力で活動できるよう相互に体制を整えていきます。
こうして見てくると、トラックにも[プロジェクトライフサイクル](https://github.com/copilot-jp/project-sprint/blob/master/JA/v3.3/theories/proeject_lifecycle.md)と同様の考え方が適用できることが分かってくるでしょう。必要なトラックの仮説を立てチームメンバーを決めるのが構想期、その後トラックのゴールやマイルストーンを明文化するのが形成期、他のトラックとの連携体制や定例ミーティングの形を整えて自律に向かうのがトラックの自律準備期に当たります。
上述のように、自律準備期までは他のトラックとの境界が曖昧なことも多くあります。また、自律推進期に入ってからも、環境の変化に伴い他トラックとの相互依存関係が密になり、自律的な推進が難しくなることもあるでしょう。その場合には、一旦自律準備期に戻ったと捉えて情報や体制を整理し、改めて定期的な同期・連携による一定程度予測可能な相互作用のみでそれぞれが自律的に動ける状態に近づけていきます。
## トラックの分割例
例えば、あるWebサイトを立ち上げるプロジェクトを考えたとき（プロジェクトゴールは「Webサイトの完成」）、Webサイトのデザインを考えるチームと、Webサイトのシステム環境を整える作業は、一定程度関連はしながらも並行して進行します。このとき、それぞれの作業領域をトラックとして分割し、トラックごとにマイルストーンを分けて考えることで、よりプロジェクトを構造化して捉えられるようになります。
上述のWebサイトの例のようなトラック分割だけでなく、営業・マーケティング・CSといったロールベースでのトラック分割や、プロダクトごと・機能ごとのトラック分割など、プロジェクトの性質や規模によって、設定されるトラックは様々です。
# 制約・イベント
プロジェクトの外部環境にあって、プロジェクトに影響を与えるためプロジェクトメンバーが意識しなければならないものを、**制約**と呼びます。特に、マイルストーンの設定の前提となり、ときにプロジェクトゴールの設定にも影響を与えるものを**イベント**と呼びます。なお、プロジェクトの内部にあってマイルストーンやプロジェクトゴールの変動をもたらすものは、プロジェクトの一部として捉え、イベントとは呼びません。
制約は、社内の稟議スケジュールや予算など、所与のものであることが多いですが、プロジェクトを取り巻くさまざまな制約のうち、どれを実際にプロジェクトに影響を与えるイベントと捉えてマイルストーンやプロジェクトゴールの設定の前提とするかについては、プロジェクトチームで判断しなくてはならないこともあります。この場合にも、プロジェクトゴールやマイルストーンの決定時と同様に、プロジェクトチームとして認識を揃えた上で納得感のある意志決定をすることが大切です。
イベントの典型的な例は、プロジェクトの外で日々行われている、組織の定常業務です。具体的には取締役会などがこれにあたります。これ自体がプロジェクトの作成物を生み出すわけではありませんが、プロジェクトに関する何らかの報告や決裁がなされるため、こうしたイベントに合わせてマイルストーンを設定する必要があることがあります。また、こうしたイベントからフィードバックされた情報がプロジェクトの前提条件を変え、マイルストーンや、ときにはプロジェクトゴールそのものを変える必要が生じることもあります。
単発のものや定期的なものだけでなく、「商戦期」のような期間をもったものも、イベントとして認識します。それに合わせてプロジェクトのマイルストーンを設定したり、その結果を受けてマイルストーンやゴールを調整したりする必要があるという点は、特定の日付であっても期間であっても変わらないからです。
# 期待値とロール
Project Sprintでは、定例ミーティングでの期待値の共有とロールの設定によって、理想的なチームの形成を目指します。
## 期待値の共有
自律的なチームであるためには、チームメンバー各々の責任・役割が共有されて認識が揃っており、メンバー相互の期待値に齟齬がないことが重要です。言い換えると、あるチームメンバーが「あの人はこれをやってくれるだろう」と考えたとき、そのチームメンバーも「これは私がやるべきことだ」と考えている状態(**期待値の一致**)です。
また、メンバー個人の視点では、上記が実現されることで、チームから自分へ期待されていることや自分から他のメンバーへ期待してよいことが明確になります。チームにおける自分の責任・役割や他のメンバーからの期待に納得感が持てれば、自分がチームのために何をすべきかを自律的に判断し実際に行動できるようになります。自分に担うことができる役割であれば何であれ必要に応じていつでも担おうとするマインドセット (**自発的な役割の引き受け**)が生まれるのです。
## ロールの設定
Project Sprintでは、チームメンバー個々人の役割のことをロールと呼びます。ロールとチームメンバーは必ずしも一対一の関係である必要はありません。つまり、一人の人が複数のロールを担うこともありますし、またあるロールを複数の人が担うこともできます。
また、設定するロールの個数には制限がありませんし、「必ず設定すべきロール」というものもありません。ロールの定義に関しても、必要なのはチームメンバーで合意することのみです。プロジェクトの性質に応じて、必要な役割分担をチームメンバーで議論し、ロールとして明文化しましょう。
# 定例ミーティングの重要性
Project Sprintは、定例ミーティングを定期的・反復的な実践の起点とすることにより、進化するゴールをチームで漸進的に達成するためのプロジェクト推進メソッドです。プロジェクトチームがプロジェクトゴールに向かって円滑に進んでいくために最も重要なのは、チームでの定例ミーティングとそこでのアジェンダの議論です。
ここでは、Project Sprintにおいて定例ミーティングが不可欠である理由を記述します。
## ミーティングとは
Project Sprintでは「ミーティング」を、「チームメンバーが一時的に同一の環境に固定されてリアルタイムで会話をすることにより、素早く効率的な認識合わせと、全員にとって納得感のある意思決定をする場」と位置づけています。
リアルタイムで全員が集まるミーティングが、プロジェクトの意思決定においては最適な選択です。変化の激しい時代にあって、メールやチャットでの非同期のコミュニケーションでは、個々のメンバーが時間軸も視界も異なる環境に置かれることになるため認識に齟齬が生じやすく、意思決定が困難になります。リアルタイムで集まることでまず、チームメンバー全員が同じ時間軸に固定されます。そして会話する中でお互いの視界にある景色を擦り合わせて初めて認識が合い、大きな意思決定を行ったりそれに対して納得したりすることができるようになるのです。
## 定例ミーティングが不可欠である理由
**1. 定期的に振り返りを行うことで、プロジェクトを最適化できる。**
不確実性の高いプロジェクトにおいては、マイルストーン達成までの道のりは整然と進むわけではありません。各ステップの中で、立ち上げ、計画、実行、終結といったそれぞれの段階が重なり合い影響し合いながら進行していくのです。そこで、定期的なミーティングでの振り返りによってメンバー間の認識を都度擦り合わせ、必要に応じて調整を加えることで、プロジェクトを最適化する必要があります。
（PMBOKの概念を参照）
**2. 前回のミーティングから今回のミーティングまでの差分をキャッチアップする機会を保証できる。**
プロジェクトはルーチンワークと違って不確実性が高く、目的も変化しやすいものです。社会や組織の変化が激しいなかでも、定期的に集まることで、各チームメンバーが経験したこと・変化を確実に、定期的に吸収することができます。これらをインプットするからこそ、プロジェクトのゴールやマイルストーンをみんなで合意して変化させることも可能になります。
**プロジェクトとルーチンワークの違い**
**3. チームメンバーのスケジュールの調整コストが低くなる。**
社内外の多様なメンバーが参加するようなプロジェクトも多い昨今では、都度スケジュール調整をしているとそれだけで時間がかかります。そのため、あらかじめスケジュール設定をしておく方が効率がよいのです。また都度ミーティングを調整していると必要なタイミングでミーティング開催ができません。これは、必要十分な参加者が一度に集まって素早く効率的に意思決定をするというProject Sprintの利点を損ねてしまいます。
**4. 同じ曜日・時間に開催されることで、他のチームの人が共有のために覗きに来やすくなる。**
あるアジェンダアイテムについて特定のゲストを呼び、スペシャリストとしてのコメントをもらうといったことはよくありますが、定期的な時間・曜日があらかじめ設定されていると都度の調整が必要なく、すでにある時間に招待すればよいため、効率的です。
**5. 定期的に期間を区切るほうがタスクの粒度を作りやすい。**
定期的な期間、例えば「1週間でできること」という基準となる間隔をもつことで、これぐらいのタスクであればできるかな、という予測がしやすくなります。現実的なタスクを作成することは、アウトプットを確実に作ること、ひいてはアジェンダの確度を上げることにつながります。個々人のアクティビティであるタスク実行をプロジェクト全体の成果に反映させるプロセスを定期的に繰り返すことによって、プロジェクトが最適化されていきます。
**6. 業務のリズムを作りやすくなり、タスクの消化がスムーズになる。**
例えば毎週月曜日はこのミーティングがあるのでこういう作業時間を確保しておこう、など。個々のメンバーが作業計画を立てやすくなります。
**7. プロジェクトの定点観測資料になる。**
ミーティングのアジェンダ、議事録、タスクの進捗報告が定点観測的に残ります。これは振り返りの際に参照しやすいログとなるほか、新しいメンバーが参加した際の読みやすさも担保します（過去の情報をむやみに読むよりは、定期的に出力されたものをマイルストーンに沿って読むほうが理解しやすいため）。また、こうしたログが残っていれば、別のプロジェクトを開始する際、過去のプロジェクトがこのようにすすんだのだという参考やひな形にしやすくなります。
# アジェンダとは
アジェンダとは、個人から出力されたアイデアや問題を、他のメンバーと共有し次の行動を決定するために明文化したものです。ミーティングに提出され議論される個々のアジェンダを、アジェンダアイテムと呼びます。
## アジェンダアイテムの目的
アジェンダアイテムは、議論の目的によって次の三つの種類に分けられます。
* 発散：議論を通して幅広い選択肢が出てくる。結論が見えないテーマについて議論し、明確でないまま終了してよい。
* 収束：議論を通していくつか選択肢から一つの選択肢に絞られる。メンバー間での意思決定や合意形成など、最終的に何かしらの結論を出す。
* 共有：情報共有や前提確認など、チームメンバーと認識を合わせる。議論を特に必要としない。
個々のアジェンダアイテムがどれに分類されるのかあらかじめ示しておくことで、ミーティングの参加者が「どのような視点で」「どのような発言をするべきか」を理解することができます。例えば、「発散」のアジェンダアイテムであれば自由に意見を発してよく、新しいアイデアを出すことが重要だと分かります。反対に「収束」のアジェンダアイテムであれば、マイルストーン達成のためにどのようなアウトプットをつくっていくべきか、現実的な結論を導くことが必要だと分かります。また「共有」のアジェンダアイテムであれば、疑問点を質問しできるだけ認識を合わせることが重要だと分かります。
# プロジェクトの環境整備
## 実現したい状態と価値基準
Project Sprintが目指すのは、プロジェクトチームにより自律的にプロジェクトが推進されている状態です。そのためには、以下のようなことが必要となります。
* 各メンバーが、進化する目的や目標を深く理解・共感している
* 各メンバーが、誰かのマネジメントに頼らず自身の役割を理解している
* 各メンバーがチームに対してなんでも意見ができ、常に改善が行われている
これらを実現してProject Sprintの実施を助けるプロジェクト環境について記述します。
## 環境を作ることで実現したい状態
Project Sprintはスクラムと同様、「経験主義」と「リーン思考」に立脚しています。
**経験主義**とは、物事を理論よりも経験に基づいて考えようとする態度であり、スクラムガイドでは「知識は経験から生まれ、意思決定は観察に基づく」とされています。複雑性・不確実性が高く予測の難しい状況に対応するには、体系立った知識や完成したノウハウを正確に運用することよりも、実践や経験から得た知識を活かすことが重要だと考えているのです。
また、**リーン思考**とは、価値を生み出さない無駄な行動を省略し、本質に集中するという考え方です。今いるところにおいて最も重要な問題を特定し集中的に完結するというサイクルを繰り返すことにより、無駄を最小限に抑えながら価値を最大化することができます。
予測可能性を最適化してリスクを制御するためにProject Sprintでは、定例ミーティングで環境に対する認識を常に揃えなおしながら反復的かつ漸進的にプロジェクトを進めるというアプローチを採用しています。プロジェクトにおける取り組みについて定期的な振り返りと改善を繰り返しながら、ゴールに至るまでの道筋を少しずつクリアにするとともにチームが自律的に学習し成長することを目指します。
## 経験主義を支える「透明性」「検査」「適応」
経験主義においては、「透明性」「検査」「適応」という三つの柱の実現が重要であるとされています。Project Sprintではこれらを、以下のように解釈しています。
**透明性**：\
創発的な取り組み過程や作業は、作業を実行する人とその作業を受け取る人にとって可視化されている必要があります。透明性とは、この可視化が標準化され、共通理解が持たれているということです。重要な意思決定は作成物をどのように認知するかに大きく左右されます。作成物の透明性が低いと、リスクを高める意思決定につながってしまう可能性があります。
**検査**：\
成果物や合意されたマイルストーンに向けた進捗状況は、頻繁かつ熱心に検査される必要があります。潜在的な望ましくない変化や問題を検知するためです。定例ミーティングは変化を引き起こすように設計されており、この変化により問題を検知しやすくなります。\
透明性の実現により、検査が可能になります。透明性が実現されていない状態での検査は、誤解を招く無駄なものになってしまいます。
**適応**：\
取り組み過程の何らかの側面が許容範囲を逸脱していたり、達成すべきものとして設定されたマイルストーンが受け入れがたい場合には、現在適用されている取り組み過程やマイルストーンの構成要素を調整する必要があります。逸脱を最小限に抑えるため、この調整はできるだけ速やかに行われなくてはなりません。\
関係者に権限が与えられていないときや、自己管理がなされていないときは、この適応が難しくなります。
## チームの価値基準
スクラムガイドでは、チームが成功するかどうかは、次の5つの価値基準を実践できるかどうかにかかっているとされており、Project Sprintもこれに共感しています。これらの価値基準は、チームの作業・行動・振る舞いの方向性を示しています。
**確約(Commitment)**： チームは、ゴールを達成し、お互いにサポートすることを確約します。
**集中(Focus)**： チームは、ゴールに向けて可能な限り進捗できるように、スプリントの作業に集中します。
**公開(Openness)**： チームとステークホルダーは、作業や課題を公開します。
**尊敬(Respect)**： チームのメンバーは、お互いに能力のある独立した個人として尊敬し、一緒に働く人たちからも同じように尊敬されます。
**勇気(Courage)**： チームのメンバーは、正しいことをする勇気や困難な問題に取り組む勇気を持ちます。
チームのメンバーは、定例ミーティングや作成物を用いながら、これらの価値基準を学習し探求します。これらの価値基準がチームや一緒に働く人たちによって具現化されるとき、経験主義が効果を発揮し、信頼が構築されるのです。
# 継続的改善アプローチ
Project Sprintでは、ミーティングを通じて継続的にプロジェクトの進め方を改善すること（最適化）を目指しています。これらの最適化のための取り組みを総称して「継続的改善アプローチ」と呼んでおり、これはさらに「振り返り」「テンショントリアージ」「ロールセッション」という三つの取り組みに分けられます。プロジェクトの状態やタイミングに適した手法を使うことで、様々な問題や違和感を発見しやすくなります。
## **継続的改善アプローチとは**
継続的改善アプローチは、今後のプロジェクトをよりよい状態にするべく継続的に改善しつづけるための仕組みです。この仕組みを通じてプロジェクトの進捗状況の共有のみならず、プロジェクトの進め方の継続的な改善ができるようになります。マイルストーンの開始時や終了時といった区切りのタイミングだけでなく、定期的にアクションを実施することが重要です。
代表的なアクションとしては「定期的に振り返りを実施して、プロジェクトをよりよい状態にするための改善策を検討する」ということになりますが、実施する視点によって考え方や最適なアプローチも変わってきますので、以下ではそれらについて記載します。
## **いつを見るか**
継続的改善アプローチの中では、\*\*「過去」・「現在」・「未来」\*\*の3つの視点でものごとを捉えます。一般的に「振り返り」といえば「過去」を見るものですが、Project Sprintの継続的改善アプローチでは、「過去」だけではなく「現在」や「未来」にも目を向けることが重要と考えています。
### **なぜ「現在」を見るのか**
「過去」だけではなく「現在」を見るのは、プロジェクトチームのメンバーが今どのような心境なのか（気になっていることや困っていることがないか）をリアルタイムに共有することが、チームの状況を改善していくために不可欠であると考えているからです。
これが「過去」を見る振り返りだけであるならば、問題が共有されるのはその問題が起こってしまった後である可能性が高いのですが、「現在」を見ることで、問題が顕在化もしくは拡大する前に共有し対処することができるようになります。
そのため、Project Sprintでは、定例ミーティングの中でのテンションの共有という形で、定期的に現在の心境を出し合うことを推奨しています。
### **なぜ「未来」を見るのか**
一方、「未来」を見て改善をするのは、実施しようとしているプラン自体を改善してプランの精度を高めていくためです。
リスクマネジメント的視点ではありますが、重要なのは「想定しているプランを実行したら、何が起こるだろうか」という仮想経験を共有することです。それによって、仮に失敗しそうであれば事前にプランを改善することができ、プランそのものの質を高めることができます。また、仮にプランそのものに問題がない場合も、一度仮想的に経験をしているので、実際に実施する際に余裕を持って対応することができます。
「未来」を見て改善するアプローチの1つとして、「プレモータム・シンキング」と呼ばれるものがあります。これは、日本語に訳すと「事前検死」というもので、これから取り組んでいくプロジェクトが失敗したと仮定して、その失敗要因を分析したり、解決策を検討するというアプローチです。ビジネスにおいては、「早く失敗すること」の重要性がよく指摘されますが、プレモータム・シンキングは最も早く失敗を体験できるものであり、その意味でも有効な1つの手法といえます。
### **現在の気持ちを共有することの重要性**
プロジェクトを改善していく上で、このように「過去」「現在」「未来」を見ることはいずれも重要ではありますが、中でも重要なのは「現在」の気持ちを共有することだと考えています。 気持ちを吐き出すことができる場があることで、前述のようにプロジェクトの課題が改善されるだけでなく、メンバーのプロジェクトへの参加感の向上にもつながるものです。
## **何を見るか**
では、「過去」「現在」「未来」について、具体的に何を見るとよいでしょうか。 [Project Sprint 101](https://github.com/copilot-jp/project-sprint/blob/master/JA/v3.3/theories/broken-reference/README.md)でも記載しているように、Project Sprintでは単にプロジェクトの進捗を見るのではなく、プログレスやチーミングが理想の状態にあるかどうか、またプロセスが円滑に機能しているかどうかがプロジェクトを進めていく上で重要な要素と考えており、継続的改善アプローチでも、これらを検証することを推奨しています。
以上、「いつを見るか」ということと「何を見るか」という視点をかけ合わせると、それぞれの項目において想定される基本的な問いは下表のような事項になります。 これは基本形ですので、各プロジェクトにおいて必要な問いそのものを定義した上で、そのプロジェクトにとって必要な検証・改善が行われる状態を構築していきましょう。
| 視点 | 過去 | 現在 | 未来 |
| ----- | ---------------------------------------------------------- | --------------------------------------------------------------- | ----------------------------------------------- |
| プログレス | ・マイルストーンを達成できたか？
・最終的な成果に繋がるアウトプットを積み重ねることができたか？
| ・今アウトプットすべきものを理解・納得しているか？
・アウトプットすべきものについて不安や心配事はないか？
| ・ゴールを達成できそうか？
・もし失敗するとしたら、何が原因になりそうか？
|
| チーミング | ・メンバー相互の期待値は明確だったか？ | ・メンバー相互の期待値に違和感はないか？ | ・今の期待値のままプロジェクトを進めたら、将来的にどうなるだろうか？ |
| プロセス | ・プロジェクトやミーティングの進め方はどうだったか？ | ・プロジェクトやミーティングの進め方に違和感はないか？ | ・今の進め方を継続したら、将来的にどうなるだろうか？ |
# Project Sprintの成功指標
Project Sprintは、チームが
* プログレスにおける理想の状態
* チーミングにおける理想の状態
を目指しながらプロジェクトゴールに向かって進んでいくのを助けるために、ものごとの捉え方・考え方や、最適化を促進するための仕組みを提供しています。
したがって、Project Sprintが成功しているかどうかは、プログレスとチーミングにおいて理想の状態が実現しているか、という観点で評価することができます。
ここで、いずれの成功についても、絶対的に到達すべき状態はないということに注意しなければなりません。プロジェクトゴールは変化しうるものであり、また何をもって理想的なチームとするかはプロジェクトの規模や時間軸などに依存します。
一方、Project Sprintが正しく導入・運営されていれば、それは理想の状態が実現されているということを意味します。そのため、Project Sprint自体の活発さをもって成功指標とみなすことができます。
したがって、成功指標は次の3つと言えます。
* タスクがリストアップされ、遂行されているか
* タスクを遂行する中で発見された問題点やテンションが、ミーティングにおけるアジェンダアイテムとしてリストアップされ、議論・意思決定されているか
* ミーティングにおける議論・意思決定の結果が、次にやるべきこととしてタスクに落とし込まれているか
# Practices
このドキュメント群では、Project Sprintの基本的な概念の説明と実践方法が順を追って説明されます。理論編であるTheories及び実践編であるPracticesから成り、それぞれを上から順番に読み進めていくことで、Project Sprintを概念として理解した上で、実際のプロジェクトに取り入れて使うための知識を得ることができるようになっています。
すでにプロジェクトマネジメントの経験がある方が新しい方法論としてProject Sprintをインプットするために読むことはもちろん、すでにProject Sprintを導入している方も、効果的な活用のための基盤固めとして読むことができます。
| Contents | Theories | Practices |
| ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Project Sprint 101 | [Project Sprint 101](/ja/v3.2/theories/101) | WIP |
| プロジェクトライフサイクル | [5つのサイクル](/ja/v3.3/theories/project_lifecycle) | WIP |
| プロジェクトゴールとマイルストーン | プロジェクトゴールとは
マイルストーンとは
制約・イベント
| プロジェクトゴールの設定
マイルストーンの設定
プロジェクトゴールとマイルストーンの見直し
|
| トラック | [トラックとは](/ja/v3.3/theories/tracks) | [トラックの設定](/ja/v3.3/practices/tracks) |
| 期待値とロール | [期待値とロール](/ja/v3.2/theories/rolls) | チームメンバーの理解とロールシートの利用
ロールの確認
|
| 定例ミーティング | [定例ミーティングの重要性](/ja/v3.3/theories/meetings) | ミーティングの設計
ミーティングの進行方法
タスクの設定
ミーティングロールの確認
ミーティング環境についてのノウハウ
|
| アジェンダ | [アジェンダとは](/ja/v3.3/theories/agenda) | [アジェンダアイテムの要素](/ja/v3.2/practices/agenda) |
| プロジェクトの環境整備 | [プロジェクトの環境整備実現したい状態と価値基準](/ja/v3.3/theories/project_environments) | 情報共有環境の構築
スタンドアップの導入
|
| 継続的改善アプローチ | [継続的改善アプローチ](/ja/v3.2/theories/continuous_improvement_approach) | 振り返り
テンショントリアージ
ロールセッション
|
| Project Sprintの成功指標 | [Project Sprintの成功指標](/ja/v3.1/tutorial/section4-4) | - |
| Project Sprintの発展 | - | [コントリビューターとしての参加の方法](https://github.com/copilot-jp/project-sprint/blob/master/JA/v3.3/practices/broken-reference/README.md) |
# プロジェクトゴールの設定
## プロジェクトゴールの設定
プロジェクトチームが目指すのはプロジェクトゴールを達成することですから、まずはこれを定義する必要があります。これからあなたが取り組むプロジェクトは、何を目指しているのでしょうか？新規事業のコンセプトを開発して、新しい価値を創出することでしょうか。それとも、システムの効率化など、決まった価値を実現するために取り組むことでしょうか。いずれにせよ、プロジェクトで目指すこと = プロジェクトゴール を明確にしましょう。
プロジェクトゴールは、プロジェクトチームが主体的に0から設定することができる場合もあれば、プロジェクトの外部で設定されたものが与えられることもあります。外部から与えられたものである場合には、それをそのままプロジェクトゴールとして置くのではなく、まずはプロジェクトチームとしてそのプロジェクトゴールが明確で納得感のあるものかどうかを確認し、必要に応じて調整を加えます。
チームメンバー間の相互理解やプロジェクトに対する認識合わせが一定程度進んでいるプロジェクトであれば、すんなりとプロジェクトゴールを設定し、続けてトラックやマイルストーンの設定などプロジェクトに関する具体的な議論を展開しはじめられるでしょう。一方、いきなりプロジェクトゴールの設定に取り組むことが難しい場合、まずはミーティングを設定して議論することから始めます。
具体的なステップは以下のようになります。
### 1. 認識を合わせてはじめてチームになる
プロジェクトは、最初からプロジェクトゴールや目的が明確な状態で立ち上がるのではなく、緩やかな方向性が示されたり外部からプロジェクトゴールの原型を提示されたりしてスタートすることがほとんどです。メンバーが最初に集まった時点で、プロジェクトゴールやプロジェクトの範囲・内容が適切に共有されていることはありえません。仮に各メンバーが自分なりの理解をしていたとしても、他のメンバーとの認識の擦り合わせができていないからです。
全く面識のないメンバーが集められてプロジェクトが始まるとき、プロジェクトの範囲・内容に対する共通認識ができていない段階では、まず「なぜこのメンバーがここに集まっているのか」の認識合わせから始めなくてはいけません。ミーティングを設定してそれぞれのメンバーがプロジェクトの目的をどう認識しているかを話し合い、擦り合わせを行います。
はじめのうちは、プロジェクトそのものやプロジェクトの目的に対する現状認識をメンバーそれぞれが言語化して書き出してみる、というような形で構いません。それらを擦り合わせているうちに個々人の認識が変わることもあるでしょうし、一度プロジェクトゴールが設定されてプロジェクトが開始されてからも、環境の変化に応じてチームとして認識を揃えなおすことは重要です。
また、集まったメンバーで何ができるのかを把握する必要があります。メンバーそれぞれが自分自身のバックグラウンドやスキルセットを開示し、どういった展望を持ってこのプロジェクトに向き合おうとしているかを話し合いましょう。[期待値とロール](https://github.com/copilot-jp/project-sprint/blob/master/JA/v3.2/theory/rolls.md)や[チームメンバーの理解とロールシートの利用](/ja/v3.3/practices/rolls)も参考にしてください。
ここまでの認識が揃ってはじめて、集まったメンバーは「プロジェクトチーム」を目指すチームとして歩き始めることができるようになります。
### 2. 共通のプロジェクトゴールを目指すプロジェクトチームになる
次に行うのは、目指すべきプロジェクトゴールを定義するためのミーティングです。さらに時間を取った検討が必要な場合は、この工程を「プロジェクトゴールを作ること」そのものをゴールとする事前プロジェクトと捉えてもよいでしょう。このときは、プロジェクトを取り巻く基本情報（プロジェクトの背景・事業に関する予備知識・制約やイベント）の収集をマイルストーンとし、プロジェクトゴールを明文化することを目指します。
プロジェクトチーム全員で話し合いながらプロジェクトゴールを作っていくのが理想ではありますが、実際には、まず全員で発散的に意見を出し合ったのち、誰かがその内容を取りまとめて明文化する、という流れを辿ることが多いでしょう。最終的な内容は、改めて全員の納得が得られている状態である必要があります。
プロジェクトゴールは、プロジェクトチームの合意と納得によって定義され、プロジェクトチームとして認識が揃ったものでなくてはなりません。プロジェクトチームの意思が適切に反映され共通認識を得た明確なプロジェクトゴールが設定されることで、各メンバーはその達成に現実味と納得感を持ってプロジェクトに参画できるようになります。こうしてチームは、共通のプロジェクトゴールを目指す「プロジェクトチーム」と呼べるようになります。
## 設定後の扱い
設定したプロジェクトゴールは、チームメンバーがいつでも参照できる状態にしておきます。こうすることで、チームメンバーがプロジェクト中にタスクを実行する際やチームメンバー間で議論を行う際に、プロジェクトゴールへの認識がずれていないかすぐに確認することができるようになります。
また、プロジェクトゴールはプロジェクトを取り巻く環境の変化や実際にタスクを遂行する中で分かってきたことを踏まえて、プロジェクト中にいつでも変更することが可能です。ただし、変更についてプロジェクトチームで納得することが必要です。
実際の変更の流れは[プロジェクトゴールとマイルストーンの見直し](/ja/v3.2/practices/reviewing_project_goals_and_milestones)で解説します。
# マイルストーンの設定
## マイルストーンの設定
トラックが設定できたら、続いてマイルストーンを設定しましょう。マイルストーンも[プロジェクトゴールの設定](/ja/v3.2/practices/project_goals)と同様、当該トラックの推進を担うメンバー全員で話し合いながら作っていくのが理想です。ただしこれも実際には、最初は全員で発散的に意見を出し合ったのち、誰かがその内容を取りまとめて明文化する、という流れを辿ることが多いものです。もちろん、最終的には全員が納得している状態になっている必要があります。そのため、全員が理解しやすいように、極力シンプルなものになるよう心掛けてください。
制約やイベントを意識しながら、「いつまでにどのような作成物が必要か/どういう状態になっている必要があるか」がある程度具体的にイメージできる場合には、プロジェクトゴールを見据えながらバックキャストでマイルストーンを設定していきます。具体的なイメージがまだ持ちにくい場合には、まず取り組めるところからフォアキャストでマイルストーンを設定することになります。
マイルストーンがうまく設定できないときは、トラックの設定やプロジェクトゴールを見直す必要があるかもしれませんし、マイルストーン設定の前提となるチームメンバー同士の認識合わせがまだ十分でないのかもしれません。必要に応じて、前の工程に戻って議論をしましょう。
## マイルストーンの粒度・抽象度
各トラックの自律性を保つには、トラック間が疎結合である必要があります。そのため、マイルストーンを設定する際には、相互の依存関係・影響関係を判断できるような粒度・抽象度を意識しましょう。具体的には、あるトラックのマイルストーンの達成のために別のトラックのマイルストーンを調整することができたり、他のトラックを担っているメンバーが「あのトラックのマイルストーン達成のためにはこのようなアウトプットを提供してあげたほうがいいな」と自発的に提案できたりするような記述が理想です。
マイルストーンの粒度や抽象度は、プロジェクトゴールとの距離感によってばらつきが出てもかまいません。通常、直近のマイルストーンは期日・作成物ともに具体的なものになり、プロジェクトゴールに近いものほど抽象的で大まかな記載になります。ただし、マイルストーンを見たチームメンバーがそれぞれ自分で意思決定をして行動できる程度には、具体性のあるものである必要があります。そのマイルストーンに直接関わっているメンバーが理解できることはもちろん、直接関わっていないメンバーが見たときにもそれに応じて自身で必要な行動を取れるようなものにしてください。また、プロジェクト外のステークホルダー（例えば、プロジェクトの結果を報告するべき人や、プロジェクトの結果を受けて業務に影響が出る人）が客観的に見たときに、何を作成物として作ろうとしているのかすんなり理解できるかどうかも、適切なマイルストーン設定のための一つの判断基準になるでしょう。
## 設定後の扱い
設定したマイルストーンは、チームメンバーがいつでも参照できる状態にしておきます。こうすることで、チームメンバーがプロジェクトの進行中にタスクを実行する際やチームメンバー間で議論を行う際にマイルストーンやその先のプロジェクトゴールを常に意識し、認識がずれていないかすぐに確認することができるようになります。
また、マイルストーンはプロジェクトを取り巻く環境の変化や実際にタスクを遂行する中で分かってきたことを踏まえて、プロジェクト中にいつでも変更することが可能です。ただし、変更についてプロジェクトチームで納得することが必要です。
実際の変更の流れは[プロジェクトゴールとマイルストーンの見直し](/ja/v3.2/practices/reviewing_project_goals_and_milestones)で解説します。
### マイルストーンマップの利用
マイルストーンを共有し参照可能にしておくためのツールとして、「マイルストーンマップ」を利用することをおすすめします。
マイルストーンマップとは、プロジェクト内のマイルストーンの全体像を把握するためのシートのことです。あるべき姿や状態を分かりやすくシンプルに表現することで、チームメンバー全員が共通認識を持てるようになります。また、複数のマイルストーンを横断的に記載することで、マイルストーン間の関係や設定の背景を含めたより深い理解を可能にします。
マイルストーンマップには次のような要素を、ゴールまでのマイルストーン全体を俯瞰して見られるような形で盛り込みます。各要素はプロジェクトの変化に応じて常に更新し、形骸化させないことが重要です。
* ステージ名: マイルストーン達成までの期間の意味的な位置づけ（このステージで実際に何をするのかを分かりやすく記載する）
* 期日の開始日: 通常は直前のマイルストーン終了日の翌日
* 期日の終了日（必須）: マイルストーン完了の期日
* 作成物（必須）: マイルストーン完了時に出力されていなくてはならない作成物
* 達成したい状態: マイルストーン完了時点でプロジェクト内部がどのような状態になっていてほしいか、またはプロジェクトの作成物を受けてプロジェクトの外部がどのような状態になっていてほしいか、といったあるべき姿や理想の状態を記述
* 達成の基準・目標値：どうなっていればマイルストーン達成と言えるかを具体的に記述
* メモ: 補足情報を自由に記載する
### マイルストーンマップの具体的な記入要素と入力内容サンプル
例えば「ある問題を解決できる新規サービスを立ち上げる」というゴールを持ったプロジェクトがあり、このためにいくつかのマイルストーンを設定した場合、マイルストーンマップを表形式で作成すると以下のようになります。
| マイルストーン | 顧客の定義とリスト化の完了 | 必要な機能の検討完了 | リリースのための環境整備 |
| ------- | --------------------------- | -------------------------------------------- | ---------------------------------------- |
| 期間 | 6/1〜6/30 | 7/1〜8/31 | 9/15〜11/14 |
| ステージ名 | 【調査】顧客の存在を確かめる | 【企画】このサービスで問題を解決できるか確かめる | 【実現】市場価値があるサービスか確かめる |
| 作成物 | ・顧客定義シート
・顧客リスト
| ・UXマップ
・サービス機能リスト
・顧客ヒアリング（5人分）
| ・クラウドファンディング実験結果まとめ
・ユーザーアンケート
|
| 達成したい状態 | ・顧客に今回の問題があることをメンバーが確信できている | ・問題解決のために必要な機能が把握できている | ・このサービスの市場価値に定量的な根拠がある |
| 達成の基準 | ・どこに顧客が存在するのかわかっている | ・リリースに含めるべき最低限の機能が特定できている | ・次のステップとしてリリースできる機能の範囲が決まっている |
| メモ | | | |
# プロジェクトゴールとマイルストーンの見直し
[プロジェクトゴールの設定](/ja/v3.2/practices/project_goals)でも述べたように、プロジェクトゴールやマイルストーンは固定的なものではなく、むしろ環境の変化に応じて柔軟に書き換えられたり進化したりしうるものなので、いつでも見直してよく、また必要に応じて見直さねばならないものです。市場環境の悪化や組織の体制変更、稟議スケジュールの変更といったプロジェクトの外部環境の変化によって調整が必要になることもあれば、プロジェクトを進める中で得られた洞察やチームメンバーの共通認識・役割期待の遷移といった内部的な変化によって進化することもあります。
## 見直しが必要となる具体的な場合
プロジェクトのゴールの見直しをするべきタイミングは、次のようなときです。
1. 外部環境の変化やプロジェクトの進行の結果、プロジェクトゴールそのものを見直したほうが良いことが分かったとき
2. マイルストーンが予定通りに達成されなかった結果、プロジェクトゴールを見直したほうが良いことがわかったとき
3. その他何らかの理由でチームメンバーがプロジェクトゴールを見直したほうがよいと考えたとき
マイルストーンに関しては、プロジェクトゴールよりも頻繁に見直しが必要となることがあるでしょう。見直しをするべきタイミングは、次のようなときです。
1. あるマイルストーンが達成されたとき
2. あるマイルストーンが予定通りに達成されないことが明らかになったとき（予定よりも遅い場合、早い場合のいずれも含む）
3. プロジェクトゴールに対してあるマイルストーンが適切ではないことが明らかになったとき
4. プロジェクトゴールが変わったためマイルストーンも変える必要が出てきたとき
5. その他何らかの理由でチームメンバーがマイルストーンを見直したほうがよいと考えたとき
## 見直しの手順
プロジェクト内外の環境は絶えず変化し続けているので、それに対応するためには、とにかく定期的にプロジェクトゴールとマイルストーンを見直し、現状に即していないところや違和感のある所がないかを確認することが重要です。プロジェクトゴールやマイルストーンは、全員が集まる場で見直しや調整を繰り返し、違和感を抱くメンバーがいれば納得いくまで議論することで、チームメンバー全員が共通認識と納得感を持てる状態にしていく必要があります。
プロジェクトゴールやマイルストーンの見直しの実施についてもミーティングのアジェンダアイテムとなるため、事前にアジェンダアイテムの提出を行う必要があります。
プロジェクトゴールやマイルストーンを変更する際には、変更の前後を並べて見せるなど、その差分を明確にし、積極的に共有するようにしてください。これは、「知らない間にプロジェクトゴールやマイルストーンが変わっていた」と感じるメンバーが出てきてしまわないようにするためです。
プロジェクトゴールやマイルストーンはプロジェクトにおけるあらゆる場面で参照され、チームメンバーにとって指針となるべきものです。そのため、変更後のプロジェクトゴールやマイルストーンにもチームメンバー全員が確実に納得できている状態を作ってください。
# トラックの設定
## 1. プロジェクトゴールに対する認識を揃える
[プロジェクトゴールの設定](/ja/v3.2/practices/project_goals)や、[マイルストーンの設定](https://github.com/copilot-jp/project-sprint/blob/master/JA/v3.3/practices/broken-reference/README.md)を参考に、まずはプロジェクトの目的やプロジェクトゴールを明確化し、チームメンバー間での共通認識にします。
## 2. メインのトラックを設定する
プロジェクト全体・プロジェクトチーム全体の主な状態を把握するトラックを、メインのトラックとして設定します。このトラックには、プロジェクトゴールの達成のために必要な大きなマイルストーンと、プロジェクト全体に関わるアイデアの共創や問題の共同解決のために必要な定例ミーティングの両方が入力されることが多いでしょう。プロジェクトメンバーによる定例ミーティングを設定し、このトラックだけでなくプロジェクト全体のマイルストーンマップを毎週確認できるようにしておきましょう。
メインのトラックにおけるマイルストーンとステップは、外部制約や主要なイベントなどに応じて設定していくのがふつうですが、そういったものが明確に存在しない場合は、3か月ごとなどの定期的なタイミングでステップを区切ってマイルストーンを設定します。たとえば何らかのサービスを立ち上げるようなプロジェクトであれば、各ステップごとに顧客に対して提供したい価値を記述するのもよいでしょう。
各ステップの終点となるマイルストーンの成果物・あるべき姿には、提供したい価値・バリューを、具体的な作成物や数値目標、達成したい状態などに落とし込んで記載しましょう。メインのトラックのマイルストーンは、このあと設定される各トラックにおけるマイルストーン達成の集積によって達成されてゆくという構造になります。そのため、メインのトラックのマイルストーンを参照することで、このあと作成する各トラックのメンバーが自律的に各トラックのマイルストーンを決定できるような内容が書いてあることが望ましいです。
メインのトラックのマイルストーンを設定するときには、「各トラックの成果物の仕上がりが合わさる、または仕上がりを合わせたい具体的なタイミングはいつか」というところから考えてみるとイメージしやすくなるかもしれません。
## 3. メインのトラックの他に必要なトラックを設定する
メインのトラックのマイルストーンを達成するために必要なものを部分部分に分割して、その他のトラックを作っていきます。
基本的には、トラック同士は依存関係が少ない疎結合な状態になるように分割します。つまり、個々のトラックだけで自律して作業を進められるような分け方です。こういった分け方ができず、強い依存関係のあるタスクベースで進捗をコントロールする必要がある場合には、別途ガントチャートを作って把握するのがよいでしょう。
各トラックで個別にミーティングが必要な場合や、各トラックで個別にチームになった場合は定例ミーティングを置きますが、それぞれのトラックには必ずしも定例ミーティングを設定する必要はありません。
また、各トラックは原則として疎結合なものとして存在しますが、進捗状況の共有やマイルストーンの詳細な確認などを目的として、トラック間での連携やトラックを横断したミーティングを置くこともあります。このときは、連携が必要となるトラックの上部構造として、連携用のミーティングを置くトラックを設定するとよいでしょう。
# チームメンバーの理解とロールシートの利用
## チームメンバーの基本情報
より良いチームを目指す前提となるのが、チームメンバーに関する理解です。例えば、プロジェクトに関わるメンバーに次のことを確認しておきましょう。
* あなたの名前はなんですか？普段はどのような組織や会社に所属している人ですか？
* あなたはどのような人ですか？例えばスキルセットはどのようなものがありますか？これまでにどのような仕事にかかわってきましたか？
* あなたがこのプロジェクトに対して貢献を期待されていることはなんですか？
* あなたはプロジェクトに対する専任メンバーですか、兼任メンバーですか？いずれにせよ、あなたがこのプロジェクトに割ける時間はどのくらいですか？
こうしたことをプロジェクトの最初に知っておくことは、ロールの設定における助けになります。
## ロールシートの利用
ロールとチームメンバーは一対一の関係になるとは限らず、またロールの種類も決まったものはない一方、決まったロールはきちんと明文化して合意する必要があります。
そのため、「いまのロールの状況」を明文化して参照できる状態にしておくための「ロールシート」を利用することをおすすめします。
ロールシートには、例えば次のような要素を盛り込みます。
* ロール名
* ロールが果たす責任(どういう目的でそのロールが必要とされ、何を果たすロールなのか）
* そのロールを担う人
これらを一つのドキュメントとしてまとめ、常に最新のものに更新しておくことで、いまの各メンバーに対する期待値を把握することや、期待とズレがあった場合の議論が可能になります。
# ロールの確認
ロールも、プロジェクトゴールやマイルストーンと同様、変化しうるものです。定例ミーティングとそこでのアジェンダの議論を通して、ロールは常に見直され、改めて認識合わせが行われることになります。
## ロールの確認
[期待値とロール](/ja/v3.3/theories/rolls)でも述べたように、自律的なチームであるためには、チームメンバー各々の責任・役割が共有されて認識が揃っており、メンバー相互の期待値に齟齬がないことが重要です。
チーミングの「理想の状態」には、明確な到達点がありません。なぜなら「ここまで達成したら理想のチームだ！」というものが決めにくいからです。そこでProject Sprintでは、常に「チームが今の時点より良い状態になること」を目指します。 そして、ここでの「より良い」とは、チームメンバー同士の果たすべき役割=ロールについての期待値がそろっている状態のことを指します。つまりロールの確認とは、チームメンバーの持つ互いの役割についての期待値がそろっているかを確認することを指します。
ロールの確認をするべきタイミングは、次のような時です。
1. 過去に定義されたロールが、より詳細にブレイクダウンして考えられるようになり、細かい認識合わせが必要になったとき
2. プロジェクトの進行により過去に定義していないような役割が生まれ、その役割を担うロールを明確化することが必要だと考えられるようになったとき
3. 過去に定義されてあるメンバーにアサインされていたロールが、周囲からの期待に添っていないとき。例えば、実際にはアサインされているメンバーとは別のメンバーがロールを遂行していたり、アサインされたメンバーが周囲からの期待値を満たしきれていなかったり、逆にアサインされたメンバーが自分は周囲からの期待値を満たせていないと感じていたりするとき
4. その他何らかの理由でチームメンバーがロールの確認をしたほうがよいと考えたとき
ロール確認の実施はミーティングのアジェンダアイテムとして扱われるので、確認が必要だと考える場合には事前にアジェンダアイテムの提出を行う必要があります。
## 明示ロールと暗黙ロール
Project Sprintでは、ミーティングロール以外には必ず設定しなければならないロールというものを決めておらず、それ以外のロールの定義についてはチームメンバーで合意することのみが必要な条件となっています。
しかし、この「チームメンバーの合意」は、必ずしも明示的なものとは限りません。チームで名前を決めて共有されるロールもある一方、プロジェクトを進めていくなかで、あるメンバーが自然に担っていく暗黙的な役割もあります。Project Sprintにおいて、前者は「明示ロール」と呼ばれ、後者は「暗黙ロール」と呼ばれます。
これらの区別は絶対的なものではなく、ある暗黙ロールが、何かのきっかけによって明示ロールとなることもありえます。
例えば、最初から暗黙ロールが十分に機能することはほとんどありません。つまり、「あの人がこれをやってくれるだろう」という阿吽の呼吸・暗黙の了解は、チーム発足初期にはあまり機能しないということです。多くの場合こうした暗黙ロールは一度「この人はこういう役割の人だ」という明示ロールとして表現され、この過程で期待値のすり合わせが行われます。その後、「あの人はこういう役割の人だからこれもやってくれるだろう」と、暗黙ロールも機能し始めるのです。チームメンバーの互いの期待値が合ってくると、未知の状況にも柔軟に対応できるようになります。
なお、暗黙ロールと明示ロールの割合はプロジェクトやチームによって異なるもので、最適なバランスもそれぞれ異なります。また、単純にロールの数が多いほうがよい、少ないほうがよい、といった点についても、一律の答えはありません。
ただし、ロールは次のような状態になっていることが望ましいとされます。
* チームメンバー間で、ロールの中でやるべきことがより細かい粒度で理解されているほどよい。
* そのチームにとって最もコストのかからない方法で、チームにとって必要十分なロールが共有されているほどよい。
* 各ロールのやるべきことをお互いにフォローできればできるほどよい。
# ミーティングの設計
[定例ミーティングの重要性](/ja/v3.3/theories/meetings)で記述した通り、ミーティングは定期的・反復的に開催される必要があります。
ミーティングに目的や完了の定義が明確に存在しうることもありますが、基本的にはミーティングは目的も到達すべき地点も持たず、その時々のアジェンダアイテムが投入されていく連続した箱のようなものと捉えるのがよいでしょう。ミーティングで議論すべきアジェンダの内容や性質は常に異なるため、どのようなアジェンダでも自由に提案できるよう、なるべく縛りを設けないでおくのです。
## 開催頻度
ミーティングの開催頻度は、週次/月次/隔週など、プロジェクトの性質やチームメンバーの人数などを勘案して任意に決めてください。ただし、Project Sprintの基本のメカニズムが「定期的・反復的なミーティングで各メンバーの取り組みの成果や作成物を共有し環境に対する認識を揃えることによって、各メンバーが同じプロジェクトゴールを目指して自律的に各自の次の行動に向かうことができるようにする。この繰り返しがプロジェクトを現在の状態から理想の状態に漸進的に近づけ、結果としてプロジェクトゴールが達成される。」であることを考えると、隔月以上の間隔でのミーティング開催は考えにくいでしょう。
## 参加者
各ミーティングの参加者はアジェンダに応じて必要十分な程度でかまいません。ここでいう必要十分とは、アジェンダに関して網羅的に議論でき（＝「誰かがいないから今日はこの話ができないね」ということがないようにする）、また議論をもとに正式な意思決定ができること（＝「誰かがいないから今日はこの話は決まらないね」ということがないようにする）を意味しています。もし参加人数が大人数(10人を一つの目安としてください）になっている場合は、必要以上の人数を集めていないか、確認してください。もしそうなってしまっている場合、アジェンダの議論と意思決定を目的としたミーティングではなく、単なる情報共有を目的とした会議になっている可能性があります。
とはいえ、ミーティングでは多様なアジェンダが提出される可能性があるので、最初にミーティングを設計する際には、あらかじめチームメンバー全員が集まることのできるミーティングを設定したほうがいい場合も多いでしょう。そうすることで、チームメンバー個々人の中にとどまっている情報を一斉に共有することができ、各チームメンバーはこのプロセスに参加するだけでプロジェクトの状況や思っていることについて自然と認識を合わせることができるようになります。
さらに、参加者が漏れなく参加でき、情報をリアルタイムに共有できるようなミーティング環境を整備するようにしてください。これは、前述の素早く効率的な認識合わせを実現するために重要なポイントとなります。具体的には、場所を問わず参加できるリモートミーティング環境の準備、その場で決まったことを共有できるドキュメントシェアサービスの利用、などを行うことになるでしょう。
## 定例ミーティングの要素
定例ミーティングを最適な状態で実施するには、会議のアジェンダの設定やファシリテーションの方法など、会議環境を整備しておく必要があります。具体的には、プロジェクトの内容やフェーズに応じて下記のような項目についてメンバー間で合意しておきましょう。
* ミーティンググランドルール
* ファシリテーション方法
* ミーティングでのメンバーの役割
* アジェンダパターン
* アジェンダの活用方法
* 議事録の活用方法
* 継続的改善アプローチの導入
# ミーティングの進行方法
## ミーティングの基本構成
この記事では、Project Sprintで行われるミーティングの基本となる進行方法を説明していきます。おおまかな構成としては次のようになっているので、これをまずはじめに頭に入れておくと、それぞれの内容を理解しやすいでしょう。
* 序盤：タスクの進捗報告、テンショントリアージ、アジェンダトリアージ
* 中盤：個別のアジェンダアイテムの進行
* 終盤：今回のミーティングから生まれたタスクの確認と、次回以降のミーティングのアジェンダ確認
さらに、特にミーティングの序盤と終盤は定型化しやすく、時間がたつにつれ、具体的な方法論や必要な時間、細かい順番が定まってきます。チームにとって最適なミーティングの「型」を見つけましょう。
## ミーティング序盤
ミーティングの最初に、タスクの進捗報告とテンショントリアージを行ってください。これらを通じて、前回のミーティングから今回のミーティングまでに起こったことについて、チームメンバー同士でアップデートを行います。議論の結果は、その日のミーティングで話すことを決める材料になります。
なお、タスクの進捗報告とテンショントリアージはそれ自体がアジェンダアイテムです。したがって、後述するアジェンダトリアージの前に実施されるものではありますが、これらのアジェンダアイテムの進行についてもモデレーターが担当する必要があります。
### タスクの進捗報告
初回のミーティングを除けば、前回までのミーティングを経て、何かしらの各自のタスクが生まれているはずです。これらのタスクの進捗状況を確認しましょう。
タスクを遂行した結果なんらかの作業結果が生まれている場合には、それをもとに話し合うべきアジェンダアイテムがないか確認しましょう。 もし作業結果がなくても、作業が思うように進まないという相談もありうるでしょう。このような場合も、これを解決するためにアジェンダアイテムとしてミーティング内で議論する必要がないか確認しましょう。
なお、この場で挙げるのではなく、ミーティング前にアジェンダアイテムとして提出しておいても構いません。
### テンショントリアージ
テンションとは、「プロジェクトに取り組む中で生まれた、他のメンバーに伝えたい違和感」のことです。具体的には、メンバー個人が思う「こうしたらもっと良くなるのに」という現状とよりよい状態の間のギャップ、ちょっとしたアイデア・気になること・不安などのことを指します。またトリアージとは、選別と優先順位づけをする行為のことを指します。
すなわちテンショントリアージとは、個々のチームメンバーが感じている違和感を提案に変えて全員で共有したうえで、今チームを改善するために必要なものを優先的に選び、解決しようとすることです。テンションをあげた本人が、テンションを違和感の解消のための具体的な提案に変換し、本人にとって納得のいく解決策を決定することが大切です。
テンションは一人一人が組織内で自律的に動くための原動力となるものです。重要なのは一人一人がテンションを感知することと、感知したテンションを無視しないことです。それぞれが感知したテンションを自律的に処理することでチームが回り、プロジェクトゴールに近づいていくのです。
前述のように、テンションとは現状とよりよい状態のギャップから生まれるものです。そのため、テンショントリアージを行う際にプログレス及びチーミングの理想の状態や、プロジェクトゴール・マイルストーン、チームのロール）を参照できるようにしておくことが、テンションを挙げるために効果的です。
テンショントリアージで共有した内容は、解決のためのアクションに落とし込むようにしてください。具体的には、直接的な改善策が明確な場合、テンションを解決するための新たなタスクとしてください。また、直接的な改善策が明確でない場合や時間をかけた議論が必要な場合は、新たなアジェンダアイテムとして改善策を探すようにしてください。
なお、この場で挙げるのではなく、ミーティング前にアジェンダアイテムとして提出しておいても構いません。
具体的なテンショントリアージの方法は、[現在の心の声を活用する：テンショントリアージ](https://github.com/copilot-jp/project-sprint/blob/master/JA/v3.3/practices/broken-reference/README.md)で解説します。
## アジェンダトリアージ
続いて、アジェンダトリアージを行ってください。アジェンダトリアージには、ミーティングに出席しているチームメンバー全員が参加します。
トリアージとは、ここでも同じく選別と優先順位づけをする行為のことを指します。すなわちアジェンダトリアージとは、その日のミーティングで話したいことを参加者全員で出し合い、優先的に話し合うべきものを選ぶことです。
モデレーターは、アジェンダトリアージを主体的に進行し、最終的な合意まで持っていくことが求められます。
この時点で、2種類のアジェンダアイテムが用意されているはずです。
1. ミーティング前に提出のあったアジェンダアイテム
2. タスクの進捗報告またはテンショントリアージの結果、新たに生まれたアジェンダアイテム
アジェンダトリアージは、これらのアジェンダアイテムのうち、その日のミーティングで議論すべきものと議論する順番を決める作業です。プロジェクトゴールやマイルストーンを参照しながら、優先順位をつけていきましょう。
事前に提出されたアジェンダアイテムの内容に不明点があれば、チームメンバーはそれに対して納得できるように質問をしましょう。このとき、ファシリテーターにはこのアジェンダアイテムの改善に関する議論を活発にすることが求められます。
アジェンダアイテムの内容が明確になった結果、あらかじめ設定されていた所要時間だと余りそう、または逆に足りなそうである、と判明することがあります。このときは、アジェンダアイテムの所要時間を調整しましょう。
それぞれのアジェンダアイテムの内容が明確になったら、優先順位をつけましょう。マイルストーン達成のために必要なアジェンダアイテムから議論するのが基本です。直近のマイルストーンの内容と、その期限までに開催できるミーティングの回数を考慮しましょう。マイルストーンを参照した結果、個別のアジェンダアイテムの議論においてどのような結論まで持っていくべきかを調整することもあります。
なお、事前に提出されたアジェンダアイテム以外に、チームメンバーから見て緊急性が高いアジェンダアイテムがある場合には、チームメンバーの合意を得た上で、それらのアジェンダアイテムが優先されます。
優先順位をつけた結果、当日話し合うことができないアジェンダアイテムは、次回以降のミーティングに持ち越しましょう。こうしたアジェンダアイテムがあるとき、アジェンダトリアージは、次の3種類の中から優先順位づけをすることになります。
1. ミーティング前に提出のあったアジェンダアイテム
2. タスクの進捗報告またはテンショントリアージの結果、新たに生まれたアジェンダアイテム
3. 前週までの持ち越しアジェンダアイテム
当日話し合うことになったアジェンダアイテムは、元々の優先順位に従って議論してもかまいませんし、内容に応じて関連するテーマについて続けて議論できるように順番を並べ替えることもできます。並び替えを行うメリットは、関連しあうテーマ同士について続けて議論するほうが効率的であることです。
## ミーティング中盤
### 個別のアジェンダアイテムの消化
アジェンダトリアージが終われば、一つ一つのアジェンダアイテムについて議論しましょう。
一つ一つのアジェンダアイテムは、すでに記載されているアジェンダアイテムの内容に基づき、それぞれのアジェンダアイテムオーナーがメインで進行します。ファシリテーターは議論の内容と最終的な結論がより良くなるように議論に参加しましょう。レコーダーは、議論の経緯・内容をリアルタイムで記録し、参加者が常に見ることのできる状態にしましょう。
### アジェンダアイテムの取りまとめ
モデレーターは、アジェンダアイテムを取りまとめ、ミーティングを通して確認や調整を行います。ただし、以下で説明するアジェンダアイテムの確認や調整は、すべてチームメンバーと話し合いながら決めるべきものです。ここでも、直近のマイルストーン達成のためにはどのような選択が有効か、が基本的な判断基準となりますが、最終的にはチームメンバーの話し合いで出た結論が優先されます。
まず、それぞれのアジェンダアイテムが議論されている最中は、予定されている時間内にそのアジェンダアイテムが終わるように気を配ってください。
ただし、議論の内容に応じて、アジェンダアイテムが予定した時間より延長してしまったり、逆に早く終わってしまうことがあります。 アジェンダアイテムが予定した時間より延長している場合、モデレーターはそのアジェンダアイテムを次回に持ち越すようにするか、一定の結論が出るまで議論を続けるかを検討してください。
次回に持ち越す場合、このアジェンダアイテムは、前週までの持ち越しアジェンダアイテムの一つとして扱われます。これまでの過程でアジェンダアイテムの詳細はすでに完成しているはずですが、ここまでで議論した内容もあわせて把握するために、レコーダーが記録した内容も一緒に確認できるようにしておきましょう。
一定の結論が出るまで議論を続けることにしたときは、他のアジェンダアイテムの時間を短縮して調整するか、場合によっては他のアジェンダアイテムを次回以降のミーティングに繰り越すようにしてください。
アジェンダアイテムが予定よりも早く終わってしまった場合、他のアジェンダアイテムの時間を延ばして余裕を持って議論できるようにするか、次回以降に繰り越すようにしていたアジェンダアイテムからその時のミーティング中に先に話し合うべきものがないか、検討してください。また、ミーティングを早く終えることを選択するのも可能です。
また、あるアジェンダアイテムを議論した結果、新しく話し合うべき内容、つまり新たなアジェンダアイテムが生まれることがあります。このとき、当日の追加アジェンダアイテムとして扱うか、次回以降に持ち越すかを検討する必要があります。
当日の追加アジェンダアイテムとして扱うときは、以下のいずれかの対応を取ってください。
* 他のアジェンダアイテムの時間を短縮して調整する
* 他のアジェンダアイテムを次回以降に繰り越す
* ミーティングの参加者全員に確認して、ミーティングの時間を延長する
もしアジェンダアイテムの内容が明確な場合は当日の議論も可能ですが、そうでない場合は次回以降に持ち越すのがよいでしょう。次回以降に持ち越すときは、このアジェンダアイテムはミーティング前に提出のあったアジェンダアイテムの一つとして扱われます。
前週までの持ち越しアジェンダアイテムと違うのは、アジェンダアイテムの内容が明確になっていない点です。したがって、ミーティング中に生まれたアジェンダアイテムについては少なくともアジェンダアイテムオーナーを明確にした状態でミーティングを終えましょう。そして、アジェンダアイテムオーナーは次回のミーティング前にアジェンダアイテムの内容を明確にしておくようにしてください。
## ミーティング終盤
ミーティング終了時には、今回のミーティングから生まれたタスクの確認と、次回のミーティングアジェンダの確認を行ってください。これによって、今回のミーティングの結果と、次回のミーティングまでに何をするべきかを確認することができます。これらの作業の前提として、マイルストーンの確認を行うことも効果的です。これによって、次回のミーティングまでに何に対してどこまで取り組むべきかの優先順位付けをしやすくなります。
なお、これらの確認もそれ自体がアジェンダアイテムなので、モデレーターが担当する必要があります。
### 今回のミーティングから生まれたタスクの確認
今回のミーティングで取り上げたアジェンダアイテムの議論を経て、チームメンバーがやるべきこと、つまりタスクがいくつか生まれているはずです。レコーダーの記録をもとにして、生まれたタスクを確認し、リストアップしましょう。リストアップしたタスクには、具体的な行動内容、担当者、期限を明確にするようにしてください。
### 次回以降のミーティングのアジェンダ確認
実際にミーティングで取り上げるアジェンダアイテムが確定するのはミーティングの当日ですが、毎回のミーティングの終了時に、次回以降のミーティングで話し合うべきアジェンダアイテムについて議論しておきましょう。このようなアジェンダアイテムには例えば次のようなものがあります。
* 次回以降に持ち越しになったアジェンダアイテム
* 進捗確認など、あらかじめタイミングを決めて議論するべきとされるアジェンダアイテム
事前にチームメンバー全員で確認することで、アジェンダアイテムオーナーのアジェンダアイテム提出漏れや、持ち越したアジェンダアイテムの内容の不備を防ぎやすくなります。
# タスクの設定
Project Sprintには、ミーティング終盤にそのミーティングを通じて生まれたタスクの確認を行い、次回のミーティングの序盤でそれまでのタスクの進捗報告を行うというサイクルがあります。 [ミーティングを開催する](/ja/v3.2/practices/holding_meetings)で解説したように、タスクを記載する際には、
* 具体的な行動内容
* 担当者
* 期限
を明確にすることが最低限必要です。
しかし、これだけでは、タスクの進捗報告の際に「想定していたのと違った」「いつまでたっても完了しない」といったことが起こりえます。これは、タスクの担当者が何をやればよいかよくわかっていないことが原因であったり、そもそも担当者の設定や期限の設定が間違っていたりすることが原因です。そして、さらにその根本的な原因は、チームメンバ―の間で認識のずれがあり、正しくタスクが定義できてないことにあります。
そこで、次の要素についてもあわせて検討し明文化することで、そうした認識ずれをあらかじめ防ぐことができます。
## 目的
なぜこのタスクを行う必要があるのかについての記述です。
タスクはプロジェクトゴールとして設定された成果物・成果に漸進的に近づくためのものです。また、タスクを遂行する中で他のメンバーに伝えたい問題点や違和感（**テンション**）が生まれ、プロジェクトを最適化するための材料となります。そのためにそれぞれのタスクがプロジェクトゴールにどのように結びついているかを意識しながら目的を明文化することが有効です。
目的を記載することで、誰がやるべきか（担当者）や、いつまでにやるべきか（期限）も簡単に判断することができます。
## 想定アウトプット・想定作業時間
タスクをこなした結果生まれるアウトプットについての具体的イメージの記述です。なお、アウトプットとは、チームメンバーが割り当てられたタスクを完了したことで生まれた結果のことです（Tips3参照）。
例えば、ある資料作成のタスクがあったとき、「スライド～～枚で、見出しはしっかりと作りこむ。本文や記載する図表はダミーでよい」と記述することで、目的に沿ったアウトプットなのかどうかを確認しやすくなります。この場合、タスクの目的が「プレゼンテーション直前のリハーサルに使うため」であればアウトプットとしては不十分でしょうし、「プレゼンテーションの大枠の内容を内々に議論するため」であれば、必要十分なアウトプットになるでしょう。目的が達成できるのであれば、必ずしも完成度を突き詰める必要はありません。それよりも、最小限のアウトプットを確実に作ることを意識しましょう。
また、想定アウトプットのイメージをすり合わせるためには、タスクを終えるまでの想定作業時間を明文化することも効果的です。前述の資料作成のタスクであれば、ある人は1時間しかかからないと思っていた作業が、別の人は4時間もかかると思っていた場合、作りこみのレベルに差がある可能性が高いということが分かります。
さらに、これらの作業を通じてタスクの粒度が大きいと判断された場合は、そのタスクを細かく分解し、ミーティングごとに確実にアウトプットが可能なサイズにしましょう。
# ミーティングロールの確認
ミーティングを効率的・効果的に運営するために必要な役割（ミーティングロール）を、個々人に割り当てましょう。
具体的には、次のようなロールの割り当てが必要です。
* ファシリテーター：議論を促進し成果の質を向上させることで、プロジェクトの成果をよりよいものにするロール。アジェンダの改善やその後の議論形成のサポート・助言を行う。
* モデレーター：アジェンダの取りまとめや進行サポートを行うことで、議論のプロセスを最適化し進行の時間を維持するロール。アジェンダの合意から、その後のアジェンダ進行とタイムキープ、議論の結果決定された次の行動の明確化、ミーティング終了時の次回のアジェンダの決定までを担う。
* コーディネーター：ミーティング環境を整えるロール。適切なミーティングルームの確保（オンラインの場合はミーティング環境の設定）、ホワイトボードやモニターの手配をする。
* レコーダー：議事録を作成するロール。ミーティング後に議事録を共有するだけでなく、ミーティングの進行中にもリアルタイムで作成中の議事録を共有し、メンバー間の認識のずれを即座に修正することができるようにする。
チームメンバーの人数によって、一人が複数のロールを担当することもありますし、何もロールを持たないメンバーがいることもあります。ただし、いずれのロールも誰かが担うようにしてください。会議の参加者全員がそれぞれの視点から助言しうるので、ファシリテーターは全員が担うことになるでしょう。また、モデレーター、コーディネーター、レコーダーは属人性が低いため、固定ではなくミーティングごとに持ち回りにすることが望ましいものです。これにより、ミーティング運営に関する問題点や最適な方法について、参加者全員が自分から考えやすくなります。
ロールの分担はミーティングの都度話し合って決定してもかまいませんが、あらかじめミーティング前に分担や持ち回りのルールを決めておくと、当日のミーティング運営が効率的になります。
# ミーティング環境についてのノウハウ
Project Sprintで意図されているミーティングの効果を得るためには、効率的なミーティング環境の構築が欠かせません。「ミーティング環境の最適化自体についてもチームメンバーで議論し、改善していけること」が、Project Sprintのもたらすものですが、この点についてはすでにいくつかのベストプラクティスが得られていますので、ここではそれらを紹介します。
## アジェンダの取りまとめ
プロジェクスプリントではアジェンダの取りまとめが非常に重要です。
例えば、次のようなアジェンダの取りまとめ作業が発生します。
* ミーティング前のアジェンダアイテムの提出と必要な内容の編集
* ミーティング開始後のアジェンダアイテムの追加と必要な内容の編集
* ミーティング開始後のアジェンダアイテムの順番変更
* ミーティング開始後のアジェンダアイテムの繰り越し
これらの作業はすべてファシリテーターの主導のもと、チームメンバー全員で行われます。そのため、アジェンダを全員で確認・編集でき、かつ同じミーティングの中でのアジェンダアイテムの順番変更、ミーティングをまたいだアジェンダアイテムの移動ができる環境をつくっておきましょう。
## ミーティング中の時間管理
アジェンダ管理に不可欠な前提が、ミーティング中の時間を的確に把握することです。オンライン / オフラインいずれの場合も、ミーティングに参加しているチームメンバーが時間を把握できるよう、目に入る位置にタイマーと時計を配置しましょう。
タイマーは、「このアジェンダアイテムにあとどれくらい時間をかけられるのか」を把握するのに必要です。
時計は、ミーティング時間の開始時間・終了時間を把握するのに必要です。ミーティングの開始時間の遅れ、延長はつねに起こりうるものですが、絶対時刻を示す時計があると開始・終了の基準を把握・調整することができます。
## 議事録作成
ミーティングはチームメンバーで認識のズレをなくし、必要な物事を決める重要な場です。ミーティングの後に各自が必要なタスクに取りかかり、次のミーティングでその結果を持ち寄ることを考えると、ミーティングの内容は極力ミーティングの最中に明文化しながら確認、共有しておくことが効率的かつ効果的です。
また、レコーダーがメインで議事を記録するものの、内容に間違いがある場合は最も正しい認識を持つ人がその場で修正してしまったほうがよいでしょう。そのため、共同編集ができるドキュメントツールを議事録作成用ツールとして導入し、ミーティング中に画面表示しながらリアルタイムで議事録作成をすることをおすすめします。
## ホワイトボード
ミーティングでは口頭での説明、資料を用いた説明が行われることが多いと考えられますが、それに加え重要なのが手書きの情報による認識合わせです。手書きで図示/文章化することで、きちんとした資料になっていなかったり、口頭で明確に伝えきれていなかったりした内容を伝えやすくなります。これもProject Sprintにおいて重要な「認識のズレをなくす」ことに大いに役立ちます。
なおここでいうホワイトボードは、オフラインミーティングにおける物理的なものに限りません。オンラインミーティング用のホワイトボードツールもありますので、そういったものを利用してもかまいませんし、むしろ保存のしやすさという点ではこちらのほうが優れている場合もあります。
また、議事録を画面表示しながらリアルタイムで作成すると、議事録自体がホワイトボードと同様の役割を果たします。この観点からも、議事録の作成とリアルタイム共有は非常に重要です。
# アジェンダアイテムの要素
毎回のミーティングが始まる前に、各チームメンバーはあらかじめアジェンダアイテムを提出します。アジェンダアイテムには、少なくとも次のような内容が含まれている必要があります。
* アジェンダアイテム名（何を議論したいか端的に記載する）
* 進行方法（具体的な議論の進行イメージ）
* 目的や背景（そのアジェンダアイテムを議論したい理由）
* 誰から誰への議論か（誰がそのアジェンダアイテムのオーナーであり、誰と議論したいのか）
* 時間（議論完了までの所要時間）
これらは、「何について話し合いたいのか」をアジェンダアイテムオーナーが明らかにするために必要な情報ですが、これに加えて「どの程度まで話し合いたいのか」までを明らかにしておくと、議論がより進めやすくなります。
具体的には、次の要素を追加で記載するようにします。
* あるべき姿(アジェンダアイテムを議論した後に目指す状態)
* 結果(議論が終わったときに生まれている明示的なアウトプット）
* 参加者がアジェンダアイテムの完了について納得していることを証明する手段
これらの要素がそれぞれ事前に明らかになっていればいるほど効率的・効果的な議論ができるようになります。アジェンダアイテムオーナーだけでは記載することが難しいものを補足したり、他のチームメンバーから見て分かりにくいものを分かりやすくしたりして、これらの要素が記載できるように議論を整理していくことが、ファシリテーターに求められる役割です。
# 情報共有環境の構築
チーム全体で情報の透明性を最大限に高める環境を実現するため、「ここにアクセスすればすべての情報に辿りつくことができる」という状態をつくります。プロジェクトメンバーは、すべての情報、すべてのメンバー間のやりとりに、いつでもどこからでもアクセス可能にしておきます。
すべての情報を全員が閲覧でき、同時・共同編集が可能にしておくことも重要です。
* **ミーティング・アジェンダ**: プロジェクトメンバー全員がミーティングの目的やアジェンダの内容を知ることができるようにしましょう。
* **マイルストーン**: プロジェクトメンバー全員が最新のマイルストーンに常にアクセスできる必要があります。マイルストーンを常に意識することで、逸脱や問題を早期に検知して対応することができます。
* **議事録**: ミーティング中、作成途中の議事録をリアルタイムで全員が閲覧できるようにしておきましょう。認識のずれを合わせるのに効果的です。
* **ファイル共有**: プロジェクトメンバー全員が同じ情報にアクセスできるよう、ファイルの共有場所を用意しましょう。
* **スケジュール共有**: スケジュール調整に必要な限りで、メンバー間の個人カレンダーを共有するようにしましょう。これは、メールなどによって都度日程調整をするのではなく、チームメンバーのスケジュール状況が一か所に集まっており、ミーティングのスケジュールを効率的に設定・変更できるようになることを意味します。
* **タスク共有**: プロジェクトを通じて生まれるタスクを共有できる場所を用意しましょう。個人でタスク管理するのではなく、プロジェクトチームで共有のタスク置き場を用意することで、お互いが何をするべきか / するつもりだったか、を確認するコミュニケーションがしやすくなります。
これらは一般的なプロジェクトマネジメントで語られる要素と大きく異なりません。しかし、Project Sprintでは、それらの要素すべてにおいて、「情報の透明性をいかに担保するか」という点を中心に考えるべきです。
Project Sprintでは、プロジェクトのゴールやマイルストーンの設定、ロールの設定と調整をはじめ、様々なタイミングで「チームメンバーの納得を伴った合意」をつくることが必要になります。そのため、納得をつくるため = チームメンバーの情報格差をなくすためにはどういったプロジェクト環境を用意するべきか、というポイントが重要視されるのです。
なお、ここに書いている要素は一例に過ぎません。プロジェクトごとに、チームメンバー間で最も最適なプロジェクト環境を整備していくように話し合うこともまた重要です。
# スタンドアップの導入
Project Sprintでは定期的なミーティングでタスクの進捗報告を行い、問題が発生していればアジェンダアイテムとしてミーティング内で議論します。しかし、それぞれが自律的にタスクに取り組むうちに、成果物のイメージが当初の想定とずれてきたり、進め方や連携の方法が最適でなくなってきたりすることがあります。
こういった状況を定例ミーティングを待たずして是正するため、各メンバーのタスクの状況をクイックに確認する方法として、「スタンドアップ」を導入することがあります。スタンドアップで個々のメンバーのタスクへの取り組み状況が共有されることで、成果物や進め方に対する認識がアップデートされ、取り組み方法が改善されたりメンバー間の連携や役割分担が最適化されたりするきっかけが生まれます。
## 概要
Project Sprintにおけるスタンドアップは、次のような形で導入されます。
* 時間: 長さは15～30分程度で、スプリントの中で複数回行われる場合は毎回同じ時間帯とするのが望ましい。
* 頻度: 日次、スプリントの折返しタイミング、週頭など、スプリントやチームの状況に合わせて設定する。チームメンバーの要望によりスポットで実施してもよい。
* メンバー: チームメンバー全員
* 目的: チームのタスク状況を確認し、見直しが必要な場合にはそのきっかけを掴むこと
## 共有事項
チームメンバーは、次の内容についての共有を、プロジェクトのマイルストーンを見ながら行います。
1. 実行したこと
2. これから実行すること
3. 障害・問題（あれば）
## 実施のポイント
* 障害・問題は共有に留める。 スタンドアップは問題解決の場ではないことに注意してください。スタンドアップにおいて、問題点の共有だけに留まらず解決方法まで議論してしまって、タイムボックスを破ることになるのは望ましくありません。解決すべき障害や問題の報告があった場合は、スタンドアップ後に関係者で解決策を話し合い、必要に応じて結果をほかのメンバーに共有するようにします。
* いつものファシリテーターがハンドリングしない。 スタンドアップでの実施内容はシンプルです。メンバーそれぞれが持ち回りでファシリテーションを行い、自己組織化を促します。
# 振り返り
## **振り返りとは**
Project Sprintにおける振り返りとは、チームメンバーが過去のプロジェクトの内容についてレビューし、プログレス・チーミングそれぞれを改善する取り組みです。
そのため振り返りは、[ミーティングの進行方法](/ja/v3.2/practices/holding_meetings)で述べたテンショントリアージのようにミーティングごとに実施するものではなく、ある程度まとまった期間ごとに実施するものであり、またその分必要な時間もテンショントリアージよりも長くなります。この「まとまった期間」には、次の二つの種類のものがあり、いずれも併用して実施しましょう。なお、二つのタイミングが揃う場合は、同時に実施してもかまいません。
#### 1. マイルストーン終了時
マイルストーン終了という一つの区切りをタイミングとして設定するものです。このタイミングは、プロジェクトゴールに向けてどれくらい進んだかを振り返るのに適しています。また、当初予定していた進め方とのズレを振り返り、次のマイルストーン達成に向けて最適なキックオフを実施できるように準備することが可能になります。
#### 2. 定期的なタイミング
「何週間おき」「何か月おき」といった定期的な時間で設定するものです。これは、プロジェクトは不確実でどのような状態になるか予期できないものであるため、とにかく時間で区切って振り返りを行うという取り組みです。たとえば、マイルストーンがいつまでも達成できないという場合には、強制的に最適化のタイミングが訪れることで問題解決のきっかけになります。
いずれの場合でも、テンショントリアージ同様、振り返りの際にも、プログレスとチーミングそれぞれにおける理想の状態（＝プロジェクトゴール・マイルストーンとチームのロール）の変遷を参照できるようにしておくと「あのときこうすればよかった」「今後はこうすればよいのではないか」といった気づきを得やすくすることができます。
振り返りで取り扱う内容は、具体的なプロジェクトゴールへの進捗に向けた取り組み（プログレス）に関することであっても、チームの役割分担（チーミング）に関することであっても、ミーティングの進行（プロセス）に関することであっても、取り扱うことができます。
振り返りの実施についてもミーティングのアジェンダアイテムとなるため、事前にアジェンダアイテムの提出を行う必要があります。
## **一般的な振り返りの手法**
一般的な「振り返り」の手法は様々なものがありますが、ここでは比較的簡単に導入でき、汎用性も高い三つの手法を例として紹介します。
### **KPT（ケプト）**
KPTは、チームメンバーがこれまでのプロジェクトを振り返って感じた「良かったこと（Keep）」「改善したいこと（Problem）」を共有し、「今後改善のために取り組みたいこと（Try）」を話し合う法です。
**手順例**
1. チームメンバーがそれぞれ Keep、Problemを付箋に記入する。
2. 記入が終わったら、チームメンバーがそれぞれ記入したKeep、Problemを説明しながらホワイトボードに貼って共有する。
3. ホワイトボードに貼られている付箋のうち、関連があったり似た内容・テーマのものがあれば近くにまとめておく。
4. 共有内容を受けてチームメンバーがそれぞれTryを付箋に記入する。
5. 記入が終わったら、チームメンバーがそれぞれ記入したTryを説明しながらホワイトボードに貼って共有する。
6. Tryのうち実際に取り組むものを決め、今後のアクション（誰がいつまでに何をするか）を明確にする。
### **+/Δ（プラス/デルタ）**
+/Δは、チームメンバーがこれまでのプロジェクトを振り返って感じた「プラス=うまくいっていること、続けたいこと」、「デルタ=改善したいこと」を共有する手法です。KPTと似ていますが、意見の分け方が2つになるため、よりシンプルな実施が可能です。
**手順例**
1. チームメンバーがそれぞれ プラス、デルタを付箋に記入する。
2. 記入が終わったら、チームメンバーがそれぞれ記入したプラス、デルタを説明しながらホワイトボードに貼って共有する。
3. ホワイトボードに貼られている付箋のうち、関連があったり似た内容・テーマのものがあれば近くにまとめておく。
4. 共有内容を受けて、改善したいことについては改善するためのアイデアをチームで議論する。
5. 出たアイデアのうち実際に取り組むものを決め、今後のアクション（誰がいつまでに何をするか）を明確にする。
### **YWT(ワイダブリューティー)**
YWTは、チームメンバーがこれまでのプロジェクトにおいて「やったこと（Y）」を共有し、それを通じて「わかったこと（W）」を共有し、「つぎにやること（T）」を話し合う手法です。最初に実際に経験したことを見直すところからスタートすることで、より地に足のついた議論ができるという利点があります。
**手順例**
1. チームメンバーがそれぞれ「やったこと（Y）」を付箋に記入する。どのような業務を実施したか等、事実ベースで記載する。
2. 記入が終わったら、チームメンバーがそれぞれ記入した内容を説明しながらホワイトボードに貼って共有する。
3. ホワイトボードに貼られている付箋のうち、関連があったりテーマをまとめられそうなものはまとめる。
4. チームメンバーがそれぞれ「やったこと（Y）」から「わかったこと（W）」を付箋に記入する。
5. 記入が終わったら、チームメンバーがそれぞれ記入した内容を説明しながらホワイトボードに貼って共有する。理由や背景を深掘り・抽象化して、別の事例で活用できるレベルに昇華できるとよい。
6. ホワイトボードに貼られている付箋のうち、関連があったりテーマをまとめられそうなものはまとめる。
7. 共有内容を受けてチームメンバーがそれぞれ「つぎにやること（T）」を付箋に記入する。
8. 記入が終わったら、チームメンバーがそれぞれ記入した内容を説明しながらホワイトボードに貼って共有する。
9. 「つぎにやること（T）」のうち実際に取り組むものを決め、今後のアクション（誰がいつまでに何をするか）を明確にし、タスクリストに記載できるとよい。
# テンショントリアージ
## **テンショントリアージとは**
[ミーティングの進行方法](/ja/v3.2/practices/holding_meetings)で解説したように、テンショントリアージとは、個々のチームメンバーが感じている違和感を提案に変えて全員で共有したうえで、今チームを改善するために必要なものを優先的に選び、解決しようとすることです。これによって、メンバー一人一人が思う「こうしたらもっとより良くなるのに」という現状とよりよい状態の間のギャップ、ちょっとしたアイデア・気になること・不安などを共有し、解決のためのアクションにつなげることができます。
テンショントリアージは毎回のミーティングで行う取り組みであり、主にチームメンバーの今現在の気持ちにフォーカスしているものです。現在を見ることで、問題が顕在化もしくは拡大する前に共有し対処することができるようになります。 また、タイムリーに気持ちを吐き出すことができる場があることで、メンバーのプロジェクトへの参加感の向上にもつながります。
## **具体的な手順**
テンショントリアージは、例えば次のような手順で実施しますが、これはあくまで一例です。上記の目的をより効率的・効果的に達成するために、ご自身のチームにとって最適な方法にアレンジしてみてください。
1. チームメンバーがテンションをあげる
2. テンショントリアージのアジェンダアイテムオーナーがテンションを一つ読み上げ「何が必要ですか？」とテンションをあげた人に問いかける
3. テンションをあげた人は次のいずれかを選択し、そのあと自分が必要としていることを回答する
* 他メンバーへのタスクのリクエスト
* 他メンバーからの情報やヘルプ提供のリクエスト
* ロールの調整・変更・追加に関するリクエスト
* 単なる情報提供や感想の共有
1. テンショントリアージのアジェンダアイテムオーナーは、次のいずれかを選択してテンションをあげた人に提案する
* その場で解決する
* タスク化する
* アジェンダアイテム化する
2. テンションをあげた人がこれで必要なことが得られれば終了とし、得られなければ、続けて議論する(3と4を詳しく繰り返す)
3. 時間の許す限り、他のテンションについても2\~5の手順を繰り返す
# ロールセッション
## **ロールセッションとは**
プロジェクトの各ステップの開始時には、次のマイルストーンまでにチームがどのように進んでいくかを擦り合わせ、個人がやるべきこと、他のメンバーに期待することについて認識を揃える必要があります。まず、改めて今回のマイルストーンの内容とプロジェクトゴールを確認します。その後、各メンバーがこのマイルストーンにおいてどのようなタスク・ロールを担うのかの認識を合わせます。
ロールセッションは、この各メンバーの役割と期待値の擦り合わせのために行われます。プロジェクトチーム全員が自分の役割の範囲でリーダーシップを発揮できるように、メンバーそれぞれのやるべきこと、苦手なこと、期待されることなど、内的な自己認識と外的な期待値を明文化して共有し、相互に役割を擦り合わせます。
## **具体的な手順**
ロールセッションは、例えば次のような手順で実施しますが、これはあくまで一例です。上記の目的をより効率的・効果的に達成するために、ご自身のチームにとって最適な方法にアレンジしてみてください。
1. 各メンバーが自分のやるべきことを付箋に書き出し共有する
2. 他のメンバーにヘルプしてほしいこと、他のメンバーへの期待値を付箋に書き出し共有する\
（アサインできる対象がわからなかったり現時点ではいなかったりしても問題ない）
3. 未アサインのヘルプ内容や期待値につき、メンバー相互に議論してアサイン先を決める
4. 改めて自分のやるべきことを精査し、各々承認し、議論して深める
5. これまでの議論を踏まえて、各メンバーが自分の役割を更新し共有する
# Essentials
Project Sprintは、プロジェクトチームがプロジェクトゴールの達成へと進んでいくための、考え方や仕組みを提供します。
プロジェクトのすべての要素は、プロジェクトチームによって規定されるものです。プロジェクトチームは、以下の原則に従って行動します。
* プロジェクトチームは、プロジェクトチーム自身の意思を反映させたプロジェクトゴールを設定し、外部環境の変化やプロジェクト内で得られる洞察に応じてアップデートを繰り返しながら、納得感と達成への現実味を持って、漸進的にプロジェクトゴールの達成を目指します。
* プロジェクトチームは、各メンバーが作成物を継続的に出力することを通して、他のメンバーに伝えたいアイデアやテンションを発見し、漸進的にプロジェクトゴールの達成に向かいます。
* プロジェクトチームは、全員参加の定期的・反復的なミーティングで認識を揃え、全員が納得できるプロジェクトゴールやロールを設定し更新しつづけるとともに、アイデアの共同創造と問題の共同解決を行います。
* プロジェクトチームは、各メンバーの責任・役割・期待値を共有します。各メンバーは、己の役割を果たすべく自律的に行動を起こし、信頼と敬意をもって相互に支援を行います。
# Reference
このドキュメントは、Project Sprintの背景にある諸メソッド・概念・文献について記載しています。
Project Sprintは、以下の理論・メソッド・文献・概念を参考にしながら、様々なプロジェクトで実践した経験則をもとに独立したメソッドとしてまとめられています。
### Manifesto for Agile Software Development
アジャイルソフトウェア開発宣言と12の原則の価値に共感しています。\
[https://agilemanifesto.org/](https://agilemanifesto.org)
### **Scrum & Scrum\@Scale**
スプリントという短期間に反復的な実践により成果物を提供する概念、透明性や自己組織化という概念、ミーティングによる認識合わせや意思決定をプロセスの中心におくこと、レトロスペクティブ(振り返り)のプロセスなどを参考にしています。\
Project Sprint という名称は Scrum のスプリントからインスピレーションを得ています。\
[https://www.scrumguides.org/](https://www.scrumguides.org)
### ティール組織
セルフマネジメントや進化する目的の概念に共感しています。\
[https://www.reinventingorganizations.com/](https://www.reinventingorganizations.com)
### **Holacracy**
チーミング・アクティビティでコアの要素となっているロールとテンションやその関係性は、ホラクラシーの考え方を参考にしています。\
[https://www.holacracy.org/](https://www.holacracy.org)
### 心理的安全性
エイミー・エドモンドソンにより提唱された概念です。チームのなかでどのような発言でも大丈夫だと信じられている環境をつくる重要性に共感しています。\
Googleが行った生産性の高いチームの調査プロジェクトにより注目が集まりました。\
Google re:Work\
### センスメイキング理論
カール・ワイクを中心に発展されている理論です。正確性よりもチームの納得に重きを置いている考え方に共感しています。
# v3.2
## **CODEとは**
**CODE**とは、Project Sprintについて説明したドキュメント群の総称です。
### [Theories](/ja/v3.2/theories) and [Practices](/ja/v3.2/practices)
このドキュメント群では、Project Sprintの基本的な概念の説明と実践方法が順を追って説明されます。理論編であるTheories及び実践編であるPracticesから成り、それぞれを上から順番に読み進めていくことで、Project Sprintを概念として理解した上で、実際のプロジェクトに取り入れて使うための知識を得ることができるようになっています。
すでにプロジェクトマネジメントの経験がある方が新しい方法論としてProject Sprintをインプットするために読むことはもちろん、すでにProject Sprintを導入している方も、効果的な活用のための基盤固めとして読むことができます。
### [Essentials](/ja/v3.3/essentials)
Project Sprintの核となる行動規範がシンプルに述べられており、そこからProject Sprintが立脚する思想や価値観を理解することができます。Theoriesの通読後に改めてEssentialsをお読みいただくと、Project Sprintの最重要箇所をより把握しやすくなるでしょう。
### [Reference](/ja/v3.0/reference)
Project Sprintの背景にある諸メソッド・概念・文献について記載されており、Project Sprintの効率的な理解が可能になり、また今後のメソッドのアップデートに関わりそうな情報を知ることができます。さらに、背景を知ることでメソッドの応用も可能になります。
## **ドキュメントの比較表**
| ドキュメント名 | Theories | Practices | Essentials | Reference |
| ------- | ---------------------------- | ----------------------------- | ------------------------------- | -------------------------------------------------------- |
| 記載内容 | 基本的な概念や考え方の説明 | 具体的な実践方法 | 核となる行動規範 | 背景にある諸メソッド・概念・文献 |
| 効果 | 理論体系としてのProject Sprintが理解できる | Project Sprintの具体的なノウハウが理解できる | Project Sprintが立脚する思想や価値観が理解できる | 効率的なProject Sprintの理解、メソッドのアップデートに関わりそうな情報、応用のための知識が得られる |
# Theories
このドキュメント群では、Project Sprintの基本的な概念の説明と実践方法が順を追って説明されます。理論編であるTheories及び実践編であるPracticesから成り、それぞれを上から順番に読み進めていくことで、Project Sprintを概念として理解した上で、実際のプロジェクトに取り入れて使うための知識を得ることができるようになっています。
すでにプロジェクトマネジメントの経験がある方が新しい方法論としてProject Sprintをインプットするために読むことはもちろん、すでにProject Sprintを導入している方も、効果的な活用のための基盤固めとして読むことができます。
| Contents | Theories | Practices |
| ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Project Sprint 101 | [Project Sprint 101](/ja/v3.2/theories/101) | WIP |
| プロジェクトライフサイクル | [5つのサイクル](/ja/v3.2/theories/project_lifecycle) | WIP |
| プロジェクトゴールとマイルストーン | プロジェクトゴールとは
マイルストーンとは
| プロジェクトゴールの設定
マイルストーンの設定
プロジェクトゴールとマイルストーンの見直し
|
| トラック | [トラックとは](/ja/v3.2/theories/tracks) | [トラックの設定](/ja/v3.3/practices/tracks) |
| 期待値とロール | [期待値とロール](/ja/v3.2/theories/rolls) | チームメンバーの理解とロールシートの利用
ロールの確認
|
| 定例ミーティング | [定例ミーティングの重要性](/ja/v3.3/theories/meetings) | ミーティングの設計
ミーティングの進行方法
タスクの設定
ミーティングロールの確認
ミーティング環境についてのノウハウ
|
| アジェンダ | [アジェンダとは](/ja/v3.3/theories/agenda) | [アジェンダアイテムの要素](/ja/v3.2/practices/agenda) |
| プロジェクトの環境整備 | [プロジェクトの環境整備](/ja/v3.3/theories/project_environments) | 情報共有環境の構築
スタンドアップの導入
|
| 継続的改善アプローチ | [継続的改善アプローチ](/ja/v3.2/theories/continuous_improvement_approach) | 振り返り
テンショントリアージ
ロールセッション
|
| Project Sprintの成功指標 | [Project Sprintの成功指標](/ja/v3.1/tutorial/section4-4) | - |
| Project Sprintの発展 | - | [コントリビューターとしての参加の方法](https://github.com/copilot-jp/project-sprint/blob/master/JA/v3.2/theories/broken-reference/README.md) |
# Project Sprint 101
Project Sprintは、プロジェクトチームがプロジェクトゴールを設定したりプロジェクトゴールに向かって進んだりするのを助けるために、ものごとの捉え方・考え方や、最適化を促進するための仕組みを提供します。
Project Sprintの基本のメカニズムは、「定期的・反復的なミーティングで各メンバーの取り組みの成果や作成物を共有し環境に対する認識を揃えることによって、各メンバーが同じプロジェクトゴールを目指して自律的に各自の次の行動に向かうことができるようにする。この繰り返しがプロジェクトを現在の状態から理想の状態に漸進的に近づけ、結果としてプロジェクトゴールが達成される。」というものです。
ここでは、このメカニズムをうまく取り入れるためのコアとなるアクションとその前提を説明し、Fundamentalsにおける個別のドキュメントの内容を理解しやすくします。
### 前提
* プロジェクトは、変化しつづける環境と目的に常に追随するための小さな実験である。
* プロジェクトとは、「全体」としての課題に取り組む過程のうち、現状のプロジェクトチームで推進・達成に現実味が持てる「部分」を切り出したものである。
* プロジェクトゴールは、「全体ゴール」の達成に寄与する「部分ゴール」である。
* プロジェクトは、プログレス、チーミング、プロセスの3要素からなる。
* プログレスは、プロジェクトの成果物やゴールにフォーカスした活動である。
* チーミングは、チームメンバーの関係性にフォーカスした活動である。
* プロセスは、プロジェクトチームがプロジェクトゴールに向かって進んでいくための手続きにフォーカスした活動である。
* プロジェクトには、プロジェクトチームとプロジェクトゴールが不可欠である。
* プロジェクトチームは、プロジェクトゴールに対する共通認識をもち、その達成に向けて相互に協力し合うメンバーの集まりである。
* プロジェクトチームの役割は、よりよい形でプロジェクトゴールに向かっていくために、個々のメンバーの活動の前提を与えることである。
* プロジェクトゴールは、プログレスゴールとチーミングゴールから成り、いずれもプロジェクトチームによって定められる。
* プログレスゴールとは、プロジェクトの成果として目指すべき状態が達成されたり作成物が出力されたりすることである。
* チーミングゴールとは、相互に期待値を共有し合う自律的なプロジェクトチームが形成されることである。
* プロジェクトチームがプロジェクトゴールに近づくために最も重要なのは、ミーティングとそこにおけるアジェンダの議論である。
* ミーティングとは、チームメンバーが一時的に同一の環境に固定されてリアルタイムで会話をすることにより、素早く効率的な認識合わせと、全員にとって納得感のある意思決定をする場である。
* アジェンダとは、個人から出力されたアイデアや問題を、他のメンバーと共有し次の行動を決定するために明文化したものである。
* プロジェクトの理想の状態とは、次に述べるコア・アクションがプロジェクトチームとしても個人としても円滑に実行され、プロセスがサイクルとして繰り返されている状態である。
### コア・アクション
* プロジェクトチームは、自身の意思を反映させたプロジェクトゴールを設定し共有する。
* そのために、ミーティングで環境への認識を揃え、各メンバーが納得できるプロジェクトゴールを設定する。
* その結果、各メンバーは個人としてプロジェクトゴールに対する納得感と達成への現実味を持ち、自律的にアクションできる。
* プロジェクトチームは、メンバー間で各々の期待値に対する共通認識を持ち、チームにおける自身の役割や責任に納得してプロジェクトに取り組む。
* そのために、自身の役割や他のメンバーへの期待をミーティングで共有し認識を揃える。
* その結果、各メンバーが自分はチームのために何をすべきかを自律的に判断し実際にアクションできる。
* プロジェクトチームは、作成物を生み出すことにより、自ら設定したプロジェクトゴールに向かい漸進的に進む。
* そのために、各メンバーが作成物の出力に取り組み、その中で他のメンバーに伝えたいひらめきや違和感に出会う。
* その結果、ミーティングのアジェンダとして提出された各メンバーのひらめきや違和感をもとに、プロジェクトチームとしての意思決定が行われ、それを前提に各メンバーが自律的にさらに次のアクションに向かうことができる。
* プロジェクトチームは、プロジェクトゴールに向けた進捗や全体像を常に見直し、継続的に改善を行う。
* そのために、プロジェクトを一定の期間で区切って定期的・反復的なミーティングを実施する。
* その結果、環境の変化に応じ、納得感と共通認識を持ってプロジェクトやプロジェクトゴールを再定義し、適切な軌道修正をすることができる。
# プロジェクトライフサイクル
プロジェクトライフサイクルとは、プロジェクトが構想されてから完了に至るまでにプロジェクトチームが辿る一連のフェーズのことを指します。
Project Sprintにおいては、プロジェクトライフサイクルは構想期、形成期、自律準備期、自律推進期、統合期の5つのフェーズから成ると捉えます。プロジェクトチームが現在どのフェーズにあるのかによって、取るべき行動や達成すべき状態は異なります。そのため、このプロジェクトライフサイクルを理解し意識することによって、プロジェクトを効率よく進めることが可能になります。
## 構想期
プロジェクトはまず、プロジェクトソース（発案者）が抱いた希望を源として立ち上がります。このフェーズでは、プロジェクトソースが自分自身の希望を明確化してプロジェクト立ち上げの理由や目的を整理し、目指すべき理想の状態を見据えた上で、プロジェクトがどのようなものになるべきかの仮説を立てます。そして、そのために最適なチームメンバーを決定することでプロジェクトチームを組成します。
## 形成期
ここからは、構想期で組成されたプロジェクトチームが主体となってプロジェクトを進めていきます。形成期は、プロジェクトチームの意思を反映したプロジェクトゴールを設定し、そのプロジェクトゴールを達成するために必要なリソースを把握するフェーズです。プロジェクトの目的や価値、生み出すべき成果を明確にしてプロジェクトゴールを設定し、そのプロジェクトゴールを相互に依存関係がなるべくないようにブレイクダウンしてトラックを作成します。
## 自律準備期
自律準備期は、このフェーズの後に続く自律推進期が1サイクル目からスムーズに走り出せるよう、環境を整えるためのフェーズです。プロジェクトの情報を整理して透明性を高め、定期的なミーティングで目線合わせを行います。 各トラックごとに自律的な推進ができるよう整理し、必要に応じてトラック同士の定期的な連携や同期タイミングを設計します。また、定例ミーティングの方法やアジェンダのテンプレートなどを準備し全体で共有しておきます。自律推進期において漸進的・反復的にプロジェクトの進め方を改善できるよう、継続的改善アプローチも導入します。
## 自律推進期
さあ、環境は整いました。プロジェクトゴールにつながる成果を生み出していくために手を動かすフェーズです。自律推進期は、漸進的にプロジェクトゴールを目指すべく、定例ミーティングを軸とした隔週～3か月程度の小さなサイクルの反復として進行されます。これにより、環境の変化に立ち遅れることなく必要に応じてプロジェクトの再定義を行い、プロジェクトチームとして、そしてトラックごとに自律的にプロジェクトゴールを目指しつづけることができるのです。 全トラックのマイルストーンは可視化され、状況に応じて更新されていなければなりません。また、それぞれのトラックで定期的な成果物の出力と、継続的改善アプローチによる最適化を行います。
## 結合期
プロジェクトゴールに向けてプロジェクトを収束させていく、または次のプロジェクトに向けた引継ぎを進めるフェーズです。そのためには、外部から求められているものを踏まえてプロジェクト完了の定義を把握しておく必要があります。全体ゴールに対する部分ゴールの達成として出力できる形でプロジェクトの成果を整え、外部に示せるようにします。
## 各サイクルにおけるProject Sprintの価値
Project Sprintの基本メカニズムが最もその効力を発揮するのは、プロジェクトチームが自律推進期にあるときです。定例ミーティングによる認識合わせと意思決定を経て、各メンバーが自律的に次の行動に向かっていくというサイクルの繰り返しが、プロジェクトチームを漸進的・安定的にプロジェクトゴールに向かわせるからです。 しかし、プロジェクトゴールやマイルストーン、トラックなどを設定し、プロジェクトの骨組みを作り軌道に乗せていく形成期や自律準備期においても、その段階におけるプロジェクトやそれを取り巻く環境の不確実性の高さゆえに、定例ミーティングで都度環境に対する認識を揃えプロジェクトを再定義するというProject Sprintのメカニズムは、高い効果を発揮します。 また、Project Sprintは、自律準備期をできるだけ短縮し、スムーズに自律推進期に入れるような考え方や仕組みを提供します。
# プロジェクトゴールとは
## プロジェクトゴールとは
プロジェクトゴールとは、プロジェクトにおいてプロジェクトチームが達成したい成果を指します。成果はある一定の状態であることもあれば、具体的な作成物であることもあります。
[Project Sprint 101](https://github.com/copilot-jp/project-sprint/blob/master/JA/v3.2/theories/broken-reference/README.md)で述べたように、Project Sprintではプロジェクトを「全体」に対する「部分」であると捉えており、プロジェクトゴールは「大きなゴール」の達成に近づくために必要な一歩としての「小さなゴール」です。この漸進的な進捗のための成果だけでなく、「相互に期待値を共有し合う自律的なプロジェクトチームを形成する」というチーミングにおける理想の状態を達成することも、プロジェクトゴールに含まれます。漸進的な進捗のための成果とチーミングにおける理想の状態いずれの達成に比重が置かれるかは、プロジェクトによって様々です。
プロジェクトゴールはプロジェクトチームによって定義され、プロジェクトチームとして認識が揃っており、プロジェクトチームによって必要に応じて再定義しうるものでなくてはなりません。これらが実現していることにより、各チームメンバーがプロジェクトゴールの達成に現実味と納得感を持ってプロジェクトに参画できるのです。
プロジェクトチームは、プロジェクトが進むべき方向を適切に見定められるよう、プロジェクトゴールが全体ゴールに対してどういう位置づけにあり、どういう役割を果たすのかを常に認識しておく必要があります。また、このプロジェクトチームとしての認識は、プロジェクトの外部に対しても明確に示せる状態にしておきます。
## プロジェクトゴールの設定
プロジェクトはプロジェクトソースの希望を源として立ち上がり、まずはプロジェクトソース主導の下で、目指すべきゴールの仮説に基づいてプロジェクトチームが組成されます。プロジェクトチームが組成されてからは、プロジェクトチームが主体となり、自身の意思に基づいて改めてプロジェクトを定義しプロジェクトゴールを設定します。
具体的な設定方法については、実践編「[プロジェクトゴールの設定](/ja/v3.3/practices/project_goals)」をご覧ください。
# マイルストーンとは
## マイルストーンとは
マイルストーンとは、プロジェクト内のある時点において、具体的な作成物とそれに紐づく期限をセットにして記述したもののことです。あるマイルストーンを達成するまでの期間のことをステージと呼びます。
マイルストーンは[トラック](/ja/v3.2/theories/tracks)ごとに設定され、ひとつのトラックに複数置かれることがほとんどです。各トラックにおけるマイルストーンの達成の集積がメインのトラックにおけるマイルストーンの達成となり、メインのトラックにおけるマイルストーンを順次達成していくことがプロジェクトゴールの達成への道です。
マイルストーンもプロジェクトゴールと同様に、当該マイルストーンが置かれるトラックの進行を担うチームによって定義され、当該チームとして認識が揃っており、当該チームによって必要に応じて再定義しうるものでなくてはなりません。また、当該チームは自らが達成すべきマイルストーンがプロジェクトゴールに対してどういう位置づけにあり、どういう役割を果たすのかを常に認識し、それをプロジェクトチーム全体に対して明確に示せる状態にしておく必要があります。
## マイルストーンの価値
マイルストーンを明示化し常に意識することで、最終的な状態や作成物に向かう道筋の確からしさを確認し、現在の地点からチームが何をするべきか、またその後何を目指していくべきかを見通すことができます。
Project Sprintにおいて、プロジェクトゴールに向けての進捗は、現在のステータス(As-Is)とあるべきステータス(To-Be)の距離として捉えられます。 As-Is時点からTo-Beを描くとき、チームメンバーによってはあまり確度が高くないこともあります。
この原因は、大きく二つに分けられます。
* As-IsやTo-Beに関して、チームメンバー間で認識が揃っていないこと (**ズレの問題**)
* As-IsやTo-Beに関して、実際にタスクをリスト化し具体的に取り組んでいかなければ明らかにならない部分が多いこと (**粗さの問題**)
Project Sprintでは、定例ミーティングでの認識合わせとマイルストーンの設定によってこれらの問題を解決します。最終的なプロジェクトゴール（To-Be）より距離の近いTo-Be'としてのマイルストーンを設定することで未来に対する予測の粗さを軽減するとともに具体的な取り組みに落とし込みやすくするのです。
## 制約・イベント
プロジェクトの外部環境にあって、プロジェクトに影響を与えるためプロジェクトメンバーが意識しなければならないものを、**制約**と呼びます。特に、マイルストーンの設定の前提となり、ときにプロジェクトゴールにも影響を与えるものを**イベント**と呼びます。なお、プロジェクトの内部にあってマイルストーンやプロジェクトゴールの変動をもたらすものは、プロジェクトの一部として捉え、イベントとは呼びません。
制約は、社内の稟議スケジュールや予算など、所与のものであることが多いですが、プロジェクトを取り巻くさまざまな制約のうち、どれを実際にプロジェクトに影響を与える**イベント**と捉えてマイルストーンやプロジェクトゴールの設定の前提とするかについては、プロジェクトチームで判断しなくてはならないこともあります。この場合にも、プロジェクトチームとして認識を揃えた上で納得感のある意志決定をすることが大切です。
イベントの典型的な例は、プロジェクトの外で日々行われている、組織の定常業務です。具体的には取締役会などがこれにあたります。これ自体がプロジェクトの作成物を生み出すわけではありませんが、プロジェクトに関する何らかの報告や決裁がなされるため、こうしたイベントに合わせてマイルストーンを設定する必要があることがあります。また、こうしたイベントからフィードバックされた情報がプロジェクトの前提条件を変え、マイルストーンや、ときにはプロジェクトゴールそのものを変える必要が生じることもあります。
単発のものや定期的なものだけでなく、「商戦期」のような期間をもったものも、イベントとして認識します。それに合わせてプロジェクトのマイルストーンを設定したり、その結果を受けてマイルストーンやゴールを調整したりする必要があるという点は、特定の日付であっても期間であっても変わらないからです。
# トラックとは
## トラックとは
トラックとは、それぞれが強い依存関係を持たず、設定した役割や目標に沿って自律自走できるプロジェクト内の単位です。
[Project Sprint 101](/ja/v3.2/theories/101)で説明したように、Project Sprintではプロジェクトを「全体」の達成に寄与するひとつの「部分」として捉えます。トラックも同様に、プロジェクトという全体の達成に必要なそれぞれの部分といえます。プロジェクトゴール達成を目指す過程を、それぞれが強い依存関係を持たず自律的に作業を進めることができる単位にまでブレイクダウンしたものを、トラックと呼びます。
必要なトラックの数や種類はプロジェクトごとに、またプロジェクトのフェーズにより異なります。一般的には、プロジェクト全体の状態を把握するためのメインのトラックをまず設定してマイルストーンを置き、そのマイルストーンの達成のために必要なものを要素ごとに分割することで、その他のトラックが置かれます。
プロジェクトの構想期はまだプロジェクトゴールが明確化されていないため、トラックへのブレイクダウンも進まないことが多いでしょう。その後の形成期や自律準備期において、プロジェクトゴールやマイルストーン、必要な成果物などが明確になってくるにつれて、トラックの分割が進みます。
## トラックの分化と統合
トラックを設定する際、まずは「このようなトラックが必要だろう」という仮説を立て、チームメンバーを決めます。この段階ではマイルストーンが置かれておらず、定例ミーティングのみのトラックになるかもしれません。その後定例ミーティングで認識合わせと意思決定を重ねることによってトラックのゴールやマイルストーンが明文化されていきます。
トラック同士は、依存関係が少ない疎結合な状態になるように設定します。トラック同士の依存関係は、個々のトラックの自律的な動きの妨げとなるからです。
とはいえ、最初にトラックを設定する場合やひとつのトラックを複数に分割する場合においては、他のトラックとの境界が曖昧で依存関係が比較的強く残り、他のトラックと密接に協力して作業する必要が出ることもあります。このような場合は、トラックごとの情報を整理して透明性を高め、定期的なミーティングで認識合わせを行いながら、最小限の協力で活動できるよう相互に体制を整えていきます。
こうして見てくると、トラックにも[プロジェクトライフサイクル](https://github.com/copilot-jp/project-sprint/blob/master/JA/v3.2/theories/proeject_lifecycle.md)と同様の考え方が適用できることが分かってくるでしょう。必要なトラックの仮説を立てチームメンバーを決めるのが構想期、その後トラックのゴールやマイルストーンを明文化するのが形成期、他のトラックとの連携体制や定例ミーティングの形を整えて自律に向かうのがトラックの自律準備期に当たります。
上述のように、自律準備期までは他のトラックとの境界が曖昧なことも多くあります。また、自律推進期に入ってからも、環境の変化に伴い他トラックとの相互依存関係が密になり、自律的な推進が難しくなることもあるでしょう。その場合には、一旦自律準備期に戻ったと捉えて情報や体制を整理し、改めて定期的な同期・連携による一定程度予測可能な相互作用のみでそれぞれが自律的に動ける状態に近づけていきます。
## トラックの分割例
例えば、あるWebサイトを立ち上げるプロジェクトを考えたとき（プロジェクトゴールは「Webサイトの完成」）、Webサイトのデザインを考えるチームと、Webサイトのシステム環境を整える作業は、一定程度関連はしながらも並行して進行します。このとき、それぞれの作業領域をトラックとして分割し、トラックごとにマイルストーンを分けて考えることで、よりプロジェクトを構造化して捉えられるようになります。
上述のWebサイトの例のようなトラック分割だけでなく、営業・マーケティング・CSといったロールベースでのトラック分割や、プロダクトごと・機能ごとのトラック分割など、プロジェクトの性質や規模によって、設定されるトラックは様々です。
# 期待値とロール
Project Sprintでは、定例ミーティングでの期待値の共有とロールの設定によって、理想的なチームの形成を目指します。
## 期待値の共有
自律的なチームであるためには、チームメンバー各々の責任・役割が共有されて認識が揃っており、メンバー相互の期待値に齟齬がないことが重要です。言い換えると、あるチームメンバーが「あの人はこれをやってくれるだろう」と考えたとき、そのチームメンバーも「これは私がやるべきことだ」と考えている状態(**期待値の一致**)です。
また、メンバー個人の視点では、上記が実現されることで、チームから自分へ期待されていることや自分から他のメンバーへ期待してよいことが明確になります。チームにおける自分の責任・役割や他のメンバーからの期待に納得感が持てれば、自分がチームのために何をすべきかを自律的に判断し実際に行動できるようになります。自分に担うことができる役割であれば何であれ必要に応じていつでも担おうとするマインドセット (**自発的な役割の引き受け**)が生まれるのです。
## ロールの設定
Project Sprintでは、チームメンバー個々人の役割のことをロールと呼びます。ロールとチームメンバーは必ずしも一対一の関係である必要はありません。つまり、一人の人が複数のロールを担うこともありますし、またあるロールを複数の人が担うこともできます。
また、設定するロールの個数には制限がありませんし、「必ず設定すべきロール」というものもありません。ロールの定義に関しても、必要なのはチームメンバーで合意することのみです。プロジェクトの性質に応じて、必要な役割分担をチームメンバーで議論し、ロールとして明文化しましょう。
# 定例ミーティングの重要性
Project Sprintは、定例ミーティングを定期的・反復的な実践の起点とすることにより、進化するゴールをチームで漸進的に達成するためのプロジェクト推進メソッドです。プロジェクトチームがプロジェクトゴールに向かって円滑に進んでいくために最も重要なのは、チームでの定例ミーティングとそこでのアジェンダの議論です。
ここでは、Project Sprintにおいて定例ミーティングが不可欠である理由を記述します。
## ミーティングとは
Project Sprintでは「ミーティング」を、「チームメンバーが一時的に同一の環境に固定されてリアルタイムで会話をすることにより、素早く効率的な認識合わせと、全員にとって納得感のある意思決定をする場」と位置づけています。
リアルタイムで全員が集まるミーティングが、プロジェクトの意思決定においては最適な選択です。変化の激しい時代にあって、メールやチャットでの非同期のコミュニケーションでは、個々のメンバーが時間軸も視界も異なる環境に置かれることになるため認識に齟齬が生じやすく、意思決定が困難になります。リアルタイムで集まることでまず、チームメンバー全員が同じ時間軸に固定されます。そして会話する中でお互いの視界にある景色を擦り合わせて初めて認識が合い、大きな意思決定を行ったりそれに対して納得したりすることができるようになるのです。
## 定例ミーティングが不可欠である理由
**1. 定期的に振り返りを行うことで、プロジェクトを最適化できる。**
不確実性の高いプロジェクトにおいては、マイルストーン達成までの道のりは整然と進むわけではありません。各ステップの中で、立ち上げ、計画、実行、終結といったそれぞれの段階が重なり合い影響し合いながら進行していくのです。そこで、定期的なミーティングでの振り返りによってメンバー間の認識を都度擦り合わせ、必要に応じて調整を加えることで、プロジェクトを最適化する必要があります。
（PMBOKの概念を参照）
**2. 前回のミーティングから今回のミーティングまでの差分をキャッチアップする機会を保証できる。**
プロジェクトはルーチンワークと違って不確実性が高く、目的も変化しやすいものです。社会や組織の変化が激しいなかでも、定期的に集まることで、各チームメンバーが経験したこと・変化を確実に、定期的に吸収することができます。これらをインプットするからこそ、プロジェクトのゴールやマイルストーンをみんなで合意して変化させることも可能になります。
**プロジェクトとルーチンワークの違い**
**3. チームメンバーのスケジュールの調整コストが低くなる。**
社内外の多様なメンバーが参加するようなプロジェクトも多い昨今では、都度スケジュール調整をしているとそれだけで時間がかかります。そのため、あらかじめスケジュール設定をしておく方が効率がよいのです。また都度ミーティングを調整していると必要なタイミングでミーティング開催ができません。これは、必要十分な参加者が一度に集まって素早く効率的に意思決定をするというProject Sprintの利点を損ねてしまいます。
**4. 同じ曜日・時間に開催されることで、他のチームの人が共有のために覗きに来やすくなる。**
あるアジェンダアイテムについて特定のゲストを呼び、スペシャリストとしてのコメントをもらうといったことはよくありますが、定期的な時間・曜日があらかじめ設定されていると都度の調整が必要なく、すでにある時間に招待すればよいため、効率的です。
**5. 定期的に期間を区切るほうがタスクの粒度を作りやすい。**
定期的な期間、例えば「1週間でできること」という基準となる間隔をもつことで、これぐらいのタスクであればできるかな、という予測がしやすくなります。現実的なタスクを作成することは、アウトプットを確実に作ること、ひいてはアジェンダの確度を上げることにつながります。個々人のアクティビティであるタスク実行をプロジェクト全体の成果に反映させるプロセスを定期的に繰り返すことによって、プロジェクトが最適化されていきます。
**6. 業務のリズムを作りやすくなり、タスクの消化がスムーズになる。**
例えば毎週月曜日はこのミーティングがあるのでこういう作業時間を確保しておこう、など。個々のメンバーが作業計画を立てやすくなります。
**7. プロジェクトの定点観測資料になる。**
ミーティングのアジェンダ、議事録、タスクの進捗報告が定点観測的に残ります。これは振り返りの際に参照しやすいログとなるほか、新しいメンバーが参加した際の読みやすさも担保します（過去の情報をむやみに読むよりは、定期的に出力されたものをマイルストーンに沿って読むほうが理解しやすいため）。また、こうしたログが残っていれば、別のプロジェクトを開始する際、過去のプロジェクトがこのようにすすんだのだという参考やひな形にしやすくなります。
# アジェンダとは
アジェンダとは、個人から出力されたアイデアや問題を、他のメンバーと共有し次の行動を決定するために明文化したものです。ミーティングに提出され議論される個々のアジェンダを、アジェンダアイテムと呼びます。
## アジェンダアイテムの目的
アジェンダアイテムは、議論の目的によって次の三つの種類に分けられます。
* 発散：議論を通して幅広い選択肢が出てくる。結論が見えないテーマについて議論し、明確でないまま終了してよい。
* 収束：議論を通していくつか選択肢から一つの選択肢に絞られる。メンバー間での意思決定や合意形成など、最終的に何かしらの結論を出す。
* 共有：情報共有や前提確認など、チームメンバーと認識を合わせる。議論を特に必要としない。
個々のアジェンダアイテムがどれに分類されるのかあらかじめ示しておくことで、ミーティングの参加者が「どのような視点で」「どのような発言をするべきか」を理解することができます。例えば、「発散」のアジェンダアイテムであれば自由に意見を発してよく、新しいアイデアを出すことが重要だと分かります。反対に「収束」のアジェンダアイテムであれば、マイルストーン達成のためにどのようなアウトプットをつくっていくべきか、現実的な結論を導くことが必要だと分かります。また「共有」のアジェンダアイテムであれば、疑問点を質問しできるだけ認識を合わせることが重要だと分かります。
# プロジェクトの環境整備
## 実現したい状態と価値基準
Project Sprintが目指すのは、プロジェクトチームにより自律的にプロジェクトが推進されている状態です。そのためには、以下のようなことが必要となります。
* 各メンバーが、進化する目的や目標を深く理解・共感している
* 各メンバーが、誰かのマネジメントに頼らず自身の役割を理解している
* 各メンバーがチームに対してなんでも意見ができ、常に改善が行われている
これらを実現してProject Sprintの実施を助けるプロジェクト環境について記述します。
## 環境を作ることで実現したい状態
Project Sprintはスクラムと同様、「経験主義」と「リーン思考」に立脚しています。
**経験主義**とは、物事を理論よりも経験に基づいて考えようとする態度であり、スクラムガイドでは「知識は経験から生まれ、意思決定は観察に基づく」とされています。複雑性・不確実性が高く予測の難しい状況に対応するには、体系立った知識や完成したノウハウを正確に運用することよりも、実践や経験から得た知識を活かすことが重要だと考えているのです。
また、**リーン思考**とは、価値を生み出さない無駄な行動を省略し、本質に集中するという考え方です。今いるところにおいて最も重要な問題を特定し集中的に完結するというサイクルを繰り返すことにより、無駄を最小限に抑えながら価値を最大化することができます。
予測可能性を最適化してリスクを制御するためにProject Sprintでは、定例ミーティングで環境に対する認識を常に揃えなおしながら反復的かつ漸進的にプロジェクトを進めるというアプローチを採用しています。プロジェクトにおける取り組みについて定期的な振り返りと改善を繰り返しながら、ゴールに至るまでの道筋を少しずつクリアにするとともにチームが自律的に学習し成長することを目指します。
## 経験主義を支える「透明性」「検査」「適応」
経験主義においては、「透明性」「検査」「適応」という三つの柱の実現が重要であるとされています。Project Sprintではこれらを、以下のように解釈しています。
**透明性**：\
創発的な取り組み過程や作業は、作業を実行する人とその作業を受け取る人にとって可視化されている必要があります。透明性とは、この可視化が標準化され、共通理解が持たれているということです。重要な意思決定は作成物をどのように認知するかに大きく左右されます。作成物の透明性が低いと、リスクを高める意思決定につながってしまう可能性があります。
**検査**：\
成果物や合意されたマイルストーンに向けた進捗状況は、頻繁かつ熱心に検査される必要があります。潜在的な望ましくない変化や問題を検知するためです。定例ミーティングは変化を引き起こすように設計されており、この変化により問題を検知しやすくなります。\
透明性の実現により、検査が可能になります。透明性が実現されていない状態での検査は、誤解を招く無駄なものになってしまいます。
**適応**：\
取り組み過程の何らかの側面が許容範囲を逸脱していたり、達成すべきものとして設定されたマイルストーンが受け入れがたい場合には、現在適用されている取り組み過程やマイルストーンの構成要素を調整する必要があります。逸脱を最小限に抑えるため、この調整はできるだけ速やかに行われなくてはなりません。\
関係者に権限が与えられていないときや、自己管理がなされていないときは、この適応が難しくなります。
## チームの価値基準
スクラムガイドでは、チームが成功するかどうかは、次の5つの価値基準を実践できるかどうかにかかっているとされており、Project Sprintもこれに共感しています。これらの価値基準は、チームの作業・行動・振る舞いの方向性を示しています。
**確約(Commitment)**： チームは、ゴールを達成し、お互いにサポートすることを確約します。
**集中(Focus)**： チームは、ゴールに向けて可能な限り進捗できるように、スプリントの作業に集中します。
**公開(Openness)**： チームとステークホルダーは、作業や課題を公開します。
**尊敬(Respect)**： チームのメンバーは、お互いに能力のある独立した個人として尊敬し、一緒に働く人たちからも同じように尊敬されます。
**勇気(Courage)**： チームのメンバーは、正しいことをする勇気や困難な問題に取り組む勇気を持ちます。
チームのメンバーは、定例ミーティングや作成物を用いながら、これらの価値基準を学習し探求します。これらの価値基準がチームや一緒に働く人たちによって具現化されるとき、経験主義が効果を発揮し、信頼が構築されるのです。
# 継続的改善アプローチ
Project Sprintでは、ミーティングを通じて継続的にプロジェクトの進め方を改善すること（最適化）を目指しています。これらの最適化のための取り組みを総称して「継続的改善アプローチ」と呼んでおり、これはさらに「振り返り」「テンショントリアージ」「ロールセッション」という三つの取り組みに分けられます。プロジェクトの状態やタイミングに適した手法を使うことで、様々な問題や違和感を発見しやすくなります。
## **継続的改善アプローチとは**
継続的改善アプローチは、今後のプロジェクトをよりよい状態にするべく継続的に改善しつづけるための仕組みです。この仕組みを通じてプロジェクトの進捗状況の共有のみならず、プロジェクトの進め方の継続的な改善ができるようになります。マイルストーンの開始時や終了時といった区切りのタイミングだけでなく、定期的にアクションを実施することが重要です。
代表的なアクションとしては「定期的に振り返りを実施して、プロジェクトをよりよい状態にするための改善策を検討する」ということになりますが、実施する視点によって考え方や最適なアプローチも変わってきますので、以下ではそれらについて記載します。
## **いつを見るか**
継続的改善アプローチの中では、\*\*「過去」・「現在」・「未来」\*\*の3つの視点でものごとを捉えます。一般的に「振り返り」といえば「過去」を見るものですが、Project Sprintの継続的改善アプローチでは、「過去」だけではなく「現在」や「未来」にも目を向けることが重要と考えています。
### **なぜ「現在」を見るのか**
「過去」だけではなく「現在」を見るのは、プロジェクトチームのメンバーが今どのような心境なのか（気になっていることや困っていることがないか）をリアルタイムに共有することが、チームの状況を改善していくために不可欠であると考えているからです。
これが「過去」を見る振り返りだけであるならば、問題が共有されるのはその問題が起こってしまった後である可能性が高いのですが、「現在」を見ることで、問題が顕在化もしくは拡大する前に共有し対処することができるようになります。
そのため、Project Sprintでは、定例ミーティングの中でのテンションの共有という形で、定期的に現在の心境を出し合うことを推奨しています。
### **なぜ「未来」を見るのか**
一方、「未来」を見て改善をするのは、実施しようとしているプラン自体を改善してプランの精度を高めていくためです。
リスクマネジメント的視点ではありますが、重要なのは「想定しているプランを実行したら、何が起こるだろうか」という仮想経験を共有することです。それによって、仮に失敗しそうであれば事前にプランを改善することができ、プランそのものの質を高めることができます。また、仮にプランそのものに問題がない場合も、一度仮想的に経験をしているので、実際に実施する際に余裕を持って対応することができます。
「未来」を見て改善するアプローチの1つとして、「プレモータム・シンキング」と呼ばれるものがあります。これは、日本語に訳すと「事前検死」というもので、これから取り組んでいくプロジェクトが失敗したと仮定して、その失敗要因を分析したり、解決策を検討するというアプローチです。ビジネスにおいては、「早く失敗すること」の重要性がよく指摘されますが、プレモータム・シンキングは最も早く失敗を体験できるものであり、その意味でも有効な1つの手法といえます。
### **現在の気持ちを共有することの重要性**
プロジェクトを改善していく上で、このように「過去」「現在」「未来」を見ることはいずれも重要ではありますが、中でも重要なのは「現在」の気持ちを共有することだと考えています。 気持ちを吐き出すことができる場があることで、前述のようにプロジェクトの課題が改善されるだけでなく、メンバーのプロジェクトへの参加感の向上にもつながるものです。
## **何を見るか**
では、「過去」「現在」「未来」について、具体的に何を見るとよいでしょうか。 [Project Sprint 101](/ja/v3.2/theories/101)でも記載しているように、Project Sprintでは単にプロジェクトの進捗を見るのではなく、プログレスやチーミングが理想の状態にあるかどうか、またプロセスが円滑に機能しているかどうかがプロジェクトを進めていく上で重要な要素と考えており、継続的改善アプローチでも、これらを検証することを推奨しています。
以上、「いつを見るか」ということと「何を見るか」という視点をかけ合わせると、それぞれの項目において想定される基本的な問いは下表のような事項になります。 これは基本形ですので、各プロジェクトにおいて必要な問いそのものを定義した上で、そのプロジェクトにとって必要な検証・改善が行われる状態を構築していきましょう。
| 視点 | 過去 | 現在 | 未来 |
| ----- | ---------------------------------------------------------- | --------------------------------------------------------------- | ----------------------------------------------- |
| プログレス | ・マイルストーンを達成できたか？
・最終的な成果に繋がるアウトプットを積み重ねることができたか？
| ・今アウトプットすべきものを理解・納得しているか？
・アウトプットすべきものについて不安や心配事はないか？
| ・ゴールを達成できそうか？
・もし失敗するとしたら、何が原因になりそうか？
|
| チーミング | ・メンバー相互の期待値は明確だったか？ | ・メンバー相互の期待値に違和感はないか？ | ・今の期待値のままプロジェクトを進めたら、将来的にどうなるだろうか？ |
| プロセス | ・プロジェクトやミーティングの進め方はどうだったか？ | ・プロジェクトやミーティングの進め方に違和感はないか？ | ・今の進め方を継続したら、将来的にどうなるだろうか？ |
# Project Sprintの成功指標
Project Sprintは、チームが
* プログレスにおける理想の状態
* チーミングにおける理想の状態
を目指しながらプロジェクトゴールに向かって進んでいくのを助けるために、ものごとの捉え方・考え方や、最適化を促進するための仕組みを提供しています。
したがって、Project Sprintが成功しているかどうかは、プログレスとチーミングにおいて理想の状態が実現しているか、という観点で評価することができます。
ここで、いずれの成功についても、絶対的に到達すべき状態はないということに注意しなければなりません。プロジェクトゴールは変化しうるものであり、また何をもって理想的なチームとするかはプロジェクトの規模や時間軸などに依存します。
一方、Project Sprintが正しく導入・運営されていれば、それは理想の状態が実現されているということを意味します。そのため、Project Sprint自体の活発さをもって成功指標とみなすことができます。
したがって、成功指標は次の3つと言えます。
* タスクがリストアップされ、遂行されているか
* タスクを遂行する中で発見された問題点やテンションが、ミーティングにおけるアジェンダアイテムとしてリストアップされ、議論・意思決定されているか
* ミーティングにおける議論・意思決定の結果が、次にやるべきこととしてタスクに落とし込まれているか
# Practices
このドキュメント群では、Project Sprintの基本的な概念の説明と実践方法が順を追って説明されます。理論編であるTheories及び実践編であるPracticesから成り、それぞれを上から順番に読み進めていくことで、Project Sprintを概念として理解した上で、実際のプロジェクトに取り入れて使うための知識を得ることができるようになっています。
すでにプロジェクトマネジメントの経験がある方が新しい方法論としてProject Sprintをインプットするために読むことはもちろん、すでにProject Sprintを導入している方も、効果的な活用のための基盤固めとして読むことができます。
| Contents | Theories | Practices |
| ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Project Sprint 101 | [Project Sprint 101](/ja/v3.2/theories/101) | WIP |
| プロジェクトライフサイクル | [5つのサイクル](/ja/v3.2/theories/project_lifecycle) | WIP |
| プロジェクトゴールとマイルストーン | プロジェクトゴールとは
マイルストーンとは
| プロジェクトゴールの設定
マイルストーンの設定
プロジェクトゴールとマイルストーンの見直し
|
| トラック | [トラックとは](/ja/v3.2/theories/tracks) | [トラックの設定](/ja/v3.3/practices/tracks) |
| 期待値とロール | [期待値とロール](/ja/v3.2/theories/rolls) | チームメンバーの理解とロールシートの利用
ロールの確認
|
| 定例ミーティング | [定例ミーティングの重要性](/ja/v3.3/theories/meetings) | ミーティングの設計
ミーティングの進行方法
タスクの設定
ミーティングロールの確認
ミーティング環境についてのノウハウ
|
| アジェンダ | [アジェンダとは](/ja/v3.3/theories/agenda) | [アジェンダアイテムの要素](/ja/v3.2/practices/agenda) |
| プロジェクトの環境整備 | [プロジェクトの環境整備実現したい状態と価値基準](/ja/v3.3/theories/project_environments) | 情報共有環境の構築
スタンドアップの導入
|
| 継続的改善アプローチ | [継続的改善アプローチ](/ja/v3.2/theories/continuous_improvement_approach) | 振り返り
テンショントリアージ
ロールセッション
|
| Project Sprintの成功指標 | [Project Sprintの成功指標](/ja/v3.3/theories/success_metrics) | - |
| Project Sprintの発展 | - | [コントリビューターとしての参加の方法](https://github.com/copilot-jp/project-sprint/blob/master/JA/v3.2/practices/broken-reference/README.md) |
# プロジェクトゴールの設定
## プロジェクトゴールの設定
プロジェクトチームが目指すのはプロジェクトゴールを達成することですから、まずはこれを定義する必要があります。これからあなたが取り組むプロジェクトは、何を目指しているのでしょうか？新規事業のコンセプトを開発して、新しい価値を創出することでしょうか。それとも、システムの効率化など、決まった価値を実現するために取り組むことでしょうか。いずれにせよ、プロジェクトで目指すこと = プロジェクトゴール を明確にしましょう。
プロジェクトゴールは、プロジェクトチームが主体的に0から設定することができる場合もあれば、プロジェクトの外部で設定されたものが与えられることもあります。外部から与えられたものである場合には、それをそのままプロジェクトゴールとして置くのではなく、まずはプロジェクトチームとしてそのプロジェクトゴールが明確で納得感のあるものかどうかを確認し、必要に応じて調整を加えます。
チームメンバー間の相互理解やプロジェクトに対する認識合わせが一定程度進んでいるプロジェクトであれば、すんなりとプロジェクトゴールを設定し、続けてトラックやマイルストーンの設定などプロジェクトに関する具体的な議論を展開しはじめられるでしょう。一方、いきなりプロジェクトゴールの設定に取り組むことが難しい場合、まずはミーティングを設定して議論することから始めます。
具体的なステップは以下のようになります。
### 1. 認識を合わせてはじめてチームになる
プロジェクトは、最初からプロジェクトゴールや目的が明確な状態で立ち上がるのではなく、緩やかな方向性が示されたり外部からプロジェクトゴールの原型を提示されたりしてスタートすることがほとんどです。メンバーが最初に集まった時点で、プロジェクトゴールやプロジェクトの範囲・内容が適切に共有されていることはありえません。仮に各メンバーが自分なりの理解をしていたとしても、他のメンバーとの認識の擦り合わせができていないからです。
全く面識のないメンバーが集められてプロジェクトが始まるとき、プロジェクトの範囲・内容に対する共通認識ができていない段階では、まず「なぜこのメンバーがここに集まっているのか」の認識合わせから始めなくてはいけません。ミーティングを設定してそれぞれのメンバーがプロジェクトの目的をどう認識しているかを話し合い、擦り合わせを行います。
はじめのうちは、プロジェクトそのものやプロジェクトの目的に対する現状認識をメンバーそれぞれが言語化して書き出してみる、というような形で構いません。それらを擦り合わせているうちに個々人の認識が変わることもあるでしょうし、一度プロジェクトゴールが設定されてプロジェクトが開始されてからも、環境の変化に応じてチームとして認識を揃えなおすことは重要です。
また、集まったメンバーで何ができるのかを把握する必要があります。メンバーそれぞれが自分自身のバックグラウンドやスキルセットを開示し、どういった展望を持ってこのプロジェクトに向き合おうとしているかを話し合いましょう。[期待値とロール](https://github.com/copilot-jp/project-sprint/blob/master/JA/v3.2/theory/rolls.md)や[チームメンバーの理解とロールシートの利用](/ja/v3.2/practices/rolls)も参考にしてください。
ここまでの認識が揃ってはじめて、集まったメンバーは「プロジェクトチーム」を目指すチームとして歩き始めることができるようになります。
### 2. 共通のプロジェクトゴールを目指すプロジェクトチームになる
次に行うのは、目指すべきプロジェクトゴールを定義するためのミーティングです。さらに時間を取った検討が必要な場合は、この工程を「プロジェクトゴールを作ること」そのものをゴールとする事前プロジェクトと捉えてもよいでしょう。このときは、プロジェクトを取り巻く基本情報（プロジェクトの背景・事業に関する予備知識・制約やイベント）の収集をマイルストーンとし、プロジェクトゴールを明文化することを目指します。
プロジェクトチーム全員で話し合いながらプロジェクトゴールを作っていくのが理想ではありますが、実際には、まず全員で発散的に意見を出し合ったのち、誰かがその内容を取りまとめて明文化する、という流れを辿ることが多いでしょう。最終的な内容は、改めて全員の納得が得られている状態である必要があります。
プロジェクトゴールは、プロジェクトチームの合意と納得によって定義され、プロジェクトチームとして認識が揃ったものでなくてはなりません。プロジェクトチームの意思が適切に反映され共通認識を得た明確なプロジェクトゴールが設定されることで、各メンバーはその達成に現実味と納得感を持ってプロジェクトに参画できるようになります。こうしてチームは、共通のプロジェクトゴールを目指す「プロジェクトチーム」と呼べるようになります。
## 設定後の扱い
設定したプロジェクトゴールは、チームメンバーがいつでも参照できる状態にしておきます。こうすることで、チームメンバーがプロジェクト中にタスクを実行する際やチームメンバー間で議論を行う際に、プロジェクトゴールへの認識がずれていないかすぐに確認することができるようになります。
また、プロジェクトゴールはプロジェクトを取り巻く環境の変化や実際にタスクを遂行する中で分かってきたことを踏まえて、プロジェクト中にいつでも変更することが可能です。ただし、変更についてプロジェクトチームで納得することが必要です。
実際の変更の流れは[プロジェクトゴールとマイルストーンの見直し](/ja/v3.3/practices/reviewing_project_goals_and_milestones)で解説します。
# マイルストーンの設定
## マイルストーンの設定
トラックが設定できたら、続いてマイルストーンを設定しましょう。マイルストーンも[プロジェクトゴールの設定](/ja/v3.3/practices/project_goals)と同様、当該トラックの推進を担うメンバー全員で話し合いながら作っていくのが理想です。ただしこれも実際には、最初は全員で発散的に意見を出し合ったのち、誰かがその内容を取りまとめて明文化する、という流れを辿ることが多いものです。もちろん、最終的には全員が納得している状態になっている必要があります。そのため、全員が理解しやすいように、極力シンプルなものになるよう心掛けてください。
制約やイベントを意識しながら、「いつまでにどのような作成物が必要か/どういう状態になっている必要があるか」がある程度具体的にイメージできる場合には、プロジェクトゴールを見据えながらバックキャストでマイルストーンを設定していきます。具体的なイメージがまだ持ちにくい場合には、まず取り組めるところからフォアキャストでマイルストーンを設定することになります。
マイルストーンがうまく設定できないときは、トラックの設定やプロジェクトゴールを見直す必要があるかもしれませんし、マイルストーン設定の前提となるチームメンバー同士の認識合わせがまだ十分でないのかもしれません。必要に応じて、前の工程に戻って議論をしましょう。
## マイルストーンの粒度・抽象度
各トラックの自律性を保つには、トラック間が疎結合である必要があります。そのため、マイルストーンを設定する際には、相互の依存関係・影響関係を判断できるような粒度・抽象度を意識しましょう。具体的には、あるトラックのマイルストーンの達成のために別のトラックのマイルストーンを調整することができたり、他のトラックを担っているメンバーが「あのトラックのマイルストーン達成のためにはこのようなアウトプットを提供してあげたほうがいいな」と自発的に提案できたりするような記述が理想です。
マイルストーンの粒度や抽象度は、プロジェクトゴールとの距離感によってばらつきが出てもかまいません。通常、直近のマイルストーンは期日・作成物ともに具体的なものになり、プロジェクトゴールに近いものほど抽象的で大まかな記載になります。ただし、マイルストーンを見たチームメンバーがそれぞれ自分で意思決定をして行動できる程度には、具体性のあるものである必要があります。そのマイルストーンに直接関わっているメンバーが理解できることはもちろん、直接関わっていないメンバーが見たときにもそれに応じて自身で必要な行動を取れるようなものにしてください。また、プロジェクト外のステークホルダー（例えば、プロジェクトの結果を報告するべき人や、プロジェクトの結果を受けて業務に影響が出る人）が客観的に見たときに、何を作成物として作ろうとしているのかすんなり理解できるかどうかも、適切なマイルストーン設定のための一つの判断基準になるでしょう。
## 設定後の扱い
設定したマイルストーンは、チームメンバーがいつでも参照できる状態にしておきます。こうすることで、チームメンバーがプロジェクトの進行中にタスクを実行する際やチームメンバー間で議論を行う際にマイルストーンやその先のプロジェクトゴールを常に意識し、認識がずれていないかすぐに確認することができるようになります。
また、マイルストーンはプロジェクトを取り巻く環境の変化や実際にタスクを遂行する中で分かってきたことを踏まえて、プロジェクト中にいつでも変更することが可能です。ただし、変更についてプロジェクトチームで納得することが必要です。
実際の変更の流れは[プロジェクトゴールとマイルストーンの見直し](/ja/v3.2/practices/reviewing_project_goals_and_milestones)で解説します。
### マイルストーンマップの利用
マイルストーンを共有し参照可能にしておくためのツールとして、「マイルストーンマップ」を利用することをおすすめします。
マイルストーンマップとは、プロジェクト内のマイルストーンの全体像を把握するためのシートのことです。あるべき姿や状態を分かりやすくシンプルに表現することで、チームメンバー全員が共通認識を持てるようになります。また、複数のマイルストーンを横断的に記載することで、マイルストーン間の関係や設定の背景を含めたより深い理解を可能にします。
マイルストーンマップには次のような要素を、ゴールまでのマイルストーン全体を俯瞰して見られるような形で盛り込みます。各要素はプロジェクトの変化に応じて常に更新し、形骸化させないことが重要です。
* ステージ名: マイルストーン達成までの期間の意味的な位置づけ（このステージで実際に何をするのかを分かりやすく記載する）
* 期日の開始日: 通常は直前のマイルストーン終了日の翌日
* 期日の終了日（必須）: マイルストーン完了の期日
* 作成物（必須）: マイルストーン完了時に出力されていなくてはならない作成物
* 達成したい状態: マイルストーン完了時点でプロジェクト内部がどのような状態になっていてほしいか、またはプロジェクトの作成物を受けてプロジェクトの外部がどのような状態になっていてほしいか、といったあるべき姿や理想の状態を記述
* 達成の基準・目標値：どうなっていればマイルストーン達成と言えるかを具体的に記述
* メモ: 補足情報を自由に記載する
### マイルストーンマップの具体的な記入要素と入力内容サンプル
例えば「ある問題を解決できる新規サービスを立ち上げる」というゴールを持ったプロジェクトがあり、このためにいくつかのマイルストーンを設定した場合、マイルストーンマップを表形式で作成すると以下のようになります。
| マイルストーン | 顧客の定義とリスト化の完了 | 必要な機能の検討完了 | リリースのための環境整備 |
| ------- | --------------------------- | -------------------------------------------- | ---------------------------------------- |
| 期間 | 6/1〜6/30 | 7/1〜8/31 | 9/15〜11/14 |
| ステップ名 | 【調査】顧客の存在を確かめる | 【企画】このサービスで問題を解決できるか確かめる | 【実現】市場価値があるサービスか確かめる |
| 作成物 | ・顧客定義シート
・顧客リスト
| ・UXマップ
・サービス機能リスト
・顧客ヒアリング（5人分）
| ・クラウドファンディング実験結果まとめ
・ユーザーアンケート
|
| 達成したい状態 | ・顧客に今回の問題があることをメンバーが確信できている | ・問題解決のために必要な機能が把握できている | ・このサービスの市場価値に定量的な根拠がある |
| 達成の基準 | ・どこに顧客が存在するのかわかっている | ・リリースに含めるべき最低限の機能が特定できている | ・次のステップとしてリリースできる機能の範囲が決まっている |
| メモ | | | |
# プロジェクトゴールとマイルストーンの見直し
[プロジェクトゴールの設定](/ja/v3.3/practices/project_goals)でも述べたように、プロジェクトゴールやマイルストーンは固定的なものではなく、むしろ環境の変化に応じて柔軟に書き換えられたり進化したりしうるものなので、いつでも見直してよく、また必要に応じて見直さねばならないものです。市場環境の悪化や組織の体制変更、稟議スケジュールの変更といったプロジェクトの外部環境の変化によって調整が必要になることもあれば、プロジェクトを進める中で得られた洞察やチームメンバーの共通認識・役割期待の遷移といった内部的な変化によって進化することもあります。
## 見直しが必要となる具体的な場合
プロジェクトのゴールの見直しをするべきタイミングは、次のようなときです。
1. 外部環境の変化やプロジェクトの進行の結果、プロジェクトゴールそのものを見直したほうが良いことが分かったとき
2. マイルストーンが予定通りに達成されなかった結果、プロジェクトゴールを見直したほうが良いことがわかったとき
3. その他何らかの理由でチームメンバーがプロジェクトゴールを見直したほうがよいと考えたとき
マイルストーンに関しては、プロジェクトゴールよりも頻繁に見直しが必要となることがあるでしょう。見直しをするべきタイミングは、次のようなときです。
1. あるマイルストーンが達成されたとき
2. あるマイルストーンが予定通りに達成されないことが明らかになったとき（予定よりも遅い場合、早い場合のいずれも含む）
3. プロジェクトゴールに対してあるマイルストーンが適切ではないことが明らかになったとき
4. プロジェクトゴールが変わったためマイルストーンも変える必要が出てきたとき
5. その他何らかの理由でチームメンバーがマイルストーンを見直したほうがよいと考えたとき
## 見直しの手順
プロジェクト内外の環境は絶えず変化し続けているので、それに対応するためには、とにかく定期的にプロジェクトゴールとマイルストーンを見直し、現状に即していないところや違和感のある所がないかを確認することが重要です。プロジェクトゴールやマイルストーンは、全員が集まる場で見直しや調整を繰り返し、違和感を抱くメンバーがいれば納得いくまで議論することで、チームメンバー全員が共通認識と納得感を持てる状態にしていく必要があります。
プロジェクトゴールやマイルストーンの見直しの実施についてもミーティングのアジェンダアイテムとなるため、事前にアジェンダアイテムの提出を行う必要があります。
プロジェクトゴールやマイルストーンを変更する際には、変更の前後を並べて見せるなど、その差分を明確にし、積極的に共有するようにしてください。これは、「知らない間にプロジェクトゴールやマイルストーンが変わっていた」と感じるメンバーが出てきてしまわないようにするためです。
プロジェクトゴールやマイルストーンはプロジェクトにおけるあらゆる場面で参照され、チームメンバーにとって指針となるべきものです。そのため、変更後のプロジェクトゴールやマイルストーンにもチームメンバー全員が確実に納得できている状態を作ってください。
# トラックの設定
## 1. プロジェクトゴールに対する認識を揃える
[プロジェクトゴールの設定](/ja/v3.3/practices/project_goals)や、[マイルストーンの設定](/ja/v3.2/practices/milestones)を参考に、まずはプロジェクトの目的やプロジェクトゴールを明確化し、チームメンバー間での共通認識にします。
## 2. メインのトラックを設定する
プロジェクト全体・プロジェクトチーム全体の主な状態を把握するトラックを、メインのトラックとして設定します。このトラックには、プロジェクトゴールの達成のために必要な大きなマイルストーンと、プロジェクト全体に関わるアイデアの共創や問題の共同解決のために必要な定例ミーティングの両方が入力されることが多いでしょう。プロジェクトメンバーによる定例ミーティングを設定し、このトラックだけでなくプロジェクト全体のマイルストーンマップを毎週確認できるようにしておきましょう。
メインのトラックにおけるマイルストーンとステップは、外部制約や主要なイベントなどに応じて設定していくのがふつうですが、そういったものが明確に存在しない場合は、3か月ごとなどの定期的なタイミングでステップを区切ってマイルストーンを設定します。たとえば何らかのサービスを立ち上げるようなプロジェクトであれば、各ステップごとに顧客に対して提供したい価値を記述するのもよいでしょう。
各ステップの終点となるマイルストーンの成果物・あるべき姿には、提供したい価値・バリューを、具体的な作成物や数値目標、達成したい状態などに落とし込んで記載しましょう。メインのトラックのマイルストーンは、このあと設定される各トラックにおけるマイルストーン達成の集積によって達成されてゆくという構造になります。そのため、メインのトラックのマイルストーンを参照することで、このあと作成する各トラックのメンバーが自律的に各トラックのマイルストーンを決定できるような内容が書いてあることが望ましいです。
メインのトラックのマイルストーンを設定するときには、「各トラックの成果物の仕上がりが合わさる、または仕上がりを合わせたい具体的なタイミングはいつか」というところから考えてみるとイメージしやすくなるかもしれません。
## 3. メインのトラックの他に必要なトラックを設定する
メインのトラックのマイルストーンを達成するために必要なものを部分部分に分割して、その他のトラックを作っていきます。
基本的には、トラック同士は依存関係が少ない疎結合な状態になるように分割します。つまり、個々のトラックだけで自律して作業を進められるような分け方です。こういった分け方ができず、強い依存関係のあるタスクベースで進捗をコントロールする必要がある場合には、別途ガントチャートを作って把握するのがよいでしょう。
各トラックで個別にミーティングが必要な場合や、各トラックで個別にチームになった場合は定例ミーティングを置きますが、それぞれのトラックには必ずしも定例ミーティングを設定する必要はありません。
また、各トラックは原則として疎結合なものとして存在しますが、進捗状況の共有やマイルストーンの詳細な確認などを目的として、トラック間での連携やトラックを横断したミーティングを置くこともあります。このときは、連携が必要となるトラックの上部構造として、連携用のミーティングを置くトラックを設定するとよいでしょう。
# チームメンバーの理解とロールシートの利用
## チームメンバーの基本情報
より良いチームを目指す前提となるのが、チームメンバーに関する理解です。例えば、プロジェクトに関わるメンバーに次のことを確認しておきましょう。
* あなたの名前はなんですか？普段はどのような組織や会社に所属している人ですか？
* あなたはどのような人ですか？例えばスキルセットはどのようなものがありますか？これまでにどのような仕事にかかわってきましたか？
* あなたがこのプロジェクトに対して貢献を期待されていることはなんですか？
* あなたはプロジェクトに対する専任メンバーですか、兼任メンバーですか？いずれにせよ、あなたがこのプロジェクトに割ける時間はどのくらいですか？
こうしたことをプロジェクトの最初に知っておくことは、ロールの設定における助けになります。
## ロールシートの利用
ロールとチームメンバーは一対一の関係になるとは限らず、またロールの種類も決まったものはない一方、決まったロールはきちんと明文化して合意する必要があります。
そのため、「いまのロールの状況」を明文化して参照できる状態にしておくための「ロールシート」を利用することをおすすめします。
ロールシートには、例えば次のような要素を盛り込みます。
* ロール名
* ロールが果たす責任(どういう目的でそのロールが必要とされ、何を果たすロールなのか）
* そのロールを担う人
これらを一つのドキュメントとしてまとめ、常に最新のものに更新しておくことで、いまの各メンバーに対する期待値を把握することや、期待とズレがあった場合の議論が可能になります。
# ロールの確認
ロールも、プロジェクトゴールやマイルストーンと同様、変化しうるものです。定例ミーティングとそこでのアジェンダの議論を通して、ロールは常に見直され、改めて認識合わせが行われることになります。
## ロールの確認
[期待値とロール](/ja/v3.2/theories/rolls)でも述べたように、自律的なチームであるためには、チームメンバー各々の責任・役割が共有されて認識が揃っており、メンバー相互の期待値に齟齬がないことが重要です。
チーミングの「理想の状態」には、明確な到達点がありません。なぜなら「ここまで達成したら理想のチームだ！」というものが決めにくいからです。そこでProject Sprintでは、常に「チームが今の時点より良い状態になること」を目指します。 そして、ここでの「より良い」とは、チームメンバー同士の果たすべき役割=ロールについての期待値がそろっている状態のことを指します。つまりロールの確認とは、チームメンバーの持つ互いの役割についての期待値がそろっているかを確認することを指します。
ロールの確認をするべきタイミングは、次のような時です。
1. 過去に定義されたロールが、より詳細にブレイクダウンして考えられるようになり、細かい認識合わせが必要になったとき
2. プロジェクトの進行により過去に定義していないような役割が生まれ、その役割を担うロールを明確化することが必要だと考えられるようになったとき
3. 過去に定義されてあるメンバーにアサインされていたロールが、周囲からの期待に添っていないとき。例えば、実際にはアサインされているメンバーとは別のメンバーがロールを遂行していたり、アサインされたメンバーが周囲からの期待値を満たしきれていなかったり、逆にアサインされたメンバーが自分は周囲からの期待値を満たせていないと感じていたりするとき
4. その他何らかの理由でチームメンバーがロールの確認をしたほうがよいと考えたとき
ロール確認の実施はミーティングのアジェンダアイテムとして扱われるので、確認が必要だと考える場合には事前にアジェンダアイテムの提出を行う必要があります。
## 明示ロールと暗黙ロール
Project Sprintでは、ミーティングロール以外には必ず設定しなければならないロールというものを決めておらず、それ以外のロールの定義についてはチームメンバーで合意することのみが必要な条件となっています。
しかし、この「チームメンバーの合意」は、必ずしも明示的なものとは限りません。チームで名前を決めて共有されるロールもある一方、プロジェクトを進めていくなかで、あるメンバーが自然に担っていく暗黙的な役割もあります。Project Sprintにおいて、前者は「明示ロール」と呼ばれ、後者は「暗黙ロール」と呼ばれます。
これらの区別は絶対的なものではなく、ある暗黙ロールが、何かのきっかけによって明示ロールとなることもありえます。
例えば、最初から暗黙ロールが十分に機能することはほとんどありません。つまり、「あの人がこれをやってくれるだろう」という阿吽の呼吸・暗黙の了解は、チーム発足初期にはあまり機能しないということです。多くの場合こうした暗黙ロールは一度「この人はこういう役割の人だ」という明示ロールとして表現され、この過程で期待値のすり合わせが行われます。その後、「あの人はこういう役割の人だからこれもやってくれるだろう」と、暗黙ロールも機能し始めるのです。チームメンバーの互いの期待値が合ってくると、未知の状況にも柔軟に対応できるようになります。
なお、暗黙ロールと明示ロールの割合はプロジェクトやチームによって異なるもので、最適なバランスもそれぞれ異なります。また、単純にロールの数が多いほうがよい、少ないほうがよい、といった点についても、一律の答えはありません。
ただし、ロールは次のような状態になっていることが望ましいとされます。
* チームメンバー間で、ロールの中でやるべきことがより細かい粒度で理解されているほどよい。
* そのチームにとって最もコストのかからない方法で、チームにとって必要十分なロールが共有されているほどよい。
* 各ロールのやるべきことをお互いにフォローできればできるほどよい。
# ミーティングの設計
[定例ミーティングの重要性](/ja/v3.2/theories/meetings)で記述した通り、ミーティングは定期的・反復的に開催される必要があります。
ミーティングに目的や完了の定義が明確に存在しうることもありますが、基本的にはミーティングは目的も到達すべき地点も持たず、その時々のアジェンダアイテムが投入されていく連続した箱のようなものと捉えるのがよいでしょう。ミーティングで議論すべきアジェンダの内容や性質は常に異なるため、どのようなアジェンダでも自由に提案できるよう、なるべく縛りを設けないでおくのです。
## 開催頻度
ミーティングの開催頻度は、週次/月次/隔週など、プロジェクトの性質やチームメンバーの人数などを勘案して任意に決めてください。ただし、Project Sprintの基本のメカニズムが「定期的・反復的なミーティングで各メンバーの取り組みの成果や作成物を共有し環境に対する認識を揃えることによって、各メンバーが同じプロジェクトゴールを目指して自律的に各自の次の行動に向かうことができるようにする。この繰り返しがプロジェクトを現在の状態から理想の状態に漸進的に近づけ、結果としてプロジェクトゴールが達成される。」であることを考えると、隔月以上の間隔でのミーティング開催は考えにくいでしょう。
## 参加者
各ミーティングの参加者はアジェンダに応じて必要十分な程度でかまいません。ここでいう必要十分とは、アジェンダに関して網羅的に議論でき（＝「誰かがいないから今日はこの話ができないね」ということがないようにする）、また議論をもとに正式な意思決定ができること（＝「誰かがいないから今日はこの話は決まらないね」ということがないようにする）を意味しています。もし参加人数が大人数(10人を一つの目安としてください）になっている場合は、必要以上の人数を集めていないか、確認してください。もしそうなってしまっている場合、アジェンダの議論と意思決定を目的としたミーティングではなく、単なる情報共有を目的とした会議になっている可能性があります。
とはいえ、ミーティングでは多様なアジェンダが提出される可能性があるので、最初にミーティングを設計する際には、あらかじめチームメンバー全員が集まることのできるミーティングを設定したほうがいい場合も多いでしょう。そうすることで、チームメンバー個々人の中にとどまっている情報を一斉に共有することができ、各チームメンバーはこのプロセスに参加するだけでプロジェクトの状況や思っていることについて自然と認識を合わせることができるようになります。
さらに、参加者が漏れなく参加でき、情報をリアルタイムに共有できるようなミーティング環境を整備するようにしてください。これは、前述の素早く効率的な認識合わせを実現するために重要なポイントとなります。具体的には、場所を問わず参加できるリモートミーティング環境の準備、その場で決まったことを共有できるドキュメントシェアサービスの利用、などを行うことになるでしょう。
## 定例ミーティングの要素
定例ミーティングを最適な状態で実施するには、会議のアジェンダの設定やファシリテーションの方法など、会議環境を整備しておく必要があります。具体的には、プロジェクトの内容やフェーズに応じて下記のような項目についてメンバー間で合意しておきましょう。
* ミーティンググランドルール
* ファシリテーション方法
* ミーティングでのメンバーの役割
* アジェンダパターン
* アジェンダの活用方法
* 議事録の活用方法
* 継続的改善アプローチの導入
# ミーティングの進行方法
## ミーティングの基本構成
この記事では、Project Sprintで行われるミーティングの基本となる進行方法を説明していきます。おおまかな構成としては次のようになっているので、これをまずはじめに頭に入れておくと、それぞれの内容を理解しやすいでしょう。
* 序盤：タスクの進捗報告、テンショントリアージ、アジェンダトリアージ
* 中盤：個別のアジェンダアイテムの進行
* 終盤：今回のミーティングから生まれたタスクの確認と、次回以降のミーティングのアジェンダ確認
さらに、特にミーティングの序盤と終盤は定型化しやすく、時間がたつにつれ、具体的な方法論や必要な時間、細かい順番が定まってきます。チームにとって最適なミーティングの「型」を見つけましょう。
## ミーティング序盤
ミーティングの最初に、タスクの進捗報告とテンショントリアージを行ってください。これらを通じて、前回のミーティングから今回のミーティングまでに起こったことについて、チームメンバー同士でアップデートを行います。議論の結果は、その日のミーティングで話すことを決める材料になります。
なお、タスクの進捗報告とテンショントリアージはそれ自体がアジェンダアイテムです。したがって、後述するアジェンダトリアージの前に実施されるものではありますが、これらのアジェンダアイテムの進行についてもモデレーターが担当する必要があります。
### タスクの進捗報告
初回のミーティングを除けば、前回までのミーティングを経て、何かしらの各自のタスクが生まれているはずです。これらのタスクの進捗状況を確認しましょう。
タスクを遂行した結果なんらかの作業結果が生まれている場合には、それをもとに話し合うべきアジェンダアイテムがないか確認しましょう。 もし作業結果がなくても、作業が思うように進まないという相談もありうるでしょう。このような場合も、これを解決するためにアジェンダアイテムとしてミーティング内で議論する必要がないか確認しましょう。
なお、この場で挙げるのではなく、ミーティング前にアジェンダアイテムとして提出しておいても構いません。
### テンショントリアージ
テンションとは、「プロジェクトに取り組む中で生まれた、他のメンバーに伝えたい違和感」のことです。具体的には、メンバー個人が思う「こうしたらもっと良くなるのに」という現状とよりよい状態の間のギャップ、ちょっとしたアイデア・気になること・不安などのことを指します。またトリアージとは、選別と優先順位づけをする行為のことを指します。
すなわちテンショントリアージとは、個々のチームメンバーが感じている違和感を提案に変えて全員で共有したうえで、今チームを改善するために必要なものを優先的に選び、解決しようとすることです。テンションをあげた本人が、テンションを違和感の解消のための具体的な提案に変換し、本人にとって納得のいく解決策を決定することが大切です。
テンションは一人一人が組織内で自律的に動くための原動力となるものです。重要なのは一人一人がテンションを感知することと、感知したテンションを無視しないことです。それぞれが感知したテンションを自律的に処理することでチームが回り、プロジェクトゴールに近づいていくのです。
前述のように、テンションとは現状とよりよい状態のギャップから生まれるものです。そのため、テンショントリアージを行う際にプログレス及びチーミングの理想の状態や、プロジェクトゴール・マイルストーン、チームのロール）を参照できるようにしておくことが、テンションを挙げるために効果的です。
テンショントリアージで共有した内容は、解決のためのアクションに落とし込むようにしてください。具体的には、直接的な改善策が明確な場合、テンションを解決するための新たなタスクとしてください。また、直接的な改善策が明確でない場合や時間をかけた議論が必要な場合は、新たなアジェンダアイテムとして改善策を探すようにしてください。
なお、この場で挙げるのではなく、ミーティング前にアジェンダアイテムとして提出しておいても構いません。
具体的なテンショントリアージの方法は、[現在の心の声を活用する：テンショントリアージ](/ja/v3.3/practices/tension_triage)で解説します。
## アジェンダトリアージ
続いて、アジェンダトリアージを行ってください。アジェンダトリアージには、ミーティングに出席しているチームメンバー全員が参加します。
トリアージとは、ここでも同じく選別と優先順位づけをする行為のことを指します。すなわちアジェンダトリアージとは、その日のミーティングで話したいことを参加者全員で出し合い、優先的に話し合うべきものを選ぶことです。
モデレーターは、アジェンダトリアージを主体的に進行し、最終的な合意まで持っていくことが求められます。
この時点で、2種類のアジェンダアイテムが用意されているはずです。
1. ミーティング前に提出のあったアジェンダアイテム
2. タスクの進捗報告またはテンショントリアージの結果、新たに生まれたアジェンダアイテム
アジェンダトリアージは、これらのアジェンダアイテムのうち、その日のミーティングで議論すべきものと議論する順番を決める作業です。プロジェクトゴールやマイルストーンを参照しながら、優先順位をつけていきましょう。
事前に提出されたアジェンダアイテムの内容に不明点があれば、チームメンバーはそれに対して納得できるように質問をしましょう。このとき、ファシリテーターにはこのアジェンダアイテムの改善に関する議論を活発にすることが求められます。
アジェンダアイテムの内容が明確になった結果、あらかじめ設定されていた所要時間だと余りそう、または逆に足りなそうである、と判明することがあります。このときは、アジェンダアイテムの所要時間を調整しましょう。
それぞれのアジェンダアイテムの内容が明確になったら、優先順位をつけましょう。マイルストーン達成のために必要なアジェンダアイテムから議論するのが基本です。直近のマイルストーンの内容と、その期限までに開催できるミーティングの回数を考慮しましょう。マイルストーンを参照した結果、個別のアジェンダアイテムの議論においてどのような結論まで持っていくべきかを調整することもあります。
なお、事前に提出されたアジェンダアイテム以外に、チームメンバーから見て緊急性が高いアジェンダアイテムがある場合には、チームメンバーの合意を得た上で、それらのアジェンダアイテムが優先されます。
優先順位をつけた結果、当日話し合うことができないアジェンダアイテムは、次回以降のミーティングに持ち越しましょう。こうしたアジェンダアイテムがあるとき、アジェンダトリアージは、次の3種類の中から優先順位づけをすることになります。
1. ミーティング前に提出のあったアジェンダアイテム
2. タスクの進捗報告またはテンショントリアージの結果、新たに生まれたアジェンダアイテム
3. 前週までの持ち越しアジェンダアイテム
当日話し合うことになったアジェンダアイテムは、元々の優先順位に従って議論してもかまいませんし、内容に応じて関連するテーマについて続けて議論できるように順番を並べ替えることもできます。並び替えを行うメリットは、関連しあうテーマ同士について続けて議論するほうが効率的であることです。
## ミーティング中盤
### 個別のアジェンダアイテムの消化
アジェンダトリアージが終われば、一つ一つのアジェンダアイテムについて議論しましょう。
一つ一つのアジェンダアイテムは、すでに記載されているアジェンダアイテムの内容に基づき、それぞれのアジェンダアイテムオーナーがメインで進行します。ファシリテーターは議論の内容と最終的な結論がより良くなるように議論に参加しましょう。レコーダーは、議論の経緯・内容をリアルタイムで記録し、参加者が常に見ることのできる状態にしましょう。
### アジェンダアイテムの取りまとめ
モデレーターは、アジェンダアイテムを取りまとめ、ミーティングを通して確認や調整を行います。ただし、以下で説明するアジェンダアイテムの確認や調整は、すべてチームメンバーと話し合いながら決めるべきものです。ここでも、直近のマイルストーン達成のためにはどのような選択が有効か、が基本的な判断基準となりますが、最終的にはチームメンバーの話し合いで出た結論が優先されます。
まず、それぞれのアジェンダアイテムが議論されている最中は、予定されている時間内にそのアジェンダアイテムが終わるように気を配ってください。
ただし、議論の内容に応じて、アジェンダアイテムが予定した時間より延長してしまったり、逆に早く終わってしまうことがあります。 アジェンダアイテムが予定した時間より延長している場合、モデレーターはそのアジェンダアイテムを次回に持ち越すようにするか、一定の結論が出るまで議論を続けるかを検討してください。
次回に持ち越す場合、このアジェンダアイテムは、前週までの持ち越しアジェンダアイテムの一つとして扱われます。これまでの過程でアジェンダアイテムの詳細はすでに完成しているはずですが、ここまでで議論した内容もあわせて把握するために、レコーダーが記録した内容も一緒に確認できるようにしておきましょう。
一定の結論が出るまで議論を続けることにしたときは、他のアジェンダアイテムの時間を短縮して調整するか、場合によっては他のアジェンダアイテムを次回以降のミーティングに繰り越すようにしてください。
アジェンダアイテムが予定よりも早く終わってしまった場合、他のアジェンダアイテムの時間を延ばして余裕を持って議論できるようにするか、次回以降に繰り越すようにしていたアジェンダアイテムからその時のミーティング中に先に話し合うべきものがないか、検討してください。また、ミーティングを早く終えることを選択するのも可能です。
また、あるアジェンダアイテムを議論した結果、新しく話し合うべき内容、つまり新たなアジェンダアイテムが生まれることがあります。このとき、当日の追加アジェンダアイテムとして扱うか、次回以降に持ち越すかを検討する必要があります。
当日の追加アジェンダアイテムとして扱うときは、以下のいずれかの対応を取ってください。
* 他のアジェンダアイテムの時間を短縮して調整する
* 他のアジェンダアイテムを次回以降に繰り越す
* ミーティングの参加者全員に確認して、ミーティングの時間を延長する
もしアジェンダアイテムの内容が明確な場合は当日の議論も可能ですが、そうでない場合は次回以降に持ち越すのがよいでしょう。次回以降に持ち越すときは、このアジェンダアイテムはミーティング前に提出のあったアジェンダアイテムの一つとして扱われます。
前週までの持ち越しアジェンダアイテムと違うのは、アジェンダアイテムの内容が明確になっていない点です。したがって、ミーティング中に生まれたアジェンダアイテムについては少なくともアジェンダアイテムオーナーを明確にした状態でミーティングを終えましょう。そして、アジェンダアイテムオーナーは次回のミーティング前にアジェンダアイテムの内容を明確にしておくようにしてください。
## ミーティング終盤
ミーティング終了時には、今回のミーティングから生まれたタスクの確認と、次回のミーティングアジェンダの確認を行ってください。これによって、今回のミーティングの結果と、次回のミーティングまでに何をするべきかを確認することができます。これらの作業の前提として、マイルストーンの確認を行うことも効果的です。これによって、次回のミーティングまでに何に対してどこまで取り組むべきかの優先順位付けをしやすくなります。
なお、これらの確認もそれ自体がアジェンダアイテムなので、モデレーターが担当する必要があります。
### 今回のミーティングから生まれたタスクの確認
今回のミーティングで取り上げたアジェンダアイテムの議論を経て、チームメンバーがやるべきこと、つまりタスクがいくつか生まれているはずです。レコーダーの記録をもとにして、生まれたタスクを確認し、リストアップしましょう。リストアップしたタスクには、具体的な行動内容、担当者、期限を明確にするようにしてください。
### 次回以降のミーティングのアジェンダ確認
実際にミーティングで取り上げるアジェンダアイテムが確定するのはミーティングの当日ですが、毎回のミーティングの終了時に、次回以降のミーティングで話し合うべきアジェンダアイテムについて議論しておきましょう。このようなアジェンダアイテムには例えば次のようなものがあります。
* 次回以降に持ち越しになったアジェンダアイテム
* 進捗確認など、あらかじめタイミングを決めて議論するべきとされるアジェンダアイテム
事前にチームメンバー全員で確認することで、アジェンダアイテムオーナーのアジェンダアイテム提出漏れや、持ち越したアジェンダアイテムの内容の不備を防ぎやすくなります。
# タスクの設定
Project Sprintには、ミーティング終盤にそのミーティングを通じて生まれたタスクの確認を行い、次回のミーティングの序盤でそれまでのタスクの進捗報告を行うというサイクルがあります。 [ミーティングを開催する](/ja/v3.3/practices/holding_meetings)で解説したように、タスクを記載する際には、
* 具体的な行動内容
* 担当者
* 期限
を明確にすることが最低限必要です。
しかし、これだけでは、タスクの進捗報告の際に「想定していたのと違った」「いつまでたっても完了しない」といったことが起こりえます。これは、タスクの担当者が何をやればよいかよくわかっていないことが原因であったり、そもそも担当者の設定や期限の設定が間違っていたりすることが原因です。そして、さらにその根本的な原因は、チームメンバ―の間で認識のずれがあり、正しくタスクが定義できてないことにあります。
そこで、次の要素についてもあわせて検討し明文化することで、そうした認識ずれをあらかじめ防ぐことができます。
## 目的
なぜこのタスクを行う必要があるのかについての記述です。
タスクはプロジェクトゴールとして設定された成果物・成果に漸進的に近づくためのものです。また、タスクを遂行する中で他のメンバーに伝えたい問題点や違和感（**テンション**）が生まれ、プロジェクトを最適化するための材料となります。そのためにそれぞれのタスクがプロジェクトゴールにどのように結びついているかを意識しながら目的を明文化することが有効です。
目的を記載することで、誰がやるべきか（担当者）や、いつまでにやるべきか（期限）も簡単に判断することができます。
## 想定アウトプット・想定作業時間
タスクをこなした結果生まれるアウトプットについての具体的イメージの記述です。なお、アウトプットとは、チームメンバーが割り当てられたタスクを完了したことで生まれた結果のことです（Tips3参照）。
例えば、ある資料作成のタスクがあったとき、「スライド～～枚で、見出しはしっかりと作りこむ。本文や記載する図表はダミーでよい」と記述することで、目的に沿ったアウトプットなのかどうかを確認しやすくなります。この場合、タスクの目的が「プレゼンテーション直前のリハーサルに使うため」であればアウトプットとしては不十分でしょうし、「プレゼンテーションの大枠の内容を内々に議論するため」であれば、必要十分なアウトプットになるでしょう。目的が達成できるのであれば、必ずしも完成度を突き詰める必要はありません。それよりも、最小限のアウトプットを確実に作ることを意識しましょう。
また、想定アウトプットのイメージをすり合わせるためには、タスクを終えるまでの想定作業時間を明文化することも効果的です。前述の資料作成のタスクであれば、ある人は1時間しかかからないと思っていた作業が、別の人は4時間もかかると思っていた場合、作りこみのレベルに差がある可能性が高いということが分かります。
さらに、これらの作業を通じてタスクの粒度が大きいと判断された場合は、そのタスクを細かく分解し、ミーティングごとに確実にアウトプットが可能なサイズにしましょう。
# ミーティングロールの確認
ミーティングを効率的・効果的に運営するために必要な役割（ミーティングロール）を、個々人に割り当てましょう。
具体的には、次のようなロールの割り当てが必要です。
* ファシリテーター：議論を促進し成果の質を向上させることで、プロジェクトの成果をよりよいものにするロール。アジェンダの改善やその後の議論形成のサポート・助言を行う。
* モデレーター：アジェンダの取りまとめや進行サポートを行うことで、議論のプロセスを最適化し進行の時間を維持するロール。アジェンダの合意から、その後のアジェンダ進行とタイムキープ、議論の結果決定された次の行動の明確化、ミーティング終了時の次回のアジェンダの決定までを担う。
* コーディネーター：ミーティング環境を整えるロール。適切なミーティングルームの確保（オンラインの場合はミーティング環境の設定）、ホワイトボードやモニターの手配をする。
* レコーダー：議事録を作成するロール。ミーティング後に議事録を共有するだけでなく、ミーティングの進行中にもリアルタイムで作成中の議事録を共有し、メンバー間の認識のずれを即座に修正することができるようにする。
チームメンバーの人数によって、一人が複数のロールを担当することもありますし、何もロールを持たないメンバーがいることもあります。ただし、いずれのロールも誰かが担うようにしてください。会議の参加者全員がそれぞれの視点から助言しうるので、ファシリテーターは全員が担うことになるでしょう。また、モデレーター、コーディネーター、レコーダーは属人性が低いため、固定ではなくミーティングごとに持ち回りにすることが望ましいものです。これにより、ミーティング運営に関する問題点や最適な方法について、参加者全員が自分から考えやすくなります。
ロールの分担はミーティングの都度話し合って決定してもかまいませんが、あらかじめミーティング前に分担や持ち回りのルールを決めておくと、当日のミーティング運営が効率的になります。
# ミーティング環境についてのノウハウ
Project Sprintで意図されているミーティングの効果を得るためには、効率的なミーティング環境の構築が欠かせません。「ミーティング環境の最適化自体についてもチームメンバーで議論し、改善していけること」が、Project Sprintのもたらすものですが、この点についてはすでにいくつかのベストプラクティスが得られていますので、ここではそれらを紹介します。
## アジェンダの取りまとめ
プロジェクスプリントではアジェンダの取りまとめが非常に重要です。
例えば、次のようなアジェンダの取りまとめ作業が発生します。
* ミーティング前のアジェンダアイテムの提出と必要な内容の編集
* ミーティング開始後のアジェンダアイテムの追加と必要な内容の編集
* ミーティング開始後のアジェンダアイテムの順番変更
* ミーティング開始後のアジェンダアイテムの繰り越し
これらの作業はすべてファシリテーターの主導のもと、チームメンバー全員で行われます。そのため、アジェンダを全員で確認・編集でき、かつ同じミーティングの中でのアジェンダアイテムの順番変更、ミーティングをまたいだアジェンダアイテムの移動ができる環境をつくっておきましょう。
## ミーティング中の時間管理
アジェンダ管理に不可欠な前提が、ミーティング中の時間を的確に把握することです。オンライン / オフラインいずれの場合も、ミーティングに参加しているチームメンバーが時間を把握できるよう、目に入る位置にタイマーと時計を配置しましょう。
タイマーは、「このアジェンダアイテムにあとどれくらい時間をかけられるのか」を把握するのに必要です。
時計は、ミーティング時間の開始時間・終了時間を把握するのに必要です。ミーティングの開始時間の遅れ、延長はつねに起こりうるものですが、絶対時刻を示す時計があると開始・終了の基準を把握・調整することができます。
## 議事録作成
ミーティングはチームメンバーで認識のズレをなくし、必要な物事を決める重要な場です。ミーティングの後に各自が必要なタスクに取りかかり、次のミーティングでその結果を持ち寄ることを考えると、ミーティングの内容は極力ミーティングの最中に明文化しながら確認、共有しておくことが効率的かつ効果的です。
また、レコーダーがメインで議事を記録するものの、内容に間違いがある場合は最も正しい認識を持つ人がその場で修正してしまったほうがよいでしょう。そのため、共同編集ができるドキュメントツールを議事録作成用ツールとして導入し、ミーティング中に画面表示しながらリアルタイムで議事録作成をすることをおすすめします。
## ホワイトボード
ミーティングでは口頭での説明、資料を用いた説明が行われることが多いと考えられますが、それに加え重要なのが手書きの情報による認識合わせです。手書きで図示/文章化することで、きちんとした資料になっていなかったり、口頭で明確に伝えきれていなかったりした内容を伝えやすくなります。これもProject Sprintにおいて重要な「認識のズレをなくす」ことに大いに役立ちます。
なおここでいうホワイトボードは、オフラインミーティングにおける物理的なものに限りません。オンラインミーティング用のホワイトボードツールもありますので、そういったものを利用してもかまいませんし、むしろ保存のしやすさという点ではこちらのほうが優れている場合もあります。
また、議事録を画面表示しながらリアルタイムで作成すると、議事録自体がホワイトボードと同様の役割を果たします。この観点からも、議事録の作成とリアルタイム共有は非常に重要です。
# アジェンダアイテムの要素
毎回のミーティングが始まる前に、各チームメンバーはあらかじめアジェンダアイテムを提出します。アジェンダアイテムには、少なくとも次のような内容が含まれている必要があります。
* アジェンダアイテム名（何を議論したいか端的に記載する）
* 進行方法（具体的な議論の進行イメージ）
* 目的や背景（そのアジェンダアイテムを議論したい理由）
* 誰から誰への議論か（誰がそのアジェンダアイテムのオーナーであり、誰と議論したいのか）
* 時間（議論完了までの所要時間）
これらは、「何について話し合いたいのか」をアジェンダアイテムオーナーが明らかにするために必要な情報ですが、これに加えて「どの程度まで話し合いたいのか」までを明らかにしておくと、議論がより進めやすくなります。
具体的には、次の要素を追加で記載するようにします。
* あるべき姿(アジェンダアイテムを議論した後に目指す状態)
* 結果(議論が終わったときに生まれている明示的なアウトプット）
* 参加者がアジェンダアイテムの完了について納得していることを証明する手段
これらの要素がそれぞれ事前に明らかになっていればいるほど効率的・効果的な議論ができるようになります。アジェンダアイテムオーナーだけでは記載することが難しいものを補足したり、他のチームメンバーから見て分かりにくいものを分かりやすくしたりして、これらの要素が記載できるように議論を整理していくことが、ファシリテーターに求められる役割です。
# 情報共有環境の構築
チーム全体で情報の透明性を最大限に高める環境を実現するため、「ここにアクセスすればすべての情報に辿りつくことができる」という状態をつくります。プロジェクトメンバーは、すべての情報、すべてのメンバー間のやりとりに、いつでもどこからでもアクセス可能にしておきます。
すべての情報を全員が閲覧でき、同時・共同編集が可能にしておくことも重要です。
* **ミーティング・アジェンダ**: プロジェクトメンバー全員がミーティングの目的やアジェンダの内容を知ることができるようにしましょう。
* **マイルストーン**: プロジェクトメンバー全員が最新のマイルストーンに常にアクセスできる必要があります。マイルストーンを常に意識することで、逸脱や問題を早期に検知して対応することができます。
* **議事録**: ミーティング中、作成途中の議事録をリアルタイムで全員が閲覧できるようにしておきましょう。認識のずれを合わせるのに効果的です。
* **ファイル共有**: プロジェクトメンバー全員が同じ情報にアクセスできるよう、ファイルの共有場所を用意しましょう。
* **スケジュール共有**: スケジュール調整に必要な限りで、メンバー間の個人カレンダーを共有するようにしましょう。これは、メールなどによって都度日程調整をするのではなく、チームメンバーのスケジュール状況が一か所に集まっており、ミーティングのスケジュールを効率的に設定・変更できるようになることを意味します。
* **タスク共有**: プロジェクトを通じて生まれるタスクを共有できる場所を用意しましょう。個人でタスク管理するのではなく、プロジェクトチームで共有のタスク置き場を用意することで、お互いが何をするべきか / するつもりだったか、を確認するコミュニケーションがしやすくなります。
これらは一般的なプロジェクトマネジメントで語られる要素と大きく異なりません。しかし、Project Sprintでは、それらの要素すべてにおいて、「情報の透明性をいかに担保するか」という点を中心に考えるべきです。
Project Sprintでは、プロジェクトのゴールやマイルストーンの設定、ロールの設定と調整をはじめ、様々なタイミングで「チームメンバーの納得を伴った合意」をつくることが必要になります。そのため、納得をつくるため = チームメンバーの情報格差をなくすためにはどういったプロジェクト環境を用意するべきか、というポイントが重要視されるのです。
なお、ここに書いている要素は一例に過ぎません。プロジェクトごとに、チームメンバー間で最も最適なプロジェクト環境を整備していくように話し合うこともまた重要です。
# 振り返り
## **振り返りとは**
Project Sprintにおける振り返りとは、チームメンバーが過去のプロジェクトの内容についてレビューし、プログレス・チーミングそれぞれを改善する取り組みです。
そのため振り返りは、[ミーティングの進行方法](/ja/v3.3/practices/holding_meetings)で述べたテンショントリアージのようにミーティングごとに実施するものではなく、ある程度まとまった期間ごとに実施するものであり、またその分必要な時間もテンショントリアージよりも長くなります。この「まとまった期間」には、次の二つの種類のものがあり、いずれも併用して実施しましょう。なお、二つのタイミングが揃う場合は、同時に実施してもかまいません。
#### 1. マイルストーン終了時
マイルストーン終了という一つの区切りをタイミングとして設定するものです。このタイミングは、プロジェクトゴールに向けてどれくらい進んだかを振り返るのに適しています。また、当初予定していた進め方とのズレを振り返り、次のマイルストーン達成に向けて最適なキックオフを実施できるように準備することが可能になります。
#### 2. 定期的なタイミング
「何週間おき」「何か月おき」といった定期的な時間で設定するものです。これは、プロジェクトは不確実でどのような状態になるか予期できないものであるため、とにかく時間で区切って振り返りを行うという取り組みです。たとえば、マイルストーンがいつまでも達成できないという場合には、強制的に最適化のタイミングが訪れることで問題解決のきっかけになります。
いずれの場合でも、テンショントリアージ同様、振り返りの際にも、プログレスとチーミングそれぞれにおける理想の状態（＝プロジェクトゴール・マイルストーンとチームのロール）の変遷を参照できるようにしておくと「あのときこうすればよかった」「今後はこうすればよいのではないか」といった気づきを得やすくすることができます。
振り返りで取り扱う内容は、具体的なプロジェクトゴールへの進捗に向けた取り組み（プログレス）に関することであっても、チームの役割分担（チーミング）に関することであっても、ミーティングの進行（プロセス）に関することであっても、取り扱うことができます。
振り返りの実施についてもミーティングのアジェンダアイテムとなるため、事前にアジェンダアイテムの提出を行う必要があります。
## **一般的な振り返りの手法**
一般的な「振り返り」の手法は様々なものがありますが、ここでは比較的簡単に導入でき、汎用性も高い三つの手法を例として紹介します。
### **KPT（ケプト）**
KPTは、チームメンバーがこれまでのプロジェクトを振り返って感じた「良かったこと（Keep）」「改善したいこと（Problem）」を共有し、「今後改善のために取り組みたいこと（Try）」を話し合う法です。
**手順例**
1. チームメンバーがそれぞれ Keep、Problemを付箋に記入する。
2. 記入が終わったら、チームメンバーがそれぞれ記入したKeep、Problemを説明しながらホワイトボードに貼って共有する。
3. ホワイトボードに貼られている付箋のうち、関連があったり似た内容・テーマのものがあれば近くにまとめておく。
4. 共有内容を受けてチームメンバーがそれぞれTryを付箋に記入する。
5. 記入が終わったら、チームメンバーがそれぞれ記入したTryを説明しながらホワイトボードに貼って共有する。
6. Tryのうち実際に取り組むものを決め、今後のアクション（誰がいつまでに何をするか）を明確にする。
### **+/Δ（プラス/デルタ）**
+/Δは、チームメンバーがこれまでのプロジェクトを振り返って感じた「プラス=うまくいっていること、続けたいこと」、「デルタ=改善したいこと」を共有する手法です。KPTと似ていますが、意見の分け方が2つになるため、よりシンプルな実施が可能です。
**手順例**
1. チームメンバーがそれぞれ プラス、デルタを付箋に記入する。
2. 記入が終わったら、チームメンバーがそれぞれ記入したプラス、デルタを説明しながらホワイトボードに貼って共有する。
3. ホワイトボードに貼られている付箋のうち、関連があったり似た内容・テーマのものがあれば近くにまとめておく。
4. 共有内容を受けて、改善したいことについては改善するためのアイデアをチームで議論する。
5. 出たアイデアのうち実際に取り組むものを決め、今後のアクション（誰がいつまでに何をするか）を明確にする。
### **YWT(ワイダブリューティー)**
YWTは、チームメンバーがこれまでのプロジェクトにおいて「やったこと（Y）」を共有し、それを通じて「わかったこと（W）」を共有し、「つぎにやること（T）」を話し合う手法です。最初に実際に経験したことを見直すところからスタートすることで、より地に足のついた議論ができるという利点があります。
**手順例**
1. チームメンバーがそれぞれ「やったこと（Y）」を付箋に記入する。どのような業務を実施したか等、事実ベースで記載する。
2. 記入が終わったら、チームメンバーがそれぞれ記入した内容を説明しながらホワイトボードに貼って共有する。
3. ホワイトボードに貼られている付箋のうち、関連があったりテーマをまとめられそうなものはまとめる。
4. チームメンバーがそれぞれ「やったこと（Y）」から「わかったこと（W）」を付箋に記入する。
5. 記入が終わったら、チームメンバーがそれぞれ記入した内容を説明しながらホワイトボードに貼って共有する。理由や背景を深掘り・抽象化して、別の事例で活用できるレベルに昇華できるとよい。
6. ホワイトボードに貼られている付箋のうち、関連があったりテーマをまとめられそうなものはまとめる。
7. 共有内容を受けてチームメンバーがそれぞれ「つぎにやること（T）」を付箋に記入する。
8. 記入が終わったら、チームメンバーがそれぞれ記入した内容を説明しながらホワイトボードに貼って共有する。
9. 「つぎにやること（T）」のうち実際に取り組むものを決め、今後のアクション（誰がいつまでに何をするか）を明確にし、タスクリストに記載できるとよい。
# テンショントリアージ
## **テンショントリアージとは**
[ミーティングの進行方法](/ja/v3.3/practices/holding_meetings)で解説したように、テンショントリアージとは、個々のチームメンバーが感じている違和感を提案に変えて全員で共有したうえで、今チームを改善するために必要なものを優先的に選び、解決しようとすることです。これによって、メンバー一人一人が思う「こうしたらもっとより良くなるのに」という現状とよりよい状態の間のギャップ、ちょっとしたアイデア・気になること・不安などを共有し、解決のためのアクションにつなげることができます。
テンショントリアージは毎回のミーティングで行う取り組みであり、主にチームメンバーの今現在の気持ちにフォーカスしているものです。現在を見ることで、問題が顕在化もしくは拡大する前に共有し対処することができるようになります。 また、タイムリーに気持ちを吐き出すことができる場があることで、メンバーのプロジェクトへの参加感の向上にもつながります。
## **具体的な手順**
テンショントリアージは、例えば次のような手順で実施しますが、これはあくまで一例です。上記の目的をより効率的・効果的に達成するために、ご自身のチームにとって最適な方法にアレンジしてみてください。
1. チームメンバーがテンションをあげる
2. テンショントリアージのアジェンダアイテムオーナーがテンションを一つ読み上げ「何が必要ですか？」とテンションをあげた人に問いかける
3. テンションをあげた人は次のいずれかを選択し、そのあと自分が必要としていることを回答する
* 他メンバーへのタスクのリクエスト
* 他メンバーからの情報やヘルプ提供のリクエスト
* ロールの調整・変更・追加に関するリクエスト
* 単なる情報提供や感想の共有
1. テンショントリアージのアジェンダアイテムオーナーは、次のいずれかを選択してテンションをあげた人に提案する
* その場で解決する
* タスク化する
* アジェンダアイテム化する
2. テンションをあげた人がこれで必要なことが得られれば終了とし、得られなければ、続けて議論する(3と4を詳しく繰り返す)
3. 時間の許す限り、他のテンションについても2\~5の手順を繰り返す
# ロールセッション
## **ロールセッションとは**
プロジェクトの各ステップの開始時には、次のマイルストーンまでにチームがどのように進んでいくかを擦り合わせ、個人がやるべきこと、他のメンバーに期待することについて認識を揃える必要があります。まず、改めて今回のマイルストーンの内容とプロジェクトゴールを確認します。その後、各メンバーがこのマイルストーンにおいてどのようなタスク・ロールを担うのかの認識を合わせます。
ロールセッションは、この各メンバーの役割と期待値の擦り合わせのために行われます。プロジェクトチーム全員が自分の役割の範囲でリーダーシップを発揮できるように、メンバーそれぞれのやるべきこと、苦手なこと、期待されることなど、内的な自己認識と外的な期待値を明文化して共有し、相互に役割を擦り合わせます。
## **具体的な手順**
ロールセッションは、例えば次のような手順で実施しますが、これはあくまで一例です。上記の目的をより効率的・効果的に達成するために、ご自身のチームにとって最適な方法にアレンジしてみてください。
1. 各メンバーが自分のやるべきことを付箋に書き出し共有する
2. 他のメンバーにヘルプしてほしいこと、他のメンバーへの期待値を付箋に書き出し共有する\
（アサインできる対象がわからなかったり現時点ではいなかったりしても問題ない）
3. 未アサインのヘルプ内容や期待値につき、メンバー相互に議論してアサイン先を決める
4. 改めて自分のやるべきことを精査し、各々承認し、議論して深める
5. これまでの議論を踏まえて、各メンバーが自分の役割を更新し共有する
# Essentials
Project Sprintは、プロジェクトチームがプロジェクトゴールの達成へと進んでいくための、考え方や仕組みを提供します。
プロジェクトのすべての要素は、プロジェクトチームによって規定されるものです。プロジェクトチームは、以下の原則に従って行動します。
* プロジェクトチームは、プロジェクトチーム自身の意思を反映させたプロジェクトゴールを設定し、外部環境の変化やプロジェクト内で得られる洞察に応じてアップデートを繰り返しながら、納得感と達成への現実味を持って、漸進的にプロジェクトゴールの達成を目指します。
* プロジェクトチームは、各メンバーが作成物を継続的に出力することを通して、他のメンバーに伝えたいアイデアやテンションを発見し、漸進的にプロジェクトゴールの達成に向かいます。
* プロジェクトチームは、全員参加の定期的・反復的なミーティングで認識を揃え、全員が納得できるプロジェクトゴールやロールを設定し更新しつづけるとともに、アイデアの共同創造と問題の共同解決を行います。
* プロジェクトチームは、各メンバーの責任・役割・期待値を共有します。各メンバーは、己の役割を果たすべく自律的に行動を起こし、信頼と敬意をもって相互に支援を行います。
# Reference
このドキュメントは、Project Sprintの背景にある諸メソッド・概念・文献について記載しています。
Project Sprintは、以下の理論・メソッド・文献・概念を参考にしながら、様々なプロジェクトで実践した経験則をもとに独立したメソッドとしてまとめられています。
### Manifesto for Agile Software Development
アジャイルソフトウェア開発宣言と12の原則の価値に共感しています。\
[https://agilemanifesto.org/](https://agilemanifesto.org)
### **Scrum & Scrum\@Scale**
スプリントという短期間に反復的な実践により成果物を提供する概念、透明性や自己組織化という概念、ミーティングによる認識合わせや意思決定をプロセスの中心におくこと、レトロスペクティブ(振り返り)のプロセスなどを参考にしています。\
Project Sprint という名称は Scrum のスプリントからインスピレーションを得ています。\
[https://www.scrumguides.org/](https://www.scrumguides.org)
### ティール組織
セルフマネジメントや進化する目的の概念に共感しています。\
[https://www.reinventingorganizations.com/](https://www.reinventingorganizations.com)
### **Holacracy**
チーミング・アクティビティでコアの要素となっているロールとテンションやその関係性は、ホラクラシーの考え方を参考にしています。\
[https://www.holacracy.org/](https://www.holacracy.org)
### 心理的安全性
エイミー・エドモンドソンにより提唱された概念です。チームのなかでどのような発言でも大丈夫だと信じられている環境をつくる重要性に共感しています。\
Googleが行った生産性の高いチームの調査プロジェクトにより注目が集まりました。\
Google re:Work\
### センスメイキング理論
カール・ワイクを中心に発展されている理論です。正確性よりもチームの納得に重きを置いている考え方に共感しています。
# v3.1
## **CODEとは**
**CODE**とは、Project Sprintについて説明したドキュメント群の総称です。
### [**Tutorial**](/ja/v3.1/tutorial)
Project Sprintの基本的な概念の説明と実践方法が順を追って説明されており、読みながらProject Sprintを実際に導入することができます。 Project Sprintというものの概要を手早く理解したい方は、まずはTutorialのProject Sprint 101をお読みいただくとよいでしょう。このページは、「Project Sprintの基本メカニズム」「Project Sprintを理解するために把握しておくべき前提」「Project Sprintを活用するためのコア・アクション」の三本立ての構成になっています。Project Sprintをアクションベースで理解することで、実際の活用イメージが掴みやすくなることを期待しています。
### [**Essentials**](/ja/v3.0/essentials)
Project Sprintの核となる行動規範がシンプルに述べられており、そこからProject Sprintが立脚する思想や価値観を理解することができます。Tutorialの通読後に改めてEssentialsをお読みいただくと、Project Sprintの最重要箇所をより把握しやすくなるでしょう。
### [**Reference**](/ja/v3.1/reference)
Project Sprintの背景にある諸メソッド・概念・文献について記載されており、Project Sprintの効率的な理解が可能になり、また今後のメソッドのアップデートに関わりそうな情報を知ることができます。さらに、背景を知ることでメソッドの応用も可能になります。
## **ドキュメントの比較表**
| ドキュメント名 | Tutorial | Essentials | Reference |
| ------- | ------------------------- | ------------------------------- | -------------------------------------------------------- |
| 記載内容 | 基本的な概念の説明と実践方法 | 核となる行動規範 | 背景にある諸メソッド・概念・文献 |
| 効果 | 基本の理解、導入手順、具体的なノウハウが理解できる | Project Sprintが立脚する思想や価値観が理解できる | 効率的なProject Sprintの理解、メソッドのアップデートに関わりそうな情報、応用のための知識が得られる |
# Tutorial
このドキュメント群では、Project Sprintの基本的な概念の説明と実践方法が順を追って説明されています。
全体を通して4つの章から構成されており、上から順番に読み進めていくことで、Project Sprintを実際のプロジェクトで使うことができるようになっています。
まだProject Sprintを導入していない人が学習のための最初の一歩としては使うことはもちろん、すでにProject Sprintを導入している人も、実施のための基盤がためとして読むことができます。
## **1. はじめに**
最初に読んでほしいProject Sprintの概要を紹介しています。
1.1. [Project Sprint 101](https://github.com/copilot-jp/project-sprint/blob/master/JA/v3.1/tutorial/broken-reference/README.md)
## **2. 準備しよう**
Project Sprintを始めるにあたって準備しなければいけないことを記載しています。まずはここで決めた仕組みをもとにして、Project Sprintがスタートします。
2.0. [プロジェクトライフサイクル](/ja/v3.1/tutorial/section2-0)
2.1. [プロジェクトの環境整備](/ja/v3.1/tutorial/section2-1)
2.2. [プロジェクトゴールとマイルストーンを設定する](https://github.com/copilot-jp/project-sprint/blob/master/JA/v3.1/tutorial/broken-reference/README.md)
2.2.1. [プロジェクトゴールやマイルストーンの設定が難しいときの始め方](https://github.com/copilot-jp/project-sprint/blob/master/JA/v3.1/tutorial/broken-reference/README.md)
2.2.2. [トラック：プロジェクト遂行の単位](/ja/v3.1/tutorial/section2-2/section2-2-2)
2.2.3. [トラックの設定方法](/ja/v3.1/tutorial/section2-2/section2-2-3)
2.3. [チームメンバーを知り、ロールを設定する](/ja/v3.1/tutorial/section2-3)
2.4. [ミーティングを設計する](https://github.com/copilot-jp/project-sprint/blob/master/JA/v3.1/tutorial/broken-reference/README.md)
## **3. やってみよう**
Project Sprintによって実際にプロジェクトを運営していく方法を記載しています。「準備しよう」で作った仕組みを動かしていきましょう。
3.1. [ミーティングの準備をする](https://github.com/copilot-jp/project-sprint/blob/master/JA/v3.1/tutorial/broken-reference/README.md)
3.2. [ミーティングを開催する](https://github.com/copilot-jp/project-sprint/blob/master/JA/v3.1/tutorial/broken-reference/README.md)
3.2.1. [タスクを設定する](/ja/v3.1/tutorial/section3-2/section3-2-1)
3.3. [ミーティング環境についてのノウハウ](https://github.com/copilot-jp/project-sprint/blob/master/ja-v3.1.0/tutorial/tutorial/section3-3.md)
## **4. 改善しよう**
Project Sprintによってプロジェクトを改善する仕組みを記載しています。「やってみよう」で行ったことをもとに、どんどんプロジェクトを改善していきましょう。
4.1. [継続的改善アプローチ](https://github.com/copilot-jp/project-sprint/blob/master/section4-1.md)
4.1.1. [過去の経験を活かす：振り返り](https://github.com/copilot-jp/project-sprint/blob/master/JA/v3.1/tutorial/broken-reference/README.md)
4.1.2. [現在の心の声を活用する：テンショントリアージ](https://github.com/copilot-jp/project-sprint/blob/master/JA/v3.1/tutorial/broken-reference/README.md)
4.1.3. [未来の展望と仮説：ロールセッション](https://github.com/copilot-jp/project-sprint/blob/master/JA/v3.1/tutorial/broken-reference/README.md)
4.2. [プロジェクトゴールとマイルストーンを見直す](https://github.com/copilot-jp/project-sprint/blob/master/JA/v3.1/tutorial/broken-reference/README.md)
4.3. [ロールを確認する](/ja/v3.1/tutorial/section4-3)
4.4. [Project Sprintの成功指標](/ja/v3.3/theories/success_metrics)
## **5. さらに興味のある方へ**
Project Sprintを学習・実践し、自らもメソッド作りに改善提案や貢献をしたいと思われる方向けに、その方法について記載しています。
5.1. [コントリビューターとしての参加の方法](https://github.com/copilot-jp/project-sprint/blob/master/JA/v3.1/tutorial/broken-reference/README.md)
# Project Sprint 101
Project Sprintは、プロジェクトチームがプロジェクトゴールを設定したりプロジェクトゴールに向かって進んだりするのを助けるために、ものごとの捉え方・考え方や、最適化を促進するための仕組みを提供します。
Project Sprintの基本のメカニズムは、「定期的・反復的なミーティングで各メンバーの取り組みの成果や作成物を共有し環境に対する認識を揃えることによって、各メンバーが同じプロジェクトゴールを目指して自律的に各自の次の行動に向かうことができるようにする。この繰り返しがプロジェクトを現在の状態から理想の状態に漸進的に近づけ、結果としてプロジェクトゴールが達成される。」というものです。
ここでは、このメカニズムをうまく取り入れるためのコアとなるアクションとその前提を説明し、「準備しよう」「やってみよう」「改善しよう」における個別のドキュメントの内容を理解しやすくします。
### 前提
* プロジェクトは、変化しつづける環境と目的に常に追随するための小さな実験である。
* プロジェクトとは、「全体」としての課題に取り組む過程のうち、現状のプロジェクトチームで推進・達成に現実味が持てる「部分」を切り出したものである。
* プロジェクトゴールは、「全体ゴール」の達成に寄与する「部分ゴール」である。
プロジェクトは、プログレス、チーミング、プロセスの3要素からなる。
* プログレスは、プロジェクトの成果物やゴールにフォーカスした活動である。
* チーミングは、チームメンバーの関係性にフォーカスした活動である。
* プロセスは、プロジェクトチームがプロジェクトゴールに向かって進んでいくための手続きにフォーカスした活動である。
* プロジェクトには、プロジェクトチームとプロジェクトゴールが不可欠である。
* プロジェクトチームは、プロジェクトゴールに対する共通認識をもち、その達成に向けて相互に協力し合うメンバーの集まりである。
* プロジェクトチームの役割は、よりよい形でプロジェクトゴールに向かっていくために、個々のメンバーの活動の前提を与えることである。
* プロジェクトゴールは、プログレスゴールとチーミングゴールから成り、いずれもプロジェクトチームによって定められる。
* プログレスゴールとは、プロジェクトの成果として目指すべき状態が達成されたり作成物が出力されたりすることである。
* チーミングゴールとは、相互に期待値を共有し合う自律的なプロジェクトチームが形成されることである。
* プロジェクトチームがプロジェクトゴールに近づくために最も重要なのは、ミーティングとそこにおけるアジェンダの議論である。
* ミーティングとは、チームメンバーが一時的に同一の環境に固定されてリアルタイムで会話をすることにより、素早く効率的な認識合わせと、全員にとって納得感のある意思決定をする場である。
* アジェンダとは、個人から出力されたアイデアや問題を、他のメンバーと共有し次の行動を決定するために明文化したものである。
* プロジェクトの理想の状態とは、次に述べるコア・アクションがプロジェクトチームとしても個人としても円滑に実行され、プロセスがサイクルとして繰り返されている状態である。
### コア・アクション
* プロジェクトチームは、自身の意思を反映させたプロジェクトゴールを設定し共有する。
* そのために、ミーティングで環境への認識を揃え、各メンバーが納得できるプロジェクトゴールを設定する。
* その結果、各メンバーは個人としてプロジェクトゴールに対する納得感と達成への現実味を持ち、自律的にアクションできる。
* プロジェクトチームは、メンバー間で各々の期待値に対する共通認識を持ち、チームにおける自身の役割や責任に納得してプロジェクトに取り組む。
* そのために、自身の役割や他のメンバーへの期待をミーティングで共有し認識を揃える。
* その結果、各メンバーが自分はチームのために何をすべきかを自律的に判断し実際にアクションできる。
* プロジェクトチームは、作成物を生み出すことにより、自ら設定したプロジェクトゴールに向かい漸進的に進む。
* そのために、各メンバーが作成物の出力に取り組み、その中で他のメンバーに伝えたいひらめきや違和感に出会う。
* その結果、ミーティングのアジェンダとして提出された各メンバーのひらめきや違和感をもとに、プロジェクトチームとしての意思決定が行われ、それを前提に各メンバーが自律的にさらに次のアクションに向かうことができる。
* プロジェクトチームは、プロジェクトゴールに向けた進捗や全体像を常に見直し、継続的に改善を行う。
* そのために、プロジェクトを一定の期間で区切って定期的・反復的なミーティングを実施する。
* その結果、環境の変化に応じ、納得感と共通認識を持ってプロジェクトやプロジェクトゴールを再定義し、適切な軌道修正をすることができる。
# プロジェクトライフサイクル
プロジェクトライフサイクルとは、プロジェクトが構想されてから完了に至るまでにプロジェクトチームが辿る一連のフェーズのことを指します。
Project Sprintにおいては、プロジェクトライフサイクルは構想期、形成期、自律準備期、自律推進期、統合期の5つのフェーズから成ると捉えます。プロジェクトチームが現在どのフェーズにあるのかによって、取るべき行動や達成すべき状態は異なります。そのため、このプロジェクトライフサイクルを理解し意識することによって、プロジェクトを効率よく進めることが可能になります。
## 構想期
プロジェクトはまず、プロジェクトソース（発案者）が抱いた希望を源として立ち上がります。このフェーズでは、プロジェクトソースの希望を明確化してプロジェクト立ち上げの理由や目的を整理し、目指すべき理想の状態を見据えた上で、プロジェクトがどのようなものになるべきかの仮説を立てます。そして、そのために最適なチームメンバーを決定することでプロジェクトチームを組成します。
## 形成期
ここからは、構想期で組成されたプロジェクトチームが主体となってプロジェクトを進めていきます。形成期は、プロジェクトチームの意思を反映したプロジェクトゴールを設定し、そのプロジェクトゴールを達成するために必要なリソースを把握するフェーズです。プロジェクトの目的や価値、生み出すべき成果を明確にしてプロジェクトゴールを設定し、そのプロジェクトゴールを相互に依存関係がなるべくないようにブレイクダウンしてトラックを作成します。
## 自律準備期
自律準備期は、このフェーズの後に続く自律推進期が1スプリント目からスムーズに走り出せるよう、環境を整えるためのフェーズです。プロジェクトの情報を整理して透明性を高め、定期的なミーティングで目線合わせを行います。\
各トラックごとに自律的な推進ができるよう整理し、必要に応じてトラック同士の定期的な連携や同期タイミングを設計します。また、定例ミーティングの方法やアジェンダのテンプレートなどを準備し全体で共有しておきます。自律推進期において漸進的・反復的にプロジェクトの進め方を改善できるよう、継続的改善アプローチも導入します。
## 自律推進期
さあ、環境は整いました。プロジェクトゴールにつながる成果を生み出していくために手を動かすフェーズです。自律推進期は、漸進的にプロジェクトゴールを目指すべく、定例ミーティングを軸とした隔週～3か月程度の小さなサイクルの反復として進行されます。これにより、環境の変化に立ち遅れることなく必要に応じてプロジェクトの再定義を行い、プロジェクトチームとして、そしてトラックごとに自律的にプロジェクトゴールを目指しつづけることができるのです。\
全トラックのマイルストーンは可視化され、状況に応じて更新されていなければなりません。また、それぞれのトラックで定期的な成果物の出力と、継続的改善アプローチによる最適化を行います。
## 結合期
プロジェクトゴールに向けてプロジェクトを収束させていく、または次のプロジェクトに向けた引継ぎを進めるフェーズです。そのためには、外部から求められているものを踏まえてプロジェクト完了の定義を把握しておく必要があります。全体ゴールに対する部分ゴールの達成として出力できる形でプロジェクトの成果を整え、外部に示せるようにします。
## 各フェーズにおけるProject Sprintの意義
Project Sprintの基本メカニズムが最もその効力を発揮するのは、プロジェクトチームが自律推進期にあるときです。定例ミーティングによる認識合わせと意思決定を経て、各メンバーが自律的に次の行動に向かっていくというサイクルの繰り返しが、プロジェクトチームを漸進的・安定的にプロジェクトゴールに向かわせるからです。\
しかし、プロジェクトゴールやマイルストーン、トラックなどを設定し、プロジェクトの骨組みを作り軌道に乗せていく形成期や自律準備期においても、その段階におけるプロジェクトやそれを取り巻く環境の不確実性の高さゆえに、定例ミーティングで都度環境に対する認識を揃えプロジェクトを再定義するというProject Sprintのメカニズムは、高い効果を発揮します。\
また、Project Sprintは、構想期及び自律準備期をできるだけ短縮し、スムーズに自律推進期に入れるような考え方や仕組みを提供します。
# プロジェクトの環境整備
この記事では、プロジェクスプリントの実施を助けるプロジェクト環境について記載します。
## **情報共有環境の構築**
* **ファイル共有**: プロジェクトメンバー全員が同じ情報にアクセスできるよう、ファイルの共有場所を用意しましょう。
* **スケジュール共有**: スケジュール調整に必要な限りで、メンバー間の個人カレンダーを共有するようにしましょう。これは、メールなどによって都度日程調整をするのではなく、チームメンバーのスケジュール状況が一か所に集まっており、ミーティングのスケジュールを効率的に設定・変更できるようになることを意味します。
* **タスク共有**: プロジェクトを通じて生まれるタスクを共有できる場所を用意しましょう。個人でタスク管理するのではなく、プロジェクトチームで共有のタスク置き場を用意することで、お互いが何をするべきか / するつもりだったか、を確認するコミュニケーションがしやすくなります。
これらは一般的なプロジェクトマネジメントで語られる要素と大きく異なりません。しかし、Project Sprintでは、それらの要素すべてにおいて、「情報の透明性をいかに担保するか」という点を中心に考えるべきです。
Project Sprintでは、プロジェクトのゴールやマイルストーンの設定、ロールの設定と調整をはじめ、様々なタイミングで「チームメンバーの納得を伴った合意」をつくることが必要になります。そのため、納得をつくるため = チームメンバーの情報格差をなくすため、にはどういったプロジェクト環境を用意するべきか、というポイントが重要視されるのです。
なお、ここに書いている要素は一例に過ぎません。プロジェクトごとに、チームメンバー間で最も最適なプロジェクト環境を整備していくように話し合うこともまた重要です。
## **スタンドアップの導入**
詳しくは[ミーティングを開催する](https://github.com/copilot-jp/project-sprint/blob/master/JA/v3.1/tutorial/broken-reference/README.md)で記述しますが、Project Sprintでは定期的なミーティングでタスクの進捗報告を行い、問題が発生していればアジェンダアイテムとしてミーティング内で議論します。しかし、それぞれが自律的にタスクに取り組むうちに、成果物のイメージが当初の想定とずれてきたり、進め方や連携の方法が最適でなくなってきたりすることがあります。
こういった状況を定例ミーティングを待たずして是正するため、各メンバーのタスクの状況をクイックに確認する方法として、「スタンドアップ」を導入することがあります。スタンドアップで個々のメンバーのタスクへの取り組み状況が共有されることで、成果物や進め方に対する認識がアップデートされ、取り組み方法が改善されたりメンバー間の連携や役割分担が最適化されたりするきっかけが生まれます。
### **概要**
Project Sprintにおけるスタンドアップは、次のような形で導入されます。
* 時間: 長さは15～30分程度で、スプリントの中で複数回行われる場合は毎回同じ時間帯とするのが望ましい。
* 頻度: 日次、スプリントの折返しタイミング、週頭など、スプリントやチームの状況に合わせて設定する。チームメンバーの要望によりスポットで実施してもよい。
* メンバー: チームメンバー全員
* 目的: チームのタスク状況を確認し、見直しが必要な場合にはそのきっかけを掴むこと
### **共有事項**
チームメンバーは、次の内容についての共有を、プロジェクトのマイルストーンを見ながら行います。
1. 実行したこと
2. これから実行すること
3. 障害・問題（あれば）
### **実施のポイント**
* 障害・問題は共有に留める。 スタンドアップは問題解決の場ではないことに注意してください。スタンドアップにおいて、問題点の共有だけに留まらず解決方法まで議論してしまって、タイムボックスを破ることになるのは望ましくありません。解決すべき障害や問題の報告があった場合は、スタンドアップ後に関係者で解決策を話し合い、必要に応じて結果をほかのメンバーに共有するようにします。
* いつものファシリテーターがハンドリングしない。 スタンドアップでの実施内容はシンプルです。メンバーそれぞれが持ち回りでファシリテーションを行い、自己組織化を促します。
# プロジェクトゴールとマイルストーンを設定する
プロジェクトゴールとマイルストーンの設定は、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)を参照してください)。
トラック間が疎結合であることで各トラックの自律性が保たれます。そのためには、マイルストーンを設定する際に、相互の依存関係・影響関係を判断できるような粒度・抽象度が必要です。具体的には、あるトラックのマイルストーンの達成のために別のトラックのマイルストーンを調整することができたり、他のチームメンバーが「このマイルストーン達成のためにはこのようなアウトプットを提供してあげたほうがいいな」と自発的に提案できたりするような記述になるように心がけましょう。
## **制約・イベント**
プロジェクトの外部環境にあって、プロジェクトに影響を与えるためプロジェクトメンバーが意識しなければならないものを、「制約」と呼びます。特に、プロジェクトゴールやマイルストーンの設定の前提となるものを「イベント」と呼びます。なお、プロジェクトの内部にあってマイルストーンやゴールの変動をもたらすものは、プロジェクトの一部として捉え、イベントとは呼びません。
制約は、社内の稟議スケジュールや予算など、所与のものであることが多いですが、プロジェクトを取り巻くさまざまな制約のうちどれを、実際にプロジェクトに影響を与える**イベント**として採用しプロジェクトゴール設定の前提とするかをプロジェクトチームで判断する必要があることもあります。この場合にも、プロジェクトチームとして納得感のある意志決定をすることが大切です。
イベントの典型的な例は、プロジェクトの外で日々行われている、組織の定常業務です。具体的には取締役会などがこれにあたります。これ自体がプロジェクトの作成物を生み出すわけではありませんが、プロジェクトに関する何らかの報告や決済がなされるため、こうしたイベントに合わせてプロジェクトゴールやマイルストーンを設定する必要があることがあります。また、こうしたイベントからフィードバックされた情報がプロジェクトの前提条件を変え、マイルストーンや、ときにはプロジェクトゴールそのものを変える必要が生じることもあります。
単発のものや定期的なものだけでなく、「商戦期」のような期間をもったものも、イベントとして認識します。それに合わせてプロジェクトのマイルストーンを設定したり、その結果を受けてマイルストーンやゴールを調整したりする必要があるという点は、特定の日付であっても期間であっても変わらないからです。
## **設定後の扱い**
設定したゴールとマイルストーンは、チームメンバーがいつでも参照できる状態にしておきます。こうすることで、チームメンバーがプロジェクト中にタスクを実行する際やチームメンバー間で議論を行う際に、マイルストーンやその先のプロジェクトゴールへの認識がずれていないか、すぐに確認することができるようになります。
また、マイルストーンやゴールは状況に合わせて変えてもよいものだと意識してください。プロジェクトを取り巻く環境の変化や実際にタスクを遂行する中でわかってきたことを踏まえて、マイルストーンやゴールはプロジェクト中にいつでも変更することが可能です。
実際の変更の流れは[プロジェクトのゴールとマイルストーンを見直す](/ja/v3.1/tutorial/section4-2)で解説します。
# プロジェクトゴールやマイルストーンの設定が難しいときの始め方
[プロジェクトゴールとマイルストーンを設定する](/ja/v3.1/tutorial/section2-1)では、プロジェクトゴールやマイルストーンの設定にすんなり取り組みはじめることができ、有効な議論が展開できる場合について記述しました。これが可能なのは、チームメンバー間の相互理解やプロジェクトに対する認識合わせがある程度のところまで進んでいるプロジェクトです。 一方、いきなりプロジェクトゴールやマイルストーンの設定に取り組むことが難しい場合、まずはミーティングを設定して議論することから始めましょう。具体的なステップは以下のようになります。
### **認識を合わせてはじめてチームになる**
全く面識のないメンバーが集められてプロジェクトが始まるとき、プロジェクトの範囲・内容に対する共通認識ができていない段階では、まず「なぜこのメンバーがここに集まっているのか」の認識合わせから始めなくてはいけません。ミーティングを設定してそれぞれのメンバーがプロジェクトの目的をどう認識しているかを話し合い、擦り合わせを行います。
また、集まったメンバーで何ができるのかを把握する必要があります。メンバーそれぞれが自分自身のバックグラウンドやスキルセットを開示し、どういった展望を持ってこのプロジェクトに向き合おうとしているかを話し合いましょう。[チームメンバーを知り、ロールを設定する](/ja/v3.1/tutorial/section2-2)も参考にしてください。
ここまでの認識が揃ってはじめて、集まったメンバーは「プロジェクトチーム」を目指すチームとして歩き始めることができるようになります。
### **共通のプロジェクトゴールを目指すプロジェクトチームになる**
プロジェクトは、最初からプロジェクトゴールや目的が明確な状態で立ち上がるのではなく、緩やかな方向性が示されたり外部からプロジェクトゴールの原型を提示されたりしてスタートすることがほとんどです。
ですから、次に行うのは、目指すべきプロジェクトゴールを定義するためのミーティングです。さらに時間を取った検討が必要な場合は、この工程を「プロジェクトゴールを作ること」そのものをゴールとする事前プロジェクトと捉えてもよいでしょう。このときは、プロジェクトを取り巻く基本情報（プロジェクトの背景・事業に関する予備知識・制約やイベント）の収集をマイルストーンとし、プロジェクトゴールを明文化することを目指します。
ミーティングで議論し、チームの意思が適切に反映され、チームメンバーの共通認識を得たプロジェクトゴールを設定することで、プロジェクトゴールがチームにとって明確で納得感のあるものとなります。メンバー全員が、このチームとして何を目指すのかについての共通理解をもち、さらにそれに対して納得している状態をつくる必要があります。
このようなプロジェクトゴールが明確に設定されてはじめて、チームは共通のプロジェクトゴールを目指す「プロジェクトチーム」と呼べるようになります。
はじめのうちは、プロジェクトゴールや目的に対する現状認識をまずチームとして揃えるために言語化して書き出してみる、というような形で構いません。議論しているうちに認識が変わることもあるでしょうし、一度設定してプロジェクトが開始されてからも、チームで納得してさえいれば環境の変化に応じていつでも変更して構わないのです。
### **明確化されたプロジェクトゴールをもとにマイルストーンを設定する**
続いて、ここまでで設定したプロジェクトゴールをもとにマイルストーンを引いていきましょう。うまく引けないときは、プロジェクトゴールを見直す必要があるかもしれませんし、マイルストーン設定の前提となるチームメンバー同士の認識合わせがまだ十分でないのかもしれません。必要に応じて、前の工程に戻って議論をしましょう。
制約やイベントを意識しながら、「いつまでにどのような作成物が必要か/どういう状態になっている必要があるか」がある程度具体的にイメージできる場合には、プロジェクトゴールを見据えながらバックキャストでマイルストーンマップを引いていきます。具体的なイメージがまだ持ちにくい場合には、まず取り組めるところからフォアキャストでマイルストーンマップを引くことになります。
ここまで来れば、少なくともプロジェクトチームとして直近取り組むべき内容や目指すべきマイルストーンは明確になっていることでしょう。その先のまだ不明確な部分に関しては、実際にプロジェクトに取り組みながら、[プロジェクトのゴールとマイルストーンを見直す](/ja/v3.1/tutorial/section4-2)を参考に、いつでも見直しや調整を加えればよいのです。
# トラック：プロジェクト遂行の単位
## トラックとは
トラックとは、それぞれが強い依存関係を持たず、設定した役割や目標に沿って自律自走できるプロジェクト内の単位です。
[Project Sprint 101](https://github.com/copilot-jp/project-sprint/blob/master/JA/v3.1/tutorial/broken-reference/README.md)で説明したように、Project Sprintではプロジェクトを「全体」の達成に寄与するひとつの「部分」として捉えます。トラックも同様に、プロジェクトという全体の達成に必要なそれぞれの部分といえます。プロジェクトゴール達成を目指す過程を、それぞれが強い依存関係を持たず自律的に作業を進めることができる単位にまでブレイクダウンしたものを、トラックと呼びます。
プロジェクト全体の状態を把握するためのメインのトラックをまず設定してマイルストーンを置き、そのマイルストーンを達成するために必要なものを要素ごとに分割することで、その他のトラックが置かれます。トラック同士は、依存関係が少ない疎結合な状態になるように分割します。トラック同士の依存関係は、個々のトラックの自律的な動きの妨げとなるからです。
プロジェクトの構想期はまだプロジェクトゴールが明確化されていないため、トラックへのブレイクダウンも進まないことが多いでしょう。その後の形成期や自律準備期において、プロジェクトゴールやマイルストーン、必要な成果物などが明確になってくるにつれて、トラックの分割が進みます。
## トラックのライフサイクル
[プロジェクトライフサイクル](/ja/v3.1/tutorial/section2-0)の考え方は、トラックにも適用できます。トラックの構想期においては、「このようなトラックが必要だろう」という仮説を立て、チームメンバーを決めます。この段階ではマイルストーンが置かれておらず、定例ミーティングのみのトラックになるかもしれません。その後トラックゴールやマイルストーンを明文化するのがトラックの形成期、定例ミーティングや他のトラックとの連携を設定するのがトラックの自律準備期に当たります。
自律準備期までは、他のトラックとの境界が曖昧なことも多くあります。また、自律推進期に入ってからも、環境の変化に伴い他トラックとの相互依存関係が密になり、自律的な推進が難しくなることもあるでしょう。その場合には、一旦自律準備期に戻ったと捉えて情報や体制を整理し、改めて定期的な同期・連携による一定程度予測可能な相互作用のみでそれぞれが自律的に動ける状態に近づけていきます。
## トラックの分割例
例えば、あるWebサイトを立ち上げるプロジェクトを考えたとき（プロジェクトゴールは「Webサイトの完成」）、Webサイトのデザインを考えるチームと、Webサイトのシステム環境を整える作業は、一定程度関連はしながらも並行して進行します。このとき、それぞれの作業領域をトラックとして分割し、トラックごとにマイルストーンを分けて考えることで、よりプロジェクトを構造化して捉えられるようになります。
上述のWebサイトの例のようなトラック分割だけでなく、営業・マーケティング・CSといったロールベースでのトラック分割や、プロダクトごと・機能ごとのトラック分割など、プロジェクトの性質や規模によって、設定されるトラックは様々です。
# トラックの設定方法
## 1. プロジェクトゴールに対する認識を揃える
[プロジェクトゴールとマイルストーンを設定する](/ja/v3.1/tutorial/section2-1)や、[プロジェクトゴールやマイルストーンの設定が難しいときの始め方](https://github.com/copilot-jp/project-sprint/blob/master/ja-v3.1.0/tutorial/section2-1-1.md)を参考に、まずはプロジェクトの目的やプロジェクトゴールを明確化し、チームメンバー間での共通認識にします。
## 2. メインのトラックを設定する
プロジェクト全体・プロジェクトチーム全体の主な状態を把握するトラックを、メインのトラックとして設定します。このトラックには、プロジェクトゴールの達成のために必要な大きなマイルストーンと、プロジェクト全体に関わるアイデアの共創や問題の共同解決のために必要な定例ミーティングの両方が入力されることが多いでしょう。プロジェクトメンバーによる定例ミーティングを設定し、このトラックだけでなくプロジェクト全体のマイルストーンマップを毎週確認できるようにしておきましょう。
メインのトラックにおけるマイルストーンとステップは、外部制約や主要なイベントなどに応じて設定していくのがふつうですが、そういったものが明確に存在しない場合は、3か月ごとなどの定期的なタイミングでステップを区切ってマイルストーンを設定します。たとえば何らかのサービスを立ち上げるようなプロジェクトであれば、各ステップごとに顧客に対して提供したい価値を記述するのもよいでしょう。
各ステップの終点となるマイルストーンの成果物・あるべき姿には、提供したい価値・バリューを、具体的な作成物や数値目標、達成したい状態などに落とし込んで記載しましょう。メインのトラックのマイルストーンは、このあと設定される各トラックにおけるマイルストーン達成の集積によって達成されてゆくという構造になります。そのため、メインのトラックのマイルストーンを参照することで、このあと作成する各トラックのメンバーが自律的に各トラックのマイルストーンを決定できるような内容が書いてあることが望ましいです。
メインのトラックのマイルストーンを設定するときには、「各トラックの成果物の仕上がりが合わさる、または仕上がりを合わせたい具体的なタイミングはいつか」というところから考えてみるとイメージしやすくなるかもしれません。
## 3. メインのトラックの他に必要なトラックを設定する
メインのトラックのマイルストーンを達成するために必要なものを部分部分に分割して、その他のトラックを作っていきます。
基本的には、トラック同士は依存関係が少ない疎結合な状態になるように分割します。つまり、個々のトラックだけで自律して作業を進められるような分け方です。こういった分け方ができず、強い依存関係のあるタスクベースで進捗をコントロールする必要がある場合には、別途ガントチャートを作って把握するのがよいでしょう。
各トラックで個別にミーティングが必要な場合や、各トラックで個別にチームになった場合は定例ミーティングを置きますが、それぞれのトラックには必ずしも定例ミーティングを設定する必要はありません。
また、各トラックは原則として疎結合なものとして存在しますが、進捗状況の共有やマイルストーンの詳細な確認などを目的として、トラック間での連携やトラックを横断したミーティングを置くこともあります。このときは、連携が必要となるトラックの上部構造として、連携用のミーティングを置くトラックを設定するとよいでしょう。
# チームメンバーを知り、ロールを設定する
チームメンバーを知り、ロールを設定することは、Project Sprintにおけるチーミングドメインにあたります。各チームメンバーの責任・役割・期待値を共有することで、自分の責任・役割・期待値が明確になり、自律的な行動が取れるようになります。
チーミングの「理想の状態」の条件のひとつは、「チームメンバー各々の各自の責任・役割・期待値が共有されており、各メンバーの認識に齟齬がない」ということです。言い換えると、あるチームメンバーが「あの人はこれをやってくれるだろう」と考えたとき、そのチームメンバーも「これは私がやるべきことだ」と考えている状態(**期待値の一致**)です。
また、プロジェクトの「理想の状態」の条件のひとつに、「チームにおける自分の責任・役割・期待値に納得感が持てており、自分がチームのために何をすべきかを自律的に判断し実際に行動できている」ことが挙げられます。つまり、自分に担うことができる役割であれば、何であれ必要に応じていつでも担おうとするマインドセットがあること (**自発的な役割の引き受け**)です。
Project Sprintでは、プロセスでの期待値の共有とロールの設定によって、これらを実現します。
チーミングの「理想の状態」には、明確な到達点がありません。なぜなら「ここまで達成したら理想のチームだ！」というものが決めにくいからです。そこでProject Sprintでは、常に「チームが今の時点より良い状態になること」を目指します。
### **チームメンバーの基本情報**
より良いチームを目指す前提となるのが、チームメンバーに関する理解です。例えば、プロジェクトに関わるメンバーに次のことを確認しておきましょう。
* あなたの名前はなんですか？普段はどのような組織や会社に所属している人ですか？
* あなたはどのような人ですか？例えばスキルセットはどのようなものがありますか？これまでにどのような仕事にかかわってきましたか？
* あなたがこのプロジェクトに対して貢献を期待されていることはなんですか？
* あなたはプロジェクトに対する専任メンバーですか、兼任メンバーですか？いずれにせよ、あなたがこのプロジェクトに割ける時間はどのくらいですか？
こうしたことをプロジェクトの最初に知っておくことは、続くロールの設定における助けになります。
### **ロールの共有**
Project Sprintでは、チームメンバー個々人の役割のことをロールと呼びます。ロールとチームメンバーは必ずしも一対一の関係である必要はありません。つまり、一人の人が複数のロールを担うこともありますし、またあるロールを複数の人が担うこともできます。
また、設定するロールの個数には制限がありませんし、「必ず設定すべきロール」というものもありません。ロールの定義に関しても、必要なのはチームメンバーで合意することのみです。プロジェクトの性質に応じて、必要な役割分担をチームメンバーで議論し、ロールとして明文化しましょう。
### **ロールシートの利用**
ロールとチームメンバーは一対一の関係になるとは限らず、またロールの種類も決まったものはない一方、決まったロールはきちんと明文化して合意する必要があります。
そのため、「いまのロールの状況」を明文化して参照できる状態にしておくための「ロールシート」を利用することをおすすめします。
ロールシートには、例えば次のような要素を盛り込みます。
* ロール名
* ロールが果たす責任(どういう目的でそのロールが必要とされ、何を果たすロールなのか）
* そのロールを担う人
これらを一つのドキュメントとしてまとめ、常に最新のものに更新しておくことで、いまの各メンバーに対する期待値を把握することや、期待とズレがあった場合の議論が可能になります。
# ミーティングを設計する
プログレスとチーミング双方において、プロジェクトチームがプロジェクトゴールに向かって円滑に進んでいくための仕組みがプロセスであり、その軸となるのは、チームでのミーティングとそこでのアジェンダの議論です。個々人がタスクに取り組む中で生まれた作成物やアイデア・問題・テンションをミーティングで共有し認識を揃えることによって、プロジェクトチームとしてのアイデアを共同創造し、問題の共同解決を行って次の行動を決定することが重要です。
ここではそのミーティングの設計について記述します。
### **「ミーティング」とは**
Project Sprintでは「ミーティング」を、「チームメンバーが一時的に同一の環境に固定されてリアルタイムで会話をすることにより、素早く効率的な認識合わせと、全員にとって納得感のある意思決定をする場」と位置づけています。
リアルタイムで全員が集まるミーティングが、プロジェクトの意思決定においては最適な選択です。変化の激しい時代にあって、メールやチャットでの非同期のコミュニケーションでは、個々のメンバーが時間軸も視界も異なる環境に置かれることになるため認識に齟齬が生じやすく、意思決定が困難になります。リアルタイムで集まることでまず、チームメンバー全員が同じ時間軸に固定されます。そして会話する中でお互いの視界にある景色を擦り合わせて初めて認識が合い、大きな意思決定を行ったりそれに対して納得したりすることができるようになるのです。
これを実現するために、ミーティングを適切にデザインし、プロジェクトメンバーで合意しましょう。
### **ミーティングの設計**
ミーティングは定期的・反復的に開催される必要があります。この理由については、詳しく後述します。
ミーティングの開催頻度は、週次/月次/隔週など、プロジェクトの性質やチームメンバーの人数などを勘案して任意に決めてください。ただし、Project Sprintの基本のメカニズムが「定期的・反復的なミーティングで各メンバーの取り組みの成果や作成物を共有し環境に対する認識を揃えることによって、各メンバーが同じプロジェクトゴールを目指して自律的に各自の次の行動に向かうことができるようにする。この繰り返しがプロジェクトを現在の状態から理想の状態に漸進的に近づけ、結果としてプロジェクトゴールが達成される。」であることを考えると、隔月以上の間隔でのミーティング開催は考えにくいでしょう。
ミーティングに目的や完了の定義が明確に存在しうることもありますが、基本的にはミーティングは目的も到達すべき地点も持たず、その時々のアジェンダアイテムが投入されていく連続した箱のようなものと捉えるのがよいでしょう。ミーティングで議論すべきアジェンダの内容や性質は常に異なるため、どのようなアジェンダでも自由に提案できるよう、なるべく縛りを設けないでおくのです。
なお、各ミーティングの参加者はアジェンダに応じて必要十分な程度でかまいません。ここでいう必要十分とは、アジェンダに関して網羅的に議論でき（＝「誰かがいないから今日はこの話ができないね」ということがないようにする）、また議論をもとに正式な意思決定ができること（＝「誰かがいないから今日はこの話は決まらないね」ということがないようにする）を意味しています。もし参加人数が大人数(10人を一つの目安としてください）になっている場合は、必要以上の人数を集めていないか、確認してください。もしそうなってしまっている場合、アジェンダの議論と意思決定を目的としたミーティングではなく、単なる情報共有を目的とした会議になっている可能性があります。
とはいえ、ミーティングでは多様なアジェンダが提出される可能性があるので、最初にミーティングを設計する際には、あらかじめチームメンバー全員が集まることのできるミーティングを設定したほうがいい場合も多いでしょう。そうすることで、チームメンバー個々人の中にとどまっている情報を一斉に共有することができ、各チームメンバーはこのプロセスに参加するだけでプロジェクトの状況や思っていることについて自然と認識を合わせることができるようになります。
さらに、参加者が漏れなく参加でき、情報をリアルタイムに共有できるようなミーティング環境を整備するようにしてください。これは、前述の素早く効率的な認識合わせを実現するために重要なポイントとなります。具体的には、場所を問わず参加できるリモートミーティング環境の準備、その場で決まったことを共有できるドキュメントシェアサービスの利用、などを行うことになるでしょう。
### **定例ミーティングが不可欠である理由**
**1. 定期的に振り返りを行うことで、プロジェクトを最適化できる。**
不確実性の高いプロジェクトにおいては、マイルストーン達成までの道のりは整然と進むわけではありません。各ステップの中で、立ち上げ、計画、実行、終結といったそれぞれの段階が重なり合い影響し合いながら進行していくのです。そこで、定期的なミーティングでの振り返りによってメンバー間の認識を都度擦り合わせ、必要に応じて調整を加えることで、プロジェクトを最適化する必要があります。
（PMBOKの概念を参照）
**2. 前回のミーティングから今回のミーティングまでの差分をキャッチアップする機会を保証できる。**
プロジェクトはルーチンワークと違って不確実性が高く、目的も変化しやすいものです。社会や組織の変化が激しいなかでも、定期的に集まることで、各チームメンバーが経験したこと・変化を確実に、定期的に吸収することができます。これらをインプットするからこそ、プロジェクトのゴールやマイルストーンをみんなで合意して変化させることも可能になります。
**プロジェクトとルーチンワークの違い**
**3. チームメンバーのスケジュールの調整コストが低くなる。**
社内外の多様なメンバーが参加するようなプロジェクトも多い昨今では、都度スケジュール調整をしているとそれだけで時間がかかります。そのため、あらかじめスケジュール設定をしておく方が効率がよいのです。また都度ミーティングを調整していると必要なタイミングでミーティング開催ができません。これは、必要十分な参加者が一度に集まって素早く効率的に意思決定をするというProject Sprintの利点を損ねてしまいます。
**4. 同じ曜日・時間に開催されることで、他のチームの人が共有のために覗きに来やすくなる。**
あるアジェンダアイテムについて特定のゲストを呼び、スペシャリストとしてのコメントをもらうといったことはよくありますが、定期的な時間・曜日があらかじめ設定されていると都度の調整が必要なく、すでにある時間に招待すればよいため、効率的です。
**5. 定期的に期間を区切るほうがタスクの粒度を作りやすい。**
定期的な期間、例えば「1週間でできること」という基準となる間隔をもつことで、これぐらいのタスクであればできるかな、という予測がしやすくなります。現実的なタスクを作成することは、アウトプットを確実に作ること、ひいてはアジェンダの確度を上げることにつながります。個々人のアクティビティであるタスク実行をプロジェクト全体の成果に反映させるプロセスを定期的に繰り返すことによって、プロジェクトが最適化されていきます。
**6. 業務のリズムを作りやすくなり、タスクの消化がスムーズになる。**
例えば毎週月曜日はこのミーティングがあるのでこういう作業時間を確保しておこう、など。個々のメンバーが作業計画を立てやすくなります。
**7. プロジェクトの定点観測資料になる。**
ミーティングのアジェンダ、議事録、タスクの進捗報告が定点観測的に残ります。これは振り返りの際に参照しやすいログとなるほか、新しいメンバーが参加した際の読みやすさも担保します（過去の情報をむやみに読むよりは、定期的に出力されたものをマイルストーンに沿って読むほうが理解しやすいため）。また、こうしたログが残っていれば、別のプロジェクトを開始する際、過去のプロジェクトがこのようにすすんだのだという参考やひな形にしやすくなります。
# ミーティングの準備をする
個人の取り組みの成果や作成物を共有し環境に対する認識を揃えることで、各メンバーが次の行動に自律的に向かえるようにするための仕組みがプロセスであり、その軸となるのは、チームでのミーティングとそこでのアジェンダの議論です。個々人がタスクに取り組む中で生まれた作成物やアイデア・問題・テンションをミーティングで共有し認識を揃えることによって、プロジェクトチームとしてのアイデアを共同創造し、問題の共同解決を行って次の行動を決定することが重要です。
ここでは、具体的なミーティングの準備について記載します。
Project Sprintでは「ミーティング」を、「チームメンバーが一時的に同一の環境に固定されてリアルタイムで会話をすることにより、素早く効率的な認識合わせと、全員にとって納得感のある意思決定をする場」と位置づけています。リアルタイムで全員が参加する定期的・反復的なミーティングで、問題点や違和感を共有して認識を揃え、次の行動とその進め方を決定することが重要です。
### **ミーティングロールの確認**
まず、ミーティングを効率的・効果的に運営するための役割（ミーティングロール）を個々人に割り当てましょう。
具体的には、次のようなロールの割り当てが必要です。
* ファシリテーター：議論を促進し成果の質を向上させることで、プロジェクトの成果をよりよいものにするロール。アジェンダの改善やその後の議論形成のサポート・助言を行う。
* モデレーター：アジェンダの取りまとめや進行サポートを行うことで、議論のプロセスを最適化し進行の時間を維持するロール。アジェンダの合意から、その後のアジェンダ進行とタイムキープ、議論の結果決定された次の行動の明確化、ミーティング終了時の次回のアジェンダの決定までを担う。
* コーディネーター：ミーティング環境を整えるロール。適切なミーティングルームの確保（オンラインの場合はミーティング環境の設定）、ホワイトボードやモニターの手配をする。
* レコーダー：議事録を作成するロール。ミーティング後に議事録を共有するだけでなく、ミーティングの進行中にもリアルタイムで作成中の議事録を共有し、メンバー間の認識のずれを即座に修正することができるようにする。
チームメンバーの人数によって、一人が複数のロールを担当することもありますし、何もロールを持たないメンバーがいることもあります。ただし、いずれのロールも誰かが担うようにしてください。会議の参加者全員がそれぞれの視点から助言しうるので、ファシリテーターは全員が担うことになるでしょう。また、モデレーター、コーディネーター、レコーダーは属人性が低いため、固定ではなくミーティングごとに持ち回りにすることが望ましいものです。これにより、ミーティング運営に関する問題点や最適な方法について、参加者全員が自分から考えやすくなります。
ロールの分担はミーティングの都度話し合って決定してもかまいませんが、あらかじめミーティング前に分担や持ち回りのルールを決めておくと、当日のミーティング運営が効率的になります。
### **アジェンダアイテムの提出**
毎回のミーティングが始まる前には、あらかじめ各チームメンバーがアジェンダアイテムを提出します。アジェンダアイテムには、少なくとも次のような内容が含まれている必要があります。
* アジェンダアイテム名（何を議論したいか端的に記載する）
* 進行方法（具体的な議論の進行イメージ）
* 目的や背景（そのアジェンダアイテムを議論したい理由）
* 誰から誰への議論か（誰がそのアジェンダアイテムのオーナーであり、誰と議論したいのか）
* 時間（議論完了までの所要時間）
これらは、「何について話し合いたいのか」をアジェンダアイテムオーナーが明らかにするために必要な情報ですが、これに加えて「どの程度まで話し合いたいのか」までを明らかにしておくと、議論がより進めやすくなります。
具体的には、次の要素を追加で記載するようにします。
* あるべき姿(アジェンダアイテムを議論した後に目指す状態)
* 結果(議論が終わったときに生まれている明示的なアウトプット）
* 参加者がアジェンダアイテムの完了について納得していることを証明する手段
これらの要素がそれぞれ事前に明らかになっていればいるほど効率的・効果的な議論ができるようになります。アジェンダアイテムオーナーだけでは記載することが難しいものを補足したり、他のチームメンバーから見て分かりにくいものを分かりやすくしたりして、これらの要素が記載できるように議論を整理していくことが、ファシリテーターに求められる役割です。
### **アジェンダアイテムの目的**
アジェンダアイテムは、議論の目的によって次の三つの種類に分けられます。
* 発散：議論を通して幅広い選択肢が出てくる。結論が見えないテーマについて議論し、明確でないまま終了してよい。
* 収束：議論を通していくつか選択肢から一つの選択肢に絞られる。メンバー間での意思決定や合意形成など、最終的に何かしらの結論を出す。
* 共有：情報共有や前提確認など、チームメンバーと認識を合わせる。議論を特に必要としない。
個々のアジェンダアイテムがどれに分類されるのかあらかじめ示しておくことで、ミーティングの参加者が「どのような視点で」「どのような発言をするべきか」を理解することができます。例えば、「発散」のアジェンダアイテムであれば自由に意見を発してよく、新しいアイデアを出すことが重要だと分かります。反対に「収束」のアジェンダアイテムであれば、マイルストーン達成のためにどのようなアウトプットをつくっていくべきか、現実的な結論を導くことが必要だと分かります。また「共有」のアジェンダアイテムであれば、疑問点を質問しできるだけ認識を合わせることが重要だと分かります。
# ミーティングを開催する
個人の取り組みの成果や作成物を共有し環境に対する認識を揃えることで、各メンバーが次の行動に自律的に向かえるようにするための仕組みがプロセスであり、その軸となるのは、チームでのミーティングとそこでのアジェンダの議論です。個々人がタスクに取り組む中で生まれた作成物やアイデア・問題・テンションをミーティングで共有し認識を揃えることによって、プロジェクトチームとしてのアイデアを共同創造し、問題の共同解決を行って次の行動を決定することが重要です。
Project Sprintでは「ミーティング」を、「チームメンバーが一時的に同一の環境に固定されてリアルタイムで会話をすることにより、素早く効率的な認識合わせと、全員にとって納得感のある意思決定をする場」として位置づけています。リアルタイムで全員が参加する定期的・反復的なミーティングで、問題点や違和感を共有して認識を揃え、次の行動とその進め方を決定します。
## **ミーティングの「型」**
この記事では、Project Sprintで行われるミーティングの基本となる進行方法を説明していきます。おおまかな構成としては次のようになっているので、これをまずはじめに頭に入れておくと、それぞれの内容を理解しやすいでしょう。
* 序盤：タスクの進捗報告、テンショントリアージ、アジェンダトリアージ
* 中盤：個別のアジェンダアイテムの進行
* 終盤：今回のミーティングから生まれたタスクの確認と、次回以降のミーティングのアジェンダ確認
さらに、特にミーティングの序盤と終盤は定型化しやすく、時間がたつにつれ、具体的な方法論や必要な時間、細かい順番が定まってきます。チームにとって最適なミーティングの「型」を見つけましょう。
## **ミーティング開始時**
ミーティングの最初に、タスクの進捗報告とテンショントリアージを行ってください。これらを通じて、前回のミーティングから今回のミーティングまでに起こったことについて、チームメンバー同士でアップデートを行います。議論の結果は、その日のミーティングで話すことを決める材料になります。
なお、タスクの進捗報告とテンショントリアージはそれ自体がアジェンダアイテムです。したがって、後述するアジェンダトリアージの前に実施されるものではありますが、これらのアジェンダアイテムの進行についてもモデレーターが担当する必要があります。
### **タスクの進捗報告**
初回のミーティングを除けば、前回までのミーティングを経て、何かしらの各自のタスクが生まれているはずです。これらのタスクの進捗状況を確認しましょう。
タスクを遂行した結果なんらかの作業結果が生まれている場合には、それをもとに話し合うべきアジェンダアイテムがないか確認しましょう。 もし作業結果がなくても、作業が思うように進まないという相談もありうるでしょう。このような場合も、これを解決するためにアジェンダアイテムとしてミーティング内で議論する必要がないか確認しましょう。
なお、この場で挙げるのではなく、ミーティング前にアジェンダアイテムとして提出しておいても構いません。
### **テンショントリアージ**
テンションとは、「プロジェクトに取り組む中で生まれた、他のメンバーに伝えたい違和感」のことです。具体的には、メンバー個人が思う「こうしたらもっと良くなるのに」という現状とよりよい状態の間のギャップ、ちょっとしたアイデア・気になること・不安などのことを指します。またトリアージとは、選別と優先順位づけをする行為のことを指します。
すなわちテンショントリアージとは、個々のチームメンバーが感じている違和感を提案に変えて全員で共有したうえで、今チームを改善するために必要なものを優先的に選び、解決しようとすることです。テンションをあげた本人が、テンションを違和感の解消のための具体的な提案に変換し、本人にとって納得のいく解決策を決定することが大切です。
テンションは一人一人が組織内で自律的に動くための原動力となるものです。重要なのは一人一人がテンションを感知することと、感知したテンションを無視しないことです。それぞれが感知したテンションを自律的に処理することでチームが回り、プロジェクトゴールに近づいていくのです。
前述のように、テンションとは現状とよりよい状態のギャップから生まれるものです。そのため、テンショントリアージを行う際にプログレス及びチーミングの理想の状態や、プロジェクトゴール・マイルストーン、チームのロール）を参照できるようにしておくことが、テンションを挙げるために効果的です。
テンショントリアージで共有した内容は、解決のためのアクションに落とし込むようにしてください。具体的には、直接的な改善策が明確な場合、テンションを解決するための新たなタスクとしてください。また、直接的な改善策が明確でない場合や時間をかけた議論が必要な場合は、新たなアジェンダアイテムとして改善策を探すようにしてください。
なお、この場で挙げるのではなく、ミーティング前にアジェンダアイテムとして提出しておいても構いません。
具体的なテンショントリアージの方法は、[現在の心の声を活用する：テンショントリアージ](https://github.com/copilot-jp/project-sprint/blob/master/JA/v3.1/section4-1-2.md)で解説します。
### **アジェンダトリアージ**
続いて、アジェンダトリアージを行ってください。アジェンダトリアージには、ミーティングに出席しているチームメンバー全員が参加します。
トリアージとは、ここでも同じく選別と優先順位づけをする行為のことを指します。すなわちアジェンダトリアージとは、その日のミーティングで話したいことを参加者全員で出し合い、優先的に話し合うべきものを選ぶことです。
モデレーターは、アジェンダトリアージを主体的に進行し、最終的な合意まで持っていくことが求められます。
この時点で、2種類のアジェンダアイテムが用意されているはずです。
1. ミーティング前に提出のあったアジェンダアイテム
2. タスクの進捗報告またはテンショントリアージの結果、新たに生まれたアジェンダアイテム
アジェンダトリアージは、これらのアジェンダアイテムのうち、その日のミーティングで議論すべきものと議論する順番を決める作業です。プロジェクトゴールやマイルストーンを参照しながら、優先順位をつけていきましょう。
事前に提出されたアジェンダアイテムの内容に不明点があれば、チームメンバーはそれに対して納得できるように質問をしましょう。このとき、ファシリテーターにはこのアジェンダアイテムの改善に関する議論を活発にすることが求められます。
アジェンダアイテムの内容が明確になった結果、あらかじめ設定されていた所要時間だと余りそう、または逆に足りなそうである、と判明することがあります。このときは、アジェンダアイテムの所要時間を調整しましょう。
それぞれのアジェンダアイテムの内容が明確になったら、優先順位をつけましょう。マイルストーン達成のために必要なアジェンダアイテムから議論するのが基本です。直近のマイルストーンの内容と、その期限までに開催できるミーティングの回数を考慮しましょう。マイルストーンを参照した結果、個別のアジェンダアイテムの議論においてどのような結論まで持っていくべきかを調整することもあります。
なお、事前に提出されたアジェンダアイテム以外に、チームメンバーから見て緊急性が高いアジェンダアイテムがある場合には、チームメンバーの合意を得た上で、それらのアジェンダアイテムが優先されます。
優先順位をつけた結果、当日話し合うことができないアジェンダアイテムは、次回以降のミーティングに持ち越しましょう。こうしたアジェンダアイテムがあるとき、アジェンダトリアージは、次の3種類の中から優先順位づけをすることになります。
1. ミーティング前に提出のあったアジェンダアイテム
2. タスクの進捗報告またはテンショントリアージの結果、新たに生まれたアジェンダアイテム
3. 前週までの持ち越しアジェンダアイテム
当日話し合うことになったアジェンダアイテムは、元々の優先順位に従って議論してもかまいませんし、内容に応じて関連するテーマについて続けて議論できるように順番を並べ替えることもできます。並び替えを行うメリットは、関連しあうテーマ同士について続けて議論するほうが効率的であることです。
## **ミーティングの進行**
### **個別のアジェンダアイテムの消化**
アジェンダトリアージが終われば、一つ一つのアジェンダアイテムについて議論しましょう。
一つ一つのアジェンダアイテムは、すでに記載されているアジェンダアイテムの内容に基づき、それぞれのアジェンダアイテムオーナーがメインで進行します。ファシリテーターは議論の内容と最終的な結論がより良くなるように議論に参加しましょう。レコーダーは、議論の経緯・内容をリアルタイムで記録し、参加者が常に見ることのできる状態にしましょう。
### **アジェンダアイテムの取りまとめ**
モデレーターは、アジェンダアイテムを取りまとめ、ミーティングを通して確認や調整を行います。ただし、以下で説明するアジェンダアイテムの確認や調整は、すべてチームメンバーと話し合いながら決めるべきものです。ここでも、直近のマイルストーン達成のためにはどのような選択が有効か、が基本的な判断基準となりますが、最終的にはチームメンバーの話し合いで出た結論が優先されます。
まず、それぞれのアジェンダアイテムが議論されている最中は、予定されている時間内にそのアジェンダアイテムが終わるように気を配ってください。
ただし、議論の内容に応じて、アジェンダアイテムが予定した時間より延長してしまったり、逆に早く終わってしまうことがあります。 アジェンダアイテムが予定した時間より延長している場合、モデレーターはそのアジェンダアイテムを次回に持ち越すようにするか、一定の結論が出るまで議論を続けるかを検討してください。
次回に持ち越す場合、このアジェンダアイテムは、前週までの持ち越しアジェンダアイテムの一つとして扱われます。これまでの過程でアジェンダアイテムの詳細はすでに完成しているはずですが、ここまでで議論した内容もあわせて把握するために、レコーダーが記録した内容も一緒に確認できるようにしておきましょう。
一定の結論が出るまで議論を続けることにしたときは、他のアジェンダアイテムの時間を短縮して調整するか、場合によっては他のアジェンダアイテムを次回以降のミーティングに繰り越すようにしてください。
アジェンダアイテムが予定よりも早く終わってしまった場合、他のアジェンダアイテムの時間を延ばして余裕を持って議論できるようにするか、次回以降に繰り越すようにしていたアジェンダアイテムからその時のミーティング中に先に話し合うべきものがないか、検討してください。また、ミーティングを早く終えることを選択するのも可能です。
また、あるアジェンダアイテムを議論した結果、新しく話し合うべき内容、つまり新たなアジェンダアイテムが生まれることがあります。このとき、当日の追加アジェンダアイテムとして扱うか、次回以降に持ち越すかを検討する必要があります。
当日の追加アジェンダアイテムとして扱うときは、以下のいずれかの対応を取ってください。
* 他のアジェンダアイテムの時間を短縮して調整する
* 他のアジェンダアイテムを次回以降に繰り越す
* ミーティングの参加者全員に確認して、ミーティングの時間を延長する
もしアジェンダアイテムの内容が明確な場合は当日の議論も可能ですが、そうでない場合は次回以降に持ち越すのがよいでしょう。次回以降に持ち越すときは、このアジェンダアイテムはミーティング前に提出のあったアジェンダアイテムの一つとして扱われます。
前週までの持ち越しアジェンダアイテムと違うのは、アジェンダアイテムの内容が明確になっていない点です。したがって、ミーティング中に生まれたアジェンダアイテムについては少なくともアジェンダアイテムオーナーを明確にした状態でミーティングを終えましょう。そして、アジェンダアイテムオーナーは次回のミーティング前にアジェンダアイテムの内容を明確にしておくようにしてください。
## **ミーティング終了時**
ミーティング終了時には、今回のミーティングから生まれたタスクの確認と、次回のミーティングアジェンダの確認を行ってください。これによって、今回のミーティングの結果と、次回のミーティングまでに何をするべきかを確認することができます。これらの作業の前提として、マイルストーンの確認を行うことも効果的です。これによって、次回のミーティングまでに何に対してどこまで取り組むべきかの優先順位付けをしやすくなります。
なお、これらの確認もそれ自体がアジェンダアイテムなので、モデレーターが担当する必要があります。
### **今回のミーティングから生まれたタスクの確認**
今回のミーティングで取り上げたアジェンダアイテムの議論を経て、チームメンバーがやるべきこと、つまりタスクがいくつか生まれているはずです。レコーダーの記録をもとにして、生まれたタスクを確認し、リストアップしましょう。リストアップしたタスクには、具体的な行動内容、担当者、期限を明確にするようにしてください。
### **次回以降のミーティングのアジェンダ確認**
実際にミーティングで取り上げるアジェンダアイテムが確定するのはミーティングの当日ですが、毎回のミーティングの終了時に、次回以降のミーティングで話し合うべきアジェンダアイテムについて議論しておきましょう。このようなアジェンダアイテムには例えば次のようなものがあります。
* 次回以降に持ち越しになったアジェンダアイテム
* 進捗確認など、あらかじめタイミングを決めて議論するべきとされるアジェンダアイテム
事前にチームメンバー全員で確認することで、アジェンダアイテムオーナーのアジェンダアイテム提出漏れや、持ち越したアジェンダアイテムの内容の不備を防ぎやすくなります。
# タスクを設定する
Project Sprintには、ミーティング終盤にそのミーティングを通じて生まれたタスクの確認を行い、次回のミーティングの序盤でそれまでのタスクの進捗報告を行うというサイクルがあります。 [ミーティングを開催する](https://github.com/copilot-jp/project-sprint/blob/master/JA/v3.1/tutorial/broken-reference/README.md)で解説したように、タスクを記載する際には、
* 具体的な行動内容
* 担当者
* 期限
を明確にすることが最低限必要です。
しかし、これだけでは、タスクの進捗報告の際に「想定していたのと違った」「いつまでたっても完了しない」といったことが起こりえます。これは、タスクの担当者が何をやればよいかよくわかっていないことが原因であったり、そもそも担当者の設定や期限の設定が間違っていたりすることが原因です。そして、さらにその根本的な原因は、チームメンバ―の間で認識のずれがあり、正しくタスクが定義できてないことにあります。
そこで、次の要素についてもあわせて検討し明文化することで、そうした認識ずれをあらかじめ防ぐことができます。
#### **目的**
なぜこのタスクを行う必要があるのかについての記述です。
タスクはプロジェクトゴールとして設定された成果物・成果に漸進的に近づくためのものです。また、タスクを遂行する中で他のメンバーに伝えたい問題点や違和感（**テンション**）が生まれ、プロジェクトを最適化するための材料となります。そのためにそれぞれのタスクがプロジェクトゴールにどのように結びついているかを意識しながら目的を明文化することが有効です。
目的を記載することで、誰がやるべきか（担当者）や、いつまでにやるべきか（期限）も簡単に判断することができます。
#### **想定アウトプット・想定作業時間**
タスクをこなした結果生まれるアウトプットについての具体的イメージの記述です。なお、アウトプットとは、チームメンバーが割り当てられたタスクを完了したことで生まれた結果のことです（Tips3参照）。
例えば、ある資料作成のタスクがあったとき、「スライド～～枚で、見出しはしっかりと作りこむ。本文や記載する図表はダミーでよい」と記述することで、目的に沿ったアウトプットなのかどうかを確認しやすくなります。この場合、タスクの目的が「プレゼンテーション直前のリハーサルに使うため」であればアウトプットとしては不十分でしょうし、「プレゼンテーションの大枠の内容を内々に議論するため」であれば、必要十分なアウトプットになるでしょう。目的が達成できるのであれば、必ずしも完成度を突き詰める必要はありません。それよりも、最小限のアウトプットを確実に作ることを意識しましょう。
また、想定アウトプットのイメージをすり合わせるためには、タスクを終えるまでの想定作業時間を明文化することも効果的です。前述の資料作成のタスクであれば、ある人は1時間しかかからないと思っていた作業が、別の人は4時間もかかると思っていた場合、作りこみのレベルに差がある可能性が高いということが分かります。
さらに、これらの作業を通じてタスクの粒度が大きいと判断された場合は、そのタスクを細かく分解し、ミーティングごとに確実にアウトプットが可能なサイズにしましょう。
# ミーティング環境についてのノウハウ
Project Sprintで意図されているミーティングの効果を得るためには、効率的なミーティング環境の構築が欠かせません。「ミーティング環境の最適化自体についてもチームメンバーで議論し、改善していけること」が、Project Sprintのもたらすものですが、この点についてはすでにいくつかのベストプラクティスが得られていますので、ここではそれらを紹介します。
### **アジェンダの取りまとめ**
プロジェクスプリントではアジェンダの取りまとめが非常に重要です。
例えば、次のようなアジェンダの取りまとめ作業が発生します。
* ミーティング前のアジェンダアイテムの提出と必要な内容の編集
* ミーティング開始後のアジェンダアイテムの追加と必要な内容の編集
* ミーティング開始後のアジェンダアイテムの順番変更
* ミーティング開始後のアジェンダアイテムの繰り越し
これらの作業はすべてファシリテーターの主導のもと、チームメンバー全員で行われます。そのため、アジェンダを全員で確認・編集でき、かつ同じミーティングの中でのアジェンダアイテムの順番変更、ミーティングをまたいだアジェンダアイテムの移動ができる環境をつくっておきましょう。
### **ミーティング中の時間管理**
アジェンダ管理に不可欠な前提が、ミーティング中の時間を的確に把握することです。オンライン / オフラインいずれの場合も、ミーティングに参加しているチームメンバーが時間を把握できるよう、目に入る位置にタイマーと時計を配置しましょう。
タイマーは、「このアジェンダアイテムにあとどれくらい時間をかけられるのか」を把握するのに必要です。
時計は、ミーティング時間の開始時間・終了時間を把握するのに必要です。ミーティングの開始時間の遅れ、延長はつねに起こりうるものですが、絶対時刻を示す時計があると開始・終了の基準を把握・調整することができます。
### **議事録作成**
ミーティングはチームメンバーで認識のズレをなくし、必要な物事を決める重要な場です。ミーティングの後に各自が必要なタスクに取りかかり、次のミーティングでその結果を持ち寄ることを考えると、ミーティングの内容は極力ミーティングの最中に明文化しながら確認、共有しておくことが効率的かつ効果的です。
また、レコーダーがメインで議事を記録するものの、内容に間違いがある場合は最も正しい認識を持つ人がその場で修正してしまったほうがよいでしょう。そのため、共同編集ができるドキュメントツールを議事録作成用ツールとして導入し、ミーティング中に画面表示しながらリアルタイムで議事録作成をすることをおすすめします。
### **ホワイトボード**
ミーティングでは口頭での説明、資料を用いた説明が行われることが多いと考えられますが、それに加え重要なのが手書きの情報による認識合わせです。手書きで図示/文章化することで、きちんとした資料になっていなかったり、口頭で明確に伝えきれていなかったりした内容を伝えやすくなります。これもProject Sprintにおいて重要な「認識のズレをなくす」ことに大いに役立ちます。
なおここでいうホワイトボードは、オフラインミーティングにおける物理的なものに限りません。オンラインミーティング用のホワイトボードツールもありますので、そういったものを利用してもかまいませんし、むしろ保存のしやすさという点ではこちらのほうが優れている場合もあります。
また、議事録を画面表示しながらリアルタイムで作成すると、議事録自体がホワイトボードと同様の役割を果たします。この観点からも、議事録の作成とリアルタイム共有は非常に重要です。
# 継続的改善アプローチ
Project Sprintでは、ミーティングを通じて継続的にプロジェクトの進め方を改善すること（最適化）を目指しています。これらの最適化のための取り組みを総称して「継続的改善アプローチ」と呼んでおり、これはさらに「振り返り」「テンショントリアージ」「ロールセッション」という三つの取り組みに分けられます。プロジェクトの状態やタイミングに適した手法を使うことで、様々な問題や違和感を発見しやすくなります。
## **継続的改善アプローチとは**
継続的改善アプローチは、今後のプロジェクトをよりよい状態にするべく継続的に改善しつづけるための仕組みです。この仕組みを通じてプロジェクトの進捗状況の共有のみならず、プロジェクトの進め方の継続的な改善ができるようになります。マイルストーンの開始時や終了時といった区切りのタイミングだけでなく、定期的にアクションを実施することが重要です。
代表的なアクションとしては「定期的に振り返りを実施して、プロジェクトをよりよい状態にするための改善策を検討する」ということになりますが、実施する視点によって考え方や最適なアプローチも変わってきますので、以下ではそれらについて記載します。
## **いつを見るか**
継続的改善アプローチの中では、\*\*「過去」・「現在」・「未来」\*\*の3つの視点でものごとを捉えます。一般的に「振り返り」といえば「過去」を見るものですが、Project Sprintの継続的改善アプローチでは、「過去」だけではなく「現在」や「未来」にも目を向けることが重要と考えています。
### **なぜ「現在」を見るのか**
「過去」だけではなく「現在」を見るのは、プロジェクトチームのメンバーが今どのような心境なのか（気になっていることや困っていることがないか）をリアルタイムに共有することが、チームの状況を改善していくために不可欠であると考えているからです。
これが「過去」を見る振り返りだけであるならば、問題が共有されるのはその問題が起こってしまった後である可能性が高いのですが、「現在」を見ることで、問題が顕在化もしくは拡大する前に共有し対処することができるようになります。
そのため、Project Sprintでは、定例ミーティングの中での[テンションの共有](https://github.com/copilot-jp/project-sprint/blob/master/JA/v3.1/tutorial/broken-reference/README.md)という形で、定期的に現在の心境を出し合うことを推奨しています。
### **なぜ「未来」を見るのか**
一方、「未来」を見て改善をするのは、実施しようとしているプラン自体を改善してプランの精度を高めていくためです。
リスクマネジメント的視点ではありますが、重要なのは「想定しているプランを実行したら、何が起こるだろうか」という仮想経験を共有することです。それによって、仮に失敗しそうであれば事前にプランを改善することができ、プランそのものの質を高めることができます。また、仮にプランそのものに問題がない場合も、一度仮想的に経験をしているので、実際に実施する際に余裕を持って対応することができます。
「未来」を見て改善するアプローチの1つとして、「プレモータム・シンキング」と呼ばれるものがあります。これは、日本語に訳すと「事前検死」というもので、これから取り組んでいくプロジェクトが失敗したと仮定して、その失敗要因を分析したり、解決策を検討するというアプローチです。ビジネスにおいては、「早く失敗すること」の重要性がよく指摘されますが、プレモータム・シンキングは最も早く失敗を体験できるものであり、その意味でも有効な1つの手法といえます。
### **現在の気持ちを共有することの重要性**
プロジェクトを改善していく上で、このように「過去」「現在」「未来」を見ることはいずれも重要ではありますが、中でも重要なのは「現在」の気持ちを共有することだと考えています。 気持ちを吐き出すことができる場があることで、前述のようにプロジェクトの課題が改善されるだけでなく、メンバーのプロジェクトへの参加感の向上にもつながるものです。
## **何を見るか**
では、「過去」「現在」「未来」について、具体的に何を見るとよいでしょうか。 [Project Sprint 101](https://github.com/copilot-jp/project-sprint/blob/master/ja-v3.1.0/tutorial/broken-reference/README.md)でも記載しているように、Project Sprintでは単にプロジェクトの進捗を見るのではなく、プログレスやチーミングが理想の状態にあるかどうか、またプロセスが円滑に機能しているかどうかがプロジェクトを進めていく上で重要な要素と考えており、継続的改善アプローチでも、これらを検証することを推奨しています。
以上、「いつを見るか」ということと「何を見るか」という視点をかけ合わせると、それぞれの項目において想定される基本的な問いは下表のような事項になります。 これは基本形ですので、各プロジェクトにおいて必要な問いそのものを定義した上で、そのプロジェクトにとって必要な検証・改善が行われる状態を構築していきましょう。
| 視点 | 過去 | 現在 | 未来 |
| ----- | ---------------------------------------------------------- | --------------------------------------------------------------- | ----------------------------------------------- |
| プログレス | ・マイルストーンを達成できたか？
・最終的な成果に繋がるアウトプットを積み重ねることができたか？
| ・今アウトプットすべきものを理解・納得しているか？
・アウトプットすべきものについて不安や心配事はないか？
| ・ゴールを達成できそうか？
・もし失敗するとしたら、何が原因になりそうか？
|
| チーミング | ・メンバー相互の期待値は明確だったか？ | ・メンバー相互の期待値に違和感はないか？ | ・今の期待値のままプロジェクトを進めたら、将来的にどうなるだろうか？ |
| プロセス | ・プロジェクトやミーティングの進め方はどうだったか？ | ・プロジェクトやミーティングの進め方に違和感はないか？ | ・今の進め方を継続したら、将来的にどうなるだろうか？ |
---
[Next Page](/llms-full.txt/1)