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