マイクロサービスアーキテクチャの適用候補となる企業のデジタルビジネスプラットフォームは、

• 利便性や効率性を高めるための人と人とのコラボレーション
• ビジネス機能を組み合わせるオーケストレーション
• ビジネスを生み出す場となるクリエーション
• 需要者と供給者を結ぶマッチング

の4つに分類できる。共通するのは、変化に対する俊敏な追従や新機能の継続的な追加が必要な点だ。

　ユーザー層を軸にすると、デジタルビジネスプラットフォームは以下3つのスコープで考えられる。

• 社内ユーザー限定のインターナル（内部的）なプラットフォーム
• 取引先など関連性が高いユーザーにまで参加してもらうプライベートなプラットフォーム
• パートナー企業や個人ユーザーにも開放するパブリックなプラットフォーム

　デジタルビジネスプラットフォームへのニーズの変化に伴って、アプリケーションに求められる機能や性能は変化する。そうした変化に耐えられる仕組みが、マイクロサービスアーキテクチャというわけだ。「デジタルビジネスプラットフォームがアプリケーションに求める要件と、マイクロサービスアーキテクチャが提供するメリットは合致しています」（飯島氏）

マイクロサービス化で起こりがちな10個の課題とその対策

　全てのアプリケーションをマイクロサービスアーキテクチャにすればいいという簡単な話ではない。マイクロサービスアーキテクチャが生きるところと、既存アーキテクチャのままでいいところを見極め、うまく使い分ける必要がある。講演で飯島氏はマイクロサービス化に当たってつまずきがちな10個の課題を挙げ、それぞれについて対策を示した。

課題1：どこから手を付けるべきか分からない

　1つ目の課題は、どこからマイクロサービス化するかだ。新しい開発手法を取り入れる際に必ず挙がる課題といえる。全てのアプリケーションを一気にマイクロサービス化しようとする例もあると飯島氏は言うが、これもどこから手を付けていいか分からないから起こる問題だ。

　「ビジネスの変化スピードやその頻度、ビジネスの価値を考え、適用すべき領域を特定するとメリットを得やすいでしょう」と飯島氏は指摘する。特にデリバリーのスピードや拡張性が求められるアプリケーションは、マイクロサービス化が大きな効果を発揮する。

課題2：適正な粒度が分からない

　第2の課題は、マイクロサービスの適正な粒度が分からないというもの。「モノリシックなアプリケーションを分割するといっても、どの程度のサイズに分割すればいいのか分からない」という相談や、「とにかくマイクロサービスを小さくすればいい」という勘違いが多いと飯島氏は明かす。一般的にサイズを小さくすればデリバリーを迅速化できる。ただし小さくし過ぎると、アプリケーションを構成するマイクロサービスの種類や数が増え、管理が複雑化する。

　この課題を解決するためには、まずはビジネスのスピードに、アプリケーションのデリバリースピードを合わせるべきだと飯島氏は言う。ビジネスの変化に応じて、その遂行に必要なアプリケーションは変化する。アプリケーションの改修や新規開発に関するデリバリースピードが、ビジネスの変化に追い付いていなければ、サイズをさらに小さくした方がいいというわけだ。

　「マイクロサービスは多様な粒度を取り得るので、目的や範囲に応じて粒度を考えるべきです」と飯島氏はアドバイスする。変更の必要性がなかったり、データの厳密な一貫性が求められたりするアプリケーションは、モノリシックのまま、もしくはそれに近い“マクロサービス”と呼べるほど大規模なマイクロサービスが適する場合もある。「自社のアプリケーションがどのような目的を持ち、どのように拡張するのかを考え、マイクロサービス化の対象や粒度を決める必要があります」（同氏）

課題3：マイクロサービスの適用シナリオが現実的ではない

　マイクロサービス化を進めようとしたものの、いきなり複数のアプリケーションをマイクロサービス化しようとするなど、その適用シナリオが現実的ではない場合、かえって混乱を招いてしまうこともある。これが3つ目の課題だ。マイクロサービス化のロードマップを描く際には、適用可能なシナリオが幾つもあることを知り、自社に適したシナリオを選ぶことで適用の可能性が広がる。

課題4：提供者目線でAPIを設計、提供してしまう

　マイクロサービスは、API（アプリケーションプログラミングインタフェース）を通じて他のマイクロサービスと連携できる。その点で、マイクロサービスは「APIサービス」だと捉えることもできる。

　APIを軸にしてデジタルエコシステム（IT分野のビジネス生態系）を構成するプレイヤーを考えると、APIを提供する側と利用する側（ユーザー）に分けられる。5つ目の課題は、API、つまりマイクロサービスを提供する側が、自社の都合をAPIのユーザーに押し付けてしまうことだ。

　デジタルエコシステムにおいてAPIは商品であり、ユーザー目線での設計が必要だと飯島氏は強調する。その上でサービス全体のメトリクス（品質指標）を見つつ、品質のボトルネックを解消し続けなければならない。

課題5：マイクロサービス化を一時的なプロジェクトとして扱う

　課題3の対策は、課題5にも関連する。マイクロサービス化の適用を一時的なプロジェクトと考え、将来的な状況まで考えていないというものだ。マイクロサービス関連技術は進化し、デジタルビジネスプラットフォームに求められる要件も変化する。この双方を視野に入れ、ビジネス成長のロードマップを描く必要がある。

課題6：設計開発プロセスが未熟

　飯島氏は、開発プロセスを成熟させないままプロジェクトをスタートしてしまうという課題も挙げる。「マイクロサービスのメリットを生かすため、開発やデリバリーのプロセスを成熟させ、プロセス自動化の完成度を高めてからプロジェクトをスタートしなければなりません」と同氏は強調。サービスを機能単位で小さく提供する、デプロイの生産性を上げてアジリティーを高める、サービス基盤の自動化を進めるなどの準備が必要だと指摘する。

課題7：構築方法が分からない

　飯島氏が7つ目に挙げるのは、マイクロサービスの開発実行インフラの構築方法が分からないという課題だ。マイクロサービス化のメリットであるアジリティーを最大限に得ようと考えるなら、API公開用のゲートウェイ、デプロイやビルドの自動化機能などを全て自社で構築していては非効率だ。

　「マイクロサービスアーキテクチャを生かすためには、インフラにもアジリティーが求められます。既存のクラウドをうまく使うのがいいでしょう」と飯島氏は指摘。責任の範囲やアジリティー目線で

• IaaS（Infrastructure as a Service）
• CaaS（Container as a Service）：コンテナを提供するクラウドサービス
• aPaaS（Application Platform as a Service）：アプリケーションの開発・デプロイ環境を提供するクラウドサービス
• fPaaS（Function Platform as a Service）：サーバレスを提供するクラウドサービス

を使い分けるべきだとアドバイスする。

課題8：開発環境、実行環境が管理不能

　第8の課題は、マイクロサービスの独立性や自由度を追求し過ぎてしまうこと。その結果としてマイクロサービスの開発言語やAPIの種類が膨大になると、開発環境や実行環境の管理が困難になる。ベースとなる言語を幾つかに絞り込んでおくこと、APIを増やし過ぎないことなどに気を付けるべきだと飯島氏は指摘する。

課題9：既存アプリケーションとシームレスに連携できない

　9つ目は、既存アプリケーションとの連携に関する課題。マイクロサービスはAPIを備えるため、自然と他のマイクロサービスやアプリケーションとの連携が容易になる。マイクロサービス化を進めるアプリケーションだけではなく、他の既存アプリケーションとの連携もしやすくしたい、というニーズもあるだろう。これを実現するためには、既存アプリケーションのAPI化を並行して推進する、REST API（システム連携の設計原則「REST」に準拠したAPI）を積極的に活用するなどの工夫が求められる。

課題10：社内にスキルがない

　最後は、マイクロサービス化に必要なスキルが社内にないというもの。エンジニアは一朝一夕で成長できるわけではないので、最初から完全なスキルセットを求めないようにすべきだと飯島氏はアドバイスする。開発者コミュニティーやハッカソン（プログラミングイベント）、ユーザー会への参加で最新技術にキャッチアップをすることも有効だと訴える。

　マイクロサービスアーキテクチャは優れた点はあるものの、万能ではない。「マイクロサービス化にこだわり過ぎることなく、ビジネス上の観点から現状をチェックし、ロードマップを設定し、アプリケーションの進化に必要なプロセスを考える必要があります。ビジネスとの整合性を考えながら、開発チームを編成し、そこに適するのであればマイクロサービスアーキテクチャを取り入れていくといいでしょう」（飯島氏）