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

© 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

View Slide

Yuki Yoshida(吉⽥祐樹)
Sr. AppDev Consultant@Professional Services
Amazon Web Service Japan G.K.
好きなテキストエディタ︓
vi, Vim, NeoVim
好きなAWSサービス︓
AWS Amplify AWS AppSync Amazon
CodeCatalyst

View Slide

セッション対象者とゴール
想定聴講者
• アジャイルとは何かを知りたい⽅
• アジャイルなのにアジリティが上がらないと感じている⽅
• 「うちの開発者の⽣産性が低い」と感じているPOの⽅
• 「⽣産性が低い」とPOに⾔われた開発者の⽅
ゴール
• アジャイルとは何なのかを知る
• アジャイルとウォーターフォールは⽐較するものではないことを知る
• アジャイルな働き⽅を改善するポイントを整理する
• 「⽣産性」とは何かを考えるきっかけを作る

View Slide

早速ですが質問です

View Slide

1. 先にあまり要件を決めずに⼩さい部分から作り始める
2. 各アジャイル開発⼿法の定義に則って開発をしている
3. 短い期間で要件定義、設計、開発を繰り返す（≒ミニWF）
4. 上記すべて
アジャイル開発という名前の開発⼿法の定義を説明したもので
正しいのは以下の何番でしょう︖

View Slide

「アジャイル開発」という名前の
開発⼿法は（厳密には）存在しない
解︓5番

View Slide

ではアジャイルとは︖

View Slide

アジャイルソフトウェア開発宣⾔
私たちは、ソフトウェア開発の実践あるいは実践を⼿助けをする活動を通じて、
よりよい開発⽅法を⾒つけだそうとしている。この活動を通して、私たちは以下の価値に⾄った。
- プロセスやツールよりも個⼈と対話を、
- 包括的なドキュメントよりも動くソフトウェアを、
- 契約交渉よりも顧客との協調を、
- 計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。
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, 上記の著者たちこの宣⾔は、この注意書きも含めた形で全⽂を含めることを条件に⾃由にコピーしてよい。

View Slide

つまりアジャイルとは状態を指す
アジャイルになるための補助輪と
してスクラムやXPがある
ドキュメントを重視
動くソフトウェアを重視
計画に従う変化に柔軟に対応する
Not Agile
Agile
※実際は多次元ですが簡易的に2次元で書いてます

View Slide

アジャイルな状態になるのは時間がかかる
成
果
時間
お互いをよく知り、
チームが抱える
課題を共有する
Forming
形成期
Storming
混乱期
Performing
機能期
お互いを尊重しつつ
本⾳で考えを語り合い
意⾒が衝突する
新たな範囲や役⽬を
明確にし、⽬標達成に
向けてコミットする
⾃律的な対話を通じて
問題を解決しメンバー
の成⻑を促す
※タックマンモデル
進め⽅や状況次第で、どれだけ時間をかけても機能期に到達せず散会期を迎えることもある
Norming
統⼀期
アジャイルになるには最低でも数ヶ⽉かかる
Adjourming
散会期
⽬標達成状況や時間
的な制約などの理由
によりチームが解散

View Slide

アジャイルを始めても
すぐにアジリティは上がらない
つまり
ということ

View Slide

設計
開発
テスト
振り返り
要件定義
リリース
設計
開発
テスト
振り返り
要件定義
リリース
設計
開発
テスト
振り返り
要件定義
リリース
設計
開発
テスト
振り返り
要件定義
リリース
設計
開発
テスト
振り返り
要件定義
リリース
設計
開発
テスト
振り返り
要件定義
リリース
設計
開発
テスト
振り返り
要件定義
リリース
設計
開発
テスト
振り返り
要件定義
リリース
設計
開発
テスト
振り返り
要件定義
リリース
設計
開発
テスト
振り返り
要件定義
リリース
設計
開発
テスト
振り返り
要件定義
リリース
設計
開発
テスト
振り返り
要件定義
リリース
MVP開発本番リリースし、同⼀チームで開発しながら運⽤もする
企画
要件定義
開発リリース
テスト
（バグ修正）
運⽤開始
企画
要件定義
設計
開発
テスト
振り返り
設計
開発
テスト
振り返り
設計
開発
テスト
振り返り
リリース
テスト
（バグ修正）
設計
開発
テスト
振り返り
運⽤開始
終わりがない
短期間のアジャイル体験から「アジャイルは遅い」と結論をつけてしまう
本
来
の
ア
ジ
(
イ
ル
現
実
の
ア
ジ
(
イ
ル
従
来
型

View Slide

アジャイルを始めても
すぐにアジリティは上がらない
【再掲】

View Slide

企画
要件定義
設計
開発
テスト
振り返り
設計
開発
テスト
振り返り
設計
開発
テスト
振り返り
③ ②
リリース
テスト
（バグ修正）
設計
開発
テスト
振り返り
この⼯程を完全に無くすのは
難しいが短縮する余地はある
運⽤開始
①
現
実
の
ア
ジ
(
イ
ル
理想のアジャイルに近づくために出来ること
1. 運⽤チームに引き継ぎ、開発者が運⽤しない
• 運⽤性に優れたソフトウェアは運⽤を無視した開発からは⽣まれない ※1
• ⾃分たちで作ったものを⾃分たちで運⽤しないと⻑期的には開発速度が落ちる
隣の芝⽣が⻘く⾒えるだけなのか、
本当に⽣産性が低いのか︖
2. スコープとリリース⽇が先に決まり変更不可
• アジャイルではスコープは変動するつもりで事前に社内調整する必要がある
• 開発して再⾒積もりを継続的に⾏うことで予定の⾒える化を⾏う
3. POと開発者で期待値が揃っておらず「うちのチームは⽣産性が低い」などPOから不満が出る
※1 https://speakerdeck.com/toricls/you-build-it-you-run-it?slide=19

View Slide

開発⽣産性はどうやって測る︖
• 書いたソースコードの⾏数で測る
• 1000⾏で書いたAさん vs 10⾏で書いたBさん
• 同じことが実装出来たのならBさんの⽅が⽣産性が⾼そう
• コードを削除して、業務プロセスの変更等で問題解決したCさんは︖
• 1⾏で解決したけど書いた本⼈にしか理解出来ないコードを書いたXさんは︖
ソースの⾏数では⽣産性を測れない
• スクラムではストーリーポイント（バックログの⾒積もり）で測る
• 各バックログの規模にポイントをつけることで成果を測る
• 過去と今を⽐較することで、チームの⽣産性が向上したのかを知れる
ストーリーポイントは他チームとの⽐較が出来ない

View Slide

代⽤特性
https://fukabori.fm/episode/71

View Slide

開発⽣産性の代⽤特性候補案
※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つの指標 === 開発⽣産性と断⾔できるわけではないので使い⽅に注意が必要

View Slide

5つの指標補⾜
1. 開発⽣産性を上げるためには技術的な卓越性以上に組織⽂化の変⾰が必要
• 優秀な開発者が仕組みを整えてもデプロイの承認まで1⽇以上かかる、など
• 組織的な根回しや開発チームへの信頼が必要になる
2. 開発者向け補⾜
• 「⽣産性」の定義をチームで認識合わせするきっかけ作りに利⽤する
• 5つの指標を⾼めることに合意が取れればリファクタリングする理由が説明できるようになる
• コードの可読性が上がることでミス減少や障害発⽣時の原因特定が容易になる
• 疎結合アーキテクチャになることでデプロイ単位が⼩さくなり、デプロイ頻度が向上する
3. 5つの指標全てが⾼パフォーマンスになって初めて組織パフォーマンスに好影響
• スループット、安定性だけでは組織に良い影響を与えられない
4. 5つの指標には、設計から開発完了までの速度などの話が直接含まれてはいない
• 5つの指標を⾼パフォーマンスにすれば様々なことが⾃動化されるため、設計や開発に費やす
ための時間が増え、結果として速くなる
5. 以前のレポートでは運⽤の指標がなく4つの指標としてFour Keysと呼ばれていた

View Slide

まとめ
• アジャイルは状態
• 機能するチームを作るためのもの
• X⽉Y⽇までに開発完了、などを守るために⾏うものではない
• ウォーターフォールと⽐較するものではない
• 「アジャイルは遅い」と思ったら（⾔われたら）
• 始めは遅い、時間がかかるもの、と理解する
• 混乱期から逃げずに⽴ち向かった先に「機能するチーム」や「完成
に近づいたプロダクト」が待っている（かもしれない）
• ⽣産性を向上するためには組織⽂化の変⾰、技術的なスキルが必要
• 5つの指標は参考情報までに
• 開発⽣産性の指標は今後も市場を追っていく必要がある

View Slide

Thank you!
Yuki Yoshida
Amazon Web Services Japan
Sr. AppDevConsultant Professional Services

View Slide

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

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

yuukiyo

More Decks by yuukiyo

Other Decks in Technology

Featured

Transcript