少し専門的テーマ：マイクロサービス方式システムは「救世主」です！！

【このテーマの目的・ねらい】
目的：マイクロサービス化は「２０２５年の崖」の救世主になります。
　　　是非、研究してください、という提言です。
ねらい：「２０２５年の崖」を回避しましょう。
ーーーーーーーーーーーーーーーーーーーーーーー
以下の構成で、解説いたします。
１．「２０２５年の崖」の問題提起

２．「温泉旅館」の改築が必要

３．システムの作り直し・再構築の目的

４．拡張性・保守性の抜本的改善の対策

５．マイクロサービス化の効果

６．マイクロサービス化の成功要因・実現ノウハウ

１．「２０２５年の崖」の問題提起

ご承知のように、

２０１８年９月に発行された経済産業省の「ＤＸレポート」では、
現在のレガシーシステムを放置すると毎年１２兆円のロスが発生する

という問題提起がされています。

システムが大きな塊の岩盤状態になっていて、

どこをどう直せばよいかがすぐに分からない状態になっているのです。

この状態は「スパゲッティ状態」「田舎の温泉旅館スタイル」

と言われたりもしています。

そのために、

手を入れる際にどこをどう直せばよいか分からないだけでなく、

誤って別の部屋の改修をしたり、

直さなくてもいいところに手を入れて壊してしまうというようなことが

起きているのです。

そういう状態であるために、余計なコストがかかるだけでなく、

経営環境の変化に対応して、ビジネスを変革していこうとする場合の

足かせになるというのが，ＤＸレポートの問題提起です。

２．「温泉旅館」の改築が必要

そこで、温泉旅館の改築が必要なのですが、

システムは経営にとって必須ですから、

営業しながらの改築が要求されます。

余裕のある企業であれば、現在と別の場所に新築をして

完成と同時に引っ越すという方式（ビッグバン方式と言われます）

も考えられます。

これができるのは、メガバンクくらいのものでしょう。

そこで、多くの企業では、少しずつ改修していくという方法が

現実的な選択肢です。

前掲の「ＤＸレポート」でもこう述べています。

ーーーーーーーーーーーーーーーーーーーーーーーー

3．7 　刷新におけるマイクロサービス等の活用

既存システムの刷新となると、

大規模・長期なプロジェクトとなる恐れがある。
他方で、3.3.1 で述べたように、

ビジネス上頻繁に更新することが求められる機能につい ては、

刷新後のシステムにおいて、新たなデジタル技術が導入され、

ビジネス・モデルの変化に迅速に追従できるようになっている必要がある。

すなわち、システムがモジュール化された機能に分割され、

短いサイクルでリリースができる状態にしていくことが求められる。 

これによって、ビジネス上頻繁に更新することが求められる機能については、

システム刷新における移行時において、

マイクロサービス化することによって細分化し、

アジャイル開発方法により段階的に刷新するアプローチも考えられる。

これにより、仕様を明確にできるところから開発を進めることとなるため、

刷新に伴うリスクの軽減も期待できる。 

このような方法については、まだ先行事例も少ないため、

実証的に検討を進めることも考えられる。

ーーーーーーーーーーーーーーーーーーーーーーーーーー
３．システムの作り直し・再構築の目的

そこで、システムを作り直す目的は、以下となります。

１）その時点の新しい経営ニーズを実現する。

２）できあがったシステムの拡張性・保守性を抜本的に高める。

１）は当然のことですが、

今後とも常にシステムに対する経営ニーズが発生しますので、

２）の条件がより重要だということになります。

４．拡張性・保守性の抜本的改善の対策
現在のシステムが、「田舎の温泉旅館」になってしまった遠因は、

３０～４０年前の「システムの統合化」の「布教」にあります。

見境なく何でも一つにしてしまいました。

統合で大きな塊にしてしまったために、

１）塊の内部構造が見えない。

２）変更に対して広い範囲が影響する

ようになったのです。

その塊を的確に見るのは人間にはムリです。

そこで、塊の内部を見るために

レントゲン、ＣＴ、ＭＲＩのようなツールが開発されています。

ある面で、「マッチポンプ」です。

拡張性・保守性を高めるには、

その統合をやめ分割をすることが有効な対策となります。

適切な分割をすれば、変更すべき部分が限定できます。

ただし、体系的・整合的な分割である必要があります。

そうでないと、どの部分を変更すべきかの判断ができない

ことになってしまいます。

この課題を解決する方法が、

「マイクロサービス化」でなければならないのです。

実は、拡張性・保守性を高める対策としては、

拡張・保守作業を容易化するための手法があります。

最近は「ノーコード化」ツールとか言われますが、

これまでは、「第４世代言語」「超高速開発ツール」とか言われた

プログラムの自動生成を行うツールです。

これらのツールは、人間が作成するシステムの仕様から

プログラムを自動生成しますので、開発作業の効率化になります。

「マイクロサービス化」と「ノーコード化」の効果の

評価はこうなります。

それぞれが実現する効果は以下のとおりであると想定されます。

新システムのアーキテクチャ	期待できる効果
マイクロサービス化	影響調査・テスト工数削減
ノーコード化	変更仕様定義・コーデイング・テスト工数削減

両者の効果の大小は状況によっても異なりますが、
一般的には前者の効果の方が大きいと思われます。

ＪＵＡＳ等の調査では、分析、修正、テスト、その他の比率は

３：３：３：１となっています。

この比率によれば、マイクロサービス化によって影響する工数は６で

ノーコード化によって影響する工数は３となります。

５．マイクロサービス化の効果

ＪＩＳＡ発行の「情報サービス産業白書２０１９」

に掲載された「２０１８年度米国視察調査報告」には

以下の記述があります。

「１０分の１になる」は誇大だとしても、

　何分の１かにはなりそうです。

視察対象の多くの企業でマイクロサービス化に積極的に取り組んでいた。
Staples社は，Amazon対応のスピードと柔軟性に対応すべく
マイクロサービス化を進めていた。
現在７００名の開発要員は、すべてマイクロサービス化すると
大きく減少する見込みであることを確認することができた。
「１０分の１程度ですか」という質問に「そんなに必要ない」と返答された。

６．マイクロサービス化の成功要因・実現ノウハウ
上掲の米国視察調査でも、

多くの企業がマイクロサービスを有効活用するための工夫がされている

ことが報告されていました。

残念ながら、日本では未だにそのようなノウハウの開示がされていません。

当社がある企業と共同して研究したところでは、

以下の領域に対する実施ノウハウが必要であることが判明しています。

マイクロサービス方式実現の成功要因

ビジネス要因	内容
１．   適切な対象選択	どのシステム、どのサブシステムから開発すべきかの判断基準
２．   適切なサービス単位設定	どの単位に「サービス」を設定すべきかの判断基準
３．   適切な移行方式実施	既存の「資産」を「サービス」に乗せる方法 のガイド

 

技術要因	内容
４．適切な技術選択	「サービス間のメッセージ通信方法」「同期通信の方法」「非同期通信の方法」「処理順序指定方法」等についてのガイド
５．適切なデプロイ方式設計	信頼度と容易度のバランスで手法を選択するガイド
６．サービスネットワーク状況把握システム構築	全体構成を把握するためのサービス間の関連図を作成する方法のガイド
７．適切な監視システム設置	適切なメトリクス設定・ログ記録等によるシステムの運行状態を把握するシステムの設計ガイド

われわれが研究した経験では、こういうことが言えます。
これらが、マイクロサービス化成功の課題であることを認識すれば、
その場になって必死に検討すると、それなりの解が得られる。

前掲の海外調査報告にも、以下のような例が紹介されています。

マイクロサービス化に関する技術的な課題についても、
さまざまな現実的な手法あるいはツールが生み出されている。

例えば、Staples社は、
現行システムから新システムへの移行期間中に発生する
新旧両システムのダブルメンテナンス問題について、

極めてリーズナブルな対応方式をつくり出している。

新システムで使う旧システムにあるデータ項目に関して、
旧システムのデータベースの該当項目を
新システムから更新するツールを開発した、のである。
これによりメンテナンスは新システムのみで行うこととなり、
新旧システムのデータの不整合を発生しないようにしている。

また、マイクロサービスの技術課題の一つに
「同期処理の非同期処理への移行」があるが、
これに関しても必ず方法があり、
すべての処理はマイクロサービス化できると強調している人もいた。

詳細なパターンを含めて確認する必要があると考えるが、
サービスレベルの見直しを含めた処理方式の見直しを行えば、
大半の場合は対応可能な方式が存在するのではと思われる。

スピードや生産性向上のメリットも含めて、
全体としてリーズナブルな対応方式を考えることが、
この課題への対応の基本だと考える。

さらに、マイクロサービス化により多くのマイクロサービスの管理や
ＡＰＩの管理などが必要となるが、
これに関してはＡＰＩ-ＧＷなどのマイクロサービスを支援する
ツール群がどんどん提供されているのが現状である。

「案ずるよりは産むが易し」です。

是非、「２０２５年の崖」回避にチャレンジしてください。