「言語化の技術②」曖昧を具体にする、2つの手法

2026年2月16日にdotD noteに投稿された記事です。

このシリーズでは「言語化」をテーマに、DXの現場で起きている本質的な問題、PMとして使っている具体的な手法、そして生成AIがこの壁をどう変えるかを全3回で書いていきます。

前回、DXの現場で最も厄介な壁は技術ではなく「言語化」だと書きました。クライアントの「自社で直販がやりたい」「生成AIの基盤を作りたい」といったモヤっとした言葉の裏には、本当にやりたいことが隠れている。その意思を言語化してあげることが、いま求められている能力だと。

では、「言語化してあげる」って具体的に何をするのか。

今回は、PMとして現場で実際に使っている中の2つの手法について簡単にご紹介したいと思います。

触診——「なぜ」を重ねて、本当の課題を探り当てる

1つ目は、触診——と勝手に呼んでいるのですが、いわゆる「なぜなぜ分析」に近いものです。ただ、もう少し柔らかく、医者が患者の症状を聞きながら原因を絞り込んでいくようなイメージで使っています。段階的に質問を重ねて、相手が本当に解決したい課題を探り当てていきます。

例えば、ある業務システムのプロジェクトで、クライアントから「承認フローが煩雑なので、もっと簡略化してほしい」のような要望を言われたことがありました。一見すると、UIやワークフロー設計の問題に見えます。

そこで順に聞いていきました。
「煩雑というのは、具体的にどのあたりですか？」
　——承認に時間がかかっています。
「なぜ時間がかかるんでしょう？」
　——差し戻しが多いからです。
「差し戻しが多いのはなぜですか？」
　——申請内容の粒度が人によって違うからです。
「なぜ粒度が揃わないのですか？」
　——申請基準が明文化されていないからです。
「なぜ明文化されていないのですか？」
　——各部門の裁量に任せており、統一ポリシーがないんです。

といった具合に、掘り下げていくと見えてきたのは「フローが複雑」という表層の問題ではなく、意思決定基準が曖昧だという構造的な問題でした。基準が曖昧だから確認が増え、確認が増えるから承認が長引く。UIを簡略化しても、差し戻しは減りません。

最初の言葉は「フローを簡単にしてほしい」。でも本当の課題は、ガバナンス設計と判断基準の未整理にあったわけですね。

これは業務システムに限った話ではありません。DXの企画でも、新規事業の相談でも、真の課題に直結する言葉を最初から持っている方は、実はそう多くないんですね。表層的な症状だけが見えている場合もあれば、課題を把握していても、それをうまく言葉にできない場合もあります。だからこそ、触診が必要になると考えています。

プロトタイプ——モノを見せて、空中戦を止める

2つ目は、プロトタイプをぶつけるという手法です。

触診で情報を集めたら、こちらで想像を膨らませて、コンセプトレベルのデザインプロトタイプを作ります。だいたい1週間くらいで形にして、「あなたのやりたいことは、例えばこういうイメージですか？」とぶつけます。

なぜわざわざモノを作るのか。言葉やパワーポイントの資料だけだと、会話が空中戦になりやすいからです。お互いが同じ話をしていると思い込んでいて、実はまったくズレていた——こういう経験ありませんか。

実物に等しいモノを見せると、これが起きません。認識が違えば「違います」とはっきり返ってきますし、同じモノを見ながら会話するので「具体的にどこが違うのか」も言いやすい。合っていてもズレていても、話が確実に前に進むんですね。

例えば、ある案件で「商品企画を生成AIを使って高度化したい」という、まだ漠然としたお題をいただきました。こちらで想像を膨らませて、現行の販売実績をもとに新製品の仕様が検討できるプロトタイプを作って見せたところ、クライアントから「こういう考え方があるのか。じゃあ製品のバリエーション単位でもできますか？ 実はですね……」と、1つのアイデアからイメージが膨らんで、発展的な議論が始まりました。

もちろん、外すこともあります。社員が持つアイデアを企業の競争力に活かしたいというテーマに対して、アグレッシブな社内SNSのプロトタイプを提案したことがありますが、これは箸にも棒にもかかりませんでした（笑）。

繰り返しになりますが、外れたとしても「これではない」ということが具体的に分かります。言葉だけで議論していたら数ヶ月かかったかもしれない認識合わせが、モノを1つ見せることで一瞬で終わる。当たっても外れても前に進む。だから早く・安く作ってぶつけることに意味があるんですね。

触診→プロトタイプ、この順番に意味がある

実際の現場では、この2つを別々に使うというより、触診→プロトタイプの順番で使うことがほとんどです。

まず触診で軽くヒアリングして、仮説を作るために必要な情報をいただく。その情報をもとにプロトタイプを作り、ぶつける。返ってきたフィードバックをもとにまた触診し、次のプロトタイプを作る。このサイクルを短期間で回すことで、スピード感を持って「曖昧」を「具体」に変えていきます。

この2つに共通しているのは、相手の最初の言葉を額面通りに受け取らないということかもしれません。「フローを簡単にしてほしい」をそのまま実装しない。「商品企画をAIで高度化したい」を言葉のまま解釈しない。最初の言葉はあくまで入り口であって、その奥にある本当の意思を一緒に掘り出していく。それが「言語化」の仕事だと考えています。

そしてもう一つ、大事だと思っているのは、相手の課題を自分ごととして捉えるということです。触診もプロトタイプも、一方的に分析して答えを出すものではありません。「この人は何を実現したいのか」を自分の頭で考え、自分なりの仮説を持って動く。相手と一緒に考えながら形にしていく。長くPMとしてやってきて思うのは、「曖昧を具体にする」の本質は、そういった対話の姿勢なのだと思っています。

次回は、この対話のプロセスに生成AIが加わったとき、何が変わるのか。そして、変わらないものは何か。シリーズ最終回です。