---
title: はじめてのアジャイル開発入門
tags:  #agile  
author: [市谷聡啓](https://convert.docswell.com/user/papanda)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/GEWDYQRMJ2.jpg?width=480
description: はじめてのアジャイル開発入門勉強会スライド
published: May 31, 24
canonical: https://convert.docswell.com/s/papanda/ZJL3Q1-agile-hajimete
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/GEWDYQRMJ2.jpg)

はじめてのアジャイル開発⼊⾨
Ichitani Toshihiro
市⾕聡啓


# Page. 2

![Page Image](https://bcdn.docswell.com/page/47ZGXWRME3.jpg)

市⾕ 聡啓
Ichitani Toshihiro
新価値創出、組織変⾰の伴⾛⽀援
(株式会社レッドジャーニー)
・チーム、事業、組織に「アジャイル」を取り⼊れ、向き合う伴⾛⽀援
・新規事業開発、プロダクト開発の⽀援（仮説検証型アジャイル開発）
特に専⾨は
「仮説検証、アジャイル開発、組織アジャイル」
Toshihiro Ichitani All Rights Reserved.
2


# Page. 3

![Page Image](https://bcdn.docswell.com/page/YJ6Y4GR57V.jpg)

本⽇のテーマ
「アジャイル開発」って何なの︖
Toshihiro Ichitani All Rights Reserved.


# Page. 4

![Page Image](https://bcdn.docswell.com/page/GJ5GQV8GJ4.jpg)

「アジャイルは楽しい︕」
…は、そうとして、
その⾔葉だけで押し切らずに
アジャイルとは何かを語ってみる
Toshihiro Ichitani All Rights Reserved.


# Page. 5

![Page Image](https://bcdn.docswell.com/page/9E2YP3KDER.jpg)

対⽐として、
ウォーターフォールとは
・「フェーズ」(⼯程) と呼ばれるタスクのまとまりを定義し、
順次⼯程を進捗させる開発⼿法
・やるべきこと(タスク)を明確に決めるため、状況の把握が
やりやすい (つまり進捗管理がしやすい)
・進⾏は不可逆で、設計して実装して要件定義に戻る…といった
ことはしない
フェーズ
フェーズ
フェーズ
フェーズ
要件
定義
設計
実装
テスト
Toshihiro Ichitani All Rights Reserved.
フェーズ
リリース


# Page. 6

![Page Image](https://bcdn.docswell.com/page/D7YG51NM7M.jpg)

アジャイルとは
・「スプリント」(イテレーション)という時間単位を定義し、
この時間単位の反復の中で、開発を進める
・やるべきことをすべて整理し尽くしたら前に進めるフェーズとは
異なり、⽤意された時間単位(スプリント)の連鎖に、その時点
その時点でやるべきことを決めてあてはめる
計画づくり
ふりかえり
スプリント
検査適応
計画づくり
開発
ふりかえり
スプリント
検査適応
Toshihiro Ichitani All Rights Reserved.
開発
ふりかえり


# Page. 7

![Page Image](https://bcdn.docswell.com/page/VENGN2X3J8.jpg)

WFとアジャイルの違いとは
ウォーターフォールは「終わらせる作戦」
アジャイルは「続けるための作戦」
といえる（根本的には⽬指すところが異なる）
終わらせるために必要なことをすべて洗い出して、
いつ終わらせられるか、終わらせるためには何が
必要かを管理する
スプリント⾃体には全体がいつ終わるのか
という観点はなく、必要なだけ繰り返す
﹅
﹅
﹅
﹅
﹅
﹅
﹅
﹅
﹅
﹅
﹅
開発を持続させるための仕組みを重視
…
Toshihiro Ichitani All Rights Reserved.


# Page. 8

![Page Image](https://bcdn.docswell.com/page/Y79WR18P73.jpg)

WFも、アジャイルも、
ソフトウェアを作るという点は同じ
当たり前のことのように思えるけど、前提として重要。
ソフトウェア作りに必要になる「⾏為」は同じように必要ということ
何を作るべき
か決める
どう作るかを
判断する
利⽤に適した
品質の確保
WF
要件定義ですべて決めきる
設計ですべて決めきる
各⼯程及びテストで確保
Agile
SprintPlanningで必要な分
だけ決める
Sprintの中で適宜⾏う
Sprint内及び、まとまった
分量は異なるが⾏為は必要
⾏為として必要
テスト(QA)を⾏って確保
Toshihiro Ichitani All Rights Reserved.
⾏為として必要


# Page. 9

![Page Image](https://bcdn.docswell.com/page/G78NW48XJD.jpg)

ただし、
コミュニケーションの担保が異なる
WFは、フェーズ間やフェーズ内で分業があり「受け渡し」が必要
ゆえに、ドキュメントで意思疎通を確実に⾏う作戦が取られる
Agileは、「1つのチーム」でスプリントを連続させ続けるため、
「受け渡し」が発⽣しない
ゆえに、過度な⾔語化が不要で、対話やラフな⾔語化でも⼗分通じる
document
document
document
document
TeamA
TeamB
TeamC
Toshihiro Ichitani All Rights Reserved.


# Page. 10

![Page Image](https://bcdn.docswell.com/page/L7LPN6RNJR.jpg)

設計
⾏為として必要
設計書
「書」として必要なのは︖
・設計⾏為のため︖
・コミュニケーションのため︖
・合意形成のため︖
・記録のため︖
どの観点も程度はあれど必要
「必ず作るべし」を先⽴たせるから状況と tしない
何の⽬的のための⼿段かを⾒失わない
fi
Toshihiro Ichitani All Rights Reserved.


# Page. 11

![Page Image](https://bcdn.docswell.com/page/4EM4X5RQJW.jpg)

WF
Agile
体制の
あり⽅
分業指向
(フェーズ間、フェーズ内)
Oneチーム
意思疎通
の⽅法
ドキュメント
による⾔語化
頻繁な対話
コミュニケーション
質を⾼める
⼯夫
ムラが出ないように
テンプレやルールで
品質を確保
出来る限りチーム内
で完結するように
職能横断を前提
(標準や規定で規定する)
Toshihiro Ichitani All Rights Reserved.
(必要な専⾨スキルを結集させる)


# Page. 12

![Page Image](https://bcdn.docswell.com/page/PERWN3RKJ9.jpg)

Agileでありながら、これまでのやり⽅である
「ドキュメント中⼼」を踏襲してしまうと、
ドキュメント作り
+ 対話
スプリント内の作業が溢れ、肝⼼の開発が
進まず、チームがタスクに追われて疲弊する
Toshihiro Ichitani All Rights Reserved.


# Page. 13

![Page Image](https://bcdn.docswell.com/page/P7XPN4R5JX.jpg)

WFとAgileの⾒た⽬上の違いは
「フェーズ」と「スプリント(反復)」にある
WFが「前提」と置くことを理解し、かつ
「反復」で何を得たいのかを整理することで
両者の使い分けを会得しよう
Toshihiro Ichitani All Rights Reserved.


# Page. 14

![Page Image](https://bcdn.docswell.com/page/37KDNZRRED.jpg)

WFが前提として置いていること
① 正解が何か分かっている
② ドキュメント(⾔語化)によって
意思疎通は可能である
③ 分業によって規模に⽴ち向かう
Toshihiro Ichitani All Rights Reserved.


# Page. 15

![Page Image](https://bcdn.docswell.com/page/LJ3RVD8GE5.jpg)

WFが前提として置いていること
① 正解が何か分かっている
② ドキュメント(⾔語化)によって
意思疎通は可能である
③ 分業によって規模に⽴ち向かう
Toshihiro Ichitani All Rights Reserved.


# Page. 16

![Page Image](https://bcdn.docswell.com/page/8JDY8PMNJG.jpg)

要求
(何の変哲もないオンライン書店を例にすると)
要件
・書籍名、タイトル、ジャンルで検索することができる
・カートに書籍を追加して、決済することができる
・購⼊したタイトルを履歴から確認できる
仕様
・キーワードを⼊⼒し検索ボタンをクリックすると結果が表⽰される
・検索結果は、書籍のタイトル、著者、価格、評価、表紙画像を含む
・検索結果は最⼤50件まで表⽰され、ページング機能が提供される
設計
・(UI設計)検索結果リストのレイアウト︓グリッド形式で1pageあたり5⾏×10列
・(DB設計)書籍テーブル︓ID、タイトル、著者、価格、ジャンル、表紙画像URL
・(アーキテクチャ設計)検索サービス︓ユーザーからの検索リクエストを受け取り
データベースから⼀致する書籍を取得し、結果を返す
(実現したいこと。実現する
ことで価値になる)
(要求のためにソフトウェア
として実現するべきこと)
(要件を満たすためのより
詳細な条件)
(仕様を満たすための⽅法)
オンラインで書籍を購⼊できるようにしたい
Toshihiro Ichitani All Rights Reserved.


# Page. 17

![Page Image](https://bcdn.docswell.com/page/VEP68NRN78.jpg)

確実に実現するための流れをつくる
具体詳細化と
要求
要件
仕様
設計
実現化の検討
何を、どのように実現したら
良いかを決める
決めたことに従い、実現する
実装
Toshihiro Ichitani All Rights Reserved.


# Page. 18

![Page Image](https://bcdn.docswell.com/page/27V3NKRYJQ.jpg)

作ったものが正しいか検査する
要求
要件
仕様
設計
要求を満たすか︖
要件を満たすか︖
仕様を満たすか︖
設計を満たすか︖
実装
Toshihiro Ichitani All Rights Reserved.
テスト
テスト
テスト
テスト


# Page. 19

![Page Image](https://bcdn.docswell.com/page/5JG3KQMWEL.jpg)

各フェーズを経ることで
「要求通りに正確に作る」ことを実現する
要求⾃体が正しいかどうかの検査は⾏わない
= 要求が不正確な場合は機能しない
Toshihiro Ichitani All Rights Reserved.


# Page. 20

![Page Image](https://bcdn.docswell.com/page/47Q5NKRQEP.jpg)

WFが前提として置いていること
① 正解が何か分かっている
② ドキュメント(⾔語化)によって
意思疎通は可能である
③ 分業によって規模に⽴ち向かう
Toshihiro Ichitani All Rights Reserved.


# Page. 21

![Page Image](https://bcdn.docswell.com/page/KE49GP8YJ1.jpg)

そもそもなぜ隅々までの⾔語化が必要なのか︖
分業体制のため
(その是⾮については次項で扱う)
開発
チームA
発注者
受注者
開発
チームB
① 発注者が上位の情報を
作り受け渡す
② 開発を分担するため
⼀昔前にいた↓
要件
定義者
開発
チームC
設計者
チーム間で情報の受け渡し必要
実装者
テスター
③ フェーズ間で担当者が異なるため情報の受け渡しが必要
Toshihiro Ichitani All Rights Reserved.


# Page. 22

![Page Image](https://bcdn.docswell.com/page/L71KD92NEG.jpg)

作るためには、「具体詳細化」が必要
⼀⽅で、詳細化の最後は「コード」に⾏き着く
(⼀昔前はもうコード書いたほうが早いやんということを
ドキュメントにしていた時代があった)
Toshihiro Ichitani All Rights Reserved.


# Page. 23

![Page Image](https://bcdn.docswell.com/page/G7WDYQ2ME2.jpg)

つまり、「何を作るべきか︖」という詳細化は
必ず「抽象」に踏みとどまるところがあり
作る上では「抽象→具体」の変換を必要がある
抽象
具体
Toshihiro Ichitani All Rights Reserved.


# Page. 24

![Page Image](https://bcdn.docswell.com/page/4JZGXWDM73.jpg)

抽象→具体の変換を補うものは︖
① コミュニケーション (確認する)
② ドメイン知識、過去のPJでの経験知識
抽象
具体
コミュニケーション
経験知識
⼀昔前から業務知識があるかが盛んに問われ、今も経験実績が問われる
理由とは1⾔って1理解ではなく、1から3、5を⽣み出す期待があるから
Toshihiro Ichitani All Rights Reserved.


# Page. 25

![Page Image](https://bcdn.docswell.com/page/YE6Y4G15JV.jpg)

前項で述べたとおり、そもそも要求が不確かな場合
⾔語化だけでは「正しさ」を明らかにできない
「実物を試す」が必要になる
(どういうことかは後で)
︖
実物
Toshihiro Ichitani All Rights Reserved.


# Page. 26

![Page Image](https://bcdn.docswell.com/page/GE5GQV4GE4.jpg)

WFが前提として置いていること
① 正解が何か分かっている
② ドキュメント(⾔語化)によって
意思疎通は可能である
③ 分業によって規模に⽴ち向かう
Toshihiro Ichitani All Rights Reserved.


# Page. 27

![Page Image](https://bcdn.docswell.com/page/972YP3VD7R.jpg)

前提
正解(要求)は
何か分かっている
(=⼿戻り不要)
ドキュメンドで
意思疎通は可能
前提
分業が可能
(分解が可能)
作るべき機能は分解可能で、最後に
まとめなおせば⽬的のモノになる
コスト低減
受け渡された情報にもとづき、ただ
作れば良いという体制ができれば、
その分コストを抑えられる思惑
また、分解可能ということは規模を
分割し対処可能となるということ
⼤規模への対処
Toshihiro Ichitani All Rights Reserved.


# Page. 28

![Page Image](https://bcdn.docswell.com/page/DJYG513MJM.jpg)

現実は分業(分解)による負の影響は⼤きい
⽬的の⽋如
“群盲象を撫でる”
状態で、⽬的は何
だったか、得たい
成果は何か、誰も
他⼈事化
気にしていない
⾃分の受け持つフェーズさえ
全うできれば良く、先の段階で
実現可能なのか気にもしてない
局所最適
⾃分のフェーズでのみ最適化を
図り、過剰な準備や作り込みを
⾏ってしまう
Toshihiro Ichitani All Rights Reserved.


# Page. 29

![Page Image](https://bcdn.docswell.com/page/V7NGN2V3E8.jpg)

現実は分業による負の影響は⼤きい
要件と実装、
実装と実装(の結合)、 ⽬的の⽋如
“群盲象を撫でる”
実物と要求
状態で、⽬的は何
だったか、得たい
を突き合わせた時はじめて、
成果は何か、誰も
気にしていない
他⼈事化
思うようになっていないということ
が突きつけられる
⾃分の受け持つフェーズさえ
全うできれば良く、先の段階で
実現可能なのか気にもしてない
局所最適
⾃分のフェーズでのみ最適化を
(後になるほど影響は⼤きく、燃える)
⾏ってしまう
図り、過剰な準備や作り込みを
Toshihiro Ichitani All Rights Reserved.


# Page. 30

![Page Image](https://bcdn.docswell.com/page/YJ9WR16PJ3.jpg)

分業が機能しない︖
では、どうやって「規模」に⽴ち向かうの︖
Toshihiro Ichitani All Rights Reserved.


# Page. 31

![Page Image](https://bcdn.docswell.com/page/GJ8NW4ZXED.jpg)

「時間」「意味」で分けて、結合を「頻繁化」
フェーズ1
(一次開発)
フェーズ2
(二次開発)
…
「時間」で分ける
最低限必要なものから始める
MVP
検証結果
に基づく
開発
「意味」で分ける
価値は何かを確かめることから始める
分けるが同期・結合を
出来る限り「早くやる」
最終的にチームを分けて事にあたる、かもしれないが
状況・情報の同期、モノの結合を頻繁に⾏う
Toshihiro Ichitani All Rights Reserved.


# Page. 32

![Page Image](https://bcdn.docswell.com/page/LJLPN6DNER.jpg)

結合の「頻度」と「分量」のイメージ
結合頻度
「頻度多、分量少」が理想だが、
頻度が多すぎるとその分オーバーヘッドが
⼤きくなる可能性がある
「頻度多、分量少」でオーバーヘッドが
⼤きくならない頻度で同期・結合する
→ 1週間〜2週間
多
「頻度少、分量多」は従来のフェーズ指向
仮に受け渡す情報を明確にできたとして
相⼿が受け⽌められる量が問われる
少
少
多
Toshihiro Ichitani All Rights Reserved.
結合分量


# Page. 33

![Page Image](https://bcdn.docswell.com/page/47M4X5PQEW.jpg)

なぜフェーズではなくスプリントか︖
スプリント(反復)の意味が⾒えてきた︖
Toshihiro Ichitani All Rights Reserved.


# Page. 34

![Page Image](https://bcdn.docswell.com/page/P7RWN31KE9.jpg)

何のために「反復」するのか
① 「分かる」ようにするため
② 「結合のリスク」を減らすため
③ 「理解」をあわせるため
④ チームの「練度」を⾼めるため
⑤ 「関係性」を作っていくため
Toshihiro Ichitani All Rights Reserved.


# Page. 35

![Page Image](https://bcdn.docswell.com/page/PJXPN4Y5EX.jpg)

そもそも何を作るべきかが分かっていない
…としたら「試すこと」で何が分かれば良い︖
Toshihiro Ichitani All Rights Reserved.


# Page. 36

![Page Image](https://bcdn.docswell.com/page/3JKDNZ3R7D.jpg)

分かりたい対象の解像度をあげてみよう
課題
解くべき課題は
試す
合っているか︖
(要求の妥当性)
次の課題の探索
課題機能の t
形態
機能
機能は使えるように
課題解決に適した
なっているか︖
(仕様設計の妥当性)
※利⽤者との界⾯
機能形態の t
機能を特定しているか︖
(要件仕様の妥当性)
試す
試す
fi
fi
Toshihiro Ichitani All Rights Reserved.


# Page. 37

![Page Image](https://bcdn.docswell.com/page/LE3RVDGG75.jpg)

要求を定義する前の段階
=「仮説」
仮説
課題、機能、形態としての仮説を⽴て
検証を⾏う（試す）ことで確かめる
検証⽅法はインタビュー、
プロトタイプなど多岐にわたる
仮説
検証
費⽤対効果の良い⽅法を模索する
仮説検証の結果から
何が価値になるかを整理する
Toshihiro Ichitani All Rights Reserved.
要求
(実現したいこと。実現する
ことで価値になる)


# Page. 38

![Page Image](https://bcdn.docswell.com/page/8EDY8P1NEG.jpg)

仮説検証とは、
ソフトウェアを作って試すことではないの︖
Toshihiro Ichitani All Rights Reserved.


# Page. 39

![Page Image](https://bcdn.docswell.com/page/V7P68NQNJ8.jpg)

そもそもの課題や課題解決についての
確からしさが必要な段階で
いちいちソフトウェアを作って検証では
割に合わない
⾼
プロトタイプ
ソフトウェア
低
インタビュー
緻密なパワポ
⼩
⼤
検証(物)の
リアリティ
など
必要なリソース
Toshihiro Ichitani All Rights Reserved.
分かっていること
分かりたいこと
から検証⽅法を
選ぶ
(費⽤対効果の⾼い検証⽅法は
模索し続ける必要がある)


# Page. 40

![Page Image](https://bcdn.docswell.com/page/2JV3NK5YEQ.jpg)

みなさんのスクラムはどちら︖
仮説の検証
実運⽤プロダクト
のためのスクラム
のためのスクラム
Toshihiro Ichitani All Rights Reserved.


# Page. 41

![Page Image](https://bcdn.docswell.com/page/5EG3KQ6W7L.jpg)

チェックしよう︕
要求は確定
できている
︖︖︖
開発に邁進
（Why Agileはみんなで確認しておこうか）
要求はまだ
仮説である
あってる
あってない
「モノを作って試す」で関係者と理解あってる︖
﹅
﹅
﹅
﹅
﹅
﹅
﹅
﹅
﹅
﹅
﹅
﹅
﹅
﹅
﹅
﹅
﹅
もしくは何しているのか本当に理解できている︖
アジャイルやることが⽬的とかになってない︖
仮説検証
のためのスクラム
実運⽤するプロダクト
のためのスクラム
Toshihiro Ichitani All Rights Reserved.


# Page. 42

![Page Image](https://bcdn.docswell.com/page/4JQ5NK4Q7P.jpg)

分かりたいことによって⽅法は異なる
まだ課題の仮説が検証できていない
課題が合っているかの検証
(インタビューほか)
形態(IF)として適しているかが
検証できていない
課題は特定できているが課題解決に
有効な機能が検証できていない
理解できる、使えるかの検証
課題解決に適した機能かの検証
(プロトタイプ〜MVP検証)
(プロトタイプ検証)
Toshihiro Ichitani All Rights Reserved.


# Page. 43

![Page Image](https://bcdn.docswell.com/page/K749GPQYE1.jpg)

まとめると︖
何が価値かを分かるための
仮説検証
(インタビュー、プロトタイプ)
適切に規模を分割する
範囲特定
開発レディにする
最⼩限の⾔語化
(スプリント0)
(MVPアプローチ)
必要なのはドキュメント
ではなく「⾏為」
現実のプロダクトを⽣み出す
スクラムによる開発
実運⽤のための品質を担保する
テスト・QA
上位の観点、⾮機能等
Toshihiro Ichitani All Rights Reserved.


# Page. 44

![Page Image](https://bcdn.docswell.com/page/LJ1KD9PN7G.jpg)

正しいものを正しくつくる
仮説検証型アジャイル開発
選択の幅最⼤
（セットベース）
検証
計画
仮説⽴案
(モデル化)
価値探索
スプリント
プランニング
検証
（正しいものを探す）
評価
仮説検証
選択肢を⼗分に
広げた後に絞る
MVP特定
開発計画
(リリースプラ
ンニング)
アジャイル開発
（正しくつくる）
スプリント
レトロスペク
ティブ
選択の振れ幅最⼩
（ポイントベース）
スプリント
開発
MVP検証
スプリント
レビュー
次の価値探索へ
アジャイル
構想を早く形にして
フィードバックを得る
Toshihiro Ichitani All Rights Reserved.
44


# Page. 45

![Page Image](https://bcdn.docswell.com/page/GJWDYQVM72.jpg)

何のために「反復」するのか
① 「分かる」ようにするため
② 「結合のリスク」を減らすため
③ 「理解」をあわせるため
④ チームの「練度」を⾼めるため
⑤ 「関係性」を作っていくため
Toshihiro Ichitani All Rights Reserved.


# Page. 46

![Page Image](https://bcdn.docswell.com/page/4EZGXW4MJ3.jpg)

https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf
Toshihiro Ichitani All Rights Reserved.


# Page. 47

![Page Image](https://bcdn.docswell.com/page/Y76Y4G35EV.jpg)

アジャイルとは「常に結合する」ということ
スプリント
インクリメント
CI/CD
常に統合し検証可能にする
インクリメントはこれまでの
すべてのインクリメントに追加
Toshihiro Ichitani All Rights Reserved.


# Page. 48

![Page Image](https://bcdn.docswell.com/page/G75GQVLG74.jpg)

アジャイルはOneチームだから
「受け渡し」問題は起きないのだよね︖
Toshihiro Ichitani All Rights Reserved.


# Page. 49

![Page Image](https://bcdn.docswell.com/page/9J2YP3LDJR.jpg)

プロダクトオーナー
チーム
スプリント
バックログ
プロダクト
バックログ
スプリント
プランニング
全体(中距離)
のプランニング
スクラムマスター
スプリント
(活動)
起きるよ
アジャイル
リファイン
メント
デイリー
スクラム
(スクラム)
スプリント
レトロ
スペクティブ
アウプット
による試⾏・適⽤
スプリント
レビュー
アウトプット
ステークホルダー
Toshihiro Ichitani All Rights Reserved.


# Page. 50

![Page Image](https://bcdn.docswell.com/page/DEYG51QMEM.jpg)

何のために「反復」するのか
① 「分かる」ようにするため
② 「結合のリスク」を減らすため
③ 「理解」をあわせるため
④ チームの「練度」を⾼めるため
⑤ 「関係性」を作っていくため
Toshihiro Ichitani All Rights Reserved.


# Page. 51

![Page Image](https://bcdn.docswell.com/page/VJNGN2K378.jpg)

PO → 開発チーム
プロダクトバックログ → インクリメント
抽象的な要求 → コードという超具体
抽象から具体への変換を
何でもって担保するか︖
Toshihiro Ichitani All Rights Reserved.


# Page. 52

![Page Image](https://bcdn.docswell.com/page/YE9WR1VPE3.jpg)

POと開発チームの差とは
「どうあるべきか」という「基準」があるかどうか
開発チーム
PO
ユーザー
仮説検証
対話
ユーザーには
POは仮説検証を
多くの場合
どうありたいかの
通じてユーザーの
開発チームには
「基準」がある
「基準」を宿す
「基準」がない
もしくは基準は
顕在化しておらず
検証によって把握する
もっと⾔うと解釈を加え
どうあるべきかを
⾃分なりにつくる
ゆえに対話によって
いちいち基準と
照らし合わせをする
Toshihiro Ichitani All Rights Reserved.


# Page. 53

![Page Image](https://bcdn.docswell.com/page/GE8NW4PX7D.jpg)

開発チームにも「⼩さな基準(ユーザー)」を宿す
ユーザー
PO
開発チームも仮説検証に
仮説検証
基準
仮説検証
基準
開発チーム
参画して「基準」を
⼀定持つことが出来たら︖
いちいちPOに照会せず
⾃分たちで判断できる
ところが増やせる
POと基準を全く同じにする必要もない
仮説検証にフル参画しないまでも
ユーザーテストを定期的に実施するなどはできる
Toshihiro Ichitani All Rights Reserved.


# Page. 54

![Page Image](https://bcdn.docswell.com/page/LELPN61N7R.jpg)

スプリントの積み重ねによって
インクリメントが増える
インクリメントが増えることで
ユーザーに関する新たな知識(課題)を
知ることができる (知る機会が増やせる)
ゆえに、ユーザーのことを⼀度知れば
良いわけではない
スプリントとプロダクトが持続する限り
仮説検証(ユーザー理解)も継続する
Toshihiro Ichitani All Rights Reserved.


# Page. 55

![Page Image](https://bcdn.docswell.com/page/4JM4X5WQ7W.jpg)

何のために「反復」するのか
① 「分かる」ようにするため
② 「結合のリスク」を減らすため
③ 「理解」をあわせるため
④ チームの「練度」を⾼めるため
⑤ 「関係性」を作っていくため
Toshihiro Ichitani All Rights Reserved.


# Page. 56

![Page Image](https://bcdn.docswell.com/page/PJRWN3YK79.jpg)

各フェーズの「学び」が活きるのは「次のPJ」
※チームがPJごとに解散する場合は
学びがいかせるかは個々⼈次第になる
次のPJ︖
次のPJ︖
次のPJ︖
スプリントの「学び」が活きるのは「次のスプリント」
学び
学び
Toshihiro Ichitani All Rights Reserved.


# Page. 57

![Page Image](https://bcdn.docswell.com/page/PEXPN4G57X.jpg)

スプリントによって⽣み出されるのは
プロダクトだけではなくチームも⼀つの成果物になる
Toshihiro Ichitani All Rights Reserved.


# Page. 58

![Page Image](https://bcdn.docswell.com/page/3EKDNZ4RJD.jpg)

何のために「反復」するのか
① 「分かる」ようにするため
② 「結合のリスク」を減らすため
③ 「理解」をあわせるため
④ チームの「練度」を⾼めるため
⑤ 「関係性」を作っていくため
Toshihiro Ichitani All Rights Reserved.


# Page. 59

![Page Image](https://bcdn.docswell.com/page/L73RVDLGJ5.jpg)

ソフトウェアは、⼈と⼈とで作る
ゆえに、⼈と⼈との間の関係性が多⼤な影響を及ぼす
開発チームはさぼらずに全⼒で
やってくれている︖
POも開発チームも、ただ⾃分たち
が楽しいかしかないのでは︖
POは開発にやることをとにかく
押し込もうとしていないか︖
関係性とは信頼のこと
⾏動をはやめることも、⾜踏みさせることもある
Toshihiro Ichitani All Rights Reserved.


# Page. 60

![Page Image](https://bcdn.docswell.com/page/87DY8PNN7G.jpg)

だから、チームビルディングをやるんだよね︖
もちろん、ビルディングワークも⼤事だけど
それだけやっていたら、
強いチームになるわけではないよ
Toshihiro Ichitani All Rights Reserved.


# Page. 61

![Page Image](https://bcdn.docswell.com/page/VJP68N5NE8.jpg)

「やれる感」が私達の関係性を強くする
つまり、⾃分たち⾃⾝で作り出す「結果」に
⾃分たち⾃⾝が励まされる
1回もスプリントを実施せずにビルディングワークだけ10回実施しているチームと、
1回でもスプリントを回しているチーム、どちらが本当の「やれる感」を得ているだろう︖
Toshihiro Ichitani All Rights Reserved.


# Page. 62

![Page Image](https://bcdn.docswell.com/page/2EV3NKPY7Q.jpg)

成功循環モデルは
関係の質からスタートする
チーム結成直後の初期段階や
節⽬におけるビルディングワークは重要
同時に関係の質を⾼めるは「⼀つ前の結果の質」でもある
Toshihiro Ichitani All Rights Reserved.


# Page. 63

![Page Image](https://bcdn.docswell.com/page/57G3KQPWJL.jpg)

最初はごく⼩さな結果でも良い
徐々に関係→思考→⾏動の質が⾼まり
というか⼩さくしかできない
結果にそして次の関係性につながっていく
スプリントの分だけ関係性を⾼める機会が得られるということ
Toshihiro Ichitani All Rights Reserved.


# Page. 64

![Page Image](https://bcdn.docswell.com/page/4EQ5NK2QJP.jpg)

WFで「やれる感」を得るのは後半、終盤︖
実装が進むにつれて「やれる感」よりむしろ
「やれない感」が⾒えてくる︕︖
いくら要件定義や設計だけ進めても
プロダクトとしての「やれる感」は不明
苦しくもリリースをやりとげて、
確かに「やれた感」は得られる…︖
アジャイルでは「1つ⽬のスプリント」から機会がある
結果
結果
最初の段階では「失敗」
「うまくいかない」も
次に良くなるための
「伸びしろ」にあたる
(というかそういう⾒⽅をあえてすること)
Toshihiro Ichitani All Rights Reserved.


# Page. 65

![Page Image](https://bcdn.docswell.com/page/KJ49GPLY71.jpg)

「⼈を分けない」からこそ
「全体」が分かり、
⾃分が何を果たせば良いかも分かる
「全体」=「個別フェーズ」になりやすい
「全体」をチームで理解する
「全体」=「プロダクトゴール」
「各スプリントの全体」
=「スプリントゴール」
「各スプリントの全体」
=「スプリントゴール」
「各スプリントの全体」
=「スプリントゴール」
Toshihiro Ichitani All Rights Reserved.


# Page. 66

![Page Image](https://bcdn.docswell.com/page/LE1KD9LNJG.jpg)

受け渡しとともに
「ちゃんと作る」の責務
も受け渡し
受け渡ししない
「ちゃんと作る」の責務を
チーム全員で背負う
Toshihiro Ichitani All Rights Reserved.


# Page. 67

![Page Image](https://bcdn.docswell.com/page/GEWDYQQMJ2.jpg)

でも、アジャイルにやるには
“マインドセット” が必要なんでしょう︖
Toshihiro Ichitani All Rights Reserved.


# Page. 68

![Page Image](https://bcdn.docswell.com/page/47ZGXWWME3.jpg)

“必要なマインドセット” として表現することは
「⾔葉」としては理解できるかもしれない
でも、「⾏為」としては分かったことにはならない
⾔葉
⾏為
Toshihiro Ichitani All Rights Reserved.


# Page. 69

![Page Image](https://bcdn.docswell.com/page/YJ6Y4GG57V.jpg)

⾃分たちの⾏為⾃体から、
望ましいあり⽅を少しずつ学ぶ
それも確実に⾔えることではない
出来ることは、
学び直す機会を設けておくこと
学べるかは確実ではないけども、
学ぶ機会⾃体を置くかは⾃分たちの意志次第にできるよね
Toshihiro Ichitani All Rights Reserved.


# Page. 70

![Page Image](https://bcdn.docswell.com/page/GJ5GQVVGJ4.jpg)

アジャイルにはそれが備わっている
Toshihiro Ichitani All Rights Reserved.


# Page. 71

![Page Image](https://bcdn.docswell.com/page/LE3RVDDP75.jpg)

なぜ、アジャイルだと
﹅
﹅
﹅
﹅
﹅
﹅
﹅
﹅
﹅
﹅
楽しくなってくるのか︖
Toshihiro Ichitani All Rights Reserved.


# Page. 72

![Page Image](https://bcdn.docswell.com/page/8EDY8PP3EG.jpg)

なるべくしてなる。
Toshihiro Ichitani All Rights Reserved.


# Page. 73

![Page Image](https://bcdn.docswell.com/page/V7P68NNPJ8.jpg)

楽しさと、前進を得ていこう。
Photo credit: digitalpimp. on Visualhunt.com / CC BY-ND


