「アジャイル開発とスクラム」入門

Slide 1

Slide 1 text

Slide 2

Slide 2 text

2 ©AR Advanced Technology All Right Reserved. はじめに：この機会が生まれた背景  アクセルを踏むタイミングの見極め • マーケットの成熟状況 • 現有戦力との相性  いよいよ機が熟したという判断（遅すぎた？） • 足元では実際のスクラム案件増加 • 技術部隊の組織的成長 • 採用状況を踏まえ、ARIの付加価値向上と魅力付け急務  先行事例から挑戦することに • 一部部門へのスクラムマスター研修参加への打診 • 自身でドッグフーディングとしてその研修に先行参加（4/19～23）自身の勉強不足への反省と共に、「ARIにとってメリットがあるのでは？」という予感が強い仮説に変わった

Slide 3

Slide 3 text

3 ©AR Advanced Technology All Right Reserved. 新しいことへの向き合い方：まず良く知ることから始める  まずは「アジャイル開発」の本質、利点と課題を深く知ろう。  「アジャイル開発」か「ウォーターフォール」の二元論的比較や、ある単一のプラクティスを元にした拡大解釈による総論批評は避けたい。  多くの人が共感しているこの新しい価値観を ARIとしてどうすれば最も効果的に活用できるのか？より多くの人と共に、実践を通じ学び、考えていきたい。

Slide 4

Slide 4 text

4 ©AR Advanced Technology All Right Reserved. 参考書籍  スクラム概論 | Fintan https://fintan.jp/?p=949  平鍋健児・野中郁次郎・及部敬雄（2021）アジャイル開発とスクラム第2版顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント株式会社翔泳社  本資料は以下2つの資料と書籍から大幅に引用させていただいています。

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

7 ©AR Advanced Technology All Right Reserved. アジャイル開発が世界で注目を浴びた場面 Agile2007でのSalesforce.com の事例発表 https://www.slideshare.net/sgreene/salesforcecom-agile-transformation-agile-2007-conference 年4回のリリースが年1回に • 最初の見積が不正確で、完成期限が守れず、テスト期間が短縮されてしまう • 開発全体の進捗が不透明で、現状が正確につかめない • 機能に対する修正や変更のフィードバックが、開発の最後になって届く • スケジュールが遅延し、リリース日の予測が困難にアジャイル開発にシフト • 年4回のリリースへ • 技術的負債の返済 • リリース期日の遵守 • 社内アンケートで 87%が「自己組織化されている」 80%が「新しい手法がチームの生産性を上げた」

Slide 8

Slide 8 text

8 ©AR Advanced Technology All Right Reserved. アジャイルとは？ Agile – 【形】機敏な、敏捷な名詞ではなく、形容詞。状態を表す。 Don’t do agile, be agile ❞ ❝ アジャイル開発を行うのが目的ではなく、アジャイルな状態にすることが重要。その核となる考え方や原則がまとめられたものに、”アジャイルソフトウェア開発宣言”と “アジャイル宣言の背後にある原則”がある。

Slide 9

Slide 9 text

9 ©AR Advanced Technology All Right Reserved. 2001年、当時軽量ソフトウェア開発手法と呼ばれていた分野において著名な 17名が集まり、それぞれが重視していた部分を統合し、文書にまとめたもの。日本で特に知られているのは、以下の6名。 • Kent Beck (XPの考案者、JUnitの生みの親) • Martin Fowler (PoEAAの著者。マイクロサービスという言葉の生みの親) • Dave Thomas (達人プログラマーなどの著者。ボブおじさん) • Robert C. Martin (Clean Code, Clean Coderなどの著者) • Ken Schwaber (スクラムの生みの親) • Jeff Sutherland (スクラムの生みの親) アジャイルソフトウェア開発宣言

Slide 10

Slide 10 text

10 ©AR Advanced Technology All Right Reserved. アジャイルソフトウェア開発宣言 http://agilemanifesto.org/iso/ja/manifesto.html 私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている。この活動を通して、私たちは以下の価値に至った。プロセスやツールよりも個人と対話を、包括的なドキュメントよりも動くソフトウェアを、契約交渉よりも顧客との協調を、計画に従うことよりも変化への対応を、価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。 © 2001, 上記の著者たちこの宣言は、この注意書きも含めた形で全文を含めることを条件に自由にコピーしてよい。 Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas

Slide 11

Slide 11 text

11 ©AR Advanced Technology All Right Reserved. 私たちは以下の原則に従う: 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。 http://agilemanifesto.org/iso/ja/principles.html アジャイル宣言の背後にある原則

Slide 12

Slide 12 text

12 ©AR Advanced Technology All Right Reserved. アジャイル宣言の背後にある原則(続き) 動くソフトウェアこそが進捗の最も重要な尺度です。アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。シンプルさ（ムダなく作れる量を最大限にすること）が本質です。最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。 http://agilemanifesto.org/iso/ja/principles.html

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

15 ©AR Advanced Technology All Right Reserved. 出典: Scaling Software Agility プロセスウォーターフォールアジャイル成功の測定計画通りに実行出来たか。 QCDによる測定。変化への対応。顧客満足。競争力向上。マネジメント指揮命令型トップダウンサーバントリーダーシップフラット計画範囲固定で工数を見積る。期日固定で範囲を見積もる。要求と設計最初に要求を洗い出す。要求のすべてを設計する。継続的に要求を受け入れる。必要なタイミングで設計を行う。実装全機能を同時に開発。優先順位の高い機能から開発。テストと品質保証終盤に実施。早期から継続的にテストを実施。アジャイルとウォーターフォールのプロセスの違い

Slide 16

Slide 16 text

16 ©AR Advanced Technology All Right Reserved. イテレーティブとインクリメンタルイテレーティブ開発は最初から価値を作る。シンプルで最低限の機能しかないが、はじめから利用者の価値を実現するのがイテレーティブ開発。毎回のイテレーションで性能や操作性を高めて洗練させていく。インクリメンタル開発では完成するまで価値がない。中間成果物において価値が認められない作り方がインクリメンタル開発。＝反復する、繰り返す＝増加の、増分の、徐々に増加する、漸増のアジャイル開発がイテレーティブかつインクリメンタルな開発であるのは、イテレーション毎に既存機能を磨いていくだけでなく、新たな機能追加も行うからに他ならない。引用元：イテレーティブ開発とインクリメンタル開発の違い – プロダクト・マネジメントの要諦 The Rules of the Game of Product Management

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

19 ©AR Advanced Technology All Right Reserved. ここまでのまとめ  アジャイル開発では、期間を短く区切って優先度の高い機能から実装することを繰り返すことで、最後にならないと動くものが見えないリスクを軽減するとともに、ユーザーや顧客のフィードバックを取り入れながら開発する。  アジャイル開発は単なる手順やプロセスではなく、「アジャイル宣言」に述べられている価値観に根ざしている。  アジャイル開発、という手法が存在するわけではない。アジャイル宣言に示された価値観を持つ開発手法は複数あり、その1つがスクラムである。

Slide 20

Slide 20 text

Slide 21

Slide 21 text

21 ©AR Advanced Technology All Right Reserved. 出せば売れる時代は”どれだけ投資してどれだけ作れるか”というシンプルな構造だった。少々の欠陥があっても売れるので問題なかった。何が売れるか分からない、不確実なマーケット。 “どれだけ投資してもどれだけのリターンが得られるか” 分からない。ビジネスモデルの賞味期限が短くなってきている。価格競争付加価値競争予測可能予測困難マーケットの激しい変化に対応していかなければならない企業を取り巻く環境の変化

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

24 ©AR Advanced Technology All Right Reserved. 従来手法の課題：典型的なウォーターフォールの特徴 1. 最初に、綿密な計画が作成される。計画では、最終製品が注意深く検討・設計され、そして詳細に文書化される。 2. 計画を実施するために必要な作業が決定され、作業は「ガントチャート」や「マイクロソフトプロジェクト」のようなツールを使って作られる。見積は、展開された詳細見積の積算となる。 3. ステークホルダーが計画を詳細にレビュー・承認した後で、チームが開発に着手する。 4. チームメンバーは各自が担当工程を受け持ち、作業が完了すると次の工程の担当者に成果物を手渡す。 5. 開発が完了すると、製品は一旦品質保証を担当する組織に納品される。そこで最終顧客への納品前にテストを行う。ここでは、最初の計画・設計通りに作られていることを保証するために、全工程を通じて計画からの「ずれ」で管理される。引用：平鍋健児;野中郁次郎;及部敬雄.アジャイル開発とスクラム第2版顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

Slide 25

Slide 25 text

25 ©AR Advanced Technology All Right Reserved. 従来手法の課題：典型的なウォーターフォールの特徴このアプローチには、利点と欠点がある。利点は、非常に論理的である、ということだ。作る前に十分検討し、文書化し、計画に従い、すべてをできるだけ体系的に管理しようとする。しかし唯一の欠点は、このプロセスに「人間」が関与していることだ。このために、多くの問題が起こる。引用：平鍋健児;野中郁次郎;及部敬雄.アジャイル開発とスクラム第2版顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

Slide 26

Slide 26 text

26 ©AR Advanced Technology All Right Reserved. 従来手法の課題：人間が関与することによる問題  人の創造性を奪ってしまう • 途中でより良いやり方が見つかっても採用できない  文書によるコミュニケーションには限界がある • 文書は頭の中で考えたことの不完全なコピー • 詳細に書いた文書ほど、なかなか読まれない  悪いタイミング • 重要なひらめきほど、変更が難しい最終段階で起こる  未来を読む水晶玉はない • 競合や市場の動き、人生の変動は予期できない  仕事が楽しくない • 厳密な工程は、仕事を渡す側と受け取る側に敵対関係を生み出す傾向がある  部分最適化 • 変更を阻むプロセスからは、平凡なプロダクトしか生まれない

Slide 27

Slide 27 text

27 ©AR Advanced Technology All Right Reserved. ここまでのまとめ  アジャイル開発が浸透してきた背景には、ビジネスの変化の速さがある。  アジャイル開発では、ビジネスとITがゴールを共有する。  すばやくフィードバックを得ることで、無駄な機能を作ることを防ぎ、市場投入のスピードを上げ、ビジネスの投資対効果を高める  ソフトウェア開発は人間が行う仕事であるという現実に向き合った上で、その課題を解決したいという意図もある。

Slide 28

Slide 28 text

Slide 29

Slide 29 text

29 ©AR Advanced Technology All Right Reserved. 1990年代前半に件シュエーバーとジェフ・サザーランドによって開発されたアジャイル開発において用いられる代表的なフレームワークの1つ  軽量  理解が容易  習得は困難特徴 3つの責任、5つのイベント、3つの成果物が定義（ちなみにPMBOK V6には49個のプロセスが存在する）スクラムは経験主義。実際の経験と既知に基づく判断によって習得していく。 https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf スクラムの正式なルールについては、以下のスクラムガイドを参照すること 2010年に初版が作成され、現時点では2020年11月が最新版になっているスクラムの定義

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

34 ©AR Advanced Technology All Right Reserved. • 開発チームの作業とプロダクトの価値の最大化に責任を持つ • リリース日、リリース内容を決める • プロダクトバックログの管理に責任を持つ1人の人間（複数人はだめ） • プロダクトバックログの優先順位の決定(委員会があっても構わないが、決定はPOの責任) • 開発チームへの作業依頼(PO以外が開発チームに作業依頼をしてはいけない) • 作業結果の受入・拒否 • プロダクトバックログアイテム(PBI)を明確に表現する • ゴールとミッションを達成できるようにPBIを並べ替える • 開発チームが行う作業の価値を最適化する • PBIを全員に見える化・透明化・明確化し、スクラムチームが次に行う作業を示す • 必要とされるレベルでPBIを開発チームに理解してもらう • コスト感覚 • ネゴシエーション力 • 説明力 • 決断力求められる能力 • 一貫性 • 戦略性役割仕事プロダクトオーナー（PO）

Slide 35

Slide 35 text

35 ©AR Advanced Technology All Right Reserved. 開発者 • リリース可能なモノを作成する • 職能横断的に様々なスキルをもった人が製品を中心に集まり、強みを持ちより、垣根を越えて貢献し合うべく、自律性的に行動する • 自分たちの作業の管理(1番良いやり方を自分たちで考え、決める) • バックログに入っている項目を完了状態にし、製品の価値を高めていく責任 • 生産性を向上するために努力する責任 • 製品を開発するために必要な能力ビジネスアナリスト、プログラマー、Architect、デザイナーなど明示的な区別なし • 自律性 • チームへの貢献姿勢求められる能力役割 • スプリントプランニングで約束したことを実現する • 生産性向上のための行動を常に考え、行う仕事

Slide 36

Slide 36 text

36 ©AR Advanced Technology All Right Reserved. • スクラムの理解と成立に責任を持つ • プロダクトオーナーの支援 • 開発チームの支援 • スクラムの説明を行い、理解してもらう • 効果的なプロダクトバックログの管理方法の検討 • (必要に応じて) イベントのファシリテート • 開発チームの進捗を阻害する要因の排除 • サーバントリーダーシップ • ティーチング力 • ファシリテーション力 • コーチング力求められる能力役割仕事 • スクラム以外のプロセスの理解 • 集団心理の理解 • 事実(数字)を示すスクラムマスター

Slide 37

Slide 37 text

37 ©AR Advanced Technology All Right Reserved. スクラムを支える3本柱透明性 (Transparency) 結果責任を持つ人に対して見える化されていること。標準化され、見ている人が共通理解を持てること。検査 (Inspect) 作成物や進捗を頻繁に検査し、変化を検知する。検査を頻繁にやりすぎて作業の妨げになってはいけない。適応 (Adapt) プロセスに不備がある場合、その構成要素を調整する。プロセスの調整を出来る限り早く行い、逸脱を防ぐ。経験的プロセス制御の実現は以下の3つによって支えられている。スクラムのイベント、作成物、ロールには必ず何れかが当てはまる。

Slide 38

Slide 38 text

38 ©AR Advanced Technology All Right Reserved. 確約 (Commitment) 個人はスクラムチームのゴールの達成を確約しなければいけない。無理をして絶対に終わらせるということではない。勇気 (Courage) スクラムチームのメンバーは、正しいことをする勇気を持ち、困難な問題に取り組まなければいけない。集中 (Focus) スクラムチーム全員がスプリントの作業とゴールに集中しなければいけない。公開 (Openness) スクラムチームとステークホルダーは、仕事や課題と、その遂行の様子を公開することに合意しなければいけない。尊敬 (Respect) スクラムチームのメンバーは、お互いを能力のある独立した個人として尊敬しなければいけない。 5つの価値基準を取り入れ、実践することで透明性・検査・適応が実現可能となる。スクラムを支える5つの価値基準

Slide 39

Slide 39 text

Slide 40

Slide 40 text

40 ©AR Advanced Technology All Right Reserved. ここまでのまとめ  スクラムは、アジャイル開発の１手法である。  スクラムは、予見的プロセスではなく経験的プロセスであり、実際にやってみた結果を見ながらチームを適応させていく。  スクラムは、３つの「責任」、５つの「イベント」、３つの「作成物」で定義された、マネジメントの枠組みである。  スクラムチームの責任は、「プロダクトオーナー」「開発者」「スクラムマスター」の３つで構成されている。  スクラムマスターは、トップダウンの管理的マネジメントをするのではなく、スクラムチーム全体を支援し、チームと組織にスクラムが確立されることに責任を持つ。  スクラムでは、スプリントごとに機能する製品を開発し、その製品とプロセスの両方について「検査と適応」を繰り返す。

Slide 41

Slide 41 text

Slide 42

Slide 42 text

42 ©AR Advanced Technology All Right Reserved. アジャイルの実践に向けて説明したこと以外でもアジャイルを実践する際は「チーム」と「システム」両面で様々なツールや手法を組み合わせて運用を継続的に最適化してくことが大切経験主義の原則に則り、各チームに合うものを各自のやり方を模索する引用：平鍋健児;野中郁次郎;及部敬雄.アジャイル開発とスクラム第2版顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

Slide 43

Slide 43 text

43 ©AR Advanced Technology All Right Reserved. スクラムの実践において陥りやすい3つの罠  スクラムが形式的、儀式的になる • スクラムガイドはあくまでもルールブックでしかない • プレイブック（実際の運用戦略）は各チーム自身で考える  プロダクトオーナー vs 開発チームの構図に陥いる • 最新版では「開発チーム」という言葉をなくした意図 • 3つの役割に分けているのは、仕事に線をひくためではない • 計画と実行を分けないことがアジャイルの基本思想 • 「あなた vs 私」ではなく、「問題 vs 私たち」へ  スクラムマスターがスクラム警察もしくは雑用係に陥る • スクラムを回すことが仕事になってしまう • より高次の組織的目標にコミットするような動機づけと導き • スクラムマスター同士の社内コミュニティで経験や学びを共有これはスクラムに限った話ではない。今すぐ現場に活かせる考え方。引用：平鍋健児;野中郁次郎;及部敬雄.アジャイル開発とスクラム第2版顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

Slide 44

Slide 44 text

44 ©AR Advanced Technology All Right Reserved. SIにおけるアジャイル実践時の契約引用：» アジャイル開発版「情報システム・モデル取引・契約書」～ユーザ／ベンダ間の緊密な協働によるシステム開発で、DXを推進～：IPA 独立行政法人情報処理推進機構 https://www.ipa.go.jp/ikc/reports/20200331_1.html 2020年3月にIPAよりモデル契約書が提供されている。  スクラムをベース  準委任契約を前提  POはユーザー企業から選出引用：平鍋健児;野中郁次郎;及部敬雄.アジャイル開発とスクラム第2版顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

Slide 45

Slide 45 text

45 ©AR Advanced Technology All Right Reserved. ここまでのまとめ  スクラムで成果を上げるためには、スクラムガイドで定義されていること以外に様々な手法やツールを駆使することが効果的。  文化や組織風土、契約書面など多方面な整備が必要となる  スクラムを効果的に実践するためには、スクラムチームを含む組織全体が「コマンド─コントロール」型から「リーダーシップ─コラボレーション」型の自律した組織に変わる必要がある。