1．はじめに

2011年米国の著名投資家であるMarc Andreessenが「Why Software Is Eating The World」と題した手記の中で，「ソフトウェアを中心にビジネスを駆動する企業が台頭し，あらゆる産業を飲み込んでいく」と予言した[1]．IT（Software）の位置付けが活動効率化の道具から価値創造の中心へと大きく変化していくことは論を待たないであろう（図1）．

このため，近年，デジタルトランスフォーメーション（以降，DX）の推進が注目され，企業はIoT，ビックデータ，AIなどの新しいディジタル技術の活用による新たな付加価値の創出に取り組んでいる．同時にこれらの活動は，競争上の優位性を確立するため，俊敏な対応が求められる．そこで，新たな価値創出に必要となる柔軟性とスピードを実現する開発手法としてアジャイル開発が広く採用されている．これまで，アジャイル開発は，繋がるためのシステムであるSystem of Engagement（SoE）と呼ばれる領域に適用されてきたが，この領域では小規模な開発が多い．

一方，「2025年の崖」で指摘されるとおり，これまで企業活動を支えてきたレガシーシステムが足かせとなり，期待する形でビジネス変革が進まない企業も多くある．DXの潮流から取り残され，企業の経営基盤そのものの維持・継続が困難となる危機が迫っている．従来型の基幹系業務システムは主に，記録するためのシステムであるSystem of Records（SoR）と呼ばれる領域であり，大規模である．このため，この領域は，アジャイル型の開発向きではなく，ウォーターフォール型の開発が向いているとされてきた．

レガシーシステムの多くは長期間に及ぶシステム運用の結果，システムが肥大化・複雑化・ブラックボックス化し，有識者不在・最新化された設計書がないといった課題を抱えている．このため，システム化の要求事項である業務要件・機能仕様を上流工程で定義することが困難になり，これまでのようにウォーターフォール型の開発を単純適用することができないというジレンマに陥り始めている．このジレンマに対する解決策は難しいため，この課題が先延ばしされ続けている．その結果，さらに肥大化・複雑化が進行するという悪循環に陥り，解決が不可避な危機に直面している．

（一社）日本情報システム・ユーザ協会（JUAS）のアンケート調査[2]によると，約8割の企業が「レガシーシステム」を抱えており，約7割が「レガシーシステム」が足かせになっていると回答している．DXレポート[3]では，複雑化・老朽化・ブラックボックス化したレガシーシステムが残存した場合，2025年までに予想される経済損失は最大12兆円／年にのぼる可能性を「2025年の崖」として指摘している．多くの企業にとって，レガシーモダナイゼーションによって目前に迫った2025年の崖を回避してレガシーシステムから脱却することが急務である．これは，脅威であると同時に好機でもある．ブラックボックスを解消し，本格的なDXを実行して“ディジタル企業”へ変革することができれば，2030年に実質GDPを130兆円押し上げる効果があるとも指摘している．

富士通（株）は，お客さま基幹システムの新システム化構想における「基幹業務システムのレガシーモダナイゼーション」に取り組んだ[4]．超大規模レガシーモダナイゼーションプロジェクトを「動くソフトウェア活用による現行踏襲」「漸進型リリース」の開発プロセスと，「自律改善型マネジメント」のマネジメント手法の適用により成功に導いた．これまで蓄積したウォーターフォール型開発ノウハウへのカイゼンを繰り返す一方，アジャイル開発の考え方[5]を取り入れ，プロジェクト独自に進化を遂げたハイブリッド・アジャイル型の実践手法を確立できた．それらの適用により「2025年の崖」の足かせとなっていたレガシーシステムをDXのための基盤に変革させた．まさに，一足早く，「2025年の崖」を飛び越えることができた．

本稿では，ハイブリッドアジャイル開発によるレガシーモダナイゼーションの取り組み事例を紹介する．第2章では開発プロジェクトの背景，第3章以降では，プロジェクトにおける段階的な成長の過程をアジャイル開発でグローバルに広まった，守破離（Shu-ha-ri）のプロセスに見立て，第3章では，守：ウォーターフォール適用と課題，第4章では，破：ハイブリッドアジャイル開発適用，第5章では，離：マネジメント変革について紹介する．

2．プロジェクトの背景

2.1　ビジネス環境

対象の基幹システムは，建築事業と不動産事業を統合した全社的業務を担う．建築事業のお客様の依頼で建てた建物を，不動産事業のお客様に賃貸する．このため，不動産事業のお客さまである一般消費者の反応が，建築事業のお客さまに大きく影響する．しかも，その一般消費者の反応を予測することは年々困難になっている．企業が競争優位を確立するためには，この一般消費者を含む市場の変化に俊敏に対応することが求められる．企業活動の中核を支えるICT基盤を中長期の将来を見据えて刷新するため，「新システム化構想における新基幹業務システム」を構築する本プロジェクトが立ち上げられた．新規事業を俊敏に展開できる柔軟性・拡張性を持ち，DXの環境を整えたICT基盤を構築することを指針目標とした．構築から20年以上が経過したメインフレームの基幹業務システムをモダナイズし，レガシーからの脱却を目指した．

2.2　レガシーシステムの特徴

お客さま情報システムの約半数を占める基幹業務システムの再構築プロジェクトであり，富士通受託作業での総工数11,000人月超，ピーク時開発人員500名超，開発期間58カ月に及んだ．対象規模620万ステップ（6.2Mstep：メガステップ）のRPGやCOBOL等のメインフレームで多用されている言語（メインフレーム言語）の資産をJavaへ書き換える超大規模レガシーモダナイゼーションプロジェクトである．

構築から20年以上経過した本システムは以下の特徴を持つ.

• プログラムはブラックボックス化・スパゲッティ化し，設計書は最新化されていない．また，有識者も十分にいない状況である．
• ビジネス変化に対応するため，定常的に現行システムを改修し続けている．
• データ結合度が高い25,000テーブルを保有している．

上記の特徴は，構築から20年以上のシステム保守においては，どのお客さまにも共通する典型的な特徴と考えられる．

2.3　再構築手法の分析

（1）再構築手法の選択

レガシーシステムの再構築（レガシーモダナイゼーション）には複数の手法があり，新システム化要件によって選択される．主な手法としては，ハードウェアの入れ替えとOSやミドルウェアのレベルアップを行うハードウェア更改，サーバやOSといったITインフラを刷新するリホスト，現行の業務仕様を変更せずに旧言語から新言語へ書き換えるリライト，現行の業務仕様を基に設計・製造・テストを改めて実施するリビルドがある．再構築手法とレイヤにおける変更の有無を表1に示す．

一般的には，変更のあるレイヤが高くなるに連れて再構築の難易度が上昇し，プロジェクトのリスクが高まる．ハードウェア更改やリホストは，ハードウェアおよび，ミドルウェアレイヤに変更個所を極小化することで再構築に伴うリスクを軽減・回避する．リライト，リビルドは業務アプリケーション領域に変更が加わるため難易度が上昇する．特に，リビルド手法は変更レイヤがすべてに渡るため難易度が最も高く，選択する場合には留意が必要となる．

本プロジェクトでは，メインフレーム言語からJavaへのリビルドを前提条件としていた．なぜならば，事業に必要となる柔軟性・拡張性を持ったシステムを構築することが，ブラックボックス化・スパゲティ化したままのプログラムをリライト方式で単純移行しただけでは実現できないためである．これに加え，これまでベンダロックインに悩まされてきた課題から標準技術適用が目的の1つに掲げられていたことや，リライトを実現できる実績のあるコンバージョンツールが存在しないなどの理由が挙げられる．

リビルドは現行の業務仕様を基に設計・製造・テストを改めて実施する再構築手法である．このため，次のような何らかの方法で現行の業務仕様を明確化する必要がある．

• 現行システムの有識者が業務要件・機能仕様を再定義する
• 現行システムの設計書を基にする
• 現行プログラムソースからリバースエンジニアリングする

有識者不在，最新化された設計書がないという状況の中，新規スクラッチ開発と同様に要件定義工程で業務要件を定義し，基本設計（外部設計）で機能仕様を再定義するというアプローチを選択することができなかった．そのため，有識者不在，現行システムの設計書がなくても仕様を明確化する手段として，現行プログラムソースを解析して新設計書を作成する考え方[6]を開発プロセスの基本方針とした．

（2）ウォーターフォール型の限界

ウォーターフォール改良型である開発プロセスを基本方針として，プロジェクト開始当初は，4STEPの段階的開発を行う計画を策定した．システム特性の分析結果からサイロ化されたシステムのシステム間連携強度・データ連携依存度を考慮し，ビックバン型の一括移行によるリスク分散を図るために段階的開発とした．事業領域ごとのシステムをリリース単位として4段階リリースとし，最初のリリースとなるSTEP1開発は初期リスクを考慮して全体の約1／20規模の小規模開発としてプロジェクトを推進した．

プロトタイプ開発，STEP1開発の実践により，開発プロセスの基本方針の有効性は実証できたが，ウォーターフォールの発想の域をでない改良型では一部課題が残ることが判明した．テストタスクの一部として現行システムと新システムを比較する現新コンペアを実施するだけでは網羅性が不十分な点，テスト工程での実施では手戻りが増大して納期延伸になる点，不確実性のリスクを作業タスクとして積み上げるためコストが増大する点である．

また，STEP1開発に続いて開始したSTEP2開発では，STEP1開発の実績から設定した生産性や品質の指標が達成できず，大幅な進捗遅延が発生した．STEP2開発では同一プロセスを適用したが，STEP1開発との条件の違いから，STEP2開発で指標が達成できない原因は，STEP2開発の規模にあると考えた．本プロジェクトは11,000人月超のプロジェクトであるため，4STEPの段階的開発でも各STEPの規模は数千人月単位となり，従来の手法をそのまま適用することに限界があると考えた．

開発プロセスおよび大きすぎる規模に係わる課題を解決するため，ウォーターフォール開発に従来型にはない手法を取り入れることで，レガシーモダナイゼーションに適合する新しい開発手法ができるのではないかとの仮説を立て，計画を見直した．

3．守：ウォーターフォール適用と課題

基幹業務システムの再構築プロジェクトにおいて，ウォーターフォール開発を採用することは従来の定石である．現行システムが存在しており，決められた品質，決められた予算，決められた納期で計画とおりに完遂することをユーザは求めており，ベンダもその期待に応えようとする．しかし，レガシーシステムが抱える制約条件により，ウォーターフォール開発の単純適用ができないケースでは，プロジェクト特性に合わせたテーラリングがプロジェクトの成否を握る鍵となる．ウォーターフォール開発の「型」を守り，レガシーモダナイゼーションするための課題として，以下を識別した．

• 肥大化・複雑化した現行ソースからの仕様再定義
• 構築中（2年間）も仕様凍結せず，ビジネス変化に対応
• 大量のデータベースの移行策

3.1　肥大化・複雑化した現行ソースからの仕様再定義

最新化されていない現行システムの設計書を廃棄し，基本設計工程で現行プログラムソースを解析して新設計書を作成する開発プロセスの基本方針は変えず，開発プロセスを「N字モデル」として再定義した．一般的なウォーターフォール開発プロセスであるV字モデルに加え，現行プログラムソース解析の工程を設定し，新機能要件として再定義している．有識者がおらず，業務要件・機能仕様を明確化できない場合，企画プロセスと呼ばれる超上流工程を設けたとしても課題の先延ばしとなるケースが多い．いずれはどのようなアプローチで現行仕様を明確化するのかという課題に直面することになる．このため，さらなる上流工程を設けるのではなく，通常は下流工程で行う作業からの仕様の掘り起こしを行うためのアプローチを採用した（図2）．

上流工程で明確化できないシステム機能仕様を，リバースエンジニアリングで現行プログラムソースから抽出し，V字モデルにつなげる．従来のV字モデルの前段階に，現行ソースを解析する工程を加えてNの字に見立てているのが特徴である．解析ツール製品を活用して構造化ドキュメントを生成して可視化し，日本語化ツールでプログラムソースの可読性を高め，メインフレーム言語のスキル保有者以外でも現行ソース解析が可能となるよう考慮した．プロジェクト独自の変換ツールも作成し，品質・生産性の向上を図っている．

肥大化・複雑化した現行ソースの解析は非常に困難であるため，ベンダ側のメンバだけではなくユーザ側のメンバも参画し，プロジェクトメンバが協力して段階的に新設計書を仕上げるプロセスとして定義した．

重要なポイントとして，資産解析工程では100%の品質を目指さないことを合意した．品質とコストはトレードオフの関係にある．時間を掛ければ掛けるだけ品質は向上するが，コストに見合った品質向上効果は得ることができない（図3）．本工程ではプロジェクトで規定した開発標準プロセスを遵守することで一定の品質を担保し，さらなる品質向上はテスト工程で底上げする．

一方，テスト工程でのさらなる品質向上の実現方法とコストのバランスの実現が課題となった．

3.2　構築中も仕様凍結せず，ビジネス変化に対応

構築期間をシステム規模から2年～3年に及ぶと試算した．システム構築期間中は，仕様凍結できることが望ましい．一方，利用部門は，一般消費者の変化に対して俊敏な対応により競争優位を確立することを推進しているため，現行仕様凍結ができない．現行仕様凍結ができない場合，新システムの開発期間中に常に現行システムの改修内容を反映し続けなければならず，二重の開発コストがかかる．二重開発コストは単純計算で10億円以上と試算された．それだけではなく，常時発生する仕様変更を取り込み続けることによる，QCDのすべてに影響が発生するリスクが想定された．

構築中，仕様凍結せず，ビジネス変化に対応し続けることが課題となった．

3.3　大量データベースの移行策

現行システムから新システムへの移行はプログラムだけではなく，データも同時に移行する必要がある．現行システムは最大で25,000超のデータベーステーブルを保有している．ビジネス変化に俊敏に対応するため，分割した移行の考慮も必要である．この場合，現行システムにおけるサブシステム間のデータ結合度が高いため，対象テーブルに対して現行システムと新システム間でリアルタイム連携が必要となる．対象テーブル数が増加していき，性能限界を超えてしまうリスクもある．このため，システム間のリアルタイム連携を不要とする，現実的なプログラムとデータベースの移行策が必要であった．

4．破：ハイブリッドアジャイル実践手法の確立

ウォーターフォール開発の型を守り，改良を加えた開発プロセスを適用したが従来手法の踏襲では限界があり，従来手法にはない新しい開発手法の確立を目指してプロジェクトではカイゼンを続けた．本章では，第3章に示した3つの課題に対し，ウォーターフォール開発の「型」を破り，レガシーモダナイゼーションに適合する新しい開発手法へのアプローチを示す．

4.1　「動くソフトウェア」を活用した現行踏襲

アジャイル開発では，ビジネスの観点で十分に評価可能な「動くソフトウェア」を素早く継続的に提供し，顧客の満足度がどのような状態なのか，明らかにする．これにより，要件の曖昧性の除去と価値創造に貢献する．この考え方をN字モデルの開発プロセスに加える．すなわち，設計・製造・テストを実施するコンペアスプリントタスク（表2）により，異なる3つの観点で繰り返し現新コンペア（比較，差異分析，修正・設計・製造・テスト）を行う．変更を前提とした「反復型ウォーターフォール」の開発プロセスを構築した（図4）．

プログラムテスト工程と結合テスト工程の間に，現新コンペア工程を新たに定義した．この工程は，あらかじめ作業量を見積もることができないため，開発とは別に準委任契約を締結している．現新コンペア工程では，現行システムと新システムにそれぞれ同じテストデータを与えて両方の実行結果を照合する.この施策に至る考慮点は3点ある．

1点目は，手戻り工数と納期遅延リスクを考慮した場合，現新比較をプログラムテスト工程後に実施することが最も効果的であると考えた点である．現新コンペアは十分な効果がでるが，比較結果が一致しない差異も想定以上に発生することが確認された．現新差異分析の結果，システムテスト工程でなくプログラムテスト工程でも検出可能なレベルの差異が7割を超えることが判明した．加えて，想定以上の件数が発生すると，改修期間・再テストに十分な時間が取れずに納期遅延のリスクが高まる．このため，プログラムテスト工程完了後の実施とする．

2点目は，現新コンペアには現行調査が必要であり，現行システムを良く知るユーザの参画が不可欠と考えたからである．現新差異分析の結果，5割を超える現新差異は，現行システムの調査を必要とし，現行データ起因の差異や一部の現行データ障害が検出されることが確認された．加えて，スピーディな対応のためにはユーザ側とベンダ側の協力体制が必要となる．請負契約では契約上の問題があるため，準委任契約とし，協働体制を構築する．

3点目は協働体制により，作業タスクおよび実施リスクを分担し，コストを抑制するためである．現新差異に対するリスクをベンダ側が負うことになる場合，ベンダ側はリスクをコストに転嫁することになる．ユーザ側とベンダ側で互いにリスク受容し，協力的な体制で現新コンペアに取り組むことが効率的な解の1つである．これにより，コスト抑制効果を期待している．

さらに，現新コンペアの実施時の工夫として，アジャイル開発の考え方を取り入れ，反復型の現新コンペア（コンペアスプリント）を実施する．主要観点を絞った段階的な現新差異の抽出と不一致の修正を行う．

4.2　漸進型リリース

（1）標準開発モデルの策定

再定義した開発プロセスを基に，開発期間，開発規模，開発体制の実現性を評価し，開発プロジェクトの基準となる標準モデルを策定する．標準モデルの策定にあたっては，前提条件や制約条件も合わせて考慮することが必要である．

ウォーターフォール開発における，開発期間の見積もり手法としてはCOCOMOがあるが，最適期間を算出するものではない．一方，アジャイル開発においては，タイムボックスという概念があり，アジャイル開発の原則によれば，2～3週間から2～3カ月という期間が示されている[7]．

まず，現行仕様凍結が可能な期間を利用部門と調整し，システム全体ではなく一部の業務に限る場合の最長仕様凍結期間を検討し，約半年を設定した．次に，約半年を前提に最適な期間と規模を検討した，プロトタイプ開発とSTEP1開発，STEP2開発の生産性実績を加味して最適期間と規模の調整を行った．最終調整の結果，開発期間7カ月（±1.5カ月），対象資産規模70kstep（キロステップ），チーム体制はユーザ側メンバ4名±α，ベンダ側メンバ10名±αの標準開発モデル（小ロット開発モデル）という計画を策定した（図5）．

（2）漸進型リリースモデル

アジャイル開発では，コストと期間を固定にして，開発のリズムを維持して「動くソフトウェア」によりビジネスに貢献していく．この考え方を標準モデルの適用に応用した．

標準開発モデルに適合するようにサブシステムの分割を行い，プロジェクトの分割を図る（小ロット化）．サブシステム粒度がまちまちであっても，分割にあたっては標準モデルに適合させることを優先条件とする．なぜならば，大規模マネジメントの最適化を図るためには仕組みのスケールアウトが必要であると考え，徹底的に標準化にこだわったからである．サブシステムの分割や再統合，開発期間に収まるような開発順序の組み換えを行い，業務制約も加味しながらリリース計画の策定には時間をかけて協議した．

初期リスクを軽減させるため，ファーストロットは単一ロットから始め，徐々に開発多重度（同時並行推進ロット数）を上げる．1ロットを終えると，次のロットに着手する繰り返しモデルとすることで，プロジェクトメンバの習熟度を向上させ，生産性向上，品質向上に繋げた．

リリースに際しては，コンティンジェンシー計画を策定し，約2カ月間の現行システムと新システムの並行稼働期間を設けて，万が一の場合は現行システムへの切戻しを可能とした．並行稼働期間における十分なシステム妥当性を確認後，現行システム環境を閉塞するようにした．

小ロットの再編，小ロット開発順序設定を経て，漸進型リリース計画を立案した．最終的には，4STEPの段階的リリースの計画から，82ロット分割の小ロット漸進型リリース計画に変更した（図6）．

4.3　プログラムとデータベースの移行の分離

プログラム移行（Phase1）とデータベース移行（Phase2）を2段階に分けるPhase分割を新たに考案した（図7）．Phase1ではデータベースは移行せずに現行データベースを継続利用してプログラムだけをモジュール単位で順に移行するため，現新データ連携が不要となることを意図した．

Phase分割案に基づき，実現性検証，QCDインパクト調査結果を反映した見直し計画（リプラン）を策定し，プロジェクトオーナの承認を得た．データベース移行（Phase2）は，本プロジェクトでは行わないという決断を下した．

Phase分割にあたっての考慮点として，現行データベース（DB2）と新データベース（Oracle）の非互換SQL調査を行い，互換機能のみを新規プログラムに採用し各種規約に反映させている．互換機能利用により，Phase2でのデータベース移行時のプログラム移行作業が容易となるよう考慮した．

5．離：マネジメント変革

「反復型ウォーターフォール」「漸進型リリース」により従来手法による規模のスケールアップではなく，超大規模レガシーモダナイゼーションに適合する新たな「型」を産み出し，仕組みをスケールアウトすることが可能となった．この「仕組み」を実践するための「仕掛け」としてプロジェクトではさらなるカイゼンを続けた．本章では，ウォーターフォール開発の「型」を離れ，レガシーモダナイゼーションに適合する新しいマネジメント手法へのアプローチを示す．

5.1　自律改善型マネジメントへ

小ロット開発体制を円滑に推進するために，統制型マネジメント体制から自律改善型マネジメント体制に変革した（図8）．チームリーダ，事業領域グループリーダの自主性を最大限に生かせるように指示型の統制をやめ，支援型のアプローチを行った．リーダ同士による協調や，リーダ自身の自律により自主運営型の組織に変革していった．

5.2　WA（和）のマネジメント

自律したチームが互いに助け合う1つのWA（和）[8]を形成した．さらに，4～5チームが1つになってグループを形成し，自律したグループがさらに大きな1つのWAを形成し，5グループが1つになってプロジェクトのWAを形成した．統制型の階層型組織ではなく，自律改善型のチーム一丸体制を構築することで協調・自律・助け合いの組織に変革することを意図した（図9）．

5.3　カイゼンマインドの醸成

カイゼンマインドは，日ごろからのカイゼン活動によって組織の文化や風土として醸成されていく．知識や仕組みとして頭で理解しているつもりになっているだけでは，表面的な取り組みに留まり，本質的な自律改善を行うことは難しい．

本プロジェクトでは，TMS（Toyota way Management System）[9]を組織で学び，継続的な取り組みを行った．「プロジェクトメンバ全員が健康とワークライフバランスを保ち，プロジェクト成功に向けて楽しく取り組み，お客さまへの付加価値を生み出す」という目標を掲げて取り組んだ（図10）．

筆者は第1期カイゼンリーダとして自律改善活動を推進し，プロジェクトメンバにカイゼンマインドを醸成した．半期ごとにカイゼンリーダをローテーションし，プロジェクト開始当初から5年に渡る組織的なカイゼン活動を通じて，プロジェクトメンバ全員が互いに助け合いながら課題解決する力を身につけてきた．

5.4　BA（場）づくり

自律改善型のマネジメントを実践するための取り組みとして，進捗会議やチームミーティングとは別に，現場リーダ層の自主運営によるリーダ朝会，リーダ会，カイゼン会を設定した．リーダ層が持ち回りで，アジェンダ作成，ファシリテート，課題解決や施策の検討をすべて実施する．プロジェクトマネージャは，自主運営の会議体には参加しない，もしくは，参加しても積極的には発言せず，リーダ層の自主性を尊重することとした．

（1）リーダ朝会（15分／デイリー）

毎朝，スタンドアップのリーダ朝会を行い，全チームに影響を及ぼす課題や対応策についての共有を行う．

（2）リーダ会（60分／ウィークリー）

各ロットで発生した課題や対応策の振り返りを行うことで，日々積み重ねた実践知を形式知化してプロジェクト全体にフィードバックする．標準開発プロセス・標準開発モデルの適用により，全ロットが共通の前提条件となり，プロジェクト全体の学びのスピードと効果が飛躍的に向上することを意図した．

（3）カイゼン会（30分／ウィークリー）

プロジェクトのプロセス改善だけに留まらず，日々の作業や組織活動，残業時間削減や年休取得率向上といった組織活動改善の工夫を考える．1週間という短いサイクルで振り返りを行う場が提供されるため，カイゼンのスピードと効果が飛躍的に向上することを意図した．

6．プロジェクト効果

6.1　課題への評価

第3章で提示した課題に対する評価を以下に示す．

（1）肥大化・複雑化した現行ソースからの仕様再定義

重大障害0件で予定納期どおりのリリースを達成した．
「動くソフトウェア」が利用者と開発者の協働に有効であった．

（2）構築中も仕様凍結せず，ビジネス変化に対応

すべてを凍結にするのではなく，事業領域ごとに半年の仕様凍結により継続的にリリースすることができた．利用者の満足度は，次項の顧客満足度でも確認することができる．また，二重開発コスト抑制により，見積り時試算比10億円の削減効果を得ることができた．

（3）大量データベースの移行策

全82ロットの稼働をプログラム移行のみにより実現できた．

6.2　プロジェクトでの成果と効果

（1）QCD評価

本施策の適用により，ハイブリッドアジャイル開発手法の確立と，プロジェクトにおけるQCD目標の達成，CS向上，ES向上の効果を得ることができた．2014年10月にプロジェクトを開始し，2017年5月のファーストロット稼働から2019年7月の最終ロット稼働までの全82ロットをすべて稼働し，Phase1を完遂した．82ロットを38サービスのサーブレット・マルチコンテナで運用し，開発環境・検証環境・ステージング環境・本番環境のビルドパイプラインを構築したことで，アジリティの高いICT基盤環境を実現している．

品質に関しては，ファーストロット稼働から最終ロット稼働までの間，システム停止を引き起こすような重大障害は発生していない．軽微な障害に関しては，小ロット開発開始当初は新規Java開発における社内のプロジェクト標準指標値を上回る発生状況であった．しかし，小ロット開発モデルの適用により，漸進型リリースによる繰り返し開発のプロセス改善と習熟度向上による品質改善の効果が得られた．本稼働後3カ月の品質指標値として設定した障害発生率0.05件／ks（キロステップ辺りの障害件数）に対し，1サイクル目平均0.08件／ks，2サイクル目平均0.05件／ks，3サイクル目以降平均0.03件／ksの結果を示し，62.5%の品質改善効果を得た．

コストに関しては，約15億円の改善効果を得ることができた．現新コンペアの協働体制による作業タスクと実施リスクの分担により，見積時試算値に対して約5億円のコスト削減効果を得た．加えて，小ロット開発による二重開発の抑制により，約10億円と試算された二重開発コストの抑止効果を得た．

（2）顧客満足度評価

協働体制の構築により信頼関係が醸成された点や，漸進型リリースによる成功体験共有の積み重ねにより，お客さま満足度の向上に結び付いた．プロジェクト開始当初は，お互いの主張をぶつけ合うような状態であったが，リプランを経て，小ロット開発で最初の稼働を迎えた時期から変化が見られた．プロジェクト開始初年度（2015年度）の総合評価6ポイント（10点満点）から，プロジェクト終盤（2018年度）には総合評価10ポイントへお客さま満足度が4ポイント向上した（図11）．

（3）メンバ満足度

富士通側プロジェクトメンバに関しては，自律改善活動を通じて主体的にプロジェクトに参画することができた効果から，社内意識調査のアンケート結果では全社平均を大幅に上回る結果を得ている（図12）．特に，自律改善活動と関連性の高い評価項目では，「意欲的な組織風土」はプラス12ポイント，「成長支援」はプラス12ポイント，「良好なチームワーク」はプラス9ポイントの結果を示している．

6.3　新たなノウハウ展開の評価

ユーザ側メンバとベンダ側メンバが1つのチームとなって協働体制で小ロット開発を推進したことが成功に繋がっていった．従来型のウォーターフォール開発では，課題発生時における責任の所在がベンダ側に片寄せになるケースが多いが，協働体制を築いたことにより数々の困難を乗り越えることができた．

漸進型リリースにより，複数ロットが稼働し始めると新たに課題を解決するためのさらなる施策を立案した．プロジェクトコストの削減と保守体制へのシフトである．

レガシーモダナイゼーションを実現するための数々の施策の実施にあたっては，条件変更の都度，プロジェクト予算の見直しが入り，コスト増の傾向にあった．これに対し，作業範囲の見直しを行うことでベンダ調達費用を低減することを狙った．加えて，お客さま情報システムでは，現行システムの保守運用を内製化しており，新システムでも保守運用を内製化する意向があった．如何にしてスムーズに開発体制から保守運用体制へシフトするかが課題であった．その施策として，82ロット分割の漸進型リリース計画の見直しを行い，一部ロットをユーザ主体で開発する協働型リリースモデルへのシフトを実現できた（図13）．

これは，これまで確立した手法が保守運用体制へのメンバに展開できたことを示している．

7．おわりに

本プロジェクトでは，ハイブリッドアジャイル型の実践手法を編み出し，超大規模レガシーモダナイゼーションプロジェクトを成功に導くことができた．2014年10月から本プロジェクトを開始し，2016年からのリプランを経て，2019年7月に全オンライン資産（Java資産規模9.2MStep）のモダナイゼーションを完遂した．

プロジェクトメンバが一丸となって，より良い手法を模索し続け，カイゼンし続ける姿勢はアジャイル開発の考え方に通じる．「アジャイルとは，常に改善している状態・より良いものを目指している状態」という定義を引用するのであれば，TMSをベースに常にカイゼンをし続けた結果がウォーターフォール開発にアジャイル開発のプラクティスを取り入れたハイブリッドアジャイルになっていたのは理解できるのではないだろうか．

本プロジェクトはユーザ側，ベンダ側が混成して1つの協働チームのWAを形成する．1つ1つのWAを広げ，全チームのWAが一丸となって，反復とカイゼンを繰り返し，プロジェクト全体へと実践知を共有するものである．平鍋と野中（2013）によると，「「学びを組織で共有する」というオリジナルのスクラムにある考え方は，アジャイル開発に抜けた部分として，日本のオリジナリティが生きる領域だとも筆者は考えている[10]」としている．本プロジェクトの実践は，学びを組織で共有し，常にカイゼンを継続するプロセスそのものであり，スクラムの上位概念ともいえるフラクタルを実践した結果であったと考えることもできる．

本プロジェクトでは，ウォーターフォール開発を基軸としてアジャイル開発の考え方を取り込むこととなった．しかし，それは，教科書を読んで適用したのではない．レガシーからの脱却という目的を達成するために，課題に対して，現場で悩み考え，カイゼンを繰り返し続け，最善と考えられる施策を講じてきた結果，アジャイル開発とウォーターフォールを有機的に融合したハイブリッドアジャイルの型を確立した．これは，アジャイル開発は元々日本の実践ノウハウを触媒として発展してきた経緯と重なるものがある（図14）．

今後に向けての本手法の課題は，規模特性やプロジェクト特性に依存しない汎用化された手法として再考が必要となる点である．本手法は，ウォーターフォール開発から抜け出せない日本の開発文化において，アジャイル開発へシフトするための試金石になると考えられる．超大規模のレガシーモダナイゼーションのみならず，中規模以上の開発プロジェクト一般に適用可能であると考えられるため，ほかのプロジェクトでの適用を検討し，本手法の有効性を検証したい．

筆者は現在，レガシーシステムからSalesforceを活用したWebフロントシステムに置き換える基幹再構築プロジェクトに携わっている．ここでは，タイムボックスを3カ月に区切り，基本設計から結合テストまでを小ロット標準開発モデルとした本手法の適用を実践中である（図15）．現在は開発工程の最中であるが，実プロジェクトの実践を通して本手法の有効性を検証していく．

今後，2025年に向けて本稿のようなレガシーモダナイゼーションのプロジェクトが多く発生することが想定される．本プロジェクトの実践知を体系化することで，「2025年の崖」に直面しているレガシーシステムからの脱却の一助となればと思う．さらに，ソフトウェア開発および，プロジェクトマネジメントの発展に貢献していきたい．

謝辞　本プロジェクトに参画したプロジェクトメンバならびにステークホルダの方々に感謝の意を表すとともに，本稿を執筆するにあたり，ご支援をいただいた皆さまに感謝いたします．