# Definitions

Project Sprint は、プロジェクトチーム自らがプロジェクトの主体となり、小さな成果を繰り返し確実に生み出すことを通じて、環境の変化を捉えつづけながら自律的にプロジェクトを推進するためのフレームワークです。

この Definitions では、Project Sprint を理解するための前提として読者の皆さんと共有したい、Project Sprint の世界観を説明し、その他の用語を定義します。

## 1. Project Sprint の世界観

**i) プロジェクトチームの意思にもっとも重きを置く**

Project Sprint は、プロジェクトチームがプロジェクトの中心であり、プロジェクトチームの意思がプロジェクトにおけるあらゆる事柄を決定するという世界観に立ちます。この世界観の下では、プロジェクトチームはプロジェクト内外の変化を自らの意思に基づいて解釈し、それに応じて自律的に行動することができます。

プロジェクトチームは、プロジェクトにおける唯一の決定権者かつ実行主体として自らの意思に基づいてプロジェクトを定義し、その後も状況の変化に応じてプロジェクトの再定義を繰り返しながらプロジェクトを推進していきます

プロジェクトゴールを変更の余地のない所与の条件と捉え、それに規定された「プロジェクト」を活動の固定的な枠組みとして受け入れることもできます。しかしそういった場合、プロジェクトチームはあくまで、与えられた定義や枠組みに従ってプロジェクト達成の条件を満たすために活動する、プロジェクトの構成要素のひとつでしかありません。そのため、プロジェクトメンバーという生身の人間がプロジェクト推進の最前線で活動しつづける中で感じる違和感や閃き、そしてプロジェクトチームの個性は、プロジェクトの枠組みや推進過程に十分に反映されず、プロジェクトチームの行動に不自由さが生じることがありました。

Project Sprint におけるプロジェクトチームは、所与の条件にそのまま従う参加者ではなく、プロジェクトを取り巻く状況を意思を持って解釈し納得した上でプロジェクトを定義する主体でなくてはなりません。そのことにより、プロジェクトチームはプロジェクトの実行主体として、プロジェクトを構想し定義しつづけていく責任とプロジェクト外部の環境の変化を捉えつづけていく責任、さらに外部のステークホルダーと自ら調整を行っていく責任を負うことになります。それはときに、プロジェクトチームにとって大きな挑戦になるかもしれません。

しかし、この考え方により、プロジェクトチームは固定的な枠組みに押し込められることなく、自らの意思で自由にプロジェクトを定義し、環境の変化を素早く捉えながら自律的にプロジェクトを推進することができるようになります。

**ii) 状況に応じて最適なアプローチを自由に決定する**

Project Sprint は、どのようなアプローチでプロジェクトを進めるかをその時々の状況に応じて自由に決定できるという世界観に立ちます。この世界観の下では、プロジェクトチームは状況の変化をキャッチすることにどの程度能動的でいるかを自らの意思に基づいて決定し、それに応じて最適な進め方を取ることができます。

プロジェクト進行のアプローチには、大きく分けて予測型（ウォーターフォール）と適応型（アジャイル）の二つがあります。

予測型は、変化の少ない環境を前提とし、予め設定した最終ゴールを目指してロードマップを組み立て、それに従ってプロジェクトを進めるというアプローチです。予測型で進められるプロジェクトは図1-1のように、プロジェクトの大枠が固定されており、達成すべきゴールはプロジェクト開始時点から明確です。プロジェクトチームはそれらの要求に応じた計画を立て、ゴールに向かって順を追って成果を積み上げていきます。

![予測型で進むプロジェクト](https://855156827-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FRxkBtzTPMYA9SyqVG360%2Fuploads%2Fgit-blob-1a604136ea1913fb60850620455fbb058c4212bb%2Fillust_prediction.png?alt=media)

一方適応型は、環境は変化するものだということを前提とし、その変化を捉えて能動的に最終ゴールとロードマップを変化させながら進んでいくというアプローチを取ります。適応型で進められるプロジェクトは図2-2のように、不確実性と変動性が高く、プロジェクト開始時点では最終ゴールすらも曖昧模糊としたものであることもありますが、反復的・漸進的な取り組みの中で、先々のゴールやロードマップは自ずと詳細化・明確化されてゆきます。

![適応型で進むプロジェクト](https://855156827-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FRxkBtzTPMYA9SyqVG360%2Fuploads%2Fgit-blob-1b7246b409d85f04213f995f6860b8c9a71d96ab%2Fillust_daptation.png?alt=media)

個々のプロジェクトについて、予測型なら予測型、適応型なら適応型で進めるものと捉えることもできます。しかし、ひとつのプロジェクトの中でも、工程が予め明確になっており予測型で計画的に進めることができる部分と、未知の部分が多く適応型で柔軟に進めたほうがよい部分が混在することが多いものです。また、予測型と適応型はそもそも二項対立で切り分けられるものではなく、予測型と適応型の間には変化に対してどの程度能動的であるかにおいて無数のパターンがグラデーション状に存在します。

![変化への能動性のグラデーション](https://855156827-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FRxkBtzTPMYA9SyqVG360%2Fuploads%2Fgit-blob-9045226957e49bd247c9e65d57fbff5d347a2db7%2Fillust_gradation.png?alt=media)

そのため Project Sprint は、プロジェクトへのアプローチを固定する必要はなく、状況に応じて適切なアプローチを柔軟に選択すればよいというハイブリッド型の考え方を取ります。

この考え方により、プロジェクトチームは、ロードマップの詳細さや厳密さに強弱をつけながら、効率的にプロジェクトを推進することができるようになります。

**iii) 探索的な小さな実験の繰り返しとしてプロジェクトを進める**

Project Sprint は、プロジェクトを探索的な小さな実験と検証の繰り返しと捉えるという世界観に立ちます。この世界観の下では、プロジェクトチームは将来にわたる計画を立てることに必要以上に囚われず、目の前の具体的な課題に取り組んで小さくとも確実にプロジェクトを推進することができます。

プロジェクトは、全体を一気に定義したり計画したりするものではなく、小さなサイクルの繰り返しであると捉えられます。最終的に達成すべき成果のために必要な要素を小さな成果に分割し、分割したひとつひとつの成果に対して仮説を立てて実行した上で、その検証をもとに以降のフェーズの軌道修正を行います。こうして反復的かつ漸進的にプロジェクトを進めていくのです。

プロジェクトにおける最終的な成果の達成までの一連の流れを、できるだけ失敗や手戻りが生じないように計画的に推進していこうと考えることもできます。しかし、計画を綿密に立ててもその後大幅に修正が必要になったり、プロジェクト全体を同じ精度で捉えつづけようとすることでメンバーの認知負荷が高くなりすぎたりすることもあります。

そのためProject Sprint では、仮説の設定とその仮説に沿った行動を、短いタイムスパンで小さく実験的に繰り返すという進め方を取ります。

個々の実験において重要なのは実験結果を振り返って次のフェーズに生かすことであって、仮説が正しかったかどうかはさほど重要なことではありません。「正しい仮説を立てる」ことにこだわって行動の速度が鈍ったり保守的になったりするよりは、「取り組んでみることで見えてくるものもある」と捉えて前向きに挑戦し、得られた結果を次のフェーズの改善材料にしていくのです。また、仮説が間違っていたとしても、実験の結果がプロジェクト全体の成功につながる成果を実現することもあります。ただし、行動を起こしやすく軌道修正を容易にするため、個々の実験のサイズは小さければ小さいほどよいということに留意する必要があります。

このようにプロジェクトを進めることで、プロジェクトチームは、創造性豊かに小さな挑戦を重ね、仮説を検証して小さく軌道修正を繰り返すことで、複雑な問題を素早く解決して最終的な成果に向けてプロジェクトを推進していくことができます。

## 2. 用語集

このセクションの用語は、Project Sprint の前提を理解し、Framework の記述をスムーズに読み進めるために定義したものです。

図3は、用語の全体像をおおまかに示したものです。個々の用語の詳細や相互の関係については、[Framework](https://www.projectsprint.org/ja/v4.3/framework) などで別途記述されます。

* **チーム**　共通の目的をもってプロジェクト内の会議体に参加し、目的に向かって出力を行うメンバーの集まり。
* **プロジェクトチーム**　プロジェクトの目的に対する共通了解をもち、プロジェクトの達成に向けて自律的に協働するメンバーの集まり。チームの一種だが、例外的に、全メンバーが参加する会議体を持たない場合や、出力を行わないアドバイザー的な立ち位置のメンバーを持つ場合がある。
* **プロジェクト**　プロジェクトチームが、プロジェクト外部の社会に何らかの変化や価値を提供するために、自発的に行う活動。
* **活動**　チームや個人が、意思や目的をもって、何ごとかをある状態から別の状態に変化させるために、何らかの出力を伴う身体的な行動をすること。
* **フェーズ**　チームがある目的をもって活動する期間。
* **プロジェクトストーリー**　プロジェクトチームが次の行動を決定するための指針として、目的達成までの過程をシンプルに時系列で表現したもの。各チームのフラッグが集まることで表現される。

<div data-full-width="false"><img src="https://855156827-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FRxkBtzTPMYA9SyqVG360%2Fuploads%2Fgit-blob-7d082f99c0af6a241d3971acef60ed82514f43d5%2Fproject_story.png?alt=media" alt="フラッグによるプロジェクトストーリー"></div>

* **フラッグ**　チームが、外部からの制約や実現したい価値・成果を踏まえ、ある目的をもって設定した到達点。以下の要素を持つ。

<div data-full-width="false"><img src="https://855156827-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FRxkBtzTPMYA9SyqVG360%2Fuploads%2Fgit-blob-1164694221df915ed419fc9eaeab27f8343f16c4%2Felements_of_flag.png?alt=media" alt="フラッグの要素"></div>

* **成果**　チームが、プロジェクトにおいて実現を目指す価値を踏まえ、プロジェクト内の他チームやプロジェクト全体に向けて生み出す所産。
* **価値**　プロジェクト外部のステークホルダーが、プロジェクトが実行された結果として受け取る便益。便益の有無や軽重の評価はステークホルダーの認識に委ねられるので、プロジェクトチームが創出を目指す価値はあくまで仮説である。
* **ゴール**　フラッグのチームがある期日において達成していたい状態。要素として、あるべき状態・成果物・完了日の3つをもつ。
  * **あるべき状態**　その状態に至ることで成果を達成したと判断できる、状態や定性的な捉え方。
  * **成果物**　出力・作成されることで成果を達成したと判断できる、有形的なものや定量的な値。
* **理由**　プロジェクトの成立や推進に関して、過去に存在する背景や経緯。
* **目的**　プロジェクトにおいて達成したい事柄に関するプロジェクトチームの意思。
* **制約**　プロジェクトの外部環境にありプロジェクトチームの意思で調整することができない、プロジェクトチームの行動に制限を与える事柄。または、プロジェクトチームがステークホルダーから必ず達成することを期待されている事柄。
* **イベント**　プロジェクトチームの行動が制限される出来事や期日。
* **出力**　チームメンバーが作成物を産出すること。
* **作成物**　チームメンバーによって生み出され、チームに対して共有されて他のチームメンバーが意見を述べたり助言をしたりといったリアクションを取ることが可能な、かたちあるもの。
* **実験**　行動を起こしやすく軌道修正を容易にするため、相対的に小さな規模で行われて次の行動の改善材料となる、作成物の産出を伴う成果の仮説構築・実行・検証のサイクル。
* **定例会議**　チームが、短期的・定期的なサイクルで反復的に実施する対話の場。各メンバーが自身の次の行動を自己決定できる状態を目指して他のメンバーと同期し対話を行い、共通了解の形成、問題の共同解決、アイデアの共同創造、意思決定などを行う。


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://www.projectsprint.org/ja/v4.3/definitions.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
