われわれはなぜアジャイルに向かうのか

われわれはなぜ アジャイルに向かうのか 開発をアジャイルにしていくために 読むべき最初の⼿引き Ichitani Toshihiro Toshihiro Ichitani All Rights Reserved. 市⾕聡啓

Ichitani Toshihiro 市⾕聡啓 ギルドワークス株式会社 代表 株式会社 エナジャイル 代表 ⼀般社団法⼈ 越境アジャイルアライアンス代表理事 DevLOVE コミュニティ ファウンダ ソフトウェア開発16年 SIer→サービス→受託→起業 仮説検証とアジャイル開発 0→1 http://about.me/papanda0806 Toshihiro Ichitani All Rights Reserved.

• http://about.me/papanda0806

皆さんは、アジャイル開発という⾔葉に 様々な場⾯で既に遭遇しているかと思います。 どんな⾯持ちでしょう？ Copyright (c) 2017 Guild Works Inc.

皆さんは、アジャイル開発という⾔葉に 様々な場⾯で既に遭遇しているかと思います。 どんな⾯持ちでしょう？ 「取り組んでいるが上⼿くやれているか分からない」 「アジャイル開発？今更(笑」 Copyright (c) 2017 Guild Works Inc.

皆さんは、アジャイル開発という⾔葉に 様々な場⾯で既に遭遇しているかと思います。 どんな⾯持ちでしょう？ 「取り組んでいるが上⼿くやれているか分からない」 「アジャイル開発？今更(笑」 アジャイルに向き合うのに今更も へったくれもありません！ Copyright (c) 2017 Guild Works Inc.

なぜなら、アジャイルとは度合いだから。 “アジャイル開発”という実体があるわけではない。 (歴史的な成り⽴ちからして) Copyright (c) 2017 Guild Works Inc.

なぜなら、アジャイルとは度合いだから。 “アジャイル開発”という実体があるわけではない。 (歴史的な成り⽴ちからして) 実体としては「XP」「スクラム」「リーン開発」 などがよく挙がる。 そして、 「そのチームにとっての開発のあり⽅、やり⽅」も ”アジャイルな開発”と⾔える。 Copyright (c) 2017 Guild Works Inc.

度合いって何のこと？ ⼀⾔でアジャイルな開発を表現すると (共通的な特徴は) 少しずつ反復的に開発を進めることで 必要とする⼈から必要なフィードバックを得て 調整し続けられる開発 →“アジャイルさ” = 「変化に適応できる度合い」 「アジャイル開発者の習慣」 http://gihyo.jp/dev/serial/01/agile Copyright (c) 2017 Guild Works Inc.

• http://gihyo.jp/dev/serial/01/agile

皆さんは、アジャイル開発という⾔葉に 様々な場⾯で既に遭遇しているかと思います。 どんな⾯持ちでしょう？ 「取り組んでいるが上⼿くやれているか分からない」 「アジャイル開発？今更w」 アジャイルに向き合うのに今更も へったくれもありません！ この時間では、アジャイルな開発とは何か あらためて問い、どのように向き合っていくか をテーマに致します。 Copyright (c) 2017 Guild Works Inc.

本⽇のテーマ なぜ、アジャイルに向かうのか。 背景 よくある問題 乗り越える Copyright (c) 2017 Guild Works Inc.

関係者それぞれの期待が異なり、 出来たモノと違っていたと分かった。 Copyright (c) 2017 Guild Works Inc.

関係者それぞれの期待が異なり、 出来たモノと違っていたと分かった。 システムテストに⾄るまで、完成品が 確認できなかった。結果、最後の調整が膨⼤に。 Copyright (c) 2017 Guild Works Inc.

関係者それぞれの期待が異なり、 出来たモノと違っていたと分かった。 システムテストに⾄るまで、完成品が 確認できなかった。結果、最後の調整が膨⼤に。 でも、考えていること、期待していることを ドキュメントですべて表現できない。 Copyright (c) 2017 Guild Works Inc.

関係者それぞれの期待が異なり、 出来たモノと違っていたと分かった。 システムテストに⾄るまで、完成品が 確認できなかった。結果、最後の調整が膨⼤に。 でも、考えていること、期待していることを ドキュメントですべて表現できない。 最後のテストで、技術的な問題噴出。 Copyright (c) 2017 Guild Works Inc.

関係者それぞれの期待が異なり、 出来たモノと違っていたと分かった。 システムテストに⾄るまで、完成品が 確認できなかった。結果、最後の調整が膨⼤に。 でも、考えていること、期待していることを ドキュメントですべて表現できない。 最後のテストで、技術的な問題噴出。 構想してから、市場に投⼊するまでの 期間が⻑すぎる。 Copyright (c) 2017 Guild Works Inc.

関係者それぞれの期待が異なり、 出来たモノと違っていたと分かった。 システムテストに⾄るまで、完成品が 確認できなかった。結果、最後の調整が膨⼤に。 る あ に 分 でも、考えていること、期待していることを ⼗ が 義 意 う か 向 に ドキュメントですべて表現できない。 ル イ ャ アジ 最後のテストで、技術的な問題噴出。 構想してから、市場に投⼊するまでの 期間が⻑すぎる。 Copyright (c) 2017 Guild Works Inc.

アジャイルな開発のプロセス的な特徴 少しずつ反復的に開発を進めることで 必要とする⼈から必要なフィードバックを得て 調整し続けられる開発 Copyright (c) 2017 Guild Works Inc.

フェーズゲート開発 要件定義 設計 実装 テスト リリース アジャイルな開発 開発された ボリューム Copyright (c) 2017 Guild Works Inc.

アジャイルな開発のプロセス的な特徴 少しずつ反復的に開発を進めることで 必要とする⼈から必要なフィードバックを得て 調整し続けられる開発 「インクリメンタル」(少しずつ) 「イテレーティブ」(繰り返し) つまり「早く(少しだけ)形にできる」やり⽅ Copyright (c) 2017 Guild Works Inc.

早く(少しだけ)形にできることの意義 ① フィードバックに基づく調整で、⽬的に適した ソフトウェアに仕⽴てられる ② 形にすることで早めに関係者の認識を揃えられる ③ つくるものやチームについての問題早く気付ける ④ チームの学習効果が⾼い ⑤ 早く始められる ⑥ 結合のリスクを早めに倒せる ⑦ Time to market が短い ⑧ サンクコストが⼩さくできる ⑨ 開発チームのリズムを整えられる Copyright (c) 2017 Guild Works Inc.

形にすることで早めに関係者の認識を揃えられる そもそも、関係者(ビジネス側、ビジネスとチーム間、 チーム内で)つくるものの解釈が異なっている。 最初から、完成型が構想できない。 誰かが正解を持っているわけではない。 ドキュメントですべてを書き尽くせない。 それはコードになる。 「形にするためのコミュニケーションの過程」や 「形にしたものの動き」から共通理解を育める Copyright (c) 2017 Guild Works Inc.

アジャイル開発は、ドキュメント つくらない？ Copyright (c) 2017 Guild Works Inc.

アジャイル開発は、ドキュメント つくらない？ 開発するために必要なことは減らない！ アジャイルな開発にすることで、急に開発に必要 だった⼿順がなくなるわけではない。 コード以外の記述が全く不要なわけではない。 ただし、「理解や伝達のための成果物」は 最低限にしておくこと。 Copyright (c) 2017 Guild Works Inc.

つくるものやチームについての問題早く気付ける 開発を⼀巡させるのが早いため、プロダクトやチームの 問題に早く気付ける。 コードが書けない = バックログの完成の条件を詳細にする。 バックログが消化できない = チームに必要なタレントを巻き込む。 認識の齟齬が多い = コミュニケーションの内容、頻度の調整。 要件の実現⽅法が分からない = 技術的な実現可能性の検証。 改修時のデグレが多い = ⾃動回帰テストの充実。 Copyright (c) 2017 Guild Works Inc.

チームの学習効果が⾼い 「常に最初から同じメンバーで継続的に活動」が前提 異なる担当者に伝達 伝達 伝達 Copyright (c) 2017 Guild Works Inc.

早く始められる 全ての要件を決めきる必要がない = 部分を後回しに出来る 結合のリスクを早めに倒すこと 常に結合。 Time to marketが短い 早いスプリントからリリースできる = 早く収益化できる。 サンクコストが⼩さくできる 早いスプリントから評価が出来るため、途中でやめられる。 開発チームのリズムを整えられる チームの実状に計画をあわせられる。 Copyright (c) 2017 Guild Works Inc.

アジャイル開発は、計画しない？ 確かに、綿密な細か〜い、スケジュール表を 最近は⾒かけなくなりましたね！ だけど、 細かいスケジュールをつくらない ≠ 計画しない というわけでは決してない。 Copyright (c) 2017 Guild Works Inc.

むしろ、頻繁に計画づくりを⾏う。 アジャイルな開発では、イテレーションと呼ばれる 単位で、時間を区切り開発を進める。 各イテレーションで何をするのかは 「イテレーション計画ミーティング」 という場で、イテレーション毎に毎回⾏う。 Copyright (c) 2017 Guild Works Inc.

むしろ、頻繁に計画づくりを⾏う。 アジャイルな開発では、イテレーションと呼ばれる 単位で、時間を区切り開発を進める。 各イテレーションで何をするのかは 「イテレーション計画ミーティング」 という場で、イテレーション毎に毎回⾏う。 毎回。イテレーションを1週間で回しているなら 毎週、計画づくりをするってこと！ なぜやるかって？頻繁に計画づくりしたほうが、 現実から乖離した計画を追わなくて済むよね。 Copyright (c) 2017 Guild Works Inc.

アジャイル開発は、⾒積もりしない？ Copyright (c) 2017 Guild Works Inc.

アジャイル開発は、⾒積もりしない？ ⾒積もりは、2つのプランニングで必要になるよ。 ①「リリースプランニング」 ②「イテレーション(スプリント)プランニング」 Copyright (c) 2017 Guild Works Inc.

アジャイル開発は、⾒積もりしない？ ⾒積もりは、2つのプランニングで必要になるよ。 ①「リリースプランニング」 ②「イテレーション(スプリント)プランニング」 やることに対して⾒積もりをしないと、全体として 何イテレーション必要なのかが分からない(①)し ⽬の前のイテレーションでチームとしてどこまで できそうなのか⾒⽴てることができない(②) Copyright (c) 2017 Guild Works Inc.

⾒積もりは相対的に⾏う A.コップの⽔の量がどのくらいあるか？ B.右のコップの⽔の量は左に⽐べてどのくらいか？ Copyright (c) 2017 Guild Works Inc.

アジャイル開発は、フェーズゲート開発 よりも早く済むし、お安く済むんでしょ？ Copyright (c) 2017 Guild Works Inc.

アジャイル開発は、フェーズゲート開発 よりも早く済むし、お安く済むんでしょ？ ムダが減らせる分は、早くたどり着けるかもしれ ないし、コストも抑えられるかもしれない。 …ただし、イテレーション開発とは、そもそも 試⾏錯誤をするために時間を区切っているわけ だから、つくる⽅向性の調整が今までより細かく できるようになるということは、期間もコストも ⼤きくなる可能性があるということ。 Copyright (c) 2017 Guild Works Inc.

Copyright (c) 2017 Guild Works Inc.

☓ ◯ △ △ Copyright (c) 2017 Guild Works Inc.

本⽇のテーマ なぜ、アジャイルに向かうのか。 背景 よくある問題 乗り越える Copyright (c) 2017 Guild Works Inc.

少しずつ形にするにあたっての問題 (a) 忙しい。 常に開発をしている、常に確認をするということは 常に開発チームと共にあるということ Copyright (c) 2017 Guild Works Inc.

少しずつ形にするにあたっての問題 (b) ある程度の腕が求められる。 各タスクにある程度 ⻑い時間をかける 最初から⼀通りのスキルが必要。 最初は圧倒される可能性がある。 早めに失敗できるので、何が ボトルネックになるか気付き易い。 (最初は進捗が上がりにくい) Copyright (c) 2017 Guild Works Inc.

少しずつ形にするにあたっての問題 (c) チームを越えて対象を分割すると、同期が難しい チームを分割した場合、 フェーズではなくて、 タイムボックスで同期を 取るため、取れ⾼が容易に ずれる。 作っているモノを同期しなけ ればならないときに、揃える 難しさがある。 Copyright (c) 2017 Guild Works Inc.

少しずつ形にするにあたっての問題 (d) QCDに特徴的な課題がある 「品質の維持」のためのコストが必要 →少しずつ作るので、作る度に既存機能に改修の影響が発⽣する タイムボックス分割分のオーバーヘッドがある 「品質とコスト」を⼀定とすると、「スコープ」と「納期」で 調整する必要がある = ローンチタイミングが守られるか Copyright (c) 2017 Guild Works Inc.

少しずつ形にするにあたっての問題 (e) そもそも考え⽅が関係者であっていない 「いままでと違うやり⽅」について、 上層部、現場メンバーそれぞれに対して考え⽅が合わない。 Copyright (c) 2017 Guild Works Inc.

本⽇のテーマ なぜ、アジャイルに向かうのか。 背景 よくある問題 乗り越える Copyright (c) 2017 Guild Works Inc.

「忙しい問題」の乗り越え⽅ (i) ⻑期的には、プロダクトオーナーを育てる。 ふるまいを⾝に付け、時間を取れること。 (ii) 短期的には、代理のプロダクトオーナーを⽴てる。 ※ バックログの⼊れ替えである程度対処は可能だが 本質的には「プロダクトオーナーの判断」以上には 全体のスピードは早まらない。 Copyright (c) 2017 Guild Works Inc.

「ある程度腕が求められる」乗り越え⽅ (i) ⼤⽬に⾒る。 (ii) チームの状態にあわせて段階的な移⾏が必要。 ・プラクティスを少しずつ取り⼊れる ・第1段階 開発上の問題を取り除く (ふりかえり、タスクボード、スタンドアップミーティング) ・第2段階 開発だけ反復 ・第3段階 プロダクトオーナーを巻き込んだ開発 Copyright (c) 2017 Guild Works Inc.

「同期問題」の乗り越え⽅ (i) チーム内の同期 → 計画ミーティング、デイリー、デモ、 (ii) チーム外との同期 → 階層化=「デイリーカクテルパーティ」 Copyright (c) 2017 Guild Works Inc. 第3章：デイリーカクテルパーティーに参加しよう

「QCD問題」の乗り越え⽅ (i) 品質の維持へのコスト → ⾃動回帰テスト (ii) タイムボックスオーバーヘッド問題 → 反復の必要性を問う (iii) ローンチタイミングが守られるか → 常にシミュレーションが必要(着地予想)。 納期とスコープのトレードオフを判断し続ける。 Copyright (c) 2017 Guild Works Inc.

「考え⽅あわない問題」の乗り越え⽅ アジャイルな開発に取り組み始める際に準備が必要 → インセプションデッキ ・なぜ必要なのか ・どうやってやるのか ・この現場での課題とは何か Copyright (c) 2017 Guild Works Inc.

インセプションデッキは 何のために必要？ Copyright (c) 2017 Guild Works Inc.

インセプションデッキは 何のために必要？ プロジェクトを始めるにあたって、 前提と制約、背景と現状などについて 関係者の間で認識を共通にすることで ⽅針や判断基準を揃える。 その結果、チームが状況に応じた適切な判断を 下せるようになることを期待する。 Copyright (c) 2017 Guild Works Inc.

導⼊にあたっての作戦 ① 段階的にやる (プラクティス導⼊) ② コミットメント(特に納期)の調整が効きやすい領域から ③ 経験豊かな⼈を混ぜ込む Copyright (c) 2017 Guild Works Inc.

自分の現場で何から始めたら良いのか Copyright (c) 2017 Guild Works Inc.

型としてのアジャイル開発との⽐較を⾏う(1/3) ※ここでの型はスクラムガイド及び アジャイルサムライ、リーン開発の 現場を前提 型としてのアジャイル開発 あなたのチーム ⻘字は今後やると良さそうなこと ・1チーム、両⼿未満 ・プログラマ、デザイナ、プロジェクトマ チーム ネージャ、アナリスト、テスター等 ・開発チーム、PO、スクラムマスター ・必要に応じた役割と定義と期待 ・プロジェクトの⽅向付けやチームビルド ⽅向付け e l p m Sa を⾏う ・フレームは、インセプションデッキ ・管理⼿段は、プロダクトバックログ ・形式は、ユーザーストーリー形式(INVEST) 要求 ・完成の定義がある ・バックログを練る、伝える機会がある →バックログリファインメント ・プロダクトバックログを元に、リリース 時期を⾒定める リリース計画 ・チームのベロシティ(仮定でおく) ・バックログの⾒積もり(相対⾒積) →プランニングポーカー Copyright (c) 2016 Guild Works Inc. 54

この先にあるのは？ 「少しずつ形にできるようになる」 つまり「体のコントロール」と同じ。 Copyright (c) 2017 Guild Works Inc.

この先にあるのは？ 「少しずつ形にできるようになる」 つまり「体のコントロール」と同じ。 「体のコントロール」 = 頭で考えたことを即座に伝えて、 体の部分を思うようにすぐに動かせる Copyright (c) 2017 Guild Works Inc.

この先にあるのは？ 「少しずつ形にできるようになる」 つまり「体のコントロール」と同じ。 「体のコントロール」 = 頭で考えたことを即座に伝えて、 体の部分を思うようにすぐに動かせる 「体のコントロール」のようにソフトウェアをつくる = 必要なことを即座に伝えあい、 すぐに試せる、形にできる。 Copyright (c) 2017 Guild Works Inc.

最後に、再び。 “アジャイル開発”という実体があるわけではない。 実体としては「XP」「スクラム」などがあり、 先⼈の肩越しに、⾃分たちの開発を変化に適応 できるようになることが「アジャイルである」こと。 ⾃分たちの意思と、その実現のための開発が 限りなく⼀致していくこと！ Copyright (c) 2017 Guild Works Inc.

「正しいものを正しくつくる」ギルドワークス https://guildworks.jp/ 「越境をエナジャイズする」エナジャイル https://enagile.jp/ 「SoE、SoRで越境する戦略と戦術を得る」越境アジャイルアライアンス https://www.tagile.org/ 「開発現場のためのコミュニティ」DevLOVE Copyright (c) 2017 Guild Works Inc. https://devlove.doorkeeper.jp/

• https://guildworks.jp/
• https://enagile.jp/
• https://www.tagile.org/
• https://devlove.doorkeeper.jp/