食べログの大規模なエンジニア組織を段階的に改善していく取り組み

こんにちは、食べログシステム本部長の京和です。

昨年のアドベントカレンダーでは 「食べログの大規模なレガシーシステムを段階的に改善していく取り組み」 と言う記事で技術的な取り組みを中心に紹介しました。
今年のアドベントカレンダーでは、食べログのエンジニア組織を段階的に改善していく取り組みについてご紹介します。

食べログの組織構造

食べログの組織はシステム、営業、ビジネスと言った機能ごとに組織が分かれる、いわゆる機能別組織の組織構造を採用しています。

2021年12月現在の食べログの組織は、公式な組織図としては上記の機能別組織を維持しながら、内部ではマトリクス型組織の要素を一部に導入したハイブリッドな組織形態となっています。

今も試行錯誤中の段階ではありますが、現在に至るまでの変遷を、

1. システム部門を機能別組織として最適化する
2. マトリクス型組織によるクロスファンクショナルチームの導入
3. 「冒険者と武器屋型モデル」による部門間の協調的な取り組み

と言う3段階に分けてご紹介していきます。

1. システム部門を機能別組織として最適化する

まず、私が入社した当時のシステム部門の組織は以下のような組織構造になっていました。

この2部門の中に、食べログ事業の運営に必要な様々なチームが集約されていました。この体制は下記のような構造的な課題を抱えていました。

1. 1部門内にサーバーサイド・アプリ・新規事業と言った利用者や技術領域の異なるチームが混在しており、部門としての責務が不明確
2. 1部門あたりの人数が多く、扱うドメイン・技術領域も様々であるため、部門長が全体を把握することが困難
3. それぞれの部門に運用を担うDevOpsチームが存在しており、全体最適観点からのシステム改善が行われづらい

このような背景から、食べログが事業として提供しているシステムを機能ごとに改めて整理し、さらには技術的負債やレガシーシステムの改善を組織的に進めていくために、組織を下記のように変更しました。

それぞれ名前の通り、ユーザー向けのウェブアプリケーションを開発する部門、ユーザー向けのiOS/Androidアプリを開発する部門、飲食店向けのウェブアプリケーションや予約在庫管理、販売管理など基幹系のシステムを開発する部門、食べログ仕入や食べログモールといった新規事業のシステムを開発する部門、技術開発や運用を行う部門、という構成になっています。

技術部門の設立については2019年のアドベントカレンダーで私が投稿した「技術部門にOKRを導入したら3ヶ月で部の雰囲気がめちゃくちゃ良くなった話」でも詳しく書かれていますので、よろしければご覧ください。

この変更によって、食べログのそれぞれの領域でいくら投資していて人が何人いるのかが分かりやすく可視化される、所管部門の責任が単一になることで、部門の役割と期待する成果が明確になる、と言った効果がありました。
ただ、事業開発を担う部門ではこの組織変更によって明確な成果が生まれたわけではありません。ですが、このように機能別に整理しておくことによって組織の見通しがよくなり、次のステップとなる組織的な改善を進めやすくするための布石として大事な一歩になっています。

2. マトリクス型組織によるクロスファンクショナルチームの導入

機能別組織におけるサイロ化という課題

機能別組織における最も大きな課題の一つが組織のサイロ化です。機能別組織では、プロダクト開発のライフサイクルにおけるそれぞれの工程において、各工程を所管する部門ごとに責任範囲が分割されます。

その結果、それぞれの部門内での運用は最適化されていくものの、部門間の調整・コミュニケーションコストが増加していき、全体として見ると非効率になっていきます。また、情報が部門内で閉じがちなため、他部門が何をしているのか見えづらい状況にもなります。食べログでもこうした課題があり、エンジニアからは受託っぽい、といった声が挙がっていました。

ミッションに関わる開発サイクル全体に責任を持つプロジェクトチームの組成

上記の課題を解決するために、食べログではマトリクス型組織を導入しました。マトリクス型組織では、職能横断で構成される複数のクロスファンクショナルチームがそれぞれミッションとKPIを持ち、ミッション達成に向けた開発のライフサイクル全体に責任を持っています。

例えば検索改善プロジェクトと言うチームでは、「飲食店を探しやすいサービスNo.1になる 」というミッションを掲げ、「ガッカリ体験をなくす」ということを目標にKPIを設定していました。具体的には検索結果の0件ヒットをユーザーにとってのガッカリ体験に繋がる一つの指標とし、それを改善していくといった形です。

また、いきなり食べログ全体で導入するのではなく、まずユーザー向けのメディア領域で進めることにしました。システム部門においてメディア領域を所管するのは、1段階目で紹介したウェブ開発とアプリ開発の部門です。予め機能ごとに部門を整理しておくことによって、こうした取り組みをする際に、組織が不自然な形になることを防ぐことができています。

導入にあたっての工夫点

次に、マトリクス型組織の導入にあたって工夫した点をご紹介していきます。

①レポートラインの整理

マトリクス型組織の事例として近年最も有名なのはSpotifyモデルでしょう。日本でもSpotifyモデルを元にマトリクス型組織を導入した事例を定期的に見かけます。しかし、Spotifyモデルは 「Spotifyは ‘Spotifyモデル ‘を使っていない」 で書かれているように、幾つかの根本的な課題を抱えています。
その中の一つが調整に関する問題です。以下、上記のブログより引用します。

エンジニアリングチーム内で意見の相違が生じた場合、プロダクトマネージャーはチーム内のすべてのエンジニアと交渉する必要がありました。エンジニアが合意に達することができなかった場合、プロダクトマネージャーは、チームにいるエンジニアの専門分野の数だけ、エンジニアマネージャー（チャプターリード）にエスカレーションする必要がありました。バックエンド、ウェブアプリ、モバイルアプリのエンジニアがいるチームには、少なくとも3人のエンジニアリングマネージャーがおり、彼らを巻き込む必要があります。これらのエンジニアリングマネージャーがコンセンサスに達することができない場合、1つのチームの問題は、部門のエンジニアリングディレクターにエスカレーションする必要がありました。

マトリクス型組織では機能軸のマネジメントラインと事業軸のマネジメントラインが同時に存在することによる調整の難しさを構造的に抱えており、Spotifyモデルの事例は正にそれが表面化した形と言えます。
食べログではこの問題に対して、下記のアプローチで回避しています。

• クロスファンクショナルチーム内のエンジニアリング全般に責任を持つエンジニアリングマネージャを設置する。
• 可能な限りチームに権限を委ね、チーム内で意思決定を完結させる。人に関わる問題は採用などで回避し、リソースの移動などは必要最小限に抑える。

つまり、実態としてクロスファンクショナルチームは、それぞれが持つミッションやKPIの達成を目的とする事業型組織に近い構造となっています。
食べログでは機能別組織で長らく運用されてきたこともあり、職能単位での横の連携が自然と行われる習慣が根付いているという点や、後述の「冒険者と武器屋モデル」によって、組織全体での技術的な取り組みを担保・推進していることから、このような組織形態を採用しています。

②業務プロセスの見直しとITツールの共通化

機能別組織では、タスク管理やドキュメント管理などもそれぞれの部門で行われる事が一般的です。食べログにおいても同様で、企画は企画部門でタスク管理を、システム部門はシステム部門でタスク管理をしており、他部門の状況を見る機会はあまりありませんでした。

組織を変える際には、組織構造の変化に合わせて日々の業務プロセスやツールなども見直す必要があります。食べログではマトリクス型組織の導入に合わせて機能別の部門単位ではなく、クロスファンクショナルチーム単位で仕事を管理するために、各種のツールの運用見直しも行いました。

幾つか検討した結果、食べログではAsanaを新たに導入し、共通のツールとして利用することにしました。Asanaを選定した理由は大きく以下の3点です。

1. AsanaではAsana上に組織やチームの構造をそのまま再現し、その単位ごとに仕事を管理することができる
2. 企画案件のプロジェクト管理だけでなく、チーム運営にまつわる幅広い業務を管理できる
3. 各チームごとのカスタマイズが容易で、柔軟に業務プロセスを設計できる

*図: Asanaのチーム構造（[Asana を使って仕事をシステマティックに組み立てる方法](https://blog.asana.com/2020/05/ja-asana-tips-structure-work/) より引用）*

具体的には、日々のタスクやプロジェクトの管理に加えて、「プロダクト改善アイデアボード」や「振り返り」などチーム運営にまつわることも含めてAsana上では管理されています。また、チームを横断して見る必要のあるメール配信のスケジューリングなどもAsanaで管理しており、これら以外にも各チームで独自の業務改善が日々行われています。

ツールを共通化するという制限を加えつつ、ツールの運用そのものはなるべく各チームの裁量に任せることによって、チームごとの自律性を維持しながらチーム間での仕事の進め方のギャップが大きくなりすぎないよう、バランスが取れた状態になるように設計しています。
チームによってはAsanaがフィットしないケースもあるなど幾つか課題はありましたが、マトリクス型組織外の技術部門でも活用が進み、Asana社の株を買うほどの熱狂的なファンも生まれるなど意外な効果もあり、全体としては概ね満足しています。

③目標設定ガイドラインの策定

マトリクス型組織の導入以前は、エンジニアにとってはコントローラブルではないという理由で事業にまつわるKPIは目標として置かない運用としていました。しかし、クロスファンクショナルチームでは積極的に事業にコミットメントすることが求められます。そうした組織環境の変化に合わせ、目標設定を通じてプロダクトへのオーナーシップを高めるために、クロスファンクショナルチーム向けに目標設定のガイドラインを策定しました。

ガイドラインではプロジェクト目標、パフォーマンス、スキルの3つを基本とし、事業軸・機能軸それぞれの観点で評価できるようにしています。
また、目標設定と評価のタイミングでPMやEMからフィードバックを受けられるようにもしました。職能間での相互理解を深め、事業面だけでなくエンジニア個々人のキャリアや成長も加味して担当業務を設計できるようにしています。

まとめ

マトリクス型組織の導入から1年と数ヶ月が経過しました。導入当初は戸惑いの声もあり、変化に対して疑問を持つ人も少なからずいたように思います。しかし、お互いの状況が可視化され、開発関係者が一つのチームとしてこれまでより近い距離でコミュニケーションしながら連携するようになったことで、徐々にプロダクトに対するオーナーシップが高まってきています。
まだまだ解決すべき課題はありますが、ワンチームとなってミッションに向かっていける体制へと少しずつ前進している実感があり、以前よりも事業が目指すべき姿に向かってスピード感を持って仕事を進められるようになってきています。

3. 「冒険者と武器屋型モデル」による部門間の協調的な取り組み

最後に、1段階目で紹介した技術部門と、2段階目で紹介したクロスファンクショナルチームの連携についてご紹介します。
事業開発を担う部門と技術開発を担う部門間のインタラクションデザインは、組織設計において極めて重要なポイントです。相互の部門が主体性を持ちながら、協調的に取り組むための考え方を、私は「冒険者と武器屋モデル」と呼んでいます。

技術部門は、冒険者である事業部門を担うエンジニアたちに、彼らの課題を解決するための武器を提供します。ただし、敵を倒す = 課題を解決する 主体は、あくまでも冒険者自身です。
RPGを元にしたこのメタファーは多くの人にとって馴染みがあり、関係性がイメージしやすく覚えやすいため、共通認識を揃えるためにこのような表現を使っています。

事業部門と技術部門間でよくある問題

一定規模以上の事業において、このようなやり取りをご覧になった方は多いのではないでしょうか。こうした問題はなぜ起こるのでしょうか？様々な要因を含んでいますが、構造的な問題として、チームの責務（やりたいこと）と遂行能力（できること）の不一致があると考えています。

事業開発を担うエンジニアは、スケジュールどおりに機能を開発するだけでなく、ユーザーにより良い価値をより速く提供し、事業要求に応えるために、自分たちが運用するシステムを磨いていく責任があります。
しかし、事業部門が日々の開発や運用を行いながら、新しい技術の検証や、新技術導入に伴う広範な影響範囲を調査し、改修を進めていく時間を確保するのは困難です。一方で、技術部門を担うチームでは、技術検証ができたとしても、実際の改修に際して必要となるコンテキストやドメイン知識を有していないため、彼ら自身の責任で改善を進めていくことが困難です。

冒険者と武器屋モデルでは、それぞれが実行能力を有している範囲に責任を整理することで、この構造的な問題を解決しています。

おすすめ武器の紹介

上記の考え方に基づき、今年は様々な取り組みが実現されました。その一部は今年のアドベントカレンダーに掲載されていますので、ぜひ目を通してみてください。例えば、「ビッグデータ分析基盤の刷新」、「Pub/Subメッセージング基盤の刷新」、「Cloud NativeなCI/CDパイプライン」、「テスト自動化のアーキテクチャ設計」、といった記事があります。また、今年の記事にはなりませんでしたが、現在進行中の取り組みとして、API GatewayやGraphQLの導入なども進んでいます。

ちなみに今回、特にイチオシと言える技術が Change Data Capture（CDC）です。CDCは簡単に言うと、DBの変更を検知しリアルタイムでイベントストリームに変換する技術です。食べログではレストラン検索のインデックス更新処理にCDCを採用し、約100倍高速化しました。詳しくは「食べログのレストラン検索を支える Debezium と Apache Kafka」 をご覧ください。

CDCはその特性から、様々な領域に応用が可能です。例えばビッグデータ基盤におけるセミリアルタイム更新であったり、ビジネスで即時性が期待されている領域での活用を今後検討しています。また、マイクロサービス化に向けたデータベースの分割（書籍 「モノリスからマイクロサービスへ 」で紹介されています）においても活用事例があります。

技術的負債に対する組織の向き合い方

組織として技術的負債やレガシーシステムの改善を進める上で、私が心がけている事が一つあります。それは、「技術的負債」や「マイクロサービス」と言う言葉を安易に使用しないということです。

技術的負債も実際には巨大な化け物に見えますが、本質は１つ１つの小さな（非機能系の）課題です。それは、機能増大や環境変化による既存システムがもっている設計上の前提と、現実のギャップが積み重なって生まれたものです。
「技術的負債」への処方箋と「２つのDX」 - Qiita

上記の記事の引用にもある通り、技術的負債とは大きな一つの塊があるのではなく、実態は1つ1つの課題が積み重なった集合体です。技術的負債やマイクロサービスは便利な言葉ではありますが、一方で、そうした解像度の粗い言葉に頼ってしまうことで、手段の目的化や、目的に対する手段が過剰になるオーバーエンジニアリングな状態、また投資に対して得られる価値が見合わない意思決定に陥る、と言ったリスクがあると感じています。「マイクロサービス化ですべての課題をまとめて一緒くたに解決しようとする」みたいなのはその代表例と言えるでしょう。

技術的負債の返済は、それ自体を目的とするべきではなく、あくまでもビジネス上の課題解決につながるものであるべきです。技術的負債の1つ1つを見極め、それをビジネス上の課題に紐付けることが重要です。そうすることで、事業を担うエンジニアにとっても手触りのある課題だと感じられるようになります。その結果、お互いが手を取り合い、協力的な関係を築きながら、ビジネス面、技術面のどちらにとっても価値のある、理想的な取り組みを進められるようになるでしょう。

おわりに

大変長くなりましたが、食べログのエンジニア組織を段階的に改善していく取り組みについてご紹介してきました。

機能別組織はしばしば「縦割り型の組織」として、セクショナリズムやサイロ化につながるネガティブな組織形態として捉えられます。私も入社前は一定そうした印象がありました。
しかし、食べログが現在技術的負債の返済やクラウドネイティブ化、ITツールなどのインフラ基盤にしっかりと投資できているのは、機能別組織としてエンジニアが十分な予算や裁量を持っているからに他なりません。

組織が長期的に競争力を維持し、優位性を築いていくためには、事業開発と技術開発を車の両輪として、どちらもバランスよく推進することが肝要です。そのような組織を実現するためには、機能を軸にした組織、事業を軸にした組織のいずれであったとしても、もう一方を補完する両面的なアプローチが必要になってくるでしょう。
そのように考えると、機能別組織と事業別組織に優劣はなく、いかに両者の長所を活かしつつ、短所を克服していく工夫こそが重要だと言うことなのだと思います。

そうした状態を実現するためには理想を描くことも必要ですが、まず何よりも重要なのは、自社の事をきちんと知ることです。組織は様々な要因によって構成される複雑なシステムで、正解はそれぞれの組織ごとに異なります。どんな病気かわからなければ、薬は処方できません。また、車を1速から6速にいきなり上げることはできないように、組織も理想の形に近づくためには段階を踏んでいく必要があります。理想像を描くこと自体はそれほど難しくなく、AsIsからToBeへと至る橋をどう設計し、それをどう実行に移していくかの方が圧倒的に難しいと実感しています。

近年、組織運営に関する書籍の出版も増えてきており、12月には「チームトポロジー」と言う界隈で話題の書籍も邦訳されました。日本においても組織マネジメントの重要性は今後ますます高まっていくでしょう。食べログでもそうした書籍や他社事例を参考にしながら、今後も組織の改善を続けていきたいと思います。