システム連携における「要件を出せ vs 仕様を教えろ」問題

システム開発において、他のモジュールやシステムとの連携を構築する際にしばしば発生する、私は個人的に「要件を出せ vs 仕様を教えろ」問題と呼んでいる問題について、その構造と解決策を共有します。

「要件を出せ vs 仕様を教えろ」問題

システム連携では、基本的にデータを受け取る側と提供する側が存在します。両者の間で次のようなやり取りが発生することがあります。

受取側「システム連携を構築したいので、あなたのシステムの仕様を教えてください」
提供側「まずは要件を出してください」
受取側「仕様が分からないと要件を考えられません」
提供側「いやいや、要件が分からないと、それを実現できるか回答できません」
（以下、平行線）

「要件を出せ vs 仕様を教えろ」問題

どちらが正しいのか

このやり取りにおいて、正しいのはどちらでしょうか？受取側、提供側どちらの立場でもこのやり取りを経験した立場として、私は次のように考えます。

must要件については「要件を出せ」が正しい

must要件、つまりシステム連携において必ず実現したいことにおいては、受取側がきちんと定義する必要があると考えます。

nice to have要件については「仕様を教えろ」も許容される

nice to have要件、つまりできたら好ましいが、難しいなら妥協可能なことについては、「仕様を教えろ」にも一理あると考えます。

もちろん、nice to have要件についても受取側が定義した上で、提供側がどこまで実現できるかを判断する流れで進めるのが理想的です。しかし、もし初めから提供側としてできることが決まっているのであれば、先にそれを受取側に伝え、その制約の中でnice to have要件を考える進め方が効率的です。

建設的なコミュニケーション方法

上記構造を理解した上で、建設的に議論を進めるためのコミュニケーション方法を提案します。

提供側の場合：提供できる仕様を伝え、できない場合は制約を示す

提供側としては、仕様書やAPIドキュメントが存在する場合は、意地を張らずにそれを渡しましょう。もし存在しない場合は、どの程度の自由度でシステム連携を構築できるかという制約を伝えた上で要件を考えてもらうようにします。

受取側の場合：最低限must要件は明確に、その上でnice to have要件の検討のために仕様を求めることはOK

受取側としては、最低限must要件はきちんと定義して提供側に伝えます。その上で、nice to have要件を考える上で仕様が欲しいのであれば、「must要件はきちんと考えるが、nice to have要件については提供側のできる範囲で考えたいので、可能であればまずは仕様や制約の提供をお願いしたい」という形でお願いします。

（補足）歴史的な変化

私は30代前半なので想像ですが、恐らくパッケージやSaaSがあまりメジャーではなく、フルスクラッチ開発が一般的だった頃は、システム連携は「要件を出せ」一択だったと思います。

しかし近年はSaaSを中心に、APIを外部公開し、その詳細な仕様をインターネット上で簡単に確認できるようにすることが一般的になりました。そのため、受取側がAPI仕様を見ながらシステム連携を作る、つまり「仕様を教えろ」の進め方がされることも増えました。

そんな中で生まれたのが「要件を出せ vs 仕様を教えろ」問題だと思います。

おわりに

私は、システム連携の成否は各システムの担当者同士のコミュニケーションで決まると考えています。本記事で取り上げた問題を乗り越え、より良いシステムを構築する一助になれば幸いです。

以上です。