システム業者との打ち合わせで「話が通じない」と感じる経営者は多くいます。こちらは業務の話をしているのに技術用語で返ってくる、こちらの要望が伝わっていない気がする、業者の説明が分からないまま進んでいく——こうした違和感を抱えたままシステム開発を進めると、最終的に「思っていたのと違う」システムが納品されます。本記事では、システム業者と話が通じない構造的な原因と、共通言語を作るための3つの実践的な手法を経営者目線で整理します。
この記事の結論（3行）
- 話が通じないのは「業務語」と「技術語」の間に翻訳機能が欠けているため。どちらか一方の責任ではない
- 共通言語は「業務フロー図」「画面モック」「数値要件」の3つの中間言語で作れる
- 通訳役を社内に置くか、外部の業務寄りのパートナーに頼むかで、コミュニケーションコストが大きく変わる
なぜシステム業者と話が通じないのか
システム業者との会話が噛み合わないのは、双方に悪意があるわけではありません。業務を専門にしている経営者と、技術を専門にしているベンダーの間には、言葉と思考の体系が違うという構造的な隔たりがあります。この隔たりを埋める「通訳役」がいないまま打ち合わせを重ねても、会話は表面的な合意で終わり、実質的な理解には届きません。
- 経営者の語彙は「業務」中心、ベンダーの語彙は「技術」中心
- 「何のために」を経営者が、「どうやって」をベンダーが担当する
- 中間にいる通訳役の存在が想定されていない
通訳役の不在は、中小企業の案件で特に顕在化します。大企業なら情報システム部門が通訳役を担いますが、中小企業ではその役割を担う人材がおらず、経営者が直接ベンダーと話すしかありません。結果として、業務語と技術語の双方を理解できないまま会話が進みます。
経営者の語彙は「業務」中心、ベンダーの語彙は「技術」中心
経営者が話すのは「在庫を見える化したい」「営業の生産性を上げたい」「顧客の購買履歴を活用したい」のような業務上の課題です。一方ベンダーが話すのは「マスタテーブルの設計」「権限ロールの分離」「バッチ処理の頻度」のような技術仕様です。両者は同じシステムの話をしているはずなのに、語彙が違うために共通の理解に到達できません。
「何のために」を経営者が、「どうやって」をベンダーが担当する
役割分担としては自然な構図ですが、「何のために」と「どうやって」の間には大きな翻訳ステップがあります。経営者が「在庫の見える化」と言ったとき、それを「リアルタイム在庫表示画面」「アラート通知機能」「在庫推移グラフ」など具体的な機能に翻訳するステップが必要です。この翻訳をベンダーに丸投げすると、ベンダーの解釈次第で違うものが出来上がります。
中間にいる通訳役の存在が想定されていない
業務語と技術語の翻訳を担う「通訳役」が必要だという認識が、発注側にもベンダー側にも薄いケースが多くあります。通訳役は単に両方の言葉を知っているだけでなく、「この業務課題はこの機能で解決できる」という設計思考を持つ人材です。中小企業では社内にこうした人材がいないことが多く、外部に頼るか経営者が学ぶしか選択肢がありません。
共通言語を作る3つの中間言語
業務語と技術語の間を埋める「中間言語」が3つあります。これらを使うことで、経営者とベンダーが同じものを見て話せるようになります。
| 中間言語 | 役割 | 作る人 | 効果 | |---|---|---|---| | 業務フロー図 | 業務の流れを図解して共有 | 発注側（または通訳役） | 「何の業務か」を共有 | | 画面モック | 画面の構成と項目を視覚化 | ベンダー（発注側がレビュー） | 「どう見えるか」を共有 | | 数値要件 | 性能・精度を数値で明文化 | 双方で合意 | 「どこまで作るか」を共有 |
3つの中間言語は、それぞれ役割が異なります。どれか1つでは不十分で、3つを揃えることで会話が噛み合うようになります。発注前に共通言語の有無を整理したい場合は、業務改善・システム見積もりAI適正診断で確認できます。
中間言語1: 業務フロー図
業務フロー図は、業務の登場人物と操作の流れを図解したものです。誰が、いつ、何をするかを時系列で表現することで、ベンダーは業務を視覚的に理解できます。「営業担当が見積もり依頼を受ける → 在庫確認 → 見積書作成 → 上司承認 → 顧客送付」のような図があれば、技術仕様に翻訳する基礎ができます。
業務フロー図は発注側で作るのが理想ですが、書き慣れていないなら手書きでも構いません。重要なのは「自分たちの業務を自分たちの言葉で図にする」ことで、これがベンダーとの共通言語の出発点になります。フロー図を描く際は、登場人物（営業・経理・現場担当など）を縦のレーンに並べ、操作を上から下へ時系列で書いていく形式が読みやすくなります。1業務あたり1枚、A4サイズで収まる程度の粒度が共有しやすい範囲です。
中間言語2: 画面モック
画面モックは、システムの画面構成・項目・ボタンを視覚化したものです。手書きでも、PowerPointの簡易図でも構いません。画面モックがあることで、「ここでこのボタンを押すと何が起きる」を共有でき、機能の解釈ズレが大幅に減ります。
画面モックはベンダー側で作るのが一般的ですが、発注側がレビューする力を持つ必要があります。「自分の業務シナリオでこの画面を使ってみたら、何分かかりそうか」を想像しながらレビューすることで、現場で使えるシステムに近づきます。
中間言語3: 数値要件
性能・精度・容量などの要件を数値で明文化したものです。「検索1秒以内」「同時アクセス50ユーザー」「データ精度99%以上」のように、検証可能な数値で書くことで期待値ズレが防げます。
数値要件は双方で合意するのが基本ですが、経営者側から数値を提示すると主導権を保てます。「現場担当者の感覚では3秒は長い」「同時アクセスはピーク時に30〜50ユーザー」のような感覚値でも、数値化することでベンダーが設計の前提を立てやすくなります。数値で表現された要件は検収時の合否判定にも使えるため、リリース後の揉め事を防ぐ効果も大きい点が特徴です。
経営者目線で考える「通訳役」の置き方
ここからは経営の話です。業務語と技術語の翻訳を担う通訳役を、どこに置くかは経営判断です。3つの選択肢があります。
第一に、社内に通訳役を育てる。情報システム担当または業務改革担当を1名置き、業務とITの両方を学んでもらう方法です。育成には2〜3年かかり、年収500〜700万円のコストが乗ります。長期的には最も強い選択肢ですが、即効性はありません。第二に、外部の業務寄りITパートナーに頼む。業務理解と技術知識の両方を持つコンサルタントやベンダーを通訳役にする方法です。月額30〜80万円程度のコストで、即効性があります。中小企業ではこの選択肢が現実的です。第三に、経営者自身が学ぶ。最低限のIT基礎知識（業務フロー図の書き方、データ項目の意味、画面モックの読み方）を経営者が学ぶ方法です。学習時間は3〜6ヶ月、教材費は数万円で済みます。
3つの選択肢は組み合わせ可能で、「経営者自身が基礎を学ぶ + 外部パートナーを通訳役に置く」が中小企業では最も現実的なバランスです。社内人材の育成は、その後の余裕が出てから検討するのがお勧めです。
ぷらすわんの実例：通訳役としての関わり方
ぷらすわんでは、システム開発の請負だけでなく「通訳役」としての関わり方を意識しています。ある製造業A社のケースでは、A社の経営者が複数のシステム業者から見積もりを取ったものの、どの業者の説明も理解できず判断に詰まっていました。
このケースで関わったのは、開発の請負ではなく「経営者と業者の間に立って通訳する」役割です。経営者が話す業務の課題を、ぷらすわん側で業務フロー図と画面モックに整理し、それを業者に提示しました。同時に業者の見積もり内訳を、経営者に分かる言葉で翻訳しました。結果として、経営者は3社の見積もりを「同じ前提で」比較できるようになり、納得して1社を選定しました。
このようなコミュニケーション支援の役割を、社内人材で代替できる体制が理想です。中小企業の場合、まずは経営者自身が業務フロー図を描けるようになるところから始めるのが、最初の一歩としては現実的です。発注前に通訳役の必要性を項目別に整理したい場合は、現状を整理してから検討するのがお勧めです。
共通言語を作るための5つの実践
業務語と技術語の共通言語を作るための、5つの実践的なステップを整理します。
- 経営者自身が業務フロー図を1枚描いてみる
- 画面モックは「使う側の言葉」でレビューする
- 数値要件は「現場担当者の感覚」から起こす
- ベンダーの説明は「中学生に説明できるか」で測る
- 打ち合わせの議事録は発注側で取る
この5つは、どれも経営者側から始められる項目です。ベンダー側に通訳役を期待するのではなく、発注側が主体的に共通言語を作りにいくことで、コミュニケーションの質が大きく上がります。
経営者自身が業務フロー図を1枚描いてみる
最初の一歩として、自社の代表的な業務（受注処理・在庫管理・請求書発行など）の流れを、経営者自身が1枚の図に描いてみてください。手書きで構いません。これを描く過程で、自社の業務を改めて言語化できます。ベンダーとの打ち合わせ初回でこの図を見せると、会話の質が一段上がります。
画面モックは「使う側の言葉」でレビューする
ベンダーが提示した画面モックを見るとき、「使う側の言葉」でレビューしてください。「この画面で営業担当は何分かけて入力するか」「この画面で経理担当は何件を1日で処理するか」のように、業務シナリオの中で評価することがポイントです。技術的な評価はベンダー側に任せて構いません。
数値要件は「現場担当者の感覚」から起こす
数値要件をベンダーに提示するとき、現場担当者の感覚から起こしてください。「検索が3秒以上かかると現場担当者がイライラする」「ピーク時には30人が同時に使う」のような肌感覚を、そのまま数値要件に翻訳します。理論値ではなく現場感覚が、現場で使われるシステムを作る材料になります。
ベンダーの説明は「中学生に説明できるか」で測る
ベンダーから受けた説明を、経営者が中学生に説明できるかどうかで理解度を測ってください。説明できないなら、自分が理解していないか、ベンダーの説明が抽象的すぎるかのどちらかです。「もう一度、中学生にも分かるように説明してください」と頼める関係性がベンダーとの間にあるかも重要です。優秀なベンダーほど、専門用語を使わずに業務語で説明し直せます。説明を聞いて理解できなかったとき、その場で確認できる関係性こそが、後で揉めない発注の土台になります。
打ち合わせの議事録は発注側で取る
打ち合わせの議事録は、できる限り発注側で取ってください。ベンダー側が取ると、ベンダーの解釈で文書化されるため、後で「言った言わない」が起きやすくなります。発注側が議事録を取り、ベンダーに確認してもらう流れにすると、認識のズレを早期に発見できます。発注前のコミュニケーション体制を比較を依頼する場合も、議事録の運用方法を比較軸に入れてください。
まとめ
システム業者と話が通じないのは、業務語と技術語の間に翻訳機能が欠けているためです。これを埋める3つの中間言語——業務フロー図・画面モック・数値要件——を揃えることで、共通言語が成立し、会話が噛み合うようになります。
通訳役を社内に育てるか、外部パートナーに頼むか、経営者自身が学ぶかは経営判断です。中小企業の現実的な選択は、「経営者自身が基礎を学ぶ + 外部パートナーを通訳役に置く」の組み合わせです。発注前に共通言語の有無を診断することで、コミュニケーションの不安を解消しながらシステム開発を進められます。