成功と失敗に学ぶアジャイル受託開発の極意

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• http://www.aoky.net/articles/steve_yegge/good_agile_bad_agile.htm

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

プロジェクトを積み上げても事業にはならない 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プロジェクトの収支は悪化するものの、トータルでは辻褄はあう 「なのでこのヘルプ増員は妥当だ」 ⇒ ほんとに？ ミクロも大切だけど、マクロな視点が事業継続には大切 © Copyright 2021, ESM, Inc. 40

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

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

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

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

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

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

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

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

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

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

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

関連情報 ● 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モデルそれぞれ詳述 © Copyright 2021, ESM, Inc. 52

• https://www.agile-studio.jp/post/agile-japan-2019
• https://2020.agilejapan.jp/pdf/DAY2_CH2_1420.pdf
• https://www.agile-studio.jp/post/agile-contracts

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