アジャイル開発の推進に必要なガバナンス

企業におけるデジタルトランスフォーメーション（DX）の広がりに伴い、DXの実現手段としてアジャイル開発に対する期待が高まっています。国内の金融機関などの大手企業でも、自社のシステム開発にアジャイル開発を適用する流れが加速しています。
しかし、アジャイル開発の適用を試みたが期待する効果が表れないため、「自社には適合しない」と断念する企業もあります。本稿では、アジャイル開発が期待通りに進まない原因と対策を考察し、開発に必要なガバナンスについて解説します。

アジャイル開発に対する期待の高まり
アジャイル開発が期待通りに進まない原因は何か
企業がアジャイル開発を推進させるために必要なガバナンスとは
終わりに

昨今、DXによるビジネスと組織の変革の拡大に伴い、DXの実現手段として、アジャイル開発に対する期待が高くなっています。新型コロナウイルス感染症以降はその流れが加速化していると言え、2020年にKPMGが実施した調査（図表1）からも、そのことがわかります。また、その対策としてビジネス部門とIT部門をコラボレーションして、システム開発の態勢強化を推進しているとの回答も見られます。
この背景として社内外の環境変化が激しく、今後のビジネスニーズなど先々を予測することがより困難になっていることが考えられます。特にコロナ禍ではソーシャルディスタンシングに伴う非対面取引やワークフローの適用範囲の拡大、BCPの強化など各種の要因がDXの必然性を加速させています。
そのため、企業は顧客や社員のニーズに柔軟に対応しながら他社に先駆けて素早くサービスを導入できる、アジリティのあるシステム開発態勢を社内に要求するようになりました。IT部門はその要求に応えるためにウォーターホール型（WF）に代表される計画的で厳格なプロセスに沿った開発手法ではなく、ビジネス部門と足並みを揃えて必要な機能を素早くリリースして継続的に拡張する、アジャイル型の開発手法の新規採用、もしくは適用範囲を拡大させる必要性が増しています。

金融機関をはじめ国内の大手企業において、DX推進によるサービスの改革や、それらを支える新たな組織や人材育成を企業戦略の柱として中期経営計画を作成するケースが増えています。しかし、同時に「DXが期待通りに推進しない、主な原因はDXに対応する組織の組成やアジャイル開発などの先端スキルを備えた人材の育成に課題がある」という声もよく耳にします。
多くの企業ではアジャイル開発を自社に浸透させるため、Scrum^※1などのアジャイル開発に適した手法を社内に適用させるためのルール整備や、ノウハウの蓄積を進めています。そのような施策はとても重要ですが、IT部門の改善に限定されている可能性があります。システムの開発速度や生産性の向上に寄与する可能性はありますが、企業がアジャイル開発に抱く期待に応えるためには不十分です。
企業がアジャイル開発に抱く期待は、顧客や社員のニーズへの柔軟な対応や素早いサービス導入に対する貢献です。これはIT部門だけでは実現できません。ビジネス部門による顧客ニーズや自社課題の把握、導入済みのサービスに対する継続的な分析が不可欠です。また、サービスの目的やターゲットの顧客は変わるかもしれません。それに伴い、システム開発の対象範囲やリリース時期も変わる可能性があります。さらには開発に必要なコストも流動的になります。経営層は不確定な要素が多いシステムの開発計画を承認し、バックアップするための企業風土の醸成やマネジメント態勢を構築することが必要になります。
つまり、アジャイル開発を効果的に進めるためには企業全体におけるガバナンス整備が必要ですが、多くの企業ではIT担当などの部門的な取組みに留まっています。そのため、本来であれば創出できるビジネスの価値を生み出せず、アジャイル開発が期待通りに進まない大きな原因に繋がっていると考えられます。

アジャイルは仮説の検証を繰り返し、課題の解決に近づいていく開発手法です。また、失敗に立ち止まらず継続的に学習して、開発チームおよび企業全体を改善し続ける考え方です。この考え方は社会や顧客に対する企業の在り方と酷似しています。そのため企業は組織全体でアジャイル開発に取り組む必要があります（図表2）。

【図表2　企業がアジャイル開発を推進させるために必要なガバナンス】

企業全体:アジャイル型の組織への変革

開発チーム:プロダクトマネジメント型のチームへの変革

（1）アジャイル型の組織への変革
経営層が主体となり、自社を環境変化に対し能動的に学習と試行を繰り返し、顧客に価値を提供し続けるアジャイル型の組織への変革が必要です。

企業の戦略や目標の整理、アジャイル開発が必要な理由の明確化
企業は自社サービスの課題や顧客ニーズ、他社や社会動向を踏まえてビジネス戦略を策定しています。アジャイル開発の推進には、ビジネス戦略をドライブさせるIT戦略が併せて検討されていることが重要になります。ビジネスの目的と実現の手段が検討されていることにより、アジャイル開発が必要なシステム領域が明確になります。
顧客と繋がりが深く課題の分析に基づき柔軟な対応が求められるサービス（SoE^※2と称されるシステム領域）と、社内業務中心でコスト効率化などが求められるサービス（SoR^※3と称されるシステム領域）では開発計画の確度や変動要素が異なります。前者はアジャイルで開発する必然性が高いと考えますが、後者は必ずしもアジャイルで開発する必要は無いかもしれません。そのようなサービスに対して、アジャイル開発を選択すると関係者の理解を得られない恐れがあります。アジャイルで開発を進める対象のサービスを明確にすることはとても重要です。

失敗を許容する企業風土
アジャイル開発では仮説の検証と失敗が繰り返されるため、失敗を許容する企業風土の醸成が一般的には必要と言われます。そのような企業風土は確かに理想的ですし、取り組む価値があります。しかし、企業風土の醸成を客観的に示す基準を設けることは難しいでしょう。また、予算や人的リソースに限りがある以上、失敗の許容には限度があり、画一的な基準の設置は現実的ではありません。
そのため、経営層はビジョンを共有して、社内でフラットに議論する場を作ることが必要です。例えば企業の目指す姿、アジャイル開発を用いる目的、サービスの位置づけ、顧客の声やコンペティターなどの情報について、社内で共通の認識を持てるような仕組みを作ることが重要です。

挑戦しないリスクに対応するマネジメント態勢
開発のマネジメント態勢について、従前のルールでは適用が難しい事項が多いと考えられます。特にアジャイル開発では不確定要素が多いため、開発の計画や予算の承認は困難ですが、従前のルール（例えば開発のコストやリターンのみで計画を評価）を活用した場合、開発計画の確度を上げるために時間を要しサービスを導入するタイミングを逸するなど挑戦を阻害する恐れがあります。
そのサービスが自社のビジネスに与えるプラスのインパクトや、挑戦しないことにより顧客やマーケットから排除されるリスクなども総合的に勘案して評価する、新しい考え方を加味したマネジメント態勢が必要です。

プロダクトマネジメントに適した組織体制
アジャイルで開発する目的は、価値があるサービスを顧客に提供し続けることです。特定の期間でサービス導入のミッションを達成した後は保守担当に引き継ぐといったプロジェクト型の組織とは適合しません。アジャイル開発ではプロダクトマネジメント型の組織体制が必要です。
プロダクトマネジメントとはサービスや顧客を重視して、サービスのライフサイクルに対応する組織体制です。開発に直接関与するIT部門と、顧客に相対するビジネス部門とが一体でサービスの導入を進めていきます。

新しい人材モデルと育成プランの作成
アジャイル開発にはIT部門だけでなくビジネス部門なども主体的に関与します。従来よりも携わるタスクの種類が幅広いため、開発チームメンバーにはより多能工なスキルが要求されます。経営層は必要なスキルを可視化した新しい人材モデルや、人材育成のビジョンを示すことが必要です。
なお、人材モデルの変化に伴い、新しい人事評価の検討も必要です。例えばOKR（Objectives and Key Results:目標と主要な結果）のようなフレームワークを用いて、企業の目標と個人の目標や成果とを関連付けし、企業全体でビジョンの共有を図ることや、個人のミッションを明確にする施策などが有効です。

アジャイル開発を支えるシステムやツールの導入
ビジネスやITなど部門を跨いだ混成メンバーでスピーディに開発を進めるために、効率的な社内のコミュニケーションは欠かせません。さらに昨今ではリモートワーク環境でのコミュニケーションの考慮も必須です。ウェブ会議システムやタスク管理ツールなど、非同期でのコミュニケーションを図るシステムについて社内の整備を進める必要があります。
また、サービスを素早く細かい頻度で継続的にリリースを繰り返し、なおかつ品質を維持するためにはテストやリリースの自動化など開発のライフサイクルに沿って支援するツールが重要になります。

（2）プロダクトマネジメント型のチームへの変革
サービスのライフサイクルに対してプロダクトマネジメント型の組織体制で顧客をサポートします。ビジネス部門やIT部門、セキュリティ担当チームが一体（BizDevOps＋Sec）^※4※5となって開発に取り組むことで、新たなビジネス上の価値を創造します。

ビジネス部門（Biz）
顧客へのサービス提供に関係する営業や商品企画などのビジネス部門には、顧客目線に基づくニーズの分析や自社の課題について把握することが一般的に求められます。ビジネス部門がアジャイルの開発体制に参加するためにはそれらに加えて、以下のリーンスタートアップ^※6を意識した行動が効果的です。
なお、そのためアジャイル開発においてはビジネス部門でも顧客ニーズなどのデータを分析する力やビジネスニーズからシステム要件を想定するような高いITリテラシーが重要になります。

• 仮説の構築
  顧客のニーズや自社課題に基づき最適なサービスや商品を検討します。

• MVP^※7の特定
  低コスト・短期間で試作品を市場に投入するために必要最低限な開発の要求仕様を特定します。

• 計測と学習
  試作品の対象顧客や利用状況を把握する手段を検討して顧客のフィードバックを計測します。当該結果に基づき仮説の妥当性を検証します。

• 意思決定
  サービスの本格展開や拡大、もしくは方向転換など今後のサービスの方向性について検討します。

開発担当のIT部門（Dev）
開発担当には従前より高品質なシステムを素早くリリースすることが当たり前のように要求されますが、アジャイル開発ではリリース速度に対する要求水準がさらに高くなる傾向があります。
企業が望むリリース時期の要求に応えつつ、高い品質を維持するためには以下のようにビジネス部門や運用担当との壁を取り払う工夫が必要です。また、ビジネス部門と同じ目線でサービスの要求仕様を共有するためには、IT部門にも自社のビジネスに対する深い理解が重要となります。

• ビジネスとIT部門が相互に理解できるチーム体制
  ビジネスとITの担当者が開発の要求仕様について早い段階から共通の理解を持てるチーム体制とします。開発の要求仕様について、同じ目線での共有を可能とするようなプロダクトバックログ^※8の作成やデイリースクラム^※9などの活用を検討します。

• テスト駆動型のシステム開発
  アジャイル開発では開発の終盤にプログラムの変更が繰り返し発生する可能性があります。その都度テストやテストケースを検討しているとリリースタイミングに影響が出ますし、品質にも懸念が残ります。開発者は対策として開発と並行してテストケースやテストプログラムを作成し、細かく開発とテストを繰り返します。

運用担当のIT部門（Ops）
アジャイル開発では導入済みのシステムに対しても継続的な改修とリリースが頻繁に発生することが想定されます。これらの一連の作業を高い品質と生産性で行うためにCI／CDツール^※10などを用いて開発のインフラを強化することが重要です。
また、大きな組織では開発と運用の担当チームが異なる、もしくは子会社などに運用を委託するケースもあります。開発チームと運用チームがサイロ化されている場合は体制の変更も重要な要素になるかもしれません。

セキュリティチーム（Sec）
リリースの速度と頻度が高まるにつれ、システムのセキュリティを担当するチームが動きについていくことが難しくなります。そのため、システム開発後にセキュアにするのではなく、最初からセキュアな開発を意識して取り組むことが重要になります。セキュリティチームは開発の初期から主体的に関与して開発の要求仕様や計画を理解した上でセキュリティやコンプライアンス上の懸念事項などを開発担当と共有します。開発担当は最初からセキュリティを意識したコーディングを行うことで遅延やセキュリティにかかわるシステムの品質リスクを軽減できます。
セキュリティチームが果たす役割は開発済みのシステムに対する品質チェックではなく、セキュリティのリスクを発生させる開発態勢となっていないかといった、開発のプロセスに対する品質チェックに変化することがポイントです。

変化が激しい社会において、企業はビジネスの新しい価値を創出するために仮説と検証を反復しています。アジャイル開発が注目を集める理由はプログラムの修正とリリースを反復するアジャイル開発の考え方が企業の価値を創出するアプローチと親和性が高いためと考えます。それゆえアジャイル開発には経営層含めて企業全体で取り組む必要があります。
すなわち、アジャイル開発の導入とは単なる新しいシステムの開発手法の採用ではなく、企業全体の在り方やガバナンスを変革する新しい試みだと考えます。

※1　Scrum：チームで主体的に仕事を進めるためのフレームワーク。アジャイル開発で活用されることが多い。
※2　SoE：Systems of Engagement。顧客接点があるフロント系のシステム。
※3　SoR：Systems of Record。社内情報を安全に管理するミドル、バック系のシステム。
※4　BizDevOps：ビジネス部門、開発部門、運用部門が分断せず協力して開発を推進する態勢。
※5　DevSecOps：開発、運用チームとセキュリティ担当が協力して開発を推進する態勢。
※6　リーンスタートアップ：低コスト短期間で試作品を作り、顧客の反応を確認しながら顧客満足度の高いサービスを開発するマネジメント手法。
※7　MVP（Minimum Viable Product）：顧客から有効なフィードバックを得ることが可能な初期のサービスのバージョン。
※8　プロダクトバックログ：ステークホルダーがプロダクトの状況（改善要素）について把握を可能とするツール。誰に対し、何故必要なのかを明確に示すことを目的とする。
※9　デイリースクラム：タスクの予実や課題を関係者で共有する。会議体の形式で行われることが多い。
※10　CI／CDツール：継続的インテグレーション、継続的デリバリーツール。テスト自動化やリリースの自動化の支援ツール。

KPMGコンサルティング
シニアマネジャー　石田 正悟