開発組織を柔軟に動かし、エンジニアのパフォーマンスを最大化させる上で、「リーダーシップ」の定義は欠かせません。組織の価値最大化を求められるマネジメントレイヤーならば、どのような形で組織に関わっていくべきか、日頃から頭を悩ませているはずです。
ここで、エンジニアを「率いる」のではなく「支援する」という視点でリーダーシップのあり方を考えたとき、どのような組織のフォーメーションが想定できるでしょうか。
リクルートは、「エンジニアを支援し、エンジニアの生産性を向上させるための組織」として開発組織を定義。結果的に、ピラミッドではなく「バリューチェーン」として組織を捉える、というユニークな発想へたどり着きました。
バリューチェーンの中では、エンジニアの“後方支援”に特化した専門職が開発のフェーズごとに配置され、さまざまなアプローチで組織を下支えしています。その姿はまるでサッカーのフォーメーションのよう。ゴールを決める攻撃的ポジションがエンジニアならば、そのポジションにボールが回るよう、効率的にパスを回すのが彼ら専門職の役割と言えます。
そんな支援型の開発組織はどのような経緯で誕生したのか。バリューチェーンにもサッカーのフォーメーションにもたとえられる、その開発組織の内訳とは。
開発組織のマネジメントに長年携わってきた、大島將義さん、黒田樹さんに伺いました。
（前・後編の前編です）
※この記事は株式会社リクルートによるSponsoredContentです。
スケーラビリティ、ボラティリティ、アジリティを追求する開発組織
── まずはお二人の自己紹介をお願いします。
大島 リクルートの国内人材ビジネスにおけるシステム開発全般を管掌しています。入社して8年間、ずっとHR（人材）のビジネス領域を担当しています。
大島 將義（おおしま・まさよし）
株式会社リクルート プロダクト統括本部
プロダクト開発統括室 プロダクトディベロップメント室 HR領域プロダクトディベロップメントユニット長
黒田 大島さんの配下で、開発部の部長を務めています。併せて、リクルートの大規模開発におけるオフショア部隊の管理や人材に関わる社内の開発プロジェクトの支援といった業務も担当しています。
黒田 樹（くろだ・いつき）
株式会社リクルート プロダクト統括本部
プロダクト開発統括室 プロダクトディベロップメント室 アプリケーションソリューションユニット長
── 今回はリクルートの開発組織における設計思想を掘り下げたいのですが、そもそも開発組織を組み立てる上で「大切なこと」は何だと思いますか？
大島 やや大きなスコープで語るならば、変化への適応と規模の拡大、そして適応や拡大の速度をどれだけ上げられるか、ということに尽きると思います。平たく言うと、スケーラビリティとボラティリティとアジリティに基づく設計思想の追求です。
歴史的な背景として、リクルートのビジネス的な変遷にも触れておきましょう。私たちは「情報誌中心の会社」から「WEBサービスも扱う会社」へと姿を変えるなかで、およそ20年かけてDXし続けてきました。もちろん、コアの価値は変わっていませんが、時代を経るごとにサービスの形態やマネタイズの手法は大きく変わり、その提供価値もスケールしています。
会社を取り巻く状況も変化しています。ビジネストレンドは年々移り変わり、それに適応するような俊敏な動きをするプレイヤーも現れてきています。そうした傾向は加速していて、「同じことをやり続ける」のではなく「変化に対して柔軟に適応する」ことが求められています。
巨大なビジネスを支える、複雑なシステムを構築しながら「素早く」変化に適応したり、「素早く」世の中に機能・サービスをリリースしたりできることは、技術的な優位性だと考えます。そんな技術的な優位性を出そうとすると、前述のような設計思想を志向せざるを得ないわけです。
開発組織を「バリューチェーン」として捉える意味
── スケーラビリティ、ボラティリティ、アジリティを志向する上で、どのようなフォーメーションを組んでいるのでしょうか？
大島 まずお伝えしておきたいのは、開発工程は大きく2軸に分けて考えるべきだということです。すなわち、ビジネスサイドとすり合わせながら要求を仕様に落とし込むプロセスと、仕様の実装に向けて開発チームをマネジメントするプロセス。平たく言うなら、「何を作るか」と「どう作るか」を分けて考えるということです。
この考え方は、開発組織をバリューチェーンとして捉えると、より分かりやすくなるように思います。
エンジニアがソースコードを書いてデプロイする、という最終ゴール＝バリュー（赤）に対して「何を作るか」という横軸のプロセスと「どう作るか」という縦軸のプロセスがそれぞれ影響を与える。
── この2つの軸は、一般的な開発組織だとPM（プロジェクトマネージャー）やEM（エンジニアリングマネージャー）といった1つのポジションがマネジメントしていますよね。
大島 そうですね。彼らが「仕様」や「スコープ」に翻弄されながら「チームマネジメント」も担う状況で、日々の仕事に忙殺されたり、専門性を磨けなかったり、という課題も生まれているのではないかと思います。
ただ、大前提としてこの2軸は、開発工程をバリューチェーンのように捉えると“全く別の価値”であり“全く別のプロセス”なのだということが理解できますよね。
当然、プロダクトやシステムはエンジニアが書いたソースコードをデプロイしなければ具現化せず価値を生みませんから、その価値をレバレッジさせるために、横軸と縦軸をいかに最適化させるかを考えなければなりません。
── 開発工程をバリューチェーンで表現するとは面白いですね。横軸と縦軸は具体的に、どんなスタイルで最適化されているのでしょう？
黒田 それぞれの軸に専門性の高いロールを細かく設定しました。具体的には、BA（ビジネスアナリスト）と開発マネジメントという形で、仕様の策定領域と開発チームのマネジメント領域を切り離しています。
BAは主にビジネス的な文脈や抽象度の高い戦略レイヤーの話を理解しながら、システムやプロダクトの要件を定義します。開発マネジメントはさまざまな開発チャネルを組み合わせながらプロジェクトに応じたチームを編成し、QCD（品質、コスト、納期）をコントロールします。
エンジニアのパフォーマンスを最大化させるという大きな目的に対して、エンジニアが無駄なコードを書かないで済むよう要求に対して必要最小限の仕様におさえることや、エンジニアが効率的にコードを書けるよう開発プロセスや体制をコントロールすることは、駆動目標と言えます。その駆動目標にフィットした職種として、BAと開発マネジメントを設けました。
これ以外にも専門職は数多く存在しますが、代表的なものをもう1つ紹介するならば、アーキテクトという、エンジニアが高い生産性のもとコードが書けるようフレームワークやライブラリなどを提供して開発の技術的難易度を下げる職種も存在します。
つまり、何を、どんなモノを使って、どう開発するか、という3つのアプローチにそれぞれ専門職を配置し、エンジニアを支援している形です。
── 縦軸も横軸も中心に近づくほど人が増えているのは何か意図があるんでしょうか？
大島 これは開発プロセスが進むにつれ作業量が増える、という一般的なシステム開発のあり方を表現しています。
作業の内容が変わるのと並行して、作業の量が増える。その経過もバリューチェーンとして表現するのが適切であるように思います。
それに、作業量が増えるからこそプロセスごとに適切なロールを配置し、それぞれベクトルの異なるマネジメントを施していく必要があるわけです。
── そして、このスタイルであれば、スケーラビリティとボラティリティとアジリティを追求できると。
黒田 はい。プロセスごとに専門職を配置することでエンジニアの生産性が最大化され、大規模なプロジェクトにも柔軟かつスピーディーに対応できます。
もう少し具体的に言うと、プロジェクトの大規模化に対応する上で、開発工程の柔軟性や効率性を追求するには、BAの要件コントロールによる開発案件単位の最適化（細かく1つ1つ対応するのか、大きく1つにまとめるのか、など）や開発マネージャーによる開発案件特性に合わせた開発プロセスのカスタマイズやチーム作り、アーキテクトによる開発案件特性に合わせた技術選定や方式デザインが欠かせない、ということです。
スクラム、アジャイル開発…さまざまな手法を取り込み昇華させたフォーメーション
── 開発工程をバリューチェーンとして捉える合理性は理解しましたが、一方でその発想に沿ってポジションを設計していくのは難しいように思います。先ほども触れましたが、PMやEMといったポジションが確立されている以上、彼らに全工程の管理が任されがちです。
大島 そうですね。リクルートでも、さまざまな役割を、どんどん担わなくてはならないといったことは、長年の悩みでした。それに、1つの職種の中で、先ほどお伝えしたようなBAとしての動き、開発マネージャーとしての動き、アーキテクトとしての動きの全てを求められてしまうがゆえに、彼らが専門性を追求しにくくなったり、生産性が落ちたりという課題もありました。
やはり何を作るか、そのためにどういうチームを作るかは全く別の問題であり、得意分野と不得意な分野も分かれてきます。そのため、いっそのこと適性に応じて職種を分けた方が効率的なのではないかと。
一方、スクラムやアジャイル開発の領域では、チームの生産性を上げるスクラムマスターと要件を定義するPO（プロダクトオーナー）にポジションが分かれていますよね。私たちの開発組織も考え方としては近いのですが、全く同じというわけではありません。
── そうした考え方を取り入れて昇華させた、というイメージなのでしょうか。
大島 はい。これ以外にも、開発マネジメントの手法やフレームワークのトレンドをその時々で学び、取り込んでいます。例えば、直近では大規模なアジャイルのフレームワークであるSAFe®（Scaled Agile Framework）、古くはプロジェクトマネジメントやビジネス分析の知識体系をまとめた「PMBOK（Project Management Body of Knowledge）」「BABOK（Business Analysis Body Of Knowledge）」など。それらを全て理解した上で独自に組み上げたフォーメーションであり、ロール設計だということです。
── 「リクルートならでは」の側面はあるのでしょうか。
大島 フォーメーションにしてもロール設計にしても、既存の概念や手法ありきではなく、あくまでその時々の環境に適応していくなかで必要に応じて生まれてくる、というスタイルでしょうか。こうした型にはまらず、合理性を重んじる考え方はリクルートらしく、大規模なサービスを数多く立ち上げて運用する、というビジネス様式を支えています。
あとは、「苦手なことを克服するよりは得意なことを伸ばす」というリクルートが大事にする思想は意識しています。つまり、「何でもできる人を育てる」だけでなく「個人の強みや興味を尊重し、それぞれの得意なやり方で組織に貢献する」ことを良しとするというカルチャーです。
── なるほど。一般的な開発組織と異なるロール設計にも、合理的な理由があるわけですね。両者に共通しているのは、従来のツリー構造組織ではない、ということですね。
黒田 軸が複数あるとピラミッド型のマネジメントは成立しません。マネジメントの志向性が、「エンジニアをどう引っ張るか」ではなく「エンジニアをいかにサポートするか」という後方支援的なものに特化しているわけです。
── マネジメントの方向性が3つあることで、意見が衝突するおそれはありませんか？
大島 広い意味でワンチームのように動くので、衝突は基本的に起こりません。それに、開発のフェーズによってリーダーシップを取るポジションも変わってきます。初期段階ではBAが、開発プロセスが進むと開発マネジメントが、という形で。
── 専門性の高い人たちが集まって、一つのチームとして協調できるように工夫している訳ですね。まるでサッカーのフォーメーションのようです。
大島 そうですね。ただ、必ずしも全てのプロジェクトに全てのロールが関与する、というわけではありません。当然ながら、プロジェクトの性質によってフォーメーションは少しずつ変わっています。
（後編ではこの開発フォーメーションがフル活用された事例を紹介します）
リクルートのテックに関するブログ記事はこちら
株式会社リクルートではエンジニアを募集中！
今すぐの転職を考えていなくても、希望職種に関する情報やスカウトを受け取れるキャリア登録の仕組みも用意されています。少しでも興味のある方は👇気軽にクリック！
さまざまな取り組みの裏側やナレッジ、厳選した採用情報もSNSで発信中！
🎁 Amazonギフト券が当たる！ リクルートに関するアンケート 📝
Amazon.co.jp は、本キャンペーンのスポンサーではありません（株式会社はてなのキャンペーンです）。
関連記事
リクルートの他部署に関連したSponsoredContent、および旧リクルート各事業会社によるSponsoredContentもあわせてお読みください。
[SponsoredContent] 企画・制作：はてな
取材・構成：星暁雄
撮影：佐坂和也
