2026-08-09
「できます」の先を確かめる——発注側がベンダー選定で使える問いの立て方
Argora編集部
ベンダーに声をかけると、みんな「できます」と自信満々に答える。技術を判定できない側が技術の判定を求められるこの構造と、感触以外の選定軸をどう持つかを考える。
デジタル化のために業者を探し始めたとき、多くの事業者が最初にぶつかるのは「選べない」という問題だ。候補のベンダーに連絡すると、みんなが「できます」と答える。自信満々に、なんでも。こちらはデジタルのプロではないから、何がどこまで本当にできるのかを判断する手立てがない。
商談を3回重ねて、ようやく「あ、これは無理だったんだ」と分かることがある。業者が嘘をついていたというよりも、お互いに「できる」の意味をすり合わせないまま話を進めていたからだ。
技術を知らない側が技術を判定するという矛盾
この構図には、根本的な非対称がある。ベンダーは自分たちの技術の得意・不得意を分かっている。発注側は分からない。だから「できますか?」と聞けば「できます」と返ってくる。相手が嘘をついているわけでなく、質問が漠然としているから、漠然と「できます」と言えてしまう。
問題は、この状況で「判定してください」と発注側に求められることだ。見積もりを比べ、実績を眺め、最後は「なんとなく信頼できそう」という感触で決める。けっして小さくない投資の決断を、その感触が支えている。
見積書をめぐる「探す」問題でも、似た構造が起きる。情報の非対称が、判断そのものを難しくする。
「感触が合わない」は正確なシグナルかもしれない
「感触しか残らない」と嘆く前に、考えてほしいことがある。その感触は、意外と正確なものを測っている可能性がある。
選定の決め手として挙げられることが多いのは、こういう観察だ。
- 質問したら質問で返してくる
- こちらのやりたいことを理解してもらえる
- 話していて、どこかが噛み合わない
これらは「好き・嫌い」ではない。コミュニケーションの質を測っている。
「質問で返してくる」ベンダーは、課題をまだ理解しきれていないことを自覚している。だから問い返す。「何でもできます」と即答するより、問い返してくるほうが、実は信頼に足る。「話が噛み合わない」も同様だ。業務の言葉と技術の言葉の間を橋渡しする力がなければ、開発が始まってから噛み合わなくなる。商談段階でのズレは、実装段階のズレの予兆だ。
「共通言語があるかどうか、それだけなんです。技術の話じゃなくて」
技術評価とは別に、こういう観察は有効な判断材料になる。感触を「感情的な選択」と切り捨てないほうがいい。
判定の場に「第三者」を置く
とはいえ、感触だけを頼りにする状況が理想でないのは確かだ。選定の精度を上げるために有効なのは、事業者でもベンダーでもない立場の第三者を場に置くことだ。
その役割はこうなる。
- 業務の要件を技術の言葉に翻訳する
- ベンダーの「できます」が何を意味するのかを問い直す
- 複数の提案の前提の違いを並べて見せる
DXの提案が社内を通らない場面でも、「言葉の翻訳」が鍵になることが多い。技術側と事業側をつなぐ人が場にいるかどうかで、議論の質が変わる。
ベンダーを選ぶ力は、技術知識から生まれなくていい。要件を整理し、問いを立て、「この質問に答えてもらえるか」を確認する工程を助けてくれる第三者がいれば、感触以外の軸が生まれる。
しぼる(DX伴走支援)では、こうした選定の場面から関わることができる。発注側の業務を整理し、ベンダーとの対話を構造化する。技術を評価するのではなく、対話を評価できる状態をつくることが出発点だ。
「できますか?」と聞けば「できます」と返ってくる。その構造は変わらない。変えられるのは、その後に何を確かめるかだ。
FAQ
よくある質問
ベンダー選定で技術力を評価する方法がわかりません。どうすればいいですか?
技術そのものを評価するのではなく、コミュニケーションの質を見るのが現実的です。要件を話したとき質問で返してくるか、話が噛み合うかを確認してください。
ベンダーが「できます」と言っているのに信じていいですか?
「できます」だけでは判断できません。具体的にどう実現するかを問い、自社の業務に当てはめた説明ができるかを確認することが重要です。
ベンダー選定に第三者を入れるメリットは何ですか?
事業者でもベンダーでもない立場の第三者は、業務要件を技術仕様に翻訳し、ベンダーの回答の妥当性を評価できるため、選定の精度が上がります。
Related
Argo:デジタルの、ほかの読みもの
2026-08-11
自動化は業務フローを固定する——AIエージェントを乗せる前に確かめること
AIエージェントを業務に組み込む前に、問うべきことがある。自動化はフローを固定する技術であり、整っていないものを乗せれば、誰も読めない仕組みが生まれる。
2026-08-10
「非効率」と呼ぶ前に受け取るべきもの——現場の経験を失わないDXの進め方
アナログな業務を「非効率」と断じてデジタル化を進めると、現場が培った判断力と責任感ごと失いかねない。経験を受け取ってから設計することが、DXを根付かせる起点になる。
2026-08-10
ベンダーを動かすのは仕様書ではない——事業者が磨くべき「課題を語る力」
システム開発の失敗の多くは、技術ではなく「課題の伝わらなさ」から起きる。事業者がITを学ぶとはコードを書くことではなく、問いを立てる力を身につけることだ。