はじめに
Developers Summit 2018 (Developers Summit 2018)
【15-C-4】多様なビジネスドメイン、サービスフェーズが混在する中での組織戦略と技術戦略
スピーカー：宮川 典久 さん [リクルートテクノロジーズ]
の聴講メモです。
メモは口頭説明を中心にまとめています。資料を併せてご参照ください。
Twitterのつぶやきがtogetterでまとめられています。併せてご参照ください。
【デブサミ2018】15-C-4「多様なビジネスドメイン、サービスフェーズが混在する中での組織戦略と技術戦略」 #devsumiC #devsumi - Togetter
【参考】としている個所は私が挿入しています（補足や参考資料など）。登壇者の講演内容ではありませんので、その旨ご了承ください。
聴講メモ
リクルートの主な事業
リボン図はユーザと企業をつなぐビジネスを表している。
【参考】
リボン図（リボンモデル）を解説した記事があります。
すべての事業の基盤は「リボンモデル」 : 日経BizGate
ライフイベント領域は人生の大きなイベント、ライフスタイル領域は日々のイベントをターゲットにしている。
リクルートの文化
リクルートはボトムアップの文化であり、下から提案し、上はそれを承認する。また、失敗から学ぶ文化がある。
各部門でバラバラにテーマを決めて取り組んでおり、その一つとしてオフショア開発にも積極的に取り組んでいる。
行ってきた取組
エンジニア採用の拡大により、150人が6年で700人を超えた。
ビジネス観点
飲食店向けのサービスであれば、クライアントはお店であり、カスタマーは来店者といえる。
SoEはゴールが見えないため、アジャイルが向いているといわれる。
各ビジネスが100億を超え、かつ成長しているためにリソースを集中させにくい。
関連組織が機能別に分かれており、ステークホルダーが多いために仕様調整が難しい。
アーキテクチャ観点
型化とは、全員が平均以上のことをできるようにするということ。だが、型化ゆえに基本構成から外れることが困難になった。
【参考】
「型化」についての説明を引用します。
私が考えたのは「型化」。つまり、仕事のやり方の型・ベースを徹底的に身に着けるという事です。
スマート開業事例 ～ 3万社への営業から導き出した行動概念をマニュアル化し「型化」するサービス。株式会社Gifted(ギフテッド) 杉田 恵美氏 | 先輩起業家インビュー | 開業事例 | 開業計画ナビ
リクルートは見込みのあるプロダクトに対して一気に投資を行うことで、成長期を短期間に通過しようとする。それゆえに技術負債がたまりやすい。
これまでの開発体制
カスタマー(Web)はいろいろ改善をしたい。これに対してクライアント(Web)は変更の頻度が低い。
だから、カスタマーはScrum開発チーム、クライアントはオフショア開発チームが担当するという体制になっていた。
だが、カスタマーとクライアントはそれぞれにSoR/SoEの両方の要素がある。ScrumでSoRの要求（納期）、オフショアでSoEの要求（高速リリース）という、本来であればチームに向かない要求に応える開発を行う中で元々の強みが失われていった。
現在目指している体制
SoEの領域はScrum開発チームが担当し、SoRの領域はオフショア開発チームが担当することで、各開発チームの強みを活かせるようにしていく。
開発体制
様々な組織から発生する開発案件に対し、開発チームのマネージャーやリーダーが調整業務に奔走することになった。だが、リーダーの調整業務をエンジニアに任せるのではなく、エンジニアには開発に集中して欲しい。そこで、ディレクション組織が開発案件をコントロールすることにした。
学び
苦手を克服しようとして強みを失ってしまう。
ビジネスフェーズによる組織戦略
導入期・成長期はSoE、成熟期はSoRの要素が強い。
成長期にエンジニアが疲弊してしまう。技術的負債がたまったり、SoEからSoRへと要素が変化することに対応しなければいけないため。
マネジメント層がフェーズに応じてチームの構成を変えていく必要がある。
アーキテクチャ方針
課題に対してアーキテクチャで対応した。
BFFサーバを採用して、バックエンドはシンプルにし、BFFで画面とのギャップを吸収する。
【参考】
BFF(Backend For Frontend)の解説です。
Sam Newman - Backends For Frontends
Consumer Driven Contract でフロントエンド（利用）側がAPI仕様を決定するようになると、変更が頻発してバックエンド（提供）側が疲弊する。この対応としてAgreedを開発した。フロントに対してはモックとして機能し、バックエンドに対してはテストケースとして機能する。
【参考】
Agreedのもう少し詳しい解説が記載されています。
リクルートテクノロジーズのフロントエンド開発 2016 - from scratch
BFFはフロントエンド／バックエンドの双方が開発に携わる。
想定外の変更がないようにディレクション組織が管理する。
FWなどを担当する技術基盤チームを機能として独立させるのではなく、開発チームに組み込んだ。
アーキテクチャ戦略
マイクロサービスのように細かく分離しすぎると、これまでのモノリシックとのギャップが大きく、エンジニアがついていけなかったり活用できないことになる。
技術方針
長期的な視点で技術の開拓を行い、サービスに採用していく。
所感
リクルートテクノロジーズは転職活動の際にお世話になったことがあります。その際に非常に印象的だったのが、面接官のエンジニアの方も採用担当の方もとてもエネルギッシュで、仕事を楽しんでいることが伝わってきました。今回のお話のテーマの一つである組織戦略がそこに寄与しているのではないかと感じます。
仕事を楽しめる文化と環境を作ることは私個人のテーマでもあり、チーム作りの参考にしたいと考えています。
