組織を考慮してアーキテクチャとシステム運用を改善する
前回の記事で軽く触れていますが、現職 Ubie では症状検索エンジン「ユビー」の、リアーキテクチャを計画しています。
さらに冒頭で触れたアーキテクチャ図は我々の理想にはあまり沿っておらず、特に肥大化している FE 、 BFF 部分に関してはモジュラーモノリスに置き換えていく構想もあります。このようなリアーキテクチャ活動にどうシステム運用を装着していくかも課題の一つになっていきます。
本記事では特にこの BFF 部分に言及しますが、リアーキテクチャの方針としてモジュラーモノリスへの移行を検討しており、実現に向けた検証が今月から始まっています。 この取り組みが功を奏せば、前述の記事で言及した信頼性向上のためのアクションが取りやすくなるのはもちろんながら、プロダクトの開発生産性も向上することができるでしょう。
合わせて考えるべき組織の話
モジュラーモノリスとして引き合いに出されるのはやはりマイクロサービスアーキテクチャでしょう。 マイクロサービスアーキテクチャでは典型的にはドメイン毎に分割されたサービスを持ち、サービス毎に異なるチームで開発・デプロイ・運用を行えます。 ここでよく、マイクロサービスをどう切るかがが問題となり、コンウェイの法則に従いマイクロサービスに関わる組織をどう設計するかへ波及します。 アーキテクチャとしてはよりシンプルで開発・ネットワークコストの少ないモジュラーモノリスでも、モジュールをどう切るかの問題は発生して、ひいては組織をどうすべきかの問題から逃げられません。
組織に関する課題を考える上で、 Ubie においてはホラクラシーの導入などの効果により各メンバーが組織に対して強い関心を払っているのが効いてくると感じています。 誰かが組織をいい感じに整えてくれるのを待つ（あるいは自分がいい感じにして整えたものを皆に下ろす）のではなく、自発的に組織課題に向き合うメンバーばかりが揃っています。 それゆえモジュラーモノリスへのリアーキテクチャとそれに伴う組織への影響も、独りよがりなものにならず意見を反映させた形に持っていきやすいです。
一方で Ubie ならではの難しさもあると予感しています。 Ubie のプロダクト開発組織ではチームトポロジーの導入が進んでおり、実際に症状検索エンジン「ユビー」を取り巻く組織構造はチームトポロジーの考え方を反映したものになっています。 （ちなみにチームトポロジー導入前は、組織構造が大きく変わりプロダクトに及ぼす影響が甚大で、たとえばある機能に関心を払っていたチームが解散して誰もオーナーシップを持っていない状態になるなどの問題も起こっていました）
チームトポロジーの導入により明確に長生きすべきストリームアラインドチームが可視化されました。 一方で Ubie のプロダクトはまだまだ発展途上にあり、プロダクト開発も激しさを増していきます。 これを支える組織構造も引き続き、安定した箇所はありつつも変化が激しい箇所も存在し続け、チーム間のコミュニケーションも刻一刻と変わっていきます。
組織を意識しながらリアーキテクチャを進める
コンウェイの法則によると、組織のコミュニケーション構造はシステムの設計に影響を及ぼします。 チームトポロジーに従って安定を見せた箇所はありますが以前としてコミュニケーション構造は変わりやすく、リアーキテクチャではこれを念頭に置いた上で行えると良いと考えます。 （まあこの辺の変わりやすい性質を考慮してモジュラーモノリスという選択肢を選んでいる側面もあり、変化に合わせて柔軟にあるべきアーキテクチャを更新するのはありそうですが）
冒頭で述べた通りリアーキテクチャではプロダクトの開発生産性を改善したく、実際にプロダクト開発に携わるチームに価値を届けなければなりません。やっていくしかない！
最後に、アーキテクチャと組織の両面を意識しながらプロダクト開発を邁進できる仲間を圧倒的に募集中ですので、何卒何卒！！！
