アジャイル・スクラム勉強会の第1回資料

1. アジャイル・スクラム
勉強会
なぜ今、アジャイルなのか︖

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

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

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

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

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

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