「異次元の短期化」に挑むため、人月の原則をハック
Indeedは、複数の求人サイトと複数のATSをつなぎ、求職者と求人のより効率的なマッチングを実現する求人配信プラットフォーム「Indeed PLUS」をリリースした。これは関係者数千人、4か国にまたがる大規模プロジェクトだった。その中でも、新プラットフォームの一部「Airワーク 採用管理」は最も工数がかかるプロジェクトだ。このプロジェクトは、「通常であれば12か月かけて取り組むべきところ、4か月で完遂することが求められていた」という。
そこでリクルート プロダクトディベロップメント室 ＨＲ領域プロダクトディベロップメントユニットでは開発期間の「異次元の短期化」を実現するために、「多重並走アーキテクチャ」を採用。通常では多方面に配慮しながら開発する必要がある中で、今回ばかりは開発の「スピード」を第一優先に置いた。
竹下氏は「異次元の短期化を実現するために、今までの常識では太刀打ちできない。原理原則として捉えていたものを改めて見直し、ハックすることを意識した」と振り返る。
結論から言えば、N名のエンジニアで12か月かけて開発するところ、通常の3倍のエンジニアが参画することで、3分の1の4か月で開発するという戦略をとった。しかし、本来この手法は常識では禁じ手である。システム開発の期間はコミュニケーションコストと関係するからだ。
「『人月の神話』の中に登場するブルックスの法則では『遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせるだけである』と指摘されています。コミュニケーションパスが人数の二乗で増加し、人数増加で消費できるタスク量よりも、コミュニケーションコストが上回ってしまうのです」（竹下氏）
この問題を解消するため、メンバーを3倍に増員しながらもコミュニケーションパスの増加を徹底的に防ぐ必要があった。
そこで、このようなタスクの進め方ができる新しいアーキテクチャを考案することにした。それが「多重並走アーキテクチャ」である。
ポイントは2点。まず、フロントエンド・バックエンドの間の協調を最小限に抑えること。そしてUIコンポーネントを軸に責任を分担することだ。
そもそもアプリケーション開発において、特にコミュニケーションコストがかかる、すなわち協調が必要になるのは「BFF（Backend For Frontend）」の実装だ。BFFとは、画面要求を達成するためのサーバー実装であり、UIを表現するためのデータ取得などがそれにあたる。BFFはバックエンドとフロントエンド、どちらの責務であるか曖昧な領域であるため、双方の認識齟齬なく、確実で的確なやりとりが求められる。
「ボトルネックになりがちなBFF実装の整理こそ、ブルックスの法則に抗うためのキーポイントだった」と吉井氏。
そこで吉井氏は、BFF実装の工程を以下の3つのステップと捉え、スピードのボトルネックとなる協調点をずらした。「複雑な協調はバックエンドの開発者のチームだけで完結するように合意形成しておき、フロントエンドとバックエンドをまたぐ協調は単純化した」という。
さらに、フロントエンドとバックエンド、それぞれの開発の中でも、担当領域ごとに責務を明確にすることで、コミュニケーションコストを下げた。その責務の境界の基準となったのが「UIコンポーネント」である。
例えばWeb APIのサーバーがあった場合、一般的にはOpenAPIなどで規約を定義してから開発に着手するだろう。しかし、それだけでは責務の境界を引くことはできない。「UIに必要なデータ加工をどこで行うのか。データ中心のAPI なのか、UI中心のAPIなのか決めるために、必ず協調が必要になるからです」と吉井氏は言う。
そこで、一つの画面を複数のUIコンポーネントに分断し、UIコンポーネントと専用Web APIが一対一の関係になるように責務を分担。「UIを成立させることに徹する」という規約を置いた。
こうして「多重並走アーキテクチャ」を構成した同社。吉井氏は、多重並走アーキテクチャのキーポイントとして、「フロントエンドとバックエンドの協調を最小限に抑えること」「UIコンポーネントを軸に責務を分断すること」に加えて「要件定義の段階から分断されていること」が重要だったと振り返る。
「『どこまで分割するのか』について協調が必要になってしまわないように、ワイヤーフレームが上がった時点で、UIの単位で割っていきましょうというレールを敷いた。これが現場に落とし込むうえで一番ポイントでした」（吉井氏）
今回の開発対象は40画面だったが、190ほどのUIコンポーネントに分断した。その結果、「短期間で開発を完遂したい、人数は問わない」という要求に応えることができた。
