はじめてのアジャイル開発入門
150.7K Views
May 31, 24
スライド概要
はじめてのアジャイル開発入門勉強会スライド
関連スライド
各ページのテキスト
はじめてのアジャイル開発⼊⾨ Ichitani Toshihiro 市⾕聡啓
市⾕ 聡啓 Ichitani Toshihiro 新価値創出、組織変⾰の伴⾛⽀援 (株式会社レッドジャーニー) ・チーム、事業、組織に「アジャイル」を取り⼊れ、向き合う伴⾛⽀援 ・新規事業開発、プロダクト開発の⽀援（仮説検証型アジャイル開発） 特に専⾨は 「仮説検証、アジャイル開発、組織アジャイル」 Toshihiro Ichitani All Rights Reserved. 2
本⽇のテーマ 「アジャイル開発」って何なの︖ Toshihiro Ichitani All Rights Reserved.
「アジャイルは楽しい︕」 …は、そうとして、 その⾔葉だけで押し切らずに アジャイルとは何かを語ってみる Toshihiro Ichitani All Rights Reserved.
対⽐として、 ウォーターフォールとは ・「フェーズ」(⼯程) と呼ばれるタスクのまとまりを定義し、 順次⼯程を進捗させる開発⼿法 ・やるべきこと(タスク)を明確に決めるため、状況の把握が やりやすい (つまり進捗管理がしやすい) ・進⾏は不可逆で、設計して実装して要件定義に戻る…といった ことはしない フェーズ フェーズ フェーズ フェーズ 要件 定義 設計 実装 テスト Toshihiro Ichitani All Rights Reserved. フェーズ リリース
アジャイルとは ・「スプリント」(イテレーション)という時間単位を定義し、 この時間単位の反復の中で、開発を進める ・やるべきことをすべて整理し尽くしたら前に進めるフェーズとは 異なり、⽤意された時間単位(スプリント)の連鎖に、その時点 その時点でやるべきことを決めてあてはめる 計画づくり ふりかえり スプリント 検査適応 計画づくり 開発 ふりかえり スプリント 検査適応 Toshihiro Ichitani All Rights Reserved. 開発 ふりかえり
WFとアジャイルの違いとは ウォーターフォールは「終わらせる作戦」 アジャイルは「続けるための作戦」 といえる（根本的には⽬指すところが異なる） 終わらせるために必要なことをすべて洗い出して、 いつ終わらせられるか、終わらせるためには何が 必要かを管理する スプリント⾃体には全体がいつ終わるのか という観点はなく、必要なだけ繰り返す ﹅ ﹅ ﹅ ﹅ ﹅ ﹅ ﹅ ﹅ ﹅ ﹅ ﹅ 開発を持続させるための仕組みを重視 … Toshihiro Ichitani All Rights Reserved.
WFも、アジャイルも、 ソフトウェアを作るという点は同じ 当たり前のことのように思えるけど、前提として重要。 ソフトウェア作りに必要になる「⾏為」は同じように必要ということ 何を作るべき か決める どう作るかを 判断する 利⽤に適した 品質の確保 WF 要件定義ですべて決めきる 設計ですべて決めきる 各⼯程及びテストで確保 Agile SprintPlanningで必要な分 だけ決める Sprintの中で適宜⾏う Sprint内及び、まとまった 分量は異なるが⾏為は必要 ⾏為として必要 テスト(QA)を⾏って確保 Toshihiro Ichitani All Rights Reserved. ⾏為として必要
ただし、 コミュニケーションの担保が異なる WFは、フェーズ間やフェーズ内で分業があり「受け渡し」が必要 ゆえに、ドキュメントで意思疎通を確実に⾏う作戦が取られる Agileは、「1つのチーム」でスプリントを連続させ続けるため、 「受け渡し」が発⽣しない ゆえに、過度な⾔語化が不要で、対話やラフな⾔語化でも⼗分通じる document document document document TeamA TeamB TeamC Toshihiro Ichitani All Rights Reserved.
設計 ⾏為として必要 設計書 「書」として必要なのは︖ ・設計⾏為のため︖ ・コミュニケーションのため︖ ・合意形成のため︖ ・記録のため︖ どの観点も程度はあれど必要 「必ず作るべし」を先⽴たせるから状況と tしない 何の⽬的のための⼿段かを⾒失わない fi Toshihiro Ichitani All Rights Reserved.
WF Agile 体制の あり⽅ 分業指向 (フェーズ間、フェーズ内) Oneチーム 意思疎通 の⽅法 ドキュメント による⾔語化 頻繁な対話 コミュニケーション 質を⾼める ⼯夫 ムラが出ないように テンプレやルールで 品質を確保 出来る限りチーム内 で完結するように 職能横断を前提 (標準や規定で規定する) Toshihiro Ichitani All Rights Reserved. (必要な専⾨スキルを結集させる)
Agileでありながら、これまでのやり⽅である 「ドキュメント中⼼」を踏襲してしまうと、 ドキュメント作り + 対話 スプリント内の作業が溢れ、肝⼼の開発が 進まず、チームがタスクに追われて疲弊する Toshihiro Ichitani All Rights Reserved.
WFとAgileの⾒た⽬上の違いは 「フェーズ」と「スプリント(反復)」にある WFが「前提」と置くことを理解し、かつ 「反復」で何を得たいのかを整理することで 両者の使い分けを会得しよう Toshihiro Ichitani All Rights Reserved.
WFが前提として置いていること ① 正解が何か分かっている ② ドキュメント(⾔語化)によって 意思疎通は可能である ③ 分業によって規模に⽴ち向かう Toshihiro Ichitani All Rights Reserved.
WFが前提として置いていること ① 正解が何か分かっている ② ドキュメント(⾔語化)によって 意思疎通は可能である ③ 分業によって規模に⽴ち向かう Toshihiro Ichitani All Rights Reserved.
要求 (何の変哲もないオンライン書店を例にすると) 要件 ・書籍名、タイトル、ジャンルで検索することができる ・カートに書籍を追加して、決済することができる ・購⼊したタイトルを履歴から確認できる 仕様 ・キーワードを⼊⼒し検索ボタンをクリックすると結果が表⽰される ・検索結果は、書籍のタイトル、著者、価格、評価、表紙画像を含む ・検索結果は最⼤50件まで表⽰され、ページング機能が提供される 設計 ・(UI設計)検索結果リストのレイアウト︓グリッド形式で1pageあたり5⾏×10列 ・(DB設計)書籍テーブル︓ID、タイトル、著者、価格、ジャンル、表紙画像URL ・(アーキテクチャ設計)検索サービス︓ユーザーからの検索リクエストを受け取り データベースから⼀致する書籍を取得し、結果を返す (実現したいこと。実現する ことで価値になる) (要求のためにソフトウェア として実現するべきこと) (要件を満たすためのより 詳細な条件) (仕様を満たすための⽅法) オンラインで書籍を購⼊できるようにしたい Toshihiro Ichitani All Rights Reserved.
確実に実現するための流れをつくる 具体詳細化と 要求 要件 仕様 設計 実現化の検討 何を、どのように実現したら 良いかを決める 決めたことに従い、実現する 実装 Toshihiro Ichitani All Rights Reserved.
作ったものが正しいか検査する 要求 要件 仕様 設計 要求を満たすか︖ 要件を満たすか︖ 仕様を満たすか︖ 設計を満たすか︖ 実装 Toshihiro Ichitani All Rights Reserved. テスト テスト テスト テスト
各フェーズを経ることで 「要求通りに正確に作る」ことを実現する 要求⾃体が正しいかどうかの検査は⾏わない = 要求が不正確な場合は機能しない Toshihiro Ichitani All Rights Reserved.
WFが前提として置いていること ① 正解が何か分かっている ② ドキュメント(⾔語化)によって 意思疎通は可能である ③ 分業によって規模に⽴ち向かう Toshihiro Ichitani All Rights Reserved.
そもそもなぜ隅々までの⾔語化が必要なのか︖ 分業体制のため (その是⾮については次項で扱う) 開発 チームA 発注者 受注者 開発 チームB ① 発注者が上位の情報を 作り受け渡す ② 開発を分担するため ⼀昔前にいた↓ 要件 定義者 開発 チームC 設計者 チーム間で情報の受け渡し必要 実装者 テスター ③ フェーズ間で担当者が異なるため情報の受け渡しが必要 Toshihiro Ichitani All Rights Reserved.
作るためには、「具体詳細化」が必要 ⼀⽅で、詳細化の最後は「コード」に⾏き着く (⼀昔前はもうコード書いたほうが早いやんということを ドキュメントにしていた時代があった) Toshihiro Ichitani All Rights Reserved.
つまり、「何を作るべきか︖」という詳細化は 必ず「抽象」に踏みとどまるところがあり 作る上では「抽象→具体」の変換を必要がある 抽象 具体 Toshihiro Ichitani All Rights Reserved.
抽象→具体の変換を補うものは︖ ① コミュニケーション (確認する) ② ドメイン知識、過去のPJでの経験知識 抽象 具体 コミュニケーション 経験知識 ⼀昔前から業務知識があるかが盛んに問われ、今も経験実績が問われる 理由とは1⾔って1理解ではなく、1から3、5を⽣み出す期待があるから Toshihiro Ichitani All Rights Reserved.
前項で述べたとおり、そもそも要求が不確かな場合 ⾔語化だけでは「正しさ」を明らかにできない 「実物を試す」が必要になる (どういうことかは後で) ︖ 実物 Toshihiro Ichitani All Rights Reserved.
WFが前提として置いていること ① 正解が何か分かっている ② ドキュメント(⾔語化)によって 意思疎通は可能である ③ 分業によって規模に⽴ち向かう Toshihiro Ichitani All Rights Reserved.
前提 正解(要求)は 何か分かっている (=⼿戻り不要) ドキュメンドで 意思疎通は可能 前提 分業が可能 (分解が可能) 作るべき機能は分解可能で、最後に まとめなおせば⽬的のモノになる コスト低減 受け渡された情報にもとづき、ただ 作れば良いという体制ができれば、 その分コストを抑えられる思惑 また、分解可能ということは規模を 分割し対処可能となるということ ⼤規模への対処 Toshihiro Ichitani All Rights Reserved.
現実は分業(分解)による負の影響は⼤きい ⽬的の⽋如 “群盲象を撫でる” 状態で、⽬的は何 だったか、得たい 成果は何か、誰も 他⼈事化 気にしていない ⾃分の受け持つフェーズさえ 全うできれば良く、先の段階で 実現可能なのか気にもしてない 局所最適 ⾃分のフェーズでのみ最適化を 図り、過剰な準備や作り込みを ⾏ってしまう Toshihiro Ichitani All Rights Reserved.
現実は分業による負の影響は⼤きい 要件と実装、 実装と実装(の結合)、 ⽬的の⽋如 “群盲象を撫でる” 実物と要求 状態で、⽬的は何 だったか、得たい を突き合わせた時はじめて、 成果は何か、誰も 気にしていない 他⼈事化 思うようになっていないということ が突きつけられる ⾃分の受け持つフェーズさえ 全うできれば良く、先の段階で 実現可能なのか気にもしてない 局所最適 ⾃分のフェーズでのみ最適化を (後になるほど影響は⼤きく、燃える) ⾏ってしまう 図り、過剰な準備や作り込みを Toshihiro Ichitani All Rights Reserved.
分業が機能しない︖ では、どうやって「規模」に⽴ち向かうの︖ Toshihiro Ichitani All Rights Reserved.
「時間」「意味」で分けて、結合を「頻繁化」 フェーズ1 (一次開発) フェーズ2 (二次開発) … 「時間」で分ける 最低限必要なものから始める MVP 検証結果 に基づく 開発 「意味」で分ける 価値は何かを確かめることから始める 分けるが同期・結合を 出来る限り「早くやる」 最終的にチームを分けて事にあたる、かもしれないが 状況・情報の同期、モノの結合を頻繁に⾏う Toshihiro Ichitani All Rights Reserved.
結合の「頻度」と「分量」のイメージ 結合頻度 「頻度多、分量少」が理想だが、 頻度が多すぎるとその分オーバーヘッドが ⼤きくなる可能性がある 「頻度多、分量少」でオーバーヘッドが ⼤きくならない頻度で同期・結合する → 1週間〜2週間 多 「頻度少、分量多」は従来のフェーズ指向 仮に受け渡す情報を明確にできたとして 相⼿が受け⽌められる量が問われる 少 少 多 Toshihiro Ichitani All Rights Reserved. 結合分量
なぜフェーズではなくスプリントか︖ スプリント(反復)の意味が⾒えてきた︖ Toshihiro Ichitani All Rights Reserved.
何のために「反復」するのか ① 「分かる」ようにするため ② 「結合のリスク」を減らすため ③ 「理解」をあわせるため ④ チームの「練度」を⾼めるため ⑤ 「関係性」を作っていくため Toshihiro Ichitani All Rights Reserved.
そもそも何を作るべきかが分かっていない …としたら「試すこと」で何が分かれば良い︖ Toshihiro Ichitani All Rights Reserved.
分かりたい対象の解像度をあげてみよう 課題 解くべき課題は 試す 合っているか︖ (要求の妥当性) 次の課題の探索 課題機能の t 形態 機能 機能は使えるように 課題解決に適した なっているか︖ (仕様設計の妥当性) ※利⽤者との界⾯ 機能形態の t 機能を特定しているか︖ (要件仕様の妥当性) 試す 試す fi fi Toshihiro Ichitani All Rights Reserved.
要求を定義する前の段階 =「仮説」 仮説 課題、機能、形態としての仮説を⽴て 検証を⾏う（試す）ことで確かめる 検証⽅法はインタビュー、 プロトタイプなど多岐にわたる 仮説 検証 費⽤対効果の良い⽅法を模索する 仮説検証の結果から 何が価値になるかを整理する Toshihiro Ichitani All Rights Reserved. 要求 (実現したいこと。実現する ことで価値になる)
仮説検証とは、 ソフトウェアを作って試すことではないの︖ Toshihiro Ichitani All Rights Reserved.
そもそもの課題や課題解決についての 確からしさが必要な段階で いちいちソフトウェアを作って検証では 割に合わない ⾼ プロトタイプ ソフトウェア 低 インタビュー 緻密なパワポ ⼩ ⼤ 検証(物)の リアリティ など 必要なリソース Toshihiro Ichitani All Rights Reserved. 分かっていること 分かりたいこと から検証⽅法を 選ぶ (費⽤対効果の⾼い検証⽅法は 模索し続ける必要がある)
みなさんのスクラムはどちら︖ 仮説の検証 実運⽤プロダクト のためのスクラム のためのスクラム Toshihiro Ichitani All Rights Reserved.
チェックしよう︕ 要求は確定 できている ︖︖︖ 開発に邁進 （Why Agileはみんなで確認しておこうか） 要求はまだ 仮説である あってる あってない 「モノを作って試す」で関係者と理解あってる︖ ﹅ ﹅ ﹅ ﹅ ﹅ ﹅ ﹅ ﹅ ﹅ ﹅ ﹅ ﹅ ﹅ ﹅ ﹅ ﹅ ﹅ もしくは何しているのか本当に理解できている︖ アジャイルやることが⽬的とかになってない︖ 仮説検証 のためのスクラム 実運⽤するプロダクト のためのスクラム Toshihiro Ichitani All Rights Reserved.
分かりたいことによって⽅法は異なる まだ課題の仮説が検証できていない 課題が合っているかの検証 (インタビューほか) 形態(IF)として適しているかが 検証できていない 課題は特定できているが課題解決に 有効な機能が検証できていない 理解できる、使えるかの検証 課題解決に適した機能かの検証 (プロトタイプ〜MVP検証) (プロトタイプ検証) Toshihiro Ichitani All Rights Reserved.
まとめると︖ 何が価値かを分かるための 仮説検証 (インタビュー、プロトタイプ) 適切に規模を分割する 範囲特定 開発レディにする 最⼩限の⾔語化 (スプリント0) (MVPアプローチ) 必要なのはドキュメント ではなく「⾏為」 現実のプロダクトを⽣み出す スクラムによる開発 実運⽤のための品質を担保する テスト・QA 上位の観点、⾮機能等 Toshihiro Ichitani All Rights Reserved.
正しいものを正しくつくる 仮説検証型アジャイル開発 選択の幅最⼤ （セットベース） 検証 計画 仮説⽴案 (モデル化) 価値探索 スプリント プランニング 検証 （正しいものを探す） 評価 仮説検証 選択肢を⼗分に 広げた後に絞る MVP特定 開発計画 (リリースプラ ンニング) アジャイル開発 （正しくつくる） スプリント レトロスペク ティブ 選択の振れ幅最⼩ （ポイントベース） スプリント 開発 MVP検証 スプリント レビュー 次の価値探索へ アジャイル 構想を早く形にして フィードバックを得る Toshihiro Ichitani All Rights Reserved. 44
何のために「反復」するのか ① 「分かる」ようにするため ② 「結合のリスク」を減らすため ③ 「理解」をあわせるため ④ チームの「練度」を⾼めるため ⑤ 「関係性」を作っていくため Toshihiro Ichitani All Rights Reserved.
https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf Toshihiro Ichitani All Rights Reserved.
アジャイルとは「常に結合する」ということ スプリント インクリメント CI/CD 常に統合し検証可能にする インクリメントはこれまでの すべてのインクリメントに追加 Toshihiro Ichitani All Rights Reserved.
アジャイルはOneチームだから 「受け渡し」問題は起きないのだよね︖ Toshihiro Ichitani All Rights Reserved.
プロダクトオーナー チーム スプリント バックログ プロダクト バックログ スプリント プランニング 全体(中距離) のプランニング スクラムマスター スプリント (活動) 起きるよ アジャイル リファイン メント デイリー スクラム (スクラム) スプリント レトロ スペクティブ アウプット による試⾏・適⽤ スプリント レビュー アウトプット ステークホルダー Toshihiro Ichitani All Rights Reserved.
何のために「反復」するのか ① 「分かる」ようにするため ② 「結合のリスク」を減らすため ③ 「理解」をあわせるため ④ チームの「練度」を⾼めるため ⑤ 「関係性」を作っていくため Toshihiro Ichitani All Rights Reserved.
PO → 開発チーム プロダクトバックログ → インクリメント 抽象的な要求 → コードという超具体 抽象から具体への変換を 何でもって担保するか︖ Toshihiro Ichitani All Rights Reserved.
POと開発チームの差とは 「どうあるべきか」という「基準」があるかどうか 開発チーム PO ユーザー 仮説検証 対話 ユーザーには POは仮説検証を 多くの場合 どうありたいかの 通じてユーザーの 開発チームには 「基準」がある 「基準」を宿す 「基準」がない もしくは基準は 顕在化しておらず 検証によって把握する もっと⾔うと解釈を加え どうあるべきかを ⾃分なりにつくる ゆえに対話によって いちいち基準と 照らし合わせをする Toshihiro Ichitani All Rights Reserved.
開発チームにも「⼩さな基準(ユーザー)」を宿す ユーザー PO 開発チームも仮説検証に 仮説検証 基準 仮説検証 基準 開発チーム 参画して「基準」を ⼀定持つことが出来たら︖ いちいちPOに照会せず ⾃分たちで判断できる ところが増やせる POと基準を全く同じにする必要もない 仮説検証にフル参画しないまでも ユーザーテストを定期的に実施するなどはできる Toshihiro Ichitani All Rights Reserved.
スプリントの積み重ねによって インクリメントが増える インクリメントが増えることで ユーザーに関する新たな知識(課題)を 知ることができる (知る機会が増やせる) ゆえに、ユーザーのことを⼀度知れば 良いわけではない スプリントとプロダクトが持続する限り 仮説検証(ユーザー理解)も継続する Toshihiro Ichitani All Rights Reserved.
何のために「反復」するのか ① 「分かる」ようにするため ② 「結合のリスク」を減らすため ③ 「理解」をあわせるため ④ チームの「練度」を⾼めるため ⑤ 「関係性」を作っていくため Toshihiro Ichitani All Rights Reserved.
各フェーズの「学び」が活きるのは「次のPJ」 ※チームがPJごとに解散する場合は 学びがいかせるかは個々⼈次第になる 次のPJ︖ 次のPJ︖ 次のPJ︖ スプリントの「学び」が活きるのは「次のスプリント」 学び 学び Toshihiro Ichitani All Rights Reserved.
スプリントによって⽣み出されるのは プロダクトだけではなくチームも⼀つの成果物になる Toshihiro Ichitani All Rights Reserved.
何のために「反復」するのか ① 「分かる」ようにするため ② 「結合のリスク」を減らすため ③ 「理解」をあわせるため ④ チームの「練度」を⾼めるため ⑤ 「関係性」を作っていくため Toshihiro Ichitani All Rights Reserved.
ソフトウェアは、⼈と⼈とで作る ゆえに、⼈と⼈との間の関係性が多⼤な影響を及ぼす 開発チームはさぼらずに全⼒で やってくれている︖ POも開発チームも、ただ⾃分たち が楽しいかしかないのでは︖ POは開発にやることをとにかく 押し込もうとしていないか︖ 関係性とは信頼のこと ⾏動をはやめることも、⾜踏みさせることもある Toshihiro Ichitani All Rights Reserved.
だから、チームビルディングをやるんだよね︖ もちろん、ビルディングワークも⼤事だけど それだけやっていたら、 強いチームになるわけではないよ Toshihiro Ichitani All Rights Reserved.
「やれる感」が私達の関係性を強くする つまり、⾃分たち⾃⾝で作り出す「結果」に ⾃分たち⾃⾝が励まされる 1回もスプリントを実施せずにビルディングワークだけ10回実施しているチームと、 1回でもスプリントを回しているチーム、どちらが本当の「やれる感」を得ているだろう︖ Toshihiro Ichitani All Rights Reserved.
成功循環モデルは 関係の質からスタートする チーム結成直後の初期段階や 節⽬におけるビルディングワークは重要 同時に関係の質を⾼めるは「⼀つ前の結果の質」でもある Toshihiro Ichitani All Rights Reserved.
最初はごく⼩さな結果でも良い 徐々に関係→思考→⾏動の質が⾼まり というか⼩さくしかできない 結果にそして次の関係性につながっていく スプリントの分だけ関係性を⾼める機会が得られるということ Toshihiro Ichitani All Rights Reserved.
WFで「やれる感」を得るのは後半、終盤︖ 実装が進むにつれて「やれる感」よりむしろ 「やれない感」が⾒えてくる︕︖ いくら要件定義や設計だけ進めても プロダクトとしての「やれる感」は不明 苦しくもリリースをやりとげて、 確かに「やれた感」は得られる…︖ アジャイルでは「1つ⽬のスプリント」から機会がある 結果 結果 最初の段階では「失敗」 「うまくいかない」も 次に良くなるための 「伸びしろ」にあたる (というかそういう⾒⽅をあえてすること) Toshihiro Ichitani All Rights Reserved.
「⼈を分けない」からこそ 「全体」が分かり、 ⾃分が何を果たせば良いかも分かる 「全体」=「個別フェーズ」になりやすい 「全体」をチームで理解する 「全体」=「プロダクトゴール」 「各スプリントの全体」 =「スプリントゴール」 「各スプリントの全体」 =「スプリントゴール」 「各スプリントの全体」 =「スプリントゴール」 Toshihiro Ichitani All Rights Reserved.
受け渡しとともに 「ちゃんと作る」の責務 も受け渡し 受け渡ししない 「ちゃんと作る」の責務を チーム全員で背負う Toshihiro Ichitani All Rights Reserved.
でも、アジャイルにやるには “マインドセット” が必要なんでしょう︖ Toshihiro Ichitani All Rights Reserved.
“必要なマインドセット” として表現することは 「⾔葉」としては理解できるかもしれない でも、「⾏為」としては分かったことにはならない ⾔葉 ⾏為 Toshihiro Ichitani All Rights Reserved.
⾃分たちの⾏為⾃体から、 望ましいあり⽅を少しずつ学ぶ それも確実に⾔えることではない 出来ることは、 学び直す機会を設けておくこと 学べるかは確実ではないけども、 学ぶ機会⾃体を置くかは⾃分たちの意志次第にできるよね Toshihiro Ichitani All Rights Reserved.
アジャイルにはそれが備わっている Toshihiro Ichitani All Rights Reserved.
なぜ、アジャイルだと ﹅ ﹅ ﹅ ﹅ ﹅ ﹅ ﹅ ﹅ ﹅ ﹅ 楽しくなってくるのか︖ Toshihiro Ichitani All Rights Reserved.
なるべくしてなる。 Toshihiro Ichitani All Rights Reserved.
楽しさと、前進を得ていこう。 Photo credit: digitalpimp. on Visualhunt.com / CC BY-ND