Slide 1
Slide 1 text
アジャイルを学ぼう
2019-06-01 インフラ勉強会 @nainaistar(きり丸)
Slide 2
Slide 2 text
アジェンダ
自己紹介及び資料の説明 5分
アジャイルのゴール 3分
アジャイルがなぜ生まれたか 15分
アジャイルとは 5分
アジャイルの幻想 5分
アジャイルとウォーターフォールの違い 27分
Slide 3
Slide 3 text
自己紹介
HN：きり丸
ツイッター名：@nainaistar
経歴
二次受けSIer ウォーターフォール5年弱経験
社内SE アジャイル(スクラム)4カ月経験
資格
Slide 4
Slide 4 text
当資料の対象人物
・アジャイルを知らない人
・アジャイルを知っているが、ウォーターフォールを知らない人
・アジャイルを再勉強したい人
当資料の非対象人物
・アジャイルを熟知している人
Slide 5
Slide 5 text
当資料でわかること
・アジャイルの理解
・アジャイルとウォーターフォールの違い
当資料でわからないこと
・具体的なアジャイルのフレームワーク実践方法
(次の登壇テーマはスクラムにしようと考えています。
)
Slide 6
Slide 6 text
アジャイルのゴール
Slide 7
Slide 7 text
アジャイルのゴール
価値のあるものを迅速に、
定期的にお客様に届けて、
お客様の満足度を高める。
Slide 8
Slide 8 text
アジャイルがなぜ生まれたか
Slide 9
Slide 9 text
なぜアジャイルが生まれたか
プロジェクトで炎上した経験はありませんか。
もし炎上した経験があれば、轍を踏まないように、
ルールを追加するでしょう。
しかし、失敗の数だけ追加したいルールはあり、
理論上いくらでも膨らんでいきます。
そして、ルールが重くなることによって、
利益を得るまでのリードタイムが長くなったり、
そもそもルールが多すぎることによって別の失敗が発生してしまう可能性があります。
Slide 10
Slide 10 text
なぜアジャイルが生まれたか
そのような中で、90年代ごろから開発者たちが
古いアイデアと新しいアイデアを組み合わせ始めました。
様々な組み合わせが出来上がる中で、
開発チームとビジネスの利害関係者間の密接な協力関係 、ビジネス価値の頻繁な提供 、自
己組織的なチーム、コードの作成、レビュー、リリース方法が大事であることがわかりました。
様々な組み合わせがフレームワークとなり、
スクラム、エクストリームプログラミング (XP)、機能駆動型開発（FDD）、
動的システム開発方式（ DSDM）などが登場し始めました。
Slide 11
Slide 11 text
なぜアジャイルが生まれたか
そして、2001年。
とある17人が集まり、
フレームワークを使ったさまざまなアプローチの共通点を話し合って、
合意した結果、アジャイルソフトウェア開発宣言が生まれました。
Slide 12
Slide 12 text
No content
Slide 13
Slide 13 text
なぜアジャイルが生まれたか
アジャイルソフトウェア開発宣言が行った
2つの主なことは、
アジャイルソフトウェア開発の基礎を形成する価値ステートメントを提供すること、
アジャイルソフトウェア開発という用語自体を結び付けることでした。
https://agilemanifesto.org/iso/ja/manifesto.html
Slide 14
Slide 14 text
なぜアジャイルが生まれたか
その後の数か月の間に、
アジャイル宣言の背後にある
12の原則を用いてアジャイル宣言のアイデアを拡張しました。
https://agilemanifesto.org/iso/ja/principles.html
※アジャイルの歴史とは関係ないですが、
川口 恭伸（カワグチ ヤスノブ）様の資料が
12の原則を反転させていて面白かったので、
一読しておくと皆様の役に立てると思います。
https://speakerdeck.com/kawaguti/what-is-agile
Slide 15
Slide 15 text
アジャイルとは
Slide 16
Slide 16 text
アジャイルとは
迅速かつ適応的にソフトウェア開発を行う
軽量な開発手法群の総称。
逆に、「重量ソフトウェア開発手法
」とは、
ウォーターフォール開発を選んだ時に起こりがちな手法。
(軽量な開発手法群 = アジャイル
重量な開発手法群 ≠ ウォーターフォール)
Slide 17
Slide 17 text
アジャイルのフレームワーク
・スクラム
・エクストリームプログラミング
(XP)
・機能駆動型開発（FDD）
・動的システム開発方式（
DSDM）
・リーン
人にフォーカスしたフレームワーク
(スクラム等)、
プロダクトにフォーカスしたフレームワーク
(Lean等)の大きく2パターンに分けられます。
どれか一つだけを採用する。というわけではない。
Pivotal Lab、Yahoo Japanでは、「Lean XP」を採用している。
Slide 18
Slide 18 text
アジャイルの幻想
Slide 19
Slide 19 text
おことわり
当スライド以降、アジャイルそのものではなく、
スクラムの話が混ざります。
基本的な概念は、変わらないと思いますが、
実践するフレームワークによっては、
異なるかもしれない点があることをご了承ください。
また、グラフも出てきますが、
Spreadシートでの
グラフ作成方法がよくわからず、雰囲気だけを伝えるようにしているため、
数値や桁数がおかしいことになっています。
その旨もご了承ください、または正しい値を知っていれば、コメントください。
Slide 20
Slide 20 text
アジャイルの幻想
アジャイルで開発すると、
生産性とか倍だし、開発期間も短くなるんでしょ？
Slide 21
Slide 21 text
アジャイルの幻想
ウォーターフォールだろうが、
アジャイルだろうが、
最終的に作る人が同じため、生産性は変わりません。
開発期間は短くなる傾向はありますが、
劇的な変化が見込めるわけではありません。
Slide 22
Slide 22 text
ウォーターフォールと比較して
Slide 23
Slide 23 text
そもそもウォーターフォールの
メリットってなんだっけ？
Slide 24
Slide 24 text
ウォーターフォールは作業工程ごとに分割する。
分割した工程を一工程ずつ終わらせる計画を立て進捗管理をする。
原則として前工程が完了しないと次工程に進まない事で、
前工程の成果物の品質を確保し、前工程への
後戻りを最小限にする。
ウォーターフォールの利点は、工程の
進捗管理がしやすい。
そもそもウォーターフォールの
メリットってなんだっけ？
Slide 25
Slide 25 text
ただし、前提が前工程が完璧であること。
後戻りしない前提なので、
後戻りした場合のスケジュール遅延を組み込むことができません。
そもそもウォーターフォールの
メリットってなんだっけ？
Slide 26
Slide 26 text
一個流しとロット流し
(一個ずつやるか、
まとめてやるか)
Slide 27
Slide 27 text
実は、ウォーターフォールのキーワード「 一工程ずつ終わらせる」という処理は、
効率がよさそうに見えて、効率が悪いです。
1つずつ終わらせた方が、作業が早く終わります。
アジャイルでは、1個ずつ終わらせます。
同時に仕掛かる機能を減らして、 迅速に出荷することが大事です。
参考動画
https://www.youtube.com/watch?v=uc7N3aPTCkY
一個流しとロット流し
(1個ずつやるか、まとめてやるか)
Slide 28
Slide 28 text
スケジュールの立て方の違い
Slide 29
Slide 29 text
ウォーターフォールでは、
マスタースケジュール(プロジェクト全体のスケジュール
)を立て、
更に各工程ごとの詳細のスケジュールを作成します。
アジャイルでは、1スプリントや2スプリントの直近1-4週間しかスケジュールを立てません。
リリースできる概算日を出すことはあるでしょうが、
基本的に全体スケジュールの概念はありません。
スケジュールの立て方の違い
Slide 30
Slide 30 text
見積もり時間のぶれやすさ
Slide 31
Slide 31 text
時間見積もりの違い
Slide 32
Slide 32 text
見積もった時間に対して、
実際の時間はどうなりがちか
以下の作業が、見積もりに対して実際はどうなりがちか考えてみましょう。
・単純作業(デプロイ作業等)
・知的作業(設計、コーディング等)
Slide 33
Slide 33 text
単純作業の時間分布
(5分で終わる見積もりしたとき)
Slide 34
Slide 34 text
単純作業の時間分布
(5分で終わる見積もりしたとき)
Slide 35
Slide 35 text
知的作業の時間分布
(5分で終わる見積もりしたとき)
Slide 36
Slide 36 text
知的作業の時間分布
(5分で終わる見積もりしたとき)
ABP HP
2倍の時間かけて
も、終わってないこ
ともある
Slide 37
Slide 37 text
知的作業の時間分布
(5分で終わる見積もりしたとき)
ABP HP
Slide 38
Slide 38 text
パーキンソンの法則
第1法則
仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する
Slide 39
Slide 39 text
振り返りの頻度の違い
Slide 40
Slide 40 text
開発期間が短くなる理由
スクラムでは、1-2週間で振り返り(レトロスペクティブ)を行います。
ウォーターフォールでは、工程ごとの
1-2カ月、またはリリース後に振り返ります。
定期的な振り返りの場があることで、
不満があったら次の機会で吐き出そうとするため、
効果的な振り返りができやすくなります。
Slide 41
Slide 41 text
作るものが決まっている
プロジェクトでは比較できない点
Slide 42
Slide 42 text
必要なものを必要なだけ作る
Slide 43
Slide 43 text
No content
Slide 44
Slide 44 text
No content
Slide 45
Slide 45 text
要望に優先度をつけて少しずつ
価値のあるものを作っていく。
作ったものからフィードバックを得て、
本当に顧客が欲しかった要望を引き出す。
作る根拠のないものは、作らない。
必要なものを必要なだけ作る
Slide 46
Slide 46 text
ウォーターフォールは計画主義
アジャイルは適応的開発
Slide 47
Slide 47 text
No content
Slide 48
Slide 48 text
ウォーターフォールでは、計画に従うことを重要視しています。
アジャイルでは、変化への対応を重要視しています。
ウォーターフォールでは、追加タスクを嫌います。
最初に想定していたタスク以外を実施しない、ということは、
ビジネスの観点(Buisiness Domein)のみでしかタスクを作成することができず、
プロダクトの観点(Solution Domain)からタスクを作成できません。
ウォーターフォールは計画主義(完璧主義)
アジャイルは適応的開発
Slide 49
Slide 49 text
つまり、ビジネス側からの要請が無い限り、
ウォーターフォールでは、プロダクトの改善をする機会を得づらいです。
プロダクトの改善をする機会が無いということは、
エンハンス開発で増えた機能、バグ修正等でプロダクトは
複雑になって可読性がどんどん悪くなっていきます。
(技術的負債の増加)
アジャイルでは、プロダクトの改善する時間を取るようにしています。
ウォーターフォールは計画主義(完璧主義)
アジャイルは適応的開発
Slide 50
Slide 50 text
ウォーターフォールでは、リリースするたびに難易度が上がります。
アジャイルでは、リリースを繰り返しても、難易度が上がらないようにして、
定期的にリリースできるようにします。
ウォーターフォールは計画主義(完璧主義)
アジャイルは適応的開発
Slide 51
Slide 51 text
まとめ
Slide 52
Slide 52 text
アジャイルのゴール
価値のあるものを迅速に、
定期的にお客様に届けて、
お客様の満足度を高める。
Slide 53
Slide 53 text
参考資料及び
使用しなかったスライド
Slide 54
Slide 54 text
参考資料
・Agile Alliance
https://www.agilealliance.org/
・5分で分かるアジャイルムーブメントの歴史 拡大版
https://www.slideshare.net/fkino/brief-history-of-agile-movement
・アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技
https://www.amazon.co.jp/dp/4797347783
Slide 55
Slide 55 text
参考資料
・マイクロソフト牛尾様のブログ
http://simplearchitect.hatenablog.com/entry/2017/10/16/081633
・最初の機能が少なくて乏しいほど、最後の品質が高くなる。
https://sloanreview.mit.edu/article/productdevelopment-practices-that-work-how-internet-companies-build-softw
are/
Slide 56
Slide 56 text
使用しなかったスライド
Slide 57
Slide 57 text
優先度
Slide 58
Slide 58 text
プロジェクト目標マネジメントのＱＣＤＳ（品質、
コスト、タイム、スコープ）
品質
ウォーターフォール アジャイル
コスト
タイム
(納期)
スコープ
低 高 低 高