はじめに

「2025年の崖」が、経済産業省のDXレポートで提唱されてから、4年が経過した。2025年までにシステム刷新を集中的に推進する必要があるという主張に応え、システム再構築プロジェクトを立ち上げ、まさに佳境を迎えている企業が多いのではないだろうか。
筆者も昨年、基幹系システムとECサイトを統合し、マイクロサービス化するという、総工数6,000MMを越える大規模プロジェクトを終えたばかりだ。

改めて「2025年の崖」とは……

事実、多くの日本企業が持つ基幹システムは、部分最適の繰り返しで肥大化・複雑化し、老朽化している。10数年前、あんなに苦労してリリースした「新」基幹システムが、その後の保守開発、改善テーマ対応を繰り返すうちに、誰も抜本的に手が付けられない状態になり、場当たり的なつぎはぎ改修が増えていき……気付いたら巨大なバケモノに変貌していた、というITあるあるにギクリとする方も多いかと思う。
また、使われている技術も古く、保守運用を担う技術者の確保も困難になりつつある。そう遠くない将来、基幹システムの保守運用自体が困難になり、ビジネス継続できなくなるリスクすら秘めている。

＃産まれた頃はあんなにきれいでかわいかったのに……
＃昔は確かに「新」しかったけど……

マイクロサービス化では、このバケモノシステムを一つひとつひもといて、サービス分割（再定義）し、設計し直すので、非常に骨の折れるプロジェクトになることは想像に難くない。読者の皆さまも、相当な覚悟を持って立ち上げたはずだ。しかし、実際に検討を進めていくと、崖に到達する前に多くの落とし穴があることに気づき、回避したと思ったら別の落とし穴に落ちてはもがき苦しみ、どうにか脱出する……の繰り返し。想像以上の難易度に絶望しそうになる。

そしてこんな邪念が脳裏をよぎる

今やっていることはそもそも正解なのか……？

レガシーシステムをマイクロサービスアーキテクチャに再構築しろと言うのは簡単だ。しかし、一度立ち止まって考えてほしい。似たような再構築はこれまでにも何度かやってきたはずだ。果たして、そのたびに思うような効果が出ただろうか。
2000年代初頭ブームになったSOA（サービス指向アーキテクチャ）と何が違うのか。性能課題も出るし、共通ロジック化したほうが開発効率も良いし、 マイクロサービス化する必要性を感じない。

今のまま進めて2025年に間に合うのか……？

基幹システムが持つ機能は多いし深い。とても設計・開発が追いつかない。ようやくテスト工程に入ったと思ったら、現状業務で利用している機能の検討漏れや仕様の認識齟齬が多発して、追加設計・開発の繰り返し……いつになったらゴールにたどり着けるのだろうか。

やっぱりマイクロサービスは理想論でしかない。
こんなデスマーチ的プロジェクトでは誰も幸せにならない。今すぐやめるべきだ！
今だから言えるが、実際に筆者もそう思った。しかし、これは誤りだ。

確かにこの旅の難易度は高い。もしかすると会社史上最難関の長い道のりになるかもしれない。
故にゴールできれば、社史にも刻まれるレベルの英雄だ。

このコラムでは、筆者が経験した問題とその打開策について解説していく。
ひとりでも多くの方に「2025年の崖」を越えるヒントをつかんでいただければ幸いである。

「SOA」から「マイクロサービス」へ

2000年代初頭、SOAがブームになった理由は、当時もモノリシックで肥大化・複雑化したシステムに課題を抱えていた企業が多かったからだろう。機能をサービス分割するという方向性も類似しており、SOAはマイクロサービスと比較されることがことさら多い。

一言で表すなら、SOAは中央集権型、マイクロサービスは地方分権型だ。どちらもサービス単位にモジュールが分かれているので、画面から業務処理を実行したいとき、複数の処理を組み合わせたり、条件によって実行する処理を変えたりする必要がある。SOAでは、ここで発生するシステム間の通信をESB（Enterprise Service Bus）と呼ばれる基盤が一手に担い、処理の実行順序も制御する。一方、マイクロサービスにこのような基盤は無いので、画面側が責任を持って処理順序を制御し、処理ごとにPeer to Peerで通信する。SOAにおいて、ESBは幹線道路であり、渋滞や事故の影響は全面的に波及してしまう（単一障害点や性能ボトルネックになりやすい）というデメリットがある。

それならなぜ2000年代初頭にマイクロサービスが主流にならなかったのか。大きな要因は、クラウドサービスが存在していなかったことだろう。当時はサーバを実際に購入して、データセンターのラックに設置し、ケーブルをつないで、OSをインストールして、環境設定して、ミドルウェアを入れて、モジュールを入れてようやく動く……とにかく作業負荷が高かった！

現在はIaaSだけでなく、PaaSも充実していて、インフラ構築作業はコンソール画面でポチポチするだけで良くなった。サーバ台数を増やすのも容易だし、一部の処理が高負荷なら、システムを分割して、それだけ単独でハイスペックにするのもコンソール画面上からできてしまう。
特定の時間帯だけ高負荷になる場合も、サーバを追加稼働（スケールアウト）して、負荷が下がったら不要なサーバを停止（スケールイン）することも自動化できるし、利用に対する課金なので無駄がない。

サービスを分割すればするほどサーバ数が増える。さらに、サービス単位でDB（データベース）が分かれると、それぞれのデータを同時に処理できなくなり、いままでのモノリシックな基幹システムの性能に勝てなくなるという課題も生まれる。サービス間のデータを同期する機構を導入するといった解決策はあるが、これもインフラの構築負荷を上げるので、クラウドサービスが一般的でなかった時代は、「サービスの単位は小さくし過ぎないこと」がポイントとなり、SOAが市民権を得たのだろう。しかし実態は、当時盛んにおこなわれていた脱ホストが主の基幹再構築において、SOAがバズワード化していただけで、基幹システムのモジュールをサービス単位で真に疎結合化できていた企業は少ないように思う。

クラウドサービスが充実している現在において、マイクロサービス化を阻む技術要因は大幅に減少した。むしろ、再分化された多数のサーバを容易に運用し、コスト最適化できる点において、クラウドサービスとマイクロサービスはベストマッチしている。もちろん全てのケースに当てはまるわけではないが、大きな方向性としては正しいと言えるのではなかろうか。

マイクロサービス化の目的に立ち返る

「2025年の崖」を飛ぶまでの旅程を示す。目指すのはDXに取り組める環境を整えることだ。マイクロサービス化はその入り口に当たる。
DXには、柔軟かつ迅速に、変化への対応ができるシステムが求められるので、一つひとつのシステムが小さく分割されているだけでは不十分だ。機能に無駄が無く、個々のシステムが独立運営できる状態になっていなければならない。

前述したとおり、愚直に現行の基幹システムが持っている機能を全て可視化し、マイクロサービスに作り替えようとすると、とてもではないが2025年には間に合わない。ポイントは2つある。

マイクロサービスと相性の良いクラウドを使い倒そう

まずは「2: 最新クラウド活用による技術的負債の解消」に注目する。前章でもふれたが、マイクロサービスとクラウドは実に相性が良い。マイクロサービス化されたシステムを運用するのにクラウドは不可欠であり、マイクロサービス化がクラウドのメリットを最大限に引き出してくれる。
しかし、この旅は基幹再構築という団体旅行（大規模プロジェクト）であることを忘れてはならない。全員を乗せて崖を飛ぶのにジャンボジェット（オンプレミスのハイスペックなサーバ）は使えないし、離陸に必要な滑走路も足りない。今から設計・調達する時間もない。部隊を細分化し、複数の小型機を借りて（クラウドサービス中心のサーバ構成で）飛ぶことを考えなければならない。

要件定義の段階で基幹システムを身軽にしておこう

次に「3: レガシーIT資産の大幅な圧縮」に注目する。今実装しようとしている機能は本当に必要なのか、要件定義の段階で再確認しておこう。基幹システムの機能が減れば、プロジェクト全体の設計・開発工数も難易度も下げることができる。
不安になって旅行バッグにモノを詰め込みたくなる気持ちも分かるが、結局使わずに終わることが多いのも事実。思い切って断捨離しよう。意外と何とかなるものだ。

マイクロサービスは銀の弾丸じゃない

上記と合わせて、マイクロサービス化は今日本企業が抱えている課題をすべて解決してくれるような技術要素ではなく、あくまでも「設計思想」だということを申し上げておきたい。のべつ幕なし、とにかく機能を細分化すれば良いということではない。どんなシステムにおいても、インプットは業務設計だ。基幹システムをマイクロサービス化するということは、つまり、企業のコア業務に対して、BPR（Business Process Reengineering）をすることと同義なのである。

それは、システム部門おひとりさまでこの旅のゴールにたどりつくことはできない、ということを意味している。事業部門と熟考を重ね、共に苦労を分かち合いながら、二人三脚でこの旅を乗り越えていただきたいと切に願う。

また、この旅は基幹再構築という団体旅行（大規模プロジェクト）であるため、ツアーコンダクター（プロジェクトマネージャ直轄の共通チーム）も重要な成功要因の一つになる。マイクロサービスは独立したチームで設計・開発するが、単独での勝手な行動は全体計画・進捗を乱し、プロジェクトを簡単に破綻させてしまうだろう。

筆者は基幹のマイクロサービス化プロジェクトにおいて、以下4つの教訓を得た。次回以降、それぞれの具体的な考え方や活動内容について紹介していこうと思う。

• 納得感を持って機能を断捨離しよう
• マイクロサービス化はBPRプロジェクトと心得よう
• 縦割りのスピード感・柔軟性と横串の品質・効率性を両面享受しよう
• 無理せず段階的移行も検討しよう

執筆者情報

MSシステム事業部　深沢 直輝：
2006年に野村総合研究所に入社。メーカー・卸・小売・通信・教育業界等に対して、IT戦略立案～システム化計画、要件定義、システム開発～リリースに従事。専門はクラウドサービスを活用したシステム化計画、業務改革の推進。

次のページ：マイクロサービス化で2025年の崖を飛べ（中編）

DX時代のシステム導入最前線一覧ページへ

産業ITソリューションNewsletterのご登録（別サイトへ）

産業ITソリューションサイトへ