はじめに
こんにちは。食べログ飲食店システム開発部でエンジニアリングマネージャーをしている井本です。
今回は私の所属している予約サービスチームをサンプルにし、以下のような内容を紹介します。
- 食べログのエンジニア組織、所属チームで起きていた課題
- 食べログエンジニア組織と予約サービスチームについて
- 予約サービスチームの組織編成の工夫について
- チームで行なっている情報共有の工夫
この記事が組織編成や仕組みを考えるヒントになれば幸いです。
食べログのエンジニア組織、所属チームで起きていた課題
複数の開発チームにまたがる開発の課題について
我々が所属している食べログは、年々ネット予約の利用人数が増加しております。
大変喜ばしい状況ですが、ビジネスの拡大に追いつくため、組織も対応していく必要が出てきています。
特に近年ではエンジニア組織も拡大し、複数の開発チームにまたがり開発する機会が増えました。
複数チームでの開発が多くなることで以下の課題が発生しました。
- コミュニケーション上や情報伝達のコスト増大
- チーム間情報の温度感が適切に伝わらず、問題の解消が先送りになる傾向がある
- ビジネス拡大の速度に対して、開発スピードが追いつかない
開発スピードアップのため、現在様々な取り組みが行われています。
こちらの記事もよろしければ合わせてご一読ください。
予約サービスチームの課題
我々が所属している予約サービスチームも同じように組織拡大における様々な課題が存在します。
- チームの業務分掌拡大への対応
- チーム内コミュニケーションが行き届かずポテンヒット（誰も確認していなかった事象）への対応
- 意思決定のスピードアップが必要
- チーム内のドメインエキスパートをいかに増やすか
これらに対しどのように工夫して取り組むか、次項以降で説明します。
食べログエンジニア組織と予約サービスチームの体制例
食べログのサーバーサイドエンジニアの組織について
食べログのサーバーサイドエンジニア組織はそれぞれ領域別に部・チームが分かれています。
エンジニアの部署がどのように分かれているか下図で示します。
飲食店システム開発部について
我々が所属している飲食店システム開発部に焦点を当てて見てみましょう。
飲食店システム開発部は、その名の通り飲食店向けサービスのシステム開発をする部署となります。
2チームで構成されており、我々の予約サービス開発チームと販売管理チームがあります。
それぞれ業務ドメインをベースにチームが編成されており、業務分掌となる場所がシステム上の様々な場所に点在しています。
予約サービスチームの業務分掌
その中で予約サービスチームは食べログの「予約」という機能の塊に合わせて存在しています。
大きく分けて以下のような機能があります。
- ユーザ向けのAPI提供
- 他システム、外部サービスに向けてのAPI提供
- 食べログノート（予約管理台帳）
- その他CSが利用する管理機能など
予約サービスチームの組織編成の工夫について
前項では予約サービスチームの部署内での業務分掌を紹介しました。
本項ではチームで行なっている工夫について紹介します。
予約サービスチームのフォーメーション
ここでは予約サービスチームのフォーメーション（編成）について紹介します。
予約サービスチームは以下のような特徴を持っています。
- EM(以下:マネージャー)が2名在籍している
- チームの中にユニットと呼ばれる小チームを作るユニット制にしている
- メンバーが20名以上在籍している
編成を考える上で以下のポイントを大切にしました。
- 事業状況に沿った組織編成にしたい
- 属人的になりにくい組織編成にしたい
- チームを領域別に分けてもコミュニケーションがとりやすい状態にしたい
上記を踏まえ、今期では以下のような編成にすることにしました。
EMの役割と特徴
1.予約サービスチームのEMの役割について
食べログ開発本部では複数のEMが在籍していますが、所属チームによって役割は様々です。
あくまでも予約サービスチームにおけるEMの役割を紹介します。
EMの役割は、食べログでは以下となります。
- エンジニアリングを通してビジネスの価値を創造する
- 現場を指揮し、プロジェクトの方向性を決めていく
- 様々な決め事の意思決定をする、責務を担う
- メンバー、リーダーの成長をサポートする
- 窓口・調整役になる
- 周りとの関係性を維持する
EMの開発プロセスとの関わりは、食べログでは以下となります。
図のようにEMはプロジェクトの要求分析〜基本設計部分まで関わります。
プロジェクト規模により、要件定義の途中でユニットリーダーにお任せする場合もあれば、基本設計にもレビューに入るなど関わる場合もあります。
図にはありませんが実装方針もコードチェック等で確認したりと、内容や状況によって動き方を変えています。
2.EM2名の役割分担
前半期からマネージャーに昇格したメンバーを加えて私とEM2名での体制を作ることになりました。
体制を考える際、チーム > ユニット という構成だった状態に加えて「領域」という概念を作ることにしました。
「領域」の概念があることにより、同じチーム内でも各マネージャーの責務が明確に分離でき、それぞれに集中してマネジメントが行える状態をつくりました。
チームとして分けることも検討しましたが、情報集約や情報伝達スピードの観点で同じチームとすることにしました。
「組織パターン: チームの成長によりアジャイルソフトウェア開発の変革を促す James O.Coplien・Neil B. Harrison著 翔泳社」の5.2.8 〜ドメインの粒度にあわせて人員を配置せよ〜 に以下のような内容が記載されています。
ドメインの粒を中心に人員を配置しよう。つまり、システム内の管理可能なパーツに対する、長期的な専属の責務を負わせよう。そうすることで、担当するシステムのパーツの再利用性を、経験が積み重なるに合わせて調整したり改善したりする機会を活かせるようになるのだ。
行った組織編成の工夫
1.チームリーダーの配置
チームはEM2名でそれぞれ領域に別れて活動することにしましたが、それとは別にチームでリーダーを1名配置しました。
これはチームの方針やルールを決める際、意思決定を迅速にするためです。別の目的としてはチーム内外へのインターフェースとしての役割も１つのねらいです。
チームリーダーの役割を担ったEMはチーム全体の課題を俯瞰的に見て課題の管理と解消のための進行を促す役目も持ちます。
2.領域の分割についての工夫
運用・改善とプロダクト開発に領域を分けてそれぞれのマネージャーがロールとして持つようにしました。
以下が変更のポイントです。
- 業務上密接に関わることが多いユニットを同じ領域にした
- 企画開発部分を1人のEMが受け持つことで、窓口が一本化された
この変更によって、負荷のバランスよりも担当業務で領域を分けた方が業務コラボレーションを生みやすいことが分かりました。
3.構成人数についての工夫
これまで開発ラインを増大するためにメンバーを大幅増員した結果、メンバーをサポートするユニットリーダーが担う管理コストが大きくなっていた課題がありました。
対策としてユニットの構成人数をなるべく少なくし、管理コストを下げる試みを行いました。
リーダーが手を動かせる状態を保つことも目的の一つです。
こちらについては構成の工夫だけでなく、様々な取り組みを今後取り入れていく予定です。
4.意思決定のボトムアップについての工夫
チームの組織編成を紹介したので、その中で行われる意思決定についても触れます。
階層構造になっているチームですが、トップダウンの意思決定に加えて、メンバー、リーダーも意思決定の領域を持ちます。
粒度が細かい内容についてはメンバーが意思決定し、レビューを通してユニットリーダーやマネージャーと内容を確定しています。
意思決定の発生と意思決定の流れを下図に示します。
ユニットリーダーの関心領域は特に固定していません。どこまで責任範囲とするかは本人に任されています。
役割によっての責務が階層構造化されているため、責任範囲の中である程度自由に意思決定ができるようになります。
また、意思決定を担当者にお任せすることが意思決定スピードアップにつながります。
品質管理やダブルチェックの観点とのトレードオフとなりますが、毎日様々な考慮点が発生する現在の状況で有効だと判断しました。
チームで行なっている情報共有の工夫
前項ではチームの編成についてお伝えしました。
本項目ではチームで行なっている情報共有について詳しく書きます。
チーム内での情報共有
チーム内での情報共有は主に日次、週次での単位で行なっています。
これは食べログ内のプロジェクトのライフサイクルの期間が関係しており、日毎に状況が変わる内容をキャッチアップするためです。
情報集約は基本的にはボトムアップの流れで行われています。
日次の流れについて下図に示します。
図の下部から上部に向かって矢印が伸びており、上に行くほど情報の粒度が粗くなります。
具体的には、下部ではより個別作業の進捗やそれに関連する細かい意思決定事項、上部はプロジェクト進行をブロックするような問題や重要な意思決定事項が集約されます。
作業上で別のチームとのやりとりが発生した際はユニットリーダーが窓口となって受けています。
プロダクトリリースや不具合修正についての現状の共有などはこの限りではなく、全体の朝会や必要になったタイミングで適宜行うようにしています。
週次での伝達は以下のように行なっています。
各ユニットから、マネージャーがチーム外から得た週次情報を集約し、展開します。
この情報はリーダーだけではなくメンバーにも情報を展開するようにしています。
週次情報は食べログの全体的な動きがなんとなく掴める ＋ チーム内の他のメンバーやユニットの動きを確認できるものを目指しています。
情報のまとめ方については集約するコスト面や情報の選定の仕方などまだまだ改善の余地があります。今後もブラッシュアップを続けていきます。
他チームとの情報共有
食べログでは年々サービス規模や開発規模が拡大してきており、他チームとの情報共有は常に発生している状況となっています。
チーム外との情報共有は、窓口役としての役割を持っているユニットリーダー、マネージャーが行なっています。
「組織パターン: チームの成長によりアジャイルソフトウェア開発の変革を促す James O.Coplien・Neil B. Harrison著 翔泳社」〜4.2.10 門番〜では以下のように記載があります。
プロジェクトは、対話する、あるいは対話すべき部外者との適切なインターフェースを築かなければならない。 〜中略〜 プロジェクトの外部からくる最先端の情報や２次的な情報は、その人物がプロジェクトのメンバーに伝える。 その際、プロジェクトに関係する用語に「翻訳」するのだ。
窓口役は、上述の外部組織へのインターフェースと同様の概念です。
現状では関わりがあるチームが多く、複数のインターフェースが必要だと判断し、マネージャー２人で担当しています。
下図は窓口受付時のイメージです。
様々な情報をマネージャーに集約していますが、ユニットリーダーに窓口を担ってもらった場合は赤い矢印であるように情報をキャッチアップしています。
こうすることで一旦マネージャーが簡易的な質問に回答したり、より良いやり方を案内する機会が生まれます。
マネージャーが受けたあとは各業務分掌に従ってユニットリーダーとやりとりを交代します。
交代した後の担当者間でのやりとりを黒矢印、その後のキャッチアップを赤矢印とします。
やりとり自体に直接入らなくてもその後の情報キャッチアップやボトムアップはマネージャーが担当します。
今後の展望
1.他チームとのやりとりのコミュニケーション改善
組織の増加につれ、１つのプロジェクトを複数のチームと合同で進めることが多くなりました。
現在は複数チームでの動き方について食べログエンジニア組織全体で改善に取り組んでいます。
チームは縦割りの構成となっていますが、横軸の強化をするために様々なチームと情報交換をする機会が増えてきています。
こちらについては、どこかのタイミングで記事としてご紹介します。
2.組織の状態とシステムの状態をフィットさせるリモデリングプロジェクト
予約サービスチームでは現在、「リモデリングプロジェクト」計画が進行しています。
現状のドメインに組織を合わせるだけでなく、ドメインそのものを組織形態やビジネスの動き方にフィットさせるプロジェクトです。
「予約」という膨れ上がったドメインを整理するため、システムを少しずつ、大きく変更していく計画を立てています。
他にも食べログ全体では「マイクロサービス化」「モジュラモノリス化」などの大きなプロジェクトが進行しております。
リモデリングプロジェクトはドメイン整理が必要なため自チームで動くのが最適と考えています。
非常にパワーがいる作業ですが、プロジェクト成功に向けてチーム一丸で進めていきます。
3.エンジニアリングに集中するためのコミュニケーション改善
今回の記事では、組織編成や情報共有の形についてお伝えしてきました。
内容的には情報統制やマネジメントの話が中心でしたが、本来の目的は一人一人がエンジニアリングに集中するためのものです。
さらなる工夫を重ねて一人一人がエンジニアリングに集中できる環境を作っていきます。
仲間を募集しています
食べログでは新たな仲間を募集しております。
今回の記事で興味を持っていただけた方は、以下のリンクの採用ページをご覧ください。
