1. アジャイルのはじまり 〜なぜアジャイルは生まれたのだろう？〜 2024年1月26 @ In niStudy fi 株式会社アトラクタ 細澤あゆみ
2. 細澤あゆみ /Ayumi Hosozawa - 清水出身 - 静岡県立大学大学院 修了 - 大学在学中にアジャイルに出会う - 卒業後、スクラムチームでのソフトウェア開発や、基幹系システム 再構築の経験を積む - Regional Scrum Gathering Tokyo 実行委員、XP祭り実行委員、ス クフェス三河実行委員 - 産業技術大学院大学非常勤講師(2021) 2
3. 株式会社アトラクタについて ✤ 社名：株式会社アトラクタ 英文表記：Attractor Inc. / https:// www.attractor.co.jp ✤ 設立：2016年12月 ✤ 所在：東京都港区 ✤ 開発プロセスに関するコンサルティングやトレーニングを提供 ✤ アジャイル開発 / DevOps / チーム育成 / クラウドコンピューティング / ドメインモデ リングなどが専門領域 3
4. 登壇 各種イベントでの登壇 コーチング トレーニング 執筆・翻訳 アジャイル開発やDevOps に関するコーチング アジャイル開発や組織づくり に関する各種トレーニング 技術書やドキュメントの 執筆や翻訳 認定研修 認定スクラムマスター研修 Suitable for all categories 等の主催 business and personal などなど
5. HPより受付中！ https://www.attractor.co.jp/ 5
6. アジャイルとは何か？ ✤ アジャイルとは、変化を生み出し、それに対応する能力のこと ✤ ✤ 不確実で激動の環境に対処し、最終的には成功するための方法 現在あなたがいる環境で何が起こっているのか理解し、直面している不確実性を特定 し、それにどのように適応していくか考えること Agile Alliance 『What is Agile?』 https://www.agilealliance.org/agile101/ 6
7. アジャイルソフトウェア開発とは ✤ 「アジャイルソフトウェア開発宣言」とその背後にある「12の原則」に示された価値観 と原則に基づく一連のフレームワークとプラクティスの包括的な用語 ✤ スクラム、エクストリームプログラミング、機能駆動開発（FDD）などの具体的なフ レームワークより広い概念 ✤ ペアプログラミング、テスト駆動開発、スタンドアップ、プランニングセッション、スプ リントなどのプラクティス以上のもの Agile Alliance 『What is Agile?』 https://www.agilealliance.org/agile101/ 7
8. アジャイルに開発してますか？ ✤ 『アジャイルソフトウェア開発宣言』（2001年）が発表されてから23年… 8
10. 時価総額ランキング 2019 (6末) 2007 1. マイクロソフト (10265億ドル) 1. エクソンモービル (4685億ドル) 2. Amazon (9322億ドル) 2. GE (3866億ドル) 3. アップル (9106億ドル) 3. マイクロソフト (2936億ドル) 4. アルファベット (7510億ドル) 4. CITIグループ (2695億ドル) 5. Facebook (5509億ドル) 5. ペトロチャイナ (2618億ドル) 10
11. ソフトウェアを取り巻くビジネス環境の変化 ✤ ビジネスの変化がどんどんはやくなっている ✤ VUCA ✤ Volatility (不安定)、Uncertainty (不確実)、Complexity (複雑)、Ambiguity (曖昧) ✤ やってみないとわからないことが増えてきた ✤ ソフトウェア自体がビジネスに貢献する比重が大きくなってきた、ソフトウェア（デジタル技術）自体がビジ ネスそのものに ✤ 多くのサービスが10数年以内に登場し既存のビジネスモデルに影響を与えたり、人の働き方を変えている ✤ ✤ Zoom（2011）、Slack（2013）、Discord（2015）、Uber（2009）、Instagram（2010）、Airbnb（2008）、 Mericari（2013）、MoneyFoward（2012） ITはビジネス上の成果達成のための重要な要素に 11
13. 昔ながらのプロダクトやシステムの作り方 要求を全部あつめる 見積もる まとめて作る まとめて確認する 13
15. システムの機能の約6割は使われない 7% 13% 全く使わない ほとんど使わない たまに使う よく使う いつも使う 45% 16% 19% The Standish Group “Chaos” report 2002 15
16. 7つのムダ ✤ 作りすぎのムダ => 使わない機能 ✤ 手待ちのムダ => 仕様未決で開発待ち ✤ 運搬のムダ => 他部署への引き継ぎ ✤ 加工のムダ => ドキュメントの体裁 ✤ 在庫のムダ => 同時にたくさん着手 ✤ 動作のムダ => 不要な作業、遅い作業 ✤ 不良を作るムダ => バグ修正 16
17. つまり ✤ 最初に要求を全部集めても、それがあっている保証がない ✤ 一度機会を逃すと機能を追加するのが当面先になるので、とりあえず必要そうなもの をたくさん入れようとする力が働く ✤ ただしそうやって「必要かもしれない」と思って入れた機能は使われない ✤ これは価値を産んでいない(ムダ) ✤ 規模が大きくなると加速度的に保守の労力が上がり、速度が遅くなっていく 17
18. 昔ながらのプロダクトやシステムの作り方 要求を全部あつめる 見積もる まとめて作る まとめて確認する 18
19. 費用とスケジュール見積りは難しい 不確実性コーン 19
20. 見積もる人と作る人が違うとさらに難しい ✤ 作るチームが違えば、(本当は)見積りも変わってくる ✤ 作業する人と見積もる人が違うと見積もりはさらに当たらりづらくなる 20
21. 鉄の三角形 (Iron Triangle) 21
22. 昔ながらのプロダクトやシステムの作り方 要求を全部あつめる 見積もる まとめて作る まとめて確認する 22
23. 開発フェーズで起こりがちなこと ✤ ✤ 設計した人と作る、テストする人が別 ✤ 受け渡しのムダ ✤ 設計書の曖昧性を減らそうとして設計書の作成に時間がかかる、プログラム設計 書になる（作った方が早い） ✤ テストする人が仕様の理解ができていない 実装中に判明した不具合や修正点の反映がされない、もしくは実施が大変 設計する人 開発する人 テストする人 23
24. そこで起こること ✤ 頼んだものと違うと言われる ✤ バグだらけ ✤ 期日に間に合わない ✤ ただでさえ時間がかかったのにさらに時間がかかる ✤ ビジネスチャンスをどんどん逃す 24
25. 伝統的な開発モデルの問題点 ✤ 前工程が正しいことを前提としている ✤ 対応する後工程のテストによって問題が発見される ✤ 前工程の遅れが後工程に影響する ✤ 工程によって担当者が変わることがある ✤ プロジェクト期間が長いほどリスクが高い 要求分析 受け入れテスト 基本設計 システムテスト 機能設計 結合テスト 詳細設計 単体テスト コーディング 25
26. 結果的にこうなっている… プロジェクト成功率の推移 2011 2012 2013 2014 2015 成功した 29% 27% 31% 28% 29% 課題が残った 49% 56% 50% 55% 52% 失敗した 22% 17% 19% 17% 19% ※ 成功要因の定義（期日通り、予算通り、満足のいく結果）を用いて、 過去5年間のプロジェクトの成果を要約したもの 出典： Standish 2015 CHAOS Report 26
27. 結果的にこうなっている（手法による成功率） 手法 成功した 課題が残った 失敗した アジャイル 39% 52% 9% ウォーターフォール 11% 60% 29% ※ 過去5年間のプロジェクトの成果1万件超をアジャイルとウォーターフォールに区分したもの 出典： Standish 2015 CHAOS Report 27
28. 結果的にこうなっている（手法/規模による成功率） 規模 手法 成功した 課題が残った 失敗した アジャイル 18% 59% 23% ウォーターフォール 3% 55% 42% アジャイル 27% 62% 11% ウォーターフォール 7% 68% 25% アジャイル 58% 38% 4% ウォーターフォール 44% 45% 11% 大 中 小 ※ 過去5年間のプロジェクトの成果1万件超をアジャイルとウォーターフォールに区分したもの 出典： Standish 2015 CHAOS Report 28
29. すなわち従来のやり方は… ✤ バッチサイズが大きすぎる ✤ フィードバックサイクルが長すぎる ✤ そもそもサイクルが回っていない可能性 ✤ リスクは後半ほど顕在化する ✤ 変化に対応できない ✤ (※ もちろん変化がない領域であれば問題はないし、そういう場合では従来の手 法が有効に機能することもある） 29
30. ここまでの整理 ✤ よいソフトウェアを顧客に届けることはビジネスにとって極めて重要 ✤ 世の中の変化の速度がどんどん速くなっている ✤ 変化が起こる状況では事前にスコープを洗い出すのは困難 ✤ スコープを固定しようとするとムダなものをたくさん作ってしまう ✤ あわせて見積り自体もやったことのない領域のものは難しい ✤ すなわち変化がある領域では従来のやり方は機能しない 30
31. やり方を見直す ✤ バグがあったときの直すのはプロセス ✤ 繰り返しのない仕組みは改善するのが難しい 31
32. アジャイルマニフェスト 2001年に、ケント・ベック、マーティン・ファウラーら、 17人によって採択された Agileソフトウェア開発の価値観を指す 32
34. アジャイル開発の12原則 ✤ 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します ✤ 要求の変更はたとえ開発の後期であっても歓迎します ✤ 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースし ます ✤ ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません ✤ 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終 わるまで彼らを信頼します ✤ 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすること です 34
35. アジャイル開発の12原則 ✤ 動くソフトウェアこそが進捗の最も重要な尺度です ✤ アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持 できるようにしなければなりません ✤ 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます ✤ シンプルさ（作らず済ませる量を最大限にすること）が本質です ※ ✤ 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます ✤ チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自 分たちのやり方を最適に調整します ※ 誤訳箇所を一部改変 35
36. 予測主義 vs 経験主義 ✤ ウォーターフォール型の開発手法(予測主義)は、先のことまで見通した正しい計画が 作れることを前提にしている。対象プロジェクトには変化があるか？ ✤ アジャイル開発とは経験主義に基づく軽量な進め方。経験した事実を踏まえて計画を 修正し続ける。修正範囲にはスコープも含まれる 36
37. 従来型とアジャイルのアプローチの違い 予見的プロセス 経験的プロセス 立ち上げ プロジェクト憲章など インセプションデッキなど 計画 初期にすべてを計画する 全体をざっくり、直近を詳細に 見積り PMが一人で見積もる チーム全員で見積もる 見積り方法 絶対的 相対的 成功の基準 計画通りだったか 現実に対応できたか 品質 終盤でテストをして確保 序盤から作り込み リスク管理 PMBOK等では規定されている 検査と適応を常時行う 文化 コマンド&コントロール 協調的リーダーシップ、自己組織化 情報共有 ドキュメント、形式知重要 会話、暗黙知重視 ツール使用 時に政治的、慣行的に選択 人的負担軽減のための自動化 生産性向上 生産量の増加 労力の低減 37
38. 反復型開発≠アジャイル開発 Henrik Kniberg『Making sense of MVP (Minimum Viable Product) – and why I prefer Earliest Testable/Usable/Lovable』 https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp 38
39. アジャイルはマインドセット ✤ アジャイルはアジャイルマニフェストの価値観と原則に基づいた考え方 ✤ どのようにして変化を生み出し、変化に対応し、不確実性に対処するかについての 指針 ✤ 不確実性に直面したときは、うまくいきそうなことを試し、フィードバックを得て、それに 応じて調整する ✤ 価値観と原則を念頭に置くこと。チームと協力してお客さまに価値を提供するために、 どのフレームワーク、プラクティス、テクニックを使うかは、あなたの状況に合わせて決 めてください Agile Alliance 『What is Agile?』 https://www.agilealliance.org/agile101/ 39
40. “アジャイル”の意味 ✤ agile [US] dʒəl （ロングマン英英辞典/ロングマン英和辞典） ✤ 1. able to move quickly and easily ✤ 2. someone who has an agile mind is able to think very quickly and intelligently ✤ 1. 機敏な, すばしこい ✤ 2. 頭の回転の速い, 鋭敏な 「アジャイル」は形容詞 40 ǽ ✤
41. アジャイルなマインドセット こちこち アジャイル 能力は 変わらない 成長できる 目的は 見栄えのよさ 学び 挑戦を 避ける 受け入れる 失敗は 自分を決める 情報をくれる 努力は 才能のない人 熟達への道 挑戦への反応 無力感 弾力/回復力 『失敗を学びに変えるアジャイルなマインドセットとは？～Agile 2011 Conference』 https://enterprisezine.jp/iti/detail/3400 41
42. まとめ ✤ ソフトウェアを取り巻くビジネス環境の変化が激しくなってきた ✤ ソフトウェアが重要性も高まってきている ✤ 従来のソフトウェアの作り方ではうまくいかないことが多くなってきた ✤ 新しいやり方として”アジャイルな”ソフトウェア開発が誕生した ✤ アジャイルは変化に対応する能力であり、マインドセット ✤ 現状から常に考え続けることが必要 42
43. アジャイルコミュニティの紹介 ✤ Regional Scrum Gathering Tokyo - 2025年1月 ✤ 各地Scrum Fest ✤ Okinawa ✤ Fukuoka - 2024/3/8〜9 ✤ Osaka ✤ Mikawa ✤ Sendai ✤ Niigata ✤ Sapporo(去年はニセコ） ✤ XP祭り - 毎年9月 ✤ その他にもたくさんあります 43
