DXで直面するカベを突破せよ ITのシステムアジリティー向上を阻むカベを突破せよ

筆者の所属するPwCコンサルティングが発表した「2024年DX意識調査―IT モダナイゼーション編」の分析結果からは、「DXの成果が期待通り、もしくはそれ以上」と回答した企業が41%にとどまることが分かった。これは、顧客動向、法規制、地政学リスク、新技術動向など企業を取り巻くビジネス環境の変化が日を追うごとに加速する一方で、ITシステムがこれらの変化に迅速に対応できていないことに起因していると想定する。

従来のウォーターフォール型の開発では、プロジェクト開始時に策定した計画に基づいてプロジェクトを実施することが求められるが、現実にはプロジェクト中にさまざまなビジネス環境の変化が起きてしまう。こうした変化の激しい状況においては、変更を前提としたアジャイル開発の活用が企業に求められる。

実際にPwCコンサルティングの調査では、「DXの成果が期待通りもしくはそれ以上」と回答した企業のうち、90%がアジャイル開発を活用しており、その効果は「不要な開発の削減」「変更要求への柔軟な対応」「サービス提供開始時期の早期化」が上位の回答となった。この結果から、ビジネスが激変する環境におけるアジャイル開発の有用性を確認できる。そこで本稿は、どのようにアジャイル開発を組織に浸透させ、ITシステムのアジリティーを向上させるか、そして、それらを阻害する要因への対処方法に関して解説する。

図表1：DXの成功と親和性の高いアジャイル開発

^{出典：「2024年DX意識調査 - ITモダナイゼーション編 -」を基にPwCにて作成}

第1のケース：名前だけアジャイル

とある企業は、従来のウォーターフォール型開発から一部をアジャイル開発に移行した。スクラムを手法として採用し、プロダクトオーナーやスクラムマスターを任命。週次報告会は「スプリントレビュー」と名前を変え、朝会は「デイリースクラム」と呼ぶようになった。プロダクトオーナーやスクラムマスターは、これまでにはない役割のため、プロダクトオーナーは企画部門の課長、スクラムマスターはプロジェクトマネージャーと、既存の役割や役職に当てはめ任命した。

ところが、スクラムにおけるスプリントレビューなどのイベントの本質的な意味や、目的を理解しないままイベントを移行したり、個人の能力や特性を考慮せずに役割を画一的に当てはめたりしたことで、スクラムチームが機能せず、自社には合わないと判断して諦めてしまったのだ。このケースが失敗した要因と、望ましい対応方法を以下に説明する。

スクラムでは、プロダクトオーナーやスクラムマスターと呼ばれる役割を定義する。これは、役職や職階ではなく役割である。既存の役職と対比できるものではない。無理に既存の役職に当てはめるのではなく、個人の能力や特性に応じて適切に任命するのがポイントとなる。

各種スクラムイベント（会議）にしても、デイリースクラムは次の24時間の再計画を行う場であり、1日1回の報告を行う朝会とは異なる。また、スプリントレトロスペクティブはチームの最も重要な1つの課題を特定しアクションを決定する場であり、反省会や振り返りではない。「Keep」（良かったこと）、「Problem」（より良くしたいこと）、「Try」（改善案）を出す「KPT法」などの特定の手法を用いたからといって、スプリントレトロスペクティブが機能するわけではない。

既存の枠組みに無理に当てはめた結果、スクラムが合わないと断念する前に、まずはスクラムをそのまま実践してみることが必要である。組織への影響が大きいのであれば、小さなところ――例えば、1チームや短期で終わるプロジェクトでスクラムガイド通りに実践してみてほしい。そして効果が見えてきた段階で、より大きな効果を出すために、スクラム自体をカスタマイズする。つまりはプロダクトオーナー、スクラムマスターと開発者のみでスクラムチームを構成し、別の役割（例えばプロジェクトマネージャー）を作らない、兼務を避けるなど、スクラムガイド通りに行うことが肝要であり、最初から独自のカスタマイズは避けるべきである。

まとめ

アジリティー向上の鍵は、現場のスキルおよび自律性の向上である。これを実現するには、チームに学習の時間と支援、自律性を育むために権限を与えることが重要となる。そのためには、組織レベルにおいても現場レベルにおいても多くのことを変える必要がある。既存のしがらみやルールなどとの整合を取ることは無視できないが、最優先すべきはアジリティーの向上と、その結果としてのビジネスバリューである。

アジャイル導入を名前だけの変更など表面的なやり方にとどめるのではなく、原理原則を理解した上で導入してほしい。