アジャイル開発が上手くいく組織、上手くいかない組織• 2021.11.17

アジェンダ• 自己紹介• 会社紹介• アジャイル開発が上手くいかない組織• ケースごとの問題と対策• アジャイル開発が上手くいく組織• よりよいチームにするには• まとめ• サービス紹介2

• 会社説明3

4

5

アジャイル開発が上手くいく、上手くいかないとは＊スクラムマスターとしてのアジャイル開発(スクラム)を導入するゴール

変化に適応し、価値を最大化する
自己管理されたチーム• 毎スプリント動作可能なものをつくり切る• 使う人に実際触ってもらってフィードバックを得る• 変化を受け入れ、スプリント単位で方向修正化を可能にする6

アジャイル開発が上手くいかない組織＊スクラムマターとしてスクラムを導入しやすいか、むずかしいのかという観点の話で、そもそもの組織構造が良い悪いの話ではありません。

7

ケース1：
マルチベンダー

https://note.com/shift_tech/n/na404409a8bae

8ベンダーごとのチームにわけることの問題

クロスファンクショナルなチームではない• スプリントごとに動作可能な成果物をだすことがむずかしい。
• 最後に結合をするとリスクが最後に集中して危険。

• フィードバックを得て改善をする機会がない。

「全体で成果を出す」より• 全体最適よりも、部分最適が進む。

「責任範囲の仕事をする」• 責任範囲を超えての助け合いがしずらい。

9対策：ベンダー関係なく混合チームにする
ベンダーごとのチームわけではなく、混合チームにして、
クロスファンクショナルなチームにするスクラムでは個人の成果ではなくチームの成果に着目する

スクラムイベントを通して、チームとしての一体感が出てくる

動作可能な成果物をスプリントごとに作成をしてスプリントレビューを行いフィードバックがもらえるようになる
10

SHIFTではどうしているの？
✓ アジャイル開発を多く経験してきたSHIFTだからできる開発とQA活動
No

ここを
目指す

スプリントＮ

1

体系的なテストが行われていない
アジャイル開発

2

スプリント周回遅れ
テストパターン3
4

スプリントＮ+1

スプリントＮ+2

スプリントＮ+3

リリースサイクル

開発１

1

開発２
開発３
開発１

テスト１
開発２

テスト２
開発３

開発１
テスト専用
スプリントパターン

サイクル

テスト３

2

サイクル

テスト１

開発２

テスト２
開発３

テスト３

4

サイクル

開発１
ＱＡ１
開発とQAの並行
パターン

開発２
ＱＡ２

開発３
ＱＡ３

1

サイクル

従来のテストエンジニアのアジャイルQAとの違い

テストエンジニア

アジャイルQA（ウォータフォール開発において、テスト工程でテストする人）（アジャイル開発で開発チームの一員となりスプリント内でQAを行う人）

期間、規模

テスト工程期間内に終わらせ スプリント期間内に終わらせるる（大規模長期間）（小規模短期間）

アプローチ

多くの不具合を見つける

連携の仕方

開発者から成果物を受け取り、開発メンバーの一員として一緒にテストをする（分業）
高品質な開発ができるようにする

不具合を減らす（上流で防ぐ）

12

ケース2：
POが
外部の人

13

POの資質POは開発するサービス、製品のビジョンを語り、みんなを巻き込んで、それを実現する• 深いドメイン知識• 製品、サービスに対する情熱や愛情• 実現に必要な権限

14

POが外部の人だった場合の問題

御用聞き変化への対応よりも計画重視
決定権がない• 外部のからの要望を聞いて調整するだけになってしまう。

• 「変化を受け入れ、価値を高める」よりも「安全にスケ

ジュール通りにプロジェクトを終わらせる」になってしまう。

• 新規にやることや、優先順付け、スコープの変更に承認が必要になり、時間がかかる。

とはいえ、POができる人は忙しくてPO業務ができない…
15

対策：キーマンを見つけ、素早く連携できるようにしておく

キーマンを見つけ、連携する
ドメイン知識に詳しい人

情熱、愛情、ビジョンを語れる人
決定権がある人

16

アジャイル開発

ウォーターフォール開発

ケース３：
スコープと
スケジュールが固定されている

D（納期）

C（コスト）S（スコープ）
固定

Q（品質）
Q（品質）

可変
D（納期）

C（コスト）S（スコープ）

そもそもアジャイル開発する必要がないのでは…

17

スコープとスケジュールが固定されることの問題

過度な残業

人員の追加

禁じ手
テストの簡略化• 持続可能な働き方ではない、メンバーが疲弊する。
• 運用しながらの長期的な開発ができない。

• 急に人を増やしてもオーバーヘッドの方が大きい。

• 使い勝手が悪い、不具合がある。
• ユーザーとの信頼関係を失いサービス継続が困難に…。

18

対策：MVPを決める
確実にMVPは達成しいつでもリリースできる状態にするMVP（ Minimum Viable Product ）実用最小限の製品余力で優先度の高い機能を追加していく

19

その機能は本当に必要？
システムの機能の利用割合
いつも使
よく使う

う

16%

7%

まったく

たまに使

使わない

う

45%

13%

ほぼ使わ
ない

19%

64%
の機能は、
まったく使わないか、
ほとんど使わない。

PCやスマートフォンのプレインストール
ソフトウェアを考えると想像がつく
The Standish Group “Chaos” report 2002
20

どれも重要な機能なのはわかりました。
リリースするのに最小限の機能はどれですか？

アジャイル開発が上手くいく組織
21

チームを信頼し、権限が委譲されているスクラムを導入しはじめは、すぐに効果は出ない• マネージメント層はチームを信頼して効果が出てくるまで待つ。

本来スクラムが扱う領域• 問題に直面した時に素早く判断、決断ができる。

は、不確実なことが多い• 新しいアイデアにすくにチャレンジして経験を積み、学びを得る。

言われたものをつくるか
ら自分たちでつくるに• 主体的にプロジェクトに関わることになり、モチベーションアップ。

22

スクラムチームの成熟段階

オーバーコミット

コミットしたこ
とができる

価値への
フォーカス

• インプット＞アウトプット• インプット＝アウトプット• インプット＜アウトカム
23

アウトプット（どれだけ作業をしたか）ではなくアウトカム（どれだけ価値を
だせたか）
を意識する

もっとチームをよくするためにアウトプットではなくアウトカムを意識できるチームにするチームを信頼し、チームに権限が開発者を信頼し、開発者に権限が委譲されている

委譲されている24

スクラムでの基本的な役割分担
What(何を達成するか)
プロダクトバックログ

How(どう実現するか)スプリントバックログ

項目

タスク

25

開発者がWhatに関与する割合を増やす
開発初期
開発者：how

PO : why what(how)

スクラムの基本的な役割分担
PO : why what

開発者 : how

より成熟したチームへ
PO : why（方向性）

開発者 : what how

価値にフォーカスをし、より素早く実現できるようにする
26

バックログ項目がhowになっている。何をするか明確だが柔軟性がない。
what、howが分かれ、開発者が手段を選べる状態。

開発者も積極的にwhatに関与する状態。
どれだけ作業をしたかではなくどれだけ価値をだせたか。

まとめ：アジャイル開発（スクラム）を上手く導入するにはアジャイル開発（スクラム）はツールです• 導入する目的と使う手法の特性があっていますか？

アジャイル開発（スクラム）に合わせた考え方に変える• 個別最適 ＜全体最適• 計画重視 ＜価値の最大化（変化を受け入れる）• 管理統制 ＜ 自己管理

27

（全体として成果を出す）（信じて任せる）

SHIFT
アジャイル
サービスの
ご紹介

28

SHIFTアジャイルサービスの紹介✓ アジャイル開発への取り組みを行い、小規模から大規模のアジャイル開発を支援する

プロダクトオーナー支援
プロダクトオーナー補佐
プロダクトバックログをチームが開発できる状態に支援する。

アジャイルPMO支援
アジャイルPMO
スクラムとウォーターフォール
をつなぎ、メトリクスやチームの状況を可視化する。

スクラム推進支援
スクラムマスター
スクラムプロセスが円滑に進行するように、外部から支援する。
アジャイルコーチ
スクラムマスターを補佐し、課題の本質を見極め、解決を支援する。

アジャイルテスト支援
QAリード
スクラム内でQA活動が円滑に進行するように、リードする。
QAチーム
開発と協調しながらプロダクトをテストし、品質保証する。

質疑応答

31