最も変化の激しい部分をマイクロサービスとして切り出す
マイクロサービスの設計面の課題の1つは、適正な粒度が分からないことだ。「最初からすごく小さい単位に分割しようとするユーザーがいるが、まずはビジネスのスピードに追い付くことが第一の目的だ」（飯島氏）。ビジネスのスピードに付いていけなくなったら、マイクロサービスの粒度を下げることを考える。
目的に応じて粒度を変えることも重要だ。ECサイトのシステム全体をカプセル化して公開するために、粒度の荒いマクロサービスを適用する。この一方、配送オプションなどの個々の機能は、粒度の細かいマイクロサービスを適用する。このように、APIの公開範囲と照らし合わせて考える。
既存のアプリケーションをマイクロサービスに分割する際に、一気にすべての論理境界を分析して分割すると上手くいかない、という課題もある。例えば、機能を分割したのに、マイクロサービス間でデータの依存関係が残ってしまうことがある。この結果、個々のマイクロサービスを独立してデプロイできない問題が起こる。
マイクロサービスの成功事例を見ると、複数の論理境界を見つけるのではなく、まずは一番重要なところ、変化の大きいところ、独立して拡張したいところの論理境界を見出して切り出している。この上で、必要であればビジネスが要求するスピードに応じて粒度を小さくする。これを反復する。
マイクロサービスを提供者側の目線で構築してしまうことも大きな課題だ。「APIは商品。APIの利用者の目線で設計しなければならない」（飯島氏）。APIを提供するマイクロサービスについて考えるのではなく、マイクロサービスによって提供されるAPIを利用するウェブサイトやモバイルアプリケーションなどのフロントエンドについて考えなければならない。
クラウドサービスを活用してアジリティを確保せよ
マイクロサービスを設計した後に問われるのは、マイクロサービスを開発する準備ができているのかどうかだ。マイクロサービスを設計／開発するプロセスが未熟なままプロジェクトを開始してしまうケースがある。例えば、「アジャイル開発の方法論を使っているが、アジリティのメトリクスがない」といった具合だ。
マイクロサービスの開発／実行基盤をどう構築するか分からない、という課題もある。マイクロサービスは小さく提供する必要があり、開発／実行基盤には自動化やセルフサービスなどのアジリティが求められる。ここでは、クラウド型のプラットフォーム（IaaS/CaaS/aPaaS/fPaaS）が有効だ。
マイクロサービスの選択の自由度や独立性の高さを追求し過ぎると、開発／実行環境が管理不能に陥るという課題もある。「言語や開発環境は2〜3種類に絞ったほうがいい」（飯島氏）
マイクロサービスのスキルが社内にないという課題もある。これについては「スキルセットを獲得するアプローチにもモード2を適用し、最初から完全なスキルセットを求めない」（飯島氏）ことが大切だ。既存のIT部門の考え方と異なることが多いため、「IT部門のマインドセットのバイモーダル化を進める必要もある」（飯島氏）
