2026.09.02

システム会社との打合せで失敗しないコツ｜専門用語を使わずに要望を伝える技術

執筆者情報

中村圭介

株式会社カジヤ/代表取締役　男性向けファッション通販サイト運営の会社を経験し、現職に至る。デザインや開発から、ECやメディアのコンサルティングまでを一貫して行う。お付き合いのあるお客様の事業を成功に導けるように、再現性のある成長支援ができる会社を目指す。

【AIによる要約】
– 打合せの失敗の原因は「用語の知識不足」ではなく「曖昧な言葉のまま合意してしまうこと」にあります。
– 打合せ前の準備は「誰が・いつ・何を」の形での不満リストと理想の動きの例。打合せ中は3つの確認フレーズで認識のズレを潰します。
– 打合せ後は当日中に自分の言葉で確認メールを送り、費用の認識までズレを潰すことが後工程のすれ違いを防ぎます。

システム会社との打合せイメージ

はじめに：「言ったのに違うものができた」問題

「打合せでちゃんと伝えたつもりなのに、納品されたら全然違うものだった」

Webサイトやシステムの発注側担当者が抱える悩みとして、これほど頻繁に耳にするものはありません。当社は業界歴10年以上で300社以上の企業サイト・Webシステムを支援してきましたが、その中で他社が作ったシステムの引き継ぎや改良を担当することも少なくなく、「最初の打合せで何が起きていたのか」を事後に想像せざるを得ない場面に何度も直面してきました。

そして見えてくるのは、こうしたすれ違いの多くが発注側の知識不足ではなく、双方が曖昧な言葉のまま合意してしまったことで起きているという事実です。

この記事では、専門用語をほとんど知らなくても実践できる「要望の伝え方」を、打合せの前・中・後に分けて具体的に解説します。読み終えるころには、次の打合せからすぐ使える形に整理できているはずです。

なぜ「専門用語を覚える」のは間違った努力なのか

打合せに失敗する担当者の多くは、「PHPとかCMSとか、用語を勉強しなければ」と考えがちです。しかし、これは努力の方向がズレています。

用語には複数の意味がある

たとえば「更新」という一語を取っても、担当者は「記事を投稿する」ことを思い浮かべ、エンジニアは「プログラムのバージョンアップ」を思い浮かべていることがあります。片方が「毎月の更新が楽になりたい」と言い、もう片方が「バージョンアップの計画を立てよう」と答える——この会話は、両者とも真面目にしているのに、まったく噛み合いません。

用語は知識があればあるほど「通じている気にさせる」危険性を持っています。半分だけ知っている用語ほど、確認を省略させてしまうのです。

発注側が持つべきは「用語」ではなく「状態の語彙」

プロとして明確に言い切りますが、発注側の担当者に必要なのは用語ではなく、今起きていることと理想の状態を具体的に説明する語彙です。

「〇〇の画面で、お客様が見積依頼ボタンを押しても、送信できたかどうかが分からず、電話で『届きましたか？』と確認する人が後を絶たない」——この一文は、どの専門用語よりも多くの情報を正確に伝えます。エンジニアはこれを聞けば、技術的な原因と対策を自分の言葉で組み立てられます。

当社が300社以上と関わってきた経験から言えば、プロジェクトが成功する案件の担当者は、専門用語を流暢に使う人ではなく「現場の困りごとを生々しく語れる人」でした。

要望を構造的に伝えるイメージ

打合せ「前」の準備：持ち込むのは仕様ではなく「困りごと」

用意するものは2つだけ

現状の不満リスト:今のサイトやシステムで「時間がかかる」「間違えやすい」「分からなくて困る」場面を、発生順に書き出す
理想の動きの例:「こうなったらいいな」を、自社または他社の具体例で表現する

「誰が・いつ・何を」で書く

不満を書くときのコツは、主語と場面を必ず入れることです。

✗ 「管理画面が使いにくい」
○ 「更新担当の総務のAさんが、 news ページに1記事追加するのに30分以上かかっており、他の業務を圧迫している」

後者の形にしておけば、打合せの場で「30分の内訳はどこか」「月に何件発生するか」という具体の確認に進めます。工数の話が数字になると、費用対効果の議論も一気に現実的になります。

落とし穴：「こう作ってほしい」まで語りすぎない

逆に注意すべきは、発注側が画面設計や処理の手順まで細かく指定してしまうケースです。「このボタンをここに置いて、押したらこういう画面に遷移して……」と語ると、本当に解決すべき課題が仕様の詳細に埋もれてしまいます。専門の視点を持ち込むのは相手の仕事です。持ち込むのは「目的」と「困りごと」、確定するのは打合せの場で、が基本のスタンスです。

打合せ「中」：使うのはたった3つのフレーズ

当日は、次の3つの確認フレーズがあれば用語の知識はほぼ不要です。

1.「それを、もう少し噛み砕いてもらえますか？」

エンジニアの説明に聞き慣れない言葉が出てきたら、恥ずかしがらずにこの一言を。用語の意味を聞くより「噛み砕いて」と頼むほうが、相手は具体例やたとえ話で説明し直してくれます。説明し直してもらった内容が自分の理解と合えば前進、合わなければ実はまだ認識がズレている、ということが確実に分かります。

2.「それは、画面上だとどの動きのことですか？」

抽象的な説明を受けたら、具体的な画面や操作に落とさせる質問です。「検索性を向上させます」「導線を最適化します」といった言葉は、画面上のどの操作がどう変わるのかが分からなければ評価できません。白紙や画面に書いてもらい、「このボタンが、こう変わる」という形まで確認してください。

3.「それをしないと、どんな不都合が起きますか？」

追加費用や工数の見積が出てきたときに効く質問です。提案された対応の必要性を理解するためにも、「やらなかった場合に誰が・いつ困るのか」を確認しておくと、優先順位を自社の判断でつけられます。良い制作会社はこの質問に快く、具体的に答えます。

議事録は「その場で・自分の言葉で」

打合せ中にパソコンを開き、聞いた内容を自分の言葉で書き留めてください。後で相手の議事録を鵜呑みにするのではなく、「私はこう理解したが合っているか」を確認する材料にするのが目的です。専門用語が出てきたら「〇〇(自分なりの言い換え)のことですね」と書き、後で確認します。

プロの現場からの実体験をひとつ。当社でも長年やっているのは、打合せの最後に「本日のゴールと、次回までの分担を、お互いの言葉で読み上げて確認する」工程です。この5分が、後工程のすれ違いの大半を防ぐと確信しています。

確認事項を整理するチェックリストのイメージ

打合せ「後」：メールで「理解のズレ」を潰す

返送してもらう前提で確認メールを送る

打合せ当日中に、次の3点を自分の言葉でまとめたメールを送ります。

決まったこと(ゴール・範囲・期日)
未決事項と、いつまでに誰が決めるか
認識合わせで受けた回答の要約

そして「認識に相違があればお知らせください」と一文添えます。この一文があるだけで、後から「言った・言っていない」の水掛け論をかなり減らせます。

落とし穴：「で、結局いくらなのか」を確認しない

打合せで良い空気のまま終わって、費用の話が保留のまま進んでしまうパターンは注意が必要です。良い提案だったとしても、「この範囲なら概算いくら程度か」「次の打合せまでに正式見積を出せるか」を口頭かメールで必ず確認してください。後工程の失望の多くは「費用の認識が最初からズレていた」ことに起因します。

それでもすれ違いが起きるとき：判断の境界線

誠実に準備し、確認し、記録しても、相違が起きることはあります。そのときの線引きを明確にしておきます。

打合せの記録と照らし合わせて、相手の認識不足・伝達ミスの可能性が高い場合：まずは記録ベースで認識合わせを依頼する。誠実な会社であれば対応します。
仕様の追加・変更によって当初の範囲を超えた場合:追加費用は発生するのが自然です。「最初から聞いていた話だ」と思える案件は、逆に自分側の準備(不満リスト・理想の例)が不足していなかったかを振り返る機会にしてください。
何度確認しても抽象的な言葉でごまかされる、記録を残したがらない場合:それは伝え方の問題ではなく、パートナーとして適切かどうかの問題です。悪い意味での「プロぶった」対応が続くなら、第二の意見を聞くことをためらわないでください。

当社が代理店を挟まない直接取引にこだわるのも、この「記録と認識合わせ」を発注側・受注側の両方の当事者として行うためです。自社でもWebサービスやECサイトを運営しているからこそ、打合せの場で発注側の不安がどこにあるのかを、同じ目線で汲み取ることを意識しています。