齋藤：
ただし、マーティン氏の定義が絶対的なものではなく、それを満たさないとマイクロサービスではないということではありません。もちろん、グローバルスタンダードな標準として定義されているわけでもありません。あくまで概念として参考していただき、ポイントを押さえた形で導入いただくのがよいかと考えています。

鶴田：
マイクロサービスを検討する上でのひとつのポイントは、「APIとデータベースの分離」です。「APIで個々のサービスでしっかり分割する」、そして、「必要なデータはサービスの中で閉じて持つ」、この2つを満たしていることが重要となります。先ほどの話の通り明確な定義はありませんが、だからといって、単にAPIゲートウェイを入れただけでマイクロサービスを適用できているというものでもありません。そこは注意が必要です。

齋藤：
「APIとデータベースの分離」以外でも、技術的観点で重要なポイントがあります。それは、ビジネスの要求に応じてリソースを柔軟に増減できることです。例えば、クラウドを使うことで、クリックひとつでサービスをすぐに立ち上げることも、すぐに潰すこともでき、リソース増減の要求に柔軟に対応できます。

鶴田：
マイクロサービスが有効なのは、不確実性が高く変化しやすい領域です。具体的には顧客との接点にあたるシステム部分が該当することが多いです。企業の目的や状況にあわせてターゲットや優先順位を間違えないように気を付けましょう。

齋藤：
よく誤解される方がいらっしゃいますが、マイクロサービスが複雑化したレガシーシステムの課題をなんでも解決できるわけではありません。当然、向き不向きがあります。変化に強いのがマイクロサービスの強みですが、その分サービスが多く存在するため、管理が煩雑になります。実際にいくつもの企業事例を見させていただいた実感でもありますが、全てのシステムをマイクロサービス化するのは現実的ではありません。どこをマイクロサービス化して、どこを既存システムのまま残すのか、棲み分けをどうすべきか検討していくのがポイントになります。

過去に支援した事例では、既存システムにできるだけ手を加えずに、一部分だけをクラウドでマイクロサービスを開発し、既存のホストとの連携機能を整備しました。こうした既存システムとマイクロサービスとの連携は費用対効果の高い効果的なやり方だと考えています。

鶴田：
マイクロサービス化を実施する上で、まず検討すべきはPoCによる効果検証です。ちょっとだけ試してみるというスモールスタートの考え方が望ましい。マイクロサービスを初めて大規模に導入したと言われる「Netflix」も、PoCから始めています。大きなシステムを小さなサービスに分割することは難しいため、一足飛びにいきなり何十億円をかけて開発するのではなく、アジャイル的に小さくトライアンドエラーを繰り返し、継続的に活動を続けていくことが肝要です。

齋藤：
ただし、ここでネックとなるのが予算の問題です。トライアンドエラーを繰り返すと予算が固まりません。また、マイクロサービス化が、システムのコスト削減に直結するわけでもありません。コスト削減を主目的においてしまうと、間違った方向にいってしまうリスクがあります。実際、過去の事例をみても、明確にコスト削減につながったものはほとんどないのが実情です。
マイクロサービス化のメリットは、変化への迅速な対応力、「スピード・アジリティ」の獲得です。スピード・アジリティを獲得することで、どんなビジネス上のベネフィットを得られるのか、そういったスピード・アジリティの獲得に関するKPI設定を行うとよいでしょう。

鶴田：
予算に関しては、社内稟議の話もあり、KPI設定の問題とは別に考えていかなければならない難しい問題です。ひとつの考え方として、SAFe（Scaled Agile Framework）という大規模なアジャイル開発のフレームワークが参考になります。SAFeでは、通常、不確実性の高い内容に対してフレキシブルに対応できるよう「いつでも引き出せるお財布」を用意します。しかしながら、こうした予算の組み方を検討するには、経営層レベルの意識改革も含め、会社組織全体の枠組みで考えて取り組んでいかなければなりません。IT部門に閉じない新しい予算の組み方まで踏み込んで考えるのもよいでしょう。

齋藤：
マイクロサービスは、不確実性が高く変化しやすい領域で迅速にシステムを改修できるものです。当然ながら、開発手法もそれに見合った形にしていくことがセットになります。マイクロサービスの実装では、従来のプロジェクト型の開発ではなく、プロダクトを意識した開発が必要です。

鶴田：
従来型のシステム開発の場合、「作って終わり」という感覚があると思いますが、本来は、サービスを改善し続けるために、開発を継続させなければなりません。そうなると開発体制やマネジメントのあり方も変わってきます。それが、プロダクト開発です。

従来のウォーターフォール開発では、要件定義から基本設計、詳細設定と進むにつれて関わる人員が増えていき、システムリリースした瞬間に開発チームも解散する形になりますが、プロダクト開発では、そういう山谷はありません。人の集め方やエンジニアのリソース管理も見直していかなければならないでしょう。

鶴田：
やはり、まずはアジャイル開発を始めるのが先だと思います。

齋藤：
マイクロサービスは、アジャイル、CI/CD、DevOpsのような流れをくんだITアーキテクチャーです。サービス間連携のオーバーヘッドが増えてしまうデメリットもあるため、選択肢のひとつとして考えておくのがよいでしょう。マイクロサービスを導入すること自体が目的となってしまわないよう進めていくように注意すべきです

鶴田：
そうですね。マイクロサービスありきで考えるのではなく、どれぐらいのスピードが要求されるかなど、最終的に実現したいことからアーキテクチャー設計を考えていった方がよいと思います。

例えば、マイクロサービスのもつ「システムのモジュール化・独立性」は、マイクロサービスでなければできないというものではありません。マイクロサービスの対局にあたるモノリスシステムでも、「モジュラーモノリス」というアプリケーション内でモジュール化して独立性を高める考え方を採用することで、マイクロサービスのように1つのチームが他チームの動きを気にせず単独でシステムをリリースでき、開発スピードを高めることが可能です。

齋藤：
アーキテクチャーの観点だけでなく、開発手法や体制も含めて総合的にスピード・アジリティを高めていくとよいでしょう。
また、顧客や市場の動きも注視していく必要があります。システム側が変化に強くなったとしても、ただシステムの中身が変わっただけではビジネス側から見ると何も変わりません。顧客がそのシステムやサービスの使い勝手をどう感じているのか、要望を拾い上げて要件に落とし込むことで、システム改善につなげていくのが理想的です。そのため、顧客や市場の動きを素早く察知して追従できる体制・仕組みが求められるのです。

鶴田：
成功例としては、ZOZOやメルカリなどWeb系の企業があげられます。
Web系の企業は、既存システムが少ないため動きやすいという利点があります。もともとITサービスが事業の主軸にあるので、ビジネスとITの方向性が合致していることも成功要因として大きいと考えます。ユーザーからのフィードバックも受けやすい環境なので、マイクロサービスを導入しやすいです。

齋藤：
大企業の場合、既存システムの影響が大きいので、マイクロサービスの成功事例は少なく、まだまだ道半ばの企業が多い印象です。PoCの段階でとん挫してしまったり、既存システムの改修に時間がかかって取り組みが進まなかったりといったケースも珍しくありません。

鶴田：
既存のシステムはしがらみも多く、たくさんの制約事項があって身動きがとれなくなってしまいがちです。事業戦略が許すのであれば、新しい会社とシステムをスモールスタートで一から作った方が、結果として時間もコストもかからない場合があります。実際、デジタルサービスを提供する新会社を設立して、新しいシステムを一から作っている企業もあります。

齋藤：
DXのITアーキテクチャーでは、市場の変化にキャッチアップできるスピード・アジリティの獲得が肝です。マイクロサービスはこれを実現するための有効な手段のひとつです。機能単位で実装・リリースを臨機応変に行える反面、サービス間連携のオーバーヘッドが高くなってしまうなどのデメリットもあるため、どの部分にどう適用するのか、目的やゴールをしっかり考えた上で、プロダクト開発を進めていくことをおすすめします。

鶴田：
マイクロサービスは、小さな単位のサービスを少人数のチーム体制で開発・運用すべしと言われていますが、実際に、どの程度の小さいサービスに分割すべきかは、システムの種別に依存するため職人技が必要になります。一般的には、ドメイン駆動設計という、ドメインごとに、サービス、役割を切っていくという考え方がありますが、抽象的であり概念を理解するだけでも難しいです。
いきなり構築するのは不可能なので、外部の知見を入れて、トライ＆エラーを繰り返しながら進めていくのがスマートなやり方だと考えます。

NRIでは、現行システムのマイクロサービス化を支援する「マイクロサービス化支援サービス」を行っております。本サービスにあたり、数多くの企業支援などを通して得たドメイン駆動設計やサービス分割、移行手法などの知見をベストプラクティスとしてまとめており、幅広い業界・業態で活用できるよう体系化しています。
https://www.nri.com/jp/service/scs/dx/digital_architecture