アジャイルソフトウェア開発とは

アジャイルソフトウェア開発（およびスクラム開発）を非エンジニアにもわかりやすく噛み砕いた表現で説明した資料です

Transcript

1. アジャイル開発で素早く価値を創造し 社会の課題解決へつなげる
2. アジャイルソフトウェア開発とは
3. はじめに
4. 1. なぜアジャイルなのかを知る 2. アジャイル開発と非アジャイル開発を知る 3. アジャイル開発のプロセスを 1 つ例にとって感じてみる 今日のゴール
5. 1. なぜアジャイルなのかを知る 2. アジャイル開発と非アジャイル開発を知る 3. アジャイル開発のプロセスを 1 つ例にとって感じてみる 今日のゴール
6. 今の世の中って？
7. 出典：Society5.0 －ともに創造する未来 一般社団法人 日本経済団体連合会 http://www.keidanren.or.jp/policy/2018/095.html Society 5.0
8. Society 5.0 1. 変化が激しい 2. 物事の予測が困難 3. 複雑かつ不確実な世の中
9. デジタル革新と多様な人々の想像・創造力の融合によって、 社会の課題を解決し、価値を創造する社会 Society 5.0 1. 変化が激しい 2. 物事の予測が困難 3. 複雑かつ不確実な世の中
10. ただ
11. 出典：なぜ、今アジャイルが必要か？ 独立行政法人 情報処理推進機構 IPA https://www.ipa.go.jp/files/000073019.pdf 従来のソフトウェア開発だとこれに追随できない
12. 出典：なぜ、今アジャイルが必要か？ 独立行政法人 情報処理推進機構 IPA https://www.ipa.go.jp/files/000073019.pdf ので、こうする必要がある
13. 出典：なぜ、今アジャイルが必要か？ 独立行政法人 情報処理推進機構 IPA https://www.ipa.go.jp/files/000073019.pdf ソフトウェアの価値も高め続ける必要がある
14. 今求められている開発
15. 1. 変化するビジネス要件に迅速に追従できる 2. 事業と開発が密にコミュニケーションをとり一体となる 今求められている開発
16. これらを解決するために生まれたのが
17. アジャイル開発
18. アジャイル開発って何？
19. アジャイル開発はどんなイメージか チャットに書き込んでみましょう！
20. 柔軟で効率的なシステム開発によって、迅速なシステム提供を目ざすというソフトウェア開発手法の総称。 アジャイルは英語で、「素早い・機敏な・（頭の回転が）速い」などの意味をもつ。 ソフトウェア開発の課題であった、開発期間の短縮化や低コスト化、柔軟で迅速な対応などを実現するための取り組みで、プログラマーなどの 開発サイドから提唱された手法である。 2001 年アメリカのスノーバードにソフトウェア開発手法の分野のエキスパートが集まり アジャイルソフトウェア開発宣言（アジャイル・マニフェスト） という文書がまとめられた。 さらに、組織としてアジャイル・アライアンス Agile Aliance が結成され、本格的な取り組みがスタートした。 途中経過の成果を早い段階から継続的に顧客に引き渡す ことで、開発途中での確認や仕様変更などに対応する。 また仕様書だけに頼るのではなく、顧客や開発チーム内でのコミュニケーションを重視することを原則としている。 アジャイル開発とは 参考：https://kotobank.jp/word/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB-348
21. アジャイル開発とは 柔軟で効率的なシステム開発によって、迅速なシステム提供を目ざすというソフトウェア開発手法の総称。 アジャイルは英語で、「素早い・機敏な・（頭の回転が）速い」などの意味をもつ。 ソフトウェア開発の課題であった、開発期間の短縮化や低コスト化、柔軟で迅速な対応などを実現するための取り組みで、プログラマーなどの 開発サイドから提唱された手法である。 2001 年アメリカのスノーバードにソフトウェア開発手法の分野のエキスパートが集まり アジャイルソフトウェア開発宣言（アジャイル・マニフェスト） という文書がまとめられた。 さらに、組織としてアジャイル・アライアンス Agile Aliance が結成され、本格的な取り組みがスタートした。 途中経過の成果を早い段階から継続的に顧客に引き渡す ことで、開発途中での確認や仕様変更などに対応する。 また仕様書だけに頼るのではなく、顧客や開発チーム内でのコミュニケーションを重視することを原則としている。 参考：https://kotobank.jp/word/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB-348
22. アジャイル開発とは アジャイルソフトウェア開発宣言 ↓に則って 途中経過の成果を早い段階から継続的に顧客に引き渡す
23. アジャイル開発とは アジャイルソフトウェア開発宣言 ↓に則って 途中経過の成果を早い段階から継続的に顧客に引き渡す
24. アジャイルソフトウェア開発宣言
25. アジャイルソフトウェア開発宣言
26. アジャイルソフトウェア開発宣言 完全に理解した
27. アジャイルソフトウェア開発宣言 やり方とか知らんが 関係者と話して、 ドキュメントを作らず実装 して、 計画せずに顧客要求を飲み続ける 開発手法ね！
28. アジャイルソフトウェア開発宣言 やり方とか知らんが 関係者と話して、 ドキュメントを作らず実装 して、 計画せずに顧客要求を飲み続ける 開発手法ね！
29. アジャイルソフトウェア開発宣言
30. アジャイルソフトウェア開発宣言
31. このことから
32. アジャイル ≠ 開発手法
33. アジャイル = 価値観
34. ❌：Do Agile. ⭕：Be Agile.
35. ❌：アジャイルをする ⭕：アジャイルになる
36. 以上
37. ウソです、続けます💦 すいません許してください!何でもしますから! ん？今なんでm
38. アジャイルソフトウェア開発宣言 もし Do の観点で具体的にするなら実態はこれくらいの認識がいいかも 要求から動くソフトウェアを作り リリースした成果物をレビューして 肉付けしながら完成形を目指す
39. 今日のゴール 1. なぜアジャイルなのかを知る a. 従来の開発手法だと世の中の変化についていけない 2. アジャイル開発と非アジャイル開発を知る 3. アジャイル開発のプロセスを 1 つ例にとって感じてみる
40. 今日のゴール 1. なぜアジャイルなのかを知る a. 従来の開発手法だと世の中の変化についていけない 2. アジャイル開発と非アジャイル開発を知る 3. アジャイル開発のプロセスを 1 つ例にとって感じてみる
41. アジャイル以外の開発
42. アジャイルの価値 個人と対話 動くソフトウェア 顧客との協調 変化への対応 非アジャイルとアジャイル（以下のように定義） 非アジャイルの価値 プロセスやツール 包括的なドキュメント 契約交渉 計画に従うこと
43. 非アジャイル開発の進め方
44. 非アジャイル開発の進め方 って何が思い浮かびますか？ チャットに書き込んでみよう！
45. アジャイルの価値 個人と対話 動くソフトウェア 顧客との協調 変化への対応 非アジャイルとアジャイル 非アジャイルの価値 プロセスやツール 包括的なドキュメント 契約交渉 計画に従うこと
46. 非アジャイルとアジャイル 非アジャイルの価値 プロセスやツール　　　　　 →　　不確定要素の排除、 WBS ガントチャート 包括的なドキュメント　　　 →　　認識相違をなくす 契約交渉　　　　　　　　　 →　　金銭・責任（他） 計画に従うこと　　　　　　 →　　期日までの確実な履行
47. 非アジャイル開発の進め方　例：ウォーターフォール 参考：https://it-trend.jp/process_management/article/464-0012
48. なぜアジャイルになりにくいのか？
49. 要求定義 要件定義 基本設計 詳細設計 実装 単体テスト 結合テスト 総合テスト 受入テスト リリース なぜアジャイルになりにくいのか？
50. 要求定義 要件定義 基本設計 詳細設計 実装 単体テスト 結合テスト 総合テスト 受入テスト リリース なぜアジャイルになりにくいのか？ ここで最終ゴールが決まる！
51. 登場人物 顧客 PM 開発者
52. なぜアジャイルになりにくいのか？ 早く移動したい！
53. なぜアジャイルになりにくいのか？ 早く移動したい！ 要求ヒアリング • 時速100km出る • 乗ってる人は安全に • 何らかのエネルギーで動く
54. なぜアジャイルになりにくいのか？ 要件定義 • 時速100km出る • 乗ってる人は安全に ◦ 箱に入れよ • 何らかのエネルギーで動く ◦ ガソリンにしよ
55. なぜアジャイルになりにくいのか？ 自動車作ろ！ • 時速100km出る • 乗ってる人は安全に ◦ 箱に入れよ • 何らかのエネルギーで動く ◦ ガソリンにしよ 要件定義
56. なぜアジャイルになりにくいのか？ 承認 要件定義提出 自動車 • 時速100km出る • 乗る人は箱に入れる • ガソリンで動く
57. なぜアジャイルになりにくいのか？ 承認 基本、詳細設計で承 認を得る —---- —---- —---- —---- —---- —---- —---- —---- —---- —---- —---- —---- □□□—---- □□□—---- □□□—----
58. なぜアジャイルになりにくいのか？ 承認 単体・結合・受け入れ テストで承n(ry —---- —---- —---- —---- —---- —---- —---- —---- —---- —---- —---- —---- —----□□□ —----□□□ —----□□□ —----□□□ —----□□□ —----□□□ —----□□□ —----□□□
59. なぜアジャイルになりにくいのか？ 開発中...
60. なぜアジャイルになりにくいのか？ 開発中...
61. なぜアジャイルになりにくいのか？ 開発中...
62. なぜアジャイルになりにくいのか？ 各種テスト中...
63. なぜアジャイルになりにくいのか？ 自動車
64. アジャイル開発の進め方
65. アジャイル 個人と対話 動くソフトウェア 顧客との協調 変化への対応 非アジャイルとアジャイル 非アジャイル プロセスやツール 包括的なドキュメント 契約交渉 計画に従うこと
66. アジャイルだとどうなる？ 早く移動したい！
67. アジャイルだとどうなる？ 早く移動したい！ とりあえず早く動けるやつ作ってみた！ 対話 成果物 提示
68. アジャイルだとどうなる？ 時速100kmは出した い 時速100km出せるようにした！
69. アジャイルだとどうなる？ 乗ってる人は安全に 箱に入れつつ最近流行ってる目前に物が現れた時 警告音出すやつ入れません？
70. 何らかのエネルギー で動く アジャイルだとどうなる？ 今は電気で動く車がいいらしい！ ガソリン＆電気で動けるようにしましょ！
71. 電気自動車 （アラート機能つき） アジャイルだとどうなる？
72. インクリメンタル開発の神話 “The Myth of Incremental Development” by Herding Cats under CC BY-NC-ND 3.0
73. おさらい
74. おさらい　- 非アジャイル開発の価値 早く移動したい！ 要求ヒアリング • 時速100km出る • 乗ってる人は安全に • 何らかのエネルギーで動く
75. おさらい　- 非アジャイル開発の価値 早く移動したい！ 自動車作ろ！ • 時速100km出る • 乗ってる人は安全に ◦ 箱に入れよ • 何らかのエネルギーで動く ◦ ガソリンにしよ 要件定義〜設計
76. おさらい　- 非アジャイル開発の価値 契約締結や開発者へ の負担を考慮すると 一回定めた要件を変 えたくない 予算・期日内に確実 に動くものが欲しい 一度決まったことを正確 に提出したい
77. アジャイルの価値 個人と対話 動くソフトウェア 顧客との協調 変化への対応 非アジャイルとアジャイル 非アジャイルの価値 プロセスやツール 包括的なドキュメント 契約交渉 計画に従うこと
78. おさらい　ーアジャイル開発の価値 乗ってる人は安全に 箱に入れつつ最近流行ってる目前に物が現れた時 警告音出すやつ入れません？
79. おさらい　ーアジャイル開発の価値 動いているモノを見る ことで、安心し、また 要求の解像度も上 がっていく 要求を受け入れるだ けでなく「対話」をする ことで、より価値のあ る成果物へつながる 細かく成果物を提示する ことで最終成果物の認 識相違が少なくなる 価値ある成果物につな がる
80. アジャイル 個人と対話 動くソフトウェア 顧客との協調 変化への対応 非アジャイルとアジャイル 非アジャイル プロセスやツール 包括的なドキュメント 契約交渉 計画に従うこと
81. ウォーターフォール is 悪？
82. ウォーターフォール is 悪？ ぶっちゃけ悪くはない
83. ウォーターフォール is 悪？ ぶっちゃけ悪くはない 創造性、想像性が不要で、 世の中の情勢に左右されない（不変的な）開発なら 多分特段問題にならない
84. ウォーターフォール is 悪？ ただ、 1 つリスクをあげるとするなら 仮に開発期間後半で仕様を変更しようとすると、 相当な調整とコストが必要となってしまう
85. ウォーターフォール is 悪？ 参考：https://it-trend.jp/process_management/article/464-0012
86. ウォーターフォール is 悪？ 仕様変更 問題発生 参考：https://it-trend.jp/process_management/article/464-0012
87. ウォーターフォール is 悪？ 影響範囲 甚大 参考：https://it-trend.jp/process_management/article/464-0012
88. 変化に対応しづらい ウォーターフォール is 悪？
89. デジタル革新と多様な人々の想像・創造力の融合によって、 社会の課題を解決し、価値を創造する社会 1. 変化が激しい 2. 物事の予測が困難 3. 複雑かつ不確実な世の中 変化に弱い、予測型開発 という点で、 Society 5.0な世の中には マッチしていない... ウォーターフォール is 悪？
90. 開発業務を体系的に把握するという点では非常に重要 ウォーターフォール is 悪？
91. 1. 開発プロセスの理解 a. 何をすれば成果物を世の中に出せるの ... ？ 2. 開発で考慮しなければならない事の理解 a. 非機能要件の定義 i. 可用性 1. SLA 【サービス品質保証 / Service Level Agreement / サービスレベル合意書】 a. バックアップ b. 冗長化 ii. 性能・拡張性 1. ネットワーク速度 2. キャパシティプランニング iii. 保守性 1. 設計思想の定義 2. 問題発生時の役割分担、体制、訓練、マニュアル整備 3. MTTR （平均修理時間） /MTTF （平均故障時間） iv. etc… ウォーターフォール is 悪？
92. アジャイル開発でドキュメント化をしなかったとしても 「意識」はするし、エンジニアなら知っている前提という 「責任」もある ウォーターフォール is 悪？
93. アジャイル/非アジャイルまとめ
94. • 大規模かつ関係者が多い ◦ ウォーターフォールだと作業内容・工程が綿密に決められているため、誰が開発に携わっても迷わず進め ることができる ◦ またこの進め方についても説明は最小限ですむ ◦ 工程別でリソース調整もやりやすい ▪ 例：要件定義・設計フェーズには上流エンジニア2名、実装フェーズに下流エンジニア10名を採用す ればスケジュール通りに進められそう • 仕様に変更が加わりにくい ◦ 世の中の情勢に左右されにくいシステムである ▪ 例：在庫管理システム等 • 明確な予算、期日が定まっている ◦ ドキュメント、ツール等で不確実性を見える化し排除できる ▪ 例：EVM、コンティンジェンシー予備、WBSガントチャート他 ウォーターフォール開発が選択されるパターン
95. • 小規模かつ関係者が少ない ◦ アジャイルだと良くも悪くも関係者の作業範囲が定まっておらず、また進め方もプロジェクトによってさまざ ま ◦ 大規模であったり関係者が多いとこの進め方の認識があわず不和が生じる ▪ これの解決に大規模アジャイル手法もあるがここでは割愛 • 仕様が固まりきっていない（固まっていても変更のリスクがある） ◦ 世の中の情勢に左右されるシステムである（レッドオーシャン） • 価値 ＞ 予算、期日（品質） ◦ 顧客価値が高いと判断されればQCDを差し置いてでも、それを実現したい！となれば アジャイル開発が選択されるパターン
96. 今日のゴール 1. なぜアジャイルなのかを知る a. 従来の開発手法だと世の中の変化についていけない 2. アジャイル開発と非アジャイル開発を知る a. 非アジャイル（になりやすい）開発例：ウォーターフォール b. アジャイルだと「対話」することで仕様も柔軟に変更がきく 3. アジャイル開発のプロセスを 1 つ例にとって感じてみる
97. 今日のゴール 1. なぜアジャイルなのかを知る a. 従来の開発手法だと世の中の変化についていけない 2. アジャイル開発と非アジャイル開発を知る a. 非アジャイル（になりやすい）開発例：ウォーターフォール b. アジャイルだと「対話」することで仕様も柔軟に変更がきく 3. アジャイル開発のプロセスを 1 つ例にとって感じてみる
98. アジャイル開発の進め方
99. アジャイル開発手法って何がある？ チャットに書き込んでみましょう！
100. • スクラム（Scrum） ◦ プロジェクト管理に重点を置いたアジャイル開発のフレームワーク ◦ 素早いリリース、新たな要求への対応、技術や変化へ適応するために、チーム力の最大化 に全力を注ぐ • XP（eXtreme Programing、エクストリームプログラミング） ◦ ソフトウェアの品質を改善し、顧客の要望の変化に適応する能力を高める ◦ 短期間での頻繁なソフトウェアリリース ◦ 開発を効率化し要求変更コストを抑える 12（19）プラクティス ▪ ペアプログラミング、テスト駆動開発など ... • ユーザー機能駆動開発（ FDD） ◦ ユーザーにとっての価値を重視して開発 ◦ ユーザーが利用する機能やビジネスモデルに合わせて必要な機能から設計・開発 代表的なアジャイル開発手法
101. • スクラム（Scrum） ◦ プロジェクト管理に重点を置いたアジャイル開発のフレームワーク ◦ 素早いリリース、新たな要求への対応、技術や変化へ適応するために、チーム力の最大化 に全力を注ぐ • XP（eXtreme Programing、エクストリームプログラミング） ◦ ソフトウェアの品質を改善し、顧客の要望の変化に適応する能力を高める ◦ 短期間での頻繁なソフトウェアリリース ◦ 開発を効率化し要求変更コストを抑える 12（19）プラクティス ▪ ペアプログラミング、テスト駆動開発など ... • ユーザー機能駆動開発（ FDD） ◦ ユーザーにとっての価値を重視して開発 ◦ ユーザーが利用する機能やビジネスモデルに合わせて必要な機能から設計・開発 代表的なアジャイル開発手法
102. スクラム開発の進め方
103. スクラムって何
104. ほとんどはじめてのスクラム開発の内容 是非後で見て下さい
105. スクラムとは、アジャイル開発手法の 1つであり、ユーザーに価値のあるプロダクトを素早く生み出すた めの軽量なフレームワークです。 1990年初頭にKen Schwaber(ケン シュエイバー)とJeff Sutherland(ジェフ サザーランド)により生み出されまし た。また、スクラム開発におけるチームメンバーの役割、イベント、作成物などのルールは「スクラムガイ ド」で定義されています。 参考：スクラムガイド スクラムとは
106. スクラムは以下2つの考え方に基づいて作成されています。 ・経験主義 　理論よりも経験を重視し、その経験を基に物事を判断する。 ・リーン思考 　ムダを省き、本質に集中する。 当初計画に固執することなく、日々の状況変化に柔軟に対応し、ユーザーにとって本当に価値のあるプ ロダクトを提供するための開発手法です。 スクラムとは
107. スクラム開発の3・5・3
108. ・プロダクトバックログ 　プロダクトの開発や改善に必要なタスクが優先度順に並べられた一覧。 ・スプリントバックログ 　スプリントで実施するプロダクトバックログの項目を実行可能なタスクに詳細化したもの。 ・インクリメント 　プロダクトゴールへ向けた具体的な成果物のこと。 3つの成果物
109. 3つの成果物 - インクリメント
110. 5つのイベント
111. 5つのイベント
112. 5つのイベント
113. 5つのイベント
114. 5つのイベント
115. 5つのイベント
116. 3つの役割
117. 3つの役割 ・プロダクトオーナー（PO） 　プロダクトの価値を最大化することに責任を持つ。 　プロダクトバックログの管理（優先順位づけ）を行う ・スクラムマスター（SM） 　スクラムの考え方とノウハウを全員に理解してもらうことに責任を持つ。 　チームが自己組織化されるようトレーニング、コーチングする。 ・開発者 　プロダクトに関するあらゆる側面（品質、計画、専門性）に責任を持つ。 スクラムチームは上記メンバーで構成されますが、プロダクトに対するレビューやフィードバックをもらうためステーク ホルダーとも密に関わります。（顧客、エンドユーザー、関連部署の人など）
118. 3つの役割
119. これらを行う上で意識すること
120. スクラムの三本柱と五つの価値基準
121. 透明性 プロセスや作業は、作業を実行する人とその作業結果を受け取る人に見える必要があります。 透明性によって検査が可能となるため、透明性が欠けた状態での検査は、誤解を招き、ムダなものに なります。 スクラムの三本柱と五つの価値基準
122. 検査 スクラムの作成物と合意されたゴールに向けた進捗状況は、頻繁かつ熱心に検査される必要がありま す。 検査によって適応が可能となります。スクラムイベントは、変化を起こすように設計されているため、適 応のない検査は意味がないとされます。 スクラムの三本柱と五つの価値基準
123. 適応 プロダクト開発のためのプロセスが上手くいかなかったり、成果物であるプロダクトが受け入れなれな かった場合は、現在適用しているプロセスやプロダクト開発のための構成要素を調整する必要がありま す。 スクラムチームは検査によって新しいことを学んだ瞬間にその学習した内容を適応することが期待され ています。 スクラムの三本柱と五つの価値基準
124. スクラムの三本柱
125. 確約 スクラムチームはゴールを達成し、お互いにサポートすることを確約します。 スクラムの三本柱と五つの価値基準
126. 集中 スクラムチームはゴールへ向けて進捗できるように、スプリントの作業に集中します。 スクラムの三本柱と五つの価値基準
127. 公開 スクラムチームとステークホルダーは作業や課題を公開します。 スクラムの三本柱と五つの価値基準
128. ✨ 尊敬 スクラムチームのメンバーはお互いに能力のある独立した個人であると尊敬します。 スクラムの三本柱と五つの価値基準
129. 勇気 スクラムチームのメンバーは正しいことをする勇気や困難な問題に取り組む勇気を持ちます。 スクラムの三本柱と五つの価値基準
130. スクラムの三本柱と五つの価値基準 🏁👀🔓✨ これらの価値基準がスクラムチームや一緒に働く人たちによって具現化されると き、スクラムの三本柱「透明性」「検査」「適応」に息が吹き込まれ、信頼が構築さ れます。
131. スクラムの五つの価値基準
132. スクラムのまとめ
133. スクラムの三本柱と五つの価値基準 1. スクラムはユーザーに価値を素早く提供するためのフレームワークである。 2. スクラムチームは「プロダクトオーナー」「スクラムマスター」「開発者」の 3つの役割で構成される。 3. スプリントで「スプリントレビュー」「デイリースクラム」「リファインメント」「スプリントレビュー」「レトロ スペクティブ」の5つのイベントを実施する。 4. 「プロダクトバックログ」「スプリントバックログ」「インクリメント」はスクラムで必要な成果物である。 5. スクラム実施時は、「三本柱」と「五つの価値基準」を常に意識する。
134. 今日のゴール 1. なぜアジャイルなのかを知る a. 従来の開発手法だと世の中の変化についていけない 2. アジャイル開発と非アジャイル開発を知る a. 非アジャイル（になりやすい）開発例：ウォーターフォール b. アジャイルだと「対話」することで仕様も柔軟に変更がきく 3. アジャイル開発のプロセスを 1 つ例にとって感じてみる a. スクラム開を例にあげて説明
135. 今日のゴール 1. なぜアジャイルなのかを知る a. 従来の開発手法だと世の中の変化についていけない 2. アジャイル開発と非アジャイル開発を知る a. 非アジャイル（になりやすい）開発例：ウォーターフォール b. アジャイルだと「対話」することで仕様も柔軟に変更がきく 3. アジャイル開発のプロセスを 1 つ例にとって感じてみる a. スクラム開を例にあげて説明
136. 後付け
137. • スクラムは奥が深い ◦ スクラムガイドにもこんな感じに書いてある ▪ スクラムとは、以下のようなものである。 • 軽量 ▪ 理解が容易 ▪ 習得は困難 • 興味があれば #tech-scrum へ ◦ スクラムに限らずアジャイルについても語っています スクラムについて
138. • アジャイル開発を元にスクラム開発が生まれた ◦ 各種適応型、漸進的開発手法をまとめてアジャイルが生まれた • ウォーターフォールではなかったので アジャイルです！ ◦ 蓋を開いてみたら ▪ 細かいウォーターフォール ▪ 行き当たりばったりなプロセス ◦ 上流工程が面倒だからやらないウォーターフォール開発 • フェーズを切って細かくリリースしていたので アジャイルです！ ◦ 明確なゴールが決まった状態で部品をリリースしていくだけではアジャイルとは言い難い よくいるエンジニアある間違い
139. 胸に手を当てて考えてみましょう（投げやり） 弊社はアジャイル開発しているのか？
140. 参考 • スクラムガイド • なぜ今アジャイルが必要か？ • はじめてのスクラム開発 • ウォーターフォールモデルとは？メリット、アジャイルとの違いを解説
141. おしまい