モダンなアプリケーション開発へ、移行戦略の「6R」とは？
レッドハットではモダナイゼーションの移行戦略を「6R」と分類している。アプリケーションを廃棄する「Retire」、維持（塩漬け）する「Retain」、新しい筐体へアプリケーションを移行する「Rehost」、アーキテクチャの変更やコードの大幅な変更を必要とせず最適化する「Replatform」、開発方法やアーキテクチャを変更しクラウドネイティブ化する「Refactor」、SaaSへの移行やアプリケーションの一部をサービス（as a Service）に置き換える「Repurchase」の6つ戦略だ。
「Retain」や「Rehost」なら、少ない労力で移行が可能だ。一方、大胆に作り替える「Refactor」では、大仕事になる分効果も大きい。レッドハットでは、これら「6R」を学ぶことができる実践的なハンズオンのワークショップ「Modern App Development（MAD）Roadshow」を提供している。ここで得られる知識を活かせば、モダナイズの成功が見えてくるだろう。しかし、現実はそう簡単ではない。その理由について、暮林氏は「複雑で混沌とした状況を踏まえて交通整理するのがモダナイゼーション」と説明する。
モダナイゼーションのプロジェクトは「ほぼジオゲッサー」と暮林氏は言う。ジオゲッサーとは、ブラウザゲームの1つだ。プレイヤーはランダムにGoogleマップ上のどこかの地点に落とされ、周囲に見えるGoogleストリートビューの景色から現在地を当てるルールになっている。モダナイゼーションも、ジオゲッサーのように現在地を探すことから始める。
モダナイゼーションの方向性を定めていくとき、モダナイズ対象を4象限に分けて現状を整理する。下図のように、対象領域が曖昧であると図の上部に、既存領域に強く依存していると左側に分類される。
図の左上は既存かつ曖昧な領域で、範囲が広くてどこから手を付けたらいいか分からないという状態にあたる。ここでは「ドメイン駆動設計（戦略的DDD）」と呼ばれる手法が使われる。図の左下は、既存で対象が明確なので「アプリケーションシンプリファイ」という手法を利用する。図の右上は曖昧で新規寄りの領域で「アジャイルアプローチ」を使う。また、図の右下は新規システム開発になるので、モダナイゼーションからは対象外となる。順序としては左上のドメイン駆動設計から始めて、アジャイルアプローチかアプリケーションシンプリファイに移ることが多い。
現在地の把握に必要な「戦略的ドメイン駆動設計」とは？
4象限のスタート地点にあたるドメイン駆動設計から話を始めていこう。ドメイン駆動設計は、既存領域が混じり、広範囲に及ぶモダナイズだ。Eric Evans氏が考案したドメイン駆動設計（DDD）には、大きく分けて「戦略的ドメイン駆動設計」と「戦術的ドメイン駆動設計」の2つがある。日本だと戦術的ドメイン駆動設計が有名で、オブジェクト指向言語の設計方法として広まった。しかし本来は、戦略的ドメイン駆動設計の方が重要だ。
戦略的ドメイン駆動設計とは、企業の事業戦略を考慮したモデリングパターンである。暮林氏は「大局観をビジュアライズするもので、ドメイン駆動設計の神髄に近い」と言う。ドメイン駆動設計を解説する『実践ドメイン駆動設計』の著者、Vaughn Vernon氏は次のように語っている。「飛行機からの眺めは本当に素晴らしいが、自分が一体どこにいるのか分からず、どうやって移動したらいいのかすら分からない。DDDを使いこなす人たちは地図上にコースを定め、ナビゲーション装置もチューニングしているようなものだ。その他大勢の人たちには、この安心感がない」
実際のモダナイゼーション案件に照らして考えてみよう。ここでは事業がA、B、Cと裏方Dがあるとする。それぞれの事業の売上規模、成長の度合い、組織における位置づけや相関などから対象となるシステムがビジネス全体のどこにポジショニングしているか把握することで全体像を作ることができる。これがEvans氏の言う「現在地を把握している」だ。地図があれば向かうべきTo Be像が明確になり、どのシステムに変更を加えなくてはならないかが明確になる。
もし地図がなく、現在地不明のままいきなり開発を進めたらどうだろう。請負開発でよく起こりうる状況だが、開発を進めていくうちに周囲の不都合な事情や環境が見えてくるだろう。例えば「基幹システム変更の事業Bへの影響に関するクレーム対応は、事業Aから受注しているからスコープ外」とトラブルになる。後から気づいても後の祭りだ。こうした混乱を避けるために「地図を描いてから始める」ことが必要で、ドメイン駆動設計の「戦略的」の方が大事だと分かる。
なおレッドハットでは「Ansibleトレイルマップ」という手引きを公開していて、こちらはITプロセスのモダナイゼーションの道のりを飛行機ではなく登山の地図に例えている。
戦略的ドメイン駆動設計では、全員が全体像を把握できることが大きなメリットだ。そしてドメインで分けた領域に名前を付けられる。暮林氏は「日本語の“命名”はすごい言葉だと思います。名前を付けることで対象に命を与え、認識できるようになるからです」と言う。モダナイズしたい領域を特定し、すでにシステム化されていたらアプリケーションシンプリファイへ、新しくシステム化すべきならアジャイルアプローチへと、次の方向性が見えてくる。
ドメイン駆動設計の次のステップは？──「アプリケーションシンプリファイ」と「アジャイルアプローチ」
ドメイン駆動設計の次のステップを見ていこう。まずはアプリケーションシンプリファイだ。かつては既存のレガシーシステムが抱える技術的負債を出発点として、ルール駆動開発を行っていた。このテーマは2020年と2021年のDevelopers Summitで発表した内容なので今回は割愛する。興味があれば資料を参照してほしい。
現在ではアプリケーションシンプリファイへと手法が昇華している。まず「Clarify」であえて既存のソースコードを見ず、現行のビジネスプロセスの中核からビジネスロジックモデルを洗い出していく。次に「（Over）Simplify」で洗い出したビジネスロジックだけをシンプルアプリケーションとして実装する。そして「Satisfy」では新旧システムの両方で処理した結果を比較して、枝を実装していく。新旧の一致率（品質）が満足いくものになるまで、比較と実装を繰り返していくという流れになる。
「Clarify」では「あえてソースコードを見ない」のが大きなポイントだ。ある程度成熟したビジネスを例として考える。典型的な顧客は75％で、その顧客をカバーするソースコードの割合は25％、それ以外の顧客を含めても使われているソースコードは全体の40％だったとする。もし利用するコードが40％しかないと最初からわかっていたら、ソースコードすべてに目を通す必要があるだろうか。まずは主要な顧客を広くカバーする25％のコードを開発して、後で足りない部分15％（とはいえ実際この15%は目に見えない）を追加していこうという考え方が重要になる。
続いて、アジャイルアプローチが必要な場合に進もう。多くの役員は「成長過程のビジネスが既存顧客や基幹システムのデータにアクセスできたらシナジーが生まれるのでは」と期待する。そこで新システムのSoEは、レガシーシステムのSoRのデータベースに直接アクセスするか、APIでアクセスしたいと要請する。大抵は交渉が難航し、折衷案としてSoRのデータを非同期でSoEに渡すことになる。これでは鮮度の悪いデータが社内に共有されてしまう。
ここでは、レガシーシステムと新システムをクラウドネイティブにつなげることが求められる。このテーマはレッドハットが提供している「マイクロサービスEssential」や「Integration Dojo（インテグレーション錬成道場）」といったワークショップで詳しく学ぶことができる。
レガシーシステムとクラウドネイティブなシステムの適切な接続や、シンプルなアプリケーションを開発が実現されると、モダナイズは最終形に近づいてくる。新旧どちらのシステムも同じデータ基盤上に乗り、疎結合に相互に連携できて、ビジネス的な効果も出せる状態だ。
アジャイルアプローチではマイクロサービスにとらわれず、システム間の接続の方法に注力した方が良い。また、マイクロサービス化を一気にやろうとすると、ウォーターフォールな手法で分割することが目的になってしまいがちだ。暮林氏は「ドメイン駆動設計を駆使して都合よく切れる場所を判断し、切っては繋ぐことを繰り返していくのがいいです」と推奨する。
またアジャイルアプローチはアジャイル開発を含むものの、アジャイルそのものではないことも気をつけておきたい。もしアジャイルのレベルを高めたいのであれば、レッドハットが提供する「Open Innovation Labs」というハイエンドなアジャイル支援サービスを検討してもいいだろう。
最後にそれぞれの手法を活用する段階を補足しておこう。「自分がどこにいるのか分からない」というモダナイズの超初期にドメイン駆動設計を使う。次に新規をどう接続するかを考える時にアジャイルアプローチを使い、これを念頭におきながらアプリケーションシンプリファイを進めていく。
暮林氏は「それぞれのアプローチは必要とされるピークの段階が違いますが、ピークを超えたらやらなくてもいいのではなく、ピーク時にやらないと手遅れになると考えてください。モダナイゼーションの段階に応じて効果的なものを実践していきましょう」と呼びかけて講演を締めた。
