要件通りに作ったのに「思っていたのと違う」と言われる理由—— SIerが見落とす「翻訳」の工程

顧客から「こういうシステムが欲しい」と言われる。
↓
ヒアリングして、要件を整理して、提案書を作って、見積もりを出す。
↓
受注できれば、設計して、作って、納める。

まっとうな仕事の流れに見えます。実際、プロジェクトは回っている。

でも、納品した後にこんな声を聞いたことはないでしょうか。

要件通りに作ったはずなのに、顧客が満足していない。

その理由を、
「要件定義が甘かった」
「顧客側の意思決定が曖昧だった」
と説明していないでしょうか。

「設計図通りに建てました」で終わっていないか

建築に例えると、この構造が見えやすくなります。

施主が「広いリビングが欲しい」と言ったとします。
その言葉をそのまま設計図に落とせば、確かに広いリビングはできる。

でも、施主が本当に望んでいたのは
「家族が自然と集まる場所」だったかもしれません。

広さだけでは、人は集まらない。
動線、光の入り方、キッチンとの距離感。

施主自身も言葉にできていない
「暮らしの想い」を汲み取って、初めて住む人に合った空間が生まれます。

SIerの現場でも同じことが起きています。

顧客の
「こういう機能が欲しい」という言葉は、
施主の「広いリビングが欲しい」と同じです。

その裏にある

• なぜそれが必要なのか

• その機能で本当は何を実現したいのか

という Why を、誰が翻訳しているでしょうか。

要件をそのまま設計に落とすのは、施工者の仕事。
顧客のWhyを引き出し、仕組みに変換するのは 第1回で述べた「設計者」の仕事です。

その設計者の役割が
多くのプロジェクトで誰にも担われていません。

「提案力がある」と「翻訳力がある」は違う

SIerの強みは、技術力と提案力だと言われます。

• 最新のソリューションを知っている

• 事例も豊富にある

だから、顧客の課題を聞けばすぐに
「こういう技術で解決できます」と提案できる。

でも、その提案は本当に
顧客の「想い」から出発しているでしょうか。

顧客が「DXを推進したい」と言ったとき、

• どんな組織になりたいのか

• どんな価値を届けたいのか

こうした問いを引き出す前に、
ソリューションの話を始めていないでしょうか。

ある修了生はこう語っていました。

この言葉は、技術に強い人ほど陥りやすい落とし穴を突いています。

提案力は「What」と「How」の力です。
翻訳力は「Why」を引き出して構造に変える力です。

後者がなければ、どれだけ優れた提案も、顧客の想いとズレます。

しかも、この「翻訳」の工程が抜けるのは、個人の能力不足ではありません。SIerのビジネスモデルは工数と単価で成り立っています。見積もりの中に「顧客のWhyを引き出す時間」は入らない。翻訳の工程は、ビジネスの構造そのものが排除してしまっているのです。

あなたの提案に、この問いは答えられますか？

いま手がけているプロジェクトに、こう問いかけてみてください。

• 「この提案は、顧客のどんな想いを実現するためにありますか？」

「こういう機能を作ります」ではなく、

と言えるでしょうか。

もし答えに詰まるなら、足りないのは技術でも事例でもなく、
顧客の想いを仕組みに翻訳する力かもしれません。

この連載では、DXの推進に関わるすべての人が直面する「構造的な盲点」を、隔週で掘り下げています。

次回もお読みいただけたら嬉しいです。
よろしければ、フォローしてお待ちください。