システム開発の外注で失敗を防ぐには｜「できます」の前に確認したいこと

顧客との打ち合わせで、開発会社の担当者が「わかりました」と答える。話は前に進んだように見えます。でも、チームに戻って「結局、どう作るのか」と聞かれたとき、誰も答えられない。システム開発の外注では、そんな小さな曖昧さが後の手戻りにつながります。

私はSIerと事業会社の両方で、顧客や社内の関係者と話しながら開発を進めてきました。メンバーとして関わった複数の難航案件では、顧客との打ち合わせ中に私自身も疑問を持ったのに、その場で確認されないまま話が流れていく場面がありました。担当者は理解したつもりでも、チームへ持ち帰ると肝心な点が決まっていない。再確認しないまま作り始めれば、後で認識のずれが表に出ます。

個々の案件の失敗を一つの原因だけで説明するつもりはありません。ただ、私が開発を進める立場になってから、分からないことを分からないまま持ち帰らないと決めた理由は、この経験にあります。

「わかりました」の後に、誰が何を決めるのか

打ち合わせで怖いのは、知らない言葉が出ることではありません。聞き返せないまま、全員が理解したことにしてしまうことです。

発注側は業務を知っています。開発側はシステムを作る方法を知っています。同じ言葉を使っていても、見ている範囲は違います。たとえば、画面に項目を追加するという話でも、入力した値をどこへ保存し、既存の処理にどう渡し、後から変更できるようにするかは、別に確認が必要です。

私は以前、顧客との打ち合わせを聞きながら「ここはまだ分からない」と感じても、そのまま議題が進む案件を経験しました。戻ってからチームが確認しようとしても、顧客に聞くべきことが残っています。そこで改めて聞ければよいのですが、その確認が弱いまま進むと、開発側の想像が仕様の代わりになります。

だから私は、自分が担当する打ち合わせでは、多少細かいと思われても、その場で聞くようにしています。誰が使うのか、今はどう処理しているのか、例外が起きたらどうするのか。質問に時間を使ったほうが、間違った前提で作り直すよりましです。

技術を知る人が同席すると、質問の深さが変わる

曖昧さは、業務と技術の境目に残りやすいと感じます。要望自体は分かっても、既存システムとの関係、技術的な実現方法、変更後の保守まで考えると、その場で答えられないことがあります。

たとえば「この処理を自動化したい」という要望なら、少なくとも次の点を確かめたいです。

• 今はどの情報を見て、人が何を判断しているか
• 既存システムのどの処理やデータに影響するか
• 例外が起きたとき、誰が気づいてどう直すか
• 今回の開発費と、その後の変更や運用にかかる手間

これは発注者に技術用語を覚えてほしいという話ではありません。開発側が業務の意図を聞き切り、技術上の条件を説明できるかが重要です。

顧客と話す人と実装するエンジニアが分かれていても、うまく連携できれば問題ありません。ただ、顧客との会話で技術的な疑問に気づけず、社内でも確認しないまま話が進むと、伝言のたびに前提が抜けます。顧客折衝を担う人にプログラミングの経験があると、こうした論点に気づきやすい。私自身はそう考えています。ただし、技術を知っているだけでは足りず、分かるまで質問する姿勢が必要です。

「できます」と即答せず、確かめてから答える

その場で技術的な可否を判断できないなら、私は「できるかもしれません。確認してから回答します」と伝えます。調べてみると、既存システムの制約が見つかるかもしれません。動作は実現できても、運用時の負担が大きいかもしれません。

確かでないことを「できます」と約束すると、その一言を前提に発注側の計画や開発のスケジュールが組まれます。後から難しいと分かれば、機能の見直しに加えて、予算や公開時期の調整も必要になります。

確認の仕方も大切です。資料やコードを読むだけで判断しきれないなら、対象の処理を実際に動かして確かめる。持ち帰った内容と確認結果を、メールか次の打ち合わせで伝える。できること、条件付きでできること、まだ分からないことを分けて答えます。

作れるかに加え、維持できるかまで話す

技術的には可能でも、必ず作るべきとは限りません。複雑な仕組みを追加すれば、以後の改修や障害対応に時間がかかることもあります。一方で、保守に手間がかかっても、事業上の効果が大きければ選ぶ理由があります。

開発側は可否に加え、選択肢と条件を伝えたいです。どの方法なら実現できるか。最初に作る範囲はどこまでか。後の運用にどんな負担が残るか。それぞれの費用と事業への影響を並べて、顧客が判断できるようにする。私はそうした提案をしたいと考えています。

発注側も、答えを急がせるより「何を確認すれば判断できるか」を聞いてみてください。まだ分からないと正直に言い、調べる手順と回答時期を示す相手なら、少なくとも不確かな約束を前提に開発を進めずに済みます。

次の打ち合わせでは、未確認のことを一つ残さない

すべての仕様を一度の会議で決める必要はありません。決まっていないことを、決まったこととして扱わない。それだけでも、会議後の進め方は変わります。

私なら打ち合わせの終わりに、決まったこと、顧客に確認すること、開発側で調べることを分けます。技術的な可否が未確認なら、何を実際に試すか、いつ返答するかも決めます。結果を受けて、保守コストと事業への効果を見ながら発注側が選べばよいのです。

IPAの「要件定義は発注者の責任である」も、要件の曖昧さや検討不足がコスト増、納期遅れ、品質低下につながり得ると指摘しています。発注側が業務の目的を説明し、開発側が不明点を聞き切る。どちらか一方が黙って補完しても、認識はそろいません。

外注前に自社で決めておきたい範囲は、システム開発を外注に丸投げしないためににまとめています。業務フローから作る範囲を考えたい場合は、システム開発の要件定義の進め方も参考にしてください。この記事で伝えたいのは、その後の会話でも曖昧さを見逃さないことです。気になる一言をその場で聞き返せるかどうかが、作り直しを防ぐ最初の分かれ目です。