├── CODE ├── v2 │ ├── .0_en │ │ ├── tutorial │ │ │ ├── user-community.md │ │ │ ├── README.md │ │ │ ├── 3-2.md │ │ │ ├── 3-3.md │ │ │ └── 1-2.md │ │ ├── images │ │ │ ├── essentials.png │ │ │ ├── track_eng.png │ │ │ └── goal-milestone_eng.png │ │ ├── tips │ │ │ ├── tips3.md │ │ │ ├── tips6.md │ │ │ ├── README.md │ │ │ ├── tips8.md │ │ │ ├── tips14.md │ │ │ ├── tips10.md │ │ │ ├── tips4.md │ │ │ ├── tips2.md │ │ │ └── tips13.md │ │ └── reference.md │ └── .2_ja │ │ ├── images │ │ ├── agenda.png │ │ ├── basic.png │ │ ├── roles.png │ │ ├── track.png │ │ ├── process.png │ │ ├── project.png │ │ ├── essentials.png │ │ ├── projectgoal.png │ │ └── goal-milestone.png │ │ ├── tutorial │ │ ├── 4-1.md │ │ ├── README.md │ │ ├── 3-3.md │ │ ├── 1-2.md │ │ ├── 3-2.md │ │ ├── project-sprint-101.md │ │ ├── 1-3.md │ │ ├── 2-1.md │ │ └── 3-1.md │ │ ├── tips │ │ ├── 2-2.md │ │ ├── 4-2.md │ │ ├── 4-1.md │ │ ├── 3-2-2.md │ │ ├── 4-5.md │ │ ├── README.md │ │ ├── 3-2-3.md │ │ ├── 1-1.md │ │ ├── 1-6.md │ │ ├── 1-4.md │ │ ├── 1-5.md │ │ ├── 1-3.md │ │ ├── 2-1.md │ │ ├── 3-2-1.md │ │ ├── 4-4.md │ │ └── 3-1.md │ │ ├── reference.md │ │ ├── advance.md │ │ └── README.md ├── v3 │ ├── .0_ja │ │ ├── images │ │ │ ├── agenda.png │ │ │ ├── basic.png │ │ │ ├── roles.png │ │ │ ├── track.png │ │ │ ├── process.png │ │ │ ├── project.png │ │ │ ├── essentials.png │ │ │ ├── main-track.png │ │ │ ├── projectgoal.png │ │ │ └── goal-milestone.png │ │ ├── essentials.md │ │ ├── tutorial │ │ │ ├── section4-4.md │ │ │ ├── section4-1-3.md │ │ │ ├── section4-1-2.md │ │ │ ├── section3-2-1.md │ │ │ ├── section4-2.md │ │ │ ├── section3-3.md │ │ │ ├── README.md │ │ │ ├── section2-2.md │ │ │ ├── section2-1-1.md │ │ │ ├── section2-0.md │ │ │ ├── section2-1-2.md │ │ │ └── section4-3.md │ │ ├── reference.md │ │ └── README.md │ ├── .1_ja │ │ ├── images │ │ │ ├── agenda.png │ │ │ ├── basic.png │ │ │ ├── roles.png │ │ │ ├── track.png │ │ │ ├── process.png │ │ │ ├── project.png │ │ │ ├── essentials.png │ │ │ ├── main-track.png │ │ │ ├── projectgoal.png │ │ │ └── goal-milestone.png │ │ ├── essentials.md │ │ ├── tutorial │ │ │ ├── section4-4.md │ │ │ ├── section4-1-3.md │ │ │ ├── section4-1-2.md │ │ │ ├── section2-2-2.md │ │ │ ├── section3-2-1.md │ │ │ ├── section2-2-3.md │ │ │ ├── section4-2.md │ │ │ ├── section3-3.md │ │ │ ├── section2-3.md │ │ │ ├── README.md │ │ │ ├── section2-0.md │ │ │ ├── section2-1.md │ │ │ ├── section2-2-1.md │ │ │ └── section4-3.md │ │ ├── README.md │ │ └── reference.md │ ├── .2_ja │ │ ├── images │ │ │ ├── agenda.png │ │ │ ├── basic.png │ │ │ ├── roles.png │ │ │ ├── track.png │ │ │ ├── pjs_logo.png │ │ │ ├── process.png │ │ │ ├── project.png │ │ │ ├── essentials.png │ │ │ ├── main-track.png │ │ │ ├── projectgoal.png │ │ │ └── goal-milestone.png │ │ ├── essentials.md │ │ ├── theories │ │ │ ├── agenda.md │ │ │ ├── success_metrics.md │ │ │ ├── rolls.md │ │ │ ├── project_goals.md │ │ │ ├── tracks.md │ │ │ ├── milestones.md │ │ │ ├── project_lifecycle.md │ │ │ └── project_environments.md │ │ ├── practices │ │ │ ├── agenda.md │ │ │ ├── role_session.md │ │ │ ├── rolls.md │ │ │ ├── meeting_rolls.md │ │ │ ├── tension_triage.md │ │ │ ├── stand-up_meetings.md │ │ │ ├── project_environments.md │ │ │ ├── tasks.md │ │ │ ├── reviewing_project_goals_and_milestones.md │ │ │ ├── tracks.md │ │ │ ├── meetings.md │ │ │ ├── meeting_environments.md │ │ │ └── reviewing_rolls.md │ │ ├── README.md │ │ ├── reference.md │ │ └── theories_and_practices.md │ └── .3_ja │ │ ├── images │ │ ├── agenda.png │ │ ├── basic.png │ │ ├── roles.png │ │ ├── track.png │ │ ├── pjs_logo.png │ │ ├── process.png │ │ ├── project.png │ │ ├── essentials.png │ │ ├── main-track.png │ │ ├── projectgoal.png │ │ └── goal-milestone.png │ │ ├── essentials.md │ │ ├── theories │ │ ├── agenda.md │ │ ├── success_metrics.md │ │ ├── rolls.md │ │ ├── restrictions.md │ │ ├── project_goals.md │ │ ├── milestones.md │ │ ├── tracks.md │ │ └── project_environments.md │ │ ├── practices │ │ ├── agenda.md │ │ ├── role_session.md │ │ ├── rolls.md │ │ ├── meeting_rolls.md │ │ ├── tension_triage.md │ │ ├── stand-up_meetings.md │ │ ├── project_environments.md │ │ ├── tasks.md │ │ ├── reviewing_project_goals_and_milestones.md │ │ ├── tracks.md │ │ ├── meetings.md │ │ ├── meeting_environments.md │ │ └── reviewing_rolls.md │ │ ├── README.md │ │ ├── reference.md │ │ └── theories_and_practices.md ├── v4 │ ├── .3_ja │ │ ├── images │ │ │ ├── pjs_og.png │ │ │ ├── pjs_logo.png │ │ │ ├── documents.png │ │ │ ├── mechanisms.png │ │ │ ├── project_story.png │ │ │ ├── task_action_1.png │ │ │ ├── task_action_2.png │ │ │ ├── elements_of_flag.png │ │ │ ├── illust_aspects.png │ │ │ ├── illust_daptation.png │ │ │ ├── illust_documents.png │ │ │ ├── illust_gradation.png │ │ │ ├── illust_outcome.png │ │ │ ├── pp_definitions.png │ │ │ ├── illust_prediction.png │ │ │ ├── shared_leadership.png │ │ │ └── common_understanding.png │ │ └── README.md │ ├── .0_ja │ │ ├── images │ │ │ ├── pjs_logo.png │ │ │ ├── mechanisms.png │ │ │ ├── illust_aspects.png │ │ │ ├── illust_daptation.png │ │ │ ├── illust_documents.png │ │ │ ├── illust_gradation.png │ │ │ ├── illust_outcome.png │ │ │ ├── pp_definitions.png │ │ │ ├── illust_prediction.png │ │ │ ├── shared_leadership.png │ │ │ └── common_understanding.png │ │ ├── README.md │ │ └── introduction.md │ ├── .1_ja │ │ ├── images │ │ │ ├── pjs_logo.png │ │ │ ├── mechanisms.png │ │ │ ├── illust_aspects.png │ │ │ ├── illust_daptation.png │ │ │ ├── illust_documents.png │ │ │ ├── illust_gradation.png │ │ │ ├── illust_outcome.png │ │ │ ├── pp_definitions.png │ │ │ ├── illust_prediction.png │ │ │ ├── shared_leadership.png │ │ │ └── common_understanding.png │ │ └── README.md │ └── .2_ja │ │ ├── images │ │ ├── pjs_logo.png │ │ ├── mechanisms.png │ │ ├── elements_of_flag.png │ │ ├── illust_aspects.png │ │ ├── illust_daptation.png │ │ ├── illust_documents.png │ │ ├── illust_gradation.png │ │ ├── illust_outcome.png │ │ ├── pp_definitions.png │ │ ├── illust_prediction.png │ │ ├── shared_leadership.png │ │ └── common_understanding.png │ │ └── README.md └── README.md ├── practical-guide ├── CODEv4_based │ ├── elements_of_flag.md │ ├── images │ │ ├── job_action.png │ │ └── job_action_cycle.png │ ├── README.md │ └── minimum_guide.md └── README.md └── README.md /CODE/v2/.0_en/tutorial/user-community.md: -------------------------------------------------------------------------------- 1 | # User Community 2 | 3 | -------------------------------------------------------------------------------- /practical-guide/CODEv4_based/elements_of_flag.md: -------------------------------------------------------------------------------- 1 | # フラッグの要素 2 | 3 | coming soon ! 4 | -------------------------------------------------------------------------------- /CODE/v2/.2_ja/images/agenda.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v2/.2_ja/images/agenda.png -------------------------------------------------------------------------------- /CODE/v2/.2_ja/images/basic.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v2/.2_ja/images/basic.png -------------------------------------------------------------------------------- /CODE/v2/.2_ja/images/roles.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v2/.2_ja/images/roles.png -------------------------------------------------------------------------------- /CODE/v2/.2_ja/images/track.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v2/.2_ja/images/track.png -------------------------------------------------------------------------------- /CODE/v3/.0_ja/images/agenda.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v3/.0_ja/images/agenda.png -------------------------------------------------------------------------------- /CODE/v3/.0_ja/images/basic.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v3/.0_ja/images/basic.png -------------------------------------------------------------------------------- /CODE/v3/.0_ja/images/roles.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v3/.0_ja/images/roles.png -------------------------------------------------------------------------------- /CODE/v3/.0_ja/images/track.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v3/.0_ja/images/track.png -------------------------------------------------------------------------------- /CODE/v3/.1_ja/images/agenda.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v3/.1_ja/images/agenda.png -------------------------------------------------------------------------------- /CODE/v3/.1_ja/images/basic.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v3/.1_ja/images/basic.png -------------------------------------------------------------------------------- /CODE/v3/.1_ja/images/roles.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v3/.1_ja/images/roles.png -------------------------------------------------------------------------------- /CODE/v3/.1_ja/images/track.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v3/.1_ja/images/track.png -------------------------------------------------------------------------------- /CODE/v3/.2_ja/images/agenda.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v3/.2_ja/images/agenda.png -------------------------------------------------------------------------------- /CODE/v3/.2_ja/images/basic.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v3/.2_ja/images/basic.png -------------------------------------------------------------------------------- /CODE/v3/.2_ja/images/roles.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v3/.2_ja/images/roles.png -------------------------------------------------------------------------------- /CODE/v3/.2_ja/images/track.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v3/.2_ja/images/track.png -------------------------------------------------------------------------------- /CODE/v3/.3_ja/images/agenda.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v3/.3_ja/images/agenda.png -------------------------------------------------------------------------------- /CODE/v3/.3_ja/images/basic.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v3/.3_ja/images/basic.png -------------------------------------------------------------------------------- /CODE/v3/.3_ja/images/roles.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v3/.3_ja/images/roles.png -------------------------------------------------------------------------------- /CODE/v3/.3_ja/images/track.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v3/.3_ja/images/track.png -------------------------------------------------------------------------------- /CODE/v4/.3_ja/images/pjs_og.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v4/.3_ja/images/pjs_og.png -------------------------------------------------------------------------------- /CODE/v2/.2_ja/images/process.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v2/.2_ja/images/process.png -------------------------------------------------------------------------------- /CODE/v2/.2_ja/images/project.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v2/.2_ja/images/project.png -------------------------------------------------------------------------------- /CODE/v3/.0_ja/images/process.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v3/.0_ja/images/process.png -------------------------------------------------------------------------------- /CODE/v3/.0_ja/images/project.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v3/.0_ja/images/project.png -------------------------------------------------------------------------------- /CODE/v3/.1_ja/images/process.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v3/.1_ja/images/process.png -------------------------------------------------------------------------------- /CODE/v3/.1_ja/images/project.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v3/.1_ja/images/project.png -------------------------------------------------------------------------------- /CODE/v3/.2_ja/images/pjs_logo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v3/.2_ja/images/pjs_logo.png -------------------------------------------------------------------------------- /CODE/v3/.2_ja/images/process.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v3/.2_ja/images/process.png -------------------------------------------------------------------------------- /CODE/v3/.2_ja/images/project.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v3/.2_ja/images/project.png -------------------------------------------------------------------------------- /CODE/v3/.3_ja/images/pjs_logo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v3/.3_ja/images/pjs_logo.png -------------------------------------------------------------------------------- /CODE/v3/.3_ja/images/process.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v3/.3_ja/images/process.png -------------------------------------------------------------------------------- /CODE/v3/.3_ja/images/project.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v3/.3_ja/images/project.png -------------------------------------------------------------------------------- /CODE/v4/.0_ja/images/pjs_logo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v4/.0_ja/images/pjs_logo.png -------------------------------------------------------------------------------- /CODE/v4/.1_ja/images/pjs_logo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v4/.1_ja/images/pjs_logo.png -------------------------------------------------------------------------------- /CODE/v4/.2_ja/images/pjs_logo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v4/.2_ja/images/pjs_logo.png -------------------------------------------------------------------------------- /CODE/v4/.3_ja/images/pjs_logo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v4/.3_ja/images/pjs_logo.png -------------------------------------------------------------------------------- /CODE/v2/.0_en/images/essentials.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v2/.0_en/images/essentials.png -------------------------------------------------------------------------------- /CODE/v2/.0_en/images/track_eng.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v2/.0_en/images/track_eng.png -------------------------------------------------------------------------------- /CODE/v2/.2_ja/images/essentials.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v2/.2_ja/images/essentials.png -------------------------------------------------------------------------------- /CODE/v2/.2_ja/images/projectgoal.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v2/.2_ja/images/projectgoal.png -------------------------------------------------------------------------------- /CODE/v3/.0_ja/images/essentials.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v3/.0_ja/images/essentials.png -------------------------------------------------------------------------------- /CODE/v3/.0_ja/images/main-track.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v3/.0_ja/images/main-track.png -------------------------------------------------------------------------------- /CODE/v3/.0_ja/images/projectgoal.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v3/.0_ja/images/projectgoal.png -------------------------------------------------------------------------------- /CODE/v3/.1_ja/images/essentials.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v3/.1_ja/images/essentials.png -------------------------------------------------------------------------------- /CODE/v3/.1_ja/images/main-track.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v3/.1_ja/images/main-track.png -------------------------------------------------------------------------------- /CODE/v3/.1_ja/images/projectgoal.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v3/.1_ja/images/projectgoal.png -------------------------------------------------------------------------------- /CODE/v3/.2_ja/images/essentials.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v3/.2_ja/images/essentials.png -------------------------------------------------------------------------------- /CODE/v3/.2_ja/images/main-track.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v3/.2_ja/images/main-track.png -------------------------------------------------------------------------------- /CODE/v3/.2_ja/images/projectgoal.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v3/.2_ja/images/projectgoal.png -------------------------------------------------------------------------------- /CODE/v3/.3_ja/images/essentials.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v3/.3_ja/images/essentials.png -------------------------------------------------------------------------------- /CODE/v3/.3_ja/images/main-track.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v3/.3_ja/images/main-track.png -------------------------------------------------------------------------------- /CODE/v3/.3_ja/images/projectgoal.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v3/.3_ja/images/projectgoal.png -------------------------------------------------------------------------------- /CODE/v4/.0_ja/images/mechanisms.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v4/.0_ja/images/mechanisms.png -------------------------------------------------------------------------------- /CODE/v4/.1_ja/images/mechanisms.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v4/.1_ja/images/mechanisms.png -------------------------------------------------------------------------------- /CODE/v4/.2_ja/images/mechanisms.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v4/.2_ja/images/mechanisms.png -------------------------------------------------------------------------------- /CODE/v4/.3_ja/images/documents.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v4/.3_ja/images/documents.png -------------------------------------------------------------------------------- /CODE/v4/.3_ja/images/mechanisms.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v4/.3_ja/images/mechanisms.png -------------------------------------------------------------------------------- /CODE/v4/.3_ja/images/project_story.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v4/.3_ja/images/project_story.png -------------------------------------------------------------------------------- /CODE/v4/.3_ja/images/task_action_1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v4/.3_ja/images/task_action_1.png -------------------------------------------------------------------------------- /CODE/v4/.3_ja/images/task_action_2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v4/.3_ja/images/task_action_2.png -------------------------------------------------------------------------------- /CODE/v2/.2_ja/images/goal-milestone.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v2/.2_ja/images/goal-milestone.png -------------------------------------------------------------------------------- /CODE/v3/.0_ja/images/goal-milestone.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v3/.0_ja/images/goal-milestone.png -------------------------------------------------------------------------------- /CODE/v3/.1_ja/images/goal-milestone.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v3/.1_ja/images/goal-milestone.png -------------------------------------------------------------------------------- /CODE/v3/.2_ja/images/goal-milestone.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v3/.2_ja/images/goal-milestone.png -------------------------------------------------------------------------------- /CODE/v3/.3_ja/images/goal-milestone.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v3/.3_ja/images/goal-milestone.png -------------------------------------------------------------------------------- /CODE/v4/.0_ja/images/illust_aspects.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v4/.0_ja/images/illust_aspects.png -------------------------------------------------------------------------------- /CODE/v4/.0_ja/images/illust_daptation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v4/.0_ja/images/illust_daptation.png -------------------------------------------------------------------------------- /CODE/v4/.0_ja/images/illust_documents.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v4/.0_ja/images/illust_documents.png -------------------------------------------------------------------------------- /CODE/v4/.0_ja/images/illust_gradation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v4/.0_ja/images/illust_gradation.png -------------------------------------------------------------------------------- /CODE/v4/.0_ja/images/illust_outcome.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v4/.0_ja/images/illust_outcome.png -------------------------------------------------------------------------------- /CODE/v4/.0_ja/images/pp_definitions.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v4/.0_ja/images/pp_definitions.png -------------------------------------------------------------------------------- /CODE/v4/.1_ja/images/illust_aspects.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v4/.1_ja/images/illust_aspects.png -------------------------------------------------------------------------------- /CODE/v4/.1_ja/images/illust_daptation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v4/.1_ja/images/illust_daptation.png -------------------------------------------------------------------------------- /CODE/v4/.1_ja/images/illust_documents.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v4/.1_ja/images/illust_documents.png -------------------------------------------------------------------------------- /CODE/v4/.1_ja/images/illust_gradation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v4/.1_ja/images/illust_gradation.png -------------------------------------------------------------------------------- /CODE/v4/.1_ja/images/illust_outcome.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v4/.1_ja/images/illust_outcome.png -------------------------------------------------------------------------------- /CODE/v4/.1_ja/images/pp_definitions.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v4/.1_ja/images/pp_definitions.png -------------------------------------------------------------------------------- /CODE/v4/.2_ja/images/elements_of_flag.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v4/.2_ja/images/elements_of_flag.png -------------------------------------------------------------------------------- /CODE/v4/.2_ja/images/illust_aspects.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v4/.2_ja/images/illust_aspects.png -------------------------------------------------------------------------------- /CODE/v4/.2_ja/images/illust_daptation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v4/.2_ja/images/illust_daptation.png -------------------------------------------------------------------------------- /CODE/v4/.2_ja/images/illust_documents.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v4/.2_ja/images/illust_documents.png -------------------------------------------------------------------------------- /CODE/v4/.2_ja/images/illust_gradation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v4/.2_ja/images/illust_gradation.png -------------------------------------------------------------------------------- /CODE/v4/.2_ja/images/illust_outcome.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v4/.2_ja/images/illust_outcome.png -------------------------------------------------------------------------------- /CODE/v4/.2_ja/images/pp_definitions.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v4/.2_ja/images/pp_definitions.png -------------------------------------------------------------------------------- /CODE/v4/.3_ja/images/elements_of_flag.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v4/.3_ja/images/elements_of_flag.png -------------------------------------------------------------------------------- /CODE/v4/.3_ja/images/illust_aspects.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v4/.3_ja/images/illust_aspects.png -------------------------------------------------------------------------------- /CODE/v4/.3_ja/images/illust_daptation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v4/.3_ja/images/illust_daptation.png -------------------------------------------------------------------------------- /CODE/v4/.3_ja/images/illust_documents.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v4/.3_ja/images/illust_documents.png -------------------------------------------------------------------------------- /CODE/v4/.3_ja/images/illust_gradation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v4/.3_ja/images/illust_gradation.png -------------------------------------------------------------------------------- /CODE/v4/.3_ja/images/illust_outcome.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v4/.3_ja/images/illust_outcome.png -------------------------------------------------------------------------------- /CODE/v4/.3_ja/images/pp_definitions.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v4/.3_ja/images/pp_definitions.png -------------------------------------------------------------------------------- /CODE/v2/.0_en/images/goal-milestone_eng.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v2/.0_en/images/goal-milestone_eng.png -------------------------------------------------------------------------------- /CODE/v4/.0_ja/images/illust_prediction.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v4/.0_ja/images/illust_prediction.png -------------------------------------------------------------------------------- /CODE/v4/.0_ja/images/shared_leadership.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v4/.0_ja/images/shared_leadership.png -------------------------------------------------------------------------------- /CODE/v4/.1_ja/images/illust_prediction.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v4/.1_ja/images/illust_prediction.png -------------------------------------------------------------------------------- /CODE/v4/.1_ja/images/shared_leadership.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v4/.1_ja/images/shared_leadership.png -------------------------------------------------------------------------------- /CODE/v4/.2_ja/images/illust_prediction.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v4/.2_ja/images/illust_prediction.png -------------------------------------------------------------------------------- /CODE/v4/.2_ja/images/shared_leadership.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v4/.2_ja/images/shared_leadership.png -------------------------------------------------------------------------------- /CODE/v4/.3_ja/images/illust_prediction.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v4/.3_ja/images/illust_prediction.png -------------------------------------------------------------------------------- /CODE/v4/.3_ja/images/shared_leadership.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v4/.3_ja/images/shared_leadership.png -------------------------------------------------------------------------------- /CODE/v4/.0_ja/images/common_understanding.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v4/.0_ja/images/common_understanding.png -------------------------------------------------------------------------------- /CODE/v4/.1_ja/images/common_understanding.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v4/.1_ja/images/common_understanding.png -------------------------------------------------------------------------------- /CODE/v4/.2_ja/images/common_understanding.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v4/.2_ja/images/common_understanding.png -------------------------------------------------------------------------------- /CODE/v4/.3_ja/images/common_understanding.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/CODE/v4/.3_ja/images/common_understanding.png -------------------------------------------------------------------------------- /practical-guide/CODEv4_based/images/job_action.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/practical-guide/CODEv4_based/images/job_action.png -------------------------------------------------------------------------------- /practical-guide/CODEv4_based/images/job_action_cycle.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/copilot-jp/project-sprint/HEAD/practical-guide/CODEv4_based/images/job_action_cycle.png -------------------------------------------------------------------------------- /CODE/v2/.2_ja/tutorial/4-1.md: -------------------------------------------------------------------------------- 1 | # ユーザーコミュニティ 2 | 3 | この記事では、プロジェクトスプリントのユーザーコミュニティについて紹介します。 4 | 5 | プロジェクトスプリントは[CC BY-SA 4.0ライセンス](https://projectsprint.org/LICENCE)で提供されるオープンなメソッドです。このメソッドは、**Project Sprint Contributers** と呼ばれる有志のユーザーによって定義 / 改善を繰り返してかたちづくられています。 6 | 7 | ユーザーはいくつかの手段を通じて、自らもContributersの一人としてProject Sprintに主体的に関わることができます。 8 | 9 | 詳しくは[こちら](https://github.com/copilot-jp/project-sprint)をご欄ください。 10 | -------------------------------------------------------------------------------- /practical-guide/README.md: -------------------------------------------------------------------------------- 1 | # Practical Guide 2 | 3 | Project Sprint の効果を実感し理解を深めるためには、プロジェクトの現場での実際の体験を通して納得感を得ることが重要だとわたしたちは考えています。Practical Guide では、実際に定例会議を活用することでプロジェクトを推進する方法や、プロジェクトの具体的な立ち上げ方・進め方などを、できるだけ分かりやすく解説します。 4 | 5 | 一般化され抽象度の高い CODE に比べて、より実践的な Practical Guide はプロジェクトにおける実践知をタイムリーに取り込みやすく、CODE よりも早い速度で姿を変えていきます。そのため、CODE ほど細かくバージョン管理を行わず、CODE の各メジャーバージョンに準拠した Practical Guide として運用しています。 6 | 7 | ## 最新版 8 | * [CODEv4準拠 Practical Guide](CODEv4_based//README.md) 9 | -------------------------------------------------------------------------------- /CODE/v2/.2_ja/tips/2-2.md: -------------------------------------------------------------------------------- 1 | # プロジェクトで作り出されるものにはどのようなものがあるのか（アウトプット/成果物） 2 | 3 | プロジェクトでは様々なものが生み出されますが、そのそれぞれの持つ意味合いや粒度によって名称を区別することは、チームメンバー間のコミュニケーションをスムーズにし、プロジェクトの成功を助けてくれます。 4 | 5 | この記事では、プロジェクトスプリントで用いている「アウトプット」と「成果物」について説明します。 6 | 7 | **アウトプット** 8 | 9 | アウトプットは、チームメンバーが割り当てられた作業（タスク）を完了したことで生まれた**目に見える有形物**のことです。プロジェクトを通じて生み出されるものを示す言葉の中で最小単位のものです。 10 | 11 | **成果物** 12 | 13 | 成果物は、マイルストーン完了の際につくられているべき**アウトプットの集積**を指します。 マイルストーンの「成果」は、この「成果物」と「実現したい状態」によって構成されます。 14 | -------------------------------------------------------------------------------- /CODE/v2/.2_ja/tips/4-2.md: -------------------------------------------------------------------------------- 1 | # ロールシートの利用 2 | 3 | [チームメンバーを知り、ロールを設定する](../tutorial/1-2.md)で記載した通り、ロールとは「チームメンバー個々人の役割」のことです。 ロールとチームメンバーは一対一の関係になるとは限らず、またロールの種類も決まったものはない一方、決まったロールはきちんと明文化して合意する必要があります。 4 | 5 | そのため、「いまのロールの状況」を明文化して参照できる状態にしておくための「ロールシート」を利用することをおすすめします。 6 | 7 | ロールシートには、例えば次のような要素を盛り込みます。 8 | 9 | * ロール名 10 | * ロールが果たす責任(どういう目的でそのロールが必要とされ、何を果たすロールなのか） 11 | * そのロールを担う人 12 | 13 | これらを一つのドキュメントとしてまとめ、常に最新のものに更新しておくことで、いまの各メンバーに対する期待値を把握することや、期待とズレがあった場合の議論が可能になります。 14 | -------------------------------------------------------------------------------- /CODE/v3/.0_ja/essentials.md: -------------------------------------------------------------------------------- 1 | # Essentials 2 | 3 | Project Sprintは、プロジェクトチームがプロジェクトゴールの達成へと進んでいくための、考え方や仕組みを提供します。 4 | 5 | プロジェクトのすべての要素は、プロジェクトチームによって規定されるものです。プロジェクトチームは、以下の原則に従って行動します。 6 | 7 | * プロジェクトチームは、プロジェクトチーム自身の意思を反映させたプロジェクトゴールを設定し、外部環境の変化やプロジェクト内で得られる洞察に応じてアップデートを繰り返しながら、納得感と達成への現実味を持って、漸進的にプロジェクトゴールの達成を目指します。 8 | * プロジェクトチームは、各メンバーが作成物を継続的に出力することを通して、他のメンバーに伝えたいアイデアやテンションを発見し、漸進的にプロジェクトゴールの達成に向かいます。 9 | * プロジェクトチームは、全員参加の定期的・反復的なミーティングで認識を揃え、全員が納得できるプロジェクトゴールやロールを設定し更新しつづけるとともに、アイデアの共同創造と問題の共同解決を行います。 10 | * プロジェクトチームは、各メンバーの責任・役割・期待値を共有します。各メンバーは、己の役割を果たすべく自律的に行動を起こし、信頼と敬意をもって相互に支援を行います。 11 | -------------------------------------------------------------------------------- /CODE/v3/.1_ja/essentials.md: -------------------------------------------------------------------------------- 1 | # Essentials 2 | 3 | Project Sprintは、プロジェクトチームがプロジェクトゴールの達成へと進んでいくための、考え方や仕組みを提供します。 4 | 5 | プロジェクトのすべての要素は、プロジェクトチームによって規定されるものです。プロジェクトチームは、以下の原則に従って行動します。 6 | 7 | * プロジェクトチームは、プロジェクトチーム自身の意思を反映させたプロジェクトゴールを設定し、外部環境の変化やプロジェクト内で得られる洞察に応じてアップデートを繰り返しながら、納得感と達成への現実味を持って、漸進的にプロジェクトゴールの達成を目指します。 8 | * プロジェクトチームは、各メンバーが作成物を継続的に出力することを通して、他のメンバーに伝えたいアイデアやテンションを発見し、漸進的にプロジェクトゴールの達成に向かいます。 9 | * プロジェクトチームは、全員参加の定期的・反復的なミーティングで認識を揃え、全員が納得できるプロジェクトゴールやロールを設定し更新しつづけるとともに、アイデアの共同創造と問題の共同解決を行います。 10 | * プロジェクトチームは、各メンバーの責任・役割・期待値を共有します。各メンバーは、己の役割を果たすべく自律的に行動を起こし、信頼と敬意をもって相互に支援を行います。 11 | -------------------------------------------------------------------------------- /CODE/v3/.2_ja/essentials.md: -------------------------------------------------------------------------------- 1 | # Essentials 2 | 3 | Project Sprintは、プロジェクトチームがプロジェクトゴールの達成へと進んでいくための、考え方や仕組みを提供します。 4 | 5 | プロジェクトのすべての要素は、プロジェクトチームによって規定されるものです。プロジェクトチームは、以下の原則に従って行動します。 6 | 7 | * プロジェクトチームは、プロジェクトチーム自身の意思を反映させたプロジェクトゴールを設定し、外部環境の変化やプロジェクト内で得られる洞察に応じてアップデートを繰り返しながら、納得感と達成への現実味を持って、漸進的にプロジェクトゴールの達成を目指します。 8 | * プロジェクトチームは、各メンバーが作成物を継続的に出力することを通して、他のメンバーに伝えたいアイデアやテンションを発見し、漸進的にプロジェクトゴールの達成に向かいます。 9 | * プロジェクトチームは、全員参加の定期的・反復的なミーティングで認識を揃え、全員が納得できるプロジェクトゴールやロールを設定し更新しつづけるとともに、アイデアの共同創造と問題の共同解決を行います。 10 | * プロジェクトチームは、各メンバーの責任・役割・期待値を共有します。各メンバーは、己の役割を果たすべく自律的に行動を起こし、信頼と敬意をもって相互に支援を行います。 11 | -------------------------------------------------------------------------------- /CODE/v3/.3_ja/essentials.md: -------------------------------------------------------------------------------- 1 | # Essentials 2 | 3 | Project Sprintは、プロジェクトチームがプロジェクトゴールの達成へと進んでいくための、考え方や仕組みを提供します。 4 | 5 | プロジェクトのすべての要素は、プロジェクトチームによって規定されるものです。プロジェクトチームは、以下の原則に従って行動します。 6 | 7 | * プロジェクトチームは、プロジェクトチーム自身の意思を反映させたプロジェクトゴールを設定し、外部環境の変化やプロジェクト内で得られる洞察に応じてアップデートを繰り返しながら、納得感と達成への現実味を持って、漸進的にプロジェクトゴールの達成を目指します。 8 | * プロジェクトチームは、各メンバーが作成物を継続的に出力することを通して、他のメンバーに伝えたいアイデアやテンションを発見し、漸進的にプロジェクトゴールの達成に向かいます。 9 | * プロジェクトチームは、全員参加の定期的・反復的なミーティングで認識を揃え、全員が納得できるプロジェクトゴールやロールを設定し更新しつづけるとともに、アイデアの共同創造と問題の共同解決を行います。 10 | * プロジェクトチームは、各メンバーの責任・役割・期待値を共有します。各メンバーは、己の役割を果たすべく自律的に行動を起こし、信頼と敬意をもって相互に支援を行います。 11 | -------------------------------------------------------------------------------- /CODE/v2/.2_ja/tips/4-1.md: -------------------------------------------------------------------------------- 1 | # チームの定義 2 | 3 | プロジェクトスプリントでは、より良い「チーム」の状態を作ることを大切にしています。\ 4 | 「プロジェクトスプリントの原理」の1つにも「チーミング」を入れていますが、プロジェクトが成功する・より価値を生み出していくためには、プロジェクトの進め方だけではなく、チームのあり方についても考える必要があります。 5 | 6 | プロジェクトスプリントでは、以下をチームの定義（必要な構成要素）として考えています。 7 | 8 | 1. 共通のゴール 9 | 2. 相互依存的なメンバー間による実施 10 | 3. 目的・ゴールそのものを再定義できること（もしくは、再定義するための仕組みがあること） 11 | 12 | チームは、基本的には、共通のゴールに向かって、相互依存的な関係性の中で進めていくものですが、現代のチームの特徴を考える場合に、特に上記3点目の「目的・ゴールそのものを再定義できること」がチームをチームたらしめる上で重要になるものと考えています。つまり、第三者から与えられたゴールを目指すこともチームとして重要な活動ではあるのですが、そもそものゴール自体を定義することにこそチームの存在意義があるのではないか、ということです。 13 | 14 | プロジェクトスプリントのCODEの中でも、目的やゴールの再定義のための仕組みを記載していますので、ご参照いただければと思います。 15 | 16 | * [振り返りを行う](../tutorial/3-1.md) 17 | * [プロジェクトのゴールとマイルストーンを見直す](../tutorial/3-2.md) 18 | -------------------------------------------------------------------------------- /CODE/v2/.2_ja/tips/3-2-2.md: -------------------------------------------------------------------------------- 1 | # アジェンダアイテムに含まれているとよい全要素 2 | 3 | [ミーティングの準備をする](../tutorial/2-1.md)で解説したように、ミーティングのアジェンダアイテムには次の要素が必要です。 4 | 5 | * アジェンダアイテム名 6 | * 進行方法（具体的な議論の進行イメージ） 7 | * 目的や背景（そのアジェンダアイテムを議論したい理由） 8 | * 誰から誰への議論か（誰がそのアジェンダアイテムのオーナーであり、誰と議論したいのか） 9 | * 時間 10 | 11 | これらは、「何について話し合いたいのか」をアジェンダアイテムオーナーが明らかにするために必要な情報ですが、これに加えて「どの程度まで話し合いたいのか」までを明らかにしておくと、議論がより進めやすくなります。 12 | 13 | 具体的には、次の要素を追加で記載するようにします。 14 | 15 | * あるべき姿(アジェンダアイテムを議論した後に目指す状態) 16 | * 結果(議論が終わったときに生まれている明示的なアウトプット） 17 | * 参加者がアジェンダアイテムの完了について納得していることを証明する手段 18 | 19 | これらの要素がそれぞれ事前に明らかになっていればいるほど効率的・効果的な議論ができるようになります。アジェンダアイテムオーナーだけでは記載することが難しかったり、ほかのチームメンバーから見てわかりにくいものがあれば、分かりやすいものにしていくことや、これらの要素が実現できるように議論を整理していくことが、ファシリテーター（アクセラレーター）に求められる役割になります。 20 | -------------------------------------------------------------------------------- /CODE/v3/.2_ja/theories/agenda.md: -------------------------------------------------------------------------------- 1 | # アジェンダとは 2 | 3 | アジェンダとは、個人から出力されたアイデアや問題を、他のメンバーと共有し次の行動を決定するために明文化したものです。ミーティングに提出され議論される個々のアジェンダを、アジェンダアイテムと呼びます。 4 | 5 | ## アジェンダアイテムの目的 6 | 7 | アジェンダアイテムは、議論の目的によって次の三つの種類に分けられます。 8 | 9 | ![アジェンダの種類](../images/agenda.png) 10 | 11 | * 発散：議論を通して幅広い選択肢が出てくる。結論が見えないテーマについて議論し、明確でないまま終了してよい。 12 | * 収束：議論を通していくつか選択肢から一つの選択肢に絞られる。メンバー間での意思決定や合意形成など、最終的に何かしらの結論を出す。 13 | * 共有：情報共有や前提確認など、チームメンバーと認識を合わせる。議論を特に必要としない。 14 | 15 | 個々のアジェンダアイテムがどれに分類されるのかあらかじめ示しておくことで、ミーティングの参加者が「どのような視点で」「どのような発言をするべきか」を理解することができます。例えば、「発散」のアジェンダアイテムであれば自由に意見を発してよく、新しいアイデアを出すことが重要だと分かります。反対に「収束」のアジェンダアイテムであれば、マイルストーン達成のためにどのようなアウトプットをつくっていくべきか、現実的な結論を導くことが必要だと分かります。また「共有」のアジェンダアイテムであれば、疑問点を質問しできるだけ認識を合わせることが重要だと分かります。 16 | -------------------------------------------------------------------------------- /CODE/v3/.3_ja/theories/agenda.md: -------------------------------------------------------------------------------- 1 | # アジェンダとは 2 | 3 | アジェンダとは、個人から出力されたアイデアや問題を、他のメンバーと共有し次の行動を決定するために明文化したものです。ミーティングに提出され議論される個々のアジェンダを、アジェンダアイテムと呼びます。 4 | 5 | ## アジェンダアイテムの目的 6 | 7 | アジェンダアイテムは、議論の目的によって次の三つの種類に分けられます。 8 | 9 | ![アジェンダの種類](../images/agenda.png) 10 | 11 | * 発散：議論を通して幅広い選択肢が出てくる。結論が見えないテーマについて議論し、明確でないまま終了してよい。 12 | * 収束：議論を通していくつか選択肢から一つの選択肢に絞られる。メンバー間での意思決定や合意形成など、最終的に何かしらの結論を出す。 13 | * 共有：情報共有や前提確認など、チームメンバーと認識を合わせる。議論を特に必要としない。 14 | 15 | 個々のアジェンダアイテムがどれに分類されるのかあらかじめ示しておくことで、ミーティングの参加者が「どのような視点で」「どのような発言をするべきか」を理解することができます。例えば、「発散」のアジェンダアイテムであれば自由に意見を発してよく、新しいアイデアを出すことが重要だと分かります。反対に「収束」のアジェンダアイテムであれば、マイルストーン達成のためにどのようなアウトプットをつくっていくべきか、現実的な結論を導くことが必要だと分かります。また「共有」のアジェンダアイテムであれば、疑問点を質問しできるだけ認識を合わせることが重要だと分かります。 16 | -------------------------------------------------------------------------------- /CODE/v3/.0_ja/tutorial/section4-4.md: -------------------------------------------------------------------------------- 1 | # Project Sprintの成功指標 2 | 3 | Project Sprintは、チームが 4 | 5 | * 個人の活動における理想の状態 6 | * チームとしての活動における理想の状態 7 | 8 | を目指しながらプロジェクトゴールに向かって進んでいくのを助けるために、ものごとの捉え方・考え方や、最適化を促進するための仕組みを提供しています。 9 | 10 | したがって、プロジェクトスプリントが成功しているかどうかは、個人の活動とチームとしての活動において理想の状態が実現しているか、という観点で評価することができます。 11 | ここで、いずれの成功についても、絶対的に到達すべき状態はないということに注意しなければなりません。プロジェクトゴールは変化しうるものであり、また何をもって理想的なチームとするかはプロジェクトの規模や時間軸などに依存します。 12 | 13 | 一方、Project Sprintが正しく導入・運営されていれば、それは理想の状態が実現されているということを意味します。そのため、Project Sprint自体の活発さをもって成功指標とみなすことができます。 14 | 15 | したがって、成功指標は次の3つと言えます。 16 | 17 | * タスクがリストアップされ、遂行されているか 18 | * タスクを遂行する中で発見された問題点やテンションが、ミーティングにおけるアジェンダアイテムとしてリストアップされ、議論・意思決定されているか 19 | * ミーティングにおける議論・意思決定の結果が、次にやるべきこととしてタスクに落とし込まれているか 20 | -------------------------------------------------------------------------------- /CODE/v3/.1_ja/tutorial/section4-4.md: -------------------------------------------------------------------------------- 1 | # Project Sprintの成功指標 2 | 3 | Project Sprintは、チームが 4 | 5 | * プログレスにおける理想の状態 6 | * チーミングにおける理想の状態 7 | 8 | を目指しながらプロジェクトゴールに向かって進んでいくのを助けるために、ものごとの捉え方・考え方や、最適化を促進するための仕組みを提供しています。 9 | 10 | したがって、Project Sprintが成功しているかどうかは、プログレスとチーミングにおいて理想の状態が実現しているか、という観点で評価することができます。 11 | 12 | ここで、いずれの成功についても、絶対的に到達すべき状態はないということに注意しなければなりません。プロジェクトゴールは変化しうるものであり、また何をもって理想的なチームとするかはプロジェクトの規模や時間軸などに依存します。 13 | 14 | 一方、Project Sprintが正しく導入・運営されていれば、それは理想の状態が実現されているということを意味します。そのため、Project Sprint自体の活発さをもって成功指標とみなすことができます。 15 | 16 | したがって、成功指標は次の3つと言えます。 17 | 18 | * タスクがリストアップされ、遂行されているか 19 | * タスクを遂行する中で発見された問題点やテンションが、ミーティングにおけるアジェンダアイテムとしてリストアップされ、議論・意思決定されているか 20 | * ミーティングにおける議論・意思決定の結果が、次にやるべきこととしてタスクに落とし込まれているか 21 | -------------------------------------------------------------------------------- /CODE/v3/.2_ja/theories/success_metrics.md: -------------------------------------------------------------------------------- 1 | # Project Sprintの成功指標 2 | 3 | Project Sprintは、チームが 4 | 5 | * プログレスにおける理想の状態 6 | * チーミングにおける理想の状態 7 | 8 | を目指しながらプロジェクトゴールに向かって進んでいくのを助けるために、ものごとの捉え方・考え方や、最適化を促進するための仕組みを提供しています。 9 | 10 | したがって、Project Sprintが成功しているかどうかは、プログレスとチーミングにおいて理想の状態が実現しているか、という観点で評価することができます。 11 | 12 | ここで、いずれの成功についても、絶対的に到達すべき状態はないということに注意しなければなりません。プロジェクトゴールは変化しうるものであり、また何をもって理想的なチームとするかはプロジェクトの規模や時間軸などに依存します。 13 | 14 | 一方、Project Sprintが正しく導入・運営されていれば、それは理想の状態が実現されているということを意味します。そのため、Project Sprint自体の活発さをもって成功指標とみなすことができます。 15 | 16 | したがって、成功指標は次の3つと言えます。 17 | 18 | * タスクがリストアップされ、遂行されているか 19 | * タスクを遂行する中で発見された問題点やテンションが、ミーティングにおけるアジェンダアイテムとしてリストアップされ、議論・意思決定されているか 20 | * ミーティングにおける議論・意思決定の結果が、次にやるべきこととしてタスクに落とし込まれているか 21 | -------------------------------------------------------------------------------- /CODE/v3/.3_ja/theories/success_metrics.md: -------------------------------------------------------------------------------- 1 | # Project Sprintの成功指標 2 | 3 | Project Sprintは、チームが 4 | 5 | * プログレスにおける理想の状態 6 | * チーミングにおける理想の状態 7 | 8 | を目指しながらプロジェクトゴールに向かって進んでいくのを助けるために、ものごとの捉え方・考え方や、最適化を促進するための仕組みを提供しています。 9 | 10 | したがって、Project Sprintが成功しているかどうかは、プログレスとチーミングにおいて理想の状態が実現しているか、という観点で評価することができます。 11 | 12 | ここで、いずれの成功についても、絶対的に到達すべき状態はないということに注意しなければなりません。プロジェクトゴールは変化しうるものであり、また何をもって理想的なチームとするかはプロジェクトの規模や時間軸などに依存します。 13 | 14 | 一方、Project Sprintが正しく導入・運営されていれば、それは理想の状態が実現されているということを意味します。そのため、Project Sprint自体の活発さをもって成功指標とみなすことができます。 15 | 16 | したがって、成功指標は次の3つと言えます。 17 | 18 | * タスクがリストアップされ、遂行されているか 19 | * タスクを遂行する中で発見された問題点やテンションが、ミーティングにおけるアジェンダアイテムとしてリストアップされ、議論・意思決定されているか 20 | * ミーティングにおける議論・意思決定の結果が、次にやるべきこととしてタスクに落とし込まれているか 21 | -------------------------------------------------------------------------------- /CODE/v3/.2_ja/practices/agenda.md: -------------------------------------------------------------------------------- 1 | # アジェンダアイテムの要素 2 | 3 | 毎回のミーティングが始まる前に、各チームメンバーはあらかじめアジェンダアイテムを提出します。アジェンダアイテムには、少なくとも次のような内容が含まれている必要があります。 4 | 5 | * アジェンダアイテム名（何を議論したいか端的に記載する） 6 | * 進行方法（具体的な議論の進行イメージ） 7 | * 目的や背景（そのアジェンダアイテムを議論したい理由） 8 | * 誰から誰への議論か（誰がそのアジェンダアイテムのオーナーであり、誰と議論したいのか） 9 | * 時間（議論完了までの所要時間） 10 | 11 | これらは、「何について話し合いたいのか」をアジェンダアイテムオーナーが明らかにするために必要な情報ですが、これに加えて「どの程度まで話し合いたいのか」までを明らかにしておくと、議論がより進めやすくなります。 12 | 13 | 具体的には、次の要素を追加で記載するようにします。 14 | 15 | * あるべき姿(アジェンダアイテムを議論した後に目指す状態) 16 | * 結果(議論が終わったときに生まれている明示的なアウトプット） 17 | * 参加者がアジェンダアイテムの完了について納得していることを証明する手段 18 | 19 | これらの要素がそれぞれ事前に明らかになっていればいるほど効率的・効果的な議論ができるようになります。アジェンダアイテムオーナーだけでは記載することが難しいものを補足したり、他のチームメンバーから見て分かりにくいものを分かりやすくしたりして、これらの要素が記載できるように議論を整理していくことが、ファシリテーターに求められる役割です。 20 | -------------------------------------------------------------------------------- /CODE/v3/.3_ja/practices/agenda.md: -------------------------------------------------------------------------------- 1 | # アジェンダアイテムの要素 2 | 3 | 毎回のミーティングが始まる前に、各チームメンバーはあらかじめアジェンダアイテムを提出します。アジェンダアイテムには、少なくとも次のような内容が含まれている必要があります。 4 | 5 | * アジェンダアイテム名（何を議論したいか端的に記載する） 6 | * 進行方法（具体的な議論の進行イメージ） 7 | * 目的や背景（そのアジェンダアイテムを議論したい理由） 8 | * 誰から誰への議論か（誰がそのアジェンダアイテムのオーナーであり、誰と議論したいのか） 9 | * 時間（議論完了までの所要時間） 10 | 11 | これらは、「何について話し合いたいのか」をアジェンダアイテムオーナーが明らかにするために必要な情報ですが、これに加えて「どの程度まで話し合いたいのか」までを明らかにしておくと、議論がより進めやすくなります。 12 | 13 | 具体的には、次の要素を追加で記載するようにします。 14 | 15 | * あるべき姿(アジェンダアイテムを議論した後に目指す状態) 16 | * 結果(議論が終わったときに生まれている明示的なアウトプット） 17 | * 参加者がアジェンダアイテムの完了について納得していることを証明する手段 18 | 19 | これらの要素がそれぞれ事前に明らかになっていればいるほど効率的・効果的な議論ができるようになります。アジェンダアイテムオーナーだけでは記載することが難しいものを補足したり、他のチームメンバーから見て分かりにくいものを分かりやすくしたりして、これらの要素が記載できるように議論を整理していくことが、ファシリテーターに求められる役割です。 20 | -------------------------------------------------------------------------------- /CODE/v4/.2_ja/README.md: -------------------------------------------------------------------------------- 1 | # v4.2 2 | 3 | ![文書構造](images/illust_documents.png) 4 | 5 | ## コンテンツ 6 | 7 | * [**Introduction**](introduction.md) 8 | はじめにお読みいただきたい文書です。Project Sprint からの提案の概要を紹介した上で、その基盤となっている価値観を簡単に紹介します。 9 | * [**Definitions**](definitions.md) 10 | Project Sprint を理解するための前提を示す文書です。Project Sprint におけるプロジェクト観を説明し、その他の用語を定義します。 11 | * [**Framework**](framework.md) 12 | Project Sprint の核となる概念や価値観を示す文書です。Project Sprint におけるプロジェクト推進の構造と、そのための価値観や推奨される振る舞いが記述されています。 13 | 14 | ## 関連情報 15 | 16 | * [**Practical Guide**](https://miro.com/app/board/uXjVMX-zl6s=/) 17 | Project Sprint のフレームワークを実際のプロジェクトに導入し使いこなすためのガイドブックです。諸概念を図解し、分かりやすく説明しています。 18 | 19 | ★Project Sprint の内容に疑問やご意見を持たれた方は、[こちら](https://github.com/copilot-jp/project-sprint/discussions)のGitHub Discussionへお寄せください。 20 | -------------------------------------------------------------------------------- /CODE/v2/.2_ja/tips/4-5.md: -------------------------------------------------------------------------------- 1 | # テンショントリアージの方法 2 | 3 | [ミーティングを開催する](../tutorial/2-2.md)で解説したように、ミーティング開始時にはテンショントリアージを実施します。これによって、メンバー一人一人が思う「こうしたらもっとより良くなるのに」という現状とよりよい状態の間のギャップ、ちょっとしたアイデア・気になること・不安などを共有し、解決のためのアクションにつなげることができるようになります。 4 | 5 | テンショントリアージは、例えば次のような手順で実施しますが、一例にすぎません。上記の目的をより効率的・効果的に達成するために、チームによって最適な方法にアレンジしてみてください。 6 | 7 | 1. チームメンバーがテンションをあげる 8 | 2. テンショントリアージのアジェンダアイテムオーナーがテンションを一つ読み上げ「何が必要ですか？」とテンションをあげた人に問いかける 9 | 3. テンションをあげた人は、次のいずれかを選択し、そのあと、自分が必要としていることを回答する。 10 | 11 | * 他メンバーへのタスクのリクエスト 12 | * 他メンバーからの情報やヘルプ提供のリクエスト 13 | * ロールの調整・変更・追加に関するリクエスト 14 | * 単なる情報提供や感想の共有 15 | 16 | 1. テンショントリアージのアジェンダアイテムオーナーは、次のいずれかを選択してテンションをあげた人に提案する 17 | * その場で解決する 18 | * タスク化する 19 | * アジェンダアイテム化する 20 | 2. テンションをあげた人がこれで必要なことが得られれば、終了。得られなければ、続けて議論する。(3と4を詳しく繰り返す) 21 | 3. 時間の許す限り、他のテンションについても2\~5の手順を繰り返す 22 | -------------------------------------------------------------------------------- /CODE/v3/.0_ja/tutorial/section4-1-3.md: -------------------------------------------------------------------------------- 1 | # 未来の展望と仮説：ロールセッション 2 | 3 | ## **ロールセッションとは** 4 | 5 | プロジェクトの各フェーズの開始時には、次のマイルストーンまでにチームがどのように進んでいくかを擦り合わせ、個人がやるべきこと、他のメンバーに期待することについて認識を揃える必要があります。まず、改めて今回のマイルストーンの内容とプロジェクトゴールを確認します。その後、各メンバーがこのマイルストーンにおいてどのようなタスク・ロールを担うのかの認識を合わせます。 6 | 7 | ロールセッションは、この各メンバーの役割と期待値の擦り合わせのために行われます。プロジェクトチーム全員が自分の役割の範囲でリーダーシップを発揮できるように、メンバーそれぞれのやるべきこと、苦手なこと、期待されることなど、内的な自己認識と外的な期待値を明文化して共有し、相互に役割を擦り合わせます。 8 | 9 | ## **具体的な手順** 10 | 11 | テンショントリアージは、例えば次のような手順で実施しますが、これはあくまで一例です。上記の目的をより効率的・効果的に達成するために、ご自身のチームにとって最適な方法にアレンジしてみてください。 12 | 13 | 1. 各メンバーが自分のやるべきことを付箋に書き出し共有する 14 | 2. 他のメンバーにヘルプしてほしいこと、他のメンバーへの期待値を付箋に書き出し共有する\ 15 | （アサインできる対象がわからなかったり現時点ではいなかったりしても問題ない） 16 | 3. 未アサインのヘルプ内容や期待値につき、メンバー相互に議論してアサイン先を決める 17 | 4. 改めて自分のやるべきことを精査し、各々承認し、議論して深める 18 | 5. これまでの議論を踏まえて、各メンバーが自分の役割を更新し共有する 19 | -------------------------------------------------------------------------------- /CODE/v3/.1_ja/tutorial/section4-1-3.md: -------------------------------------------------------------------------------- 1 | # 未来の展望と仮説：ロールセッション 2 | 3 | ## **ロールセッションとは** 4 | 5 | プロジェクトの各ステップの開始時には、次のマイルストーンまでにチームがどのように進んでいくかを擦り合わせ、個人がやるべきこと、他のメンバーに期待することについて認識を揃える必要があります。まず、改めて今回のマイルストーンの内容とプロジェクトゴールを確認します。その後、各メンバーがこのマイルストーンにおいてどのようなタスク・ロールを担うのかの認識を合わせます。 6 | 7 | ロールセッションは、この各メンバーの役割と期待値の擦り合わせのために行われます。プロジェクトチーム全員が自分の役割の範囲でリーダーシップを発揮できるように、メンバーそれぞれのやるべきこと、苦手なこと、期待されることなど、内的な自己認識と外的な期待値を明文化して共有し、相互に役割を擦り合わせます。 8 | 9 | ## **具体的な手順** 10 | 11 | テンショントリアージは、例えば次のような手順で実施しますが、これはあくまで一例です。上記の目的をより効率的・効果的に達成するために、ご自身のチームにとって最適な方法にアレンジしてみてください。 12 | 13 | 1. 各メンバーが自分のやるべきことを付箋に書き出し共有する 14 | 2. 他のメンバーにヘルプしてほしいこと、他のメンバーへの期待値を付箋に書き出し共有する\ 15 | （アサインできる対象がわからなかったり現時点ではいなかったりしても問題ない） 16 | 3. 未アサインのヘルプ内容や期待値につき、メンバー相互に議論してアサイン先を決める 17 | 4. 改めて自分のやるべきことを精査し、各々承認し、議論して深める 18 | 5. これまでの議論を踏まえて、各メンバーが自分の役割を更新し共有する 19 | -------------------------------------------------------------------------------- /CODE/v3/.2_ja/practices/role_session.md: -------------------------------------------------------------------------------- 1 | # 未来の展望と仮説：ロールセッション 2 | 3 | ## **ロールセッションとは** 4 | 5 | プロジェクトの各ステップの開始時には、次のマイルストーンまでにチームがどのように進んでいくかを擦り合わせ、個人がやるべきこと、他のメンバーに期待することについて認識を揃える必要があります。まず、改めて今回のマイルストーンの内容とプロジェクトゴールを確認します。その後、各メンバーがこのマイルストーンにおいてどのようなタスク・ロールを担うのかの認識を合わせます。 6 | 7 | ロールセッションは、この各メンバーの役割と期待値の擦り合わせのために行われます。プロジェクトチーム全員が自分の役割の範囲でリーダーシップを発揮できるように、メンバーそれぞれのやるべきこと、苦手なこと、期待されることなど、内的な自己認識と外的な期待値を明文化して共有し、相互に役割を擦り合わせます。 8 | 9 | ## **具体的な手順** 10 | 11 | ロールセッションは、例えば次のような手順で実施しますが、これはあくまで一例です。上記の目的をより効率的・効果的に達成するために、ご自身のチームにとって最適な方法にアレンジしてみてください。 12 | 13 | 1. 各メンバーが自分のやるべきことを付箋に書き出し共有する 14 | 2. 他のメンバーにヘルプしてほしいこと、他のメンバーへの期待値を付箋に書き出し共有する\ 15 | （アサインできる対象がわからなかったり現時点ではいなかったりしても問題ない） 16 | 3. 未アサインのヘルプ内容や期待値につき、メンバー相互に議論してアサイン先を決める 17 | 4. 改めて自分のやるべきことを精査し、各々承認し、議論して深める 18 | 5. これまでの議論を踏まえて、各メンバーが自分の役割を更新し共有する 19 | -------------------------------------------------------------------------------- /CODE/v3/.3_ja/practices/role_session.md: -------------------------------------------------------------------------------- 1 | # 未来の展望と仮説：ロールセッション 2 | 3 | ## **ロールセッションとは** 4 | 5 | プロジェクトの各ステップの開始時には、次のマイルストーンまでにチームがどのように進んでいくかを擦り合わせ、個人がやるべきこと、他のメンバーに期待することについて認識を揃える必要があります。まず、改めて今回のマイルストーンの内容とプロジェクトゴールを確認します。その後、各メンバーがこのマイルストーンにおいてどのようなタスク・ロールを担うのかの認識を合わせます。 6 | 7 | ロールセッションは、この各メンバーの役割と期待値の擦り合わせのために行われます。プロジェクトチーム全員が自分の役割の範囲でリーダーシップを発揮できるように、メンバーそれぞれのやるべきこと、苦手なこと、期待されることなど、内的な自己認識と外的な期待値を明文化して共有し、相互に役割を擦り合わせます。 8 | 9 | ## **具体的な手順** 10 | 11 | ロールセッションは、例えば次のような手順で実施しますが、これはあくまで一例です。上記の目的をより効率的・効果的に達成するために、ご自身のチームにとって最適な方法にアレンジしてみてください。 12 | 13 | 1. 各メンバーが自分のやるべきことを付箋に書き出し共有する 14 | 2. 他のメンバーにヘルプしてほしいこと、他のメンバーへの期待値を付箋に書き出し共有する\ 15 | （アサインできる対象がわからなかったり現時点ではいなかったりしても問題ない） 16 | 3. 未アサインのヘルプ内容や期待値につき、メンバー相互に議論してアサイン先を決める 17 | 4. 改めて自分のやるべきことを精査し、各々承認し、議論して深める 18 | 5. これまでの議論を踏まえて、各メンバーが自分の役割を更新し共有する 19 | -------------------------------------------------------------------------------- /CODE/v3/.2_ja/theories/rolls.md: -------------------------------------------------------------------------------- 1 | # 期待値とロール 2 | 3 | Project Sprintでは、定例ミーティングでの期待値の共有とロールの設定によって、理想的なチームの形成を目指します。 4 | 5 | ## 期待値の共有 6 | 7 | 自律的なチームであるためには、チームメンバー各々の責任・役割が共有されて認識が揃っており、メンバー相互の期待値に齟齬がないことが重要です。言い換えると、あるチームメンバーが「あの人はこれをやってくれるだろう」と考えたとき、そのチームメンバーも「これは私がやるべきことだ」と考えている状態(**期待値の一致**)です。 8 | 9 | また、メンバー個人の視点では、上記が実現されることで、チームから自分へ期待されていることや自分から他のメンバーへ期待してよいことが明確になります。チームにおける自分の責任・役割や他のメンバーからの期待に納得感が持てれば、自分がチームのために何をすべきかを自律的に判断し実際に行動できるようになります。自分に担うことができる役割であれば何であれ必要に応じていつでも担おうとするマインドセット (**自発的な役割の引き受け**)が生まれるのです。 10 | 11 | ## ロールの設定 12 | 13 | Project Sprintでは、チームメンバー個々人の役割のことをロールと呼びます。ロールとチームメンバーは必ずしも一対一の関係である必要はありません。つまり、一人の人が複数のロールを担うこともありますし、またあるロールを複数の人が担うこともできます。 14 | 15 | また、設定するロールの個数には制限がありませんし、「必ず設定すべきロール」というものもありません。ロールの定義に関しても、必要なのはチームメンバーで合意することのみです。プロジェクトの性質に応じて、必要な役割分担をチームメンバーで議論し、ロールとして明文化しましょう。 16 | -------------------------------------------------------------------------------- /CODE/v3/.3_ja/theories/rolls.md: -------------------------------------------------------------------------------- 1 | # 期待値とロール 2 | 3 | Project Sprintでは、定例ミーティングでの期待値の共有とロールの設定によって、理想的なチームの形成を目指します。 4 | 5 | ## 期待値の共有 6 | 7 | 自律的なチームであるためには、チームメンバー各々の責任・役割が共有されて認識が揃っており、メンバー相互の期待値に齟齬がないことが重要です。言い換えると、あるチームメンバーが「あの人はこれをやってくれるだろう」と考えたとき、そのチームメンバーも「これは私がやるべきことだ」と考えている状態(**期待値の一致**)です。 8 | 9 | また、メンバー個人の視点では、上記が実現されることで、チームから自分へ期待されていることや自分から他のメンバーへ期待してよいことが明確になります。チームにおける自分の責任・役割や他のメンバーからの期待に納得感が持てれば、自分がチームのために何をすべきかを自律的に判断し実際に行動できるようになります。自分に担うことができる役割であれば何であれ必要に応じていつでも担おうとするマインドセット (**自発的な役割の引き受け**)が生まれるのです。 10 | 11 | ## ロールの設定 12 | 13 | Project Sprintでは、チームメンバー個々人の役割のことをロールと呼びます。ロールとチームメンバーは必ずしも一対一の関係である必要はありません。つまり、一人の人が複数のロールを担うこともありますし、またあるロールを複数の人が担うこともできます。 14 | 15 | また、設定するロールの個数には制限がありませんし、「必ず設定すべきロール」というものもありません。ロールの定義に関しても、必要なのはチームメンバーで合意することのみです。プロジェクトの性質に応じて、必要な役割分担をチームメンバーで議論し、ロールとして明文化しましょう。 16 | -------------------------------------------------------------------------------- /CODE/v4/.3_ja/README.md: -------------------------------------------------------------------------------- 1 | # v4.3 2 | 3 | ![](images/documents.png) 4 | 5 | ## 文書構成 6 | 7 | * [**Introduction**](introduction.md) 8 | はじめにお読みいただきたい文書です。Project Sprint からの提案の概要を紹介した上で、その基盤となっている価値観を簡単に紹介します。 9 | * [**Definitions**](definitions.md) 10 | Project Sprint を理解するための前提を示す文書です。Project Sprint におけるプロジェクト観を説明し、その他の用語を定義します。 11 | * [**Framework**](framework.md) 12 | Project Sprint の核となる概念や価値観を示す文書です。Project Sprint におけるプロジェクト推進の構造と、そのための価値観や推奨される振る舞いが記述されています。 13 | 14 | ## その他のコンテンツ 15 | 16 | * [**Practical Guide**](../../../practical-guide/CODEv4_based/README.md) 17 | Project Sprint のフレームワークを実際のプロジェクトに導入し使いこなすためのガイドブックです。Project sprint の原理をビジュアル化して分かりやすく解説した Miro や、追加で理解しておくとよいドキュメント群が含まれます。 18 | 19 | ★Project Sprint の内容に疑問やご意見を持たれた方は、[こちら](https://github.com/copilot-jp/project-sprint/discussions)のGitHub Discussionへお寄せください。 20 | -------------------------------------------------------------------------------- /CODE/v3/.2_ja/practices/rolls.md: -------------------------------------------------------------------------------- 1 | # チームメンバーの理解とロールシートの利用 2 | 3 | ## チームメンバーの基本情報 4 | 5 | より良いチームを目指す前提となるのが、チームメンバーに関する理解です。例えば、プロジェクトに関わるメンバーに次のことを確認しておきましょう。 6 | 7 | * あなたの名前はなんですか？普段はどのような組織や会社に所属している人ですか？ 8 | * あなたはどのような人ですか？例えばスキルセットはどのようなものがありますか？これまでにどのような仕事にかかわってきましたか？ 9 | * あなたがこのプロジェクトに対して貢献を期待されていることはなんですか？ 10 | * あなたはプロジェクトに対する専任メンバーですか、兼任メンバーですか？いずれにせよ、あなたがこのプロジェクトに割ける時間はどのくらいですか？ 11 | 12 | こうしたことをプロジェクトの最初に知っておくことは、ロールの設定における助けになります。 13 | 14 | ## ロールシートの利用 15 | 16 | ロールとチームメンバーは一対一の関係になるとは限らず、またロールの種類も決まったものはない一方、決まったロールはきちんと明文化して合意する必要があります。 17 | 18 | そのため、「いまのロールの状況」を明文化して参照できる状態にしておくための「ロールシート」を利用することをおすすめします。 19 | 20 | ロールシートには、例えば次のような要素を盛り込みます。 21 | 22 | * ロール名 23 | * ロールが果たす責任(どういう目的でそのロールが必要とされ、何を果たすロールなのか） 24 | * そのロールを担う人 25 | 26 | これらを一つのドキュメントとしてまとめ、常に最新のものに更新しておくことで、いまの各メンバーに対する期待値を把握することや、期待とズレがあった場合の議論が可能になります。 27 | -------------------------------------------------------------------------------- /CODE/v3/.3_ja/practices/rolls.md: -------------------------------------------------------------------------------- 1 | # チームメンバーの理解とロールシートの利用 2 | 3 | ## チームメンバーの基本情報 4 | 5 | より良いチームを目指す前提となるのが、チームメンバーに関する理解です。例えば、プロジェクトに関わるメンバーに次のことを確認しておきましょう。 6 | 7 | * あなたの名前はなんですか？普段はどのような組織や会社に所属している人ですか？ 8 | * あなたはどのような人ですか？例えばスキルセットはどのようなものがありますか？これまでにどのような仕事にかかわってきましたか？ 9 | * あなたがこのプロジェクトに対して貢献を期待されていることはなんですか？ 10 | * あなたはプロジェクトに対する専任メンバーですか、兼任メンバーですか？いずれにせよ、あなたがこのプロジェクトに割ける時間はどのくらいですか？ 11 | 12 | こうしたことをプロジェクトの最初に知っておくことは、ロールの設定における助けになります。 13 | 14 | ## ロールシートの利用 15 | 16 | ロールとチームメンバーは一対一の関係になるとは限らず、またロールの種類も決まったものはない一方、決まったロールはきちんと明文化して合意する必要があります。 17 | 18 | そのため、「いまのロールの状況」を明文化して参照できる状態にしておくための「ロールシート」を利用することをおすすめします。 19 | 20 | ロールシートには、例えば次のような要素を盛り込みます。 21 | 22 | * ロール名 23 | * ロールが果たす責任(どういう目的でそのロールが必要とされ、何を果たすロールなのか） 24 | * そのロールを担う人 25 | 26 | これらを一つのドキュメントとしてまとめ、常に最新のものに更新しておくことで、いまの各メンバーに対する期待値を把握することや、期待とズレがあった場合の議論が可能になります。 27 | -------------------------------------------------------------------------------- /CODE/v2/.2_ja/tips/README.md: -------------------------------------------------------------------------------- 1 | # Tips 2 | 3 | このドキュメント群では、プロジェクトスプリントにまつわる詳細な説明・深掘りした説明が記載されています。 4 | 5 | #### 目次 6 | 7 | ### **プロジェクト環境** 8 | 9 | 1. [プロジェクトの環境整備](1-1.md) 10 | 2. [プロジェクトの時間軸を整理するための便利な考え方（トラック/フェーズ/イベント)](1-2.md) 11 | 3. [チームが納得できて作業効率のよいタスクの設定方法](1-3.md) 12 | 4. [スタンドアップの導入](1-4.md) 13 | 5. [実務で使いやすいロールの設定](1-5.md) 14 | 6. [ロールの分類と性質](1-6.md) 15 | 16 | ### **プログレスドメイン** 17 | 18 | 1. [マイルストーンマップの利用](2-1.md) 19 | 2. [プロジェクトで作り出されるものにはどのようなものがあるのか（アウトプット/成果物）](2-2.md) 20 | 21 | ### **プロセスドメイン** 22 | 23 | 1. [ミーティングを定例開催にする理由](3-1.md) 24 | 25 | #### **ミーティング** 26 | 27 | 1. [ミーティング環境についてのノウハウ](3-2-1.md) 28 | 2. [アジェンダに含まれているとよい全要素](3-2-2.md) 29 | 3. [アジェンダの目的](3-2-3.md) 30 | 31 | ### **チーミングドメイン** 32 | 33 | 1. [チームの定義](4-1.md) 34 | 2. [ロールシートの利用](4-2.md) 35 | 3. [継続的改善アプローチ](4-3.md) 36 | 4. [代表的な振り返りの手法](4-4.md) 37 | 5. [テンショントリアージの方法](4-5.md) 38 | -------------------------------------------------------------------------------- /CODE/v2/.0_en/tips/tips3.md: -------------------------------------------------------------------------------- 1 | # Tips3: What Are Some of the Things That Are Produced in a Project（outputs/deliverables） 2 | 3 | Many things are produced in a project, and distinguishing the names according to the meaning and granularity of each of them can facilitate communication among team members and help the project succeed. 4 | 5 | In this article, it will explain "outputs" and "deliverables" as used in Project Sprint. 6 | 7 | #### Outputs 8 | Outputs are tangible, **tangible things** that are produced as a result of team members completing their assigned work (tasks). It is the smallest unit in the term that describes what is produced through a project. 9 | 10 | 11 | #### Deliverables 12 | A deliverable is **a collection of outputs** that should have been produced at the completion of a milestone. Milestone "outcomes" are composed of "deliverables" and "desired state" 13 | -------------------------------------------------------------------------------- /CODE/v3/.3_ja/theories/restrictions.md: -------------------------------------------------------------------------------- 1 | # 制約・イベント 2 | 3 | プロジェクトの外部環境にあって、プロジェクトに影響を与えるためプロジェクトメンバーが意識しなければならないものを、**制約**と呼びます。特に、マイルストーンの設定の前提となり、ときにプロジェクトゴールの設定にも影響を与えるものを**イベント**と呼びます。なお、プロジェクトの内部にあってマイルストーンやプロジェクトゴールの変動をもたらすものは、プロジェクトの一部として捉え、イベントとは呼びません。 4 | 5 | 制約は、社内の稟議スケジュールや予算など、所与のものであることが多いですが、プロジェクトを取り巻くさまざまな制約のうち、どれを実際にプロジェクトに影響を与えるイベントと捉えてマイルストーンやプロジェクトゴールの設定の前提とするかについては、プロジェクトチームで判断しなくてはならないこともあります。この場合にも、プロジェクトゴールやマイルストーンの決定時と同様に、プロジェクトチームとして認識を揃えた上で納得感のある意志決定をすることが大切です。 6 | 7 | イベントの典型的な例は、プロジェクトの外で日々行われている、組織の定常業務です。具体的には取締役会などがこれにあたります。これ自体がプロジェクトの作成物を生み出すわけではありませんが、プロジェクトに関する何らかの報告や決裁がなされるため、こうしたイベントに合わせてマイルストーンを設定する必要があることがあります。また、こうしたイベントからフィードバックされた情報がプロジェクトの前提条件を変え、マイルストーンや、ときにはプロジェクトゴールそのものを変える必要が生じることもあります。 8 | 9 | 単発のものや定期的なものだけでなく、「商戦期」のような期間をもったものも、イベントとして認識します。それに合わせてプロジェクトのマイルストーンを設定したり、その結果を受けてマイルストーンやゴールを調整したりする必要があるという点は、特定の日付であっても期間であっても変わらないからです。 10 | -------------------------------------------------------------------------------- /CODE/v2/.2_ja/tips/3-2-3.md: -------------------------------------------------------------------------------- 1 | # アジェンダの目的 2 | 3 | [Project Sprint 101](../tutorial/project-sprint-101.md)で述べたように、プロジェクトスプリントにおけるアジェンダとは「プロジェクトにおけるチームメンバーの活動を、他のメンバーと共有・認識してもらうために明文化されたもの」の集合のことを指しています。そして、具体的なアジェンダアイテムの作成方法は、[ミーティングの準備をする](../tutorial/2-1.md)や[アジェンダアイテムに含まれているとよい全要素](3-2-2.md)で説明しました。 4 | 5 | この記事ではアジェンダをさらに深く理解するために、アジェンダアイテムの目的について解説します。 6 | 7 | アジェンダアイテムは、議論の目的によって次の三つの種類に分けられます。 8 | 9 | ![アジェンダの種類](../images/agenda.png) 10 | 11 | * 発散：議論を通して幅広い選択肢が出てくる。結論が見えないテーマについて議論し、明確でないまま終了してよい。 12 | * 収束：議論を通していくつか選択肢から一つの選択肢に絞られる。メンバー間での意思決定や合意形成など、最終的に何かしらの結論を出す。 13 | * 共有：情報共有や前提確認など、チームメンバーと認識を合わせる。議論を特に必要としない。 14 | 15 | 個々のアジェンダアイテムがどれに分類されるのかあらかじめ示しておくことで、ミーティングの参加者が「どのような視点で」「どのような発言をするべきか」を理解することができます。例えば、「発散」のアジェンダアイテムであれば自由に意見を発してよく、新しいアイデアを出すことが重要だと分かります。反対に「収束」のアジェンダアイテムであれば、マイルストーン達成のためにどのようなアウトプットをつくっていくべきか、現実的な結論を導くことが必要だとわかります。さらに「共有」のアジェンダアイテムであれば、疑問点を質問しできるだけ認識を合わせることが重要だと分かります。 16 | -------------------------------------------------------------------------------- /practical-guide/CODEv4_based/README.md: -------------------------------------------------------------------------------- 1 | # Practical Guide (CODEv4準拠) 2 | 3 | Project Sprint の効果を実感し理解を深めるためには、プロジェクトの現場での実際の体験を通して納得感を得ることが重要だとわたしたちは考えています。Practical Guide では、実際に定例会議を活用することでプロジェクトを推進する方法や、プロジェクトの具体的な立ち上げ方・進め方などを、できるだけ分かりやすく解説します。 4 | 5 | ## [**ビジュアル版・プラクティカルガイド**](https://miro.com/app/board/uXjVMX-zl6s=/) (Miro) 6 | 7 | Project Sprint の原理を、スライドをベースにビジュアル化して分かりやすく解説しています。プロジェクトの具体的な立ち上げ方・進め方を説明することで、Project Sprint のフレームワークに沿ったプロジェクト推進をサポートします。 8 | 9 | ## ドキュメント版・プラクティカルガイド 10 | 11 | Minimum Guide では、Project Sprint を実際に体験するために必要な最小限の具体的な行動を記載しています。 12 | - [Project Sprint Minimum Guide](minimum_guide.md) 13 | 14 | 以下はFramework の記述を踏まえ、追加で理解しておくとよい概念や実践の際の考え方を説明したドキュメント群です。 15 | 16 | - [ジョブとアクション](job_and_action.md) 17 | 18 | 19 | ## Project Sprint に基づいて設計されたサービス 20 | 21 | [**SuperGoodMeetings**](https://supergoodmeetings.com/) 22 | 23 | 定例会議を最適な形で実施することで自律的なプロジェクト推進をサポートするクラウドサービスです。 24 | -------------------------------------------------------------------------------- /CODE/v3/.2_ja/practices/meeting_rolls.md: -------------------------------------------------------------------------------- 1 | # ミーティングロールの確認 2 | 3 | ミーティングを効率的・効果的に運営するために必要な役割（ミーティングロール）を、個々人に割り当てましょう。 4 | 5 | 具体的には、次のようなロールの割り当てが必要です。 6 | 7 | * ファシリテーター：議論を促進し成果の質を向上させることで、プロジェクトの成果をよりよいものにするロール。アジェンダの改善やその後の議論形成のサポート・助言を行う。 8 | * モデレーター：アジェンダの取りまとめや進行サポートを行うことで、議論のプロセスを最適化し進行の時間を維持するロール。アジェンダの合意から、その後のアジェンダ進行とタイムキープ、議論の結果決定された次の行動の明確化、ミーティング終了時の次回のアジェンダの決定までを担う。 9 | * コーディネーター：ミーティング環境を整えるロール。適切なミーティングルームの確保（オンラインの場合はミーティング環境の設定）、ホワイトボードやモニターの手配をする。 10 | * レコーダー：議事録を作成するロール。ミーティング後に議事録を共有するだけでなく、ミーティングの進行中にもリアルタイムで作成中の議事録を共有し、メンバー間の認識のずれを即座に修正することができるようにする。 11 | 12 | チームメンバーの人数によって、一人が複数のロールを担当することもありますし、何もロールを持たないメンバーがいることもあります。ただし、いずれのロールも誰かが担うようにしてください。会議の参加者全員がそれぞれの視点から助言しうるので、ファシリテーターは全員が担うことになるでしょう。また、モデレーター、コーディネーター、レコーダーは属人性が低いため、固定ではなくミーティングごとに持ち回りにすることが望ましいものです。これにより、ミーティング運営に関する問題点や最適な方法について、参加者全員が自分から考えやすくなります。 13 | 14 | ロールの分担はミーティングの都度話し合って決定してもかまいませんが、あらかじめミーティング前に分担や持ち回りのルールを決めておくと、当日のミーティング運営が効率的になります。 15 | -------------------------------------------------------------------------------- /CODE/v3/.3_ja/practices/meeting_rolls.md: -------------------------------------------------------------------------------- 1 | # ミーティングロールの確認 2 | 3 | ミーティングを効率的・効果的に運営するために必要な役割（ミーティングロール）を、個々人に割り当てましょう。 4 | 5 | 具体的には、次のようなロールの割り当てが必要です。 6 | 7 | * ファシリテーター：議論を促進し成果の質を向上させることで、プロジェクトの成果をよりよいものにするロール。アジェンダの改善やその後の議論形成のサポート・助言を行う。 8 | * モデレーター：アジェンダの取りまとめや進行サポートを行うことで、議論のプロセスを最適化し進行の時間を維持するロール。アジェンダの合意から、その後のアジェンダ進行とタイムキープ、議論の結果決定された次の行動の明確化、ミーティング終了時の次回のアジェンダの決定までを担う。 9 | * コーディネーター：ミーティング環境を整えるロール。適切なミーティングルームの確保（オンラインの場合はミーティング環境の設定）、ホワイトボードやモニターの手配をする。 10 | * レコーダー：議事録を作成するロール。ミーティング後に議事録を共有するだけでなく、ミーティングの進行中にもリアルタイムで作成中の議事録を共有し、メンバー間の認識のずれを即座に修正することができるようにする。 11 | 12 | チームメンバーの人数によって、一人が複数のロールを担当することもありますし、何もロールを持たないメンバーがいることもあります。ただし、いずれのロールも誰かが担うようにしてください。会議の参加者全員がそれぞれの視点から助言しうるので、ファシリテーターは全員が担うことになるでしょう。また、モデレーター、コーディネーター、レコーダーは属人性が低いため、固定ではなくミーティングごとに持ち回りにすることが望ましいものです。これにより、ミーティング運営に関する問題点や最適な方法について、参加者全員が自分から考えやすくなります。 13 | 14 | ロールの分担はミーティングの都度話し合って決定してもかまいませんが、あらかじめミーティング前に分担や持ち回りのルールを決めておくと、当日のミーティング運営が効率的になります。 15 | -------------------------------------------------------------------------------- /CODE/v4/.0_ja/README.md: -------------------------------------------------------------------------------- 1 | # v4.0 2 | 3 | ![文書構造](images/illust_documents.png) 4 | 5 | ## [Introduction](introduction.md) 6 | 7 | Introduction では、Project Sprint からの提案の概要を紹介した上で、その基盤となっている価値観を簡単に紹介します。 8 | 9 | ## [Definitions](definitions.md) 10 | 11 | Definitionsでは、Project Sprint を理解するための前提となる、Project Sprint におけるプロジェクト観を説明し、その他の用語を定義します。 12 | 13 | ## [Framework](framework.md) 14 | 15 | Frameworkは、Project Sprint の核となる概念や価値観を示すものです。Project Sprint におけるプロジェクト推進の構造と、そのための価値観や推奨される振る舞いが記述されています。 16 | 17 | v4では、Project Sprint がこれまでも重視してきた「作成物を生む」という行為により重点を置き、プロジェクトを「出力」と「成果」の関係から捉えなおしました。このことにより、以下のような効果を期待しています。 18 | 19 | * 作成物を小さく確実に生み出し続けることを重視することで、プロジェクトの推進と最適化がよりスムーズに行えるようになる 20 | * 出力を成果との1対1の対応関係から解き放ち、より幅広く価値を生み出すことができるようにする 21 | * 予測型・適応型両方のプロジェクトに対応できるようになる 22 | * プロジェクトをよりチームメンバー全員のものとして捉えることができるようになる 23 | 24 | ★Project Sprint の内容に疑問やご意見を持たれた方は、[こちら](https://github.com/copilot-jp/project-sprint/discussions)のGitHub Discussionへお寄せください。 25 | -------------------------------------------------------------------------------- /CODE/v4/.1_ja/README.md: -------------------------------------------------------------------------------- 1 | # v4.1 2 | 3 | ![文書構造](images/illust_documents.png) 4 | 5 | ## [Introduction](introduction.md) 6 | 7 | Introduction では、Project Sprint からの提案の概要を紹介した上で、その基盤となっている価値観を簡単に紹介します。 8 | 9 | ## [Definitions](definitions.md) 10 | 11 | Definitionsでは、Project Sprint を理解するための前提となる、Project Sprint におけるプロジェクト観を説明し、その他の用語を定義します。 12 | 13 | ## [Framework](framework.md) 14 | 15 | Frameworkは、Project Sprint の核となる概念や価値観を示すものです。Project Sprint におけるプロジェクト推進の構造と、そのための価値観や推奨される振る舞いが記述されています。 16 | 17 | v4では、Project Sprint がこれまでも重視してきた「作成物を生む」という行為により重点を置き、プロジェクトを「出力」と「成果」の関係から捉えなおしました。このことにより、以下のような効果を期待しています。 18 | 19 | * 作成物を小さく確実に生み出し続けることを重視することで、プロジェクトの推進と最適化がよりスムーズに行えるようになる 20 | * 出力を成果との1対1の対応関係から解き放ち、より幅広く価値を生み出すことができるようにする 21 | * 予測型・適応型両方のプロジェクトに対応できるようになる 22 | * プロジェクトをよりチームメンバー全員のものとして捉えることができるようになる 23 | 24 | ★Project Sprint の内容に疑問やご意見を持たれた方は、[こちら](https://github.com/copilot-jp/project-sprint/discussions)のGitHub Discussionへお寄せください。 25 | -------------------------------------------------------------------------------- /CODE/README.md: -------------------------------------------------------------------------------- 1 | # Project Sprint 2 | 3 | Project Sprint は実践知を集めて体系化することによってかたちづくられ、今現在もプロジェクトの現場から日々新たな実践知を取り込みながら更新が続けられています。ここには、そんな Project Sprint の各バージョンが格納されています。 4 | 5 | ## 現時点での最新版 6 | * [v4.3](v4/.3_ja/README.md) 7 | 8 | ## 過去バージョン 9 | v4 では、Project Sprint がこれまでも重視してきた「作成物を生む」という行為により重点を置き、プロジェクトを「出力」と「成果」の関係から捉えなおしました。 10 | * [v4.2](v4/.2_ja/README.md) 11 | * [v4.1](v4/.1_ja/README.md) 12 | * [v4.0](v4/.0_ja/README.md) 13 | 14 | v3 では、プロジェクトのすべての要素はプロジェクトチームによって規定されるものであるという思想に基づき、プロジェクトチームを主体とする記述に全面アップデートしました。また、Tutorial 内の 101 をアクションベースで再改訂する等、より分かりやすく汎用性のある形にアップデートしました。 15 | 16 | * [v3.3](v3/.3_ja/README.md) 17 | * [v3.2](v3/.2_ja/README.md) 18 | * [v3.1](v3/.1_ja/README.md) 19 | * [v3.0](v3/.0_ja/README.md) 20 | 21 | v2 では、読みやすさ・使いやすさを考え、各種ドキュメント体系を再構築しました。 22 | 23 | * [v2.2](v2/.2_ja/README.md) 24 | * [v2.0(英文)](v2/.0_en/README.md) 25 | 26 | 各バージョンにおける変更内容の詳細は Release Note をご参照ください。 27 | -------------------------------------------------------------------------------- /CODE/v2/.0_en/tips/tips6.md: -------------------------------------------------------------------------------- 1 | # Tips6: Using a Roll Sheet 2 | 3 | As mentioned in the section on [Knowing your team members and setting their roles](../tutorial/1-2.md), roles are the roles of individual team members. Roles and team members do not necessarily have a one-to-one relationship, and while there is no set type of role, the roles that are set must be clearly defined and agreed upon. 4 | 5 | For this reason, it is recommended to use a "role sheet" to clearly state the "current role status" and keep it available for reference. 6 | 7 | For example, the following elements should be included in the role sheet. 8 | 9 | * Role name 10 | * Responsibilities of the role (for what purpose the role is needed and what the role is to accomplish) 11 | * The person who will be responsible for the role 12 | 13 | Putting these together as a single document and keeping it up-to-date will allow you to understand the current expectations of each member and discuss any discrepancies with those expectations. 14 | -------------------------------------------------------------------------------- /CODE/v2/.2_ja/tips/1-1.md: -------------------------------------------------------------------------------- 1 | # プロジェクトの環境整備 2 | 3 | この記事では、プロジェクスプリントの実施を助けるプロジェクト環境について記載します。 4 | 5 | ここで話す内容は一般的なプロジェクト管理で語られる要素と大きく異なりません。しかし、プロジェクトスプリントでは、それらの要素すべてにおいて、「情報の透明性をいかに担保するか」という点を中心に考えるべきです。 6 | 7 | プロジェクトスプリントでは、プロジェクトのゴールやマイルストーンの設定、ロールの設定と調整をはじめ、様々なタイミングで「チームメンバーの納得を伴った合意」をつくることが必要になります。そのため、納得をつくるため = チームメンバーの情報格差をなくすため、にはどういったプロジェクト環境を用意するべきか、というポイントが重要視されるのです。 8 | 9 | なお、ここに書いている要素は一例に過ぎません。プロジェクトごとに、チームメンバー間で最も最適なプロジェクト環境を整備していくように話し合うこともまた重要です。 10 | 11 | * ファイル共有: プロジェクトメンバー全員が同じ情報にアクセスできるよう、ファイルの共有場所を用意しましょう。 12 | * スケジュール共有: スケジュール調整に必要な限りで、メンバー間の個人カレンダーを共有するようにしましょう。これは、メールなどによって都度日程調整をするのではなく、チームメンバーのスケジュール状況が一か所に集まっており、ミーティングのスケジュールを効率的に設定・変更できるようになることを意味します。 13 | * タスク共有: プロジェクトを通じて生まれるタスクを共有できる場所を用意しましょう。個人でタスク管理するのではなく、プロジェクトチームで共有のタスク置き場を用意することで、お互いが何をするべきか / するつもりだったか、を確認するコミュニケーションがしやすくなります。 14 | 15 | その他、プロジェクトスプリントの3つのドメインそれぞれにおいて必要とされる環境については、それぞれ以下のTipsをご参照ください。 16 | 17 | * プログレスドメイン: [マイルストーンマップの利用](2-1.md) 18 | * プロセスドメイン: [ミーティング環境についてのノウハウ](3-2-1.md) 19 | * チーミングドメイン: [ロールシートの利用](4-2.md) 20 | -------------------------------------------------------------------------------- /CODE/v2/.0_en/tips/README.md: -------------------------------------------------------------------------------- 1 | # Tips 2 | 3 | This set of documents contains detailed and in-depth explanations of Project Sprint. 4 | 5 | ## Table of Contents 6 | 7 | 1. [Useful Concepts for Organizing the Project Timeline (tracks/phases/events)](tips1.md) 8 | 2. [Using a Milestone Map](tips2.md) 9 | 3. [What Are Some of the Things That Are Produced in a Project(outputs/deliverables)](tips3.md) 10 | 4. [Preparing Project Environments](tips4.md) 11 | 5. [Setting Up Roles That Are Easy to Use in Practice](tips5.md) 12 | 6. [Using a Roll Sheet](tips6.md) 13 | 7. [Know-How About the Meeting Environment](tips7.md) 14 | 8. [All Elements That Should be Included in the Agenda](tips8.md) 15 | 9. [Typical Looking Back Techniques](tips9.md) 16 | 10. [Tension Triage Methods](tips10.md) 17 | 11. [How to Set Tasks in a Way That Makes Sense to the Team and Is Efficient](tips11.md) 18 | 12. [Why Meetings Should Be Held on a Regular Basis](tips12.md) 19 | 13. [Classification and Properties of Roles](tips13.md) 20 | 14. [The Purpose of an Agenda](tips14.md) 21 | -------------------------------------------------------------------------------- /CODE/v3/.2_ja/theories/project_goals.md: -------------------------------------------------------------------------------- 1 | # プロジェクトゴールとは 2 | 3 | ## プロジェクトゴールとは 4 | 5 | プロジェクトゴールとは、プロジェクトにおいてプロジェクトチームが達成したい成果を指します。成果はある一定の状態であることもあれば、具体的な作成物であることもあります。 6 | 7 | [Project Sprint 101](101.md)で述べたように、Project Sprintではプロジェクトを「全体」に対する「部分」であると捉えており、プロジェクトゴールは「大きなゴール」の達成に近づくために必要な一歩としての「小さなゴール」です。この漸進的な進捗のための成果だけでなく、「相互に期待値を共有し合う自律的なプロジェクトチームを形成する」というチーミングにおける理想の状態を達成することも、プロジェクトゴールに含まれます。漸進的な進捗のための成果とチーミングにおける理想の状態いずれの達成に比重が置かれるかは、プロジェクトによって様々です。 8 | 9 | プロジェクトゴールはプロジェクトチームによって定義され、プロジェクトチームとして認識が揃っており、プロジェクトチームによって必要に応じて再定義しうるものでなくてはなりません。これらが実現していることにより、各チームメンバーがプロジェクトゴールの達成に現実味と納得感を持ってプロジェクトに参画できるのです。 10 | 11 | プロジェクトチームは、プロジェクトが進むべき方向を適切に見定められるよう、プロジェクトゴールが全体ゴールに対してどういう位置づけにあり、どういう役割を果たすのかを常に認識しておく必要があります。また、このプロジェクトチームとしての認識は、プロジェクトの外部に対しても明確に示せる状態にしておきます。 12 | 13 | ## プロジェクトゴールの設定 14 | 15 | プロジェクトはプロジェクトソースの希望を源として立ち上がり、まずはプロジェクトソース主導の下で、目指すべきゴールの仮説に基づいてプロジェクトチームが組成されます。プロジェクトチームが組成されてからは、プロジェクトチームが主体となり、自身の意思に基づいて改めてプロジェクトを定義しプロジェクトゴールを設定します。 16 | 17 | 具体的な設定方法については、実践編「[プロジェクトゴールの設定](../practices/project_goals.md)」をご覧ください。 18 | -------------------------------------------------------------------------------- /CODE/v3/.3_ja/theories/project_goals.md: -------------------------------------------------------------------------------- 1 | # プロジェクトゴールとは 2 | 3 | ## プロジェクトゴールとは 4 | 5 | プロジェクトゴールとは、プロジェクトにおいてプロジェクトチームが達成したい成果を指します。成果はある一定の状態であることもあれば、具体的な作成物であることもあります。 6 | 7 | [Project Sprint 101](101.md)で述べたように、Project Sprintではプロジェクトを「全体」に対する「部分」であると捉えており、プロジェクトゴールは「大きなゴール」の達成に近づくために必要な一歩としての「小さなゴール」です。この漸進的な進捗のための成果だけでなく、「相互に期待値を共有し合う自律的なプロジェクトチームを形成する」というチーミングにおける理想の状態を達成することも、プロジェクトゴールに含まれます。漸進的な進捗のための成果とチーミングにおける理想の状態いずれの達成に比重が置かれるかは、プロジェクトによって様々です。 8 | 9 | プロジェクトゴールはプロジェクトチームによって定義され、プロジェクトチームとして認識が揃っており、プロジェクトチームによって必要に応じて再定義しうるものでなくてはなりません。これらが実現していることにより、各チームメンバーがプロジェクトゴールの達成に現実味と納得感を持ってプロジェクトに参画できるのです。 10 | 11 | プロジェクトチームは、プロジェクトが進むべき方向を適切に見定められるよう、プロジェクトゴールが全体ゴールに対してどういう位置づけにあり、どういう役割を果たすのかを常に認識しておく必要があります。また、このプロジェクトチームとしての認識は、プロジェクトの外部に対しても明確に示せる状態にしておきます。 12 | 13 | ## プロジェクトゴールの設定 14 | 15 | プロジェクトはプロジェクトソースの希望を源として立ち上がり、まずはプロジェクトソース主導の下で、目指すべきゴールの仮説に基づいてプロジェクトチームが組成されます。プロジェクトチームが組成されてからは、プロジェクトチームが主体となり、自身の意思に基づいて改めてプロジェクトを定義しプロジェクトゴールを設定します。 16 | 17 | 具体的な設定方法については、実践編「[プロジェクトゴールの設定](../practices/project_goals.md)」をご覧ください。 18 | -------------------------------------------------------------------------------- /CODE/v2/.2_ja/tips/1-6.md: -------------------------------------------------------------------------------- 1 | # ロールの分類と性質 2 | 3 | [チームメンバーを知り、ロールを設定する](../tutorial/1-2.md)で述べたように、プロジェクトスプリントでは、チームメンバー個々人の役割のことをロールと呼びます。また[実務で使いやすいロールの設定](1-5.md)で説明したように、プロジェクトスプリントでは、ミーティングロール以外には必ず設定しなければならないロールというものを決めておらず、ロールの定義についてはチームメンバーで合意することのみが必要な条件となっています。 4 | 5 | しかし、この「チームメンバーの合意」は、必ずしも明示的なものとは限りません。つまり、Tips5で説明した「チーミングリード」「プロセスリード」のように、チームで名前を決めて共有されるロールもある一方、プロジェクトを進めていくなかで、あるメンバーが自然に担っていく暗黙的な役割があります。プロジェクトスプリントにおいて、前者は「明示ロール」と呼ばれ、後者は「暗黙ロール」と呼ばれます。 6 | 7 | これらの区別は絶対的なものではなく、ある暗黙ロールが、何かのきっかけによって明示ロールとなることもありえます。 8 | 9 | 例えば、最初から暗黙ロールが十分に機能することはほとんどありません。つまり、「あの人がこれをやってくれるだろう」という阿吽の呼吸・暗黙の了解は、チーム発足初期にはあまり機能しないということです。多くの場合こうした暗黙ロールは一度「この人はこういう役割の人だ」という明示ロールとして表現され、この過程で期待値のすり合わせが行われます。その後、「あの人はこういう役割の人だからこれもやってくれるだろう」と、暗黙ロールも機能し始めるのです。チームメンバーの互いの期待値が合ってくると、未知の状況にも柔軟に対応できるようになります。 10 | 11 | なお、暗黙ロールと明示ロールの割合はプロジェクトやチームによって異なるもので、最適なバランスもそれぞれ異なります。また、単純にロールの数が多いほうがよい、少ないほうがよい、といった点についても、一律の答えはありません。 12 | 13 | ただし、ロールは次のような状態になっていることが望ましいとされます。 14 | 15 | * チームメンバー間で、ロールの中でやるべきことがより細かい粒度で理解されているほどよい。 16 | * そのチームにとって最もコストのかからない方法で、チームにとって必要十分なロールが共有されているほどよい。 17 | * 各ロールのやるべきことをお互いにフォローできればできるほどよい。 18 | -------------------------------------------------------------------------------- /CODE/v3/.2_ja/practices/tension_triage.md: -------------------------------------------------------------------------------- 1 | # テンショントリアージ 2 | 3 | ## **テンショントリアージとは** 4 | 5 | [ミーティングの進行方法](holding_meetings.md)で解説したように、テンショントリアージとは、個々のチームメンバーが感じている違和感を提案に変えて全員で共有したうえで、今チームを改善するために必要なものを優先的に選び、解決しようとすることです。これによって、メンバー一人一人が思う「こうしたらもっとより良くなるのに」という現状とよりよい状態の間のギャップ、ちょっとしたアイデア・気になること・不安などを共有し、解決のためのアクションにつなげることができます。 6 | 7 | テンショントリアージは毎回のミーティングで行う取り組みであり、主にチームメンバーの今現在の気持ちにフォーカスしているものです。現在を見ることで、問題が顕在化もしくは拡大する前に共有し対処することができるようになります。 また、タイムリーに気持ちを吐き出すことができる場があることで、メンバーのプロジェクトへの参加感の向上にもつながります。 8 | 9 | ## **具体的な手順** 10 | 11 | テンショントリアージは、例えば次のような手順で実施しますが、これはあくまで一例です。上記の目的をより効率的・効果的に達成するために、ご自身のチームにとって最適な方法にアレンジしてみてください。 12 | 13 | 1. チームメンバーがテンションをあげる 14 | 2. テンショントリアージのアジェンダアイテムオーナーがテンションを一つ読み上げ「何が必要ですか？」とテンションをあげた人に問いかける 15 | 3. テンションをあげた人は次のいずれかを選択し、そのあと自分が必要としていることを回答する 16 | 17 | * 他メンバーへのタスクのリクエスト 18 | * 他メンバーからの情報やヘルプ提供のリクエスト 19 | * ロールの調整・変更・追加に関するリクエスト 20 | * 単なる情報提供や感想の共有 21 | 22 | 1. テンショントリアージのアジェンダアイテムオーナーは、次のいずれかを選択してテンションをあげた人に提案する 23 | * その場で解決する 24 | * タスク化する 25 | * アジェンダアイテム化する 26 | 2. テンションをあげた人がこれで必要なことが得られれば終了とし、得られなければ、続けて議論する(3と4を詳しく繰り返す) 27 | 3. 時間の許す限り、他のテンションについても2\~5の手順を繰り返す 28 | -------------------------------------------------------------------------------- /CODE/v3/.3_ja/practices/tension_triage.md: -------------------------------------------------------------------------------- 1 | # テンショントリアージ 2 | 3 | ## **テンショントリアージとは** 4 | 5 | [ミーティングの進行方法](holding_meetings.md)で解説したように、テンショントリアージとは、個々のチームメンバーが感じている違和感を提案に変えて全員で共有したうえで、今チームを改善するために必要なものを優先的に選び、解決しようとすることです。これによって、メンバー一人一人が思う「こうしたらもっとより良くなるのに」という現状とよりよい状態の間のギャップ、ちょっとしたアイデア・気になること・不安などを共有し、解決のためのアクションにつなげることができます。 6 | 7 | テンショントリアージは毎回のミーティングで行う取り組みであり、主にチームメンバーの今現在の気持ちにフォーカスしているものです。現在を見ることで、問題が顕在化もしくは拡大する前に共有し対処することができるようになります。 また、タイムリーに気持ちを吐き出すことができる場があることで、メンバーのプロジェクトへの参加感の向上にもつながります。 8 | 9 | ## **具体的な手順** 10 | 11 | テンショントリアージは、例えば次のような手順で実施しますが、これはあくまで一例です。上記の目的をより効率的・効果的に達成するために、ご自身のチームにとって最適な方法にアレンジしてみてください。 12 | 13 | 1. チームメンバーがテンションをあげる 14 | 2. テンショントリアージのアジェンダアイテムオーナーがテンションを一つ読み上げ「何が必要ですか？」とテンションをあげた人に問いかける 15 | 3. テンションをあげた人は次のいずれかを選択し、そのあと自分が必要としていることを回答する 16 | 17 | * 他メンバーへのタスクのリクエスト 18 | * 他メンバーからの情報やヘルプ提供のリクエスト 19 | * ロールの調整・変更・追加に関するリクエスト 20 | * 単なる情報提供や感想の共有 21 | 22 | 1. テンショントリアージのアジェンダアイテムオーナーは、次のいずれかを選択してテンションをあげた人に提案する 23 | * その場で解決する 24 | * タスク化する 25 | * アジェンダアイテム化する 26 | 2. テンションをあげた人がこれで必要なことが得られれば終了とし、得られなければ、続けて議論する(3と4を詳しく繰り返す) 27 | 3. 時間の許す限り、他のテンションについても2~5の手順を繰り返す 28 | -------------------------------------------------------------------------------- /CODE/v3/.0_ja/tutorial/section4-1-2.md: -------------------------------------------------------------------------------- 1 | # 現在の心の声を活用する：テンショントリアージ 2 | 3 | ## **テンショントリアージとは** 4 | 5 | [ミーティングを開催する](section3-2.md)で解説したように、テンショントリアージとは、個々のチームメンバーが感じている違和感を提案に変えて全員で共有したうえで、今チームを改善するために必要なものを優先的に選び、解決しようとすることです。これによって、メンバー一人一人が思う「こうしたらもっとより良くなるのに」という現状とよりよい状態の間のギャップ、ちょっとしたアイデア・気になること・不安などを共有し、解決のためのアクションにつなげることができます。 6 | 7 | テンショントリアージは毎回のミーティングで行う取り組みであり、主にチームメンバーの今現在の気持ちにフォーカスしているものです。現在を見ることで、問題が顕在化もしくは拡大する前に共有し対処することができるようになります。 また、タイムリーに気持ちを吐き出すことができる場があることで、メンバーのプロジェクトへの参加感の向上にもつながります。 8 | 9 | ## **具体的な手順** 10 | 11 | テンショントリアージは、例えば次のような手順で実施しますが、これはあくまで一例です。上記の目的をより効率的・効果的に達成するために、ご自身のチームにとって最適な方法にアレンジしてみてください。 12 | 13 | 1. チームメンバーがテンションをあげる 14 | 2. テンショントリアージのアジェンダアイテムオーナーがテンションを一つ読み上げ「何が必要ですか？」とテンションをあげた人に問いかける 15 | 3. テンションをあげた人は次のいずれかを選択し、そのあと自分が必要としていることを回答する 16 | 17 | * 他メンバーへのタスクのリクエスト 18 | * 他メンバーからの情報やヘルプ提供のリクエスト 19 | * ロールの調整・変更・追加に関するリクエスト 20 | * 単なる情報提供や感想の共有 21 | 22 | 1. テンショントリアージのアジェンダアイテムオーナーは、次のいずれかを選択してテンションをあげた人に提案する 23 | * その場で解決する 24 | * タスク化する 25 | * アジェンダアイテム化する 26 | 2. テンションをあげた人がこれで必要なことが得られれば終了とし、得られなければ、続けて議論する(3と4を詳しく繰り返す) 27 | 3. 時間の許す限り、他のテンションについても2\~5の手順を繰り返す 28 | -------------------------------------------------------------------------------- /CODE/v3/.1_ja/tutorial/section4-1-2.md: -------------------------------------------------------------------------------- 1 | # 現在の心の声を活用する：テンショントリアージ 2 | 3 | ## **テンショントリアージとは** 4 | 5 | [ミーティングを開催する](section3-2.md)で解説したように、テンショントリアージとは、個々のチームメンバーが感じている違和感を提案に変えて全員で共有したうえで、今チームを改善するために必要なものを優先的に選び、解決しようとすることです。これによって、メンバー一人一人が思う「こうしたらもっとより良くなるのに」という現状とよりよい状態の間のギャップ、ちょっとしたアイデア・気になること・不安などを共有し、解決のためのアクションにつなげることができます。 6 | 7 | テンショントリアージは毎回のミーティングで行う取り組みであり、主にチームメンバーの今現在の気持ちにフォーカスしているものです。現在を見ることで、問題が顕在化もしくは拡大する前に共有し対処することができるようになります。 また、タイムリーに気持ちを吐き出すことができる場があることで、メンバーのプロジェクトへの参加感の向上にもつながります。 8 | 9 | ## **具体的な手順** 10 | 11 | テンショントリアージは、例えば次のような手順で実施しますが、これはあくまで一例です。上記の目的をより効率的・効果的に達成するために、ご自身のチームにとって最適な方法にアレンジしてみてください。 12 | 13 | 1. チームメンバーがテンションをあげる 14 | 2. テンショントリアージのアジェンダアイテムオーナーがテンションを一つ読み上げ「何が必要ですか？」とテンションをあげた人に問いかける 15 | 3. テンションをあげた人は次のいずれかを選択し、そのあと自分が必要としていることを回答する 16 | 17 | * 他メンバーへのタスクのリクエスト 18 | * 他メンバーからの情報やヘルプ提供のリクエスト 19 | * ロールの調整・変更・追加に関するリクエスト 20 | * 単なる情報提供や感想の共有 21 | 22 | 1. テンショントリアージのアジェンダアイテムオーナーは、次のいずれかを選択してテンションをあげた人に提案する 23 | * その場で解決する 24 | * タスク化する 25 | * アジェンダアイテム化する 26 | 2. テンションをあげた人がこれで必要なことが得られれば終了とし、得られなければ、続けて議論する(3と4を詳しく繰り返す) 27 | 3. 時間の許す限り、他のテンションについても2\~5の手順を繰り返す 28 | -------------------------------------------------------------------------------- /CODE/v3/.2_ja/practices/stand-up_meetings.md: -------------------------------------------------------------------------------- 1 | # スタンドアップの導入 2 | 3 | Project Sprintでは定期的なミーティングでタスクの進捗報告を行い、問題が発生していればアジェンダアイテムとしてミーティング内で議論します。しかし、それぞれが自律的にタスクに取り組むうちに、成果物のイメージが当初の想定とずれてきたり、進め方や連携の方法が最適でなくなってきたりすることがあります。 4 | 5 | こういった状況を定例ミーティングを待たずして是正するため、各メンバーのタスクの状況をクイックに確認する方法として、「スタンドアップ」を導入することがあります。スタンドアップで個々のメンバーのタスクへの取り組み状況が共有されることで、成果物や進め方に対する認識がアップデートされ、取り組み方法が改善されたりメンバー間の連携や役割分担が最適化されたりするきっかけが生まれます。 6 | 7 | ## 概要 8 | 9 | Project Sprintにおけるスタンドアップは、次のような形で導入されます。 10 | 11 | * 時間: 長さは15～30分程度で、スプリントの中で複数回行われる場合は毎回同じ時間帯とするのが望ましい。 12 | * 頻度: 日次、スプリントの折返しタイミング、週頭など、スプリントやチームの状況に合わせて設定する。チームメンバーの要望によりスポットで実施してもよい。 13 | * メンバー: チームメンバー全員 14 | * 目的: チームのタスク状況を確認し、見直しが必要な場合にはそのきっかけを掴むこと 15 | 16 | ## 共有事項 17 | 18 | チームメンバーは、次の内容についての共有を、プロジェクトのマイルストーンを見ながら行います。 19 | 20 | 1. 実行したこと 21 | 2. これから実行すること 22 | 3. 障害・問題（あれば） 23 | 24 | ## 実施のポイント 25 | 26 | * 障害・問題は共有に留める。 27 | スタンドアップは問題解決の場ではないことに注意してください。スタンドアップにおいて、問題点の共有だけに留まらず解決方法まで議論してしまって、タイムボックスを破ることになるのは望ましくありません。解決すべき障害や問題の報告があった場合は、スタンドアップ後に関係者で解決策を話し合い、必要に応じて結果をほかのメンバーに共有するようにします。 28 | 29 | * いつものファシリテーターがハンドリングしない。 30 | スタンドアップでの実施内容はシンプルです。メンバーそれぞれが持ち回りでファシリテーションを行い、自己組織化を促します。 31 | -------------------------------------------------------------------------------- /CODE/v3/.3_ja/practices/stand-up_meetings.md: -------------------------------------------------------------------------------- 1 | # スタンドアップの導入 2 | 3 | Project Sprintでは定期的なミーティングでタスクの進捗報告を行い、問題が発生していればアジェンダアイテムとしてミーティング内で議論します。しかし、それぞれが自律的にタスクに取り組むうちに、成果物のイメージが当初の想定とずれてきたり、進め方や連携の方法が最適でなくなってきたりすることがあります。 4 | 5 | こういった状況を定例ミーティングを待たずして是正するため、各メンバーのタスクの状況をクイックに確認する方法として、「スタンドアップ」を導入することがあります。スタンドアップで個々のメンバーのタスクへの取り組み状況が共有されることで、成果物や進め方に対する認識がアップデートされ、取り組み方法が改善されたりメンバー間の連携や役割分担が最適化されたりするきっかけが生まれます。 6 | 7 | ## 概要 8 | 9 | Project Sprintにおけるスタンドアップは、次のような形で導入されます。 10 | 11 | * 時間: 長さは15～30分程度で、スプリントの中で複数回行われる場合は毎回同じ時間帯とするのが望ましい。 12 | * 頻度: 日次、スプリントの折返しタイミング、週頭など、スプリントやチームの状況に合わせて設定する。チームメンバーの要望によりスポットで実施してもよい。 13 | * メンバー: チームメンバー全員 14 | * 目的: チームのタスク状況を確認し、見直しが必要な場合にはそのきっかけを掴むこと 15 | 16 | ## 共有事項 17 | 18 | チームメンバーは、次の内容についての共有を、プロジェクトのマイルストーンを見ながら行います。 19 | 20 | 1. 実行したこと 21 | 2. これから実行すること 22 | 3. 障害・問題（あれば） 23 | 24 | ## 実施のポイント 25 | 26 | * 障害・問題は共有に留める。 27 | スタンドアップは問題解決の場ではないことに注意してください。スタンドアップにおいて、問題点の共有だけに留まらず解決方法まで議論してしまって、タイムボックスを破ることになるのは望ましくありません。解決すべき障害や問題の報告があった場合は、スタンドアップ後に関係者で解決策を話し合い、必要に応じて結果をほかのメンバーに共有するようにします。 28 | 29 | * いつものファシリテーターがハンドリングしない。 30 | スタンドアップでの実施内容はシンプルです。メンバーそれぞれが持ち回りでファシリテーションを行い、自己組織化を促します。 31 | -------------------------------------------------------------------------------- /CODE/v2/.2_ja/tips/1-4.md: -------------------------------------------------------------------------------- 1 | # スタンドアップの導入 2 | 3 | [ミーティングを開催する](../tutorial/2-2.md)で記述したように、プロジェクトスプリントでは定期的なミーティングでタスクの進捗報告を行い、問題が発生していればアジェンダアイテムとしてミーティング内で議論します。しかし、それぞれが自律的にタスクに取り組むうちに、成果物のイメージが当初の想定とずれてきたり、進め方や連携の方法が最適でなくなってきたりすることがあります。 4 | 5 | こういった状況を定例ミーティングを待たずして是正するため、各メンバーのタスクの状況をクイックに確認する方法として、「スタンドアップ」を導入することがあります。スタンドアップで個々のメンバーのタスクへの取り組み状況が共有されることで、成果物や進め方に対する認識がアップデートされ、取り組み方法が改善されたりメンバー間の連携や役割分担が最適化されたりするきっかけが生まれます。 6 | 7 | ### **概要** 8 | 9 | プロジェクトスプリントにおけるスタンドアップは、次のような形で導入されます。 10 | 11 | * 時間: 長さは15～30分程度で、スプリントの中で複数回行われる場合は毎回同じ時間帯とするのが望ましい。 12 | * 頻度: 日次、スプリントの折返しタイミング、週頭など、スプリントやチームの状況に合わせて設定する。チームメンバーの要望によりスポットで実施してもよい。 13 | * メンバー: チームメンバー全員 14 | * 目的: チームのタスク状況を確認し、見直しが必要な場合にはそのきっかけを掴むこと 15 | 16 | ### **共有事項** 17 | 18 | チームメンバーは、次の内容についての共有を、プロジェクトのマイルストーンを見ながら行います。 19 | 20 | 1. 実行したこと 21 | 2. これから実行すること 22 | 3. 障害・問題（あれば） 23 | 24 | ### **実施のポイント** 25 | 26 | * 障害・問題は共有に留める。 スタンドアップは問題解決の場ではないことに注意してください。スタンドアップにおいて、問題点の共有だけに留まらず解決方法まで議論してしまって、タイムボックスを破ることになるのは望ましくありません。解決すべき障害や問題の報告があった場合は、スタンドアップ後に関係者で解決策を話し合い、必要に応じて結果をほかのメンバーに共有するようにします。 27 | * いつものファシリテーターがハンドリングしない。 スタンドアップでの実施内容はシンプルです。メンバーそれぞれが持ち回りでファシリテーションを行い、自己組織化を促します。 28 | -------------------------------------------------------------------------------- /CODE/v2/.2_ja/tutorial/README.md: -------------------------------------------------------------------------------- 1 | # Tutorial 2 | 3 | このドキュメント群では、プロジェクトスプリントの基本的な概念の説明と実践方法が順を追って説明されています。 4 | 5 | 全体を通して4つの章から構成されており、上から順番に読み進めていくことで、プロジェクトスプリントを実際のプロジェクトで使うことができるようになっています。 6 | 7 | まだプロジェクトスプリントをやっていない人が学習のための最初の一歩としては使うことはもちろん、すでにプロジェクトスプリントを行っている人も、実施のための基盤がためとして読むことができます。 8 | 9 | #### 目次 10 | 11 | **はじめに** 12 | 13 | 最初に読んでほしいプロジェクトスプリントの概要を紹介しています。 14 | 15 | * [Project Sprint 101](project-sprint-101.md) 16 | 17 | **準備しよう** 18 | 19 | プロジェクトスプリントを始めるにあたって準備しなければいけないことを記載しています。まずはここで決めた仕組みをもとにして、プロジェクトスプリントがスタートします。 20 | 21 | * [プロジェクトのゴールとマイルストーンを設定する](1-1.md) 22 | * [チームメンバーを知り、ロールを設定する](1-2.md) 23 | * [ミーティングを設計する](1-3.md) 24 | 25 | **やってみよう** 26 | 27 | プロジェクトスプリントによって実際にプロジェクトを運営していく方法を記載してみます。「準備しよう」でつくった仕組みを動かしていきましょう。 28 | 29 | * [ミーティングの準備をする](2-1.md) 30 | * [ミーティングを開催する](2-2.md) 31 | 32 | **改善しよう** 33 | 34 | プロジェクトスプリントは、プロジェクト運営をよりよくしていく仕組みも併せ持っているメソッドです。「やってみよう」で行ったことをもとに、どんどんプロジェクトを改善していきましょう。 35 | 36 | * [振り返りを行う](3-1.md) 37 | * [プロジェクトのゴールとマイルストーンを見直す](3-2.md) 38 | * [ロールを確認する](3-3.md) 39 | 40 | **さらに学びたい人へ** 41 | 42 | プロジェクトスプリントを学習し、自らもメソッドづくりに貢献するためのユーザーコミュニティについて記載しています。 43 | 44 | * [ユーザーコミュニティ](4-1.md) 45 | -------------------------------------------------------------------------------- /CODE/v3/.3_ja/theories/milestones.md: -------------------------------------------------------------------------------- 1 | # マイルストーンとは 2 | 3 | ## マイルストーンとは 4 | 5 | マイルストーンとは、プロジェクト内のある時点において、具体的な作成物とそれに紐づく期限をセットにして記述したもののことです。あるマイルストーンを達成するまでの期間のことをステージと呼びます。 6 | 7 | マイルストーンは[トラック](tracks.md)ごとに設定され、ひとつのトラックに複数置かれることがほとんどです。各トラックにおけるマイルストーンの達成の集積がメインのトラックにおけるマイルストーンの達成となり、メインのトラックにおけるマイルストーンを順次達成していくことがプロジェクトゴールの達成への道です。 8 | 9 | マイルストーンもプロジェクトゴールと同様に、当該マイルストーンが置かれるトラックの進行を担うチームによって定義され、当該チームとして認識が揃っており、当該チームによって必要に応じて再定義しうるものでなくてはなりません。また、当該チームは自らが達成すべきマイルストーンがプロジェクトゴールに対してどういう位置づけにあり、どういう役割を果たすのかを常に認識し、それをプロジェクトチーム全体に対して明確に示せる状態にしておく必要があります。 10 | 11 | ## マイルストーンの価値 12 | 13 | マイルストーンを明示化し常に意識することで、最終的な状態や作成物に向かう道筋の確からしさを確認し、現在の地点からチームが何をするべきか、またその後何を目指していくべきかを見通すことができます。 14 | 15 | Project Sprintにおいて、プロジェクトゴールに向けての進捗は、現在のステータス(As-Is)とあるべきステータス(To-Be)の距離として捉えられます。 As-Is時点からTo-Beを描くとき、チームメンバーによってはあまり確度が高くないこともあります。 16 | 17 | この原因は、大きく二つに分けられます。 18 | 19 | * As-IsやTo-Beに関して、チームメンバー間で認識が揃っていないこと (**ズレの問題**) 20 | * As-IsやTo-Beに関して、実際にタスクをリスト化し具体的に取り組んでいかなければ明らかにならない部分が多いこと (**粗さの問題**) 21 | 22 | Project Sprintでは、定例ミーティングでの認識合わせとマイルストーンの設定によってこれらの問題を解決します。最終的なプロジェクトゴール（To-Be）より距離の近いTo-Be'としてのマイルストーンを設定することで未来に対する予測の粗さを軽減するとともに具体的な取り組みに落とし込みやすくするのです。 23 | -------------------------------------------------------------------------------- /CODE/v3/.1_ja/README.md: -------------------------------------------------------------------------------- 1 | # v3.1 2 | 3 | ## **CODEとは** 4 | 5 | **CODE**とは、Project Sprintについて説明したドキュメント群の総称です。 6 | 7 | ### [**Tutorial**](tutorial/README.md) 8 | 9 | Project Sprintの基本的な概念の説明と実践方法が順を追って説明されており、読みながらProject Sprintを実際に導入することができます。 Project Sprintというものの概要を手早く理解したい方は、まずはTutorialのProject Sprint 101をお読みいただくとよいでしょう。このページは、「Project Sprintの基本メカニズム」「Project Sprintを理解するために把握しておくべき前提」「Project Sprintを活用するためのコア・アクション」の三本立ての構成になっています。Project Sprintをアクションベースで理解することで、実際の活用イメージが掴みやすくなることを期待しています。 10 | 11 | ### [**Essentials**](essentials.md) 12 | 13 | Project Sprintの核となる行動規範がシンプルに述べられており、そこからProject Sprintが立脚する思想や価値観を理解することができます。Tutorialの通読後に改めてEssentialsをお読みいただくと、Project Sprintの最重要箇所をより把握しやすくなるでしょう。 14 | 15 | ### [**Reference**](reference.md) 16 | 17 | Project Sprintの背景にある諸メソッド・概念・文献について記載されており、Project Sprintの効率的な理解が可能になり、また今後のメソッドのアップデートに関わりそうな情報を知ることができます。さらに、背景を知ることでメソッドの応用も可能になります。 18 | 19 | ## **ドキュメントの比較表** 20 | 21 | |ドキュメント名|Tutorial|Essentials|Reference| 22 | |----|----|----|----| 23 | |記載内容|基本的な概念の説明と実践方法|核となる行動規範|背景にある諸メソッド・概念・文献| 24 | |効果|基本の理解、導入手順、具体的なノウハウが理解できる|Project Sprintが立脚する思想や価値観が理解できる|効率的なProject Sprintの理解、メソッドのアップデートに関わりそうな情報、応用のための知識が得られる| 25 | -------------------------------------------------------------------------------- /CODE/v2/.2_ja/tips/1-5.md: -------------------------------------------------------------------------------- 1 | # 実務で使いやすいロールの設定 2 | 3 | プロジェクトスプリントでは、ミーティングロール以外には必ず設定しなければならないロールというものを決めておらず、ロールの定義についてはチームメンバーで合意することのみが必要な条件となっています。 4 | 5 | ただし、次の表のようなロールについては、実務上よく使われることを見越して、あらかじめ用意されています。 特にプロジェクトスプリントを初めて導入する場合、これらのロールを利用することによって、導入をスムーズに行うことができます。 6 | 7 | **プロジェクトスプリントの4領域と、それぞれに必要なロール** 8 | 9 | ![プロジェクトスプリントに必要なロール](../images/roles.png) 10 | 11 | それぞれのロールで使われている「リード」という言葉には、理想的な状態へチームを引っ張っていくという意味合いが込められています。独力でプロジェクトを管理したり推進したりするのではなく、各領域で求められていることや指標をチーム全体で達成できる環境を作ることが、「リード」の役割です。必ずしも組織における管理職や上位の人しかこのロールを担当できないというわけではありません。 12 | 13 | ### **スプリントリード** 14 | 15 | スプリントリードは、プロジェクスプリントの導入を行うロールです。具体的には、プロジェクトスプリントのCODEに書かれている手法をチームメンバーへ説明したり、実際にプロジェクトスプリントの準備と実践を主導することが期待されます。 16 | 17 | **各ドメインをリードするロール** 18 | 19 | ### **プログレスリード** 20 | 21 | プロジェクトのゴールとマイルストーンの達成をリードするためのロールです。アウトカムや成果物作成の進捗管理を行ったり、進捗を達成するために効果的・効率的な最適化の方法を検討してプロジェクトの活動に取り入れたりします。 22 | 23 | ### **プロセスリード** 24 | 25 | プロジェクトの各スプリントにおけるプロセスが正しく機能していること、とりわけミーティングが最適に運用される状態の維持・向上をリードするためのロールです。ミーティングの準備と実践が効果的・効率的に行われるための活動を行います。 26 | 27 | ### **チーミングリード** 28 | 29 | 「チームの状態を現状よりよくすること」をリードするためのロールです。チームのロールの明文化、新たなロールが発生したときやロールに変更があったときの調整、といった活動を担当し、自律的で理想的なチームの形成をリードします。 30 | -------------------------------------------------------------------------------- /CODE/v2/.2_ja/tutorial/3-3.md: -------------------------------------------------------------------------------- 1 | # ロールを確認する 2 | 3 | この記事の内容はプロジェクトスプリントにおける「チーミングドメイン」にあたります。 4 | 5 | プロセスは定期開催のミーティングとそこでのアジェンダの議論を軸としたプロジェクトスプリント固有の仕組みです。この仕組みを通じてプロジェクトの進捗状況の共有、プロジェクトの進め方の継続的な改善・プロジェクトのゴールに向けたマイルストーンの見直しや互いのロールの確認をすることができるようになります。 6 | 7 | この記事では、ロールの確認について解説します。 8 | 9 | ### **ロールの確認** 10 | 11 | [チームメンバーを知り、ロールを設定する](1-2.md)でも述べたように、チーミングの「理想の状態」には、明確な形がありません。なぜなら「ここまで達成したら理想のチームだ！」というものが決めにくいからです。そこでプロジェクトスプリントでは、「今の時点よりは良いチームの状態」を常に目指します。 12 | 13 | そして、ここでの「より良い」とは、チームメンバー同士の果たすべき役割=ロールについての期待値がそろっている状態のことを指します。つまりロールの確認とは、チームメンバーの持つ互いの役割についての期待値がそろってきているか、を確認するための取り組みです。 14 | 15 | ロールの確認をするべきタイミングは、次のような時です。 16 | 17 | 1. これまで定義したロールがより詳細にブレイクダウンして考えられるようになり、細かい認識合わせができるようになったとき 18 | 2. プロジェクトの進行により、これまで定義していないような作業が生まれ、そのロールの明確化が必要だと考えられるようになったとき 19 | 3. これまで定義し、あるメンバーにアサインされていたロールがあるメンバーの期待に添わないとき。例えば、実際にはアサインされているメンバーが別のメンバーがロールを遂行していたり、他のメンバーがアサインされているメンバーに対する期待値が満たされていないと考えていたり、逆にアサインされている人が自分が思っている以上の期待値を感じていたりするとき 20 | 4. その他何らかの理由でチームメンバーがロールの確認をしたほうがよいと考えたとき 21 | 22 | ロール確認の実施についてもミーティングのアジェンダアイテムとなるため、事前にアジェンダアイテムの提出を行う必要があります。 23 | 24 | **このページと関係するTips** 25 | 26 | * [実務で使いやすいロールの設定](../tips/1-5.md) 27 | * [ロールシートの利用](../tips/4-2.md) 28 | -------------------------------------------------------------------------------- /CODE/v3/.2_ja/README.md: -------------------------------------------------------------------------------- 1 | # v3.2 2 | 3 | ## **CODEとは** 4 | 5 | **CODE**とは、Project Sprintについて説明したドキュメント群の総称です。 6 | 7 | ### [Theories and Practices](theories_and_practices.md) 8 | 9 | このドキュメント群では、Project Sprintの基本的な概念の説明と実践方法が順を追って説明されます。理論編であるTheories及び実践編であるPracticesから成り、それぞれを上から順番に読み進めていくことで、Project Sprintを概念として理解した上で、実際のプロジェクトに取り入れて使うための知識を得ることができるようになっています。 10 | 11 | すでにプロジェクトマネジメントの経験がある方が新しい方法論としてProject Sprintをインプットするために読むことはもちろん、すでにProject Sprintを導入している方も、効果的な活用のための基盤固めとして読むことができます。 12 | 13 | ### [Essentials](essentials.md) 14 | 15 | Project Sprintの核となる行動規範がシンプルに述べられており、そこからProject Sprintが立脚する思想や価値観を理解することができます。Theoriesの通読後に改めてEssentialsをお読みいただくと、Project Sprintの最重要箇所をより把握しやすくなるでしょう。 16 | 17 | ### [Reference](reference.md) 18 | 19 | Project Sprintの背景にある諸メソッド・概念・文献について記載されており、Project Sprintの効率的な理解が可能になり、また今後のメソッドのアップデートに関わりそうな情報を知ることができます。さらに、背景を知ることでメソッドの応用も可能になります。 20 | 21 | ## **ドキュメントの比較表** 22 | 23 | |ドキュメント名|Theories|Practices|Essentials|Reference| 24 | |----|----|----|----|----| 25 | |記載内容|基本的な概念の説明と実践方法|具体的な実践方法|核となる行動規範|背景にある諸メソッド・概念・文献| 26 | |効果|理論体系としてのProject Sprintが理解できる|Project Sprintの具体的なノウハウが理解できる|Project Sprintが立脚する思想や価値観が理解できる|効率的なProject Sprintの理解、メソッドのアップデートに関わりそうな情報、応用のための知識が得られる| 27 | -------------------------------------------------------------------------------- /CODE/v3/.3_ja/README.md: -------------------------------------------------------------------------------- 1 | # v3.3 2 | 3 | ## **CODEとは** 4 | 5 | **CODE**とは、Project Sprintについて説明したドキュメント群の総称です。 6 | 7 | ### [Theories and Practices](theories_and_practices.md) 8 | 9 | このドキュメント群では、Project Sprintの基本的な概念の説明と実践方法が順を追って説明されます。理論編であるTheories及び実践編であるPracticesから成り、それぞれを上から順番に読み進めていくことで、Project Sprintを概念として理解した上で、実際のプロジェクトに取り入れて使うための知識を得ることができるようになっています。 10 | 11 | すでにプロジェクトマネジメントの経験がある方が新しい方法論としてProject Sprintをインプットするために読むことはもちろん、すでにProject Sprintを導入している方も、効果的な活用のための基盤固めとして読むことができます。 12 | 13 | ### [Essentials](essentials.md) 14 | 15 | Project Sprintの核となる行動規範がシンプルに述べられており、そこからProject Sprintが立脚する思想や価値観を理解することができます。Theoriesの通読後に改めてEssentialsをお読みいただくと、Project Sprintの最重要箇所をより把握しやすくなるでしょう。 16 | 17 | ### [Reference](reference.md) 18 | 19 | Project Sprintの背景にある諸メソッド・概念・文献について記載されており、Project Sprintの効率的な理解が可能になり、また今後のメソッドのアップデートに関わりそうな情報を知ることができます。さらに、背景を知ることでメソッドの応用も可能になります。 20 | 21 | ## **ドキュメントの比較表** 22 | 23 | |ドキュメント名|Theories|Practices|Essentials|Reference| 24 | |----|----|----|----|----| 25 | |記載内容|基本的な概念の説明と実践方法|具体的な実践方法|核となる行動規範|背景にある諸メソッド・概念・文献| 26 | |効果|理論体系としてのProject Sprintが理解できる|Project Sprintの具体的なノウハウが理解できる|Project Sprintが立脚する思想や価値観が理解できる|効率的なProject Sprintの理解、メソッドのアップデートに関わりそうな情報、応用のための知識が得られる| 27 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Project Sprint 2 | 3 |

4 | 5 |

6 | 7 |

8 | 【⚖️ Framework | 🌏 Definitions | 🚀 Introduction | 👪 Practical Guide | 📚 Release Note】 9 | 10 |

11 | 12 | ## 📍 Project Sprint とは 13 | 14 | Project Sprint は、定例会議を活用したプロジェクト推進のためのフレームワークです。本ドキュメントは、Project Sprint をオープンソースのメソッドとして公開しているものです。 15 | 16 | ▼ 現在の最新ドキュメント 17 | 18 | * [v4.3](CODE/v4/.3_ja/README.md) 19 | 20 | ## 🙆‍♂️ こんな方におすすめ 21 | 22 | Project Sprint は、「チームがプロジェクトを規定する」という価値観に基づいて構築されています。もしあなたが、従来の価値観によるプロジェクトの固定的な枠組みの中で何らかの不自由さを感じているのなら、Project Sprint はあなたをそこから解放する手助けができるかもしれません。 23 | 24 | * チームが主体として自由にプロジェクトを規定しつづけられるという価値観に共感する 25 | * 従来の予測型のプロジェクトにおける管理的・中央集権的なアプローチがうまくいっていない 26 | * 今までの自分のプロジェクトの進め方に迷いがあり、もっとよいやり方がないだろうかと悩んでいる 27 | 28 | そんな方はぜひ一度、Project Sprint がご案内する適応型のプロジェクトの世界へ飛び込んでみませんか？ 29 | 30 | ※Project Sprint におけるプロジェクトの捉え方について、さらに詳しくは[こちら](CODE/v4/.3/definitions.md)をご覧ください。 31 | 32 | -------------------------------------------------------------------------------- /CODE/v2/.2_ja/tutorial/1-2.md: -------------------------------------------------------------------------------- 1 | # チームメンバーを知り、ロールを設定する 2 | 3 | この記事の内容はプロジェクトスプリントにおける「チーミングドメイン」にあたります。 4 | 5 | チーミングの「理想の状態」とは、チームメンバー同士の果たすべき役割（これを、ロールと呼びます）についての期待値がそろっている状態です。言い換えると、あるチームメンバーが「あの人はこれをやってくれるだろう」と考えたとき、そのチームメンバーも「これは私がやるべきことだ」と考えている状態です。チーミングの「理想の状態」には、明確な形がありません。なぜなら「ここまで達成したら理想のチームだ！」というものが決めにくいからです。そこでプロジェクトスプリントでは、「今の時点よりは良いチームの状態」を常に目指します。 6 | 7 | ### **チームメンバーの基本情報** 8 | 9 | より良いチームを目指す前提となるのが、チームメンバーに関する理解です。例えば、プロジェクトにかかわるメンバーに次のことを確認しておきましょう。 10 | 11 | * メンバーの名前はなんですか？普段はどのような組織や会社に所属している人ですか？ 12 | * それぞれのメンバーは、どのような人ですか？例えばスキルセットは、どのようなものがありますか？これまでにどのような仕事にかかわってきましたか？ 13 | * それぞれのメンバーがプロジェクトに対して貢献すると期待されていることはなんですか？ 14 | * それぞれのメンバーは、プロジェクトに対する専任メンバーですか、兼任メンバーですか？いずれにせよ、各メンバーがプロジェクトに割ける時間はどのくらいですか？ 15 | 16 | こうしたことをプロジェクトの最初に知っておくことは、続くロールの設定における助けになります。 17 | 18 | ### **ロールの共有** 19 | 20 | プロジェクトスプリントでは、チームメンバー個々人の役割のことをロールと呼びます。ロールとチームメンバーは必ずしも一対一の関係である必要はありません。つまり、一人の人が複数のロールを担うこともありますし、またあるロールを複数の人が担うこともできます。 21 | 22 | また、定義するロールの個数には制限がありませんし、「必ず定義すべきロール」というものもありません。プロジェクトの性質に応じて、必要な役割分担をチームメンバーで議論し、ロールとして明文化しましょう。 23 | 24 | **このページと関係するTips** 25 | 26 | * [実務で使いやすいロールの設定](../tips/1-5.md) 27 | * [ロールシートの利用](../tips/4-2.md) 28 | * [プロジェクトの環境整備](../tips/1-1.md) 29 | * [ロールの分類と性質](../tips/1-6.md) 30 | -------------------------------------------------------------------------------- /CODE/v3/.2_ja/practices/project_environments.md: -------------------------------------------------------------------------------- 1 | # 情報共有環境の構築 2 | 3 | チーム全体で情報の透明性を最大限に高める環境を実現するため、「ここにアクセスすればすべての情報に辿りつくことができる」という状態をつくります。プロジェクトメンバーは、すべての情報、すべてのメンバー間のやりとりに、いつでもどこからでもアクセス可能にしておきます。 4 | 5 | すべての情報を全員が閲覧でき、同時・共同編集が可能にしておくことも重要です。 6 | 7 | * **ミーティング・アジェンダ**: プロジェクトメンバー全員がミーティングの目的やアジェンダの内容を知ることができるようにしましょう。 8 | * **マイルストーン**: プロジェクトメンバー全員が最新のマイルストーンに常にアクセスできる必要があります。マイルストーンを常に意識することで、逸脱や問題を早期に検知して対応することができます。 9 | * **議事録**: ミーティング中、作成途中の議事録をリアルタイムで全員が閲覧できるようにしておきましょう。認識のずれを合わせるのに効果的です。 10 | 11 | * **ファイル共有**: プロジェクトメンバー全員が同じ情報にアクセスできるよう、ファイルの共有場所を用意しましょう。 12 | * **スケジュール共有**: スケジュール調整に必要な限りで、メンバー間の個人カレンダーを共有するようにしましょう。これは、メールなどによって都度日程調整をするのではなく、チームメンバーのスケジュール状況が一か所に集まっており、ミーティングのスケジュールを効率的に設定・変更できるようになることを意味します。 13 | * **タスク共有**: プロジェクトを通じて生まれるタスクを共有できる場所を用意しましょう。個人でタスク管理するのではなく、プロジェクトチームで共有のタスク置き場を用意することで、お互いが何をするべきか / するつもりだったか、を確認するコミュニケーションがしやすくなります。 14 | 15 | これらは一般的なプロジェクトマネジメントで語られる要素と大きく異なりません。しかし、Project Sprintでは、それらの要素すべてにおいて、「情報の透明性をいかに担保するか」という点を中心に考えるべきです。 16 | 17 | Project Sprintでは、プロジェクトのゴールやマイルストーンの設定、ロールの設定と調整をはじめ、様々なタイミングで「チームメンバーの納得を伴った合意」をつくることが必要になります。そのため、納得をつくるため = チームメンバーの情報格差をなくすためにはどういったプロジェクト環境を用意するべきか、というポイントが重要視されるのです。 18 | 19 | なお、ここに書いている要素は一例に過ぎません。プロジェクトごとに、チームメンバー間で最も最適なプロジェクト環境を整備していくように話し合うこともまた重要です。 20 | -------------------------------------------------------------------------------- /CODE/v3/.3_ja/practices/project_environments.md: -------------------------------------------------------------------------------- 1 | # 情報共有環境の構築 2 | 3 | チーム全体で情報の透明性を最大限に高める環境を実現するため、「ここにアクセスすればすべての情報に辿りつくことができる」という状態をつくります。プロジェクトメンバーは、すべての情報、すべてのメンバー間のやりとりに、いつでもどこからでもアクセス可能にしておきます。 4 | 5 | すべての情報を全員が閲覧でき、同時・共同編集が可能にしておくことも重要です。 6 | 7 | * **ミーティング・アジェンダ**: プロジェクトメンバー全員がミーティングの目的やアジェンダの内容を知ることができるようにしましょう。 8 | * **マイルストーン**: プロジェクトメンバー全員が最新のマイルストーンに常にアクセスできる必要があります。マイルストーンを常に意識することで、逸脱や問題を早期に検知して対応することができます。 9 | * **議事録**: ミーティング中、作成途中の議事録をリアルタイムで全員が閲覧できるようにしておきましょう。認識のずれを合わせるのに効果的です。 10 | 11 | * **ファイル共有**: プロジェクトメンバー全員が同じ情報にアクセスできるよう、ファイルの共有場所を用意しましょう。 12 | * **スケジュール共有**: スケジュール調整に必要な限りで、メンバー間の個人カレンダーを共有するようにしましょう。これは、メールなどによって都度日程調整をするのではなく、チームメンバーのスケジュール状況が一か所に集まっており、ミーティングのスケジュールを効率的に設定・変更できるようになることを意味します。 13 | * **タスク共有**: プロジェクトを通じて生まれるタスクを共有できる場所を用意しましょう。個人でタスク管理するのではなく、プロジェクトチームで共有のタスク置き場を用意することで、お互いが何をするべきか / するつもりだったか、を確認するコミュニケーションがしやすくなります。 14 | 15 | これらは一般的なプロジェクトマネジメントで語られる要素と大きく異なりません。しかし、Project Sprintでは、それらの要素すべてにおいて、「情報の透明性をいかに担保するか」という点を中心に考えるべきです。 16 | 17 | Project Sprintでは、プロジェクトのゴールやマイルストーンの設定、ロールの設定と調整をはじめ、様々なタイミングで「チームメンバーの納得を伴った合意」をつくることが必要になります。そのため、納得をつくるため = チームメンバーの情報格差をなくすためにはどういったプロジェクト環境を用意するべきか、というポイントが重要視されるのです。 18 | 19 | なお、ここに書いている要素は一例に過ぎません。プロジェクトごとに、チームメンバー間で最も最適なプロジェクト環境を整備していくように話し合うこともまた重要です。 20 | -------------------------------------------------------------------------------- /practical-guide/CODEv4_based/minimum_guide.md: -------------------------------------------------------------------------------- 1 | # Project Sprint Minimum Guide 2 | 3 | このページでは、Project Sprint を実際に体験するために必要な最小限の具体的な行動を記載しています。まずはこれらの行動を実践し、その上で「会議がうまく進んだ」「プロジェクトがよりよくなった」と感じた方は、ぜひ[ビジュアル版・プラクティカルガイド](https://miro.com/app/board/uXjVMX-zl6s=/)や[CODE](../../CODE/README.md)で、Project Sprint の原理を読み進め、さらなる実践へ繋げてください。 4 | 5 | ## Project Sprint の実践に必要な具体的な行動 6 | - チーム全員で定例会議を実行する 7 | - 各メンバーが作成物を出力する 8 | - 上記2つを短いサイクルで繰り返す 9 | 10 | これらの行動を習慣化することにより、 11 | - 定例会議の終了時点で各メンバーが次に取るべき行動を自己決定し納得できている 12 | - プロジェクト推進の根幹である作成物が生み出されつづけている 13 | 14 | という状態を実現したい。 15 | 16 | これらの行動習慣は、納得をつくり期待を揃えるために存在する。 17 | 納得には、大きく分けて以下の3種類がある。これらを順につくっていくのが毎回の定例会議の役割である。 18 | - 現状への納得 19 | - 各メンバーが把握している状況を統合して解釈・意味づけし、チーム全員の現状認識を合わせる 20 | - 達成されるべきことへの納得 21 | - 現状を踏まえ、このプロジェクトにおける直近のジョブをチームで決定する 22 | - 次のアクションへの納得 23 | - 直近のジョブを踏まえ、各メンバーが次のアクションを宣言する 24 | - 宣言されたアクションがチームの期待から逸脱していないか確認し、アクション同士の重複や過剰な依存関係がないようチーム全員でチューニングする 25 | - そのアクションを遂行するメンバーが、アクションの方向と方法に納得する 26 | 27 | ## やるべきことまとめ 28 | - **定例会議を設定する** 29 | = 次の会議に向けてチーム全員が準備できる状態をつくる 30 | - **目指すところを明確にする** 31 | = 次の会議（日時、アジェンダの置き場所とテンプレート、進め方のフレーム、役割）を決定して誰もが分かる状態にしておき、チーム全員がそこを目掛けた行動を取りやすいようにしておく 32 | = 先々の会議のことまで決めておく必要はなく、直近の会議のみが明確化されていればよい 33 | - **アクションを明確にする** 34 | = 次の会議までにチーム全員が必ず作成物を出力し、進捗と気づきを定例会議で共有できるようにする 35 | = 定例会議の中で、「現状・達成されるべきこと・次のアクション」にチーム全員で納得しておく必要がある 36 | -------------------------------------------------------------------------------- /CODE/v2/.0_en/tips/tips8.md: -------------------------------------------------------------------------------- 1 | # Tips8: All Elements that Should be Included in the Agenda 2 | 3 | As discussed [in Preparing for a meeting](../tutorial/2-1.md), meeting agenda should include the following elements 4 | 5 | * Name of Agenda 6 | * How to proceed (a specific image of how the discussion will proceed) 7 | * Purpose and background (why you want to discuss the agenda) 8 | * Who to whom (who owns the agenda and with whom you want to discuss it) 9 | * Time 10 | 11 | These are the information necessary for the agenda owner to clarify what they want to discuss, but in addition to this, clarifying to what extent they want to discuss it will make the discussion easier. 12 | 13 | Specifically, the following additional elements should be included. 14 | 15 | * Desired state (the state you want to achieve after discussing the agenda) 16 | * Result (the explicit output that is produced when the discussion is over) 17 | * The means by which the participants will prove that they are satisfied with the completion of the agenda 18 | 19 | The more each of these elements is clear in advance, the more efficient and effective the discussion will be. If any of these elements are difficult to describe by the agenda owner alone or difficult to understand by other team members, the facilitator's (accelerator's) role is to make them easier to understand and to organize the discussion so that these elements can be realized. 20 | -------------------------------------------------------------------------------- /CODE/v2/.2_ja/tutorial/3-2.md: -------------------------------------------------------------------------------- 1 | # プロジェクトのゴールとマイルストーンを見直す 2 | 3 | この記事の内容はプロジェクトスプリントにおける「プログレスドメイン」にあたります。 4 | 5 | プロセスは定期開催のミーティングとそこでのアジェンダの議論を軸としたプロジェクトスプリント固有の仕組みです。この仕組みを通じてプロジェクトの進捗状況の共有、プロジェクトの進め方の継続的な改善・プロジェクトのゴールに向けたマイルストーンの見直しや互いのロールの確認をすることができるようになります。 6 | 7 | この記事では、プロジェクトのゴールとマイルストーンの見直しについて解説します。 8 | 9 | ### **マイルストーンの見直し** 10 | 11 | [プロジェクトのゴールとマイルストーンを設定する](1-1.md)でも述べたように、マイルストーンやプロジェクトのゴールは変えてもよいものです。プロジェクトを取り巻く環境の変化や実際にタスクをこなしていくなかでわかってきたことを踏まえて、マイルストーンやゴールはプロジェクト中にいつでも変更が可能です。 12 | 13 | マイルストーンの見直しをするべきタイミングは、次のようなときです。 14 | 15 | 1. あるマイルストーンが達成されたとき 16 | 2. あるマイルストーンが予定通りに達成されないことが明らかになったとき（予定よりも遅い場合、早い場合のいずれも含む） 17 | 3. プロジェクトのゴールに対してあるマイルストーンが適切ではないことが明らかになったとき 18 | 4. プロジェクトのゴールが変わったためマイルストーンも変える必要が出てきたとき 19 | 5. その他何らかの理由でチームメンバーがマイルストーンを見直したほうがよいと考えたとき 20 | 21 | ### プロジェクトゴールの見直し 22 | 23 | プロジェクトのゴールの見直しをするべきタイミングは、次のようなときです。 24 | 25 | 1. プロジェクトが進行した結果プロジェクトのゴールそのものを見直したほうが良いことが分かったとき 26 | 2. マイルストーンが予定通りに達成されなかった結果、プロジェクトのゴールを見直したほうが良いことがわかったとき 27 | 3. その他何らかの理由でチームメンバーがプロジェクトのゴールを見直したほうがよいと考えたとき 28 | 29 | マイルストーンやプロジェクトのゴールの見直しの実施についてもミーティングのアジェンダアイテムとなるため、事前にアジェンダアイテムの提出を行う必要があります。 30 | 31 | マイルストーンを変更する際には、変更の前後を並べて見せるなど、その差分を明確にし、積極的に共有するようにしてください。これは、「知らない間にマイルストーンが変わっていた」と感じるメンバーが出てきてしまわないようにするためです。マイルストーンはプロジェクトにおけるあらゆる場面で参照され、チームメンバーにとって指針となるべきものです。そのため、変更後のマイルストーンにもチームメンバー全員が確実に納得できている状態をつくってください。 32 | 33 | **このページと関係するTips** 34 | 35 | * [マイルストーンマップの利用](../tips/2-1.md) 36 | -------------------------------------------------------------------------------- /CODE/v3/.0_ja/reference.md: -------------------------------------------------------------------------------- 1 | # Reference 2 | 3 | このドキュメントは、Project Sprintの背景にある諸メソッド・概念・文献について記載しています。 4 | 5 | Project Sprintは、以下の理論・メソッド・文献・概念を参考にしながら、様々なプロジェクトで実践した経験則をもとに独立したメソッドとしてまとめられています。 6 | 7 | ### Manifesto for Agile Software Development 8 | 9 | アジャイルソフトウェア開発宣言と12の原則の価値に共感しています。\ 10 | [https://agilemanifesto.org/](https://agilemanifesto.org) 11 | 12 | ### **Scrum & Scrum@Scale** 13 | 14 | スプリントという短期間に反復的な実践により成果物を提供する概念、透明性や自己組織化という概念、ミーティングによる認識合わせや意思決定をプロセスの中心におくこと、レトロスペクティブ(振り返り)のプロセスなどを参考にしています。\ 15 | Project Sprint という名称は Scrum のスプリントからインスピレーションを得ています。\ 16 | [https://www.scrumguides.org/](https://www.scrumguides.org) 17 | 18 | ### ティール組織 19 | 20 | セルフマネジメントや進化する目的の概念に共感しています。\ 21 | [https://www.reinventingorganizations.com/](https://www.reinventingorganizations.com) 22 | 23 | ### **Holacracy** 24 | 25 | チーミング・アクティビティでコアの要素となっているロールとテンションやその関係性は、ホラクラシーの考え方を参考にしています。\ 26 | [https://www.holacracy.org/](https://www.holacracy.org) 27 | 28 | ### 心理的安全性 29 | 30 | エイミー・エドモンドソンにより提唱された概念です。チームのなかでどのような発言でも大丈夫だと信じられている環境をつくる重要性に共感しています。\ 31 | Googleが行った生産性の高いチームの調査プロジェクトにより注目が集まりました。\ 32 | [https://www.jstor.org/stable/2666999](https://www.jstor.org/stable/2666999) 33 | 34 | Google re:Work\ 35 | [https://rework.withgoogle.com/jp/guides/understanding-team-effectiveness/](https://rework.withgoogle.com/jp/guides/understanding-team-effectiveness/) 36 | 37 | ### センスメイキング理論 38 | 39 | カール・ワイクを中心に発展されている理論です。正確性よりもチームの納得に重きを置いている考え方に共感しています。 40 | -------------------------------------------------------------------------------- /CODE/v3/.1_ja/reference.md: -------------------------------------------------------------------------------- 1 | # Reference 2 | 3 | このドキュメントは、Project Sprintの背景にある諸メソッド・概念・文献について記載しています。 4 | 5 | Project Sprintは、以下の理論・メソッド・文献・概念を参考にしながら、様々なプロジェクトで実践した経験則をもとに独立したメソッドとしてまとめられています。 6 | 7 | ### Manifesto for Agile Software Development 8 | 9 | アジャイルソフトウェア開発宣言と12の原則の価値に共感しています。\ 10 | [https://agilemanifesto.org/](https://agilemanifesto.org) 11 | 12 | ### **Scrum & Scrum@Scale** 13 | 14 | スプリントという短期間に反復的な実践により成果物を提供する概念、透明性や自己組織化という概念、ミーティングによる認識合わせや意思決定をプロセスの中心におくこと、レトロスペクティブ(振り返り)のプロセスなどを参考にしています。\ 15 | Project Sprint という名称は Scrum のスプリントからインスピレーションを得ています。\ 16 | [https://www.scrumguides.org/](https://www.scrumguides.org) 17 | 18 | ### ティール組織 19 | 20 | セルフマネジメントや進化する目的の概念に共感しています。\ 21 | [https://www.reinventingorganizations.com/](https://www.reinventingorganizations.com) 22 | 23 | ### **Holacracy** 24 | 25 | チーミング・アクティビティでコアの要素となっているロールとテンションやその関係性は、ホラクラシーの考え方を参考にしています。\ 26 | [https://www.holacracy.org/](https://www.holacracy.org) 27 | 28 | ### 心理的安全性 29 | 30 | エイミー・エドモンドソンにより提唱された概念です。チームのなかでどのような発言でも大丈夫だと信じられている環境をつくる重要性に共感しています。\ 31 | Googleが行った生産性の高いチームの調査プロジェクトにより注目が集まりました。\ 32 | [https://www.jstor.org/stable/2666999](https://www.jstor.org/stable/2666999) 33 | 34 | Google re:Work\ 35 | [https://rework.withgoogle.com/jp/guides/understanding-team-effectiveness/](https://rework.withgoogle.com/jp/guides/understanding-team-effectiveness/) 36 | 37 | ### センスメイキング理論 38 | 39 | カール・ワイクを中心に発展されている理論です。正確性よりもチームの納得に重きを置いている考え方に共感しています。 40 | -------------------------------------------------------------------------------- /CODE/v3/.2_ja/reference.md: -------------------------------------------------------------------------------- 1 | # Reference 2 | 3 | このドキュメントは、Project Sprintの背景にある諸メソッド・概念・文献について記載しています。 4 | 5 | Project Sprintは、以下の理論・メソッド・文献・概念を参考にしながら、様々なプロジェクトで実践した経験則をもとに独立したメソッドとしてまとめられています。 6 | 7 | ### Manifesto for Agile Software Development 8 | 9 | アジャイルソフトウェア開発宣言と12の原則の価値に共感しています。\ 10 | [https://agilemanifesto.org/](https://agilemanifesto.org) 11 | 12 | ### **Scrum & Scrum@Scale** 13 | 14 | スプリントという短期間に反復的な実践により成果物を提供する概念、透明性や自己組織化という概念、ミーティングによる認識合わせや意思決定をプロセスの中心におくこと、レトロスペクティブ(振り返り)のプロセスなどを参考にしています。\ 15 | Project Sprint という名称は Scrum のスプリントからインスピレーションを得ています。\ 16 | [https://www.scrumguides.org/](https://www.scrumguides.org) 17 | 18 | ### ティール組織 19 | 20 | セルフマネジメントや進化する目的の概念に共感しています。\ 21 | [https://www.reinventingorganizations.com/](https://www.reinventingorganizations.com) 22 | 23 | ### **Holacracy** 24 | 25 | チーミング・アクティビティでコアの要素となっているロールとテンションやその関係性は、ホラクラシーの考え方を参考にしています。\ 26 | [https://www.holacracy.org/](https://www.holacracy.org) 27 | 28 | ### 心理的安全性 29 | 30 | エイミー・エドモンドソンにより提唱された概念です。チームのなかでどのような発言でも大丈夫だと信じられている環境をつくる重要性に共感しています。\ 31 | Googleが行った生産性の高いチームの調査プロジェクトにより注目が集まりました。\ 32 | [https://www.jstor.org/stable/2666999](https://www.jstor.org/stable/2666999) 33 | 34 | Google re:Work\ 35 | [https://rework.withgoogle.com/jp/guides/understanding-team-effectiveness/](https://rework.withgoogle.com/jp/guides/understanding-team-effectiveness/) 36 | 37 | ### センスメイキング理論 38 | 39 | カール・ワイクを中心に発展されている理論です。正確性よりもチームの納得に重きを置いている考え方に共感しています。 40 | -------------------------------------------------------------------------------- /CODE/v3/.3_ja/reference.md: -------------------------------------------------------------------------------- 1 | # Reference 2 | 3 | このドキュメントは、Project Sprintの背景にある諸メソッド・概念・文献について記載しています。 4 | 5 | Project Sprintは、以下の理論・メソッド・文献・概念を参考にしながら、様々なプロジェクトで実践した経験則をもとに独立したメソッドとしてまとめられています。 6 | 7 | ### Manifesto for Agile Software Development 8 | 9 | アジャイルソフトウェア開発宣言と12の原則の価値に共感しています。\ 10 | [https://agilemanifesto.org/](https://agilemanifesto.org) 11 | 12 | ### **Scrum & Scrum@Scale** 13 | 14 | スプリントという短期間に反復的な実践により成果物を提供する概念、透明性や自己組織化という概念、ミーティングによる認識合わせや意思決定をプロセスの中心におくこと、レトロスペクティブ(振り返り)のプロセスなどを参考にしています。\ 15 | Project Sprint という名称は Scrum のスプリントからインスピレーションを得ています。\ 16 | [https://www.scrumguides.org/](https://www.scrumguides.org) 17 | 18 | ### ティール組織 19 | 20 | セルフマネジメントや進化する目的の概念に共感しています。\ 21 | [https://www.reinventingorganizations.com/](https://www.reinventingorganizations.com) 22 | 23 | ### **Holacracy** 24 | 25 | チーミング・アクティビティでコアの要素となっているロールとテンションやその関係性は、ホラクラシーの考え方を参考にしています。\ 26 | [https://www.holacracy.org/](https://www.holacracy.org) 27 | 28 | ### 心理的安全性 29 | 30 | エイミー・エドモンドソンにより提唱された概念です。チームのなかでどのような発言でも大丈夫だと信じられている環境をつくる重要性に共感しています。\ 31 | Googleが行った生産性の高いチームの調査プロジェクトにより注目が集まりました。\ 32 | [https://www.jstor.org/stable/2666999](https://www.jstor.org/stable/2666999) 33 | 34 | Google re:Work\ 35 | [https://rework.withgoogle.com/jp/guides/understanding-team-effectiveness/](https://rework.withgoogle.com/jp/guides/understanding-team-effectiveness/) 36 | 37 | ### センスメイキング理論 38 | 39 | カール・ワイクを中心に発展されている理論です。正確性よりもチームの納得に重きを置いている考え方に共感しています。 40 | -------------------------------------------------------------------------------- /CODE/v2/.2_ja/reference.md: -------------------------------------------------------------------------------- 1 | # Reference 2 | 3 | このドキュメントは、プロジェクトスプリントプロジェクトスプリントの背景にある諸メソッド・概念・文献について記載しています。 4 | 5 | プロジェクトスプリントは、以下の理論・メソッド・文献・概念を参考にしながら、様々なプロジェクトで実践した経験則をもとに独立したメソッドとしてまとめられています。 6 | 7 | ### Manifesto for Agile Software Development 8 | 9 | アジャイルソフトウェア開発宣言と12の原則の価値に共感しています。\ 10 | [https://agilemanifesto.org/](https://agilemanifesto.org) 11 | 12 | ### **Scrum & Scrum@Scale** 13 | 14 | スプリントという短期間に反復的な実践により成果物を提供する概念、透明性や自己組織化という概念、ミーティングによる認識合わせや意思決定をプロセスの中心におくこと、レトロスペクティブ(振り返り)のプロセスなどを参考にしています。\ 15 | Project Sprint という名称は Scrum のスプリントからインスピレーションを得ています。\ 16 | [https://www.scrumguides.org/](https://www.scrumguides.org) 17 | 18 | ### ティール組織 19 | 20 | セルフマネジメントや進化する目的の概念に共感しています。\ 21 | [https://www.reinventingorganizations.com/](https://www.reinventingorganizations.com) 22 | 23 | ### **Holacracy** 24 | 25 | チーミング・アクティビティでコアの要素となっているロールとテンションやその関係性は、ホラクラシーの考え方を参考にしています。\ 26 | [https://www.holacracy.org/](https://www.holacracy.org) 27 | 28 | ### 心理的安全性 29 | 30 | エイミー・エドモンドソンにより提唱された概念です。チームのなかでどのような発言でも大丈夫だと信じられている環境をつくる重要性に共感しています。\ 31 | Googleが行った生産性の高いチームの調査プロジェクトにより注目が集まりました。\ 32 | [https://www.jstor.org/stable/2666999](https://www.jstor.org/stable/2666999) 33 | 34 | Google re:Work\ 35 | [https://rework.withgoogle.com/jp/guides/understanding-team-effectiveness/](https://rework.withgoogle.com/jp/guides/understanding-team-effectiveness/) 36 | 37 | ### センスメイキング理論 38 | 39 | カール・ワイクを中心に発展されている理論です。正確性よりもチームの納得に重きを置いている考え方に共感しています。 40 | -------------------------------------------------------------------------------- /CODE/v2/.2_ja/tutorial/project-sprint-101.md: -------------------------------------------------------------------------------- 1 | # Project Sprint 101 2 | 3 | この記事では、プロジェクトスプリントの概要を説明し、「準備しよう」「やってみよう」「改善しよう」における個別のドキュメントの内容を理解しやすくします。 4 | 5 | プロジェクトスプリントとは、多様性のあるメンバーが、不確実性の高い環境や状況でも複雑なアウトプットを可能にするための「プロジェクト推進メソッド」です。 6 | 7 | プロジェクトスプリントでは、プロジェクトを推進するための活動を3つに分けて考えます。 8 | 9 | **プロジェクトスプリント概念図** 10 | 11 | ![Project Sprint CODE Essentialsより引用）](../images/essentials.png) 12 | 13 | * プログレス：プロジェクトの成果物やゴールにフォーカスした活動 14 | * プロセス：プロジェクトを推進させるための手続きにフォーカスした活動 15 | * チーミング：チームメンバーの関係性にフォーカスした活動 16 | 17 | プロジェクトスプリントの基本のメカニズムは「プロセスによって、プログレスとチーミングを理想の状態にする」というものです。では、プログレスとチーミングの「理想の状態」とはいったいどういうものなのでしょうか？ 18 | 19 | プログレスの「理想の状態」とは、プロジェクトのゴールが達成されている状態です。そのため、まずは将来達成したいプロジェクトのゴールを定義します。そして、そのために必要な成果物と、成果物をつくっていくための道のり（これを、マイルストーンと呼びます）を設定し、これを辿っていきます。ただし、プロジェクトのゴールやマイルストーンは絶対のものではなく、むしろ環境の変化に応じて柔軟に変わっていくものなので、常に見直してよいものだと考えておく必要があります。 20 | 21 | 一方チーミングの「理想の状態」とは、チームメンバー同士の果たすべき役割（これを、ロールと呼びます）についての期待値がそろっている状態です。言い換えると、あるチームメンバーが「あの人はこれをやってくれるだろう」と考えたとき、そのチームメンバーも「これは私がやるべきことだ」と考えている状態です。チーミングの「理想の状態」には、明確な形がありません。なぜなら「ここまで達成したら理想のチームだ！」というものが決めにくいからです。そこでプロジェクトスプリントでは、「今の時点よりは良いチームの状態」を常に目指します。 22 | 23 | プログレスとチーミングの理想の状態を実現するためのものが「プロセス」です。 24 | 25 | プロセスは定期開催のミーティングとそこでのアジェンダの議論を軸としています。 26 | 27 | プロジェクトスプリントでは、ミーティングを、「チームメンバー全員が空間や時間を共有し、素早く効率的な認識合わせと、全員が納得した意思決定をする場」として、またアジェンダを「プロジェクトにおけるチームメンバーの活動を、他のメンバーと共有・認識してもらうために明文化されたもの」として位置付けています。 28 | 29 | これらを通じてプロジェクトの進捗状況の共有・プロジェクトの進め方の継続的な改善・プロジェクトのゴールに向けたマイルストーンの見直しや互いのロールの確認をすることができるようになります。 30 | -------------------------------------------------------------------------------- /CODE/v2/.2_ja/tips/1-3.md: -------------------------------------------------------------------------------- 1 | # チームが納得できて作業効率のよいタスクの設定方法 2 | 3 | プロジェクトスプリントには、ミーティング終盤にそのミーティングを通じて生まれたタスクの確認を行い、次回のミーティングの序盤でそれまでのタスクの進捗報告を行うというサイクルがあります。 [ミーティングを開催する](../tutorial/2-2.md)で解説したように、タスクを記載する際には、 4 | 5 | * 具体的な行動内容 6 | * 担当者 7 | * 期限 8 | 9 | を明確にすることが最低限必要です。 10 | 11 | しかし、これだけでは、タスクの進捗報告の際に「想定していたのと違った」「いつまでたっても完了しない」といったことが起こりえます。これは、タスクの担当者が何をやればよいかよくわかっていないことが原因であったり、そもそも担当者の設定や期限の設定が間違っていたりすることが原因です。そして、さらにその根本的な原因は、チームメンバ―の間で認識のずれがあり、正しくタスクが定義できてないことにあります。 12 | 13 | そこで、次の要素についてもあわせて検討し明文化することで、そうした認識ずれをあらかじめ防ぐことができます。 14 | 15 | **目的** 16 | 17 | なぜこのタスクを行う必要があるのかについての記述です。 18 | 19 | タスクは最終的にはプログレスにおける理想の状態（プロジェクトのゴールやマイルストーンの達成）またはチーミングの理想の状態（ロールの期待値がそろっている状態）につながるため、そのためにそれぞれのタスクがどのように結びついているかを意識しながら目的を書き下すことが有効です。 20 | 21 | 目的を記載することで、誰がやるべきか（担当者）や、いつまでにやるべきか（期限）も簡単に判断することができます。 22 | 23 | **想定アウトプット・想定作業時間** 24 | 25 | タスクをこなした結果生まれるアウトプットについての具体的イメージの記述です。なお、アウトプットとは、チームメンバーが割り当てられたタスクを完了したことで生まれた結果のことです（Tips3参照）。 26 | 27 | 例えば、ある資料作成のタスクがあったとき、「スライド～～枚で、見出しはしっかりと作りこむ。本文や記載する図表はダミーでよい」と記述することで、目的に沿ったアウトプットなのかどうかを確認しやすくなります。この場合、タスクの目的が「プレゼンテーション直前のリハーサルに使うため」であればアウトプットとしては不十分でしょうし、「プレゼンテーションの大枠の内容を内々に議論するため」であれば、必要十分なアウトプットになるでしょう。目的が達成できるのであれば、必ずしも完成度を突き詰める必要はありません。それよりも、最小限のアウトプットを確実につくることを意識しましょう。 28 | 29 | また、想定アウトプットのイメージをすり合わせるためには、タスクを終えるまでの想定作業時間を明文化することも効果的です。前述の資料作成のタスクであれば、ある人は1時間しかかからないと思っていた作業が、別の人は4時間もかかると思っていた場合、作りこみのレベルに差がある可能性が高いということが分かります。 30 | 31 | さらに、これらの作業を通じてタスクの粒度が大きいと判断された場合は、そのタスクを細かく分解し、ミーティングごとに確実にアウトプットが可能なサイズにしましょう。 32 | -------------------------------------------------------------------------------- /CODE/v3/.1_ja/tutorial/section2-2-2.md: -------------------------------------------------------------------------------- 1 | # トラック：プロジェクト遂行の単位 2 | 3 | ## トラックとは 4 | 5 | トラックとは、それぞれが強い依存関係を持たず、設定した役割や目標に沿って自律自走できるプロジェクト内の単位です。 6 | 7 | [Project Sprint 101](section1-1.md)で説明したように、Project Sprintではプロジェクトを「全体」の達成に寄与するひとつの「部分」として捉えます。トラックも同様に、プロジェクトという全体の達成に必要なそれぞれの部分といえます。プロジェクトゴール達成を目指す過程を、それぞれが強い依存関係を持たず自律的に作業を進めることができる単位にまでブレイクダウンしたものを、トラックと呼びます。 8 | 9 | プロジェクト全体の状態を把握するためのメインのトラックをまず設定してマイルストーンを置き、そのマイルストーンを達成するために必要なものを要素ごとに分割することで、その他のトラックが置かれます。トラック同士は、依存関係が少ない疎結合な状態になるように分割します。トラック同士の依存関係は、個々のトラックの自律的な動きの妨げとなるからです。 10 | 11 | プロジェクトの構想期はまだプロジェクトゴールが明確化されていないため、トラックへのブレイクダウンも進まないことが多いでしょう。その後の形成期や自律準備期において、プロジェクトゴールやマイルストーン、必要な成果物などが明確になってくるにつれて、トラックの分割が進みます。 12 | 13 | ## トラックのライフサイクル 14 | 15 | [プロジェクトライフサイクル](section2-0.md)の考え方は、トラックにも適用できます。トラックの構想期においては、「このようなトラックが必要だろう」という仮説を立て、チームメンバーを決めます。この段階ではマイルストーンが置かれておらず、定例ミーティングのみのトラックになるかもしれません。その後トラックゴールやマイルストーンを明文化するのがトラックの形成期、定例ミーティングや他のトラックとの連携を設定するのがトラックの自律準備期に当たります。 16 | 17 | 自律準備期までは、他のトラックとの境界が曖昧なことも多くあります。また、自律推進期に入ってからも、環境の変化に伴い他トラックとの相互依存関係が密になり、自律的な推進が難しくなることもあるでしょう。その場合には、一旦自律準備期に戻ったと捉えて情報や体制を整理し、改めて定期的な同期・連携による一定程度予測可能な相互作用のみでそれぞれが自律的に動ける状態に近づけていきます。 18 | 19 | ## トラックの分割例 20 | 21 | 例えば、あるWebサイトを立ち上げるプロジェクトを考えたとき（プロジェクトゴールは「Webサイトの完成」）、Webサイトのデザインを考えるチームと、Webサイトのシステム環境を整える作業は、一定程度関連はしながらも並行して進行します。このとき、それぞれの作業領域をトラックとして分割し、トラックごとにマイルストーンを分けて考えることで、よりプロジェクトを構造化して捉えられるようになります。 22 | 23 | 上述のWebサイトの例のようなトラック分割だけでなく、営業・マーケティング・CSといったロールベースでのトラック分割や、プロダクトごと・機能ごとのトラック分割など、プロジェクトの性質や規模によって、設定されるトラックは様々です。 24 | -------------------------------------------------------------------------------- /CODE/v2/.0_en/tips/tips14.md: -------------------------------------------------------------------------------- 1 | # Tips14: The Purpose of an Agenda 2 | 3 | As mentioned in [Project Sprint 101](../tutorial/project-sprint-101.md), an agenda in a Project Sprint is "a clear statement of a team member's activities in a project that is shared and recognized by other team members. And how to create a specific agenda is explained in[ Preparing for a meeting](../tutorial/2-1.md) and [All elements that should be included in the agenda](tips8.md). 4 | 5 | In this article, we will discuss the purpose of an agenda in order to understand it more deeply. Agendas can be divided into three types, depending on the purpose of the discussion 6 | 7 | * Divergence: When a wide range of options emerge through the discussion. 8 | * Convergence: When a number of options are narrowed down to a single option through discussion. 9 | * Sharing: When you want to share information or confirm assumptions. 10 | 11 | By indicating in advance which category the agenda will fall into, meeting participants can understand from which perspective and what they should say. For example, if the agenda is a "divergent" agenda, people can freely express their opinions, and it is important to come up with new ideas. On the other hand, if the agenda is "convergent," it is necessary to draw realistic conclusions about what kind of output should be produced in order to achieve the milestone. In addition, if the agenda is for "sharing," it is important to ask questions and make sure that everyone is on the same page as much as possible. 12 | -------------------------------------------------------------------------------- /CODE/v3/.2_ja/practices/tasks.md: -------------------------------------------------------------------------------- 1 | # タスクの設定 2 | 3 | Project Sprintには、ミーティング終盤にそのミーティングを通じて生まれたタスクの確認を行い、次回のミーティングの序盤でそれまでのタスクの進捗報告を行うというサイクルがあります。 [ミーティングを開催する](holding_meetings.md)で解説したように、タスクを記載する際には、 4 | 5 | * 具体的な行動内容 6 | * 担当者 7 | * 期限 8 | 9 | を明確にすることが最低限必要です。 10 | 11 | しかし、これだけでは、タスクの進捗報告の際に「想定していたのと違った」「いつまでたっても完了しない」といったことが起こりえます。これは、タスクの担当者が何をやればよいかよくわかっていないことが原因であったり、そもそも担当者の設定や期限の設定が間違っていたりすることが原因です。そして、さらにその根本的な原因は、チームメンバ―の間で認識のずれがあり、正しくタスクが定義できてないことにあります。 12 | 13 | そこで、次の要素についてもあわせて検討し明文化することで、そうした認識ずれをあらかじめ防ぐことができます。 14 | 15 | ## 目的 16 | 17 | なぜこのタスクを行う必要があるのかについての記述です。 18 | 19 | タスクはプロジェクトゴールとして設定された成果物・成果に漸進的に近づくためのものです。また、タスクを遂行する中で他のメンバーに伝えたい問題点や違和感（**テンション**）が生まれ、プロジェクトを最適化するための材料となります。そのためにそれぞれのタスクがプロジェクトゴールにどのように結びついているかを意識しながら目的を明文化することが有効です。 20 | 21 | 目的を記載することで、誰がやるべきか（担当者）や、いつまでにやるべきか（期限）も簡単に判断することができます。 22 | 23 | ## 想定アウトプット・想定作業時間 24 | 25 | タスクをこなした結果生まれるアウトプットについての具体的イメージの記述です。なお、アウトプットとは、チームメンバーが割り当てられたタスクを完了したことで生まれた結果のことです（Tips3参照）。 26 | 27 | 例えば、ある資料作成のタスクがあったとき、「スライド～～枚で、見出しはしっかりと作りこむ。本文や記載する図表はダミーでよい」と記述することで、目的に沿ったアウトプットなのかどうかを確認しやすくなります。この場合、タスクの目的が「プレゼンテーション直前のリハーサルに使うため」であればアウトプットとしては不十分でしょうし、「プレゼンテーションの大枠の内容を内々に議論するため」であれば、必要十分なアウトプットになるでしょう。目的が達成できるのであれば、必ずしも完成度を突き詰める必要はありません。それよりも、最小限のアウトプットを確実に作ることを意識しましょう。 28 | 29 | また、想定アウトプットのイメージをすり合わせるためには、タスクを終えるまでの想定作業時間を明文化することも効果的です。前述の資料作成のタスクであれば、ある人は1時間しかかからないと思っていた作業が、別の人は4時間もかかると思っていた場合、作りこみのレベルに差がある可能性が高いということが分かります。 30 | 31 | さらに、これらの作業を通じてタスクの粒度が大きいと判断された場合は、そのタスクを細かく分解し、ミーティングごとに確実にアウトプットが可能なサイズにしましょう。 32 | -------------------------------------------------------------------------------- /CODE/v3/.3_ja/practices/tasks.md: -------------------------------------------------------------------------------- 1 | # タスクの設定 2 | 3 | Project Sprintには、ミーティング終盤にそのミーティングを通じて生まれたタスクの確認を行い、次回のミーティングの序盤でそれまでのタスクの進捗報告を行うというサイクルがあります。 [ミーティングの進行方向](holding_meetings.md)で解説したように、タスクを記載する際には、 4 | 5 | * 具体的な行動内容 6 | * 担当者 7 | * 期限 8 | 9 | を明確にすることが最低限必要です。 10 | 11 | しかし、これだけでは、タスクの進捗報告の際に「想定していたのと違った」「いつまでたっても完了しない」といったことが起こりえます。これは、タスクの担当者が何をやればよいかよくわかっていないことが原因であったり、そもそも担当者の設定や期限の設定が間違っていたりすることが原因です。そして、さらにその根本的な原因は、チームメンバ―の間で認識のずれがあり、正しくタスクが定義できてないことにあります。 12 | 13 | そこで、次の要素についてもあわせて検討し明文化することで、そうした認識ずれをあらかじめ防ぐことができます。 14 | 15 | ## 目的 16 | 17 | なぜこのタスクを行う必要があるのかについての記述です。 18 | 19 | タスクはプロジェクトゴールとして設定された成果物・成果に漸進的に近づくためのものです。また、タスクを遂行する中で他のメンバーに伝えたい問題点や違和感（**テンション**）が生まれ、プロジェクトを最適化するための材料となります。そのためにそれぞれのタスクがプロジェクトゴールにどのように結びついているかを意識しながら目的を明文化することが有効です。 20 | 21 | 目的を記載することで、誰がやるべきか（担当者）や、いつまでにやるべきか（期限）も簡単に判断することができます。 22 | 23 | ## 想定アウトプット・想定作業時間 24 | 25 | タスクをこなした結果生まれるアウトプットについての具体的イメージの記述です。なお、アウトプットとは、チームメンバーが割り当てられたタスクを完了したことで生まれた結果のことです（Tips3参照）。 26 | 27 | 例えば、ある資料作成のタスクがあったとき、「スライド～～枚で、見出しはしっかりと作りこむ。本文や記載する図表はダミーでよい」と記述することで、目的に沿ったアウトプットなのかどうかを確認しやすくなります。この場合、タスクの目的が「プレゼンテーション直前のリハーサルに使うため」であればアウトプットとしては不十分でしょうし、「プレゼンテーションの大枠の内容を内々に議論するため」であれば、必要十分なアウトプットになるでしょう。目的が達成できるのであれば、必ずしも完成度を突き詰める必要はありません。それよりも、最小限のアウトプットを確実に作ることを意識しましょう。 28 | 29 | また、想定アウトプットのイメージをすり合わせるためには、タスクを終えるまでの想定作業時間を明文化することも効果的です。前述の資料作成のタスクであれば、ある人は1時間しかかからないと思っていた作業が、別の人は4時間もかかると思っていた場合、作りこみのレベルに差がある可能性が高いということが分かります。 30 | 31 | さらに、これらの作業を通じてタスクの粒度が大きいと判断された場合は、そのタスクを細かく分解し、ミーティングごとに確実にアウトプットが可能なサイズにしましょう。 32 | -------------------------------------------------------------------------------- /CODE/v3/.0_ja/tutorial/section3-2-1.md: -------------------------------------------------------------------------------- 1 | # タスクを設定する 2 | 3 | Project Sprintには、ミーティング終盤にそのミーティングを通じて生まれたタスクの確認を行い、次回のミーティングの序盤でそれまでのタスクの進捗報告を行うというサイクルがあります。 [ミーティングを開催する](section3-2.md)で解説したように、タスクを記載する際には、 4 | 5 | * 具体的な行動内容 6 | * 担当者 7 | * 期限 8 | 9 | を明確にすることが最低限必要です。 10 | 11 | しかし、これだけでは、タスクの進捗報告の際に「想定していたのと違った」「いつまでたっても完了しない」といったことが起こりえます。これは、タスクの担当者が何をやればよいかよくわかっていないことが原因であったり、そもそも担当者の設定や期限の設定が間違っていたりすることが原因です。そして、さらにその根本的な原因は、チームメンバ―の間で認識のずれがあり、正しくタスクが定義できてないことにあります。 12 | 13 | そこで、次の要素についてもあわせて検討し明文化することで、そうした認識ずれをあらかじめ防ぐことができます。 14 | 15 | #### **目的** 16 | 17 | なぜこのタスクを行う必要があるのかについての記述です。 18 | 19 | タスクはプロジェクトゴールとして設定された成果物・成果に漸進的に近づくためのものです。また、タスクを遂行する中で他のメンバーに伝えたい問題点や違和感（**テンション**）が生まれ、プロジェクトを最適化するための材料となります。そのためにそれぞれのタスクがプロジェクトゴールにどのように結びついているかを意識しながら目的を明文化することが有効です。 20 | 21 | 目的を記載することで、誰がやるべきか（担当者）や、いつまでにやるべきか（期限）も簡単に判断することができます。 22 | 23 | #### **想定アウトプット・想定作業時間** 24 | 25 | タスクをこなした結果生まれるアウトプットについての具体的イメージの記述です。なお、アウトプットとは、チームメンバーが割り当てられたタスクを完了したことで生まれた結果のことです（Tips3参照）。 26 | 27 | 例えば、ある資料作成のタスクがあったとき、「スライド～～枚で、見出しはしっかりと作りこむ。本文や記載する図表はダミーでよい」と記述することで、目的に沿ったアウトプットなのかどうかを確認しやすくなります。この場合、タスクの目的が「プレゼンテーション直前のリハーサルに使うため」であればアウトプットとしては不十分でしょうし、「プレゼンテーションの大枠の内容を内々に議論するため」であれば、必要十分なアウトプットになるでしょう。目的が達成できるのであれば、必ずしも完成度を突き詰める必要はありません。それよりも、最小限のアウトプットを確実につくることを意識しましょう。 28 | 29 | また、想定アウトプットのイメージをすり合わせるためには、タスクを終えるまでの想定作業時間を明文化することも効果的です。前述の資料作成のタスクであれば、ある人は1時間しかかからないと思っていた作業が、別の人は4時間もかかると思っていた場合、作りこみのレベルに差がある可能性が高いということが分かります。 30 | 31 | さらに、これらの作業を通じてタスクの粒度が大きいと判断された場合は、そのタスクを細かく分解し、ミーティングごとに確実にアウトプットが可能なサイズにしましょう。 32 | -------------------------------------------------------------------------------- /CODE/v3/.1_ja/tutorial/section3-2-1.md: -------------------------------------------------------------------------------- 1 | # タスクを設定する 2 | 3 | Project Sprintには、ミーティング終盤にそのミーティングを通じて生まれたタスクの確認を行い、次回のミーティングの序盤でそれまでのタスクの進捗報告を行うというサイクルがあります。 [ミーティングを開催する](section3-2.md)で解説したように、タスクを記載する際には、 4 | 5 | * 具体的な行動内容 6 | * 担当者 7 | * 期限 8 | 9 | を明確にすることが最低限必要です。 10 | 11 | しかし、これだけでは、タスクの進捗報告の際に「想定していたのと違った」「いつまでたっても完了しない」といったことが起こりえます。これは、タスクの担当者が何をやればよいかよくわかっていないことが原因であったり、そもそも担当者の設定や期限の設定が間違っていたりすることが原因です。そして、さらにその根本的な原因は、チームメンバ―の間で認識のずれがあり、正しくタスクが定義できてないことにあります。 12 | 13 | そこで、次の要素についてもあわせて検討し明文化することで、そうした認識ずれをあらかじめ防ぐことができます。 14 | 15 | #### **目的** 16 | 17 | なぜこのタスクを行う必要があるのかについての記述です。 18 | 19 | タスクはプロジェクトゴールとして設定された成果物・成果に漸進的に近づくためのものです。また、タスクを遂行する中で他のメンバーに伝えたい問題点や違和感（**テンション**）が生まれ、プロジェクトを最適化するための材料となります。そのためにそれぞれのタスクがプロジェクトゴールにどのように結びついているかを意識しながら目的を明文化することが有効です。 20 | 21 | 目的を記載することで、誰がやるべきか（担当者）や、いつまでにやるべきか（期限）も簡単に判断することができます。 22 | 23 | #### **想定アウトプット・想定作業時間** 24 | 25 | タスクをこなした結果生まれるアウトプットについての具体的イメージの記述です。なお、アウトプットとは、チームメンバーが割り当てられたタスクを完了したことで生まれた結果のことです（Tips3参照）。 26 | 27 | 例えば、ある資料作成のタスクがあったとき、「スライド～～枚で、見出しはしっかりと作りこむ。本文や記載する図表はダミーでよい」と記述することで、目的に沿ったアウトプットなのかどうかを確認しやすくなります。この場合、タスクの目的が「プレゼンテーション直前のリハーサルに使うため」であればアウトプットとしては不十分でしょうし、「プレゼンテーションの大枠の内容を内々に議論するため」であれば、必要十分なアウトプットになるでしょう。目的が達成できるのであれば、必ずしも完成度を突き詰める必要はありません。それよりも、最小限のアウトプットを確実に作ることを意識しましょう。 28 | 29 | また、想定アウトプットのイメージをすり合わせるためには、タスクを終えるまでの想定作業時間を明文化することも効果的です。前述の資料作成のタスクであれば、ある人は1時間しかかからないと思っていた作業が、別の人は4時間もかかると思っていた場合、作りこみのレベルに差がある可能性が高いということが分かります。 30 | 31 | さらに、これらの作業を通じてタスクの粒度が大きいと判断された場合は、そのタスクを細かく分解し、ミーティングごとに確実にアウトプットが可能なサイズにしましょう。 32 | -------------------------------------------------------------------------------- /CODE/v3/.2_ja/practices/reviewing_project_goals_and_milestones.md: -------------------------------------------------------------------------------- 1 | # プロジェクトゴールとマイルストーンの見直し 2 | 3 | [プロジェクトゴールの設定](project_goals.md)でも述べたように、プロジェクトゴールやマイルストーンは固定的なものではなく、むしろ環境の変化に応じて柔軟に書き換えられたり進化したりしうるものなので、いつでも見直してよく、また必要に応じて見直さねばならないものです。市場環境の悪化や組織の体制変更、稟議スケジュールの変更といったプロジェクトの外部環境の変化によって調整が必要になることもあれば、プロジェクトを進める中で得られた洞察やチームメンバーの共通認識・役割期待の遷移といった内部的な変化によって進化することもあります。 4 | 5 | ## 見直しが必要となる具体的な場合 6 | 7 | プロジェクトのゴールの見直しをするべきタイミングは、次のようなときです。 8 | 9 | 1. 外部環境の変化やプロジェクトの進行の結果、プロジェクトゴールそのものを見直したほうが良いことが分かったとき 10 | 2. マイルストーンが予定通りに達成されなかった結果、プロジェクトゴールを見直したほうが良いことがわかったとき 11 | 3. その他何らかの理由でチームメンバーがプロジェクトゴールを見直したほうがよいと考えたとき 12 | 13 | マイルストーンに関しては、プロジェクトゴールよりも頻繁に見直しが必要となることがあるでしょう。見直しをするべきタイミングは、次のようなときです。 14 | 15 | 1. あるマイルストーンが達成されたとき 16 | 2. あるマイルストーンが予定通りに達成されないことが明らかになったとき（予定よりも遅い場合、早い場合のいずれも含む） 17 | 3. プロジェクトゴールに対してあるマイルストーンが適切ではないことが明らかになったとき 18 | 4. プロジェクトゴールが変わったためマイルストーンも変える必要が出てきたとき 19 | 5. その他何らかの理由でチームメンバーがマイルストーンを見直したほうがよいと考えたとき 20 | 21 | ## 見直しの手順 22 | 23 | プロジェクト内外の環境は絶えず変化し続けているので、それに対応するためには、とにかく定期的にプロジェクトゴールとマイルストーンを見直し、現状に即していないところや違和感のある所がないかを確認することが重要です。プロジェクトゴールやマイルストーンは、全員が集まる場で見直しや調整を繰り返し、違和感を抱くメンバーがいれば納得いくまで議論することで、チームメンバー全員が共通認識と納得感を持てる状態にしていく必要があります。 24 | 25 | プロジェクトゴールやマイルストーンの見直しの実施についてもミーティングのアジェンダアイテムとなるため、事前にアジェンダアイテムの提出を行う必要があります。 26 | 27 | プロジェクトゴールやマイルストーンを変更する際には、変更の前後を並べて見せるなど、その差分を明確にし、積極的に共有するようにしてください。これは、「知らない間にプロジェクトゴールやマイルストーンが変わっていた」と感じるメンバーが出てきてしまわないようにするためです。 28 | 29 | プロジェクトゴールやマイルストーンはプロジェクトにおけるあらゆる場面で参照され、チームメンバーにとって指針となるべきものです。そのため、変更後のプロジェクトゴールやマイルストーンにもチームメンバー全員が確実に納得できている状態を作ってください。 30 | -------------------------------------------------------------------------------- /CODE/v3/.3_ja/practices/reviewing_project_goals_and_milestones.md: -------------------------------------------------------------------------------- 1 | # プロジェクトゴールとマイルストーンの見直し 2 | 3 | [プロジェクトゴールの設定](project_goals.md)でも述べたように、プロジェクトゴールやマイルストーンは固定的なものではなく、むしろ環境の変化に応じて柔軟に書き換えられたり進化したりしうるものなので、いつでも見直してよく、また必要に応じて見直さねばならないものです。市場環境の悪化や組織の体制変更、稟議スケジュールの変更といったプロジェクトの外部環境の変化によって調整が必要になることもあれば、プロジェクトを進める中で得られた洞察やチームメンバーの共通認識・役割期待の遷移といった内部的な変化によって進化することもあります。 4 | 5 | ## 見直しが必要となる具体的な場合 6 | 7 | プロジェクトのゴールの見直しをするべきタイミングは、次のようなときです。 8 | 9 | 1. 外部環境の変化やプロジェクトの進行の結果、プロジェクトゴールそのものを見直したほうが良いことが分かったとき 10 | 2. マイルストーンが予定通りに達成されなかった結果、プロジェクトゴールを見直したほうが良いことがわかったとき 11 | 3. その他何らかの理由でチームメンバーがプロジェクトゴールを見直したほうがよいと考えたとき 12 | 13 | マイルストーンに関しては、プロジェクトゴールよりも頻繁に見直しが必要となることがあるでしょう。見直しをするべきタイミングは、次のようなときです。 14 | 15 | 1. あるマイルストーンが達成されたとき 16 | 2. あるマイルストーンが予定通りに達成されないことが明らかになったとき（予定よりも遅い場合、早い場合のいずれも含む） 17 | 3. プロジェクトゴールに対してあるマイルストーンが適切ではないことが明らかになったとき 18 | 4. プロジェクトゴールが変わったためマイルストーンも変える必要が出てきたとき 19 | 5. その他何らかの理由でチームメンバーがマイルストーンを見直したほうがよいと考えたとき 20 | 21 | ## 見直しの手順 22 | 23 | プロジェクト内外の環境は絶えず変化し続けているので、それに対応するためには、とにかく定期的にプロジェクトゴールとマイルストーンを見直し、現状に即していないところや違和感のある所がないかを確認することが重要です。プロジェクトゴールやマイルストーンは、全員が集まる場で見直しや調整を繰り返し、違和感を抱くメンバーがいれば納得いくまで議論することで、チームメンバー全員が共通認識と納得感を持てる状態にしていく必要があります。 24 | 25 | プロジェクトゴールやマイルストーンの見直しの実施についてもミーティングのアジェンダアイテムとなるため、事前にアジェンダアイテムの提出を行う必要があります。 26 | 27 | プロジェクトゴールやマイルストーンを変更する際には、変更の前後を並べて見せるなど、その差分を明確にし、積極的に共有するようにしてください。これは、「知らない間にプロジェクトゴールやマイルストーンが変わっていた」と感じるメンバーが出てきてしまわないようにするためです。 28 | 29 | プロジェクトゴールやマイルストーンはプロジェクトにおけるあらゆる場面で参照され、チームメンバーにとって指針となるべきものです。そのため、変更後のプロジェクトゴールやマイルストーンにもチームメンバー全員が確実に納得できている状態を作ってください。 30 | -------------------------------------------------------------------------------- /CODE/v2/.2_ja/tutorial/1-3.md: -------------------------------------------------------------------------------- 1 | # ミーティングを設計する 2 | 3 | この記事の内容はプロジェクトスプリントにおける「プロセスドメイン」にあたります。 4 | 5 | プロセスは定期開催のミーティングとそこでのアジェンダの議論を軸としたプロジェクトスプリント固有の仕組みです。これによって、プログレスドメイン・チーミングドメイン双方における「理想の状態」を達成することができるようになります。 6 | 7 | ここでは、プロセスを回すための出発点となるミーティングの設計について記述します。 8 | 9 | ### **ミーティングの設計** 10 | 11 | プロジェクトスプリントでは「ミーティング」を、「チームメンバー全員が空間や時間を共有し、素早く効率的な認識合わせと、全員が納得した意思決定をする場」として位置づけています。これを実現するために、ミーティングを適切にデザインし、プロジェクトメンバーで合意しましょう。 12 | 13 | まず、ミーティングは定例ミーティングである必要があります。この理由について、詳しくは[こちら](../tips/3-1.md)を参照してください。 14 | 15 | ミーティングの開催頻度は、週次/月次/隔週など、プロジェクトの性質やチームメンバーの人数などを勘案して任意に決めてください。ただし、プロジェクトスプリントがプロジェクト推進メソッドであることを考えると、隔月以上の間隔でのミーティング開催は考えにくいでしょう。 16 | 17 | なお、各ミーティングの参加者はアジェンダに応じて必要十分な程度でかまいません。ここでいう必要十分とは、アジェンダに関して網羅的に議論でき（＝「誰かがいないから今日はこの話ができないね」ということがないようにする）、また議論をもとに正式な意思決定ができること（＝「誰かがいないから今日はこの話は決まらないね」ということがないようにする）を意味しています。もし参加人数が大人数(10人を一つの目安としてください）になっている場合は、必要以上の人数を集めていないか、確認してください。そうした会議はアジェンダの議論と意思決定ではなく、単なる情報共有を目的としている会議になっている可能性があります。 18 | 19 | とはいえ、ミーティングにおけるアジェンダは常に一定とは限りませんから、最初にミーティングを設計する際には、あらかじめチームメンバー全員が集まることのできるミーティングを設定したほうが良い場合も多いでしょう。そうすることで、チームメンバー個々人の中にとどまっている情報を一斉に共有することができ、各メンバーはこのプロセスに参加するだけでプロジェクトの状況や思っていることについて自然と認識を合わせることができるようになります。 20 | 21 | さらに、ミーティング環境を前述の参加者が漏れなく参加でき、かつ、情報をリアルタイムに共有できる環境を整備するようにしてください。これは、前述の素早く効率的な認識合わせを実現するために重要なポイントとなります。具体的には、場所を問わず参加できるリモートミーティング環境の準備、その場で決まったことを共有できるドキュメントシェアサービスの利用、などを行うことになるでしょう。 22 | 23 | **このページと関係するTips** 24 | 25 | * [プロジェクトの時間軸を整理するための便利な考え方（トラック/フェーズ/イベント)](../tips/1-2.md) 26 | * [ミーティング環境についてのノウハウ](../tips/3-2-1.md) 27 | * [プロジェクトの環境整備](../tips/1-1.md) 28 | -------------------------------------------------------------------------------- /CODE/v3/.2_ja/practices/tracks.md: -------------------------------------------------------------------------------- 1 | # トラックの設定 2 | 3 | ## 1. プロジェクトゴールに対する認識を揃える 4 | 5 | [プロジェクトゴールの設定](project_goals.md)や、[マイルストーンの設定](milestones.md)を参考に、まずはプロジェクトの目的やプロジェクトゴールを明確化し、チームメンバー間での共通認識にします。 6 | 7 | ## 2. メインのトラックを設定する 8 | 9 | プロジェクト全体・プロジェクトチーム全体の主な状態を把握するトラックを、メインのトラックとして設定します。このトラックには、プロジェクトゴールの達成のために必要な大きなマイルストーンと、プロジェクト全体に関わるアイデアの共創や問題の共同解決のために必要な定例ミーティングの両方が入力されることが多いでしょう。プロジェクトメンバーによる定例ミーティングを設定し、このトラックだけでなくプロジェクト全体のマイルストーンマップを毎週確認できるようにしておきましょう。 10 | 11 | メインのトラックにおけるマイルストーンとステップは、外部制約や主要なイベントなどに応じて設定していくのがふつうですが、そういったものが明確に存在しない場合は、3か月ごとなどの定期的なタイミングでステップを区切ってマイルストーンを設定します。たとえば何らかのサービスを立ち上げるようなプロジェクトであれば、各ステップごとに顧客に対して提供したい価値を記述するのもよいでしょう。 12 | 13 | 各ステップの終点となるマイルストーンの成果物・あるべき姿には、提供したい価値・バリューを、具体的な作成物や数値目標、達成したい状態などに落とし込んで記載しましょう。メインのトラックのマイルストーンは、このあと設定される各トラックにおけるマイルストーン達成の集積によって達成されてゆくという構造になります。そのため、メインのトラックのマイルストーンを参照することで、このあと作成する各トラックのメンバーが自律的に各トラックのマイルストーンを決定できるような内容が書いてあることが望ましいです。 14 | 15 | メインのトラックのマイルストーンを設定するときには、「各トラックの成果物の仕上がりが合わさる、または仕上がりを合わせたい具体的なタイミングはいつか」というところから考えてみるとイメージしやすくなるかもしれません。 16 | 17 | ## 3. メインのトラックの他に必要なトラックを設定する 18 | 19 | メインのトラックのマイルストーンを達成するために必要なものを部分部分に分割して、その他のトラックを作っていきます。 20 | 21 | 基本的には、トラック同士は依存関係が少ない疎結合な状態になるように分割します。つまり、個々のトラックだけで自律して作業を進められるような分け方です。こういった分け方ができず、強い依存関係のあるタスクベースで進捗をコントロールする必要がある場合には、別途ガントチャートを作って把握するのがよいでしょう。 22 | 23 | 各トラックで個別にミーティングが必要な場合や、各トラックで個別にチームになった場合は定例ミーティングを置きますが、それぞれのトラックには必ずしも定例ミーティングを設定する必要はありません。 24 | 25 | また、各トラックは原則として疎結合なものとして存在しますが、進捗状況の共有やマイルストーンの詳細な確認などを目的として、トラック間での連携やトラックを横断したミーティングを置くこともあります。このときは、連携が必要となるトラックの上部構造として、連携用のミーティングを置くトラックを設定するとよいでしょう。 26 | -------------------------------------------------------------------------------- /CODE/v3/.3_ja/practices/tracks.md: -------------------------------------------------------------------------------- 1 | # トラックの設定 2 | 3 | ## 1. プロジェクトゴールに対する認識を揃える 4 | 5 | [プロジェクトゴールの設定](project_goals.md)や、[マイルストーンの設定](milestones.md)を参考に、まずはプロジェクトの目的やプロジェクトゴールを明確化し、チームメンバー間での共通認識にします。 6 | 7 | ## 2. メインのトラックを設定する 8 | 9 | プロジェクト全体・プロジェクトチーム全体の主な状態を把握するトラックを、メインのトラックとして設定します。このトラックには、プロジェクトゴールの達成のために必要な大きなマイルストーンと、プロジェクト全体に関わるアイデアの共創や問題の共同解決のために必要な定例ミーティングの両方が入力されることが多いでしょう。プロジェクトメンバーによる定例ミーティングを設定し、このトラックだけでなくプロジェクト全体のマイルストーンマップを毎週確認できるようにしておきましょう。 10 | 11 | メインのトラックにおけるマイルストーンとステップは、外部制約や主要なイベントなどに応じて設定していくのがふつうですが、そういったものが明確に存在しない場合は、3か月ごとなどの定期的なタイミングでステップを区切ってマイルストーンを設定します。たとえば何らかのサービスを立ち上げるようなプロジェクトであれば、各ステップごとに顧客に対して提供したい価値を記述するのもよいでしょう。 12 | 13 | 各ステップの終点となるマイルストーンの成果物・あるべき姿には、提供したい価値・バリューを、具体的な作成物や数値目標、達成したい状態などに落とし込んで記載しましょう。メインのトラックのマイルストーンは、このあと設定される各トラックにおけるマイルストーン達成の集積によって達成されてゆくという構造になります。そのため、メインのトラックのマイルストーンを参照することで、このあと作成する各トラックのメンバーが自律的に各トラックのマイルストーンを決定できるような内容が書いてあることが望ましいです。 14 | 15 | メインのトラックのマイルストーンを設定するときには、「各トラックの成果物の仕上がりが合わさる、または仕上がりを合わせたい具体的なタイミングはいつか」というところから考えてみるとイメージしやすくなるかもしれません。 16 | 17 | ## 3. メインのトラックの他に必要なトラックを設定する 18 | 19 | メインのトラックのマイルストーンを達成するために必要なものを部分部分に分割して、その他のトラックを作っていきます。 20 | 21 | 基本的には、トラック同士は依存関係が少ない疎結合な状態になるように分割します。つまり、個々のトラックだけで自律して作業を進められるような分け方です。こういった分け方ができず、強い依存関係のあるタスクベースで進捗をコントロールする必要がある場合には、別途ガントチャートを作って把握するのがよいでしょう。 22 | 23 | 各トラックで個別にミーティングが必要な場合や、各トラックで個別にチームになった場合は定例ミーティングを置きますが、それぞれのトラックには必ずしも定例ミーティングを設定する必要はありません。 24 | 25 | また、各トラックは原則として疎結合なものとして存在しますが、進捗状況の共有やマイルストーンの詳細な確認などを目的として、トラック間での連携やトラックを横断したミーティングを置くこともあります。このときは、連携が必要となるトラックの上部構造として、連携用のミーティングを置くトラックを設定するとよいでしょう。 26 | -------------------------------------------------------------------------------- /CODE/v2/.0_en/tips/tips10.md: -------------------------------------------------------------------------------- 1 | # Tips10: Tension Triage Methods 2 | 3 | As explained in the section on [Holding a meeting](../tutorial/2-2.md), conduct a tension triage at the beginning of the meeting. This will allow each member to share the gaps between the current situation and the better situation, as well as any ideas, concerns, or worries that they may have, and to take action to resolve them. 4 | 5 | Tension triage, for example, is carried out in the following steps, but it is only one example. Try to arrange it in a way that works best for your team to achieve the above objectives more efficiently and effectively. 6 | 7 | 1. Team members raise the tension 8 | 2. The agenda owner of the tension triage reads one of the tensions and asks, "What do you need? and asks the person who raised the tension, "What do you need? 9 | 3. The person who raised the tension chooses one of the following, and then answers what they need 10 | 11 | * Request a task from another member 12 | * Request for information or help provision from other members 13 | * Requests for adjustments, changes, or additions to roles 14 | * Mere sharing of information or feedback 15 | 16 | 1. The agenda owner of the tension triage will make a suggestion to the person who raised the tension by choosing one of the following 17 | * Resolve it on the spot 18 | * Make it a task 19 | * Make it an agenda 20 | 2. If the person who raised the tension gets what they need from this, they are done. If not, continue the discussion. (Repeat steps 3 and 4 in detail) 21 | 3. Repeat steps 2\~5 for other tensions as time permits. 22 | -------------------------------------------------------------------------------- /CODE/v3/.1_ja/tutorial/section2-2-3.md: -------------------------------------------------------------------------------- 1 | # トラックの設定方法 2 | 3 | ## 1. プロジェクトゴールに対する認識を揃える 4 | 5 | [プロジェクトゴールとマイルストーンを設定する](section2-2.md)や、[プロジェクトゴールやマイルストーンの設定が難しいときの始め方](section2-2-1.md)を参考に、まずはプロジェクトの目的やプロジェクトゴールを明確化し、チームメンバー間での共通認識にします。 6 | 7 | ## 2. メインのトラックを設定する 8 | 9 | プロジェクト全体・プロジェクトチーム全体の主な状態を把握するトラックを、メインのトラックとして設定します。このトラックには、プロジェクトゴールの達成のために必要な大きなマイルストーンと、プロジェクト全体に関わるアイデアの共創や問題の共同解決のために必要な定例ミーティングの両方が入力されることが多いでしょう。プロジェクトメンバーによる定例ミーティングを設定し、このトラックだけでなくプロジェクト全体のマイルストーンマップを毎週確認できるようにしておきましょう。 10 | 11 | メインのトラックにおけるマイルストーンとステップは、外部制約や主要なイベントなどに応じて設定していくのがふつうですが、そういったものが明確に存在しない場合は、3か月ごとなどの定期的なタイミングでステップを区切ってマイルストーンを設定します。たとえば何らかのサービスを立ち上げるようなプロジェクトであれば、各ステップごとに顧客に対して提供したい価値を記述するのもよいでしょう。 12 | 13 | 各ステップの終点となるマイルストーンの成果物・あるべき姿には、提供したい価値・バリューを、具体的な作成物や数値目標、達成したい状態などに落とし込んで記載しましょう。メインのトラックのマイルストーンは、このあと設定される各トラックにおけるマイルストーン達成の集積によって達成されてゆくという構造になります。そのため、メインのトラックのマイルストーンを参照することで、このあと作成する各トラックのメンバーが自律的に各トラックのマイルストーンを決定できるような内容が書いてあることが望ましいです。 14 | 15 | メインのトラックのマイルストーンを設定するときには、「各トラックの成果物の仕上がりが合わさる、または仕上がりを合わせたい具体的なタイミングはいつか」というところから考えてみるとイメージしやすくなるかもしれません。 16 | 17 | ## 3. メインのトラックの他に必要なトラックを設定する 18 | 19 | メインのトラックのマイルストーンを達成するために必要なものを部分部分に分割して、その他のトラックを作っていきます。 20 | 21 | 基本的には、トラック同士は依存関係が少ない疎結合な状態になるように分割します。つまり、個々のトラックだけで自律して作業を進められるような分け方です。こういった分け方ができず、強い依存関係のあるタスクベースで進捗をコントロールする必要がある場合には、別途ガントチャートを作って把握するのがよいでしょう。 22 | 23 | 各トラックで個別にミーティングが必要な場合や、各トラックで個別にチームになった場合は定例ミーティングを置きますが、それぞれのトラックには必ずしも定例ミーティングを設定する必要はありません。 24 | 25 | また、各トラックは原則として疎結合なものとして存在しますが、進捗状況の共有やマイルストーンの詳細な確認などを目的として、トラック間での連携やトラックを横断したミーティングを置くこともあります。このときは、連携が必要となるトラックの上部構造として、連携用のミーティングを置くトラックを設定するとよいでしょう。 26 | -------------------------------------------------------------------------------- /CODE/v2/.2_ja/tips/2-1.md: -------------------------------------------------------------------------------- 1 | # マイルストーンマップの利用 2 | 3 | [プロジェクトのゴールとマイルストーンを設定する](../tutorial/1-1.md)で記載した通り、マイルストーンとは「具体的な成果物とそれに紐づく期限をセットにして記述したもの」です。このマイルストーンは、チームメンバー全員で共有・合意される必要があります。また、プロジェクトの進行中常に意識できるよう、いつでも参照できるようにしておきましょう。 4 | 5 | この作業を助けるためのツールとして、「マイルストーンマップ」を利用することをおすすめします。 6 | 7 | マイルストーンマップとは、プロジェクト内のマイルストーンの全体像を把握するためのシートのことです。あるべき姿や成果を分かりやすくシンプルに表現することで、チームメンバー全員が共通認識を持てるようになります。また、複数のマイルストーンを横断的に記載することで、マイルストーン間の関係や設定の背景を含めたより深い理解を可能にします。 8 | 9 | マイルストーンマップには次のような要素を、ゴールまでのマイルストーン全体を俯瞰して見られるような形で盛り込みます。各要素はプロジェクトの変化に応じて常に更新し、形骸化させないことが重要です。 10 | 11 | * フェーズ名: マイルストーン間の意味的な位置づけ（実際に何をするのかを分かりやすく記載する） 12 | * 期日の開始日: 通常は直前のマイルストーン終了日の翌日 13 | * 期日の終了日(※): マイルストーン完了の期日 14 | * 成果物(※): マイルストーン完了時に必要な成果物 15 | * あるべき姿: マイルストーン完了時点でプロジェクト内部がどのような状態になっていてほしいか、またはプロジェクトの成果物を受けてプロジェクトの外部がどのような状態になっていてほしいか、を記述 16 | * メモ: 補足情報を自由に記載する 17 | 18 | (※): マイルストーンとしての必須要素 19 | 20 | **マイルストーンマップの具体的な記入要素と入力内容サンプル** 21 | 22 | 例えば「ある問題を解決できる新規サービスを立ち上げる」というゴールを持ったプロジェクトがあり、このためにいくつかのマイルストーンを設定した場合、マイルストーンマップを表形式で作成すると以下のようになります。 23 | 24 | |マイルストーン|顧客の定義とリスト化の完了|必要な機能の検討完了|リリースのための環境整備| 25 | |----|----|----|----| 26 | |期間|6/1〜6/30|7/1〜8/31|9/15〜11/14| 27 | |ステージ名|【調査】顧客の存在を確かめる|【企画】このサービスで問題を解決できるか確かめる|【実現】市場価値があるサービスか確かめる| 28 | |作成物|・顧客定義シート
・顧客リスト|・UXマップ
・サービス機能リスト
・顧客ヒアリング（5人分）|・クラウドファンディング実験結果まとめ
・ユーザーアンケート| 29 | |成したい状態|・顧客に今回の問題があることをメンバーが確信できている| ・問題解決のために必要な機能が把握できている|・このサービスの市場価値に定量的な根拠がある| 30 | |達成の基準|・どこに顧客が存在するのかわかっている|・リリースに含めるべき最低限の機能が特定できている|・次のステップとしてリリースできる機能の範囲が決まっている| 31 | |メモ|||| 32 | 33 | **このページと関係するTips** 34 | 35 | * [プロジェクトの時間軸を整理するための便利な考え方（トラック/フェーズ/イベント)](1-2.md) 36 | -------------------------------------------------------------------------------- /CODE/v2/.2_ja/tutorial/2-1.md: -------------------------------------------------------------------------------- 1 | # ミーティングの準備をする 2 | 3 | この記事の内容はプロジェクトスプリントにおける「プロセスドメイン」にあたります。 4 | 5 | プロセスは定期開催のミーティングとそこでのアジェンダの議論を軸としたプロジェクトスプリント固有の仕組みです。これによって、プログレスドメイン・チーミングドメイン双方における「理想の状態」を達成することができるようになります。 6 | 7 | ミーティングの準備/ミーティングの開催の二つの時間軸に分けて解説します。この記事は、ミーティングの準備について記載されています。 8 | 9 | ### **ミーティングロールの確認** 10 | 11 | まず、ミーティングを効率的・効果的に運営するための役割（ミーティングロール）を個々人に割り当てましょう。 12 | 13 | 具体的には、次のようなロールを割り当てる必要があります。 14 | 15 | * ファシリテーター：アジェンダの取りまとめ(アジェンダの合意から、その後のアジェンダ進行とタイムキープ、ミーティング終了時の次回のアジェンダの決定)および議論の促進と成果の質の向上(アジェンダの改善、その後の議論形成のサポート)をするロール。前者をモデレーター、後者をアクセラレーターとして区別して別々のロールとして割り当てることもある。 16 | * コーディネーター：ミーティング環境をつくるロール。適切なミーティングルームの確保（オンラインの場合はミーティング環境の設定）、ホワイトボードやモニターの手配をする。 17 | * レコーダー：議事録をつくるロール。ミーティング後に議事録を共有するだけではなく、ミーティング中にも作成中の議事録を公開し、メンバー間の認識のずれを即座に修正することができるようにする。 18 | 19 | チームメンバーの人数によって、一人が複数の役割を担当することもありますし、なんの役割を持たないメンバーが現れることもあります。ただし、いずれのロールも誰かが担うようにしてください。また、いずれも属人性が低いもののため、固定ではなく、ミーティングごとに持ち回りにすることが望ましいものです。これにより、ミーティング運営に関する問題点や最適な方法について、参加者全員が自分から考えやすくなります。 20 | 21 | これらはミーティングのたびに都度話し合い決定してもかまいませんが、あらかじめミーティング前に役割分担や持ち回りのルールを決めておくと、当日のミーティング運営が効率的になります。 22 | 23 | ### **アジェンダアイテムの提出** 24 | 25 | 毎回のミーティングが始まる前には、あらかじめ各チームメンバーがアジェンダアイテムを提出します。アジェンダアイテムには、少なくとも次のような内容が含まれている必要があります。 26 | 27 | * アジェンダアイテム名 28 | * 進行方法（具体的な議論の進行イメージ） 29 | * 目的や背景（そのアジェンダアイテムを議論したい理由） 30 | * 誰から誰への議論か（誰がそのアジェンダアイテムのオーナーであり、誰と議論したいのか） 31 | * 時間 32 | 33 | **このページと関係するTips** 34 | 35 | * [実務で使いやすいロールの設定](../tips/1-5.md) 36 | * [プロジェクトで作り出されるものにはどのようなものがあるのか（アウトプット/成果物）](../tips/2-2.md) 37 | * [ミーティング環境についてのノウハウ](../tips/3-2-1.md) 38 | * [プロジェクトの環境整備](../tips/1-1/) 39 | * [アジェンダアイテムに含まれているとよい全要素](../tips/3-2-2.md) 40 | * [アジェンダの目的](../tips/3-2-3.md) 41 | -------------------------------------------------------------------------------- /CODE/v2/.2_ja/tips/3-2-1.md: -------------------------------------------------------------------------------- 1 | # ミーティング環境についてのノウハウ 2 | 3 | プロジェクトスプリントで意図されているミーティングの効果を得るためには、効率的なミーティング環境の構築が欠かせません。「ミーティング環境の最適化自体についてもチームメンバーで議論し、改善していけること」が、プロジェクトスプリントのプロセスのもたらすものではあるものの、この点についてはすでにいくつかのベストプラクティスが得られています。それらをここでは紹介しますので、参考にしてみてください。 4 | 5 | ### **アジェンダの取りまとめ** 6 | 7 | プロジェクスプリントではアジェンダの取りまとめが非常に重要です。 8 | 9 | 例えば、次のようなアジェンダの取りまとめ作業が発生します。 10 | 11 | * ミーティング前のアジェンダアイテムの提出と必要な内容の編集 12 | * ミーティング開始後のアジェンダアイテムの追加と必要な内容の編集 13 | * ミーティング開始後のアジェンダアイテムの順番変更 14 | * ミーティング開始後のアジェンダアイテムの繰り越し 15 | 16 | これらの作業はすべてファシリテーターの主導のもと、チームメンバー全員で行われます。そのため、アジェンダを全員で確認・編集でき、かつ同じミーティングの中でのアジェンダアイテムの順番変更、ミーティングをまたいだアジェンダアイテムの移動ができる環境をつくっておきましょう。 17 | 18 | ### **ミーティング中の時間管理** 19 | 20 | アジェンダ管理に不可欠な前提が、ミーティング中の時間を的確に把握することです。オンライン / オフラインいずれの場合も、ミーティングに参加しているチームメンバーが時間を把握できるよう、目に入る位置にタイマーと時計を配置しましょう。 21 | 22 | タイマーは、「このアジェンダアイテムにあとどれくらい時間をかけられるのか」を把握するのに必要です。 23 | 24 | 時計は、ミーティング時間の開始時間・終了時間を把握するのに必要です。ミーティングの開始時間の遅れ、延長はつねに起こりうるものですが、絶対時刻を示す時計があると開始・終了の基準を把握・調整することができます。 25 | 26 | ### **議事録作成** 27 | 28 | ミーティングはチームメンバーで認識のズレをなくし、必要な物事を決める重要な場です。ミーティングの間に各自が必要なタスクに取りかかり、次のミーティングでその結果を持ち寄ることを考えると、ミーティングの内容は極力ミーティングの最中に明文化しながら確認、共有しておくことが効率的かつ効果的です。また、レコーダーがメインで議事を記録するものの、内容に間違いがある場合は最も正しい認識を持つ人がその場で修正してしまったほうがよいでしょう。 29 | 30 | そのため、共同編集ができるドキュメントツールを議事録作成用ツールとして導入し、ミーティング中に画面表示しながらリアルタイムで議事録作成をすることをおすすめします。 31 | 32 | ### **ホワイトボード** 33 | 34 | ミーティングでは口頭での説明、資料を用いた説明が行われることが多いと考えられますが、それに加え重要なのが手書きの情報による認識合わせです。手書きで図示/文章化することで、きちんと資料になっていなかったり、明確に言葉で説明できない内容を伝えやすくなります。これもプロジェクトスプリントにおいて必要な「認識のズレをなくす」というポイントに貢献してくれます。 35 | 36 | なおここでいうとホワイトボードはオフラインミーティングにおける物理的なものに限りません。オンラインミーティング用のホワイトボードツールもありますので、そういったものを利用してもかまいませんし、むしろ保存のしやすさという点ではこちらのほうが優れている場合もあります。 37 | -------------------------------------------------------------------------------- /CODE/v3/.2_ja/practices/meetings.md: -------------------------------------------------------------------------------- 1 | # ミーティングの設計 2 | 3 | [定例ミーティングの重要性](../theories/meetings.md)で記述した通り、ミーティングは定期的・反復的に開催される必要があります。 4 | 5 | ミーティングに目的や完了の定義が明確に存在しうることもありますが、基本的にはミーティングは目的も到達すべき地点も持たず、その時々のアジェンダアイテムが投入されていく連続した箱のようなものと捉えるのがよいでしょう。ミーティングで議論すべきアジェンダの内容や性質は常に異なるため、どのようなアジェンダでも自由に提案できるよう、なるべく縛りを設けないでおくのです。 6 | 7 | ## 開催頻度 8 | 9 | ミーティングの開催頻度は、週次/月次/隔週など、プロジェクトの性質やチームメンバーの人数などを勘案して任意に決めてください。ただし、Project Sprintの基本のメカニズムが「定期的・反復的なミーティングで各メンバーの取り組みの成果や作成物を共有し環境に対する認識を揃えることによって、各メンバーが同じプロジェクトゴールを目指して自律的に各自の次の行動に向かうことができるようにする。この繰り返しがプロジェクトを現在の状態から理想の状態に漸進的に近づけ、結果としてプロジェクトゴールが達成される。」であることを考えると、隔月以上の間隔でのミーティング開催は考えにくいでしょう。 10 | 11 | ## 参加者 12 | 13 | 各ミーティングの参加者はアジェンダに応じて必要十分な程度でかまいません。ここでいう必要十分とは、アジェンダに関して網羅的に議論でき（＝「誰かがいないから今日はこの話ができないね」ということがないようにする）、また議論をもとに正式な意思決定ができること（＝「誰かがいないから今日はこの話は決まらないね」ということがないようにする）を意味しています。もし参加人数が大人数(10人を一つの目安としてください）になっている場合は、必要以上の人数を集めていないか、確認してください。もしそうなってしまっている場合、アジェンダの議論と意思決定を目的としたミーティングではなく、単なる情報共有を目的とした会議になっている可能性があります。 14 | 15 | とはいえ、ミーティングでは多様なアジェンダが提出される可能性があるので、最初にミーティングを設計する際には、あらかじめチームメンバー全員が集まることのできるミーティングを設定したほうがいい場合も多いでしょう。そうすることで、チームメンバー個々人の中にとどまっている情報を一斉に共有することができ、各チームメンバーはこのプロセスに参加するだけでプロジェクトの状況や思っていることについて自然と認識を合わせることができるようになります。 16 | 17 | さらに、参加者が漏れなく参加でき、情報をリアルタイムに共有できるようなミーティング環境を整備するようにしてください。これは、前述の素早く効率的な認識合わせを実現するために重要なポイントとなります。具体的には、場所を問わず参加できるリモートミーティング環境の準備、その場で決まったことを共有できるドキュメントシェアサービスの利用、などを行うことになるでしょう。 18 | 19 | ## 定例ミーティングの要素 20 | 21 | 定例ミーティングを最適な状態で実施するには、会議のアジェンダの設定やファシリテーションの方法など、会議環境を整備しておく必要があります。具体的には、プロジェクトの内容やフェーズに応じて下記のような項目についてメンバー間で合意しておきましょう。 22 | 23 | - ミーティンググランドルール 24 | - ファシリテーション方法 25 | - ミーティングでのメンバーの役割 26 | - アジェンダパターン 27 | - アジェンダの活用方法 28 | - 議事録の活用方法 29 | - 継続的改善アプローチの導入 30 | -------------------------------------------------------------------------------- /CODE/v3/.3_ja/practices/meetings.md: -------------------------------------------------------------------------------- 1 | # ミーティングの設計 2 | 3 | [定例ミーティングの重要性](../theories/meetings.md)で記述した通り、ミーティングは定期的・反復的に開催される必要があります。 4 | 5 | ミーティングに目的や完了の定義が明確に存在しうることもありますが、基本的にはミーティングは目的も到達すべき地点も持たず、その時々のアジェンダアイテムが投入されていく連続した箱のようなものと捉えるのがよいでしょう。ミーティングで議論すべきアジェンダの内容や性質は常に異なるため、どのようなアジェンダでも自由に提案できるよう、なるべく縛りを設けないでおくのです。 6 | 7 | ## 開催頻度 8 | 9 | ミーティングの開催頻度は、週次/月次/隔週など、プロジェクトの性質やチームメンバーの人数などを勘案して任意に決めてください。ただし、Project Sprintの基本のメカニズムが「定期的・反復的なミーティングで各メンバーの取り組みの成果や作成物を共有し環境に対する認識を揃えることによって、各メンバーが同じプロジェクトゴールを目指して自律的に各自の次の行動に向かうことができるようにする。この繰り返しがプロジェクトを現在の状態から理想の状態に漸進的に近づけ、結果としてプロジェクトゴールが達成される。」であることを考えると、隔月以上の間隔でのミーティング開催は考えにくいでしょう。 10 | 11 | ## 参加者 12 | 13 | 各ミーティングの参加者はアジェンダに応じて必要十分な程度でかまいません。ここでいう必要十分とは、アジェンダに関して網羅的に議論でき（＝「誰かがいないから今日はこの話ができないね」ということがないようにする）、また議論をもとに正式な意思決定ができること（＝「誰かがいないから今日はこの話は決まらないね」ということがないようにする）を意味しています。もし参加人数が大人数(10人を一つの目安としてください）になっている場合は、必要以上の人数を集めていないか、確認してください。もしそうなってしまっている場合、アジェンダの議論と意思決定を目的としたミーティングではなく、単なる情報共有を目的とした会議になっている可能性があります。 14 | 15 | とはいえ、ミーティングでは多様なアジェンダが提出される可能性があるので、最初にミーティングを設計する際には、あらかじめチームメンバー全員が集まることのできるミーティングを設定したほうがいい場合も多いでしょう。そうすることで、チームメンバー個々人の中にとどまっている情報を一斉に共有することができ、各チームメンバーはこのプロセスに参加するだけでプロジェクトの状況や思っていることについて自然と認識を合わせることができるようになります。 16 | 17 | さらに、参加者が漏れなく参加でき、情報をリアルタイムに共有できるようなミーティング環境を整備するようにしてください。これは、前述の素早く効率的な認識合わせを実現するために重要なポイントとなります。具体的には、場所を問わず参加できるリモートミーティング環境の準備、その場で決まったことを共有できるドキュメントシェアサービスの利用、などを行うことになるでしょう。 18 | 19 | ## 定例ミーティングの要素 20 | 21 | 定例ミーティングを最適な状態で実施するには、会議のアジェンダの設定やファシリテーションの方法など、会議環境を整備しておく必要があります。具体的には、プロジェクトの内容やフェーズに応じて下記のような項目についてメンバー間で合意しておきましょう。 22 | 23 | - ミーティンググランドルール 24 | - ファシリテーション方法 25 | - ミーティングでのメンバーの役割 26 | - アジェンダパターン 27 | - アジェンダの活用方法 28 | - 議事録の活用方法 29 | - 継続的改善アプローチの導入 30 | -------------------------------------------------------------------------------- /CODE/v2/.2_ja/tutorial/3-1.md: -------------------------------------------------------------------------------- 1 | # 振り返りを行う 2 | 3 | この記事の内容はプロジェクトスプリントにおける「プロセスドメイン」にあたります。 4 | 5 | プロセスは定期開催のミーティングとそこでのアジェンダの議論を軸としたプロジェクトスプリント固有の仕組みです。この仕組みを通じてプロジェクトの進捗状況の共有、プロジェクトの進め方の継続的な改善・プロジェクトのゴールに向けたマイルストーンの見直しや互いのロールの確認をすることができるようになります。 6 | 7 | この記事では、プロジェクトの進め方の継続的な改善を可能にする方法の一つである、振り返りについて解説します。 8 | 9 | ### **振り返り** 10 | 11 | プロジェクトスプリントではミーティングを通じて継続的にプロジェクトの進め方を改善すること（最適化）を目指しています。これらの最適化のため取り組みを総称して「継続的改善アプローチ」と呼んでおり、これはさらに「テンショントリアージ」と「振り返り」という二つの取り組みに分けられます。 12 | 13 | テンショントリアージが[ミーティングを開催する](2-2.md)でも解説したような毎回のミーティングで行う取り組みであり、主にチームメンバーの今の気持ちにフォーカスしているものであるのに対して、振り返りはチームメンバーが過去のプロジェクトの内容についてレビューするものになります。 14 | 15 | そのため、振り返りはテンショントリアージと違い、ある程度まとまった期間をおいて実施するものであり、またその分必要な時間もテンショントリアージよりも長くなります。 16 | 17 | この「まとまった期間」には、次の二つの種類のものがあり、いずれも併用して実施しましょう。なお、二つのタイミングが揃う場合は、あわせて実施してもかまいません。 18 | 19 | **マイルストーン終了時** 20 | 21 | マイルストーン終了という一つの区切りをタイミングとして設定するものです。このタイミングは、ゴールに対してどれくらい進んだか、を振り返るのに適しています。また、当初予定していた進め方とのズレを振り返り、次のマイルストーン達成に向けて最適なキックオフを実施できるように準備することができます。 22 | 23 | **定期的なタイミング** 24 | 25 | 「何週間おき」「何か月おき」といったような定期的な時間で設定するものです。これは、プロジェクトは不確実でどのような状態になるか予期できないものであるため、とにかく時間で区切って振り返りを行うという取り組みです。たとえば、マイルストーンがいつまでも達成できないという状況がある場合には、強制的に最適化のタイミングが訪れることで問題解決のきっかけになります。 26 | 27 | いずれの場合でも、テンショントリアージ同様、振り返りの際にも、プログレスドメイン・チーミングドメインにおける理想の状態（＝プロジェクトのゴール・マイルストーンとチームのロール）の変遷を参照できるようにしておくと「あのときこうすればよかった」「今後はこうすればよいのではないか」といった気づきを得やすくすることができます。 28 | 29 | 振り返りで取り扱う内容は、特にドメインを限定しません。つまり、具体的なプロジェクトゴールの進捗に向けた取り組み（プログレス）に関することであっても、チームの役割分担（チーミング）に関することであっても、ミーティングの進行（プロセス）に関することであっても、取り扱うことができます。 30 | 31 | 振り返りの実施についてもミーティングのアジェンダアイテムとなるため、事前にアジェンダアイテムの提出を行う必要があります。 32 | 33 | **このページと関係するTips** 34 | 35 | * [代表的な振り返りの手法](../tips/4-5.md) 36 | * [実務で使いやすいロールの設定](../tips/1-5.md) 37 | -------------------------------------------------------------------------------- /CODE/v3/.0_ja/tutorial/section4-2.md: -------------------------------------------------------------------------------- 1 | # プロジェクトゴールとマイルストーンを見直す 2 | 3 | プロジェクトゴールとマイルストーンの見直しは、プロジェクトスプリントにおける「チームでの活動」にあたります。ただし、各チームメンバーが自律的にプロジェクトに参画するためには、プロジェクトゴールやマイルストーンに個人として納得感と達成への現実味が持てていることが重要なので、プロジェクトゴールやマイルストーンの設定とその後の見直しは、「個人の活動」にも大いに関わってくるトピックです。 4 | 5 | [プロジェクトゴールとマイルストーンを設計する](section2-1.md)でも述べたように、プロジェクトゴールやマイルストーンは固定的なものではなく、むしろ環境の変化に応じて柔軟に書き換えられたり進化したりしうるものなので、いつでも見直してよく、また必要に応じて見直さねばならないものと言えます。市場環境の悪化や組織の体制変更、稟議スケジュールの変更といったプロジェクトの外部環境の変化によって調整が必要になることもあれば、プロジェクトを進める中で得られた洞察やチームメンバーの共通認識・役割期待の遷移といった内部的な変化によって進化することもあります。 6 | 7 | ## **見直しが必要となる具体的な場合** 8 | 9 | プロジェクトのゴールの見直しをするべきタイミングは、次のようなときです。 10 | 11 | 1. 外部環境の変化やプロジェクトの進行の結果、プロジェクトゴールそのものを見直したほうが良いことが分かったとき 12 | 2. マイルストーンが予定通りに達成されなかった結果、プロジェクトゴールを見直したほうが良いことがわかったとき 13 | 3. その他何らかの理由でチームメンバーがプロジェクトゴールを見直したほうがよいと考えたとき 14 | 15 | マイルストーンに関しては、プロジェクトゴールよりも頻繁に見直しが必要となることがあるでしょう。見直しをするべきタイミングは、次のようなときです。 16 | 17 | 1. あるマイルストーンが達成されたとき 18 | 2. あるマイルストーンが予定通りに達成されないことが明らかになったとき（予定よりも遅い場合、早い場合のいずれも含む） 19 | 3. プロジェクトゴールに対してあるマイルストーンが適切ではないことが明らかになったとき 20 | 4. プロジェクトゴールが変わったためマイルストーンも変える必要が出てきたとき 21 | 5. その他何らかの理由でチームメンバーがマイルストーンを見直したほうがよいと考えたとき 22 | 23 | ## **見直しの手順** 24 | 25 | プロジェクト内外の環境は絶えず変化し続けているので、それに対応するためには、とにかく定期的にプロジェクトゴールとマイルストーンを見直し、現状に即していないところや違和感のある所がないかを確認することが重要です。プロジェクトゴールやマイルストーンは、全員が集まる場で見直しや調整を繰り返し、違和感を抱くメンバーがいれば納得いくまで議論することで、チームメンバー全員が共通認識と納得感を持てる状態にしていく必要があります。 26 | 27 | プロジェクトゴールやマイルストーンの見直しの実施についてもミーティングのアジェンダアイテムとなるため、事前にアジェンダアイテムの提出を行う必要があります。 28 | 29 | プロジェクトゴールやマイルストーンを変更する際には、変更の前後を並べて見せるなど、その差分を明確にし、積極的に共有するようにしてください。これは、「知らない間にプロジェクトゴールやマイルストーンが変わっていた」と感じるメンバーが出てきてしまわないようにするためです。 30 | 31 | プロジェクトゴールやマイルストーンはプロジェクトにおけるあらゆる場面で参照され、チームメンバーにとって指針となるべきものです。そのため、変更後のプロジェクトゴールやマイルストーンにもチームメンバー全員が確実に納得できている状態を作ってください。 32 | -------------------------------------------------------------------------------- /CODE/v3/.1_ja/tutorial/section4-2.md: -------------------------------------------------------------------------------- 1 | # プロジェクトゴールとマイルストーンを見直す 2 | 3 | プロジェクトゴールとマイルストーンの見直しは、Project Sprintにおけるプログレスドメインにあたります。ただし、各チームメンバーが自律的にプロジェクトに参画するためには、プロジェクトゴールやマイルストーンに個人として納得感と達成への現実味が持てていることが重要なので、プロジェクトゴールやマイルストーンの設定とその後の見直しは、チーミングにも大いに関わってくるトピックです。 4 | 5 | [プロジェクトゴールとマイルストーンを設定する](section2-2.md)でも述べたように、プロジェクトゴールやマイルストーンは固定的なものではなく、むしろ環境の変化に応じて柔軟に書き換えられたり進化したりしうるものなので、いつでも見直してよく、また必要に応じて見直さねばならないものと言えます。市場環境の悪化や組織の体制変更、稟議スケジュールの変更といったプロジェクトの外部環境の変化によって調整が必要になることもあれば、プロジェクトを進める中で得られた洞察やチームメンバーの共通認識・役割期待の遷移といった内部的な変化によって進化することもあります。 6 | 7 | ## **見直しが必要となる具体的な場合** 8 | 9 | プロジェクトのゴールの見直しをするべきタイミングは、次のようなときです。 10 | 11 | 1. 外部環境の変化やプロジェクトの進行の結果、プロジェクトゴールそのものを見直したほうが良いことが分かったとき 12 | 2. マイルストーンが予定通りに達成されなかった結果、プロジェクトゴールを見直したほうが良いことがわかったとき 13 | 3. その他何らかの理由でチームメンバーがプロジェクトゴールを見直したほうがよいと考えたとき 14 | 15 | マイルストーンに関しては、プロジェクトゴールよりも頻繁に見直しが必要となることがあるでしょう。見直しをするべきタイミングは、次のようなときです。 16 | 17 | 1. あるマイルストーンが達成されたとき 18 | 2. あるマイルストーンが予定通りに達成されないことが明らかになったとき（予定よりも遅い場合、早い場合のいずれも含む） 19 | 3. プロジェクトゴールに対してあるマイルストーンが適切ではないことが明らかになったとき 20 | 4. プロジェクトゴールが変わったためマイルストーンも変える必要が出てきたとき 21 | 5. その他何らかの理由でチームメンバーがマイルストーンを見直したほうがよいと考えたとき 22 | 23 | ## **見直しの手順** 24 | 25 | プロジェクト内外の環境は絶えず変化し続けているので、それに対応するためには、とにかく定期的にプロジェクトゴールとマイルストーンを見直し、現状に即していないところや違和感のある所がないかを確認することが重要です。プロジェクトゴールやマイルストーンは、全員が集まる場で見直しや調整を繰り返し、違和感を抱くメンバーがいれば納得いくまで議論することで、チームメンバー全員が共通認識と納得感を持てる状態にしていく必要があります。 26 | 27 | プロジェクトゴールやマイルストーンの見直しの実施についてもミーティングのアジェンダアイテムとなるため、事前にアジェンダアイテムの提出を行う必要があります。 28 | 29 | プロジェクトゴールやマイルストーンを変更する際には、変更の前後を並べて見せるなど、その差分を明確にし、積極的に共有するようにしてください。これは、「知らない間にプロジェクトゴールやマイルストーンが変わっていた」と感じるメンバーが出てきてしまわないようにするためです。 30 | 31 | プロジェクトゴールやマイルストーンはプロジェクトにおけるあらゆる場面で参照され、チームメンバーにとって指針となるべきものです。そのため、変更後のプロジェクトゴールやマイルストーンにもチームメンバー全員が確実に納得できている状態を作ってください。 32 | -------------------------------------------------------------------------------- /CODE/v3/.0_ja/README.md: -------------------------------------------------------------------------------- 1 | # v3.0 2 | 3 | ## **CODEとは** 4 | 5 | **CODE**とは、Project Sprintについて説明したドキュメント群の総称です。 6 | 7 | ### [**Tutorial**](tutorial/) 8 | 9 | Project Sprintの基本的な概念の説明と実践方法が順を追って説明されており、読みながらProject Sprintを実際に導入することができます。 10 | 11 | ### [**Essentials**](../v3.1/essentials.md) 12 | 13 | Project Sprintの核となる行動規範がシンプルに述べられており、そこからProject Sprintが立脚する思想や価値観を理解することができます。 14 | 15 | ### [**Reference**](../v3.2/reference.md) 16 | 17 | Project Sprintの背景にある諸メソッド・概念・文献について記載されており、Project Sprintの効率的な理解が可能になり、また今後のメソッドのアップデートに関わりそうな情報を知ることができます。さらに、背景を知ることでメソッドの応用も可能になります。 18 | 19 | ## **ドキュメントの比較表** 20 | 21 | |ドキュメント名|Tutorial|Essentials|Reference| 22 | |----|----|----|----| 23 | |記載内容|基本的な概念の説明と実践方法|核となる行動規範|背景にある諸メソッド・概念・文献| 24 | |効果|基本の理解、導入手順、具体的なノウハウが理解できる|Project Sprintが立脚する思想や価値観が理解できる|効率的なProject Sprintの理解、メソッドのアップデートに関わりそうな情報、応用のための知識が得られる| 25 | 26 | ## **ラーニングパス** 27 | 28 | ドキュメントの活用方法はあなたがおかれている状況により様々です。主に想定される対象読者別に、おすすめのステップをご紹介します。 29 | 30 | #### **Case1. 自らProject Sprintの導入を主導する方** 31 | 32 | 1. [Tutorial](tutorial/)を通読し、基本的な理解をする 33 | 2. [Essentials](../v3.1/essentials.md)を読み、核となる行動規範や重要な箇所をつかむ 34 | 3. 分からないことがあれば、[Reference](../v3.2/reference.md)を読み、理解を深める 35 | 36 | #### **Case2. Project Sprintを導入することが決まったプロジェクトのメンバーの方** 37 | 38 | 1. [Tutorial](tutorial/)を通読し、基本的な理解をする 39 | 40 | #### **Case3. Project Sprintというものの概要を手早く理解したい方** 41 | 42 | 1. Tutorialの「[Project Sprint 101](tutorial/section1-1.md)」を読む 43 | 44 | #### **Case4. Project Sprintというメソッドの発展に貢献したいと考えてくださる方** 45 | 46 | 1. [Tutorial](tutorial/)を読み、基本的な理解を深める 47 | 2. [Essentials](../v3.1/essentials.md)を読み、核となる行動規範や重要な箇所をつかむ 48 | 3. [Reference](../v3.2/reference.md)を読み、背景にある考え方をより深く理解する 49 | 4. [How to Contibute](../contributing.md)に沿って、気づきを共有したり改善提案を行ったりする 50 | -------------------------------------------------------------------------------- /CODE/v3/.2_ja/practices/meeting_environments.md: -------------------------------------------------------------------------------- 1 | # ミーティング環境についてのノウハウ 2 | 3 | Project Sprintで意図されているミーティングの効果を得るためには、効率的なミーティング環境の構築が欠かせません。「ミーティング環境の最適化自体についてもチームメンバーで議論し、改善していけること」が、Project Sprintのもたらすものですが、この点についてはすでにいくつかのベストプラクティスが得られていますので、ここではそれらを紹介します。 4 | 5 | ## アジェンダの取りまとめ 6 | 7 | プロジェクスプリントではアジェンダの取りまとめが非常に重要です。 8 | 9 | 例えば、次のようなアジェンダの取りまとめ作業が発生します。 10 | 11 | * ミーティング前のアジェンダアイテムの提出と必要な内容の編集 12 | * ミーティング開始後のアジェンダアイテムの追加と必要な内容の編集 13 | * ミーティング開始後のアジェンダアイテムの順番変更 14 | * ミーティング開始後のアジェンダアイテムの繰り越し 15 | 16 | これらの作業はすべてファシリテーターの主導のもと、チームメンバー全員で行われます。そのため、アジェンダを全員で確認・編集でき、かつ同じミーティングの中でのアジェンダアイテムの順番変更、ミーティングをまたいだアジェンダアイテムの移動ができる環境をつくっておきましょう。 17 | 18 | ## ミーティング中の時間管理 19 | 20 | アジェンダ管理に不可欠な前提が、ミーティング中の時間を的確に把握することです。オンライン / オフラインいずれの場合も、ミーティングに参加しているチームメンバーが時間を把握できるよう、目に入る位置にタイマーと時計を配置しましょう。 21 | 22 | タイマーは、「このアジェンダアイテムにあとどれくらい時間をかけられるのか」を把握するのに必要です。 23 | 24 | 時計は、ミーティング時間の開始時間・終了時間を把握するのに必要です。ミーティングの開始時間の遅れ、延長はつねに起こりうるものですが、絶対時刻を示す時計があると開始・終了の基準を把握・調整することができます。 25 | 26 | ## 議事録作成 27 | 28 | ミーティングはチームメンバーで認識のズレをなくし、必要な物事を決める重要な場です。ミーティングの後に各自が必要なタスクに取りかかり、次のミーティングでその結果を持ち寄ることを考えると、ミーティングの内容は極力ミーティングの最中に明文化しながら確認、共有しておくことが効率的かつ効果的です。 29 | 30 | また、レコーダーがメインで議事を記録するものの、内容に間違いがある場合は最も正しい認識を持つ人がその場で修正してしまったほうがよいでしょう。そのため、共同編集ができるドキュメントツールを議事録作成用ツールとして導入し、ミーティング中に画面表示しながらリアルタイムで議事録作成をすることをおすすめします。 31 | 32 | ## ホワイトボード 33 | 34 | ミーティングでは口頭での説明、資料を用いた説明が行われることが多いと考えられますが、それに加え重要なのが手書きの情報による認識合わせです。手書きで図示/文章化することで、きちんとした資料になっていなかったり、口頭で明確に伝えきれていなかったりした内容を伝えやすくなります。これもProject Sprintにおいて重要な「認識のズレをなくす」ことに大いに役立ちます。 35 | 36 | なおここでいうホワイトボードは、オフラインミーティングにおける物理的なものに限りません。オンラインミーティング用のホワイトボードツールもありますので、そういったものを利用してもかまいませんし、むしろ保存のしやすさという点ではこちらのほうが優れている場合もあります。 37 | 38 | また、議事録を画面表示しながらリアルタイムで作成すると、議事録自体がホワイトボードと同様の役割を果たします。この観点からも、議事録の作成とリアルタイム共有は非常に重要です。 39 | -------------------------------------------------------------------------------- /CODE/v3/.3_ja/practices/meeting_environments.md: -------------------------------------------------------------------------------- 1 | # ミーティング環境についてのノウハウ 2 | 3 | Project Sprintで意図されているミーティングの効果を得るためには、効率的なミーティング環境の構築が欠かせません。「ミーティング環境の最適化自体についてもチームメンバーで議論し、改善していけること」が、Project Sprintのもたらすものですが、この点についてはすでにいくつかのベストプラクティスが得られていますので、ここではそれらを紹介します。 4 | 5 | ## アジェンダの取りまとめ 6 | 7 | プロジェクスプリントではアジェンダの取りまとめが非常に重要です。 8 | 9 | 例えば、次のようなアジェンダの取りまとめ作業が発生します。 10 | 11 | * ミーティング前のアジェンダアイテムの提出と必要な内容の編集 12 | * ミーティング開始後のアジェンダアイテムの追加と必要な内容の編集 13 | * ミーティング開始後のアジェンダアイテムの順番変更 14 | * ミーティング開始後のアジェンダアイテムの繰り越し 15 | 16 | これらの作業はすべてファシリテーターの主導のもと、チームメンバー全員で行われます。そのため、アジェンダを全員で確認・編集でき、かつ同じミーティングの中でのアジェンダアイテムの順番変更、ミーティングをまたいだアジェンダアイテムの移動ができる環境をつくっておきましょう。 17 | 18 | ## ミーティング中の時間管理 19 | 20 | アジェンダ管理に不可欠な前提が、ミーティング中の時間を的確に把握することです。オンライン / オフラインいずれの場合も、ミーティングに参加しているチームメンバーが時間を把握できるよう、目に入る位置にタイマーと時計を配置しましょう。 21 | 22 | タイマーは、「このアジェンダアイテムにあとどれくらい時間をかけられるのか」を把握するのに必要です。 23 | 24 | 時計は、ミーティング時間の開始時間・終了時間を把握するのに必要です。ミーティングの開始時間の遅れ、延長はつねに起こりうるものですが、絶対時刻を示す時計があると開始・終了の基準を把握・調整することができます。 25 | 26 | ## 議事録作成 27 | 28 | ミーティングはチームメンバーで認識のズレをなくし、必要な物事を決める重要な場です。ミーティングの後に各自が必要なタスクに取りかかり、次のミーティングでその結果を持ち寄ることを考えると、ミーティングの内容は極力ミーティングの最中に明文化しながら確認、共有しておくことが効率的かつ効果的です。 29 | 30 | また、レコーダーがメインで議事を記録するものの、内容に間違いがある場合は最も正しい認識を持つ人がその場で修正してしまったほうがよいでしょう。そのため、共同編集ができるドキュメントツールを議事録作成用ツールとして導入し、ミーティング中に画面表示しながらリアルタイムで議事録作成をすることをおすすめします。 31 | 32 | ## ホワイトボード 33 | 34 | ミーティングでは口頭での説明、資料を用いた説明が行われることが多いと考えられますが、それに加え重要なのが手書きの情報による認識合わせです。手書きで図示/文章化することで、きちんとした資料になっていなかったり、口頭で明確に伝えきれていなかったりした内容を伝えやすくなります。これもProject Sprintにおいて重要な「認識のズレをなくす」ことに大いに役立ちます。 35 | 36 | なおここでいうホワイトボードは、オフラインミーティングにおける物理的なものに限りません。オンラインミーティング用のホワイトボードツールもありますので、そういったものを利用してもかまいませんし、むしろ保存のしやすさという点ではこちらのほうが優れている場合もあります。 37 | 38 | また、議事録を画面表示しながらリアルタイムで作成すると、議事録自体がホワイトボードと同様の役割を果たします。この観点からも、議事録の作成とリアルタイム共有は非常に重要です。 39 | -------------------------------------------------------------------------------- /CODE/v2/.2_ja/tips/4-4.md: -------------------------------------------------------------------------------- 1 | # 代表的な振り返りの手法 2 | 3 | プロジェクトスプリントにおける振り返りとはチームメンバーが過去のプロジェクトの内容についてレビューし、プログレス・プロセス・チーミングそれぞれのドメインにおける活動を改善する取り組みです。 4 | 5 | 一般的な「振り返り」の手法は様々なものがありますが、ここでは比較的簡単に導入でき、汎用性も高い二つの手法を例として紹介します。 6 | 7 | ### **KPT(ケプト)** 8 | 9 | KPTは、チームメンバーがこれまでのプロジェクトを振り返って感じた「良かったこと(Keep)」「改善したいこと(Problem)」を共有し、「今後改善のために取り組みたいこと(Try)」を話し合う手法です。 10 | 11 | **手順例** 12 | 13 | 1. チームメンバーがそれぞれ Keep, Problemを付箋に記入する。 14 | 2. 記入が終わったら、チームメンバーがそれぞれ記入したKeep, Problemを説明しながらホワイトボードに貼って共有する。 15 | 3. ホワイトボードに貼られている付箋のうち、関連があったりテーマをまとめられそうなものはまとめる。 16 | 4. 共有内容を受けてチームメンバーがそれぞれTryを付箋に記入する。 17 | 5. 記入が終わったら、チームメンバーがそれぞれ記入したTryを説明しながらホワイトボードに貼って共有する。 18 | 6. Tryのうち実際に取り組むものを決める。 19 | 20 | ### **+/Δ(プラス/デルタ)** 21 | 22 | \+/Δは、チームメンバーがこれまでのプロジェクトを振り返って感じた「プラス=うまくいっていること、続けたいこと」、「デルタ=改善したいこと」を共有する手法です。KPTと似ていますが、意見の分け方が2つになるため、よりシンプルな実施が可能です。 23 | 24 | **手順例** 25 | 26 | 1. チームメンバーがそれぞれ プラス, デルタを付箋に記入する。 27 | 2. 記入が終わったら、チームメンバーがそれぞれ記入したプラス, デルタを説明しながらホワイトボードに貼って共有する。 28 | 3. ホワイトボードに貼られている付箋のうち、関連があったりテーマをまとめられそうなものはまとめる。 29 | 4. 共有内容を受けて、改善したいことについては改善するためのアイデアをチームで議論する。 30 | 5. 出たアイデアのうち、実際に取り組むものを決める。 31 | 32 | ### **YWT(ワイダブリューティー)** 33 | 34 | YWTは、チームメンバーがこれまでのプロジェクトにおいて「やったこと(Y)」を共有し、それを通じて「わかったこと(W)」を共有し、「つぎにすること(T)」を話し合う手法です。最初に実際に経験したことを見直すところからスタートすることで、より足元についた議論をすることができるという利点があります。 35 | 36 | **手順例** 37 | 38 | 1. チームメンバーがそれぞれ「やったこと(Y)」を付箋に記入する。 39 | 2. 記入が終わったら、チームメンバーがそれぞれ記入した内容を説明しながらホワイトボードに貼って共有する。 40 | 3. ホワイトボードに貼られている付箋のうち、関連があったりテーマをまとめられそうなものはまとめる。 41 | 4. チームメンバーがそれぞれ「わかったこと(W)」を付箋に記入する。 42 | 5. 記入が終わったら、チームメンバーがそれぞれ記入した内容を説明しながらホワイトボードに貼って共有する。 43 | 6. ホワイトボードに貼られている付箋のうち、関連があったりテーマをまとめられそうなものはまとめる。 44 | 7. 共有内容を受けてチームメンバーがそれぞれ「つぎにすること(T)」を付箋に記入する。 45 | 8. 記入が終わったら、チームメンバーがそれぞれ記入した内容を説明しながらホワイトボードに貼って共有する。 46 | 9. 「つぎにすること(T)」のうち実際に取り組むものを決める。 47 | -------------------------------------------------------------------------------- /CODE/v3/.0_ja/tutorial/section3-3.md: -------------------------------------------------------------------------------- 1 | # ミーティング環境についてのノウハウ 2 | 3 | Project Sprintで意図されているミーティングの効果を得るためには、効率的なミーティング環境の構築が欠かせません。「ミーティング環境の最適化自体についてもチームメンバーで議論し、改善していけること」が、Project Sprintのもたらすものですが、この点についてはすでにいくつかのベストプラクティスが得られていますので、ここではそれらを紹介します。 4 | 5 | ### **アジェンダの取りまとめ** 6 | 7 | プロジェクスプリントではアジェンダの取りまとめが非常に重要です。 8 | 9 | 例えば、次のようなアジェンダの取りまとめ作業が発生します。 10 | 11 | * ミーティング前のアジェンダアイテムの提出と必要な内容の編集 12 | * ミーティング開始後のアジェンダアイテムの追加と必要な内容の編集 13 | * ミーティング開始後のアジェンダアイテムの順番変更 14 | * ミーティング開始後のアジェンダアイテムの繰り越し 15 | 16 | これらの作業はすべてファシリテーターの主導のもと、チームメンバー全員で行われます。そのため、アジェンダを全員で確認・編集でき、かつ同じミーティングの中でのアジェンダアイテムの順番変更、ミーティングをまたいだアジェンダアイテムの移動ができる環境をつくっておきましょう。 17 | 18 | ### **ミーティング中の時間管理** 19 | 20 | アジェンダ管理に不可欠な前提が、ミーティング中の時間を的確に把握することです。オンライン / オフラインいずれの場合も、ミーティングに参加しているチームメンバーが時間を把握できるよう、目に入る位置にタイマーと時計を配置しましょう。 21 | 22 | タイマーは、「このアジェンダアイテムにあとどれくらい時間をかけられるのか」を把握するのに必要です。 23 | 24 | 時計は、ミーティング時間の開始時間・終了時間を把握するのに必要です。ミーティングの開始時間の遅れ、延長はつねに起こりうるものですが、絶対時刻を示す時計があると開始・終了の基準を把握・調整することができます。 25 | 26 | ### **議事録作成** 27 | 28 | ミーティングはチームメンバーで認識のズレをなくし、必要な物事を決める重要な場です。ミーティングの後に各自が必要なタスクに取りかかり、次のミーティングでその結果を持ち寄ることを考えると、ミーティングの内容は極力ミーティングの最中に明文化しながら確認、共有しておくことが効率的かつ効果的です。 29 | 30 | また、レコーダーがメインで議事を記録するものの、内容に間違いがある場合は最も正しい認識を持つ人がその場で修正してしまったほうがよいでしょう。そのため、共同編集ができるドキュメントツールを議事録作成用ツールとして導入し、ミーティング中に画面表示しながらリアルタイムで議事録作成をすることをおすすめします。 31 | 32 | ### **ホワイトボード** 33 | 34 | ミーティングでは口頭での説明、資料を用いた説明が行われることが多いと考えられますが、それに加え重要なのが手書きの情報による認識合わせです。手書きで図示/文章化することで、きちんとした資料になっていなかったり、口頭で明確に伝えきれていなかったりした内容を伝えやすくなります。これもProject Sprintにおいて重要な「認識のズレをなくす」ことに大いに役立ちます。 35 | 36 | なおここでいうホワイトボードは、オフラインミーティングにおける物理的なものに限りません。オンラインミーティング用のホワイトボードツールもありますので、そういったものを利用してもかまいませんし、むしろ保存のしやすさという点ではこちらのほうが優れている場合もあります。 37 | 38 | また、議事録を画面表示しながらリアルタイムで作成すると、議事録自体がホワイトボードと同様の役割を果たします。この観点からも、議事録の作成とリアルタイム共有は非常に重要です。 39 | -------------------------------------------------------------------------------- /CODE/v3/.1_ja/tutorial/section3-3.md: -------------------------------------------------------------------------------- 1 | # ミーティング環境についてのノウハウ 2 | 3 | Project Sprintで意図されているミーティングの効果を得るためには、効率的なミーティング環境の構築が欠かせません。「ミーティング環境の最適化自体についてもチームメンバーで議論し、改善していけること」が、Project Sprintのもたらすものですが、この点についてはすでにいくつかのベストプラクティスが得られていますので、ここではそれらを紹介します。 4 | 5 | ### **アジェンダの取りまとめ** 6 | 7 | プロジェクスプリントではアジェンダの取りまとめが非常に重要です。 8 | 9 | 例えば、次のようなアジェンダの取りまとめ作業が発生します。 10 | 11 | * ミーティング前のアジェンダアイテムの提出と必要な内容の編集 12 | * ミーティング開始後のアジェンダアイテムの追加と必要な内容の編集 13 | * ミーティング開始後のアジェンダアイテムの順番変更 14 | * ミーティング開始後のアジェンダアイテムの繰り越し 15 | 16 | これらの作業はすべてファシリテーターの主導のもと、チームメンバー全員で行われます。そのため、アジェンダを全員で確認・編集でき、かつ同じミーティングの中でのアジェンダアイテムの順番変更、ミーティングをまたいだアジェンダアイテムの移動ができる環境をつくっておきましょう。 17 | 18 | ### **ミーティング中の時間管理** 19 | 20 | アジェンダ管理に不可欠な前提が、ミーティング中の時間を的確に把握することです。オンライン / オフラインいずれの場合も、ミーティングに参加しているチームメンバーが時間を把握できるよう、目に入る位置にタイマーと時計を配置しましょう。 21 | 22 | タイマーは、「このアジェンダアイテムにあとどれくらい時間をかけられるのか」を把握するのに必要です。 23 | 24 | 時計は、ミーティング時間の開始時間・終了時間を把握するのに必要です。ミーティングの開始時間の遅れ、延長はつねに起こりうるものですが、絶対時刻を示す時計があると開始・終了の基準を把握・調整することができます。 25 | 26 | ### **議事録作成** 27 | 28 | ミーティングはチームメンバーで認識のズレをなくし、必要な物事を決める重要な場です。ミーティングの後に各自が必要なタスクに取りかかり、次のミーティングでその結果を持ち寄ることを考えると、ミーティングの内容は極力ミーティングの最中に明文化しながら確認、共有しておくことが効率的かつ効果的です。 29 | 30 | また、レコーダーがメインで議事を記録するものの、内容に間違いがある場合は最も正しい認識を持つ人がその場で修正してしまったほうがよいでしょう。そのため、共同編集ができるドキュメントツールを議事録作成用ツールとして導入し、ミーティング中に画面表示しながらリアルタイムで議事録作成をすることをおすすめします。 31 | 32 | ### **ホワイトボード** 33 | 34 | ミーティングでは口頭での説明、資料を用いた説明が行われることが多いと考えられますが、それに加え重要なのが手書きの情報による認識合わせです。手書きで図示/文章化することで、きちんとした資料になっていなかったり、口頭で明確に伝えきれていなかったりした内容を伝えやすくなります。これもProject Sprintにおいて重要な「認識のズレをなくす」ことに大いに役立ちます。 35 | 36 | なおここでいうホワイトボードは、オフラインミーティングにおける物理的なものに限りません。オンラインミーティング用のホワイトボードツールもありますので、そういったものを利用してもかまいませんし、むしろ保存のしやすさという点ではこちらのほうが優れている場合もあります。 37 | 38 | また、議事録を画面表示しながらリアルタイムで作成すると、議事録自体がホワイトボードと同様の役割を果たします。この観点からも、議事録の作成とリアルタイム共有は非常に重要です。 39 | -------------------------------------------------------------------------------- /CODE/v3/.1_ja/tutorial/section2-3.md: -------------------------------------------------------------------------------- 1 | # チームメンバーを知り、ロールを設定する 2 | 3 | チームメンバーを知り、ロールを設定することは、Project Sprintにおけるチーミングドメインにあたります。各チームメンバーの責任・役割・期待値を共有することで、自分の責任・役割・期待値が明確になり、自律的な行動が取れるようになります。 4 | 5 | チーミングの「理想の状態」の条件のひとつは、「チームメンバー各々の各自の責任・役割・期待値が共有されており、各メンバーの認識に齟齬がない」ということです。言い換えると、あるチームメンバーが「あの人はこれをやってくれるだろう」と考えたとき、そのチームメンバーも「これは私がやるべきことだ」と考えている状態(**期待値の一致**)です。 6 | 7 | また、プロジェクトの「理想の状態」の条件のひとつに、「チームにおける自分の責任・役割・期待値に納得感が持てており、自分がチームのために何をすべきかを自律的に判断し実際に行動できている」ことが挙げられます。つまり、自分に担うことができる役割であれば、何であれ必要に応じていつでも担おうとするマインドセットがあること (**自発的な役割の引き受け**)です。 8 | 9 | Project Sprintでは、プロセスでの期待値の共有とロールの設定によって、これらを実現します。 10 | 11 | チーミングの「理想の状態」には、明確な到達点がありません。なぜなら「ここまで達成したら理想のチームだ！」というものが決めにくいからです。そこでProject Sprintでは、常に「チームが今の時点より良い状態になること」を目指します。 12 | 13 | ### **チームメンバーの基本情報** 14 | 15 | より良いチームを目指す前提となるのが、チームメンバーに関する理解です。例えば、プロジェクトに関わるメンバーに次のことを確認しておきましょう。 16 | 17 | * あなたの名前はなんですか？普段はどのような組織や会社に所属している人ですか？ 18 | * あなたはどのような人ですか？例えばスキルセットはどのようなものがありますか？これまでにどのような仕事にかかわってきましたか？ 19 | * あなたがこのプロジェクトに対して貢献を期待されていることはなんですか？ 20 | * あなたはプロジェクトに対する専任メンバーですか、兼任メンバーですか？いずれにせよ、あなたがこのプロジェクトに割ける時間はどのくらいですか？ 21 | 22 | こうしたことをプロジェクトの最初に知っておくことは、続くロールの設定における助けになります。 23 | 24 | ### **ロールの共有** 25 | 26 | Project Sprintでは、チームメンバー個々人の役割のことをロールと呼びます。ロールとチームメンバーは必ずしも一対一の関係である必要はありません。つまり、一人の人が複数のロールを担うこともありますし、またあるロールを複数の人が担うこともできます。 27 | 28 | また、設定するロールの個数には制限がありませんし、「必ず設定すべきロール」というものもありません。ロールの定義に関しても、必要なのはチームメンバーで合意することのみです。プロジェクトの性質に応じて、必要な役割分担をチームメンバーで議論し、ロールとして明文化しましょう。 29 | 30 | ### **ロールシートの利用** 31 | 32 | ロールとチームメンバーは一対一の関係になるとは限らず、またロールの種類も決まったものはない一方、決まったロールはきちんと明文化して合意する必要があります。 33 | 34 | そのため、「いまのロールの状況」を明文化して参照できる状態にしておくための「ロールシート」を利用することをおすすめします。 35 | 36 | ロールシートには、例えば次のような要素を盛り込みます。 37 | 38 | * ロール名 39 | * ロールが果たす責任(どういう目的でそのロールが必要とされ、何を果たすロールなのか） 40 | * そのロールを担う人 41 | 42 | これらを一つのドキュメントとしてまとめ、常に最新のものに更新しておくことで、いまの各メンバーに対する期待値を把握することや、期待とズレがあった場合の議論が可能になります。 43 | -------------------------------------------------------------------------------- /CODE/v3/.0_ja/tutorial/README.md: -------------------------------------------------------------------------------- 1 | # Tutorial 2 | 3 | このドキュメント群では、Project Sprintの基本的な概念の説明と実践方法が順を追って説明されています。 4 | 5 | 全体を通して4つの章から構成されており、上から順番に読み進めていくことで、Project Sprintを実際のプロジェクトで使うことができるようになっています。 6 | 7 | まだProject Sprintを導入していない人が学習のための最初の一歩としては使うことはもちろん、すでにProject Sprintを導入している人も、実施のための基盤がためとして読むことができます。 8 | 9 | ## **1. はじめに** 10 | 11 | 最初に読んでほしいProject Sprintの概要を紹介しています。 12 | 13 | 1.1. [Project Sprint 101](section1-1.md) 14 | 15 | ## **2. 準備しよう** 16 | 17 | Project Sprintを始めるにあたって準備しなければいけないことを記載しています。まずはここで決めた仕組みをもとにして、Project Sprintがスタートします。 18 | 19 | 2.1. [プロジェクトの環境整備](section2-0.md) 20 | 21 | 2.2. [プロジェクトゴールとマイルストーンを設定する](section2-1.md) 22 | 23 | 2.2.1. [プロジェクトゴールやマイルストーンの設定が難しいときの始め方](section2-1-1.md) 24 | 25 | 2.2.2. [プロジェクトの時間軸を整理するための便利な考え方：トラックとフェーズ](section2-1-2.md) 26 | 27 | 2.3. [チームメンバーを知り、ロールを設定する](section2-2.md) 28 | 29 | 2.4. [ミーティングを設計する](section2-3.md) 30 | 31 | ## **3. やってみよう** 32 | 33 | Project Sprintによって実際にプロジェクトを運営していく方法を記載しています。「準備しよう」で作った仕組みを動かしていきましょう。 34 | 35 | 3.1. [ミーティングの準備をする](broken-reference/) 36 | 37 | 3.2. [ミーティングを開催する](section3-2.md) 38 | 39 | 3.2.1. [タスクを設定する](section3-2-1.md) 40 | 41 | 3.3. [ミーティング環境についてのノウハウ](section3-3.md) 42 | 43 | ## **4. 改善しよう** 44 | 45 | Project Sprintによってプロジェクトを改善する仕組みを記載しています。「やってみよう」で行ったことをもとに、どんどんプロジェクトを改善していきましょう。 46 | 47 | 4.1. [継続的改善アプローチ](section4-1.md) 48 | 49 | 4.1.1. [過去の経験を活かす：振り返り](section4-1-1.md) 50 | 51 | 4.1.2. [現在の心の声を活用する：テンショントリアージ](section4-1-2.md) 52 | 53 | 4.1.3. [未来の展望と仮説：ロールセッション](section4-1-3.md) 54 | 55 | 4.2. [プロジェクトゴールとマイルストーンを見直す](section4-2.md) 56 | 57 | 4.3. [ロールを確認する](section4-3.md) 58 | 59 | 4.4. [Project Sprintの成功指標](section4-4.md) 60 | 61 | ## **5. さらに興味のある方へ** 62 | 63 | Project Sprintを学習・実践し、自らもメソッド作りに改善提案や貢献をしたいと思われる方向けに、その方法について記載しています。 64 | 65 | 5.1. [コントリビューターとしての参加の方法](https://github.com/copilot-jp/project-sprint/wiki) 66 | -------------------------------------------------------------------------------- /CODE/v3/.2_ja/theories/tracks.md: -------------------------------------------------------------------------------- 1 | # トラックとは 2 | 3 | ## トラックとは 4 | 5 | トラックとは、それぞれが強い依存関係を持たず、設定した役割や目標に沿って自律自走できるプロジェクト内の単位です。 6 | 7 | [Project Sprint 101](101.md)で説明したように、Project Sprintではプロジェクトを「全体」の達成に寄与するひとつの「部分」として捉えます。トラックも同様に、プロジェクトという全体の達成に必要なそれぞれの部分といえます。プロジェクトゴール達成を目指す過程を、それぞれが強い依存関係を持たず自律的に作業を進めることができる単位にまでブレイクダウンしたものを、トラックと呼びます。 8 | 9 | 必要なトラックの数や種類はプロジェクトごとに、またプロジェクトのフェーズにより異なります。一般的には、プロジェクト全体の状態を把握するためのメインのトラックをまず設定してマイルストーンを置き、そのマイルストーンの達成のために必要なものを要素ごとに分割することで、その他のトラックが置かれます。 10 | 11 | プロジェクトの構想期はまだプロジェクトゴールが明確化されていないため、トラックへのブレイクダウンも進まないことが多いでしょう。その後の形成期や自律準備期において、プロジェクトゴールやマイルストーン、必要な成果物などが明確になってくるにつれて、トラックの分割が進みます。 12 | 13 | ## トラックの分化と統合 14 | 15 | トラックを設定する際、まずは「このようなトラックが必要だろう」という仮説を立て、チームメンバーを決めます。この段階ではマイルストーンが置かれておらず、定例ミーティングのみのトラックになるかもしれません。その後定例ミーティングで認識合わせと意思決定を重ねることによってトラックのゴールやマイルストーンが明文化されていきます。 16 | 17 | トラック同士は、依存関係が少ない疎結合な状態になるように設定します。トラック同士の依存関係は、個々のトラックの自律的な動きの妨げとなるからです。 18 | 19 | とはいえ、最初にトラックを設定する場合やひとつのトラックを複数に分割する場合においては、他のトラックとの境界が曖昧で依存関係が比較的強く残り、他のトラックと密接に協力して作業する必要が出ることもあります。このような場合は、トラックごとの情報を整理して透明性を高め、定期的なミーティングで認識合わせを行いながら、最小限の協力で活動できるよう相互に体制を整えていきます。 20 | 21 | こうして見てくると、トラックにも[プロジェクトライフサイクル](project_lifecycle.md)と同様の考え方が適用できることが分かってくるでしょう。必要なトラックの仮説を立てチームメンバーを決めるのが構想期、その後トラックのゴールやマイルストーンを明文化するのが形成期、他のトラックとの連携体制や定例ミーティングの形を整えて自律に向かうのがトラックの自律準備期に当たります。 22 | 23 | 上述のように、自律準備期までは他のトラックとの境界が曖昧なことも多くあります。また、自律推進期に入ってからも、環境の変化に伴い他トラックとの相互依存関係が密になり、自律的な推進が難しくなることもあるでしょう。その場合には、一旦自律準備期に戻ったと捉えて情報や体制を整理し、改めて定期的な同期・連携による一定程度予測可能な相互作用のみでそれぞれが自律的に動ける状態に近づけていきます。 24 | 25 | ## トラックの分割例 26 | 27 | 例えば、あるWebサイトを立ち上げるプロジェクトを考えたとき（プロジェクトゴールは「Webサイトの完成」）、Webサイトのデザインを考えるチームと、Webサイトのシステム環境を整える作業は、一定程度関連はしながらも並行して進行します。このとき、それぞれの作業領域をトラックとして分割し、トラックごとにマイルストーンを分けて考えることで、よりプロジェクトを構造化して捉えられるようになります。 28 | 29 | 上述のWebサイトの例のようなトラック分割だけでなく、営業・マーケティング・CSといったロールベースでのトラック分割や、プロダクトごと・機能ごとのトラック分割など、プロジェクトの性質や規模によって、設定されるトラックは様々です。 30 | -------------------------------------------------------------------------------- /CODE/v3/.0_ja/tutorial/section2-2.md: -------------------------------------------------------------------------------- 1 | # チームメンバーを知り、ロールを設定する 2 | 3 | チームメンバーを知り、ロールを設定することは、プロジェクトスプリントにおける「チームとしての活動」にあたります。各チームメンバーの責任・役割・期待値を共有することで、自分の責任・役割・期待値が明確になり、「個人の活動」において自律的な行動が取れるようになります。 4 | 5 | チームとしての活動の「理想の状態」の条件のひとつは、「チームメンバー各々の各自の責任・役割・期待値が共有されており、各メンバーの認識に齟齬がない」ということです。言い換えると、あるチームメンバーが「あの人はこれをやってくれるだろう」と考えたとき、そのチームメンバーも「これは私がやるべきことだ」と考えている状態(**期待値の一致**)です。 6 | 7 | また、個人の活動における「理想の状態」の条件のひとつに、「チームにおける自分の責任・役割・期待値に納得感が持てており、自分がチームのために何をすべきかを自律的に判断し実際に行動できている」ことが挙げられます。つまり、自分に担うことができる役割であれば、何であれ必要に応じていつでも担おうとするマインドセットがあること (**自発的な役割の引き受け**)です。 8 | 9 | Project Sprintでは、プロセスでの期待値の共有とロールの設定によって、これらを実現します。 10 | 11 | チームとしての活動の「理想の状態」には、明確な到達点がありません。なぜなら「ここまで達成したら理想のチームだ！」というものが決めにくいからです。そこでプロジェクトスプリントでは、常に「チームが今の時点より良い状態になること」を目指します。 12 | 13 | ### **チームメンバーの基本情報** 14 | 15 | より良いチームを目指す前提となるのが、チームメンバーに関する理解です。例えば、プロジェクトに関わるメンバーに次のことを確認しておきましょう。 16 | 17 | * あなたの名前はなんですか？普段はどのような組織や会社に所属している人ですか？ 18 | * あなたはどのような人ですか？例えばスキルセットはどのようなものがありますか？これまでにどのような仕事にかかわってきましたか？ 19 | * あなたがこのプロジェクトに対して貢献を期待されていることはなんですか？ 20 | * あなたはプロジェクトに対する専任メンバーですか、兼任メンバーですか？いずれにせよ、あなたがこのプロジェクトに割ける時間はどのくらいですか？ 21 | 22 | こうしたことをプロジェクトの最初に知っておくことは、続くロールの設定における助けになります。 23 | 24 | ### **ロールの共有** 25 | 26 | Project Sprintでは、チームメンバー個々人の役割のことをロールと呼びます。ロールとチームメンバーは必ずしも一対一の関係である必要はありません。つまり、一人の人が複数のロールを担うこともありますし、またあるロールを複数の人が担うこともできます。 27 | 28 | また、設定するロールの個数には制限がありませんし、「必ず設定すべきロール」というものもありません。ロールの定義に関しても、必要なのはチームメンバーで合意することのみです。プロジェクトの性質に応じて、必要な役割分担をチームメンバーで議論し、ロールとして明文化しましょう。 29 | 30 | ### **ロールシートの利用** 31 | 32 | ロールとチームメンバーは一対一の関係になるとは限らず、またロールの種類も決まったものはない一方、決まったロールはきちんと明文化して合意する必要があります。 33 | 34 | そのため、「いまのロールの状況」を明文化して参照できる状態にしておくための「ロールシート」を利用することをおすすめします。 35 | 36 | ロールシートには、例えば次のような要素を盛り込みます。 37 | 38 | * ロール名 39 | * ロールが果たす責任(どういう目的でそのロールが必要とされ、何を果たすロールなのか） 40 | * そのロールを担う人 41 | 42 | これらを一つのドキュメントとしてまとめ、常に最新のものに更新しておくことで、いまの各メンバーに対する期待値を把握することや、期待とズレがあった場合の議論が可能になります。 43 | -------------------------------------------------------------------------------- /CODE/v2/.2_ja/tips/3-1.md: -------------------------------------------------------------------------------- 1 | # ミーティングを定例開催にする理由 2 | 3 | [ミーティングを設計する](../tutorial/1-3.md)で記述したように、プロジェクトスプリントではミーティングを定期開催とすることが必要です。ここでは、その理由について解説します。 4 | 5 | #### **1. 定期的に振り返りを行うことで、プロジェクトを最適化できる。** 6 | 7 | 不確実性の高いプロジェクトにおいては、マイルストーン達成までの道のりは整然と進むわけではありません。各フェーズの中で、立ち上げ、計画、実行、終結といったそれぞれの段階が重なり合い影響し合いながら進行していくのです。そこで、定期的なミーティングでの振り返りによってメンバー間の認識を都度擦り合わせ、必要に応じて調整を加えることで、プロジェクトを最適化する必要があります。 8 | 9 | ![定期的な振り返りの必要性](../images/process.png) （PMBOKの概念を参照） 10 | 11 | #### **2. 前回のミーティングから今回のミーティングまでの差分をキャッチアップする機会を保証できる。** 12 | 13 | プロジェクトはルーチンワークと違って不確実性が高く、目的も変化しやすいものです。社会や組織の変化が激しいなかでも、定期的に集まることで、各チームメンバーが経験したこと・変化を確実に、定期的に吸収することができます。これらをインプットするからこそ、プロジェクトのゴールやマイルストーンをみんなで合意して変化させることも可能になります。 14 | 15 | **プロジェクトとルーチンワークの違い** 16 | 17 | ![プロジェクトとルーチンワークの違い](../images/project.png) 18 | 19 | #### **3. チームメンバーのスケジュールの調整コストが低くなる。** 20 | 21 | 社内外の多様なメンバーが参加するようなプロジェクトも多い昨今では、都度スケジュール調整をしているとそれだけで時間がかかります。そのため、あらかじめスケジュール設定をしておく方が効率がよいのです。また都度ミーティングを調整していると必要なタイミングでミーティング開催ができません。これは、必要十分な参加者が一度に集まって素早く効率的に意思決定をするというプロジェクトスプリントの利点を損ねてしまいます。 22 | 23 | #### **4. 同じ曜日・時間に開催されることで、他のチームの人が共有のために覗きに来やすくなる。** 24 | 25 | あるアジェンダアイテムについて特定のゲストを呼び、スペシャリストとしてのコメントをもらうといったことはよくありますが、定期的な時間・曜日があらかじめ設定されていると都度の調整が必要なく、すでにある時間に招待すればよいため、効率的です。 26 | 27 | #### **5. 定期的に期間を区切るほうがタスクの粒度を作りやすい。** 28 | 29 | 定期的な期間、例えば「1週間でできること」という基準となる間隔をもつことで、これぐらいのタスクであればできるかな、という予測がしやすくなります。現実的なタスクを作成することは、アウトプットを確実につくること、ひいてはアジェンダの確度を上げることにつながります。個々人のアクティビティであるタスク実行をプロジェクト全体の成果に反映させるプロセスを定期的に繰り返すことによって、プロジェクトが最適化されていきます。 30 | 31 | #### **6. 定期開催とすると業務のリズムをつくりやすいのでタスクが消化しやすくなる。** 32 | 33 | 例えば毎週月曜日はこのミーティングがあるのでこういう作業時間を確保しておこう、など。個々のメンバーが作業計画を立てやすくなります。 34 | 35 | #### **7. 定期的なプロジェクトの記録になる。** 36 | 37 | 会議のアジェンダ、議事録、タスクの進捗報告が定点観測的に残ります。これは振り返りの際に参照しやすいログとなるほか、新しいメンバーが参加した際の読みやすさも担保します（過去の情報をむやみに読むよりは、定期的に出力されたものをマイルストーンに沿って読むほうが理解しやすいため）。また、こうしたログが残っていれば、別のプロジェクトを開始する際、過去のプロジェクトがこのようにすすんだのだという参考やひな形にしやすくなります。 38 | -------------------------------------------------------------------------------- /CODE/v2/.0_en/tutorial/README.md: -------------------------------------------------------------------------------- 1 | # Tutorial 2 | 3 | This set of documents provides a step-by-step explanation of the basic concepts and practices of Project Sprint. 4 | 5 | There are four chapters throughout, and by reading them in order from the top, you will be able to use Project Sprint in your actual projects. 6 | 7 | It can be used as a first step for learning if you haven't done Project Sprint yet, and it can also be read by those who have already done Project Sprint as a foundation for implementation. 8 | 9 | ## Table of Contents 10 | 11 | **Introduction** 12 | 13 | This is an overview of Project Sprint that you should read first. 14 | 15 | * [Project Sprint 101](project-sprint-101.md) 16 | 17 | **Let's Get Ready** 18 | 19 | This section describes what you need to do to prepare for starting Project Sprint. The first step is to start Project Sprint based on the structure you have decided here. 20 | 21 | * [Setting Goals and Milestones for a Project](1-1.md) 22 | * [Knowing your Team Members and Setting their Roles](1-2.md) 23 | * [Designing a Meeting](1-3.md) 24 | 25 | **Let's do it!** 26 | 27 | Let's try to describe how to actually manage the project through Project Sprint. Let's put the system we created in "Let's Prepare" into action. 28 | 29 | * [Preparing for a Meeting](2-1.md) 30 | * [Holding a Meeting](2-2.md) 31 | 32 | **Let's improve it** 33 | 34 | Project Sprint is a method that also has a mechanism to improve the project management. Let's continue to improve the project based on what we have done in "Let's try". 35 | 36 | * [Conducting a Reflection](3-1.md) 37 | * [Reviewing Project Goals and Milestones](3-2.md) 38 | * [Checking Roles](3-3.md) 39 | 40 | **For those who want to learn more** 41 | 42 | This section describes the user community for learning Project Sprint and contributing to method creation yourself. 43 | 44 | * [User Community](user-community.md) 45 | -------------------------------------------------------------------------------- /CODE/v2/.0_en/tips/tips4.md: -------------------------------------------------------------------------------- 1 | # Tips4: Preparing Project Environments 2 | 3 | This article describes the project environment that helps in the implementation of Project Sprint. 4 | 5 | What we talk about here is not much different from the elements that are generally talked about in project management. However, in Project Sprint, the main focus of all those elements should be on how to ensure information transparency. 6 | 7 | In Project Sprint, it is necessary to create "consensus with team members' understanding" at various times, including setting project goals and milestones, and setting and adjusting roles. For this reason, it is important to consider what kind of project environment should be prepared in order to create conviction = to eliminate information gaps among team members. 8 | 9 | The elements described here are just one example. For each project, it is also important to discuss among team members to create the most optimal project environment. 10 | 11 | - File Management: Provide a file management environment where all project members have access to the same information. 12 | - Schedule Management: Try to share personal calendars among project members for as long as necessary to coordinate schedules. This means that team members' schedule statuses are in one place and meetings can be scheduled and rescheduled efficiently, rather than having to coordinate each time via email. 13 | - Task Management: Have a centralized place to manage the tasks that arise throughout the project. By having a place to manage tasks that are shared by the project team, rather than by individuals, it is easier to communicate with each other to see what needs to be done / was intended to be done. 14 | 15 | Please refer to the other tips for milestone management (progress), role management (teaming), and meeting management (process), which are necessary environments in the three domains of Project Sprint. 16 | -------------------------------------------------------------------------------- /CODE/v3/.2_ja/theories_and_practices.md: -------------------------------------------------------------------------------- 1 | # Theories and Practices 2 | 3 | このドキュメント群では、Project Sprintの基本的な概念の説明と実践方法が順を追って説明されます。理論編であるTheories及び実践編であるPracticesから成り、それぞれを上から順番に読み進めていくことで、Project Sprintを概念として理解した上で、実際のプロジェクトに取り入れて使うための知識を得ることができるようになっています。 4 | 5 | すでにプロジェクトマネジメントの経験がある方が新しい方法論としてProject Sprintをインプットするために読むことはもちろん、すでにProject Sprintを導入している方も、効果的な活用のための基盤固めとして読むことができます。 6 | 7 | |Contents|Theories|Practices| 8 | | ---- | ---- | ---- | 9 | |Project Sprint 101|[Project Sprint 101](theories/101.md)|WIP| 10 | |プロジェクトライフサイクル|[5つのサイクル](theories/project_lifecycle.md)|WIP| 11 | |プロジェクトゴールとマイルストーン|[プロジェクトゴールとは](theories/project_goals.md)
[マイルストーンとは](theories/milestones.md)| [プロジェクトゴールの設定](practices/project_goals.md)
[マイルストーンの設定](practices/milestones.md)
[プロジェクトゴールとマイルストーンの見直し](practices/reviewing_project_goals_and_milestones.md)| 12 | |トラック|[トラックとは](theories/tracks.md)|[トラックの設定](practices/tracks.md)| 13 | |期待値とロール| [期待値とロール](theories/rolls.md)|[チームメンバーの理解とロールシートの利用](practices/rolls.md)
[ロールの確認](practices/reviewing_rolls.md)| 14 | |定例ミーティング|[定例ミーティングの重要性](theories/meetings.md)|[ミーティングの設計](practices/meetings.md)
[ミーティングの進行方法](practices/holding_meetings.md)
[タスクの設定](practices/tasks.md)
[ミーティングロールの確認](practices/meeting_rolls.md)
[ミーティング環境についてのノウハウ](practices/meeting_environments.md)| 15 | |アジェンダ|[アジェンダとは](theories/agenda.md)|[アジェンダアイテムの要素](practices/agenda.md)| 16 | |プロジェクトの環境整備|[プロジェクトの環境整備](theories/project_environments.md)| [情報共有環境の構築](practices/project_environments.md)
[スタンドアップの導入](practices/stand-up_meetings.md)| 17 | |継続的改善アプローチ|[継続的改善アプローチ](theories/continuous_improvement_approach.md)|[振り返り](practices/looking_back.md)
[テンショントリアージ](practices/tension_triage.md)
[ロールセッション](practices/role_session.md)| 18 | |Project Sprintの成功指標|[Project Sprintの成功指標](theories/success_metrics.md)|-| 19 | |Project Sprintの発展|-|[コントリビューターとしての参加の方法](https://github.com/copilot-jp/project-sprint/wiki)| 20 | -------------------------------------------------------------------------------- /CODE/v3/.1_ja/tutorial/README.md: -------------------------------------------------------------------------------- 1 | # Tutorial 2 | 3 | このドキュメント群では、Project Sprintの基本的な概念の説明と実践方法が順を追って説明されています。 4 | 5 | 全体を通して4つの章から構成されており、上から順番に読み進めていくことで、Project Sprintを実際のプロジェクトで使うことができるようになっています。 6 | 7 | まだProject Sprintを導入していない人が学習のための最初の一歩としては使うことはもちろん、すでにProject Sprintを導入している人も、実施のための基盤がためとして読むことができます。 8 | 9 | ## **1. はじめに** 10 | 11 | 最初に読んでほしいProject Sprintの概要を紹介しています。 12 | 13 | 1.1. [Project Sprint 101](section1-1.md) 14 | 15 | ## **2. 準備しよう** 16 | 17 | Project Sprintを始めるにあたって準備しなければいけないことを記載しています。まずはここで決めた仕組みをもとにして、Project Sprintがスタートします。 18 | 19 | 2.0. [プロジェクトライフサイクル](section2-0.md) 20 | 21 | 2.1. [プロジェクトの環境整備](section2-1.md) 22 | 23 | 2.2. [プロジェクトゴールとマイルストーンを設定する](section2-2.md) 24 | 25 | 2.2.1. [プロジェクトゴールやマイルストーンの設定が難しいときの始め方](section2-2-1.md) 26 | 27 | 2.2.2. [トラック：プロジェクト遂行の単位](section2-2-2.md) 28 | 29 | 2.2.3. [トラックの設定方法](section2-2-3.md) 30 | 31 | 2.3. [チームメンバーを知り、ロールを設定する](section2-3.md) 32 | 33 | 2.4. [ミーティングを設計する](section2-4.md) 34 | 35 | ## **3. やってみよう** 36 | 37 | Project Sprintによって実際にプロジェクトを運営していく方法を記載しています。「準備しよう」で作った仕組みを動かしていきましょう。 38 | 39 | 3.1. [ミーティングの準備をする](section3-1.md) 40 | 41 | 3.2. [ミーティングを開催する](section3-2.md) 42 | 43 | 3.2.1. [タスクを設定する](section3-2-1.md) 44 | 45 | 3.3. [ミーティング環境についてのノウハウ](section3-3.md) 46 | 47 | ## **4. 改善しよう** 48 | 49 | Project Sprintによってプロジェクトを改善する仕組みを記載しています。「やってみよう」で行ったことをもとに、どんどんプロジェクトを改善していきましょう。 50 | 51 | 4.1. [継続的改善アプローチ](section4-1.md) 52 | 53 | 4.1.1. [過去の経験を活かす：振り返り](section4-1-1.md) 54 | 55 | 4.1.2. [現在の心の声を活用する：テンショントリアージ](section4-1-2.md) 56 | 57 | 4.1.3. [未来の展望と仮説：ロールセッション](section4-1-3.md) 58 | 59 | 4.2. [プロジェクトゴールとマイルストーンを見直す](section4-2.md) 60 | 61 | 4.3. [ロールを確認する](section4-3.md) 62 | 63 | 4.4. [Project Sprintの成功指標](section4-4.md) 64 | 65 | ## **5. さらに興味のある方へ** 66 | 67 | Project Sprintを学習・実践し、自らもメソッド作りに改善提案や貢献をしたいと思われる方向けに、その方法について記載しています。 68 | 69 | 5.1. [コントリビューターとしての参加の方法](https://github.com/copilot-jp/project-sprint/wiki) 70 | -------------------------------------------------------------------------------- /CODE/v3/.3_ja/theories/tracks.md: -------------------------------------------------------------------------------- 1 | # トラックとは 2 | 3 | ## トラックとは 4 | 5 | トラックとは、それぞれが強い依存関係を持たず、設定した役割や目標に沿って自律自走できるプロジェクト内の単位です。プロジェクトゴール達成を目指す過程を、それぞれが強い依存関係を持たず自律的に作業を進めることができる単位にまでブレイクダウンしたものを、トラックと呼びます。 6 | 7 | [Project Sprint 101](101.md)で説明したように、Project Sprintではプロジェクトを「全体」の達成に寄与するひとつの「部分」として捉えます。トラックも同様に、プロジェクトという全体の達成に必要なそれぞれの部分といえます。トラックごとに目的や目指すべき成果（理想の状態・成果物）が存在し、それらが達成されることでプロジェクトゴールの達成に漸進的に近づいてゆきます。 8 | 9 | 必要なトラックの数や種類はプロジェクトごとに、またプロジェクトのフェーズにより異なります。一般的には、プロジェクト全体の状態を把握するためのメインのトラックをまず設定してマイルストーンを置き、そのマイルストーンの達成のために必要なものを要素ごとに分割することで、その他のトラックが置かれます。 10 | 11 | プロジェクトの構想期はまだプロジェクトゴールが明確化されていないため、トラックへのブレイクダウンも進まないことが多いでしょう。その後の形成期や自律準備期において、プロジェクトゴールやマイルストーン、必要な成果物などが明確になってくるにつれて、トラックの分割が進みます。 12 | 13 | ## トラックの分化と統合 14 | 15 | トラックを設定する際、まずは「このようなトラックが必要だろう」という仮説を立て、チームメンバーを決めます。この段階ではマイルストーンが置かれておらず、定例ミーティングのみのトラックになるかもしれません。その後定例ミーティングで認識合わせと意思決定を重ねることによってトラックのゴールやマイルストーンが明文化されていきます。 16 | 17 | トラック同士は、依存関係が少ない疎結合な状態になるように設定します。トラック同士の依存関係は、個々のトラックの自律的な動きの妨げとなるからです。 18 | 19 | とはいえ、最初にトラックを設定する場合やひとつのトラックを複数に分割する場合においては、他のトラックとの境界が曖昧で依存関係が比較的強く残り、他のトラックと密接に協力して作業する必要が出ることもあります。このような場合は、トラックごとの情報を整理して透明性を高め、定期的なミーティングで認識合わせを行いながら、最小限の協力で活動できるよう相互に体制を整えていきます。 20 | 21 | こうして見てくると、トラックにも[プロジェクトライフサイクル](project_lifecycle.md)と同様の考え方が適用できることが分かってくるでしょう。必要なトラックの仮説を立てチームメンバーを決めるのが構想期、その後トラックのゴールやマイルストーンを明文化するのが形成期、他のトラックとの連携体制や定例ミーティングの形を整えて自律に向かうのがトラックの自律準備期に当たります。 22 | 23 | 上述のように、自律準備期までは他のトラックとの境界が曖昧なことも多くあります。また、自律推進期に入ってからも、環境の変化に伴い他トラックとの相互依存関係が密になり、自律的な推進が難しくなることもあるでしょう。その場合には、一旦自律準備期に戻ったと捉えて情報や体制を整理し、改めて定期的な同期・連携による一定程度予測可能な相互作用のみでそれぞれが自律的に動ける状態に近づけていきます。 24 | 25 | ## トラックの分割例 26 | 27 | 例えば、あるWebサイトを立ち上げるプロジェクトを考えたとき（プロジェクトゴールは「Webサイトの完成」）、Webサイトのデザインを考えるチームと、Webサイトのシステム環境を整える作業は、一定程度関連はしながらも並行して進行します。このとき、それぞれの作業領域をトラックとして分割し、トラックごとにマイルストーンを分けて考えることで、よりプロジェクトを構造化して捉えられるようになります。 28 | 29 | 上述のWebサイトの例のようなトラック分割だけでなく、営業・マーケティング・CSといったロールベースでのトラック分割や、プロダクトごと・機能ごとのトラック分割など、プロジェクトの性質や規模によって、設定されるトラックは様々です。 30 | -------------------------------------------------------------------------------- /CODE/v3/.3_ja/theories_and_practices.md: -------------------------------------------------------------------------------- 1 | # Theories and Practices 2 | 3 | このドキュメント群では、Project Sprintの基本的な概念の説明と実践方法が順を追って説明されます。理論編であるTheories及び実践編であるPracticesから成り、それぞれを上から順番に読み進めていくことで、Project Sprintを概念として理解した上で、実際のプロジェクトに取り入れて使うための知識を得ることができるようになっています。 4 | 5 | すでにプロジェクトマネジメントの経験がある方が新しい方法論としてProject Sprintをインプットするために読むことはもちろん、すでにProject Sprintを導入している方も、効果的な活用のための基盤固めとして読むことができます。 6 | 7 | |Contents|Theories|Practices| 8 | | ---- | ---- | ---- | 9 | |Project Sprint 101|[Project Sprint 101](theories/101.md)|WIP| 10 | |プロジェクトライフサイクル|[5つのサイクル](theories/project_lifecycle.md)|WIP| 11 | |プロジェクトゴールとマイルストーン|[プロジェクトゴールとは](theories/project_goals.md)
[マイルストーンとは](theories/milestones.md)
[制約・イベント](theories/restrictions.md)| [プロジェクトゴールの設定](practices/project_goals.md)
[マイルストーンの設定](practices/milestones.md)
[プロジェクトゴールとマイルストーンの見直し](practices/reviewing_project_goals_and_milestones.md)| 12 | |トラック|[トラックとは](theories/tracks.md)|[トラックの設定](practices/tracks.md)| 13 | |期待値とロール| [期待値とロール](theories/rolls.md)|[チームメンバーの理解とロールシートの利用](practices/rolls.md)
[ロールの確認](practices/reviewing_rolls.md)| 14 | |定例ミーティング|[定例ミーティングの重要性](theories/meetings.md)|[ミーティングの設計](practices/meetings.md)
[ミーティングの進行方法](practices/holding_meetings.md)
[タスクの設定](practices/tasks.md)
[ミーティングロールの確認](practices/meeting_rolls.md)
[ミーティング環境についてのノウハウ](practices/meeting_environments.md)| 15 | |アジェンダ|[アジェンダとは](theories/agenda.md)|[アジェンダアイテムの要素](practices/agenda.md)| 16 | |プロジェクトの環境整備|[プロジェクトの環境整備](theories/project_environments.md)| [情報共有環境の構築](practices/project_environments.md)
[スタンドアップの導入](practices/stand-up_meetings.md)| 17 | |継続的改善アプローチ|[継続的改善アプローチ](theories/continuous_improvement_approach.md)|[振り返り](practices/looking_back.md)
[テンショントリアージ](practices/tension_triage.md)
[ロールセッション](practices/role_session.md)| 18 | |Project Sprintの成功指標|[Project Sprintの成功指標](theories/success_metrics.md)|-| 19 | |Project Sprintの発展|-|[コントリビューターとしての参加の方法](https://github.com/copilot-jp/project-sprint/wiki)| 20 | -------------------------------------------------------------------------------- /CODE/v3/.0_ja/tutorial/section2-1-1.md: -------------------------------------------------------------------------------- 1 | # プロジェクトゴールやマイルストーンの設定が難しいときの始め方 2 | 3 | [プロジェクトゴールとマイルストーンを設定する](section2-1.md)では、プロジェクトゴールやマイルストーンの設定にすんなり取り組みはじめることができ、有効な議論が展開できる場合について記述しました。これが可能なのは、チームメンバー間の相互理解やプロジェクトに対する認識合わせがある程度のところまで進んでいるプロジェクトです。 一方、いきなりプロジェクトゴールやマイルストーンの設定に取り組むことが難しい場合、まずはミーティングを設定して議論することから始めましょう。具体的なステップは以下のようになります。 4 | 5 | ### **認識を合わせてはじめてチームになる** 6 | 7 | 全く面識のないメンバーが集められてプロジェクトが始まるとき、プロジェクトの範囲・内容に対する共通認識ができていない段階では、まず「なぜこのメンバーがここに集まっているのか」の認識合わせから始めなくてはいけません。ミーティングを設定してそれぞれのメンバーがプロジェクトの目的をどう認識しているかを話し合い、擦り合わせを行います。 8 | 9 | また、集まったメンバーで何ができるのかを把握する必要があります。メンバーそれぞれが自分自身のバックグラウンドやスキルセットを開示し、どういった展望を持ってこのプロジェクトに向き合おうとしているかを話し合いましょう。[チームメンバーを知り、ロールを設定する](section2-2.md)も参考にしてください。 10 | 11 | ここまでの認識が揃ってはじめて、集まったメンバーは「プロジェクトチーム」を目指すチームとして歩き始めることができるようになります。 12 | 13 | ### **共通のプロジェクトゴールを目指すプロジェクトチームになる** 14 | 15 | プロジェクトは、最初からプロジェクトゴールや目的が明確な状態で立ち上がるのではなく、緩やかな方向性が示されたり外部からプロジェクトゴールの原型を提示されたりしてスタートすることがほとんどです。 16 | 17 | ですから、次に行うのは、目指すべきプロジェクトゴールを定義するためのミーティングです。さらに時間を取った検討が必要な場合は、この工程を「プロジェクトゴールを作ること」そのものをゴールとする事前プロジェクトと捉えてもよいでしょう。このときは、プロジェクトを取り巻く基本情報（プロジェクトの背景・事業に関する予備知識・制約やイベント）の収集をマイルストーンとし、プロジェクトゴールを明文化することを目指します。 18 | 19 | ミーティングで議論し、チームの意思が適切に反映され、チームメンバーの共通認識を得たプロジェクトゴールを設定することで、プロジェクトゴールがチームにとって明確で納得感のあるものとなります。メンバー全員が、このチームとして何を目指すのかについての共通理解をもち、さらにそれに対して納得している状態をつくる必要があります。 20 | 21 | このようなプロジェクトゴールが明確に設定されてはじめて、チームは共通のプロジェクトゴールを目指す「プロジェクトチーム」と呼べるようになります。 22 | 23 | ### **明確化されたプロジェクトゴールをもとにマイルストーンを設定する** 24 | 25 | 続いて、ここまでで設定したプロジェクトゴールをもとにマイルストーンを引いていきましょう。うまく引けないときは、プロジェクトゴールを見直す必要があるかもしれませんし、マイルストーン設定の前提となるチームメンバー同士の認識合わせがまだ十分でないのかもしれません。必要に応じて、前の工程に戻って議論をしましょう。 26 | 27 | 制約やイベントを意識しながら、「いつまでにどのような作成物が必要か/どういう状態になっている必要があるか」がある程度具体的にイメージできる場合には、プロジェクトゴールを見据えながらバックキャストでマイルストーンマップを引いていきます。具体的なイメージがまだ持ちにくい場合には、まず取り組めるところからフォアキャストでマイルストーンマップを引くことになります。 28 | 29 | ここまで来れば、少なくともプロジェクトチームとして直近取り組むべき内容や目指すべきマイルストーンは明確になっていることでしょう。その先のまだ不明確な部分に関しては、実際にプロジェクトに取り組みながら、[プロジェクトのゴールとマイルストーンを見直す](section4-2.md)を参考に、いつでも見直しや調整を加えればよいのです。 30 | -------------------------------------------------------------------------------- /CODE/v3/.2_ja/practices/reviewing_rolls.md: -------------------------------------------------------------------------------- 1 | # ロールの確認 2 | 3 | ロールも、プロジェクトゴールやマイルストーンと同様、変化しうるものです。定例ミーティングとそこでのアジェンダの議論を通して、ロールは常に見直され、改めて認識合わせが行われることになります。 4 | 5 | ## ロールの確認 6 | 7 | [期待値とロール](../theories/rolls.md)でも述べたように、自律的なチームであるためには、チームメンバー各々の責任・役割が共有されて認識が揃っており、メンバー相互の期待値に齟齬がないことが重要です。 8 | 9 | チーミングの「理想の状態」には、明確な到達点がありません。なぜなら「ここまで達成したら理想のチームだ！」というものが決めにくいからです。そこでProject Sprintでは、常に「チームが今の時点より良い状態になること」を目指します。 そして、ここでの「より良い」とは、チームメンバー同士の果たすべき役割=ロールについての期待値がそろっている状態のことを指します。つまりロールの確認とは、チームメンバーの持つ互いの役割についての期待値がそろっているかを確認することを指します。 10 | 11 | ロールの確認をするべきタイミングは、次のような時です。 12 | 13 | 1. 過去に定義されたロールが、より詳細にブレイクダウンして考えられるようになり、細かい認識合わせが必要になったとき 14 | 2. プロジェクトの進行により過去に定義していないような役割が生まれ、その役割を担うロールを明確化することが必要だと考えられるようになったとき 15 | 3. 過去に定義されてあるメンバーにアサインされていたロールが、周囲からの期待に添っていないとき。例えば、実際にはアサインされているメンバーとは別のメンバーがロールを遂行していたり、アサインされたメンバーが周囲からの期待値を満たしきれていなかったり、逆にアサインされたメンバーが自分は周囲からの期待値を満たせていないと感じていたりするとき 16 | 4. その他何らかの理由でチームメンバーがロールの確認をしたほうがよいと考えたとき 17 | 18 | ロール確認の実施はミーティングのアジェンダアイテムとして扱われるので、確認が必要だと考える場合には事前にアジェンダアイテムの提出を行う必要があります。 19 | 20 | ## 明示ロールと暗黙ロール 21 | 22 | Project Sprintでは、ミーティングロール以外には必ず設定しなければならないロールというものを決めておらず、それ以外のロールの定義についてはチームメンバーで合意することのみが必要な条件となっています。 23 | 24 | しかし、この「チームメンバーの合意」は、必ずしも明示的なものとは限りません。チームで名前を決めて共有されるロールもある一方、プロジェクトを進めていくなかで、あるメンバーが自然に担っていく暗黙的な役割もあります。Project Sprintにおいて、前者は「明示ロール」と呼ばれ、後者は「暗黙ロール」と呼ばれます。 25 | 26 | これらの区別は絶対的なものではなく、ある暗黙ロールが、何かのきっかけによって明示ロールとなることもありえます。 27 | 28 | 例えば、最初から暗黙ロールが十分に機能することはほとんどありません。つまり、「あの人がこれをやってくれるだろう」という阿吽の呼吸・暗黙の了解は、チーム発足初期にはあまり機能しないということです。多くの場合こうした暗黙ロールは一度「この人はこういう役割の人だ」という明示ロールとして表現され、この過程で期待値のすり合わせが行われます。その後、「あの人はこういう役割の人だからこれもやってくれるだろう」と、暗黙ロールも機能し始めるのです。チームメンバーの互いの期待値が合ってくると、未知の状況にも柔軟に対応できるようになります。 29 | 30 | なお、暗黙ロールと明示ロールの割合はプロジェクトやチームによって異なるもので、最適なバランスもそれぞれ異なります。また、単純にロールの数が多いほうがよい、少ないほうがよい、といった点についても、一律の答えはありません。 31 | 32 | ただし、ロールは次のような状態になっていることが望ましいとされます。 33 | 34 | * チームメンバー間で、ロールの中でやるべきことがより細かい粒度で理解されているほどよい。 35 | * そのチームにとって最もコストのかからない方法で、チームにとって必要十分なロールが共有されているほどよい。 36 | * 各ロールのやるべきことをお互いにフォローできればできるほどよい。 37 | -------------------------------------------------------------------------------- /CODE/v3/.3_ja/practices/reviewing_rolls.md: -------------------------------------------------------------------------------- 1 | # ロールの確認 2 | 3 | ロールも、プロジェクトゴールやマイルストーンと同様、変化しうるものです。定例ミーティングとそこでのアジェンダの議論を通して、ロールは常に見直され、改めて認識合わせが行われることになります。 4 | 5 | ## ロールの確認 6 | 7 | [期待値とロール](../theories/rolls.md)でも述べたように、自律的なチームであるためには、チームメンバー各々の責任・役割が共有されて認識が揃っており、メンバー相互の期待値に齟齬がないことが重要です。 8 | 9 | チーミングの「理想の状態」には、明確な到達点がありません。なぜなら「ここまで達成したら理想のチームだ！」というものが決めにくいからです。そこでProject Sprintでは、常に「チームが今の時点より良い状態になること」を目指します。 そして、ここでの「より良い」とは、チームメンバー同士の果たすべき役割=ロールについての期待値がそろっている状態のことを指します。つまりロールの確認とは、チームメンバーの持つ互いの役割についての期待値がそろっているかを確認することを指します。 10 | 11 | ロールの確認をするべきタイミングは、次のような時です。 12 | 13 | 1. 過去に定義されたロールが、より詳細にブレイクダウンして考えられるようになり、細かい認識合わせが必要になったとき 14 | 2. プロジェクトの進行により過去に定義していないような役割が生まれ、その役割を担うロールを明確化することが必要だと考えられるようになったとき 15 | 3. 過去に定義されてあるメンバーにアサインされていたロールが、周囲からの期待に添っていないとき。例えば、実際にはアサインされているメンバーとは別のメンバーがロールを遂行していたり、アサインされたメンバーが周囲からの期待値を満たしきれていなかったり、逆にアサインされたメンバーが自分は周囲からの期待値を満たせていないと感じていたりするとき 16 | 4. その他何らかの理由でチームメンバーがロールの確認をしたほうがよいと考えたとき 17 | 18 | ロール確認の実施はミーティングのアジェンダアイテムとして扱われるので、確認が必要だと考える場合には事前にアジェンダアイテムの提出を行う必要があります。 19 | 20 | ## 明示ロールと暗黙ロール 21 | 22 | Project Sprintでは、ミーティングロール以外には必ず設定しなければならないロールというものを決めておらず、それ以外のロールの定義についてはチームメンバーで合意することのみが必要な条件となっています。 23 | 24 | しかし、この「チームメンバーの合意」は、必ずしも明示的なものとは限りません。チームで名前を決めて共有されるロールもある一方、プロジェクトを進めていくなかで、あるメンバーが自然に担っていく暗黙的な役割もあります。Project Sprintにおいて、前者は「明示ロール」と呼ばれ、後者は「暗黙ロール」と呼ばれます。 25 | 26 | これらの区別は絶対的なものではなく、ある暗黙ロールが、何かのきっかけによって明示ロールとなることもありえます。 27 | 28 | 例えば、最初から暗黙ロールが十分に機能することはほとんどありません。つまり、「あの人がこれをやってくれるだろう」という阿吽の呼吸・暗黙の了解は、チーム発足初期にはあまり機能しないということです。多くの場合こうした暗黙ロールは一度「この人はこういう役割の人だ」という明示ロールとして表現され、この過程で期待値のすり合わせが行われます。その後、「あの人はこういう役割の人だからこれもやってくれるだろう」と、暗黙ロールも機能し始めるのです。チームメンバーの互いの期待値が合ってくると、未知の状況にも柔軟に対応できるようになります。 29 | 30 | なお、暗黙ロールと明示ロールの割合はプロジェクトやチームによって異なるもので、最適なバランスもそれぞれ異なります。また、単純にロールの数が多いほうがよい、少ないほうがよい、といった点についても、一律の答えはありません。 31 | 32 | ただし、ロールは次のような状態になっていることが望ましいとされます。 33 | 34 | * チームメンバー間で、ロールの中でやるべきことがより細かい粒度で理解されているほどよい。 35 | * そのチームにとって最もコストのかからない方法で、チームにとって必要十分なロールが共有されているほどよい。 36 | * 各ロールのやるべきことをお互いにフォローできればできるほどよい。 37 | -------------------------------------------------------------------------------- /CODE/v3/.2_ja/theories/milestones.md: -------------------------------------------------------------------------------- 1 | # マイルストーンとは 2 | 3 | ## マイルストーンとは 4 | 5 | マイルストーンとは、プロジェクト内のある時点において、具体的な作成物とそれに紐づく期限をセットにして記述したもののことです。あるマイルストーンを達成するまでの期間のことをステージと呼びます。 6 | 7 | マイルストーンは[トラック](tracks.md)ごとに設定され、ひとつのトラックに複数置かれることがほとんどです。各トラックにおけるマイルストーンの達成の集積がメインのトラックにおけるマイルストーンの達成となり、メインのトラックにおけるマイルストーンを順次達成していくことがプロジェクトゴールの達成への道です。 8 | 9 | マイルストーンもプロジェクトゴールと同様に、当該マイルストーンが置かれるトラックの進行を担うチームによって定義され、当該チームとして認識が揃っており、当該チームによって必要に応じて再定義しうるものでなくてはなりません。また、当該チームは自らが達成すべきマイルストーンがプロジェクトゴールに対してどういう位置づけにあり、どういう役割を果たすのかを常に認識し、それをプロジェクトチーム全体に対して明確に示せる状態にしておく必要があります。 10 | 11 | ## マイルストーンの価値 12 | 13 | マイルストーンを明示化し常に意識することで、最終的な状態や作成物に向かう道筋の確からしさを確認し、現在の地点からチームが何をするべきか、またその後何を目指していくべきかを見通すことができます。 14 | 15 | Project Sprintにおいて、プロジェクトゴールに向けての進捗は、現在のステータス(As-Is)とあるべきステータス(To-Be)の距離として捉えられます。 As-Is時点からTo-Beを描くとき、チームメンバーによってはあまり確度が高くないこともあります。 16 | 17 | この原因は、大きく二つに分けられます。 18 | 19 | * As-IsやTo-Beに関して、チームメンバー間で認識が揃っていないこと (**ズレの問題**) 20 | * As-IsやTo-Beに関して、実際にタスクをリスト化し具体的に取り組んでいかなければ明らかにならない部分が多いこと (**粗さの問題**) 21 | 22 | Project Sprintでは、定例ミーティングでの認識合わせとマイルストーンの設定によってこれらの問題を解決します。最終的なプロジェクトゴール（To-Be）より距離の近いTo-Be'としてのマイルストーンを設定することで未来に対する予測の粗さを軽減するとともに具体的な取り組みに落とし込みやすくするのです。 23 | 24 | 25 | ## 制約・イベント 26 | 27 | プロジェクトの外部環境にあって、プロジェクトに影響を与えるためプロジェクトメンバーが意識しなければならないものを、**制約**と呼びます。特に、マイルストーンの設定の前提となり、ときにプロジェクトゴールにも影響を与えるものを**イベント**と呼びます。なお、プロジェクトの内部にあってマイルストーンやプロジェクトゴールの変動をもたらすものは、プロジェクトの一部として捉え、イベントとは呼びません。 28 | 29 | 制約は、社内の稟議スケジュールや予算など、所与のものであることが多いですが、プロジェクトを取り巻くさまざまな制約のうち、どれを実際にプロジェクトに影響を与える**イベント**と捉えてマイルストーンやプロジェクトゴールの設定の前提とするかについては、プロジェクトチームで判断しなくてはならないこともあります。この場合にも、プロジェクトチームとして認識を揃えた上で納得感のある意志決定をすることが大切です。 30 | 31 | イベントの典型的な例は、プロジェクトの外で日々行われている、組織の定常業務です。具体的には取締役会などがこれにあたります。これ自体がプロジェクトの作成物を生み出すわけではありませんが、プロジェクトに関する何らかの報告や決裁がなされるため、こうしたイベントに合わせてマイルストーンを設定する必要があることがあります。また、こうしたイベントからフィードバックされた情報がプロジェクトの前提条件を変え、マイルストーンや、ときにはプロジェクトゴールそのものを変える必要が生じることもあります。 32 | 33 | 単発のものや定期的なものだけでなく、「商戦期」のような期間をもったものも、イベントとして認識します。それに合わせてプロジェクトのマイルストーンを設定したり、その結果を受けてマイルストーンやゴールを調整したりする必要があるという点は、特定の日付であっても期間であっても変わらないからです。 34 | -------------------------------------------------------------------------------- /CODE/v2/.0_en/tutorial/3-2.md: -------------------------------------------------------------------------------- 1 | # Reviewing Project Goals and Milestones 2 | 3 | The content of this article falls under the "progress domain" in Project Sprint. 4 | 5 | The process is a Project Sprint-specific mechanism that revolves around regular meetings and agenda discussions. Through this mechanism, we can share the progress of the project, continuously improve the project process, review milestones toward the project goal, and check each other's roles. 6 | 7 | In this article, we will discuss project goals and milestone reviews. 8 | 9 | ## Milestone Review 10 | 11 | As mentioned in [Setting Goals and Milestones for a Project](1-1.md), milestones and project goals can be changed. Milestones and goals can be changed at any time during the project, based on changes in the environment surrounding the project and what you learn from actually completing the tasks. 12 | 13 | Milestones should be reviewed at the following times 14 | 15 | 1. When a milestone has been achieved 16 | 2. When it becomes apparent that a milestone will not be achieved on time (either later or earlier than planned) 17 | 3. When it becomes apparent that a milestone is not appropriate for the project goal. 18 | 4. The project goal has changed and the milestone needs to be changed. 19 | 5. When a team member feels that the milestone should be reviewed for some other reason. 20 | 21 | ## Project Goal Review 22 | 23 | You should also review the goals of the project at the following times 24 | 25 | 1. When the project has progressed to the point where it is clear that the project goal itself needs to be revised. 26 | 2. When milestones are not achieved on time and it becomes clear that the project goal should be revised. 27 | 3. For some other reason, a team member thinks that the project goal should be reviewed. 28 | 29 | The implementation of milestone and project goal reviews is also on the meeting agenda, so you will need to submit an agenda in advance. 30 | 31 | **Tips related to this page** 32 | 33 | * [Using a Milestone Map](../tips/tips2.md) 34 | -------------------------------------------------------------------------------- /CODE/v3/.0_ja/tutorial/section2-0.md: -------------------------------------------------------------------------------- 1 | # プロジェクトの環境整備 2 | 3 | この記事では、プロジェクスプリントの実施を助けるプロジェクト環境について記載します。 4 | 5 | ## **情報共有環境の構築** 6 | 7 | * **ファイル共有**: プロジェクトメンバー全員が同じ情報にアクセスできるよう、ファイルの共有場所を用意しましょう。 8 | * **スケジュール共有**: スケジュール調整に必要な限りで、メンバー間の個人カレンダーを共有するようにしましょう。これは、メールなどによって都度日程調整をするのではなく、チームメンバーのスケジュール状況が一か所に集まっており、ミーティングのスケジュールを効率的に設定・変更できるようになることを意味します。 9 | * **タスク共有**: プロジェクトを通じて生まれるタスクを共有できる場所を用意しましょう。個人でタスク管理するのではなく、プロジェクトチームで共有のタスク置き場を用意することで、お互いが何をするべきか / するつもりだったか、を確認するコミュニケーションがしやすくなります。 10 | 11 | これらは一般的なプロジェクトマネジメントで語られる要素と大きく異なりません。しかし、Project Sprintでは、それらの要素すべてにおいて、「情報の透明性をいかに担保するか」という点を中心に考えるべきです。 12 | 13 | Project Sprintでは、プロジェクトのゴールやマイルストーンの設定、ロールの設定と調整をはじめ、様々なタイミングで「チームメンバーの納得を伴った合意」をつくることが必要になります。そのため、納得をつくるため = チームメンバーの情報格差をなくすため、にはどういったプロジェクト環境を用意するべきか、というポイントが重要視されるのです。 14 | 15 | なお、ここに書いている要素は一例に過ぎません。プロジェクトごとに、チームメンバー間で最も最適なプロジェクト環境を整備していくように話し合うこともまた重要です。 16 | 17 | ## **スタンドアップの導入** 18 | 19 | 詳しくは[ミーティングを開催する](section3-2.md)で記述しますが、Project Sprintでは定期的なミーティングでタスクの進捗報告を行い、問題が発生していればアジェンダアイテムとしてミーティング内で議論します。しかし、それぞれが自律的にタスクに取り組むうちに、成果物のイメージが当初の想定とずれてきたり、進め方や連携の方法が最適でなくなってきたりすることがあります。 20 | 21 | こういった状況を定例ミーティングを待たずして是正するため、各メンバーのタスクの状況をクイックに確認する方法として、「スタンドアップ」を導入することがあります。スタンドアップで個々のメンバーのタスクへの取り組み状況が共有されることで、成果物や進め方に対する認識がアップデートされ、取り組み方法が改善されたりメンバー間の連携や役割分担が最適化されたりするきっかけが生まれます。 22 | 23 | ### **概要** 24 | 25 | Project Sprintにおけるスタンドアップは、次のような形で導入されます。 26 | 27 | * 時間: 長さは15～30分程度で、スプリントの中で複数回行われる場合は毎回同じ時間帯とするのが望ましい。 28 | * 頻度: 日次、スプリントの折返しタイミング、週頭など、スプリントやチームの状況に合わせて設定する。チームメンバーの要望によりスポットで実施してもよい。 29 | * メンバー: チームメンバー全員 30 | * 目的: チームのタスク状況を確認し、見直しが必要な場合にはそのきっかけを掴むこと 31 | 32 | ### **共有事項** 33 | 34 | チームメンバーは、次の内容についての共有を、プロジェクトのマイルストーンを見ながら行います。 35 | 36 | 1. 実行したこと 37 | 2. これから実行すること 38 | 3. 障害・問題（あれば） 39 | 40 | ### **実施のポイント** 41 | 42 | * 障害・問題は共有に留める。 スタンドアップは問題解決の場ではないことに注意してください。スタンドアップにおいて、問題点の共有だけに留まらず解決方法まで議論してしまって、タイムボックスを破ることになるのは望ましくありません。解決すべき障害や問題の報告があった場合は、スタンドアップ後に関係者で解決策を話し合い、必要に応じて結果をほかのメンバーに共有するようにします。 43 | * いつものファシリテーターがハンドリングしない。 スタンドアップでの実施内容はシンプルです。メンバーそれぞれが持ち回りでファシリテーションを行い、自己組織化を促します。 44 | -------------------------------------------------------------------------------- /CODE/v3/.1_ja/tutorial/section2-0.md: -------------------------------------------------------------------------------- 1 | # プロジェクトライフサイクル 2 | 3 | プロジェクトライフサイクルとは、プロジェクトが構想されてから完了に至るまでにプロジェクトチームが辿る一連のフェーズのことを指します。 4 | 5 | Project Sprintにおいては、プロジェクトライフサイクルは構想期、形成期、自律準備期、自律推進期、統合期の5つのフェーズから成ると捉えます。プロジェクトチームが現在どのフェーズにあるのかによって、取るべき行動や達成すべき状態は異なります。そのため、このプロジェクトライフサイクルを理解し意識することによって、プロジェクトを効率よく進めることが可能になります。 6 | 7 | ## 構想期 8 | 9 | プロジェクトはまず、プロジェクトソース（発案者）が抱いた希望を源として立ち上がります。このフェーズでは、プロジェクトソースの希望を明確化してプロジェクト立ち上げの理由や目的を整理し、目指すべき理想の状態を見据えた上で、プロジェクトがどのようなものになるべきかの仮説を立てます。そして、そのために最適なチームメンバーを決定することでプロジェクトチームを組成します。 10 | 11 | ## 形成期 12 | 13 | ここからは、構想期で組成されたプロジェクトチームが主体となってプロジェクトを進めていきます。形成期は、プロジェクトチームの意思を反映したプロジェクトゴールを設定し、そのプロジェクトゴールを達成するために必要なリソースを把握するフェーズです。プロジェクトの目的や価値、生み出すべき成果を明確にしてプロジェクトゴールを設定し、そのプロジェクトゴールを相互に依存関係がなるべくないようにブレイクダウンしてトラックを作成します。 14 | 15 | ## 自律準備期 16 | 17 | 自律準備期は、このフェーズの後に続く自律推進期が1スプリント目からスムーズに走り出せるよう、環境を整えるためのフェーズです。プロジェクトの情報を整理して透明性を高め、定期的なミーティングで目線合わせを行います。 18 | 各トラックごとに自律的な推進ができるよう整理し、必要に応じてトラック同士の定期的な連携や同期タイミングを設計します。また、定例ミーティングの方法やアジェンダのテンプレートなどを準備し全体で共有しておきます。自律推進期において漸進的・反復的にプロジェクトの進め方を改善できるよう、継続的改善アプローチも導入します。 19 | 20 | ## 自律推進期 21 | 22 | さあ、環境は整いました。プロジェクトゴールにつながる成果を生み出していくために手を動かすフェーズです。自律推進期は、漸進的にプロジェクトゴールを目指すべく、定例ミーティングを軸とした隔週～3か月程度の小さなサイクルの反復として進行されます。これにより、環境の変化に立ち遅れることなく必要に応じてプロジェクトの再定義を行い、プロジェクトチームとして、そしてトラックごとに自律的にプロジェクトゴールを目指しつづけることができるのです。 23 | 全トラックのマイルストーンは可視化され、状況に応じて更新されていなければなりません。また、それぞれのトラックで定期的な成果物の出力と、継続的改善アプローチによる最適化を行います。 24 | 25 | ## 結合期 26 | 27 | プロジェクトゴールに向けてプロジェクトを収束させていく、または次のプロジェクトに向けた引継ぎを進めるフェーズです。そのためには、外部から求められているものを踏まえてプロジェクト完了の定義を把握しておく必要があります。全体ゴールに対する部分ゴールの達成として出力できる形でプロジェクトの成果を整え、外部に示せるようにします。 28 | 29 | ## 各フェーズにおけるProject Sprintの意義 30 | 31 | Project Sprintの基本メカニズムが最もその効力を発揮するのは、プロジェクトチームが自律推進期にあるときです。定例ミーティングによる認識合わせと意思決定を経て、各メンバーが自律的に次の行動に向かっていくというサイクルの繰り返しが、プロジェクトチームを漸進的・安定的にプロジェクトゴールに向かわせるからです。 32 | しかし、プロジェクトゴールやマイルストーン、トラックなどを設定し、プロジェクトの骨組みを作り軌道に乗せていく形成期や自律準備期においても、その段階におけるプロジェクトやそれを取り巻く環境の不確実性の高さゆえに、定例ミーティングで都度環境に対する認識を揃えプロジェクトを再定義するというProject Sprintのメカニズムは、高い効果を発揮します。 33 | また、Project Sprintは、構想期及び自律準備期をできるだけ短縮し、スムーズに自律推進期に入れるような考え方や仕組みを提供します。 34 | -------------------------------------------------------------------------------- /CODE/v3/.1_ja/tutorial/section2-1.md: -------------------------------------------------------------------------------- 1 | # プロジェクトの環境整備 2 | 3 | この記事では、プロジェクスプリントの実施を助けるプロジェクト環境について記載します。 4 | 5 | ## **情報共有環境の構築** 6 | 7 | * **ファイル共有**: プロジェクトメンバー全員が同じ情報にアクセスできるよう、ファイルの共有場所を用意しましょう。 8 | * **スケジュール共有**: スケジュール調整に必要な限りで、メンバー間の個人カレンダーを共有するようにしましょう。これは、メールなどによって都度日程調整をするのではなく、チームメンバーのスケジュール状況が一か所に集まっており、ミーティングのスケジュールを効率的に設定・変更できるようになることを意味します。 9 | * **タスク共有**: プロジェクトを通じて生まれるタスクを共有できる場所を用意しましょう。個人でタスク管理するのではなく、プロジェクトチームで共有のタスク置き場を用意することで、お互いが何をするべきか / するつもりだったか、を確認するコミュニケーションがしやすくなります。 10 | 11 | これらは一般的なプロジェクトマネジメントで語られる要素と大きく異なりません。しかし、Project Sprintでは、それらの要素すべてにおいて、「情報の透明性をいかに担保するか」という点を中心に考えるべきです。 12 | 13 | Project Sprintでは、プロジェクトのゴールやマイルストーンの設定、ロールの設定と調整をはじめ、様々なタイミングで「チームメンバーの納得を伴った合意」をつくることが必要になります。そのため、納得をつくるため = チームメンバーの情報格差をなくすため、にはどういったプロジェクト環境を用意するべきか、というポイントが重要視されるのです。 14 | 15 | なお、ここに書いている要素は一例に過ぎません。プロジェクトごとに、チームメンバー間で最も最適なプロジェクト環境を整備していくように話し合うこともまた重要です。 16 | 17 | ## **スタンドアップの導入** 18 | 19 | 詳しくは[ミーティングを開催する](section3-2.md)で記述しますが、Project Sprintでは定期的なミーティングでタスクの進捗報告を行い、問題が発生していればアジェンダアイテムとしてミーティング内で議論します。しかし、それぞれが自律的にタスクに取り組むうちに、成果物のイメージが当初の想定とずれてきたり、進め方や連携の方法が最適でなくなってきたりすることがあります。 20 | 21 | こういった状況を定例ミーティングを待たずして是正するため、各メンバーのタスクの状況をクイックに確認する方法として、「スタンドアップ」を導入することがあります。スタンドアップで個々のメンバーのタスクへの取り組み状況が共有されることで、成果物や進め方に対する認識がアップデートされ、取り組み方法が改善されたりメンバー間の連携や役割分担が最適化されたりするきっかけが生まれます。 22 | 23 | ### **概要** 24 | 25 | Project Sprintにおけるスタンドアップは、次のような形で導入されます。 26 | 27 | * 時間: 長さは15～30分程度で、スプリントの中で複数回行われる場合は毎回同じ時間帯とするのが望ましい。 28 | * 頻度: 日次、スプリントの折返しタイミング、週頭など、スプリントやチームの状況に合わせて設定する。チームメンバーの要望によりスポットで実施してもよい。 29 | * メンバー: チームメンバー全員 30 | * 目的: チームのタスク状況を確認し、見直しが必要な場合にはそのきっかけを掴むこと 31 | 32 | ### **共有事項** 33 | 34 | チームメンバーは、次の内容についての共有を、プロジェクトのマイルストーンを見ながら行います。 35 | 36 | 1. 実行したこと 37 | 2. これから実行すること 38 | 3. 障害・問題（あれば） 39 | 40 | ### **実施のポイント** 41 | 42 | * 障害・問題は共有に留める。 スタンドアップは問題解決の場ではないことに注意してください。スタンドアップにおいて、問題点の共有だけに留まらず解決方法まで議論してしまって、タイムボックスを破ることになるのは望ましくありません。解決すべき障害や問題の報告があった場合は、スタンドアップ後に関係者で解決策を話し合い、必要に応じて結果をほかのメンバーに共有するようにします。 43 | * いつものファシリテーターがハンドリングしない。 スタンドアップでの実施内容はシンプルです。メンバーそれぞれが持ち回りでファシリテーションを行い、自己組織化を促します。 44 | -------------------------------------------------------------------------------- /CODE/v3/.2_ja/theories/project_lifecycle.md: -------------------------------------------------------------------------------- 1 | # プロジェクトライフサイクル 2 | 3 | プロジェクトライフサイクルとは、プロジェクトが構想されてから完了に至るまでにプロジェクトチームが辿る一連のフェーズのことを指します。 4 | 5 | Project Sprintにおいては、プロジェクトライフサイクルは構想期、形成期、自律準備期、自律推進期、統合期の5つのフェーズから成ると捉えます。プロジェクトチームが現在どのフェーズにあるのかによって、取るべき行動や達成すべき状態は異なります。そのため、このプロジェクトライフサイクルを理解し意識することによって、プロジェクトを効率よく進めることが可能になります。 6 | 7 | ## 構想期 8 | 9 | プロジェクトはまず、プロジェクトソース（発案者）が抱いた希望を源として立ち上がります。このフェーズでは、プロジェクトソースが自分自身の希望を明確化してプロジェクト立ち上げの理由や目的を整理し、目指すべき理想の状態を見据えた上で、プロジェクトがどのようなものになるべきかの仮説を立てます。そして、そのために最適なチームメンバーを決定することでプロジェクトチームを組成します。 10 | 11 | ## 形成期 12 | 13 | ここからは、構想期で組成されたプロジェクトチームが主体となってプロジェクトを進めていきます。形成期は、プロジェクトチームの意思を反映したプロジェクトゴールを設定し、そのプロジェクトゴールを達成するために必要なリソースを把握するフェーズです。プロジェクトの目的や価値、生み出すべき成果を明確にしてプロジェクトゴールを設定し、そのプロジェクトゴールを相互に依存関係がなるべくないようにブレイクダウンしてトラックを作成します。 14 | 15 | ## 自律準備期 16 | 17 | 自律準備期は、このフェーズの後に続く自律推進期が1サイクル目からスムーズに走り出せるよう、環境を整えるためのフェーズです。プロジェクトの情報を整理して透明性を高め、定期的なミーティングで目線合わせを行います。 18 | 各トラックごとに自律的な推進ができるよう整理し、必要に応じてトラック同士の定期的な連携や同期タイミングを設計します。また、定例ミーティングの方法やアジェンダのテンプレートなどを準備し全体で共有しておきます。自律推進期において漸進的・反復的にプロジェクトの進め方を改善できるよう、継続的改善アプローチも導入します。 19 | 20 | ## 自律推進期 21 | 22 | さあ、環境は整いました。プロジェクトゴールにつながる成果を生み出していくために手を動かすフェーズです。自律推進期は、漸進的にプロジェクトゴールを目指すべく、定例ミーティングを軸とした隔週～3か月程度の小さなサイクルの反復として進行されます。これにより、環境の変化に立ち遅れることなく必要に応じてプロジェクトの再定義を行い、プロジェクトチームとして、そしてトラックごとに自律的にプロジェクトゴールを目指しつづけることができるのです。 23 | 全トラックのマイルストーンは可視化され、状況に応じて更新されていなければなりません。また、それぞれのトラックで定期的な成果物の出力と、継続的改善アプローチによる最適化を行います。 24 | 25 | ## 結合期 26 | 27 | プロジェクトゴールに向けてプロジェクトを収束させていく、または次のプロジェクトに向けた引継ぎを進めるフェーズです。そのためには、外部から求められているものを踏まえてプロジェクト完了の定義を把握しておく必要があります。全体ゴールに対する部分ゴールの達成として出力できる形でプロジェクトの成果を整え、外部に示せるようにします。 28 | 29 | ## 各サイクルにおけるProject Sprintの価値 30 | 31 | Project Sprintの基本メカニズムが最もその効力を発揮するのは、プロジェクトチームが自律推進期にあるときです。定例ミーティングによる認識合わせと意思決定を経て、各メンバーが自律的に次の行動に向かっていくというサイクルの繰り返しが、プロジェクトチームを漸進的・安定的にプロジェクトゴールに向かわせるからです。 32 | しかし、プロジェクトゴールやマイルストーン、トラックなどを設定し、プロジェクトの骨組みを作り軌道に乗せていく形成期や自律準備期においても、その段階におけるプロジェクトやそれを取り巻く環境の不確実性の高さゆえに、定例ミーティングで都度環境に対する認識を揃えプロジェクトを再定義するというProject Sprintのメカニズムは、高い効果を発揮します。 33 | また、Project Sprintは、自律準備期をできるだけ短縮し、スムーズに自律推進期に入れるような考え方や仕組みを提供します。 34 | -------------------------------------------------------------------------------- /CODE/v2/.0_en/reference.md: -------------------------------------------------------------------------------- 1 | # Reference 2 | 3 | This document describes the various methods, concepts, and literature behind Project Sprint. 4 | 5 | Project Sprint is an independent method based on empirical evidence from various projects, with reference to the following theories, methods, literature, and concepts. 6 | 7 | ### Manifesto for Agile Software Development 8 | I share the values of the Manifesto for Agile Software Development and its 12 principles. 9 | [https://agilemanifesto.org/](https://agilemanifesto.org/) 10 | 11 | #### Scrum & Scrum@Scale 12 | The concept of sprints as short, iterative practices that deliver results, the notion of transparency and self-organization, the focus on meetings for alignment and decision making, and the retrospective process are all references. 13 | The name Project Sprint is inspired by the Scrum sprint. 14 | [https://www.scrumguides.org/](https://www.scrumguides.org/) 15 | 16 | ### Teal Organization 17 | I am sympathetic to the concepts of self-management and evolving purpose. 18 | [https://www.reinventingorganizations.com/](https://www.reinventingorganizations.com/) 19 | 20 | #### Holacracy 21 | The roles and tensions and their relationships, which are core elements in the teaming activity, are based on the concept of holacracy. 22 | [https://www.holacracy.org/](https://www.holacracy.org/) 23 | 24 | ### Psychological Safety 25 | This concept was proposed by Amy Edmondson. I share the importance of creating an environment where people believe it is safe to say whatever they want in a team. 26 | It was brought to attention by Google's research project on highly productive teams. 27 | [https://www.jstor.org/stable/2666999](https://www.jstor.org/stable/2666999) 28 | 29 | Google re:Work 30 | [https://rework.withgoogle.com/jp/guides/understanding-team-effectiveness/](https://rework.withgoogle.com/jp/guides/understanding-team-effectiveness/) 31 | 32 | ### Sense-Making Theory 33 | This is a theory developed by Carl Weik and others. I agree with the idea of focusing on team buy-in rather than accuracy. 34 | -------------------------------------------------------------------------------- /CODE/v2/.2_ja/advance.md: -------------------------------------------------------------------------------- 1 | # Advance 2 | 3 | このドキュメントは、プロジェクトスプリントに最新の議論・実験的な概念が記載されており、メソッドのアップデートに関する最新情報が得られます。 4 | 5 | ### プロジェクトスプリントの成功指標 6 | 7 | プロジェクトスプリントは、 8 | 9 | * プロジェクトのゴールが達成されている状態 10 | * 理想的なチームが形成されている状態 11 | 12 | を目指すプロジェクト推進メソッドです。 13 | 14 | したがって、プロジェクトスプリントが成功しているかどうかは、これらがそれぞれ実現しているか(**プログレスの成功**と **チーミングの成功**)、という観点で評価することがでできます。 15 | 16 | ここで、いずれの成功についても、絶対的に到達すべき状態がないものであることに注意しなければなりません。 プロジェクトのゴールは変化しうるものであり、また何をもって理想的なチームとするかはプロジェクトの規模や時間軸などに依存します。 17 | 18 | 一方、プロジェクトスプリントが正しく導入・運営されていれば、それはプログレスの成功とチーミングの成功がもたらされることを意味します。 そのため、プロジェクトスプリント自体の活発さ自体を成功指標とみなすことができます。 19 | 20 | **プログレスの成功指標** 21 | 22 | プログレスの成功指標は次の2つです。 23 | 24 | * プログレスに関わるタスクがリストアップされ、消化されているか、 25 | * ミーティングにおいてプログレスに関わるアジェンダアイテムが多くリストアップされ、消化されているか 26 | 27 | **チーミングの成功指標** 28 | 29 | チーミングの成功指標は次の2つです。 30 | 31 | * チーミングに関わるタスクがリストアップされ、消化されているか、 32 | * ミーティングにおいてチーミングに関わるアジェンダアイテムが多くリストアップされ、消化されているか 33 | 34 | ### 最適化 35 | 36 | **最適化の分類** 37 | 38 | **最適化**は、短期的視野で実施されている取り組みか、長期的視野で実施されている取り組みか、という点で二つに分けられます。具体的には、以下のような性質の違いがあります。 39 | 40 | | 短期の最適化 | 長期の最適化 | 41 | | ----------- | ------------ | 42 | | イニシャルコストが低い | ランニングコストが低い | 43 | | 一回性 | 継続的 | 44 | | 属人的 | 標準化 | 45 | | 試験的 | ベストプラクティスの展開 | 46 | 47 | 二つの間に絶対的な基準はなく、同じ取り組みであってもプロジェクトそのものの規模・時間軸によってどちらに分類されるかは変化します。 48 | 49 | ### プログレス・チーミングにおけるステータス 50 | 51 | **プログレスにおけるステータス(As-IsとTo-Be)** 52 | 53 | プロジェクトスプリントにおいて、プロジェクトの進捗は、現在のステータス(As-Is)とあるべきステータス(To-Be)の距離として捉えられます。 チームメンバーによってAs-Is時点からTo-Beを描くとき、その確度はそれほど高くないこともあります。 54 | 55 | この原因は、大きく二つに分けられます。 56 | 57 | * As-IsやTo-Beに関して、チームメンバーの間での認識が揃っていないこと (**ズレの問題**) 58 | * As-IsやTo-Beに関して、実際にプログレス・アクティビティを行っていかなければ明らかにならないこと (**粗さの問題**) 59 | 60 | プロジェクトスプリントは、プロセスとマイルストーンの設定によってこれらの問題を解決します。 61 | 62 | **チーミングにおけるステータス** 63 | 64 | プロジェクトスプリントにおいて、チームのステータスは、メンバーが互いに責任を明確に理解したり期待できる程度と捉えられ、次の2点が実現されれば、理想的なチームを形成することができます。 65 | 66 | * プロジェクトチームのメンバーのお互いに何をやってくれるのか、やろうとしているのかわかること(**期待値の一致**) 67 | * 自分に担うことができる役割であれば、何であれ必要に応じていつでも担おうとするマインドセットがあること (**自発的な役割の引き受け**) 68 | 69 | プロジェクトスプリントは、プロセスとロールの設定によってこれらを実現します。 70 | -------------------------------------------------------------------------------- /CODE/v3/.1_ja/tutorial/section2-2-1.md: -------------------------------------------------------------------------------- 1 | # プロジェクトゴールやマイルストーンの設定が難しいときの始め方 2 | 3 | [プロジェクトゴールとマイルストーンを設定する](section2-2.md)では、プロジェクトゴールやマイルストーンの設定にすんなり取り組みはじめることができ、有効な議論が展開できる場合について記述しました。これが可能なのは、チームメンバー間の相互理解やプロジェクトに対する認識合わせがある程度のところまで進んでいるプロジェクトです。 一方、いきなりプロジェクトゴールやマイルストーンの設定に取り組むことが難しい場合、まずはミーティングを設定して議論することから始めましょう。具体的なステップは以下のようになります。 4 | 5 | ### **認識を合わせてはじめてチームになる** 6 | 7 | 全く面識のないメンバーが集められてプロジェクトが始まるとき、プロジェクトの範囲・内容に対する共通認識ができていない段階では、まず「なぜこのメンバーがここに集まっているのか」の認識合わせから始めなくてはいけません。ミーティングを設定してそれぞれのメンバーがプロジェクトの目的をどう認識しているかを話し合い、擦り合わせを行います。 8 | 9 | また、集まったメンバーで何ができるのかを把握する必要があります。メンバーそれぞれが自分自身のバックグラウンドやスキルセットを開示し、どういった展望を持ってこのプロジェクトに向き合おうとしているかを話し合いましょう。[チームメンバーを知り、ロールを設定する](section2-3.md)も参考にしてください。 10 | 11 | ここまでの認識が揃ってはじめて、集まったメンバーは「プロジェクトチーム」を目指すチームとして歩き始めることができるようになります。 12 | 13 | ### **共通のプロジェクトゴールを目指すプロジェクトチームになる** 14 | 15 | プロジェクトは、最初からプロジェクトゴールや目的が明確な状態で立ち上がるのではなく、緩やかな方向性が示されたり外部からプロジェクトゴールの原型を提示されたりしてスタートすることがほとんどです。 16 | 17 | ですから、次に行うのは、目指すべきプロジェクトゴールを定義するためのミーティングです。さらに時間を取った検討が必要な場合は、この工程を「プロジェクトゴールを作ること」そのものをゴールとする事前プロジェクトと捉えてもよいでしょう。このときは、プロジェクトを取り巻く基本情報（プロジェクトの背景・事業に関する予備知識・制約やイベント）の収集をマイルストーンとし、プロジェクトゴールを明文化することを目指します。 18 | 19 | ミーティングで議論し、チームの意思が適切に反映され、チームメンバーの共通認識を得たプロジェクトゴールを設定することで、プロジェクトゴールがチームにとって明確で納得感のあるものとなります。メンバー全員が、このチームとして何を目指すのかについての共通理解をもち、さらにそれに対して納得している状態をつくる必要があります。 20 | 21 | このようなプロジェクトゴールが明確に設定されてはじめて、チームは共通のプロジェクトゴールを目指す「プロジェクトチーム」と呼べるようになります。 22 | 23 | はじめのうちは、プロジェクトゴールや目的に対する現状認識をまずチームとして揃えるために言語化して書き出してみる、というような形で構いません。議論しているうちに認識が変わることもあるでしょうし、一度設定してプロジェクトが開始されてからも、チームで納得してさえいれば環境の変化に応じていつでも変更して構わないのです。 24 | 25 | ### **明確化されたプロジェクトゴールをもとにマイルストーンを設定する** 26 | 27 | 続いて、ここまでで設定したプロジェクトゴールをもとにマイルストーンを引いていきましょう。うまく引けないときは、プロジェクトゴールを見直す必要があるかもしれませんし、マイルストーン設定の前提となるチームメンバー同士の認識合わせがまだ十分でないのかもしれません。必要に応じて、前の工程に戻って議論をしましょう。 28 | 29 | 制約やイベントを意識しながら、「いつまでにどのような作成物が必要か/どういう状態になっている必要があるか」がある程度具体的にイメージできる場合には、プロジェクトゴールを見据えながらバックキャストでマイルストーンマップを引いていきます。具体的なイメージがまだ持ちにくい場合には、まず取り組めるところからフォアキャストでマイルストーンマップを引くことになります。 30 | 31 | ここまで来れば、少なくともプロジェクトチームとして直近取り組むべき内容や目指すべきマイルストーンは明確になっていることでしょう。その先のまだ不明確な部分に関しては、実際にプロジェクトに取り組みながら、[プロジェクトのゴールとマイルストーンを見直す](section4-2.md)を参考に、いつでも見直しや調整を加えればよいのです。 32 | -------------------------------------------------------------------------------- /CODE/v2/.0_en/tips/tips2.md: -------------------------------------------------------------------------------- 1 | # Tips2: Using a Milestone Map 2 | 3 | As described in the section on the [Setting goals and milestones for a project](../tutorial/1-1.md), a milestone is "a description of a set of specific deliverables and the deadlines associated with them. This milestone map should be shared and agreed upon by all team members, and should be available for constant reference throughout the project. 4 | 5 | We recommend using a "milestone map" as a tool to help you with this task. 6 | 7 | A milestone map is a sheet that provides an overview of the milestones in a project. By including information other than due dates and deliverables, and by describing multiple milestones in a cross-sectional manner, it allows for a deeper understanding of the relationships between milestones and the context in which they were set. 8 | 9 | A milestone map should include the following elements 10 | 11 | * Phase name: semantic positioning between milestones 12 | * Start date of due date: usually the day after the previous milestone's end date) 13 | * End date of due date (\*): the date when the milestone is due to be completed 14 | * Deliverables(\*): Deliverables required upon completion of the milestone 15 | * Desired state: Describes what you want the project to look like internally when the milestone is completed, or what you want the project to look like externally when you receive the project deliverables. 16 | * Note: Feel free to include additional information. 17 | 18 | \*These elements are expressed in a way that gives a bird's eye view of the entire milestone. 19 | 20 | **Example of a table format** 21 | 22 | | Milestone | To Create | To Achieve | To Complete | 23 | | ----------------- | --------- | ---------- | ----------- | 24 | | Start date | | | | 25 | | End Date | | | | 26 | | Phase Name | | | | 27 | | Deliverables | | | | 28 | | What it should be | | | | 29 | | Memo | | | | 30 | -------------------------------------------------------------------------------- /CODE/v3/.0_ja/tutorial/section2-1-2.md: -------------------------------------------------------------------------------- 1 | # プロジェクトの時間軸を整理するための便利な考え方（トラック/フェーズ) 2 | 3 | Project Sprintではプロジェクトゴールとマイルストーンという概念を用いてプロジェクトの時間軸を整理することを基本としています。 この記事では、プロジェクトゴールとマイルストーンに加え、チームメンバーがコミュニケーションをするうえで知っておくとよい、トラックとフェーズという概念を紹介します。 4 | 5 | **トラック/フェーズ概念図** 6 | 7 | ![トラック概念図](../images/track.png) 8 | 9 | ## **トラック - ゴールに対して複線的なマイルストーンの進行をしたいときの考え方** 10 | 11 | Project Sprintでプロジェクトゴールとマイルストーンを設定してプロジェクトを進行するとき、最もシンプルな構造は、 12 | 13 | * プロジェクトゴール X 14 | * ゴールX を実現するための マイルストーン A 15 | * マイルストーン A を実現するための、マイルストーン B 16 | * マイルストーン B を実現するための、マイルストーン C 17 | 18 | というものです。端的に時系列で表現すると、 19 | 20 | **マイルストーン C -> マイルストーン B -> マイルストーン A -> ゴールX** 21 | 22 | というかたちで、プロジェクトが進行します。 23 | 24 | しかし、実際にはこのように単純な構造でプロジェクトが進行することはほとんどありません。 25 | 26 | 例えば、次のようなときです。 27 | 28 | * ゴールX 29 | * ゴールXを実現するためには、マイルストーンAと、マイルストーンBが必要 30 | * マイルストーンAは、3つのマイルストーンに分けて達成できる 31 | * マイルストーンBも、3つのマイルストーンに分けて達成できる 32 | 33 | このとき、次のような時系列でゴールXが実現します。 34 | 35 | **マイルストーン A-1 -> マイルストーン A-2 -> マイルストーン A-3** 36 | 37 | **マイルストーン B-1 -> マイルストーン B-2 -> マイルストーン B-3** 38 | 39 | **マイルストーン A-3 + マイルストーン B-3 -> ゴール X** 40 | 41 | マイルストーンAを作る流れとマイルストーンBを作る流れのことを、それぞれ「トラック」と呼びます。 42 | 43 | 例えばあるWebサイトを立ち上げるプロジェクトを考えたとき（ゴールはWebサイトの完成）、Webサイトのデザインを考えるチームと、Webサイトのシステム環境を整える作業は（関連はしながらも）並行して進行します。このとき、それぞれの作業領域を「トラック」として分割し、トラックごとにマイルストーンを分けて考えることで、よりプロジェクトを構造化して捉えられるようになります。 44 | 45 | なお、進捗状況の共有やマイルストーンの詳細な確認などを目的として、トラック間での連携やトラックを横断したミーティングが必要になることがあります。このとき、連携が必要かどうかを検討・判断するのはプログレスリードですが、ミーティングのアレンジはミーティングロールとしてのファシリテーターが担当します。 46 | 47 | ## **フェーズ - 個々のマイルストーンを達成するまでの期間を意味的なひとまとまりと捉える** 48 | 49 | 例えば「新規事業を立ち上げる」というゴールを持ったプロジェクトがあり、このために次のようなマイルストーンを設定したとします。 50 | 51 | * マイルストーン1 外部環境、自社や競合他社の状況に関する調査書の完成 52 | * マイルストーン2 調査書に基づいた新規事業計画書の作成 53 | * マイルストーン3 新規事業計画書に基づいた、実際に事業を立ち上げることのできる環境づくり 54 | 55 | これらのマイルストーンを順に実行することによって、ゴールが達成できます。マイルストーンは作成物と紐づく必要があるので、このような書き方になります(調査書、新規事業計画書、事業を立ち上げることのできる環境、がそれぞれ作成物です）。 56 | 57 | しかし、プロジェクトでのコミュニケーション上は、「いま自分たちは何をしているのか」を表現できたほうが便利です。このそれぞれを、「フェーズ」と呼びます。つまり、この例では、 58 | 59 | * マイルストーン1を達成するまでの間：調査フェーズ 60 | * マイルストーン2を達成するまでの間：企画フェーズ 61 | * マイルストーン3を達成するまでの間：実現フェーズ 62 | 63 | などと呼ぶことができます。 64 | 65 | フェーズの名称は、プロジェクトゴールに向けたマイルストーン全体の中でそのフェーズがどういう位置づけなのかが分かるものにします。また、自分たちのチームはもちろん、プロジェクト内の他チームのメンバーから見たときにも何をするのかが分かりやすく記載されていることが重要です。 66 | -------------------------------------------------------------------------------- /CODE/v3/.1_ja/tutorial/section4-3.md: -------------------------------------------------------------------------------- 1 | # ロールを確認する 2 | 3 | チームメンバーを知り、ロールを設定することは、Project Sprintにおけるチーミングドメインにあたります。各チームメンバーの責任・役割・期待値を共有することで、自分の責任・役割・期待値が明確になり、自律的な行動が起こせるようになります。 4 | 5 | ロールも、プロジェクトゴールやマイルストーンと同様、変化しうるものです。Project Sprintにおける「プロセス」にあたる、定期開催のミーティングとそこでのアジェンダの議論を通して、ロールは常に見直され、共通認識が持たれることになります。 6 | 7 | この記事では、ロールの確認について解説します。 8 | 9 | ## **ロールの確認** 10 | 11 | [チームメンバーを知り、ロールを設定する](section2-3.md)でも述べたように、チーミングの「理想の状態」の条件のひとつは、「チームメンバー各々の各自の責任・役割・期待値が共有されており、各メンバーの認識に齟齬がない」ということです。言い換えると、あるチームメンバーが「あの人はこれをやってくれるだろう」と考えたとき、そのチームメンバーも「これは私がやるべきことだ」と考えている状態です。 12 | 13 | チーミングの「理想の状態」には、明確な到達点がありません。なぜなら「ここまで達成したら理想のチームだ！」というものが決めにくいからです。そこでProject Sprintでは、常に「チームが今の時点より良い状態になること」を目指します。 そして、ここでの「より良い」とは、チームメンバー同士の果たすべき役割=ロールについての期待値がそろっている状態のことを指します。つまりロールの確認とは、チームメンバーの持つ互いの役割についての期待値がそろっているかを確認することを指します。 14 | 15 | ロールの確認をするべきタイミングは、次のような時です。 16 | 17 | 1. 過去に定義されたロールが、より詳細にブレイクダウンして考えられるようになり、細かい認識合わせが必要になったとき 18 | 2. プロジェクトの進行により過去に定義していないような役割が生まれ、その役割を担うロールを明確化することが必要だと考えられるようになったとき 19 | 3. 過去に定義されてあるメンバーにアサインされていたロールが、周囲からの期待に添っていないとき。例えば、実際にはアサインされているメンバーとは別のメンバーがロールを遂行していたり、アサインされたメンバーが周囲からの期待値を満たしきれていなかったり、逆にアサインされたメンバーが自分は周囲からの期待値を満たせていないと感じていたりするとき 20 | 4. その他何らかの理由でチームメンバーがロールの確認をしたほうがよいと考えたとき 21 | 22 | ロール確認の実施はミーティングのアジェンダアイテムとして扱われるので、確認が必要だと考える場合には事前にアジェンダアイテムの提出を行う必要があります。 23 | 24 | ## **明示ロールと暗黙ロール** 25 | 26 | Project Sprintでは、ミーティングロール以外には必ず設定しなければならないロールというものを決めておらず、それ以外のロールの定義についてはチームメンバーで合意することのみが必要な条件となっています。 27 | 28 | しかし、この「チームメンバーの合意」は、必ずしも明示的なものとは限りません。チームで名前を決めて共有されるロールもある一方、プロジェクトを進めていくなかで、あるメンバーが自然に担っていく暗黙的な役割もあります。Project Sprintにおいて、前者は「明示ロール」と呼ばれ、後者は「暗黙ロール」と呼ばれます。 29 | 30 | これらの区別は絶対的なものではなく、ある暗黙ロールが、何かのきっかけによって明示ロールとなることもありえます。 31 | 32 | 例えば、最初から暗黙ロールが十分に機能することはほとんどありません。つまり、「あの人がこれをやってくれるだろう」という阿吽の呼吸・暗黙の了解は、チーム発足初期にはあまり機能しないということです。多くの場合こうした暗黙ロールは一度「この人はこういう役割の人だ」という明示ロールとして表現され、この過程で期待値のすり合わせが行われます。その後、「あの人はこういう役割の人だからこれもやってくれるだろう」と、暗黙ロールも機能し始めるのです。チームメンバーの互いの期待値が合ってくると、未知の状況にも柔軟に対応できるようになります。 33 | 34 | なお、暗黙ロールと明示ロールの割合はプロジェクトやチームによって異なるもので、最適なバランスもそれぞれ異なります。また、単純にロールの数が多いほうがよい、少ないほうがよい、といった点についても、一律の答えはありません。 35 | 36 | ただし、ロールは次のような状態になっていることが望ましいとされます。 37 | 38 | * チームメンバー間で、ロールの中でやるべきことがより細かい粒度で理解されているほどよい。 39 | * そのチームにとって最もコストのかからない方法で、チームにとって必要十分なロールが共有されているほどよい。 40 | * 各ロールのやるべきことをお互いにフォローできればできるほどよい。 41 | -------------------------------------------------------------------------------- /CODE/v3/.0_ja/tutorial/section4-3.md: -------------------------------------------------------------------------------- 1 | # ロールを確認する 2 | 3 | チームメンバーを知り、ロールを設定することは、Project Sprintにおけるチーミングドメインにあたります。各チームメンバーの責任・役割・期待値を共有することで、自分の責任・役割・期待値が明確になり、自律的な行動が起こせるようになります。 4 | 5 | ロールも、プロジェクトゴールやマイルストーンと同様、変化しうるものです。Project Sprintにおける「プロセス」にあたる、定期開催のミーティングとそこでのアジェンダの議論を通して、ロールは常に見直され、共通認識が持たれることになります。 6 | 7 | この記事では、ロールの確認について解説します。 8 | 9 | ## **ロールの確認** 10 | 11 | [チームメンバーを知り、ロールを設定する](section2-2.md)でも述べたように、チームとしての活動の「理想の状態」の条件のひとつは、「チームメンバー各々の各自の責任・役割・期待値が共有されており、各メンバーの認識に齟齬がない」ということです。言い換えると、あるチームメンバーが「あの人はこれをやってくれるだろう」と考えたとき、そのチームメンバーも「これは私がやるべきことだ」と考えている状態です。 12 | 13 | チームとしての活動の「理想の状態」には、明確な到達点がありません。なぜなら「ここまで達成したら理想のチームだ！」というものが決めにくいからです。そこでプロジェクトスプリントでは、常に「チームが今の時点より良い状態になること」を目指します。 そして、ここでの「より良い」とは、チームメンバー同士の果たすべき役割=ロールについての期待値がそろっている状態のことを指します。つまりロールの確認とは、チームメンバーの持つ互いの役割についての期待値がそろっているかを確認することを指します。 14 | 15 | ロールの確認をするべきタイミングは、次のような時です。 16 | 17 | 1. 過去に定義されたロールが、より詳細にブレイクダウンして考えられるようになり、細かい認識合わせが必要になったとき 18 | 2. プロジェクトの進行により過去に定義していないような役割が生まれ、その役割を担うロールを明確化することが必要だと考えられるようになったとき 19 | 3. 過去に定義されてあるメンバーにアサインされていたロールが、周囲からの期待に添っていないとき。例えば、実際にはアサインされているメンバーとは別のメンバーがロールを遂行していたり、アサインされたメンバーが周囲からの期待値を満たしきれていなかったり、逆にアサインされたメンバーが自分は周囲からの期待値を満たせていないと感じていたりするとき 20 | 4. その他何らかの理由でチームメンバーがロールの確認をしたほうがよいと考えたとき 21 | 22 | ロール確認の実施はミーティングのアジェンダアイテムとして扱われるので、確認が必要だと考える場合には事前にアジェンダアイテムの提出を行う必要があります。 23 | 24 | ## **明示ロールと暗黙ロール** 25 | 26 | Project Sprintでは、ミーティングロール以外には必ず設定しなければならないロールというものを決めておらず、それ以外のロールの定義についてはチームメンバーで合意することのみが必要な条件となっています。 27 | 28 | しかし、この「チームメンバーの合意」は、必ずしも明示的なものとは限りません。チームで名前を決めて共有されるロールもある一方、プロジェクトを進めていくなかで、あるメンバーが自然に担っていく暗黙的な役割もあります。Project Sprintにおいて、前者は「明示ロール」と呼ばれ、後者は「暗黙ロール」と呼ばれます。 29 | 30 | これらの区別は絶対的なものではなく、ある暗黙ロールが、何かのきっかけによって明示ロールとなることもありえます。 31 | 32 | 例えば、最初から暗黙ロールが十分に機能することはほとんどありません。つまり、「あの人がこれをやってくれるだろう」という阿吽の呼吸・暗黙の了解は、チーム発足初期にはあまり機能しないということです。多くの場合こうした暗黙ロールは一度「この人はこういう役割の人だ」という明示ロールとして表現され、この過程で期待値のすり合わせが行われます。その後、「あの人はこういう役割の人だからこれもやってくれるだろう」と、暗黙ロールも機能し始めるのです。チームメンバーの互いの期待値が合ってくると、未知の状況にも柔軟に対応できるようになります。 33 | 34 | なお、暗黙ロールと明示ロールの割合はプロジェクトやチームによって異なるもので、最適なバランスもそれぞれ異なります。また、単純にロールの数が多いほうがよい、少ないほうがよい、といった点についても、一律の答えはありません。 35 | 36 | ただし、ロールは次のような状態になっていることが望ましいとされます。 37 | 38 | * チームメンバー間で、ロールの中でやるべきことがより細かい粒度で理解されているほどよい。 39 | * そのチームにとって最もコストのかからない方法で、チームにとって必要十分なロールが共有されているほどよい。 40 | * 各ロールのやるべきことをお互いにフォローできればできるほどよい。 41 | -------------------------------------------------------------------------------- /CODE/v2/.0_en/tutorial/3-3.md: -------------------------------------------------------------------------------- 1 | # Checking Roles 2 | 3 | The content of this article falls under the "teaming domain" in Project Sprint. 4 | 5 | The process is a Project Sprint-specific mechanism that revolves around regular meetings and agenda discussions. Through this mechanism, we can share the progress of the project, continuously improve the project process, review milestones toward the project goal, and confirm each other's roles. 6 | 7 | In this article, we will discuss role confirmation. 8 | 9 | ## Checking Roles 10 | 11 | As mentioned in the section [on Knowing team members and setting roles](1-2.md), the "ideal state" of teaming does not have a clear shape. This is because it is difficult to determine "If we achieve this level, we have an ideal team! is difficult to determine. Therefore, in Project Sprint, we always aim for "a better team state than the current one". 12 | 13 | And "better" here refers to a state where the expectations of team members regarding the roles they should play are aligned. In other words, role confirmation is an effort to check whether team members' expectations of each other's roles are coming together. 14 | 15 | The following are some of the times when role verification should be done 16 | 17 | 1. When the roles that have been defined can be broken down into more detail, and a detailed understanding can be established. 18 | 2. When the project progresses to the point where tasks that have not been previously defined are created and the roles need to be clarified. 19 | 3. When a role that was previously defined and assigned to one member does not meet the expectations of another member. For example, when a member who has been assigned to a role is actually having another member perform the role, or when another member believes that the expectations of the assigned member are not being met, or conversely, when the assigned person feels that the expectations are higher than they think they are. 20 | 4. When a team member feels that the role should be confirmed for some other reason. 21 | 22 | Since role confirmation is also an agenda item for the meeting, you will need to submit an agenda in advance. 23 | 24 | **Tips related to this page** 25 | 26 | * [Setting up roles for easy use in practice](../tips/tips5.md) 27 | * [Using the Rolesheet](../tips/tips6.md) 28 | -------------------------------------------------------------------------------- /CODE/v2/.2_ja/README.md: -------------------------------------------------------------------------------- 1 | # Ja v2.2.0 2 | 3 | ## **CODEとは** 4 | 5 | **CODE**とは、プロジェクトスプリントについて説明したドキュメント群の総称です。 6 | 7 | ### [**Tutorial**](tutorial/) 8 | 9 | プロジェクトスプリントの基本的な概念の説明と実践方法が順を追って説明されており、読みながらプロジェクトスプリントを実際に導入することができます。 10 | 11 | ### [**Essentials**](essentials.md) 12 | 13 | プロジェクトスプリントのコアとなる重要概念について説明されており、全体像を理解することができます。 14 | 15 | ### [**Tips**](tips/) 16 | 17 | プロジェクトスプリントにまつわる詳細な説明・深ぼった説明が記載されており、プロジェクトスプリント実践の具体的ノウハウを得たり、より応用がきくようになります。 18 | 19 | ### [**Advance**](advance.md) 20 | 21 | プロジェクトスプリントに最新の議論・実験的な概念が記載されており、メソッドのアップデートに関する最新情報を得ることができます。 22 | 23 | ### [**Reference**](reference.md) 24 | 25 | プロジェクトスプリントの背景にある諸メソッド・概念・文献について記載されており、プロジェクトスプリントの効率的な理解が可能になり、また今後のメソッドのアップデートに関わりそうな情報を知ることができます。さらに、背景を知ることでメソッドの応用も可能になります。 26 | 27 | ## **ドキュメントの比較表** 28 | 29 | | ドキュメント名 | Tutorial | Essentials | Tips | Advance | Reference | 30 | | ------- | ---------------- | ---------- | ----------------- | ----------------------- | ----------------------------------------------------- | 31 | | 記載内容 | 基本的な概念の説明と実践方法 | 重要概念・骨格 | 詳細・深堀説明 | 最新の議論や実験的な概念 | 背景にある諸メソッド・概念・文献 | 32 | | 効果 | 基本の理解、導入手順が理解できる | 全体像が理解できる | 具体的なノウハウや応用方法が分かる | メソッドのアップデートに関する最新情報が分かる | 効率的なプロジェクトスプリントの理解、メソッドのアップデートに関わりそうな情報、応用のための知識が得られる | 33 | 34 | ## **ラーニングパス** 35 | 36 | ドキュメントの活用方法はあなたがおかれている状況により様々です。主に想定される対象読者別に、おすすめのステップをご紹介します。 37 | 38 | **Case1. 自らプロジェクトスプリントの導入を主導する方** 39 | 40 | 1. [Tutorial](tutorial/)を通読し、基本的な理解をする 41 | 2. [Essentials](essentials.md)を読み、全体像や重要な箇所をつかむ 42 | 3. [Tips](tips/)を読み、様々な状況に対応できるようにする 43 | 4. 分からないことがあれば、[Reference](reference.md)を読み、理解を深める 44 | 45 | **Case2. プロジェクトスプリントを導入することが決まったプロジェクトのメンバーの方** 46 | 47 | 1. [Tutorial](tutorial/)を通読し、基本的な理解をする 48 | 2. [Tips](tips/)のうち、自分が気になるものをピックアップして読み、不明点を解消する 49 | 50 | **Case3. プロジェクトスプリントというものの概要を手早く理解したい方** 51 | 52 | 1. Tutorialの「[Project Sprint 101](tutorial/project-sprint-101.md)」を読む 53 | 54 | **Case4. プロジェクトスプリントというメソッドの発展に貢献したいと考えてくださる方** 55 | 56 | 1. [Tutorial](tutorial/)を読み、基本的な理解を深める 57 | 2. [Essentials](essentials.md)を読み、全体像や重要な個所をつかむ 58 | 3. [Tips](tips/)を読み、より詳細な説明、深ぼった説明を理解する 59 | 4. [Advance](advance.md)を読み、最新の議論を知る 60 | 5. [Reference](reference.md)を読み、背景にある考え方をより深く理解する 61 | -------------------------------------------------------------------------------- /CODE/v3/.2_ja/theories/project_environments.md: -------------------------------------------------------------------------------- 1 | # プロジェクトの環境整備 2 | 3 | ## 実現したい状態と価値基準 4 | 5 | Project Sprintが目指すのは、プロジェクトチームにより自律的にプロジェクトが推進されている状態です。そのためには、以下のようなことが必要となります。 6 | 7 | - 各メンバーが、進化する目的や目標を深く理解・共感している 8 | - 各メンバーが、誰かのマネジメントに頼らず自身の役割を理解している 9 | - 各メンバーがチームに対してなんでも意見ができ、常に改善が行われている 10 | 11 | これらを実現してProject Sprintの実施を助けるプロジェクト環境について記述します。 12 | 13 | ## 環境を作ることで実現したい状態 14 | 15 | Project Sprintはスクラムと同様、「経験主義」と「リーン思考」に立脚しています。 16 | 17 | **経験主義**とは、物事を理論よりも経験に基づいて考えようとする態度であり、スクラムガイドでは「知識は経験から生まれ、意思決定は観察に基づく」とされています。複雑性・不確実性が高く予測の難しい状況に対応するには、体系立った知識や完成したノウハウを正確に運用することよりも、実践や経験から得た知識を活かすことが重要だと考えているのです。 18 | 19 | また、**リーン思考**とは、価値を生み出さない無駄な行動を省略し、本質に集中するという考え方です。今いるところにおいて最も重要な問題を特定し集中的に完結するというサイクルを繰り返すことにより、無駄を最小限に抑えながら価値を最大化することができます。 20 | 21 | 予測可能性を最適化してリスクを制御するためにProject Sprintでは、定例ミーティングで環境に対する認識を常に揃えなおしながら反復的かつ漸進的にプロジェクトを進めるというアプローチを採用しています。プロジェクトにおける取り組みについて定期的な振り返りと改善を繰り返しながら、ゴールに至るまでの道筋を少しずつクリアにするとともにチームが自律的に学習し成長することを目指します。 22 | 23 | ## 経験主義を支える「透明性」「検査」「適応」 24 | 25 | 経験主義においては、「透明性」「検査」「適応」という三つの柱の実現が重要であるとされています。Project Sprintではこれらを、以下のように解釈しています。 26 | 27 | **透明性**： 28 | 創発的な取り組み過程や作業は、作業を実行する人とその作業を受け取る人にとって可視化されている必要があります。透明性とは、この可視化が標準化され、共通理解が持たれているということです。重要な意思決定は作成物をどのように認知するかに大きく左右されます。作成物の透明性が低いと、リスクを高める意思決定につながってしまう可能性があります。 29 | 30 | **検査**： 31 | 成果物や合意されたマイルストーンに向けた進捗状況は、頻繁かつ熱心に検査される必要があります。潜在的な望ましくない変化や問題を検知するためです。定例ミーティングは変化を引き起こすように設計されており、この変化により問題を検知しやすくなります。 32 | 透明性の実現により、検査が可能になります。透明性が実現されていない状態での検査は、誤解を招く無駄なものになってしまいます。 33 | 34 | **適応**： 35 | 取り組み過程の何らかの側面が許容範囲を逸脱していたり、達成すべきものとして設定されたマイルストーンが受け入れがたい場合には、現在適用されている取り組み過程やマイルストーンの構成要素を調整する必要があります。逸脱を最小限に抑えるため、この調整はできるだけ速やかに行われなくてはなりません。 36 | 関係者に権限が与えられていないときや、自己管理がなされていないときは、この適応が難しくなります。 37 | 38 | ## チームの価値基準 39 | 40 | スクラムガイドでは、チームが成功するかどうかは、次の5つの価値基準を実践できるかどうかにかかっているとされており、Project Sprintもこれに共感しています。これらの価値基準は、チームの作業・行動・振る舞いの方向性を示しています。 41 | 42 | **確約(Commitment)**： 43 | チームは、ゴールを達成し、お互いにサポートすることを確約します。 44 | 45 | **集中(Focus)**： 46 | チームは、ゴールに向けて可能な限り進捗できるように、スプリントの作業に集中します。 47 | 48 | **公開(Openness)**： 49 | チームとステークホルダーは、作業や課題を公開します。 50 | 51 | **尊敬(Respect)**： 52 | チームのメンバーは、お互いに能力のある独立した個人として尊敬し、一緒に働く人たちからも同じように尊敬されます。 53 | 54 | **勇気(Courage)**： 55 | チームのメンバーは、正しいことをする勇気や困難な問題に取り組む勇気を持ちます。 56 | 57 | チームのメンバーは、定例ミーティングや作成物を用いながら、これらの価値基準を学習し探求します。これらの価値基準がチームや一緒に働く人たちによって具現化されるとき、経験主義が効果を発揮し、信頼が構築されるのです。 58 | -------------------------------------------------------------------------------- /CODE/v3/.3_ja/theories/project_environments.md: -------------------------------------------------------------------------------- 1 | # プロジェクトの環境整備 2 | 3 | ## 実現したい状態と価値基準 4 | 5 | Project Sprintが目指すのは、プロジェクトチームにより自律的にプロジェクトが推進されている状態です。そのためには、以下のようなことが必要となります。 6 | 7 | - 各メンバーが、進化する目的や目標を深く理解・共感している 8 | - 各メンバーが、誰かのマネジメントに頼らず自身の役割を理解している 9 | - 各メンバーがチームに対してなんでも意見ができ、常に改善が行われている 10 | 11 | これらを実現してProject Sprintの実施を助けるプロジェクト環境について記述します。 12 | 13 | ## 環境を作ることで実現したい状態 14 | 15 | Project Sprintはスクラムと同様、「経験主義」と「リーン思考」に立脚しています。 16 | 17 | **経験主義**とは、物事を理論よりも経験に基づいて考えようとする態度であり、スクラムガイドでは「知識は経験から生まれ、意思決定は観察に基づく」とされています。複雑性・不確実性が高く予測の難しい状況に対応するには、体系立った知識や完成したノウハウを正確に運用することよりも、実践や経験から得た知識を活かすことが重要だと考えているのです。 18 | 19 | また、**リーン思考**とは、価値を生み出さない無駄な行動を省略し、本質に集中するという考え方です。今いるところにおいて最も重要な問題を特定し集中的に完結するというサイクルを繰り返すことにより、無駄を最小限に抑えながら価値を最大化することができます。 20 | 21 | 予測可能性を最適化してリスクを制御するためにProject Sprintでは、定例ミーティングで環境に対する認識を常に揃えなおしながら反復的かつ漸進的にプロジェクトを進めるというアプローチを採用しています。プロジェクトにおける取り組みについて定期的な振り返りと改善を繰り返しながら、ゴールに至るまでの道筋を少しずつクリアにするとともにチームが自律的に学習し成長することを目指します。 22 | 23 | ## 経験主義を支える「透明性」「検査」「適応」 24 | 25 | 経験主義においては、「透明性」「検査」「適応」という三つの柱の実現が重要であるとされています。Project Sprintではこれらを、以下のように解釈しています。 26 | 27 | **透明性**： 28 | 創発的な取り組み過程や作業は、作業を実行する人とその作業を受け取る人にとって可視化されている必要があります。透明性とは、この可視化が標準化され、共通理解が持たれているということです。重要な意思決定は作成物をどのように認知するかに大きく左右されます。作成物の透明性が低いと、リスクを高める意思決定につながってしまう可能性があります。 29 | 30 | **検査**： 31 | 成果物や合意されたマイルストーンに向けた進捗状況は、頻繁かつ熱心に検査される必要があります。潜在的な望ましくない変化や問題を検知するためです。定例ミーティングは変化を引き起こすように設計されており、この変化により問題を検知しやすくなります。 32 | 透明性の実現により、検査が可能になります。透明性が実現されていない状態での検査は、誤解を招く無駄なものになってしまいます。 33 | 34 | **適応**： 35 | 取り組み過程の何らかの側面が許容範囲を逸脱していたり、達成すべきものとして設定されたマイルストーンが受け入れがたい場合には、現在適用されている取り組み過程やマイルストーンの構成要素を調整する必要があります。逸脱を最小限に抑えるため、この調整はできるだけ速やかに行われなくてはなりません。 36 | 関係者に権限が与えられていないときや、自己管理がなされていないときは、この適応が難しくなります。 37 | 38 | ## チームの価値基準 39 | 40 | スクラムガイドでは、チームが成功するかどうかは、次の5つの価値基準を実践できるかどうかにかかっているとされており、Project Sprintもこれに共感しています。これらの価値基準は、チームの作業・行動・振る舞いの方向性を示しています。 41 | 42 | **確約(Commitment)**： 43 | チームは、ゴールを達成し、お互いにサポートすることを確約します。 44 | 45 | **集中(Focus)**： 46 | チームは、ゴールに向けて可能な限り進捗できるように、スプリントの作業に集中します。 47 | 48 | **公開(Openness)**： 49 | チームとステークホルダーは、作業や課題を公開します。 50 | 51 | **尊敬(Respect)**： 52 | チームのメンバーは、お互いに能力のある独立した個人として尊敬し、一緒に働く人たちからも同じように尊敬されます。 53 | 54 | **勇気(Courage)**： 55 | チームのメンバーは、正しいことをする勇気や困難な問題に取り組む勇気を持ちます。 56 | 57 | チームのメンバーは、定例ミーティングや作成物を用いながら、これらの価値基準を学習し探求します。これらの価値基準がチームや一緒に働く人たちによって具現化されるとき、経験主義が効果を発揮し、信頼が構築されるのです。 58 | -------------------------------------------------------------------------------- /CODE/v2/.0_en/tutorial/1-2.md: -------------------------------------------------------------------------------- 1 | # Knowing your Team Members and Setting their Roles 2 | 3 | The content of this article falls under the "teaming domain" in Project Sprint. 4 | 5 | The "ideal state" of teaming is when team members have the same expectations of each other's roles (called roles). In other words, when a team member thinks, "He will do this," that team member also thinks, "This is what I should do.” The "ideal state" of teaming does not have a definite form. The reason is that it is difficult to determine "If we achieve this level, we are an ideal team!” is difficult to determine. Therefore, in Project Sprint, we always aim for "a better team state than the current one.” 6 | 7 | ## Basic information of team members 8 | 9 | The prerequisite for a better team is to understand the team members. For example, make sure you know the following about the team members involved in the project 10 | 11 | * What is the name of the team member? What kind of organization or company do they usually belong to? 12 | * What kind of person is each member? What skill sets do they have, for example? What types of work have they been involved in? 13 | * What is the expected contribution of each member to the project? 14 | * Is each member a full-time or part-time member of the project? In any case, how much time can each member devote to the project? 15 | 16 | Knowing these things at the beginning of the project will help you in setting up the roles that will follow. 17 | 18 | ## Sharing Roles 19 | 20 | In the Project Sprint, the roles of individual team members are called roles. Roles and team members do not necessarily have to have a one-to-one relationship. Roles and team members do not necessarily have to have a one-to-one relationship, i.e., one person can play multiple roles, or a role can be played by multiple people. 21 | 22 | There is no limit to the number of roles to be defined, and there is no "must define" role. Depending on the nature of the project, discuss the necessary division of roles among team members and clearly define them as roles. 23 | 24 | **Tips related to this page** 25 | 26 | * [Setting up roles that are easy to use in practice](../tips/tips5.md) 27 | * [Using a role sheet](../tips/tips6.md) 28 | * [Preparing the Project Environment](../tips/tips4.md) 29 | * [Classification and nature of roles](../tips/tips13.md) 30 | -------------------------------------------------------------------------------- /CODE/v2/.0_en/tips/tips13.md: -------------------------------------------------------------------------------- 1 | # Tips13: Classification and Properties of Roles 2 | 3 | As described [in Knowing your team members and setting roles](../tutorial/1-2.md), the roles of individual team members are called roles in Project Sprint. Also, as explained in the section on [setting up roles that are easy to use in practice](tips5.md), in Project Sprint, there is no set role that must be set except for the meeting role, and the only requirement for defining roles is that team members must agree on them. 4 | 5 | However, this "team member agreement" is not always explicit. In other words, while there are roles that are named and shared by the team, such as "Team Management" and "Process Admin" described in Tip 5, there are also implicit roles that are naturally assumed by certain members as the project progresses. In Project Sprint, the former are called "explicit roles" and the latter are called "implicit roles". 6 | 7 | These distinctions are not absolute, and it is possible for an implicit role to become an explicit role for some reason. 8 | 9 | For example, implicit roles rarely work well from the start. For example, implicit roles rarely work well from the beginning, i.e., the tacit understanding that "he will do this" does not work well in the early stages of a team. In many cases, these tacit roles are once expressed as explicit roles, "This person has this role," and in this process, the expectations are matched. After that, the implicit roles begin to function as well, saying, "This person has this role, so he will do this as well. When the expectations of team members are aligned, they will be able to cope with unknown situations more effectively. 10 | 11 | The ratio of implicit roles to explicit roles varies from project to project and from team to team, and the optimal balance is different for each. In addition, there is no one-size-fits-all answer to the question of whether more or fewer roles are better. 12 | 13 | However, it is desirable for roles to be in the following state 14 | 15 | * The more fine-grained the understanding among team members of what needs to be done in the role, the better. 16 | * The more roles that are necessary and sufficient for the team are shared in a way that is least costly to the team, the better. 17 | * The more they can follow up with each other on what needs to be done in each role, the better. 18 | -------------------------------------------------------------------------------- /CODE/v4/.0_ja/introduction.md: -------------------------------------------------------------------------------- 1 | # Introduction 2 | 3 | Project Sprint は、小さな成果を繰り返し確実に生み出すことを通じて、環境の変化を捉えつづけながら価値の創出を目指すためのフレームワークです。 4 | 5 | この Introduction では、 皆さんが Project Sprint に触れる際に、Project Sprint をどのような性質のものとして捉え、どのようなスタンスで臨んでいただくとよいかをご案内します。 6 | 7 | 1. Project Sprint の提案 8 | 2. Project Sprint の精神 9 | 3. Project Sprint のフレームワーク 10 | 11 | ## 1. Project Sprint の提案 12 | 13 | Project Sprint は、プロジェクトチームがプロジェクトの中心であり、プロジェクトチームの意思がプロジェクトにおけるあらゆる事柄を決定するという相対主義的なプロジェクト観を提案します。このプロジェクト観を採用することで、プロジェクトチームはさまざまな不自由さから解放され、より自由かつ創造的にプロジェクトを進めることが可能になります。 14 | 15 | プロジェクトの推進に関しては、これまでも多くの知見が蓄えられ、活用されてきました。しかし、近年の社会ではプロジェクトを取り巻く環境は目まぐるしく変化しており、それに伴って状況が刻一刻と変わる、予測の難しいプロジェクトが増えています。 Project Sprint は、プロジェクトチームがこうしたプロジェクトに対応できるようにするためのフレームワークとして考案されました。 16 | 17 | Project Sprint のフレームワークを取り入れることにより、プロジェクトチームは自らがプロジェクトの主体となり、環境の変化を捉えつづけながら、プロジェクトをうまく推進できるようになります。 18 | 19 | ## 2. Project Sprint の精神 20 | 21 | Project Sprint は、[「Adopt & Adapt (採用と適応)」](#user-content-fn-1)[^1]のスタンスで構築されています。 22 | 23 | Project Sprint は、多様なプロジェクトに汎用的に適用することが可能です。しかし、 Project Sprint を自分たちのプロジェクトのフレームワークとして採用するかどうか、さらにどの部分をどういった形で採用するかは、個々のプロジェクトチームの意思に委ねられています。重要なのは、プロジェクトチームがどのような価値観に拠ってプロジェクトに取り組みたいかです。 24 | 25 | 以下のような価値観に共感を覚えるプロジェクトチームは、 Project Sprint との親和性が高く、 Project Sprint のフレームワークによる効果が上がりやすいでしょう。逆に、この価値観への共感が難しい場合、Project Sprint からの提案がプロジェクトチームに混乱を生じさせてしまう可能性があります。 26 | 27 | * 所与の条件にとらわれず、チームの自己決定を重視する 28 | * 予測型か適応型かにとらわれず、状況に応じて柔軟に使い分ける 29 | * 最初に決めた目標の達成にとらわれず、小さな実験を日々繰り返し成果と改善を積み重ねる 30 | 31 | こういった価値観を反映し、 Project Sprint においてプロジェクトをどのようなものとして捉えるとよいかは、 [Definitions](definitions.md) に改めて詳しく記述しています。 32 | 33 | また、 Project Sprint はあくまで実践知を一般化したフレームワークなので、個々のプロジェクトとその置かれた状況に適応するようにテーラリングした上で導入する必要があります。 34 | 35 | 自分たちがどのようなプロジェクトチームでありたいか、そして自分たちのプロジェクトの実情に最適なのはなにかを、まずは考えてみてください。その上で、 Project Sprint が提案する価値観が、より多くのプロジェクトを自由で創造的なものにすることを願っています。 36 | 37 | ## 3. Project Sprint のフレームワーク 38 | 39 | Project Sprint は、実践知を集めて体系化することによってかたちづくられたフレームワークです。 40 | 41 | 堅牢な理論に立脚して構築された揺るぎないものではなく、プロジェクトの現場から日々新たな実践知を取り込みながら更新が続けられており、大きな進化の可能性も秘められています。 42 | 43 | 現在の Project Sprint の中でももっとも本質的な価値と言える内容を、 [Framework](framework.md) にまとめています。Project Sprint の根幹をなすものとしての厳密さを重視しているため、具体的な実践内容やその手順というより、プロジェクト推進の構造やそのための価値観といった、抽象度の高い内容が記述されています。 Project Sprint における各概念の捉え方・考え方や、プロジェクトにおいて推奨される振る舞いを読み取っていただければと思います。 44 | 45 | [^1]: [ITIL](https://en.wikipedia.org/wiki/ITIL)の精神に共感し、そのまま採用しています。 46 | --------------------------------------------------------------------------------