マイクロサービスに集まる期待
「マイクロサービスが流行りらしいけど、当社も導入すべき？」「DX推進のためにマイクロサービスを検討したいが、何をしたらいいの？」最近、このように悩まれた方はいないでしょうか？マイクロサービスとは、複数の小さなサービスが、それぞれ独立して動作するアーキテクチャです。一方で、単一の大きなシステムのことをモノリスと言います。既存システムの多くはモノリスといわれています。長く運用されてきたレガシーシステムでは、保守性が悪化して開発に時間がかかるという悩みをよく聞きます。そこで、システムを小さく分割してマイクロサービスにすれば保守性を向上できると、近年ますます期待が集まっています。
マイクロサービスの幻想と現実
マイクロサービスには、保守性やスケーラビリティの向上など大きなメリットが存在します。しかし、マイクロサービスは必ずしも最善の選択肢とは限りません。実は、マイクロサービスは一部のプロジェクトではオーバースペックとなりかねないのです。そのため「なぜマイクロサービスにしたいのか？」マイクロサービスで達成したい目的を事前に明確にする必要があります。その上で、達成したい目的とマイクロサービスのメリットが合致し、コストをかけるだけの効果が得られる場合のみ、採用が推奨されています。
マイクロサービスの移行戦略
モノリスからマイクロサービスに移行する際、一度に移行すると失敗リスクが高まります。そのため、システムの一部をマイクロサービスとして切り出し、これを段階的に繰り返す移行戦略が推奨されています。これは通常、ストラングラーパターンと呼ばれます。また、既存システムには品質の問題が存在する可能性や、既存システムと新システムでは利用するテクノロジーが異なる可能性が考えられます。そのため、2つのサブシステム間に「連携部品」を設けて、一方のシステム設計やテクノロジーがもう一方に影響を与えないようにすることが重要です。（連携部品は、一般的に破損対策レイヤー、グルーコードなど様々な呼ばれ方をします。）
プログラム解析を活用して投資対効果を評価
段階的な移行戦略を採用しても、マイクロサービスへの移行には大きなコストを伴います。そのため、経営層への説明は重要です。経営層に対しては、マイクロサービスの技術的なメリットだけでなく、ビジネス上の投資対効果を語ることが重要です。そして経営層への説明は、開発が始まるよりも前のIT企画工程で行われます。しかし開発前のIT企画工程では設計書がまだ存在しないため、必要なコストや得られる効果を正確に把握することが困難です。そのため、いざ開発が始まってから「コストが予想以上にかかった」「効果が期待通りでなかった」という問題が起きかねません。そこで、鍵となるのがプログラム解析です。私たちは、プログラム解析を使ってソフトウェアの構造を明らかにし、IT企画工程において投資対効果を評価する方法を研究開発しています。
既存システムから新システムを切り出す際、投資対効果は次の手順で試算します。
- 1．プログラム解析を使って、システムの依存関係を可視化
- 2．システムの依存関係をもとに、コストを試算
- 3．システムの依存関係をもとに、効果を試算
- 4．試算したコストと効果をもとに、投資対効果を求める
以降、システムの依存関係をもとにコストと効果を試算する考え方を説明します。
コスト試算
コスト試算では、新システム、既存システム、連携部品の開発工数の合計により求めます。新システムと既存システムは、切り出し前のシステム規模と生産性により、開発工数を求めます。一方で、連携部品の開発工数の見積もりに、プログラム解析の技術を使います。本稿では、連携部品の開発工数の見積もり方を中心に説明します。
連携部品の開発工数は、次の式で求めます。
連携部品の開発工数 ＝ 依存関係の本数 × （1本あたりの実装行数／生産性）
下の図ように、「新システム」を「既存システム」から切り出すケースを考えます。このとき、新システムから既存システムへの依存関係が分断されます。例えば、切り出し前は関数呼び出しでつながっていた場合、切り出し後はネットワーク経由の通信となります。そのため通信方式を変換するための連携部品を作るコストが発生します。「1本あたりの実装行数」と「生産性」は、既存システムと新システムのアーキテクチャにより変動します。例えば、既存システムがメインフレーム上のCOBOL、新システムがクラウド上のJavaのような場合、連携部品の開発コストは大きくなるでしょう。これらの試算は、過去の案件データを元に試算したり、PoCで連携部品を作ってデータを集めたりすることで行います。
システム間の依存関係を解析するには、プログラム解析の技術が必要です。プログラム解析を用いて依存関係を明らかにすることで、システム切り出しによる連携部品開発のコストを試算します。
効果試算
効果試算では、システム切り出しによる保守開発工数の削減を試算します。保守開発工数を減らすことは、開発アジリティの向上や開発コストの削減につながります。
保守開発工数の削減率は、次の式で求めます。
保守開発工数の削減率 ＝ 1 － （切り出し後の影響範囲／切り出し前の影響範囲）
影響範囲とは、一部のプログラムを変更した場合に、その変更が他のプログラムにも影響を及ぼす範囲のことを指します。この影響範囲が広いほど、プログラムを理解しテストする範囲が広がるため、保守開発工数も増大します。実際に、影響範囲をもとに見積もった保守コストは、実際の保守コストと高い相関関係があると言われています。システムの切り出しは、この影響範囲を縮小することが可能です。
下の図のプログラムA, B, C, DがあるシステムからプログラムCとDを切り出す場合を考えてみましょう。切り出し前は、プログラムDを修正すると影響範囲はAからD全てに及びますが、切り出し後は影響範囲がCとDだけに限定されます。したがって、システム切り出しにより影響範囲がどれだけ縮小するか明らかにすることで、保守開発工数の削減率を試算できます。
このようなプログラム間の依存関係や影響範囲を解析するために、プログラム解析の技術を活用しています。
さいごに
本稿では、マイクロサービスにすべきか投資対効果をもとに判断が必要なことを説明しました。またプログラム解析を使って投資対効果を評価する方法についても紹介しました。私たちNTTデータでは、マイクロサービス導入やDXに向けたロードマップ・計画策定をご支援する、コンサルティングサービスを提供しております。また、お客さまのシステム状況を正しく把握してより良い提案につなげられるよう、プログラム解析の研究開発に取り組んでいます。最近の研究成果として、ソフトウェア工学の学会である「ソフトウェアエンジニアリングシンポジウム2022」（※）にて、プログラム解析を活用した投資対効果の評価方法を発表しました。研究開発はまだ初期段階ですが、今後も実用的なソフトウェア技術の研究開発を続けていきます。マイクロサービス導入やDXに向けた具体的なご相談や、ソフトウェア研究に関する情報交換など、ご興味のある方はお気軽に「お問い合わせ」ボタンよりご一報ください。
