--- title: はじめてのアジャイル開発入門 tags: #agile author: [市谷聡啓](https://www.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://www.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