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

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

10年以上前、ある自動車メーカーのシステム開発PMをやっていた頃の話です。

クライアントにはビジネス目標があり、それを実現するためにシステムの構築や改善が必要になる。何を作るかの要件が決まり、それがエンジニアの手元では具体的な設計や実装の仕様に落ちていきます。エンジニアは期日までに、決められた仕様を満たすシステムを品質目標通りにリリースすることが求められていました。

一見、きれいな流れに見えます。でも、実際にはそうはいきません。

当時はウォーターフォール型の開発でしたが、要件定義の工程で完璧な要件が作れるわけもなく、エンジニア側も完璧な設計ができるわけでもありません。工程が進むにつれて、仕様検討漏れや不具合が出てくる。そうなると、クライアントの要求と開発側の目線がだんだんとずれてきます。

これは技術力の問題でも、プロセスの問題でもありませんでした。言葉の問題——「言語化」の問題だったと、いま振り返って思います。

「目線のズレ」は言語化されないまま広がる

こうした経験を積んだエンジニアほど、過去に痛い目を見てきてもいます。自分たちを守る意識が強くなるのは、ある意味で当然のことです。

クライアントは「ビジネス目標を達成したい」。エンジニアは「期日と品質を守りたい」。どちらも正しいのですが、この2つの目線は、工程が進むにつれて構造的にずれていきます。しかも、そのズレは明確に言語化されないまま広がっていくんですね。

PMとして間に入っていた当時、打てる手は全て打っていました。会議の場ではクライアントとエンジニア双方の目線を意識しながら、最適な案を出す。不具合が出て期限を守れないと判断したときは、トレードオフの条件を提示してクライアントと交渉する。逆に、エンジニア側の負荷を少し上げれば対応できるケースでは、なぜそれが必要なのかを個別にしっかりと説明して動いてもらう。

基本原則は一つです。クライアントの目的達成を最大化するために、限られた制約の中で何ができるか。

この原則がブレなければ、表面的な調整ではなく本質的な交渉ができます。クライアントとの信頼も、取り繕いではなく「この人はうちの目的を本気で考えてくれている」という実感のうえに築けます。

ここで大事だったのは、両者の目線のズレを「言語化」して見える形にし、そこから落としどころを探ること自体が、PMの仕事の核でした。

DXの現場では、もっと手前に「言語化の壁」がある

時代が変わって、問題はさらに手前に移っています。

いまDXの現場で見る「言語化の壁」は、かつてとは次元が違います。「要件をどう伝えるか」ではなく、そもそも「何をやりたいのか」自体が言語化されていない。DXに関わっている方なら、こういう場面に心当たりがあるのではないでしょうか。

「そろそろ自社で直販がやりたい」「生成AIの基盤をうちでも作りたい」——こういったモヤっとした言葉は出てきます。でも、その先の具体が見えない。

ここで「早く要求を具体化してください」「もっとはっきり説明してください」と言うのは、ナンセンスだと考えています。市場の変化は速く、半年前の前提が今日は通用しないこともある時代です。作れば売れるという時代でもありません。仮説検証を繰り返しながら探索し続けることが前提の世の中です。初めから答えを持っていることは期待できません。

大事なのは「意思」があることです。

モヤっとした言葉であっても、そこには本当にやりたいことが込められています。「自社で直販」の裏には、仲介に頼らない収益構造を作りたいという意思があるかもしれない。「生成AIの基盤」の裏には、社内の業務効率を根本から変えたいという意思があるかもしれない。

その意思を言語化してあげること。これが、いまDXの現場で最も求められている能力ではないかと感じています。

「曖昧を具体にする」という仕事

SIer時代は「要件を正確に伝える」レベルの言語化の壁でした。少なくとも「何を作るか」は決まっていて、ズレが起きるのは「どう作るか」「いつまでに間に合わせるか」の話でした。いまは「そもそも何を達成したいか」のレベルです。壁の位置が、もっと根っこに移っています。

そしてこの壁は、技術の進歩やプロセスの改善だけでは越えられません。ツールがどれだけ便利になっても、「曖昧な意思を具体的な言葉にする」のは、結局のところ人の仕事です。

PMとして18年やってきて、自分の仕事を一言で表すなら「曖昧を具体にする」ことだと思っています。それは要件を整理するだけの話ではなく、クライアントのモヤっとした意思の中から本当にやりたいことを掘り出して、形にしていくプロセスそのものです。

次回は、その「言語化する」を具体的にどうやるのか。PMが現場で使う2つの手法について書きます。