アジャイル開発は本当に必要なのか、何を解決するのか

AWS Dev Day 2023 Tokyoの登壇資料です。

Transcript

1. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. アジャイル開発は本当に必要なのか、 何を解決するのか Yuki Yoshida B - 4 - 1 Amazon Web Services Japan G.K. Sr. AppDevConsultant Professional Services
2. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. Yuki Yoshida(吉⽥ 祐樹) Sr. AppDev Consultant@Professional Services Amazon Web Service Japan G.K. 好きなテキストエディタ︓ vi, Vim, NeoVim 好きなAWSサービス︓ AWS Amplify AWS AppSync Amazon CodeCatalyst
3. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. セッション対象者とゴール 想定聴講者 • アジャイルとは何かを知りたい⽅ • アジャイルなのにアジリティが上がらないと感じている⽅ • 「うちの開発者の⽣産性が低い」と感じているPOの⽅ • 「⽣産性が低い」とPOに⾔われた開発者の⽅ ゴール • アジャイルとは何なのかを知る • アジャイルとウォーターフォールは⽐較するものではないことを知る • アジャイルな働き⽅を改善するポイントを整理する • 「⽣産性」とは何かを考えるきっかけを作る
4. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. 早速ですが質問です
5. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. 1. 先にあまり要件を決めずに⼩さい部分から作り始める 2. 各アジャイル開発⼿法の定義に則って開発をしている 3. 短い期間で要件定義、設計、開発を繰り返す（≒ミニWF） 4. 上記すべて アジャイル開発という名前の開発⼿法の定義を説明したもので 正しいのは以下の何番でしょう︖
6. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. 「アジャイル開発」という名前の 開発⼿法は（厳密には）存在しない 解︓5番
7. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. ではアジャイルとは︖
8. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. アジャイルソフトウェア開発宣⾔ 私たちは、ソフトウェア開発の実践あるいは実践を⼿助けをする活動を通じて、 よりよい開発⽅法を⾒つけだそうとしている。この活動を通して、私たちは以下の価値に⾄った。 - プロセスやツールよりも個⼈と対話を、 - 包括的なドキュメントよりも動くソフトウェアを、 - 契約交渉よりも顧客との協調を、 - 計画に従うことよりも変化への対応を、 価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。 Kent Beck Ron Jeffries Ken Schwaber Alistair Cockburn Brian Marick Arie van Bennekum James Grenning Ward Cunningham Jeff Sutherland Andrew Hunt Jim Highsmith Jon Kern Robert C. Martin Martin Fowler Mike Beedle Dave Thomas Steve Mellor © 2001, 上記の著者たち この宣⾔は、この注意書きも含めた形で全⽂を含めることを条件に⾃由にコピーしてよい。
9. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. つまりアジャイルとは状態を指す アジャイルになるための補助輪と してスクラムやXPがある ドキュメントを重視 動くソフトウェアを重視 計画に従う 変化に柔軟に対応する Not Agile Agile ※実際は多次元ですが簡易的に2次元で書いてます
10. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. アジャイルな状態になるのは時間がかかる 成 果 時間 お互いをよく知り、 チームが抱える 課題を共有する Forming 形成期 Storming 混乱期 Performing 機能期 お互いを尊重しつつ 本⾳で考えを語り合い 意⾒が衝突する 新たな範囲や役⽬を 明確にし、⽬標達成に 向けてコミットする ⾃律的な対話を通じて 問題を解決しメンバー の成⻑を促す ※タックマンモデル 進め⽅や状況次第で、どれだけ時間をかけても機能期に到達せず散会期を迎えることもある Norming 統⼀期 アジャイルになるには最低でも数ヶ⽉かかる Adjourming 散会期 ⽬標達成状況や時間 的な制約などの理由 によりチームが解散
11. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. アジャイルを始めても すぐにアジリティは上がらない つまり ということ
12. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. 設計 開発 テスト 振り返り 要件定義 リリース 設計 開発 テスト 振り返り 要件定義 リリース 設計 開発 テスト 振り返り 要件定義 リリース 設計 開発 テスト 振り返り 要件定義 リリース 設計 開発 テスト 振り返り 要件定義 リリース 設計 開発 テスト 振り返り 要件定義 リリース 設計 開発 テスト 振り返り 要件定義 リリース 設計 開発 テスト 振り返り 要件定義 リリース 設計 開発 テスト 振り返り 要件定義 リリース 設計 開発 テスト 振り返り 要件定義 リリース 設計 開発 テスト 振り返り 要件定義 リリース 設計 開発 テスト 振り返り 要件定義 リリース MVP開発 本番リリースし、同⼀チームで開発しながら運⽤もする 企画 要件定義 開発 リリース テスト （バグ修正） 運⽤開始 企画 要件定義 設計 開発 テスト 振り返り 設計 開発 テスト 振り返り 設計 開発 テスト 振り返り リリース テスト （バグ修正） 設計 開発 テスト 振り返り 運⽤開始 終わりがない 短期間のアジャイル体験から「アジャイルは遅い」と結論をつけてしまう 本 来 の ア ジ ( イ ル 現 実 の ア ジ ( イ ル 従 来 型
13. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. アジャイルを始めても すぐにアジリティは上がらない 【再掲】
14. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. 企画 要件定義 設計 開発 テスト 振り返り 設計 開発 テスト 振り返り 設計 開発 テスト 振り返り ③ ② リリース テスト （バグ修正） 設計 開発 テスト 振り返り この⼯程を完全に無くすのは 難しいが短縮する余地はある 運⽤開始 ① 現 実 の ア ジ ( イ ル 理想のアジャイルに近づくために出来ること 1. 運⽤チームに引き継ぎ、開発者が運⽤しない • 運⽤性に優れたソフトウェアは運⽤を無視した開発からは⽣まれない ※1 • ⾃分たちで作ったものを⾃分たちで運⽤しないと⻑期的には開発速度が落ちる 隣の芝⽣が⻘く⾒えるだけなのか、 本当に⽣産性が低いのか︖ 2. スコープとリリース⽇が先に決まり変更不可 • アジャイルではスコープは変動するつもりで事前に社内調整する必要がある • 開発して再⾒積もりを継続的に⾏うことで予定の⾒える化を⾏う 3. POと開発者で期待値が揃っておらず「うちのチームは⽣産性が低い」などPOから不満が出る ※1 https://speakerdeck.com/toricls/you-build-it-you-run-it?slide=19
15. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. 開発⽣産性はどうやって測る︖ • 書いたソースコードの⾏数で測る • 1000⾏で書いたAさん vs 10⾏で書いたBさん • 同じことが実装出来たのならBさんの⽅が⽣産性が⾼そう • コードを削除して、業務プロセスの変更等で問題解決したCさんは︖ • 1⾏で解決したけど書いた本⼈にしか理解出来ないコードを書いたXさんは︖ ソースの⾏数では⽣産性を測れない • スクラムではストーリーポイント（バックログの⾒積もり）で測る • 各バックログの規模にポイントをつけることで成果を測る • 過去と今を⽐較することで、チームの⽣産性が向上したのかを知れる ストーリーポイントは他チームとの⽐較が出来ない
16. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. 代⽤特性 https://fukabori.fm/episode/71
17. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. 開発⽣産性の代⽤特性候補案 ※1 ISBN-10 4295004901 https://www.amazon.co.jp/dp/4295004901 ※2 DevOps Research and Assessment ※3 https://cloud.google.com/devops/state-of-devops?hl=ja LeanとDevOpsの科学※1 や、DORA※２ が発表しているState of DevOps Report 2022※3 から抜粋 8年に渡り世界中から33,000⼈以 上を調査し組織のパフォーマンス について調査結果を報告している カテゴリ 指標 定義 ⾼パフォーマンス例 スループット 安定性 運⽤パフォーマンス デプロイの頻度 本番環境にデプロイする頻度 1⽇に複数回のデプロイ 変更のリードタイム コミットされたコードが本番環境で実⾏されるまでの時間 1⽇未満 サービス復旧時間 ユーザー影響がある障害発⽣時の復旧にかかる時間 1時間未満 変更時の障害率 本番環境を変更時のサービス障害が発⽣して対策が必要になった割合 0% – 15% 信頼性 可⽤性、レイテンシ、パフォーマンス、スケーラビリティ たいてい期待にかなう • ⾼パフォーマンスな技術部⾨は、組織のパフォーマンス（商品やサービスの量、作業効率、顧客満⾜度、 製品やサービスの質、組織の⽬標達成度）が他集団を上回る結果を得ている • 5つの指標で⾼パフォーマンスの場合、燃え尽き症候群減少などの効果があることも明らかになっている ※5つの指標 === 開発⽣産性と断⾔できるわけではないので使い⽅に注意が必要
18. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. 5つの指標補⾜ 1. 開発⽣産性を上げるためには技術的な卓越性以上に組織⽂化の変⾰が必要 • 優秀な開発者が仕組みを整えてもデプロイの承認まで1⽇以上かかる、など • 組織的な根回しや開発チームへの信頼が必要になる 2. 開発者向け補⾜ • 「⽣産性」の定義をチームで認識合わせするきっかけ作りに利⽤する • 5つの指標を⾼めることに合意が取れればリファクタリングする理由が説明できるようになる • コードの可読性が上がることでミス減少や障害発⽣時の原因特定が容易になる • 疎結合アーキテクチャになることでデプロイ単位が⼩さくなり、デプロイ頻度が向上する 3. 5つの指標全てが⾼パフォーマンスになって初めて組織パフォーマンスに好影響 • スループット、安定性だけでは組織に良い影響を与えられない 4. 5つの指標には、設計から開発完了までの速度などの話が直接含まれてはいない • 5つの指標を⾼パフォーマンスにすれば様々なことが⾃動化されるため、設計や開発に費やす ための時間が増え、結果として速くなる 5. 以前のレポートでは運⽤の指標がなく4つの指標としてFour Keysと呼ばれていた
19. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. まとめ • アジャイルは状態 • 機能するチームを作るためのもの • X⽉Y⽇までに開発完了、などを守るために⾏うものではない • ウォーターフォールと⽐較するものではない • 「アジャイルは遅い」と思ったら（⾔われたら） • 始めは遅い、時間がかかるもの、と理解する • 混乱期から逃げずに⽴ち向かった先に「機能するチーム」や「完成 に近づいたプロダクト」が待っている（かもしれない） • ⽣産性を向上するためには組織⽂化の変⾰、技術的なスキルが必要 • 5つの指標は参考情報までに • 開発⽣産性の指標は今後も市場を追っていく必要がある
20. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. Thank you! © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. Yuki Yoshida Amazon Web Services Japan Sr. AppDevConsultant Professional Services