アジャイル・スクラム 勉強会 なぜ今、アジャイルなのか？ Satoshi Harada

なぜ今、アジャイル？ ► アジャイルという言葉は1990年頃からあった ✔ エクストリーム・プログラミング（1996年） ✔ アジャイルソフトウェア開発宣言（2001年） ✔ スクラム（1986年） ► アジャイルが日本で流行りだしたのは2010年頃から ✔ アジャイルソフトウェア開発宣言が日本語訳された ✔ NTTコミュニケーションズやKDDIがスクラムを推進 ► なぜ今、アジャイル？ ✔ 要件がはっきりしているバックオフィス系の大規模開発案件が減少 ✔ 要件がはっきりしていないビジネス系の小規模開発案件が増加 最初に要件を決めることが難しい（仮説はあるが確証は無い） 小さく始めてできるだけ早く仮説を検証したい 高速でPDCAを回して繰り返し改善していきたい 最初に要件を確定して全モジュールの結合が済んでからリリースするウォー ターフォール開発では、ビジネスサイドが求める仮説検証のスピード感と マッチしなくなってきた。

アジャイルとスクラム ► 一般的に、アジャイルというと“アジャイルソフトウェア 開発宣言”のことを指すことが多い ✔ プロセスやツールよりも個人と対話を、 ✔ 包括的なドキュメントよりも動くソフトウェアを、 ✔ 契約交渉よりも顧客との協調を、 ✔ 計画に従うことよりも変化への対応を、 価値とする。左記のことがらに価値があることを認めながら も、右記のことがらにより価値をおく。 ► スクラムはアジャイルを実践するためのフレームワーク ► 上記で価値があるとした右記のことがらを実践しやすくす るための運用ルールが纏められている ► アジャイルのフレームワークはスクラム以外にもある ✔ かんばん ✔ リーン ✔ XP（エクストリーム・プログラミング）　など

ウォーターフォールの問題点 1. 顧客ですらゴール（本当に必要だったもの）を理解できていない 2. コードに落とし込まれる頃には見当違いなものになってしまってい る恐れ 3. 関係者が最初からゴール（顧客が本当に必要だったもの）を認識し て到達するのは至難の業 小さく始めて、顧客のフィードバックを得て軌道修正をしながらゴール （顧客が本当に必要だったもの）を目指す必要がある。 https://matome.naver.jp/odai/2133468389280396901/2133468437980408003 ① ② ③

WFの対義語がアジャイル？ ► ウォーターフォール開発だと上手くいかないからアジャイル開発で やりましょう。。。という話ではない。 ► アジャイルとは、迅速かつ変化に柔軟に対応できる開発手法郡の総称 である ► よって、“アジャイル開発”という名前の具体的な開発手法は存在しな い ► 日本で単に“アジャイル開発”と呼ぶ場合、ほとんどの場合は“スクラム”フ レームワークによる開発を指している ► アジャイルは右記のことがらに価値をおく開発である。よって、 ウォーターフォール開発であってもアジリティ（迅速かつ柔軟）を 意識して開発をすることは可能 ✔ プロセスやツールよりも個人と対話を ✔ 包括的なドキュメントよりも動くソフトウェアを ✔ 契約交渉よりも顧客との協調を ✔ 計画に従うことよりも変化への対応を ► ただ、フェーズ間の手戻りを良しとしないウォーターフォールは、 アジャイルの考え方と相性が良くない ✔ 古のスーパーPMはウォーターフォール開発の中でも無意識にアジャイ ルな行動を実践していたのかもしれない。。。

アジャイルのおすすめ図書 ► アジャイルサムライ ✔ アジャイル開発の教科書的な本 ✔ 言い回しや挿絵が面白いので読み飽 きない ✔ “スクラム”や“かんばん”のエッセン スも含めて総合的にアジャイルを説 明してくれている ► SCRUM BOOT CAMP ✔ スクラムについてマンガや読みやす い文章で説明してくれている ✔ この本を読んで概要を理解してから 正規のスクラムガイドを読むのがお すすめ ✔ 2020年5月20日に最新のスクラムガ イドに準拠した改訂版が出版される

雑談Time A) 皆さんの思う“アジャイル”と一致してい ましたか？ B) “アジャイル”が重視する以下のことがら についてどう思いましたか？ ✔ プロセスやツールよりも個人と対話を ✔ 包括的なドキュメントよりも動くソフトウェアを ✔ 契約交渉よりも顧客との協調を ✔ 計画に従うことよりも変化への対応を C) アジャイルを用いて、迅速かつ変化に柔 軟な開発をしようとした場合、障害にな りそうなことはありますか？