「異次元の短期化」に挑むため、人月の原則をハック
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コンポーネントに分断した。その結果、「短期間で開発を完遂したい、人数は問わない」という要求に応えることができた。
データベースと想定外の問題への対応
しかし、多重並走アーキテクチャだけで工期を3分の1にできたわけではない。アーキテクチャだけでは「データベース」の制御はできないからだ。
「データベースの変更は、あらゆる方面に波及する協調の発生源となってしまう。なので、そもそもデータベースを変更しなければ協調は発生しない、と捉えました」と竹下氏。
従来であれば、画面→API→データベースの順に開発するところを、逆転の発想で「先にデータベースを設計し、その内容をロックする」やり方を採ったのである。具体的には、主要な数画面のみ固めて早期にデータベースをフィックス。その他の画面は、決まったデータベースを前提に最速で開発した。
それでもなお、開発期間中は想定外のコミュニケーションが多発する。「コーディング中に仕様の矛盾に気づいたり、設計まで立ち返ってしまうような大きな問題が発覚したりする」と竹下氏。
そこで、そのコミュニケーションに開発者が巻き込まれずに、開発だけに集中できるよう、コミュニケーションパスの発生個所をコントロール。並走開発を破綻させないために、戦略的な先送りをできる猶予期間を設定した。
ビジネス要求の漏れはこの期間に取り込み、リリース後で問題ないものに関してはリリース後まで先送りする。これによって工期は3分の1に短縮し、従来より8か月早いプロダクトリリースが可能になった。
無事に開発期間は異次元の短期化を実現したが、保守エンハンスはどうか。吉井氏は「保守エンハンスにも、協調の最小化による恩恵が見えてきた」と考察する。
開発プロセスにおいては協調を断ち切ることを徹底したが、開発対象は一つのアプリケーションなので、最終的には結合する必要がある。明確に開発領域が分かれていた各レーンを結合することで、結合点も明確になる。
その結果、バグの特定が容易になり、障害対応やエンハンスの中でも影響範囲が絞られる。また、レーンごとに単体テストは完了している。「品質・スピードともに既存と比較し、向上した効果を得られている」という。
今回のプロジェクトにおける課題の中心は、開発期間だった。リクルートの標準の3分の1の“異次元の短期化”が求められる中で、超並列開発しか実現できないと考えたのだ。最後に吉井氏は、ポイントを以下のようにまとめた。
「ナレッジポイントは、コミュニケーションコストを低下させるために超分散型の新アーキテクチャを考案したこと。データベースの設計を開発実行タスクの先頭に置くこと。そして、エンジニアが巻き込まれるコミュニケーション増加を止めること。結果、工期の3分の1の短期化を実現できました」（吉井氏）
