リクルートでは、エンジニアのパフォーマンスを最大化させるために、開発組織をバリューチェーンとして捉えています。
ツリー構造組織ではないワンチームの開発組織は実際、社内でどのように機能しているのでしょうか。今回は、リクルートが提供するプロダクトの一つである『Airワーク 採用管理』の開発事例を参考に深堀りします。
サービス開発を進めるなかで、190画面もの規模の開発をなんと4カ月で完遂させたというこの事例では、BA、アーキテクト、開発マネジメントがそれぞれ八面六臂の活躍を見せ、圧倒的な「開発速度」を実現させました。
後編では、アーキテクトの西村祐樹さん、開発マネジメントの朴永喆さん、BA（ビジネスアナリスト）の竹下由美さんの御三方を交えて、その裏側をお伺いします。
（前・後編の後編です）
※この記事は株式会社リクルートによるSponsoredContentです。
「ブルックスの法則」を乗り越える
── 今回新たに参加する方々の自己紹介をお願いします。
西村 アーキテクトの西村です。黒田の配下にある4つのエンジニアリンググループを横断し、技術面での課題解決を通じてエンジニアリングを支援しています。
西村 祐樹（にしむら・ゆうき）
株式会社リクルート プロダクト統括本部
株式会社リクルート プロダクト統括本部 プロダクト開発統括室 プロダクトディベロップメント室 HR領域プロダクトディベロップメントユニット HR領域エンジニアリング部 HRアーキテクトグループ
朴 開発マネジメントの朴です。『Airワーク 採用管理』の開発では、エンジニアのチームを編成し、要件定義が終わったものを実際に開発していく役回りでした。
朴 永喆（パク ヨンチョル）
株式会社リクルート プロダクト統括本部
プロダクト開発統括室 プロダクトディベロップメント室 HR領域プロダクトディベロップメントユニット HR領域エンジニアリング部 横断開発マネジメントグループ
竹下 BAの竹下です。ビジネス視点における検討から要件定義に至る工程で、ビジネスサイドと開発組織の架け橋になりつつ、最大のアウトカム（成果）を出すことにコミットする役割です。
竹下 由美（たけした・ゆみ）
株式会社リクルート プロダクト統括本部
プロダクト開発統括室 プロダクトディベロップメント室 HR領域プロダクトディベロップメントユニット 横断ディレクショングループ
── そもそも『Airワーク 採用管理』の事例とは、どのようなものだったのか、どのような体制で臨んだのかをまずはお聞かせください。
大島 まず私から概略をお話ししましょう。『Airワーク 採用管理』はリクルートの業務支援サービス『Air ビジネスツールズ』の一つで、採用活動を効率化する応募者管理ツールです。
これが、HR関連システム横断のプロジェクトにおいて、全体のスケジュールや工数を規定する「クリティカルパス」になっていました。
事業戦略上の要請により、一般的な規模と見積もりでは1年近くかかる190画面のシステム開発期間を6カ月に短縮する、というシステム改善のプロジェクトが始動しました。後述のように、結果として4カ月で作りきるスケジュールを組んだのですが、開発期間を1/3にするには単純計算で通常の3倍の人手をかければいい……というわけではありません。
ソフトウェア工学の古典として知られる『人月の神話』では、「チームメンバーを増やしても納期は早まらない（なぜならコミュニケーションパスもメンバー数の二乗で増えるから）」という「ブルックスの法則」が紹介されています。つまり、コミュニケーションパスがある限り、開発規模はスケールしない。
これをいかに乗り越えるかが課題でした。
── 「ブルックスの法則」に挑戦するとは、大胆なプロジェクトですね。
大島 逆に言うと、スケールの限界はコミュニケーションパスの数で決まりますから、スケーラビリティを向上させる余地はある。ブルックスの法則を解決できない前提でなく、解決すべき問題と位置付けたんです。
そこで生まれたのが「コミュニケーションパスを断ち切る」、その上で「50組の開発チームを並列的に動かす」という2つの戦略でした。
BAがビジネスサイドと開発組織の間に立って全ての仕様を決め、そこで決めた仕様は原則変えない。アーキテクトが開発を並列化させる技術を選定し、開発マネジメントが大量のチームを編成し動かす、という作業の流れです。
柔軟に仕様を変更することはできませんが、その代わり、リリースまでの最後の2か月をバッファ期間として、仕様を調整する余地（先送りの受け皿）を設ける。
ただでさえ短い開発期間をさらに短くして、このスプリントに収まらないことを次のスプリントに回す、といったイメージですね。
コミュニケーションパスの分断、重複コードの許容…開発速度を上げる工夫
── コミュニケーションパスを断ち切ってしまえば、コミュニケーションが簡潔になる反面、トラブルも起きやすくなりそうな気もします。竹下さんにお伺いしたいのですが、仕様を決めるうえで一番重視したのは何でしょう？
竹下 DB（データベース）設計のロックですね。ビジネスサイドの要求に基づいてDB設計の原案を作り、アーキテクトや開発マネジメントと相談しながら仕様を固める。固めた後は、何があっても変えません。仮に、何らかの事情でDBの変更が必要になったとしても、DBよりも影響が軽微な仕様を変更しますし、仕様よりも影響が軽微であれば業務を変更します。このように、通常であれば業務や仕様が設計・開発の前提となっているために、エンジニアリング的な解決しかないといった因果関係とは、真逆の発想で、全てをフラットに捉え最大のビジネスメリットである短期化にとって何がベストなのかを判断する必要があります。
── クリティカルな問題は起こらないよう配慮はされているのだと思いますが、それでもリスクテイクの印象が強い、勇気のいるアクションですね。
竹下 当然ながら、目的によって取るべき手段は異なります。ただ、今回の目的はあくまで「開発速度の追求」。だからこそ、速度遅延の主原因となるコミュニケーションパスを徹底的に断ち切る必要がありました。そして、コミュニケーションパスが増える局面として最もありがちなのが、「諸般の事情での仕様変更」なんです。共通ロジックがあるからここを直せばこっちも直さなければいけない、といった共通化に伴うものもありますし、実際作ってみたらうまくいかなくて変えなきゃいけない、という手戻りによる仕様変更もある。
それらを全てブロックし、あらゆる仕様はBAで決定する。「これどうしたらいい？」「これできないかも」というエンジニアからの相談も開発組織の中で解決する。
言うなれば、私は最速で走ろうとしているエンジニアを守る「防御壁」の役割でした。
── ビジネスサイドとのやり取りにも気を使ったのではないでしょうか？
竹下 『Airワーク 採用管理』がクリティカルパスになっていたことや「速さ」が最大のボトルネックになっていたことは、ビジネスサイドとも認識が合っていたので、そこまでハレーションは起きませんでしたね。
それに、先ほども説明があった通り、「先送りの受け皿」を早急に立ち上げて、リリース直前にやるべきことを優先順位をつけて羅列していく、ということも同時に行っています。
── 仕様を完全に固めていたとしても、「50組の開発チームを並列的に動かす」のは相当難しいように思いますが、開発マネジメントの朴さんとしては、そこをうまく回すための工夫があったのでしょうか？
朴 まずは、ベトナムの開発会社によるオフショア開発に切り替え、一度に多くの開発を同時並行的に行う座組みを設けました。
そして、開発体制をスケールさせるために、設計とコーディングの工程を意図的に切り分けました。アジャイル開発が主流を占める開発工程のトレンドを鑑みると「逆張り」ですが、開発速度を追求するために、あえてこの手段を選択しています。
人が増えるほどコミュニケーションコストが大きくなるのは先ほど解説した通りです。その意味で設計は関係者も増える分、コミュニケーションコストの高い工程です。もし今回、設計段階からオフショアで開発していたとしたら、物理的な距離も相まって、コミュニケーションコストがかなり嵩んでいたでしょうね。
設計を自社側で完成させ、オフショアのエンジニアには設計書に基づきコーディングを依頼する、というスタイルにすれば、開発期間は大幅に短くなるんです。
結局、フロー効率性をどの視座で捉えるかだと思うのですが、今回の開発においてはビジネス要件として190画面全てがリリース日に揃っている必要がありました。そのため、190画面のリリースに向けて、リードタイムを最も短くするための開発プロセスをデザインした形になります。
── なるほど。アーキテクトの西村さんは、50組の開発チームが並列開発するための技術を選定しなければなりませんよね？ どのような工夫をしたのでしょう？
西村 開発を並列で行う上で、並列間のコミュニケーションパスを断ち切るためにも、ある程度の重複コードを許容しました。共通化における議論をする時点でコミュニケーションパスが増え、開発がスローダウンしてしまうためです。当然ながら、アーキテクトとしては非機能的な処理やフレームワークレイヤでやっておくべきことは念入りに事前準備した上でのアクションです。
「重複コードは悪だ」としばしば言われますが、無理に重複コードを避けようとすると、例外的なif文が入ったり、それが技術的負債につながったりします。共通ロジックを切り出して、逆にリファクタリングが難しくなることもあります。
開発速度を追求するためには、この戦略が一番合理的でした。
── とても斬新な戦略ですね。技術スタックとしてはどのようなものを使ったのでしょう？
西村 共通ロジック化しないために、画面ごとのAPIを作りました。通常、APIはリソースベースで設計すると思いますが、その場合はAPI自体が共通ロジックの温床となる可能性もあります。複数の画面が一つのAPIに依存すると、「一画面に特殊な処理を入れる」ための例外的なif文が必要だったり、その影響範囲が他の画面に及ぶかどうかを検討するコミュニケーションコストが発生したりします。
そこで、「この画面用の初期描画用API」といった画面に特化したAPIを用意する。これが、今回採用した「1対1」と呼ぶ設計思想になります。
── 確かに今回のプロジェクトにおいては合理的な設計ですが、メンテナンスが煩雑になることはないのでしょうか？
西村 冗長化しているので、単純にAPIの数が増える分、メンテナンスコストがかさむ、という側面はあります。ただ、オフショア開発先の会社とフォーメーションを組めていることが前提にありつつ、開発速度を追求するためにその部分はあえて無視しました。
大島 サービス立ち上げの初期には、やることがいっぱいありますから、今回はとにかく「速さ」を重視しました。開発のフェーズが進むにつれて、今後は共通化する可能性はあるかもしれませんが、あくまでビジネス上の要件に応じて、その都度対応を考えていきます。
「開発速度の追求」という目的に忠誠を誓う
── お話を伺っていると、究極のウォーターフォール開発のようにも見えます。
黒田 前編でも少し触れましたが、ウォーターフォールもアジャイルも取り入れ、目的に合わせて戦略を考えています。
例えば、4カ月+1カ月+1カ月のような変形スプリントを設計して、最初の4カ月でウォーターフォール的にMVP（Minimum Viable Product）を作り、それを残りの2カ月でアジャストさせるといった発想は、アジャイルから取り入れています。
大島 あくまで私たちがやりたいのはビジネス的競争力に貢献するシステム開発です。そのためには、ウォーターフォールかアジャイルかといった議論ではなく、それら全てを経験し、本質的に理解した上で組み合わせ、そのプロジェクトのために特化した手段を生み出すことが大事です。今回、その目的は「開発速度の追求」だったので、このようなスタイルになりました。
黒田 もう少し抽象度を上げると、ここにあるのは「同時に走らせるため、あらゆるものを疎結合にしていく」という思想です。協調と冗長はトレードオフの関係にありますが、今回は開発の並列度や速度を重視して、冗長かつ疎結合の側に振り切ったわけです。
一つのシステムの中に擬似的なマイクロサービスを作り出しているとも捉えられるので、冗長・疎結合はマイクロサービス化のメリットにも近いように思います。
── 朴さんとしては、50チームの開発を並行させても動かせる、という確信が当初からあったのでしょうか？
朴 最初は「うまくいくのかな？」と半信半疑な面もありましたが、本格的な開発が始まる前に自分の整えた体制がうまく回るかどうかを検証しており、そこで「いけそうだ」という感触を得ていました。
黒田 開発の前段階として、朴さんが整えてくれた開発体制に、すでに要件定義が終わった案件を流して、想定するアウトプットが作れるかどうかを検証しています。プロセス上の欠陥がないかどうか確認し、FAQを用意して、フレームワークに実装が足りなかったら拡充して、「作れる」と判断した段階で50チームにスケールさせました。
── まるで製造業のようなお話ですね。
黒田 「かんばん方式」など車の製造手法も活用しましたし、そもそも製造工程の不確実性を下げることは常に意識していました。
ただ、DB設計のロックや開発体制の冗長化といった部分も「後でひっくり返るかもしれない」「ぐちゃぐちゃになるかもしれない」というリスクを積極的に冒しています。
一般的なQCDS（品質、コスト、納期、サービス）のトレードオフをしていても「圧倒的な」速度は得られません。そこで、セオリーを理解しつつも敢えてリスクを戦略的に取ったことが、常識を覆すような結果に繋がったのだと思います。
大島 開発プロセスもフォーメーションも目的に応じて設計されるべきだと思います。同じ方法を間違わずに再現できることも大事ですが、目的に応じてクリエイティブなプロセスを設計できることも大事です。
そもそも、システム開発も業務プロセスの一つなんですよね。システム開発以外の業務では、当然のように業務プロセスはビジネスの目的に沿った形態になっています。僕らはその常識を、システム開発へ応用したにすぎません。
── とても説得力があります。今回の開発事例から「型にはまらない合理性」や「リスクを取る」といったことの他に、リクルートの特徴を読み取るとすれば、どこになるでしょうか？
黒田 何らかの機能だけでなく、開発プロセスに対してもビジネス的な観点で検討をするのがリクルートの特徴かもしれません。一般的な傾向として、ユーザー部門の業務設計はやるけれども、開発プロセスの業務設計まではやらないと思うので。
大島 （前編で紹介したような）スケーラビリティ、ボラティリティ、アジリティを追求した開発組織を目指す、という点にこだわると、そこはやらざるを得ないんです。
そもそも開発プロセスの各フェーズでイシューが違い、取るべきリスクの種類も違う。だからこそ、専門性を集めた集合知としてのフォーメーションが必要でした。特定の専門領域に長けたプロフェッショナルが各フェーズにいるから、安心してリスクを取れます。
これがリクルート式の「サーバント・リーダーシップ」
── トラブルシューティングの側面で、このフォーメーションが役立つことはあったのでしょうか？
大島 はい、ありました。開発現場で細かいトラブルが起こる、ビジネス上の仕様変更が起こる、これはほぼ同時期に発生する問題です。もし、これらに対応するロールがプロジェクトマネージャーのように統一されていたら、局所的に大きな負荷がかかっていたでしょう。
でも、サッカーでポジションごとに動き方が異なるように、仕様策定と開発マネジメントを役割分担すると、負荷も分散され、それぞれ最適なやり方で対応できますよね。
トラブルは予定外のタイミングで発生しがちですが、1人で対応すると、負荷が大きくなり過ぎて予定していたタスクも滞ってしまいます。でも、その負荷を10人に分散できたら、とても良いですよね。
── たしかに。
黒田 そう考えると、このフォーメーションを支える思想は、エンジニアに奉仕、貢献する存在として各専門職を配置しているという意味で、いわゆる「サーバント・リーダーシップ（※）」に近いのではないかと思います。
※……リーダーがメンバーを奉仕する、支援型のリーダーシップ
大島 あくまでエンジニアの生産性向上を目的に、各専門職がバリューチェーンに沿って、専門性を発揮させる。それがリクルートのサーバントリーダーシップだと考えています。
（前編ではリクルートの開発組織を支える設計思想を深掘りします）
リクルートのテックに関するブログ記事はこちら
株式会社リクルートではエンジニアを募集中！
今すぐの転職を考えていなくても、希望職種に関する情報やスカウトを受け取れるキャリア登録の仕組みも用意されています。少しでも興味のある方は👇気軽にクリック！
さまざまな取り組みの裏側やナレッジ、厳選した採用情報もSNSで発信中！
🎁 Amazonギフト券が当たる！ リクルートに関するアンケート 📝
Amazon.co.jp は、本キャンペーンのスポンサーではありません（株式会社はてなのキャンペーンです）。
関連記事
リクルートの他部署に関連したSponsoredContent、および旧リクルート各事業会社によるSponsoredContentもあわせてお読みください。
[SponsoredContent] 企画・制作：はてな
取材・構成：星暁雄
撮影：佐坂和也
