2021年6月26日、#scrumosaka 金沢トラックにてお話した内容です。

1. © Copyright 2021, ESM, Inc.
成功と失敗に学ぶ
アジャイル受託開発の極意
Scrum Fest Osaka 2021 金沢トラック
2021年6月26日
1

2. © Copyright 2021, ESM, Inc.
こんにちは
2
岡島 幸男
取締役CTO／
Agile Studio ディレクター

3. © Copyright 2021, ESM, Inc.
永和システムマネジメント
3
福井本社
東京支社／神田
沖縄支社
● 金融、医療、組込み(自動車)
● Web/Cloud、アジャイル開発
● 社員 220名エンジニア集団

4. © Copyright 2021, ESM, Inc.
Agile Studio （福井の開発拠点）
4

5. © Copyright 2021, ESM, Inc.
リモート時代に対応し、 Agile Studio Fukui から Agile Studio に
5
アジャイルの知識を身につける
アジャイル研修
アジャイルチームをはじめてみる
アジャイルチーム立ち上げ
アジャイル内製チームを実現する
アジャイル共創
モダンエンジニアへの技術転換
アジャイル共育
フルリモートでのアジャイル内製化支援
リモートアジャイルBoot Camp
モダンエンジニアとアジャイルチームを組む
リモートアジャイル開発
経営層やマネジメント向けのセミナーを実施
組織の方向付け
マインドチェンジ
組織への横展開や定着を支援する
アジャイル推進・定着支援

6. © Copyright 2021, ESM, Inc.
本日語りたいこと
6
1. アジャイル受託開発を始める
○ 請負業者から開発パートナーへ
2. アジャイル受託開発を続ける
○ マクロ視点でマネジメントする
3. アジャイル受託開発に終わりはあるか
○ そして内製化支援へ
主に受注側の視点で、「アジャイル受託」は、請負業者から開発パートナー、そして内製化支援パート
ナーに変わっていく流れだと位置づけ、事例をふまえながら語ります

7. © Copyright 2021, ESM, Inc.
「アジャイル受託」の定義
7
● ソフトウェア会社による事業としての組織的取り組み
● 契約（一括請負｜準委任）はどちらでも
○ ただし派遣は除く
● Scrumなど特定のフレームワークに縛られるものではない
○ 一部プラクティスのみ、などハイブリッドも含む

8. © Copyright 2021, ESM, Inc.
アジャイル受託開発を始める
～ 請負業者からの脱却
8

9. © Copyright 2021, ESM, Inc.
よく言われるアジャイル受託の難しさ
9
● 一括請負の場合
○ 事前に全要件揃うわけないのにコミットメントが必要
○ 勘違い（安い・うまい・早い）的期待とのギャップ
○ アウトプット＞アウトカムな価値観に縛られがち

10. © Copyright 2021, ESM, Inc.
「アジャイル受託開発」に選ばれがちなプロジェクト
10
ウォーターフォール向き グレーゾーン アジャイル向き
比較的規模大きい
比較的ビジネスルール複雑
利害関係者多い
固定化されたスケジュール
SoEだとかDXと呼ばれる領域

11. © Copyright 2021, ESM, Inc.
事例で見てみよう
11
ウォーターフォール向き グレーゾーン アジャイル向き
SoEだとかDXと呼ばれる領域
事例A1：
大規模業務システム
事例B1：
大規模サービス
事例D1：
小規模業務システム
事例C1：
小規模サービス
全部請負契約です！

12. © Copyright 2021, ESM, Inc.
ふきつなにおい
12
事例A1 事例B1 事例C1 案件D1
契約 要件定義は準委任。開発は請負（段階的） 請負契約（段階的） 一括請負 一括請負
アジャイル導入のきっ
かけ
先方担当（その後
WFでやったほうがいいと当方よ
り逆提案）
先方責任者（＋こちらからの提案） 先方責任者および担当 こちらからの提案
PO お客さま（当方にも専任仕様ホルダー） お客さま（＋当方で
PO補佐） お客さま（週一話ができる） お客さま
SM なし 専任 なし なし
開発チーム規模 10人 10人 5人 3人
ステークホルダーの巻
き込み
POがやっていた。社内での立ち居振る舞いがうま
い
数が多くお客さま社内での合意形成が困難 お客様自社製品なので、
POが方向性を決められる 先方に社内をとりまとめてもらった
スプリントレビュー 定例的なイベントは無し。
できたものは常に触ってもらえるようにした
当方チーム内で実施 週一、お客様（
PO、部長、アーキテクト）とオンライ
ンで実施。できたものは常に触れる環境
週に一度デモ
要件の固さ 元々WF前提なのでかっちり決まっている 柔らかい。スコープリープ多発 柔らかい（要件定義をいきなりひっくり返す勢い。見
積もりの意味は・・）
柔らかだった（想定より大きく揺れた）
リリース頻度 6ヶ月（納品・検収後にファーストリリース） 1年目のβリリースが初 7か月目（納品・検収後にファーストリリース） 4か月目（納品・検収後にファーストリリース）
チーム安定性 高い 低い（入れ替わり多い） 低い（応援メンバー追加） 高い（固定メンバー）
チームスキル格差 高い 高い きわめて高い きわめて高い
チーム心理的安全性 低い 低い 低い 低い
勉強会 なし（PJスタート時に1日かけて説明） 週1時間 毎日30分（技術メイン） なし
顧客評価 高い（非常に高品質） ？ 高い（開発力高い） 低い（低品質）
当社自己評価 高い 低い 中 低い

13. © Copyright 2021, ESM, Inc.
おなじみのリスク回避法
13
「二段階契約」
1. 要件定義は準委任契約
○ アウトプットの一つとして規模（金額）を見積もる
2. 開発は請負契約

14. © Copyright 2021, ESM, Inc.
実際にはこんな感じ
14
※ 本物提案書より抜粋

15. © Copyright 2021, ESM, Inc.
二段階契約のポイント
15
● 要件（ストーリー）を固めるのは重要な目的だが、お互いのリスク
回避だけに終わらせない
● アジャイルの価値を味わい理解を深めてもらう
○ 小さく開発して見せるのがベター
○ 現実には開発が認められなくてもアジャイルの価値を伝える
方法は他にもある（例：研修を一緒に受ける）
アジャイルを知ってもらう努力は最初からしておく

16. © Copyright 2021, ESM, Inc.
必勝か？
16
● そもそも二段階契約にできない場合もある
● 不確定要素が残る場合もある
● それでも見積もりを外すこともある

17. © Copyright 2021, ESM, Inc.
二度と同じプロジェクトはない
17
より生産的になってはいないと、どうして言えるだろう? そう、これは扱いにくい問題なのだ。扱いにくい問題に違いなく、そうでなけれ
ば今頃はすっかり暴露されていたはずだ。しかしよく知られている様々な理由により、ソフトウェア開発の生産性の測定というのはき
わめて難しい。ソフトウェア開発に対して有効な科学実験みたいなことをするのは、さらに難しい。同じプロジェクトを同じチームで2回
行うことはできない。2回目のときには多くのことが変わってしまうからだ。2つのチームに同じプロジェクトをさせることもできない。あ
らゆる変数をコントロールするのはあまりに難しく、またそのような試みはどのような場合であれ高く付きすぎるからだ。同じチームが
2つの異なるプロジェクトを続けて行う場合というのも、やはり実験にはならない。
できることと言えば、たくさんのプロジェクトをやっているたくさんのチームについて統計的なデータを集め、類似性の同定を試み、あ
る種の回帰分析を行って、何らかの意味のある相関関係が見出されることを期待するくらいのものだ。しかしデータはどこから持って
くるのか? 企業は、仮にそのようなデータを持っていたとしても、内部データを提供しようとはしない。およそありそうにないことだ。彼
らはスケジュールの失敗を隠し、どこまでも楽観的に進み続ける。
「いいアジャイルと悪いアジャイル」より引用 （Steve Yegge / 青木靖 訳）赤字は岡島
http://www.aoky.net/articles/steve_yegge/good_agile_bad_agile.htm
一度プロジェクトが成功したとして、それでアジャイルになったといえる
か？

18. © Copyright 2021, ESM, Inc.
成功とは？失敗とは？
18
● 事例プロジェクトのB1、C1、D1は社内ではトータルで見たら失敗
という扱い
● 財務的な指標が期待を下回ることが主な理由
○ ※メンバーの成長など加点されるポイントもある
では、ウォーターフォールだったら成功していたのか？

19. © Copyright 2021, ESM, Inc.
成功とは？失敗とは？
19
● 事例プロジェクトA1は社内では成功とみなされている
顧客評価が高く儲かれば成功なのか？
チーム内は…（Agile Japan 2019発表資料より）

20. 20
受発注双方が心の底から、本質を理解、同意できるところを目指したい

21. © Copyright 2021, ESM, Inc.
お互いのアジャイル理解度を知ることが出発点
21
受注側の理解度
発注側の理解度
あ い
う え
低い 高い
低い
高い
あかんでしょ
いいかんけい
うそでしょ
えごいすと
（その顧客にとって）最初の
アジャイル受託開発はここ
からスタートすることが多
い

22. © Copyright 2021, ESM, Inc.
「アジャイルしたい！」というエゴを捨てることも大事
22
受注側の理解度
発注側の理解度
あ い
う え
低い 高い
低い
高い

23. © Copyright 2021, ESM, Inc.
「いいかんけい」に向けて
23
受注側の理解度
発注側の理解度
あ い
う え
低い 高い
低い
高い
何か困ったことが起きて
も、両者の協力と知恵で
なんとかなる（多分）。

24. © Copyright 2021, ESM, Inc.
アジャイル受託の目指すところと本質的な難しさ
24
発注側・受注側のパートナーシップの元でのアジャイルジャー
ニーであること

25. © Copyright 2021, ESM, Inc.
アジャイル受託開発を続ける
～事業として継続する
25

26. © Copyright 2021, ESM, Inc.
Agile Studioはアジャイル受託をどう捉えているか
ビジョン実現に向け、避けて通れないトランスフォーメーション

27. © Copyright 2021, ESM, Inc.
組織としてどういう形でゴールしたいのか？
27
● プロジェクトマネジメントからプロダクトマネジメントへ、という流れ
の中で
● 受託開発では、組織こそが「プロダクト」
● アジャイル受託開発は、組織ビジョン、戦略込みで考える必要性
プロジェクト（ミクロ）ではなく組織（マクロ）の視点も入れるでないとマ
ネジメントできない

28. © Copyright 2021, ESM, Inc.
（再掲）難しさの本質
28
発注側・受注側のパートナーシップの元でのアジャイルジャー
ニーであること
マネジメントとは「難しいことでもなんとかうまくやること」

29. © Copyright 2021, ESM, Inc.
アジャイルパートナーシップジャーニー
29
受注側のアジャイル度
発注側のアジャイル度
○
◎
低い より高い
低い
より高い

30. © Copyright 2021, ESM, Inc.
使い方
30
1. 発注側、受注側それぞれで、アジャイル度の目安となるステップ
を決める
2. ステップを超える条件（KPI）を壁として記入する
3. 今どのあたりにいるかポイントする
4. プロジェクトのマイルストンで状況を確認し、ゴールや次の目標点
を確認する
※ 自分たちのうまくいく型を見出すこと
現在地がポイントでき、ゴールが定められるならマクロ視点でのマネジ
メントができる

31. © Copyright 2021, ESM, Inc.
Agile Studio 標準モデル
31
受注側のアジャイル度
発注側のアジャイル度
◎
低い より高い
低い
より高い
Ready
Ready
Ready
Do
Ready
Be
Do
Ready
Do
Do
Do
Be
Be
Ready
Be
Do
Be
Be
１．発注側、受注側それぞれのアジャイ
ル度を「Ready Agile」「Do Agile」「Be
Agile」にステップ化して分ける
契約の壁
一人前の壁
①アジャイルの本質を理解いただい
た上で、準委任契約モデルを作成い
ただけたか
②メンバーのアジリティ向上
によに自己管理できるチー
ムになったか
２．ステップを超えるための条件や
KPIを
設定する
○
３．今どのあたりにいるかポイントする

32. © Copyright 2021, ESM, Inc.
事例A1のアジャイルパートナーシップジャーニー
32
受注側のアジャイル度
発注側のアジャイル度
◎
低い より高い
低い
より高い
Ready
Ready
Ready
Do
Ready
Be
Do
Ready
Do
Do
Do
Be
Be
Ready
Be
Do
Be
Be
契約の壁
一人前の壁
Step1 Step2 Step3 Step4 Step5
Step8
Step6
~7
準委任による合同
開発スタート！
お客様経験値のほ
うがむしろ高い状態
で開始。WFでやり
きった
チームが自己管理
されていると大半が
実感
お客様の理解（経
験値）もさらに深ま
る

33. 33
１
STEP
出会い
私たちの2年間
約３~６ヶ月スパンでサービスリリース
２
STEP
3
STEP
４
STEP STEP
５
モヤモヤ・・・？
チームは自己組織化モードへ
ふりかえり実施
ちょっとやり方を変えてみた
ー チームは学習モードへ
イベント見直し！
悩み・苦しみも …
完全ウォーターフォール
ー 品質・納期 ◎
ー 見える化 ◎
ー チームはサバイバルモード
6か月 9か月 6か月~
（Agile Japan 2019発表資料より）
事例A1

34. 34
１
STEP
出会い
私たちの2年間
約３~６ヶ月スパンでサービスリリース
２
STEP
3
STEP
４
STEP STEP
５
モヤモヤ・・・？
チームは自己組織化モードへ
ふりかえり実施
ちょっとやり方を変えてみた
ー チームは学習モードへ
イベント見直し！
悩み・苦しみも …
完全ウォーターフォール
ー 品質・納期 ◎
ー 見える化 ◎
ー チームはサバイバルモード
6か月 9か月 6か月~
Do Agile Be Agile
Ready Agile
（Agile Japan 2019発表資料より）
事例A1

35. © Copyright 2021, ESM, Inc.
「Ready」「Do」「Be」ステップ観点でふりかえる
35
● 重要だったのは「Ready Agile」ステップでの信頼貯金の積み重
ね
○ やりきること。ウォーターフォールでも構わない
○ 発注側にとっても重要なプロジェクトであること
● 「Do Agile」でもしんどいこと、もやもやはたくさんある
● 「Be Agile」に到達することで、あらゆる仕事をアジャイルマインド
で進められるように
○ 契約も現在は準委任に切り替わっている
いやウォーターフォール混じってるやん！！って思いましたか？

36. © Copyright 2021, ESM, Inc.
どちらを選びますか？
36
● きっちりとScrumのフレームワークを回しているがうまくいかない
● 「あんなものはアジャイルでない」とディスられながらうまくいく
マクロ視点でゴールを定めることで明確に答えらえるようになる

37. © Copyright 2021, ESM, Inc.
事例C1の場合
37
事例A1 事例B1 事例C1 案件D1
契約 要件定義は準委任。開発は請負（段階的） 請負契約（段階的） 一括請負 一括請負
アジャイル導入のきっ
かけ
先方担当（その後
WFでやったほうがいいと当方よ
り逆提案）
先方責任者（＋こちらからの提案） 先方責任者および担当 こちらからの提案
PO お客さま（当方にも専任仕様ホルダー） お客さま（＋当方で
PO補佐） お客さま（週一話ができる） お客さま
SM なし 専任 なし なし
開発チーム規模 10人 10人 5人 3人
ステークホルダーの巻
き込み
POがやっていた。社内での立ち居振る舞いがうま
い
数が多くお客さま社内での合意形成が困難 お客様自社製品なので、
POが方向性を決められる 先方に社内をとりまとめてもらった
スプリントレビュー 定例的なイベントは無し。
できたものは常に触ってもらえるようにした
当方チーム内で実施 週一、お客様（
PO、部長、アーキテクト）とオンライ
ンで実施。できたものは常に触れる環境
週に一度デモ
要件の固さ 元々WF前提なのでかっちり決まっている 柔らかい。スコープリープ多発 柔らかい（要件定義をいきなりひっくり返す勢い。見
積もりの意味は・・）
柔らかだった（想定より大きく揺れた）
リリース頻度 6ヶ月（納品・検収後にファーストリリース） 1年目のβリリースが初 7か月目（納品・検収後にファーストリリース） 4か月目（納品・検収後にファーストリリース）
チーム安定性 高い 低い（入れ替わり多い） 低い（応援メンバー追加） 高い（固定メンバー）
チームスキル格差 高い 高い きわめて高い きわめて高い
チーム心理的安全性 低い 低い 低い 低い
勉強会 なし（PJスタート時に1日かけて説明） 週1時間 毎日30分（技術メイン） なし
顧客評価 高い（非常に高品質） ？ 高い（開発力高い） 低い（低品質）
当社自己評価 高い 低い 中 低い

38. © Copyright 2021, ESM, Inc.
紆余曲折
38
受注側のアジャイル度
発注側のアジャイル度
◎
低い より高い
低い
より高い
Ready
Ready
Ready
Do
Ready
Be
Do
Ready
Do
Do
Do
Be
Be
Ready
Be
Do
Be
Be
契約の壁
一人前の壁
S
S
フェーズ3では突
破！
現体制でBe Agile
になれることが目標
スクラム熟練メン
バー追加
M
E
フェーズ1
フェーズ2
フェーズ3

39. © Copyright 2021, ESM, Inc.
失敗から成功へ
39
● ミクロで見ると失敗のフェーズもあった
○ テコ入れメンバー追加により収支は悪化
○ ただし、メンバー追加によりチーム状況は改善。顧客評価もと
ても高く終わることができた
● マクロでの評価軸を追加すると
○ 顧客から期待は高く長いパートナーシップとなる可能性
○ チームは「Be Agile」に向けジャーニーを進めている
マクロ視点を持つことで、テコ入れに対する評価軸を追加できる
「炎上プロジェクトを終わらす」、以上の価値があった

40. © Copyright 2021, ESM, Inc.
プロジェクトを積み上げても事業にはならない
40
ミクロも大切だけど、マクロな視点が事業継続には大切
8月 9月 10月
Aプロジェクト 4.0人月 4.0人月 5.0人月(+1.0)
Bプロジェクト 3.0人月 3.0人月 2.0人月(-1.0)
合計 7.0人月 7.0人月 7.0人月
1.0人月分
ヘルプ
● A,Bいずれのプロジェクトの顧客およびメンバーも納得
● どちらのプロジェクトも一括契約のため人の移動は顧客にとっては影響なし
● Aプロジェクトの収支は悪化するものの、トータルでは辻褄はあう
「なのでこのヘルプ増員は妥当だ」 ⇒ ほんとに？

41. © Copyright 2021, ESM, Inc.
アジャイル受託開発に終わりはあるか
41

42. © Copyright 2021, ESM, Inc.
開発パートナー（準委任）モデルでのアジャイル受託開発
42
＝事業価値
×
契約
金額
人数
一括の見積金額と単価で調
整できてしまう
請負業者モデル
－単価
事業価値を最大化する方程式
エンジニア一人ひとりの継続的付加価値付けと、
そのマネジメントが求められる
∑
k = 1
n
∫1
t
nさんの成長度合い
＝事業価値
それぞれが、評価（≒単価）
向上のためのスキルアップ
や付加価値付けを続けるし
かない
開発パートナーモデル
+ +
nさん n+1さん

43. © Copyright 2021, ESM, Inc.
アジャイル受託開発を終わらせないために
43
∑
k = 1
n
∫1
t
nさんの成長度合い
＝事業価値
開発パートナーモデル
成長を減速させる要因をいかに減らすかが大切。
キーワードは、透明性、ふりかえり、自己管理、適切な委譲
それを支えるチーム重要。
ここが大きくならないとそもそも事業として苦しい。
需要面では、ビジョンを持って顧客と接し、 真のニーズ、困りごと
を掘り起こす必要あり。
供給面では、ベースラインに達した人材の確保が大切。未経験
者の技術転換も重要な方策となる。
マクロ（組織）とミクロ（個人）、両面マネジメントがさらに重要となる

44. © Copyright 2021, ESM, Inc.
アジャイル受託開発のその先
44
開発パートナー
（準委任契約）
内製化支援
パートナー
請負業者
開発パートナーの正常発展形としての内製化支援パートナー

45. © Copyright 2021, ESM, Inc.
内製化支援に受託屋が取り組む意味
45
私の見解
● 内製化が期待通り進展する場合、（不合理な）丸投げ的ベンダー
ロックインも減るはず
● 結果、開発者が支援する共創（伴走）型の内製化支援へのニー
ズは高まり
● 組織導入の面から支援するアジャイルコーチに対するニーズは
もちろんある
「内製支援とは自分の首をしめているのでは？」に対する回答

46. © Copyright 2021, ESM, Inc.
案件名
2019年 2020年
9 10 11 12 1 2 3 4 5 6 7 8 9 10
精算系システム
乗員ミール手配システム
物品判定システム
勤務管理系システム
経費精算システム
LL管理システム
共創開発
本開発
PoC 本開発
PoC 本開発
PoC 本開発
本開発
本開発
内製化支援事例
1. PoC（アジャイル開発支援＆技術移転）
2. 本開発（組織展開）
3. 共創チーム
Star
Star
Star
Star
Star
共創開発
共育＃１
共育＃２
（Agile Japan 2020発表資料より）

47. © Copyright 2021, ESM, Inc.
ASY×ESMのアジャイルパートナーシップジャーニー
47
受注側のアジャイル度
発注側のアジャイル度
◎
低い より高い
低い
より高い
契約の壁（準委任へ
の切り替え）
最初から準委任
PoC終了
本開発開始
共創開始
本開発終了
現時点

48. © Copyright 2021, ESM, Inc.
やはり見出したのは「Ready」「Do」「Be」Agileというステップ
48
● 「Ready Agile」ステップでのチャレンジが重要だった
○ キーマンとの信頼関係のベースができた
○ アジャイルをお互い学べた
● 「Do Agile」では、やはりしんどいこともありました
● 契約の壁は最初から超えているが、途中議論もあった
● 共創チームは「Be Agile」≒ アジャイルマインドがあってこそ
共創チームはアジャイルパートナーシップジャーニーのゴール

49. © Copyright 2021, ESM, Inc.
内製化支援時代のアジャイルパートナーシップ
49
コミュニケーションの死角に発生しがちな「もやもや」が効率を下げる。
両社各人の風通しが良いフォーメーションを保つ
顧客の
マネージャ
顧客の
エンジニア
支援パートナー
のマネージャ
支援パートナー
のエンジニア
内製化
ビジョン
契約
現場
ミッション ミッション
D
B
A
C
Aの例
顧客のマネージャとエンジ
ニア間でミッション認識の
相違あり
⇒支援マネージャが相談
にのる
Cの例
現場に顧客マネージャの
影響強すぎ
⇒ 顧客にミッションの再確
認を提案
Bの例
支援のマネージャとエンジ
ニア間でミッション認識の
相違あり
⇒顧客マネージャから申し
入れ
Dの例
現場に支援マネージャの
影響強すぎ
⇒ 現場からミッションの再
確認を申し入れる

50. © Copyright 2021, ESM, Inc.
まとめ
50

51. © Copyright 2021, ESM, Inc.
本日語りたかったこと
51
1. アジャイル受託開発を始める
○ 二段階契約も使いよう
○ 顧客と自社それぞれのアジャイル理解度を知るところから
2. アジャイル受託開発を続ける
○ なぜアジャイル受託開発に取り組むかビジョンを持つ
○ パートナーシップジャーニーをマクロ視点でマネジメントする
○ ハイブリッドやウォーターフォールでもビジョン実現に向けたステップの一部に
できる
3. アジャイル受託開発に終わりはあるか
○ 請負業者⇒開発パートナー⇒内製化支援パートナー
○ 内製化支援時代は、顧客との死角ない関係性がさらに重要に

52. © Copyright 2021, ESM, Inc.
関連情報
52
● NTTPCさまとの取り組み事例（Agile Japan 2019）
○ https://www.agile-studio.jp/post/agile-japan-2019
○ チームの具体的な改善事例を詳しく知りたい方に
● ASYさまとの取り組み事例（Agile Japan 2020）
○ https://2020.agilejapan.jp/pdf/DAY2_CH2_1420.pdf
○ 受発注関係を超えたパートナーシップジャーニー
● アジャイルと契約（Agile Studioプロデューサー木下）
○ https://www.agile-studio.jp/post/agile-contracts
○ 準委任をベースとするIPAとLIPモデルそれぞれ詳述

53. © Copyright 2021, ESM, Inc.
またお会いしましょう
53
2021年７月11日 Agile TECH Expo Episode2
スポンサーセッションで Agile Studioのマーケティング
の話をします。リモートでアジャイルなマーケティング
チームをどう作って運営しているのか？気になる方
は是非。