カミナシ✕クラウドサイン『憧れのマイクロサービスと愛すべきモノリスの話』イベントレポート 前編

テクノロジーの力で“現場”や“契約”といったレガシーな分野のDX化をリードし続けているカミナシとクラウドサイン。 そのプロダクトを成長させていく中で避けて通れないのがマイクロサービス化とモノリスの壁、そしてセキュリティの問題です。

2022年10月に、両社のエンジニアリングを牽引するリーダーがフリートーク形式でこれらのテーマについて語るイベントを開催しました。 サービス分割やセキュリティを推進する上で出てきた課題や悩み、これまでの取り組みにおける苦労話など、ざっくばらんなディスカッションを前編と後編に分けレポートします。

イベントページはこちら：https://bengo4.connpass.com/event/261242/

【スピーカー紹介】

• 株式会社カミナシ

  • 原 トリ／執行役員CTO
  • 宮本 大嗣／エンジニアリングマネージャー

• 弁護士ドットコム株式会社

  • 井田 浩義／クラウドサイン事業本部 Product Engineering部 部長

【当日のアジェンダ】

1. LT「カミナシの開発組織の現在地 〜個人集団からチーム化へ〜」 カミナシ by 宮本 大嗣
2. LT「クラウドサインの歴史とこれから」 クラウドサイン by 井田 浩義
3. フリートーク「憧れのマイクロサービスと愛すべきモノリスの話」「セキュアでありたい話」 by 原トリ・井田 浩義

Lightning Talk①：「カミナシの開発組織の現在地 〜個人集団からチーム化へ〜」 カミナシ by 宮本 大嗣

まず最初のLTとしてカミナシのエンジニアリングマネージャーである宮本さんから、 現時点でのカミナシ開発組織の実態についてプレゼンテーション。 カミナシのサービス内容、現在の導入実績などを紹介していただきました。

宮本さんがジョインした2021年8月から新しいプロダクトの開発プロジェクトがスタート。 エンジニアが2つのチームに分かれたことで人数が減り、宮本さんが既存プロダクトの開発要望のハブとなって全体をコントロールする体制に。 メンバーの個人技でなんとか回していた時期だったと振り返ります。

その後、2022年の5月には新プロダクトの開発が白紙に。 当該プロジェクトメンバーがカミナシ開発チームに戻り再調整があり、エンジニアの思いを汲み技術的負債解消に集中する時期を迎えます。

そして翌7月からはスクラム開発の概念に基づき、優先順にタスク着手する体制を構築。 当初は上手くいかない点もありましたが9月半ばぐらいからようやく安定稼働の波に乗れてきたそうです。

「ようやくチームとして動ける状態ができはじめた段階だったのですが、実はいま、チームを分割したいという声がエンジニア陣から出ています。 実は2022年7月に半年かけて技術負債解消というテーマをいただいたのですが諸々進められていない点がありまして。 そこにきちんと取り組むべきではないか、という声がエンジニアから自発的に出てきたんです」

(※ 2022年10月時点での状況のため、実際の状況とは異なる場合がございます。)

現在はこの声に沿ってチーム分割の検討に入っているとのことでした。

このチーム分割がシステムにどう影響を与えるのか…後編のフリートークでも触れていきます。

Lightning Talk②：「クラウドサインの歴史とこれから」 クラウドサイン by 井田 浩義

続いてのセッションはクラウドサイン Product Engineering部 部長の井田より、クラウドサイン開発現場の歴史とこれからについて語っていただきました。

2022年10月で7周年を迎えたクラウドサイン。 プロダクトが早いスピードで成長拡大する中で開発部隊にも変化が迫られている、と井田は言います。

「社員数、導入社数、そして売上の3つが増えるというグッドスパイラルの中で、 これまでモノリスで作ってきたプロダクトのメリット／デメリットが顕著になってきました。 ここからさらにスケールするにあたって、この大きさのモノリスをどうすればいいのか。 頭を悩ませつつマイクロサービスの話を聞いたり、うんうん唸っているところです」

さらに大企業や地方自治体へのクラウドサイン導入が進み始める中で、セキュリティをどのように担保していくか、 という挑戦も開発陣の眼の前に立ちはだかります。

クラウドサインの次のステップとしては、“契約マネジメントプラットフォーム”への発展を考えています。

「契約締結から一歩踏み出して、どうしたら書類が使いやすくなるか。 どうしたら締結した書類を検索、閲覧できるのかといった契約管理の文脈へ踏み出していきます。 そして専門知識や専門家の介在を極力抑えるシステムで電子契約そのものの成長を目指します」

クラウドサインではすでにチーム分割は済んでおり、ここからマイクロサービスを導入すべきかどうかという壁に挑んでいます。

フリートーク「憧れのマイクロサービスと愛すべきモノリスの話」「セキュアでありたい話」 by 原トリ・井田 浩義

さてLTも終わり、ここからはイベントタイトルでもある「憧れのマイクロサービスと愛すべきモノリスの話」を題材にしたフリートーク。 カミナシからは執行役員CTOの原トリさん、クラウドサインからはLTセッションから引き続き井田が登壇します。

コンウェイの法則と逆コンウェイの法則

クラウドサインのLTを聞いて、2～3年後にやってくるであろうカミナシの組織拡大における課題を重ね合わせてヒリヒリしたというトリさん。 組織のスケールが問題の起点となると言います。

トリ：理屈としても経験則からも“コンウェイの法則と逆コンウェイの法則”を強く信じています。だから組織を分割するときシステムも割らなきゃ、ってなるんですよね。 で、システムを割る時に文脈として出てくるのが凝集性と疎結合性。 ここが最初から考えられているシステムとそうでないシステムとでは割る時のハードルに雲泥の差が生まれる。

カミナシのシステムには圧倒的な凝集性を保つモノリスが鎮座していて、簡単に割れないそう。 そのあたり、クラウドサインはどうなのかと問いかけます。

井田：いまクラウドサインではコンウェイの法則は割と無視していて、現状は複数のスクラムチームがひとつのモノリスを触っている状態です。 ただ、やはりここから先のスケールを考えると、どこかのタイミングで割らなきゃ、という議論が浮かんでは消える最中なんですよね。

井田曰く、クラウドサインは契約書を扱う文脈から書類情報を持っていて、最終的に切っても切れないところがどうしても出てきてしまうとのこと。

トリ：複数のチームに割って、それぞれが自律的に価値提供できるようになるにはチーム間の依存関係を断ち切らなければなりません。 独立してデプロイができるとか、独立してデータベーススキーマを変えられるみたいな。 でも多くの組織はシステムは単一のままチームだけ割っていこうとする。

トリさん曰く「途中でシステムを割るほうを諦めてしまう」ケースも少なくないようです。

よくできたモノリスが大好き

マイクロサービスの台頭に伴い「モノリス＝悪」という主張が散見されますが、実はトリさんはモノリスが大好きだといいます。 「特に単一のデプロイメントでありながら内部的には責務が分解されている、よくできたモノリスが好きなんですよね。」 しかしそうしたモノリスであってもメンバーが増えるとコンフリクトが発生したり、ビジビリティの低下は不可避。 結果として割らなければならないことにジレンマを感じるそうです。

その話を受けて井田は

井田：システムを分けていくときの危なさ、見えなさというのはありますね。 システムに矛盾、というか致命的な立ち行かなさが生まれる瞬間ってある。 ドメインへの理解不足や、あるいは充分理解した上での設計だけど考慮が漏れててそれが致命的だったりとか。非常に高度な設計の理解が必要になりますよね。

トリさんはさらに「システムを分けるときに組織をスケールさせる目的以外にも視点がある」と指摘。 例として「アクセスパターンに応じて柔軟にスケーリングできるようにするためにシステムを割りたいとか、コードの変更が多くてデプロイ頻度が高いところとそうでもないところを分割したいとか」と挙げながら、クラウドサインにはこういったシステム面からの“分けるニーズ”はあるのか、と質問。

井田：いまはあまりニーズはないですね。とはいえ可能性は充分あるなと認識していて、契約の締結そのものと契約書類管理は分けられるんじゃないか、という議論はありました。 結局、そこのコアに潜んでいるのが書類情報だったことから、やはりそこは分けられないんじゃないかとなったんですよね。

クラウドサインの場合、何かをやろうとすると絶対に書類情報を参照することになります。 と、なるとシステムを分割しても2つのデータベースにまたがるQueryが発行されるので、そもそも分ける意味がないのでは、という検討に至っています。

ただの自己満チーム分割を防ぐために

「カミナシはまだシステム的には割る事を考えなくてもいいかも」と語るトリさん。 組織のほうはチームを分割したいモチベーションが強く出ていたので現在検討に入っているとのことでした。

トリ：チームを割ったときにコードベースを共有したくないんですよね。インフラまで含めて。完全に自律的に動けるチームにしないと割る意味が薄れてしまう。 割ると複雑性が確実に増します。 それでも割るならそのリスクとデメリットを受け入れて余りあるメリットを享受できないと、ただの自己満チーム分割になってしまいます。

たとえば複数のチームの朝会が終わった後に認識合わせを目的にクロスチーム朝会をやりはじめたりする。 これではチーム分割の意味がないし、コード共有の事故も完全には防げないというのがトリさんの持論。 その意見に対して井田は

井田：ラージスケールスクラムでもそれをよしとしてやってるところありますよね。 結局、昼会やチームMTGのあとに各スクラムマスターが持ち寄って、共有や連携を取るみたいな形で動かすフレームのプラクティスもあります。 そういうことをやっていかないとシステムの都合とチームの都合との織り合わせが難しいのかも。

トリ：ラージスケールスクラムは確立された方法論だと思っていて、否定するわけではないんですが…話題が出るたびにそれって本当にラージスケールなの？って思う。 一億人がアクセスしているWebAPIというなら大規模だけど。 複数チームを自律的に走らせられないぐらい複雑性のある大規模システムって世の中にそんなに存在しないはずで。

それって痛みを受け入れて前に進むことをあきらめているのではないか？考えることを放棄しているだけなのではないか？とトリさんは問題提起します。 井田も自律的に動けるようになるために何ができるのか、を考えるのがエンジニアの頭の使い所ではないかと提言します。

依存関係のない情報共有は大事

さらに井田は「サイロ化の問題についてはどうお考えですか？隣のチームが何をやっているのかわからないというのと、自律的に動くのをどう両立させるのか。どう推進できるのか。」 とトリさんに質問。トリさんは前職での経験を引き合いに出しながら

トリ：お互いのチームが様子を伺いながらじゃないと前に進めないのはダメ。 ただお互い何をやっているかというナレッジの共有はやらなきゃいけない。チーム間の依存関係ありなしとチーム間での情報共有というのはそれぞれ別の話です。

システム分割して各チームにオーナーシップを確立していくのであれば、個人的には「ウチのリポジトリには触れてくれるな」ぐらいまでいきたい、とはトリさんの弁。

トリ：APIを相互に呼び合っているとして、なんかAPIがおかしいと。 仕様に書いてある挙動と違うんだけど、となったとき、コードを読みにいくのはいいとしてもそこで直すプルリク投げるのは間違っていると思っていて。 コードだけ投げてあとは運用よろしくではダメなんですよ。

相手チームのAPIが仕様と違う動きをしているのであれば、再現手段をイシューに書いて、相手に直してもらう。 それぐらいの依存関係の切り方をすべきだ、というのがトリさんの主張でした。

井田：自分たちが直すという文化から「チームの所有物はチームでメンテナンスしていきましょう」という責任の分解点を分けるというのは一つの姿ですよね。

トリ：前職にはアウェイチームと言う概念があって。向こうのAPIに手を入れたい。だけどリソースがないと言われる。 だから自分のチームからそちらのチームに人を出すので、彼に触らせてやってくれ、と。そういうことをやってましたね。それでだいたいスケジュールが遅延するんですけど（笑）。

井田：確かに外から見るとなんで直さないの？になるけどチームからすると歴史的背景もあるからそう直されちゃうと困る、みたいな。 そういうコミュニケーションをやらないためにもアウェイチームがあったのかと拝察できますね。

そしてトリさんが「結局、モノリスもマイクロサービスも難しい」と要はバランスおじさんよろしく結論づけました。

最後に「クラウドサインもカミナシもシステムをどう割るかで苦しんでいる中、試行錯誤した話が今後お互いのブログで出てくると思うので、みなさん続報を楽しみにしてください」と加えてひとつ目のテーマ「憧れのマイクロサービスと愛すべきモノリスの話」を終了しました。

イベントレポートは後編に続きます。