ソフトウェアビジネスやWebサービスの世界で、新規プロダクトの開発ではアジャイル開発が広く用いられるようになってきた。一方、デジタルトランスフォーメーションの流れの中で、大規模な基幹システムの開発やモダナイズにもアジャイルの手法を適用する動きが始まっている。全社規模のアジャイル開発体制構築に取り組む企業の動向、それを支えるベンダー、SI企業の動きを探り、アフターコロナ時代に向け企業が取り組むべき開発体制の新たな姿を明らかにする。
（取材・文／谷川耕一　編集／日高 彰）

　新型コロナウイルスへの対応で、多くの企業がさらなるデジタル変革の必要性に気付き、“2025年の崖”への対処を前倒しする動きも加速するとみられる。変革をスピーディーに進めるため、新規アプリケーションだけでなくレガシー化した既存のシステムについても、アジャイル開発の手法を検討する企業が増える可能性がある。

　大規模な業務システムの変革となれば、小さなスクラムチームで対処するのは難しい。開発には数百人規模が関わる大きなプロジェクトとなるが、その際にアジャイル開発の体制は維持できるのだろうか。企業全体の開発体制のアジャイル化を進める際には、いったいどこからアプローチすれば良いのだろうか。また、日本の多くの企業は、情報システムの開発や運用をSI企業に依存している。その体制でも、アジャイルによるシステムの変革には取り組めるのだろうか。

レガシーシステムも小さく分割し
アジャイルなアプローチを適用

　デジタル変革はゴールではなく、企業がビジネスの目的を達成する手段に過ぎない。そのため「デジタル変革を進めるためのアジャイルな開発体制も、目的ではない。顧客満足度を上げる、サービスのダウンタイムを減らすなどのビジネスアウトカム（成果）を得る手段だ」と言うのは、ヴイエムウェアのPivotal Labs Tokyoで、日本におけるサービスを担当しているザック・ブラウン・シニアマネージャだ。
 
　企業において継続的にアウトカムを得るためのデジタル変革の道のりは長く、常に変化する。変化に対応するために、アジャイルな開発体制が必要だ。そしてビジネスアウトカムは、新しいSoE（System of Engagement）のアプリケーションやサービスだけで得られるものではない。企業はミッションクリティカルなレガシーシステムも利用しており、それもまた迅速な変化への対応が求められる。
 
　もう一つ、日本特有のチャレンジとなるのが、システムの開発・運用をIT子会社やSI企業が行う形態が主流で、ITとビジネス部門の間に距離があることだ。このため、開発現場はビジネスの目的に対し当事者意識を持ち難い。求められるビジネスアウトカムを開発現場が把握し、何のためにレガシーシステムのモダナイズをするかを理解しなければ、どこから優先して取り組めば良いか判断はできない。結局、開発現場は決められた締め切りを守れるかだけを考えがちとなる。

　これらのような課題はあるものの、「レガシーシステムの変革でもアジャイルなアプローチを用いることは可能」とブラウン・シニアマネージャ。重要なのはアジャイルか否かではなく、ビジネスの目的が何かから紐解くことだと指摘する。たとえばメインフレームの移行も、更新時期を迎えたから実施するのではなく、コストを下げつつサービスの可用性を高めたい、サービスデリバリーの速度を上げたい、といったビジネス上の目標があるはずだ。アプリケーションのモダナイズでは「ビジネスゴールを共有し、そのためにベストな方法は何かから入る」とブラウン・シニアマネージャは言う。

　レガシーシステムのモダナイズを、ビッグバンで一気に変革することもあるが、Pivotalの推奨するアプローチでは、機能などに基づき小さな単位に分け必要なものからモダナイズする。大きなレガシーシステムであっても、変革する単位を小さくして積み上げることで、リスクを抑えられるからだ。

　実際にPivotalでは、メインフレームのモダナイズをサポートしており、Javaや.NETなど従来のフレームワークで構築された大規模アプリケーションの変革も行っている。旧い大きなシステムであっても、結局は小さな機能が集まってできている。切り出す単位を見極め、一つ一つに対しどれからモダナイズするかを「ビジネス価値と技術的な価値を見極め、優先順位を付け実施する」とブラウン・シニアマネージャは言う。

　ビジネス価値も技術的価値も低ければ、コストをかけずにクラウドリフトだけで終わらせる。ビジネス価値が高く繰り返し使うものは、クラウドネイティブな技術で作り直しマイクロサービス化する。大きなものを分割して考えるのは、新しいアプリケーションでも、大規模なレガシーアプリケーションでも変わらない。

　Pivotalでは、アプリケーションをそのままコンテナ化する“Re-Host”、最小限の変更でPivotal Application Serviceにデプロイする“Re-Platform”、フレームワークなど含めクラウドネイティブなアーキテクチャに移行する“Re-Factor”、アプリケーションを分割し別のコードベースとしてリライトする“Re-Build”という四つの移行パターンを定義し、ビジネスインパクトや技術的な複雑度などを評価し選択する。

　その上でAPI、イベント、データフローを視覚化するための「BORIS」と呼ばれる相互作用図を作成し、BORISから機能を選択して「SNAPeメソッド」を用い、実行可能なバックログを作成しどこから取り組むかを決める。これら一連のPivotal独自の取り組みは、同社が提供する2～3日のワークショップで実践できる。さらに次のステップでは、外部システムのインターフェースをどうするかなどのアーキテクチャーの分析も実施する。いきなり大きなアジャイル開発チームを作り、これらに取り組もうとしてもなかなか成功しない。Pivotalでは小さな単位で始め、2～3年かけて大きなチームに育てていくことを勧めている。

大規模アジャイル開発の実現で
注目される「SAFe」とは

　変革のアプローチでビジネス価値による判断を重視するのは、大規模アジャイル開発フレームワークで欧米を中心に高いシェアを得ている「SAFe（Scaled Agile Framework、セーフ）」でも同様だ。SAFeはリーン、アジャイル、DevOpsの原則に、プラクティス（実践ノウハウ）やコンピテンシー（モデルとなるスキルセット）を組み合わせた実証済みのフレームワークだ。その中身は、誰でも利用できるナレッジベースとなっている。

　アジャイル開発では自発的に考えて動ける個人がスクラムチームを構成し、チームが自律的に動いて変化に素早く対応する。一つのスクラムチームは5人から10人ほどのメンバーで構成されるが、それらのチームが三つか四つ程度連携して動く規模のプロジェクトならば大きな問題は出ないだろう。

　ところが、大規模システムの開発ともなれば、10あるいは100のスクラムチームが集まることにもなる。この規模では、個々のスクラムチームが自律的に動くアジャイル開発のフレームワークだけでは上手くいかない。「アジャイル開発のスクラムチームにはリーダーシップがないが、スクラムチームが多数集まればそれを取りまとめるリーダーの意識、振る舞いが重要となる」と言うのは、国内でSAFeの普及事業を行うSCALED AGILE Japanの古場達朗カントリービジネスデベロップメントマネージャーだ。SAFeが単純なスクラムチームの考え方と異なるのは、このリーダーに対する変化を求めているところだという。

　SAFeはビジネスに俊敏性を持たせるためのフレームワークであり、リーンアジャイルリーダーシップが中心にある。そして実行領域となるチーム＆テクニカルアジリティ、アジャイルプロダクトデリバリー、エンタープライズソリューションデリバリーが、戦略領域のリーンポートフォリオマネジメント、オーガニゼーショナルアジリティ、コンティニュアスラーニングカルチャーという七つのコンピテンシーがあり（下図参照）、それぞれのコンピテンシーは関連知識、スキル、行動様式といった三つのナレッジで構成される。
  　実行のコンピテンシーではアジャイル開発チームのあり方、DevOpsのテクノロジーを使い大規模なアジャイル開発体制を運用するためのナレッジなどがある。戦略のコンピテンシーには大規模アジャイル開発組織における意思決定のあり方、予算の考え方や組織全体をどう運営するかのナレッジが蓄積されている。リーダーシップのコンピテンシーは、リーダーがマインドをどう変えれば良いかのナレッジとなる。これらを網羅することで「大がかりな開発プロジェクトも、アジャイルな体制で進められるようになる」と古場マネージャー。
 
　経営層やマネージャーなどのリーダーには、業務のパフォーマンスに影響を与えるためにシステムを変革し、継続的に改善をもたらすようにするための権限があるだろう。リーダーが最もビジネスアウトカムを理解しており、それに必要なものが何かを判断できる。開発者がボトムアップでスクラムチームを作り、小さなプロジェクトで成功するのと、大規模システムにアジャイル開発を適用するのでは、このリーダーによる判断が大きな違いだ。そのためSAFeでは、最初に小さなスクラムチームを作りアジャイル開発のPoCを実施するのではなく、まずはビジネスを牽引するリーダーのマインドの変革から入ることになる。

　小規模なスクラムチームで、新しいアプリケーションの開発をアジャイルで成功させている先進企業でも、大規模なシステムの変革では全体統制がとれず、アジャイルの迅速性のメリットが発揮できないことがある。また、全社規模でアジャイル開発体制に移行すべきだと理解していても、デジタル変革を牽引する強いリーダーがいなければ、結局はどこから手を付け組織や体制を変えれば良いかの判断ができず、様子見となることもある。大規模システムにおけるアジャイル開発では、経営層やマネージャーのリーダーシップが極めて重要になる点はきちんと押さえておく必要がある。

[次のページ]全社規模のアジャイル化をどう実現するか