じょん総合研究所
Jeong Lab
AI × SOFTWARE ENGINEERING
AIを、ビジネスに実装する。
ノウハウ

納品後に「思っていたのと違う」を防ぐコミュニケーション設計

納品後に「思っていたのと違う」を防ぐコミュニケーション設計

システムが納品されたのに「思っていたのと違う」と感じてしまう原因は、技術よりも途中のやり取りにあることが多いものです。発注側が押さえたい確認の仕組みを整理します。

5分で読めるじょん総合研究所

システム開発や業務アプリの導入で、いちばん残念な結果のひとつが「納品されたけれど、思っていたものと違った」という状態です。費用も時間もかけたのに、現場で使われない。発注者と開発者の双方にとって、これほど消耗することはありません。

多くの場合、その原因は技術力の差ではなく、途中のコミュニケームの設計が不十分だったことにあります。この記事では、ITに詳しくない経営者や担当者の方が、納品後のギャップを減らすために押さえておきたいポイントを整理します。

「違う」が生まれる本当の理由

発注側が頭の中で思い描いている完成形と、開発側が理解した完成形は、同じ言葉で話していても一致していないことがよくあります。たとえば「顧客情報を管理できるようにしてほしい」という一言を考えてみてください。

  • 発注者は「電話番号と担当者名がすぐ探せればよい」と考えている
  • 開発者は「顧客の履歴、契約情報、請求情報まで含めるのだろう」と理解している

どちらも間違ってはいません。しかし、言葉が共有されていないために、完成したものを見て初めて食い違いに気づくのです。

また、もうひとつの大きな要因は「確認のタイミング」です。作業の途中で画面や動きを一度も見ないまま、最後に一気に確認すると、直すべき箇所が多くなり、修正のたびに追加費用や納期の遅れが発生しがちです。

認識のずれを減らす3つの仕組み

1. 「完成の姿」を文章と画面の両方で共有する

「使いやすい画面」「わかりやすい一覧」といった言葉は、人によって想像する姿が違います。以下のような形で、具体的に共有することをおすすめします。

  • 今の業務で、誰が、どの順番で、何を入力し、何を確認するのか
  • 完成後に「これができれば成功」と言える基準は何か(例:月末の集計が手作業ゼロになる、など)
  • 紙の帳票やExcelの画面など、今使っているものを写真やスクリーンショットで共有する

ポイントは、要望を「機能の名前」ではなく「業務の流れ」で伝えることです。機能名だけだと、開発側は一般的な解釈で作ってしまいがちです。

2. 途中の画面を、早い段階で必ず見る

完成前に、画面の試作版(プロトタイプ)や動くものを確認する機会を、スケジュールの中に最初から組み込んでおきます。大切なのは、見るタイミングを「最後」にしないことです。

確認の場では、次のような質問を発注者側から投げかけてみてください。

  • 普段の業務でこの画面を開いたとき、最初に目に入るのは何ですか
  • この項目は、必ず入力する必要がありますか。それとも後から入れても困りませんか
  • 間違えて押してしまったとき、元に戻せないと困りますか

見た目の好みだけでなく、現場の動きに合っているかを確かめることが目的です。

3. 「決めたこと」と「まだ決めていないこと」を記録する

打ち合わせのあとに、決まった内容を短いメモにまとめて、双方で合意しておく習慣が効果的です。後から「そんな話はしていない」となるのを防げます。

記録には、次の3つを分けて書いておくと整理しやすくなります。

  • 決定事項:例「承認は店長まで。担当者の承認は不要」
  • 保留事項:例「請求書の様式は、経理担当に確認してから決める」
  • 対象外の事項:例「今回のリリースでは、スマホ対応は含まない」

「対象外」を明記しておくことは、特に重要です。書かれていないことは、相手が当然含まれていると考えてしまうからです。

発注側が担える役割

開発会社に任せきりにするのではなく、発注側も次のような役割を担うことで、納品後のずれは大きく減ります。

  • 業務の担当者を最低1人、プロジェクトに参加させる(経営者だけの判断では現場の細かい運用が抜けやすい)
  • 社内で意見が割れている点は、開発を始める前に社内で決めておく
  • 「いつまでに、誰が、何を返すか」を決めておく。回答が遅れると、開発の手が止まってしまいます

「要望を完璧に伝えなければならない」と構える必要はありません。わからないことは、わからないと伝えることがむしろ大切です。開発側が質問しやすい雰囲気を作ることも、発注者の大事な役目です。

納品後にも確認の場を持つ

納品がゴールではありません。実際に使ってみると、初めて見えてくる問題も多くあります。納品後の数週間は、現場の声を集める期間として、定期的に振り返りの時間を取ることをおすすめします。

また、小さな修正を気軽に依頼できる窓口や、運用のルールを決めておくと、「使いにくいけれど言い出せない」状態を防げます。

まとめ

納品後の「思っていたのと違う」は、多くの場合、途中のやり取りの設計で防げるものです。

  • 完成の姿を、業務の流れと画面の両方で共有する
  • 途中の画面を、早い段階から繰り返し確認する
  • 決定事項・保留事項・対象外を、記録として残す

難しい技術の話は、開発会社に任せて構いません。一方で、「自社の業務がどう動いているか」を言葉にするのは、発注側にしかできない大切な仕事です。

「何を、どこまで伝えればいいかわからない」「前に任せた開発で行き違いが起きた」といったお悩みがあれば、LINEでお気軽にご相談ください。整理の段階から一緒に考えることもできます。

この記事をシェア
LINE

システム開発のご相談は、LINEで気軽にどうぞ。AIが24時間ヒアリングします。

LINEで相談する