asoview! TECH BLOG

アソビュー株式会社のテックブログ

組織とアーキテクチャとマーケットの話

この記事はアソビュー! Advent Calendar 2019 - Qiitaの25日目、最後の記事になります。

メリー・クリスマス

CPOの江部です。アドベントカレンダーもいよいよ最終回となりました。僭越ながらトリを務めさせていただきます。

自己紹介ですが、総じて事業・プロダクト両面において道のないところに道をつくったり、空いてるスペースに走り込んだりする役割を担ってきました。目の前の扉は蹴り破るスタイルを得意としています。

今回のお題ですが、ゼロからの組織立ち上げを経てある程度の組織規模となった現状に至る中で感じたことを吟じてみたいと思います。相当な乱文かつ少し抽象度の高い話になりますが興味のある方はご一読ください。

生産性の高い開発組織とは

生産性の高い組織であるために必要なことはなにかを考えたときに、数年前くらいからマーケット、組織、アーキテクチャの3つが統合できている状態じゃないかなーと考えるようになりました。 ちょっとわかりにくいかもしれませんが簡易的な図で表すと下記のようなイメージです。

f:id:jjebejj:20191224014103p:plain
理想の状態

顧客に対して提供するサービスの境界が明確であり、それをどの組織がオーナーシップをもって作り上げるのか定義されている状態です。

  • 誰の何の課題を解決すべきか明確
  • チームがシステム(コード)に対してオーナーシップを持てている
  • 影響範囲が特定できる
  • スピーディーに変化できる

のではないかと考えています。

逆に、この状態が歪んでいると、様々な組織課題が現れます。 個人的な感覚ですが、これまで私達が直面した組織課題はほとんどこの歪みが原因で発生しているように思います。

例えば。

組織の歪み

f:id:jjebejj:20191224021802p:plain
組織の不和
「フロント」、「バックエンド」など技術レイヤで区切られた組織の場合に起こりやすいかとおもいます。 これにより起こる問題として

  • チームメンバーが向き合う先がバラバラ
  • 案件ごとのアサインで受託マインドになりがち
  • チーム間の足並みや認識が揃わずプロジェクトマネジメントに失敗する など。

アーキテクチャの歪み

f:id:jjebejj:20191224021235p:plain
アーキテクチャの不和
例えば組織はマーケットの境界で区切られているが、システムはモノリシックなケースなど。

  • あるシステムに対して異なる目的をもった複数チームがそれぞれ修正を加えることになり、システムとしての品質を維持するのが困難になる。
  • システムのコードに関する所有権・オーナーシップ・責任が曖昧になる。気づいたらデジタル九龍城がそこに生まれる。
  • 影響範囲がわからない。触りたくない。
  • 触った結果障害が起こる。

統合の順序

ではなにをガイドラインにしてマーケット、組織、アーキテクチャを統合していくのがよいのでしょうか。 答えはそのビジネスやフェーズによって違うのかもしれませんが、すくなくともいまのアソビューで言えば

マーケットに従った組織によってアーキテクチャを変化させる

のが良いのではと考えています。

例えばアソビューの場合、マーケットとしては大きく分けるとゲスト(消費者)、パートナー(レジャー事業者)、代理店(OTA・旅行代理店・媒体など)があり、さらにゲストはチャネル別、パートナーは商品別、代理店は業種別に分けられます。

これらは異なるKPIやビジネスライフサイクルでアプローチされるわけですが、それぞれに対して明確な責任をもったチームが組まれ、そのチームにおいて事業目標達成の手段としてアーキテクチャを最適化していくことにより、マーケット、組織、アーキテクチャが統合されていくというシナリオが理想かと思います。(まさにコンウェイの法則です)

分解ではなく凝集

得てしてスタートアップのサービス開始当初はエンジニア人数も時間も制約があるなかでモノリシックなアーキテクチャで構築されがちです。 それ自体はもちろんそのタイミングでは正解なのですが、事業成長し組織が複雑化するにつれアーキテクチャやコードが最後に変化に取り残されていきます。

そのアーキテクチャを最適化しようとする時、マイクロサービスの導入を検討するわけですが、往々にしていかに最適な要素に分解するか、という視点で議論しようとする向きがあります。誰かが横軸の技術視点で分解、整理することにより技術最適化を図ろうとしてしまいがちですが、そうではなくそれぞれのマーケットに従ったチームが自らのビジネスドメインに基づいて凝集させていくほうが、長期的に整理が付きやすく、実際にそれに向けてプロジェクトが動きだすことが多いです。

ここでいう凝集とは、ビジネスドメインを整理し、それを実現するシステムに必要なサブシステムや関連システムのデータ、機能などを取り込んでいくことにより最適なアーキテクチャをビルドアップしていこうというアプローチです。

一方の分解とは、様々なデータや機能が含まれるモノリスを、ある基準に従って境界線を引きながらマイクロサービスに切り分けることによってアーキテクチャを最適化しようという思考パターンです。

技術視点での分解は、機能的な重複がきれいに整理され一見効率のよいアーキテクチャのように見えますが、往々にして上述のような組織とマーケットとの乖離を起こします。 一方、ビジネスドメインに基づいて凝集させていく考え方であれば、ある程度のデータや機能の重複は随所に起こるものの、それぞれがマーケットや組織と連動した形となり、結果ビジネスやオペレーションを含めた全体視点でみると効率的となります。そして、それによって単なるアーキテクチャの最適化プロジェクトとしてぶち上げられるのではなく、具体的な業績向上、業務効率化を目的としたプロジェクトとして打ち出すことができ、エンジニア以外のチームやメンバーと目線を合わせて進めやすくなります。

(ちなみに、マーケットと表現するとSoE (System of Engagement)に限定された議論に捉えられやすいかもしれませんが、例えば基幹系システムなどSoR (System of Record)的なシステムでも、社内の運用部門をシステムやチームにとっての顧客ととらえれば同様の考え方が適用できます。)

あくまでマーケット起点での組織、アーキテクチャであるべきであって、既存の組織の形や技術的な効率だけを理由にしたアーキテクチャの設計、とくに異なるマーケットにまたがった低レイヤーの統合は、恒常的にアーキテクトチームなどが保守できる体制でなければなるべく避けたほうが懸命です。

さいごに

かなり纏まりのない文章になってしまいました。

まあこれは多分に理想論なので、人がたりないスタートアップだとどうやってもそんなきれいにはいかないよーとかあると思います。 我々も試行錯誤の連続のなかで振り子のように行ったり来たりしながら最適解を探し続けている状態です。

が、いろいろな組織課題に悩まれているマネジメントレイヤーの方々に、少しでも思考の整理や今後の方向性を考える上でなにがしかのヒントにつながればと思い書いてみました。

では、みなさん良いお年を。 来年もアソビューをよろしくお願いいたします!