【アンチパターン】マルチベンダー開発で起きた「API所有権のねじれ」と、曖昧な責任分界点
はじめに
マルチベンダーでのシステム開発において、「誰がどこまで責任を持つのか（責任分界点）」を明確にすることはプロジェクト成功の絶対条件です。
今回は、私が過去に経験したプロジェクトで発生した、 「APIの所有権と実装のねじれ」 ついて、お話できればと思います。
プロジェクトの前提と初期計画
対象となったのは、あるドキュメント管理システムの大規模開発案件でした。このプロジェクトはマルチベンダー体制で進行しており、機能ごとにチームが分かれていました。
- 私たちのチーム： ドキュメントの「閲覧・検索機能」を担当
- 別ベンダーのチーム： ドキュメントの「管理・編集機能」を担当
システムを成立させるためには、管理・編集機能側と閲覧・検索機能側を連携させるためのAPIが必要不可欠です。当初の計画では、 「管理・編集機能チームが連携用APIを開発し、私たちのチームがそれを呼び出す」 という、シンプルな役割分担でした。
狂い始めたスケジュール
順調に進むかと思われたプロジェクトですが、ここで最初のトラブルが発生します。別ベンダーである管理・編集チームの開発スケジュールが遅延し始めたのです。
全体のリリーススケジュールは決まっているため、「APIの完成を待つ」という選択肢は取れません。プロジェクト全体をストップさせないための苦肉の策として、 「閲覧・検索機能チーム（私たち）の一部メンバーが、ヘルプで管理・編集チームに参画し、API開発を巻き取る」 という決断が下されました。
これが、のちに長引く負債の始まりでした。
発生した「ねじれ状態」
私たちがAPIを実装することになった結果、奇妙な「ねじれ」が発生しました。
- APIのリポジトリ管理・管理者権限： 管理・編集チーム（別ベンダー）
- 実際のコード実装者： 閲覧・検索チーム（私たち）
リポジトリの所有者は別ベンダーであるにもかかわらず、中身のコードを書いているのは私たちです。環境へのマージ権限などもちぐはぐになり、本来不要なコミュニケーションコストが発生する事態となりました。
また、それぞれのチームでビルド方法やCheckstyleルールも異なっていたため、実装作業においても、不要なコストが発生していました。
曖昧なまま保守・運用フェーズへ
「とりあえずリリースを間に合わせる」という大義名分のもと、このねじれ状態のままなんとかシステムはローンチされました。
しかし、一番の問題は 「リリース後、このAPIは最終的にどちらの担当になるのか」が一切明確にされなかった ことです。
本来であれば、リリース直後や保守移行のタイミングで「実装は肩代わりしたが、運用は本来の持ち主である管理・編集チームに引き継ぐ」などの取り決めを行うべきでした。しかし、うやむやなままプロジェクトは保守・運用フェーズへと突入してしまいます。
「ねじれ」とコミュニケーションコスト
保守・運用フェーズに入っても、責任分界点は曖昧なままでした。その結果、以下のような地獄のフローが定着してしまいます。
- バグ修正や機能追加： なぜかコードの仕様を把握してしまっている「閲覧・検索チーム」が対応
- ブランチのマージや本番環境へのデプロイ： リポジトリの管理者である「管理・編集チーム」が実行
私たちがコードを修正し、別ベンダーにマージやデプロイを依頼するという、非常に不自然で非効率な状態となりました。トラブルシューティングの際も「どちらの管轄か」の切り分けから始める必要がありました。
まとめと教訓
- 緊急時の巻き取り（代替対応）を行う際は、必ず「引き継ぎの条件と期限」をセットで合意する
- 「誰が作るか」と「誰が保守するか」の責任分界点は、フェーズの変わり目で見直す
プロジェクトの開発規模が大きいほど、複数のベンダーやチームが参画することになります。それ故に「責任の所在の曖昧化」は防止しなければいけません。皆様のプロジェクトで、同じようなことが発生しないことを祈っています。
ここまでお読みいただき、ありがとうございました。