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