• 長沢 翼 氏
  株式会社LIFULL CTO

登壇者のご紹介

エンジニア数十名から数千人規模まで、マイクロサービス化を進行中の4社

長沢：
株式会社LIFULLでCTOを務めています、長沢と申します。よろしくお願いします。CTOになったのは2017年頃なので、キャリアは2年ほど。フロントからバックエンドまで幅広く手がけています。

会社規模は1000人ほどで、エンジニアはプロパーが約150名ほどです。ベトナムに開発子会社があり、そちらにも約50名のエンジニアがおります。LIFULLは「あらゆるLIFEを、FULLに。」というコーポレートメッセージを掲げ、不動産・住宅情報の総合サイトLIFULL HOME’Sを運営しているほか、子会社でもさまざまなサービスを展開しています。

マイクロサービスという考えを導入し始めたのは2014年頃。そのころ事業系サービスをオンプレミスの環境からAWSに移行するというプロジェクトを進めていてそれと同時期です。

【モデレータ：株式会社LIFULL CTO 長沢 翼さん】

生内：
クラウドファンディングサイトの運営を行なっている株式会社マクアケのCTO、生内です。CTOになったのは去年の頭頃で、就任から1年半ほどになります。僕が参入した時点ではエンジニア8名程度の小さな組織だったのですが、事業拡大のために去年から一気にメンバーも増員し、現在は28名のエンジニアが在籍しています。

一般的には開発規模が拡大した際に取る手法のひとつだと思いますが、今回も同様です。まだまだ発展途上ですが、マイクロサービス化を進めています。

佐藤：
LINE株式会社の佐藤です。サーバーサイドの開発チームでマネージャーを担当しています。CTOではないのですが、社内ではマイクロサービスの共通基盤の開発にチームとしてコミットしていることと、イベントなどにおいて情報発信を担当しているということで、今回お声がけいただきました。

主な担当はLINEスタンプやLINE着せかえなど、LINEのコンテンツの一部で、社内では通称LINE Shopチームと呼んでいます。最近はLINEウォレットやLINE Payが絡んでいる部分も担当しています。

LINEはコンテンツごとに個別のグループ会社がある場合もあり、全体像が複雑なのですが、エンジニアはトータルで2000人以上在籍しています。現在は3000人規模を目指すため採用活動中です。今日はどうぞよろしくお願いします。

白石：
株式会社メルカリのディレクターをやっております白石です。メルカリ全体は現在1800人ほどの規模の会社です。

私自身は以前ソフトバンクやレコチョクに務めており、ドリコムではCTOの役回りも担っていました。現職と並行して自社の運営や複数社の技術顧問も行なっています。マイクロサービス化はメルカリでも進めていますが、他社で検討することも多いです。メルカリにおいてはマイクロサービスの技術的な部分にはほとんどタッチしておらず、テストと育成や採用などの組織マネジメントの役割を担っています。マイクロサービス化を進めるといろいろな周辺課題が出てくるので、今日はそういった切り口でお話しさせていただければと思います。

マイクロサービスの捉え方と導入経緯

機能ベースによって分割されるのがマイクロサービスの主なケース

長沢：
一口にマイクロサービスと言っても、会社ごとに捉え方が違うはずです。そこでまずみなさんの会社がマイクロサービスについてどのような捉え方をしているのか、実際にどのような単位で分割しているのかお伺いしたいと思います。

白石：
メルカリはノーティフィケーション、認証など、機能単位で分割しています。

佐藤：
LINEはLINE○○というさまざまなサービスがありますので、まずはその単位で大きく分かれています。そこからメルカリさんのように、特殊な役割を持っている、あるいは技術を利用できるような機能があれば、そこにマイクロサービスを当てはめるといった形にしています。ビジネスで欲している機能と、実装に必要な技術として中心に据えたいものがあると、それがマイクロサービスになるという感じですね。

生内：
マクアケではサービスの分割とマイクロサービス化は概念として分かれています。サービスは業務内容やサービスへの思いが強い人、サービスを使う人の思考を考慮して分割するわけですが、マイクロサービスはエンジニアリング都合で設計しています。リソースの消費傾向やセキュリティレベルなどのシステムのある部分に求められる性能傾向の偏りは分割を判断するのによくトリガーになります。

【ご登壇者：株式会社マクアケ 執行役員 CTO 生内 洋平さん】

組織の拡大、ビジネスの成長に伴って求められるマイクロサービス化

長沢：
ではマイクロサービスを導入しようとした際の課題や実際の導入経緯について、佐藤さんいかがでしょうか？

佐藤：
私が所属している部署で言うと、ジョインした2013年当時はモノリシックなサーバーの見通しが悪く、機能を追加するにもどこを触ればいいのか全くわからないような状態でした。その頃からマイクロサービス化が必要だと社内で話し合っていた印象です。2013～2014年頃はLINEのサービスのラインアップが増えてきた時期なので、その影響もあります。ビジネス上の要件について、複数人からそれぞれ別の要望を受けるような現状があり、サービス側としても自分たちのKPIややりたいことに向かって進むにはマイクロサービス化が必要だと感じていたのです。

また、拠点も東京、福岡、京都、韓国、台湾など急速に増えたことで、異なる場所のメンバーがある程度独自の判断で動ける体制が必要になったことも理由でした。

生内：
当社は先程述べたようにまず事業と組織の拡大時期にきていたのがトリガーでした。システムと組織の業務体制が絡まりあったモノリスが形成されており、一枚岩として強い部分もあったのですが、効率化・仕組み化の妨げになっていたり、開発を必要以上に複雑化している状況があったんです。

そこで僕たちの場合は、マクアケはサービスとしてどんな機能を有していているのかを洗い出し、ドメイン設計からやり直しました。そこに応じてシステムを変えていこうと考えたんです。組織の拡大をチャンスと捉え、組織の変更に寄り添う形でシステムを変更していこうという組織的判断をしたわけです。比較的丁寧にマイクロサービス化を進めているのではないでしょうか。

長沢：
ちなみに、エンジニア人数はどれくらいの規模のタイミングだったんですか？

生内：
この思想自体を打ち出したのは12名くらいの頃ですね。だいぶ早い段階だったとは思いますが、思想を形にすることで日常的に将来を考えたデータ構造を意識して開発を進めることになるので、大事なことだったと思います。

そこは、僕たちが考えているマイクロサービス化に向けてのステップが関係しています。まずはビジネスストラクチャーの構造をよく観察し、それに対してデータをモデリングしていくというプロセスを何度もトライアルする。そこからようやくデータストアを分割します。トライアル期間をできるだけたっぷり確保して、未来の形を組織の中に先行して落とし込んでおくのです。

【 Cuddled Microservice 】

長沢：
どのタイミングからマイクロサービス化するべきなのかという視点で言えば、メルカリさんもかなり早いタイミングからマイクロサービス化を推進してきたイメージがありますが、何を見据えていたのでしょうか？

白石：
メルカリがマイクロサービス化に踏み切ったのも、ビジネスが急激に加速していき、エンジニアの人数も一気に増えたタイミングです。もともとプロジェクトをはバイヤーやセラーなどKPI単位で分けて運用していたのですが、バックエンドシステムはモノリスでした。そんな状態でエンジニアの人数が増えると、開発速度が遅くなってしまいます。そのうち手としてバックエンドのチームをドメインで分けつつ、ある程度担当を分けてそれぞれで進められるようにしていくという判断がありました。

急成長するというタイミングで判断しないと、ビジネスが拡大してからではどんどん難しくなっていきなっていきますのでその前に踏み切るという判断でした。

【ご登壇者：株式会社メルカリ Director 白石 久彦さん】

マイクロサービス化をスムーズにするには？

必然性があって初めてマイクロサービスは成立する

長沢：
経営判断という面で言えば、マイクロサービス化のためにモノリスを切り分けたとしても、切り分けている最中はもちろん、切り分けた後も結局何の利益も生み出さない可能性もゼロではありません。マイクロサービスにすることで果たして新しい価値が生まれるのかどうか、議論はあったのでしょうか。

生内：
その点については意識していました。「事業的に新しくしたい部分」は率先して切り分けの対象にしようという前提があり、チャンスだからマイクロサービス化しようといった形で、順番立てて話を進めていきました。もちろん技術的に無理をしすぎず、負債もたまりすぎない範囲ですが。

長沢：
なにかビジネス的な機会があるたびにそこを切り出すんですね。佐藤さんはいかがでしょうか。

佐藤：
当社でもビジネス側と議論してお互い納得の上で進めましたし、その方がいいと思います。単に「バグを直したいからしばらく開発を止める」と言っても通用しませんが、「こういう技術があるからこう改善できる」といったバックグラウンドをきちんとコミュニケーションして説明できれば、成功しやすいはずです。

長沢：
そういう意味だとマイクロサービス化するタイミングも難しいと思うのですが、たとえばみなさんが自分で今から新しいサービスを立ち上げるとしたら、最初からマイクロサービスにするのか、それともモノリスファーストで進めるのか、どうされますか？

白石：
何社か技術顧問をやらせていただいている観点からすると、まだマイクロサービス化するタイミングではない会社は結構あります。今は「マイクロサービス」というキーワード自体が注目されているのでエンジニアとしても気になりますし、導入した方がいいのか検討すると思うのですが、実際に導入するのは事業が軌道に乗っていく少し手前、あるいはシステムをスケールアウトする手前の状態がいいのではと思います。

佐藤：
会社やビジネスが健全な状態で成長すればユーザー規模も一緒に大きくなっていくと思いますが、そういう状況の場合、実際にエンジニアが「モノリスでは開発しにくい」と思った段階でスタートするのがいい気がしますね。

【ご登壇者：LINE株式会社 開発1センター LINE開発1室 P Partチーム マネージャー 佐藤 春旗さん】

既存のモノリスを切り分けるために必要な判断やプロセス

長沢：
マイクロサービス化するタイミングについてはみなさん共通して、大きなモノリスに対してこのまま使い続けるのが難しそう、組織が拡大しそう、ビジネスが軌道に乗ってきているといったタイミングで、将来を見据えて分割していったという感じですね。

ただ、分割できそうなところから徐々にやっていくと、いつかは既存の大きくて古いモノリスにも手を入れなければいけないと思うのですが、それは積極的に動かれているんですか？

佐藤：
LINEにおいて、もともとのモノリスを解体する作業は進行中です。担当者が何をしているかと言えば、まずは具体的にモノリスの問題を見つけて、どうしたら分解できるのかある程度見通しを立てています。そこからその部分を渡すチームを新たに作り、マイクロサービス化に着手します。完成したら切り替えるというやり方ですね。終わりはまだ見えませんが、地道に続けています。

長沢：
なるほど。切り分けるための設計をしてマイクロサービスを作りはじめると、既存のシステムに機能が追加されて終わらない…という事態もあると思うのですが、その点はどう対処していますか？

佐藤：
ケースバイケースで古い方に追加しなければならない場合はマイクロサービス側も準備したり、移行できるようなやり方を検討する必要がありますね。実際、古いサーバーにとりあえずAPIを追加して、後日改善の一環としてマイクロサービス側にAPIをまるごと移行したこともあります。

長沢：
そういった微妙な判断が必要な部分はコミュニケーションで解消するということですね。

佐藤：
それがベストだと思います。

質疑応答①

1. 既存のサービスからマイクロサービス化を進めるコツは？
2. サービスを分割する際は同時に組織も分割していくのですか？
3. マイクロサービス、サービス間のやりとりはHTTP？
4. 分割した後の共通部分の管理はどうしていますか？

既存のサービスからマイクロサービス化を進めるコツは？

長沢：
先程モノリスの分割の仕方についてはお話しいただいたかと思いますが、それ以外にありますか？

生内：
MVCを取り巻く流れで言うと、いかに優れたデータモデリングができるかが一つコツになると思います。

あとはビジネスの奥行きを見ること。「これは本当に分割する意味があるのかどうか」という判断ですね。分割した後もそのサービスが目的に併せて成長していく見込みが充分あるのなら、分割すべきだと思います。

白石：
生内さんがおっしゃるように、伸びない部分を切り分けて広げても意味はありません。スタートアップの人たちが分割したいと言う場合でも、必要なのは本当にマイクロサービスなのか、それともシステム単位の分割なのかという判断がありますよね。マイクロサービスかというと、実はそうではないなというものも多かったりしますよね。

佐藤：
個人的には、既存の良いとされるデザインパターンはどのレイヤーにも使えると思っています。MVCでもそうでなくても、なんらかのモデルをしている時は良いモデル化をすること。あとはドメインドリブン的な考え方で、どのドメインがどこに属するのか、自分たちで分けられるようになっておくとマイクロサービス化はやりやすい気がします。

サービスを分割する際は同時に組織も分割していくのか？

長沢：
マクアケさんでは28名のエンジニアがいて、たとえばログインサービスは3名といったようにマイクロサービスごとに担当を決めているのでしょうか？

生内：
基本的にはそうですが、サービス間でメンバー移動はありますね。リーダーの移動やサービスの兼任はできるだけしない方がいいというスタンスですが、少人数なのでやむを得ない場合は行います。

長沢：
ありがとうございます。メルカリさんはどんな感じでしょうか。

白石：
先々は組織も分割することを考えて動いています。そしてその組織単位で自由に技術選定などもできるようになるのが理想ではあるのですが、現状はまだ遠いですね。今で言うと組織ではなくチームでは分かれているのですが、各チームが独自性を発揮するのはこれからという感じでしょうか。

佐藤：
当社も基本的にマイクロサービスと組織は紐付けされているのですが、LINE Shopチームはあえて物理的に東京と福岡に分散しています。分散しない方がいいと言われることもあるのですが、これは実証実験の意味合いもあるんです。各マイクロサービスの共通部分があるわけですが、それを東京と福岡両方で使えるものにすれば、仮に３つ目のチームができてもそれを利用できるのではと考えています。共通部分というのは、例えばデプロイのシステムやキャッシュの仕組みなどですね。しっかりデザインすれば、どのサービスでもある程度同じようなインターフェースを利用できるはずですから。

マイクロサービス、サービス間のやりとりはHTTP？

生内：
HTTPだけにはあまりこだわっていませんね。一般的なところでは、RPC系のプロトコルも標準の範疇です。ある程度標準として採用するプロトコルとして定めてはいるものの、サービス移管の過渡期であるという認識を前提に、一時的に直にSQLを叩くケースもゼロではありません。

佐藤：
LINEの場合はApache ThriftやProtocol Buffersを使っています。

ただ、マイクロサービスの利点の一つはAPIとして抽象化されていて、そのサービスが何をするものなのかわかりやすく言語化できる点です。APIを定義できて、それをメンバーが共有できる仕組みさえあれば、HTTPなのかgRPCなのかというレベルのプロトコルは本質的には何でもいいんじゃないでしょうか。

長沢：
白石さんはいかがですか？

白石：
状況や目的によりますね。別にHTTPでやっても全然いいと思っています。

長沢：
ちなみにインターフェースを選んだ基準はあったりしますか？

佐藤：
Apache Thriftに関しては、2011年当時の選定だったのですが、クライアント側、サーバー側、マイクロサービス側すべてにおいて同じものを使えないかという視点で検討したようです。ちょっと珍しいタイプの判断だったかもしれませんね。

生内：
前述の補足ですが、僕たちの規模感ならではかもしれませんが、gRPCを使う箇所が多すぎるとエンジニアの採用ハードルが上がってしまうので、メインはhttpを採用しています。

分割した後の共通部分の管理はどうしている？

長沢：
共通部分というのは、たとえばログの取得やAPIのインターフェースの部分かもしれませんが、いかがでしょうか？

白石：
メルカリの場合は「マイクロサービスプラットフォーム」というチームがあり、共通している仕様を管理しています。

佐藤：
いくつか切り口となる考え方があると思いますが、LINEの場合はインフラ寄りの部分はインフラチームが管理しています。

似通ったサービスの共用部分という意味合いであれば、リポジトリを共有していますね。うちのチームは比較的複数のマイクロサービスから成り立っていますが、シングルリポジトリです。共通化しているものに関しては１つのリポジトリの中にあるコードをいじればまとめて変更できるという仕組みを採用しています。

長沢：
分割しているサービスの言語もすべて共通しているんですか？

佐藤：
うちのチームに関しては基本的にJavaとKotlinですね。マイクロサービス単位であえて複数の言語を使うケースはあまり見たことがありませんし、アクロバティックな感じがします。

長沢：
なるほど。生内さんはいかがですか？

生内：
当社はさほど規模も大きくありませんし、プロダクト的に共通処理が起きにくいですね。ただうちはSREを置いていて、リファレンスサービスという概念も設けています。デプロイフローなどは邪魔にならない程度に共通化させていますね。

マイクロサービスのメリット・デメリット

メリットの裏側はデメリットになる、マイクロサービスの特質を理解する

【モデレータ：株式会社LIFULL CTO 長沢 翼さん】

長沢：
では第２部をスタートします。大きなテーマはマイクロサービスのメリット・デメリットということで、これも組織ごとにいろいろあると思いますから、まずはざっくりみなさんが思うところから教えていただければと思います。

佐藤：
マイクロサービスのメリット・デメリットについて日々感じている箇条書きにまとめました。

• 一般論としての、分業制のメリット・デメリットに近いものも多くある
• メリットとデメリットは表裏一体
• むやみに分割すればいいというものでもなく、メリットを享受できるように分割するべき
• 弊チームの新しいメンバー向けの紹介でも ”well-shared and well-separated micro services.” が大事、と紹介している

最後の”well-shared and well-separated micro services.”というのは、どこを共通化してどこを分けるべきかを気にするべきだということです。どちらか一方に偏ればいいというものではありません。

その上でメリットとして挙げられるのは、まず自分たちの担当範囲の改善がすばやく行えるということです。さらに技術的、開発側の理論や都合でいけば、そのサービスにとって最適な選択もしやすくなりますね。同じように、エンジニアも適した技術を持ったメンバーを集中して採用できます。

細かい技術的観点で言えば、モニタリングがやりやすいですね。モノリスの場合はプロセスやマシンは１つなのですが、モニタリングのために使用するツールややり方が複雑になりがちです。一方でAPIのモニタリングは現在ツールがかなりしっかりしているので、かなり楽に行えます。

デメリットは自分の担当から遠い部分の変更に時間がかかったり、コミュニケーションが発生する手間がかかることですね。ただこれはメリットの裏側なので、一概にだからダメというものではありません。マイクロサービスはそうなるものだと認識して進めたいところです。

また、これもメリットと裏返しのデメリットですが、サービスそのものの要素が増えるため、ソフトウェアエンジニアリングの観点では複雑系になりやすいです。そうなると、なにか一つエラーが発生した際に、どこに何が起こるのか一見してわからない可能性もあります。

【ご登壇者：LINE株式会社 開発1センター LINE開発1室 P Partチーム マネージャー 佐藤 春旗さん】

生内：
先にデメリットから言及すると、慎重に設計をしてもミスをする可能性はゼロにできません。そして工程が進んでいればいるほどリカバリーがつらい。ですから、Cuddled Microserviceの表のようにデータモデリングの段階から慎重にやっていくことが大事だと思います。

また、僕が作っているのはクラウドファンディングというまだまだ新しい概念のサービスで、市場における「システムはこうあるべき」という姿が180度変わることもあります。そういった危険性のある部分をがちがちに分割していくと痛い目を見るかもしれません。

メリットは、マイクロサービスを自由自在に扱えるようになってくるとスケーラビリティといった性能を置きたいところに置けることですね。インフラを巻き込んでアプリケーションアーキテクチャの一部として取り扱える。このようなエンジニアリング（アプリケーションエンジニアリングとインフラエンジニアリングがシームレスになった状態のエンジニアリング）のことを我々はサービス・エンジニアリングと呼んでいますが、こういった思考に昇華されていくメンバーがぼちぼち現れている。これは強力なメリットです。

当社はゴールデンタイムの番組などに紹介されることも多くて、そうなるといきなり2000倍3000倍といったアクセスによる負荷がかかるので、そういったケースで「サービス切出さなくちゃ」という意思決定が下されることもありますね。

【ご登壇者：株式会社マクアケ 執行役員 CTO 生内 洋平さん】

白石：
やはり分業してパラレルに物事を進められるのがメリットですね。人間が覚えられる細かい仕様というのは、範囲に限界があるような気がしているんです。スピーディにタスクをさばいている人たちが見るべき範囲がきちんと区分されているのは利点があると思います。

デメリットはみなさんがおっしゃるようにメリットの裏返しですが、並行して物事を進めるために作業する人も分かれていますから、モノリスよりも人員が必要になる気がしています。そして人が増えれば統制を取る必要がありますから、このへんはデメリットになり得るかもしれません。

【ご登壇者：株式会社メルカリ Director 白石 久彦さん】

長沢：
私からもLIFULLで実施して感じたメリット・デメリットをお伝えしたいと思います。LIFULL HOME’Sというサービス自体のメイン部分はもう7年ほど続いていて、モノリスな部分が多いサービスです。

その中で感じているマイクロサービスを実施した部分のメリットは、切り分けたサービスの開発効率が良かったことです。プロダクトに関わる数字、たとえば、コードの複雑度や開発やテストにかかっている時間、障害率などの数字をいろいろと取得して、モノリスなサービスとマイクロサービス間で比較した結果、特にテストやレビューなど「品質」にかけるコストが、切り分けたサービスのほうが良かったんですよね。当然なんですが、可視化すればより明確になるというか。ただ、モノリスなサービスはだんだんと品質にかけるコストが増えている一方で、障害率はほぼ変わってませんでした。このことから仮説を立てると、コードなどが複雑化したモノリスで障害率をおさえられているのは、テストやレビューにかなりの時間をかけているからだということになります。つまりマイクロサービス化によってこれらの時間を削減し、代わりに実装に割ける時間が増えたということなので、これは大きなメリットと捉えることができました。

一方でデメリットは、マイクロサービス化したものの、戦略上の問題でチームがなくなってしまったり、別のチームに吸収・統合されるといった動きがあり、誰がマイクロサービスを管理するのかわからなくなってしまうといった問題が起きたことです。

あとは分割を進めることを優先して、共通部分を無視してあえてマイクロサービス化した部分があるのですが、開発が進むと共通部分に関わるオーバーヘッドが段々無視できないレベルになってきてしまいました。ログの取得やインターフェースの部分です。効率的ではなくなってしまったので、現在は全体の共通基盤を作ろうとしているところです。

影響範囲を切り分けられるメリットがある一方、マイクロサービスの複雑性には対応が必要

長沢：
では気になった部分をいくつか深掘りしたいと思います。白石さんがおっしゃったメリットで、分業でパラレルに開発を進められるということがありましたが、これはある意味モノリシックな状態でもできなくはないという発想もあると思います。この点はいかがでしょうか？

白石：
たとえばリグレッションテストなどがオートメーション化できている場合、単体でデプロイしてもリグレッションが回って通っていれば問題ないんですよね。ただ、おっしゃったようにモノリシックで分業しようとすると、すべて同じタイミングでテストしないといけない。そこはスケールしていくときのボトルネックになると思います。何か問題が起きたときの影響範囲の切り分けという意味でも、マイクロサービスはメリットがありますね。

長沢：
一つだと一部分だけ戻すということができませんからね。

あとは佐藤さんがおっしゃっていたデメリットで、エラーが起きたときに何がどこで起きているか、影響が見えにくくなる問題ですが、これに対してカオスエンジニアリング的にわざと障害を起こして影響度を見るといったテストなどは行っていますか？

佐藤：
チーム内でもその点は勉強していて、やりたいと考えています。本格的なカオスエンジニアリングとは違いますが、ベータ環境においては一定の割合でエラーを返すような仕組みが入っていて、その状態でちゃんとフォールバックするかは日々確認している例もあります。LINEの場合は何かキャンペーンを開始したときに障害が起きるというのが典型的なパターンなので、最近は定期的にハイトラフィックを一台にぶつけてみて、止まったらどうなるのかを見るようにもしています。

マイクロサービスがエンジニア組織のモチベーションアップに寄与する事例の紹介

長沢：
マイクロサービスにたいして誰が責任を持つのかわからない、といったように宙に浮いてしまったということはありますか？

生内：
僕はあります。チームで運営していたサービスが、そのチームが解散した際にを誰も引き取ってくれなかったケースです。アドテクに近いサービスの一部を切り出すプロジェクトだったのですが、作りがレガシーであることに加えてビジネス的な貢献度もわかりづらいものでした。やりがいのない単位で分割してしまうとまずいかもしれません。失敗談ですね。

白石：
やりがい問題はありますよね。たとえば主要なKPIがちゃんとマイクロサービス化しても意識できるとか、OKRを担当チームで持てるといったことは非常に重要です。個人的にはマイクロサービスの半分くらいは組織論なのではないでしょうか。

長沢：
では、逆にマイクロサービスにしたことによってメンバーのモチベーションが上がったといったことはありますか？

白石：
メルカリでは、システムを分けることで各エンジニアがオーナーシップを持ってほしいという点があります。その範囲に対してオーナーシップを持つ人間が出て意思決定をする人が増えるくるということは、チャンスも増えます。それを良いことだと捉えてやっていきたいなと思っています。

長沢：
適切にオーナーシップを持つのは非常に大切ですね。そのサービスを任されているオーナー的な人がいて、その人の判断でサービスを良くするための機能が追加できるとなればメンバーのモチベーションも上がりますし、そのサービスを良くするためにはどうしたらいいのか考える癖がつきます。

逆に言われたものをただ作ってるだけのマイクロサービスになってしまうと進歩がありませんし、モチベーションも上がらないと思います。佐藤さんいかがですか？

佐藤：
今のお話を聞いて思い出したのは、新卒のメンバーが入社したときのことですね。新しいサービスを立ち上げてもらう形で、マイクロサービスをゼロから作ってもらいました。 ビジネス規模自体が大きいと、新しくビジネスを立ち上げてサービスをゼロから作るという機会はほとんど無いと思います。それがマイクロサービスにしたことで、定期的にゼロからサービスを作った経験をメンバーに与えられるのは、教育や組織論の観点で良いやり方だなと思いました。

質疑応答②

1. マイクロサービスにおけるアンチパターンの実体験について
2. ドメイン設計後、モジュール分割に留めずマイクロサービス化に舵を切った理由は？
3. マイクロサービス化された部分はモノリスよりも外注に出しやすい？
4. マイクロサービス化をした後でビジネス範囲が変わってしまうことはあるのか？

マイクロサービスにおけるアンチパターンの実体験について

長沢：
では第2部の質問タイムに移りたいと思います。アンチパターンの実体験について。マイクロサービスにしたせいで、かえって変更がつらくなったといったことでしょうか。佐藤さんいかがですか？

佐藤：
分けたこと自体は判断として間違っていなかったので、つらい経験というわけではないのですが、分けてからどうしてもビジネス的に一緒に見せたいというタイミングはありましたね。改めて分割したデータを混ぜて表示しなければいけなかったケースです。もっと前からそれがわかっていればいろいろとやり方があったのかなと思います。ただ未来に何が起きるのか見通すのも難しいので、むしろそういったことが起こり得るという覚悟が必要なのではないでしょうか。

生内：
アーキテクチャの変更そのものにチームが慣れていくということも視点としてあるかもしれないですね。分割したりマージしたりということはあるものだと捉えるんです。いや、そこはばっちり設計すべきだという考えの方はいますか？

白石：
未来を考えて設計をすべて完璧に作り上げいくとしたら、それが制約になってしまうことも多いんじゃないでしょうか。とりあえず現状向いている方向に進んだ方が発展的な気がします。

生内：
アーキテクチャ自体、一生懸命作っても保って3～5年程度ですしね。

白石：
想像できる範囲は限られていますから、どこまでスコープに入れて設計するかという世界を追求するよりも、変化を前提とした設計をした方がいいのかもしれないですよね。

ドメイン設計後、モジュール分割に留めずマイクロサービス化に舵を切った理由は？

生内：
マイクロサービスはDevOpsとも言われていて、その中でもインフラのコード化という文脈とセットになっていると捉えています。つまり、アプリケーションエンジニアがインフラやデータストアのステージングなども含めて考えてくれるようになる。そういったエンジニアが増えること自体がマイクロサービス化のものすごく大きなメリットですね。言語の共通化ができるので、問題意識や焦点の当て方も全く変わってきます。

そういう意味で、理論上はモジュール分割でも良い部分が確かにありましたが、組織づくりという点でエンジニアがベーシックに取り扱えるものの幅が広がるという利点を取った形です。

佐藤：
あくまで一般論ではありますが、ロールバックが容易になるといったことも含めて、マイクロサービス化する方がモジュール分割よりも自由度が高まりますよね。何か問題が起きたときに対策手段が増えるというのは気が楽ですし。

白石：
組織論で言えば、フィードバックを受けてそれに対して責任を持つというのはオーナーシップの根源だと思いますが、それがマイクロサービスによって強化されて、さらにサービスを良くできるというのは素晴らしいと思います。

マイクロサービス化された部分はモノリスよりも外注に出しやすい？

佐藤：
たとえばきちんとAPIを定義してあげるとか、再利用可能なインターフェースを考えるといったマイクロサービス化するために使えるテクニックそのものが、外注に出す部分を決める際に役立つ気がしています。

外注だとやはり働く場所や時間が違いますから、リポジトリも完全に共通化するわけにはいきません。そこでマイクロサービス化で培ったやり方がそのまま使えますし、使うべきだというところですね。

長沢：
サービスがモノリスのときは、割と外注に出しにくいんですよね。リポジトリも１つですし、既存のリソースに接続しなければならないデータベースや検索エンジンがある中で、そこにネットワークに穴を空けて外部とつなげられるようにして良いかというと、会社のセキュリティ的に難しいことがあります。

ですからマイクロサービスでネットワークも分離できた方が外注には非常に出しやすい、むしろそういうサービスしか外注には出せません。リモートや開発子会社に出す場合も同じで、切り分けられた環境が好ましいです。

マイクロサービス化をした後でビジネス範囲が変わってしまうことはあるのか？

長沢：
では最後の質問です。ビジネス範囲が変わってしまわないようにしたいからこそ、ある程度ビジネスが軌道に乗ってからマイクロサービス化すべきかどうかという点も含めて、いかがでしょうか。一定規模にまで成長した組織にも当てはまる部分だと思いますが。

生内：
今の段階で当社がマイクロサービスに舵を切っているのは、僕がCTOという立場で経営陣に入っているからです。そういう人がいるなら、ビジネスがまだ軌道に乗っていない段階でもマイクロサービス化に踏み切れるかもしれません。

というのも、マイクロサービス化は経営練度を気にしながら進めなければならないという実感があるんです。このビジネスがどこに行くのか、行きたい方向に進むためにはどうするのかという問題ですね。マイクロサービスの中心に立つ人物が経営陣の中にいないとやりきれないと思います。

白石：
社外CTOとしてコミットしている会社に、とにかく多くのサービスを作るビジネスモデルの会社があります。この場合、サービスを横断した共通パーツとして抽象化できるものと、サービス単位で作っていくものがあまり交わらないんです。たとえばSaaSのサービスを作っても当たらなければすぐにサービスを閉じるという環境では、オーナーシップを継続的に持たせるのは難しいですし、マイクロサービス化は厳しいと思います。メルカリは全く逆で、一つのサービスを継続していくことが前提なのでやりやすい。その部分の差があるのは感じています。

イベントの最後に、flexyのfのポーズをしていただきました！大変勉強になる貴重なお話し、有り難うございました！

企画/編集：FLEXY編集部