SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine(コードジン) DeveloperZine(デベロッパージン)- エンジニアの意思決定を支える技術情報メディア

ProductZine Day&オンラインセミナーは、プロダクト開発にフォーカスし、最新情報をお届けしているWebメディア「ProductZine(プロダクトジン)」が主催する読者向けイベントです。現場の最前線で活躍されているゲストの方をお招きし、日々のプロダクト開発のヒントとなるような内容を、講演とディスカッションを通してお伝えしていきます。

AI時代の「壁」を乗り越えろ。プロダクトマネージャーが直面するカオスと、現場を動かす「仕組み化」のリアル

ProductZine Day 2026

ProductZine Day 2026

「CEDEC2026」レポート

AIがそれらしい文章を書く時代に、なぜ「質問の仕方」を学ぶのか【CEDEC2026】

CEDEC2026 DeNA山口晴美氏が引いた「AIに聞けること」の境界線

AIに聞けるのは、6つのうち2つだけ

 2つ目のテーマは「何が分からないのか分からない」である。寄せられた悩みは2種類あった。「他職種からの質問内容が理解できない」という、自分が理解していないパターン。そして「後輩の話が要領を得ず困っている」という、相手が理解していないパターンだ。山口氏の答えは、両者を1つにまとめるものだった。「職種の壁も若手指導も根本原因は同じです」「分からない部分の解像度をあげましょう」。

 とはいえ、分からないものを前にした瞬間は誰でも焦る。「私はサウンド職ですが、エンジニアやデザイナーからの話が分からないなんてことは日常茶飯事です。もちろん今でもあります」と山口氏は明かす。だからまずは、いったん落ち着く。Slackなどのチャットであれば、「確認して折り返します」と一言送れば済む。

 落ち着いたうえで、何が理解できないのかを考える。山口氏はここで「分からない」を6つに細分化した。

「分からない」ことの6分類(山口晴美氏の講演資料をもとに編集部作成)
分からない事は? どのような状態か
言葉 専門用語や略語の意味が分からない
ツールの使い方 やりたいことは分かるが、ツールの操作方法が分からない
データの仕組み データの仕組みや、裏側でどう動いているかが分からない
答えの場所 ルールのありかや、誰が決定権を持っているかが分からない
前提(文脈) なぜ今その作業が必要なのか、背景や意図が分からない
役割(期待値) 話は理解できるが、自分に何を求めているのか分からない

 分類そのものより重要なのは、その先である。分からないことが何かを特定すると、取るべき手段が自動的に絞り込まれる。山口氏は6つの分類と6つの手段を掛け合わせた表を示した。

「分からない」ことと対処方法のマトリクス。「AIに聞く」に印が付くのは上2行だけである(出典:山口晴美氏の講演資料、以下同)
「分からない」ことと対処方法のマトリクス。「AIに聞く」に印が付くのは上2行だけである(出典:山口晴美氏の講演資料、以下同)

 この表の左端に「AIに聞く」という列があることに注目したい。印が付くのは「言葉」「ツールの使い方」の2行だけで、残る4行は空欄である。一般的な言葉やツールであれば調べれば出てくるが、プロジェクト独自の言葉は調べても出てこない。データの仕組みや答えの場所も同様で、ここはドキュメントか有識者に当たるしかない。そして「前提(文脈)」と「役割(期待値)」に至っては、有効な手段が相手に質問の1列しか残らない。

 冒頭の問い「AIがあるのに、わざわざ文章構成を考える必要はあるのか」に対する答えは、この表の空欄そのものである。なぜ今その作業が必要なのか、自分に何が期待されているのか。それは検索にも生成AIにも載っていない情報であり、その場にいる相手の頭の中にしかない。AIが埋められるのは情報格差の一部でしかなく、残りは依然として人に聞くしかない。

「分かりません」ではなく「○○という理解でよろしいでしょうか」

 もっとも、聞けばいいというものでもない。山口氏は質問時の注意点として、「調べず(考えず)に質問しない」「仮説を立ててから質問する」の2点を挙げた。

 具体的には、「分かりません、教えてください!」と丸投げするのではなく、自分で考えたうえで「○○という理解でよろしいでしょうか」「○○という解釈で合っていますか」と確認の形を取る。こうすれば自分の理解も深まるし、認識にずれがあった場合には、そのぶん詳細な説明をもらうことができる。

 これは前年の講演で扱った、クローズドクエスチョンの応用でもある。答えに制約のないオープンクエスチョンは、聞く側は楽だが答える側の負担が大きい。対して答えが明確に決まるクローズドクエスチョンは、答える側の負担が小さい。認識のずれを埋めたいときは、後者のほうが速い。

先回りして「つまり○○だよね」と言わない

 立場が逆になり、後輩の話が要領を得ないときはどうするか。基本は同じで、一緒に課題を整理していく。

 有効なのは、話に見出しを付けてもらうことだ。「○○について××です」という形で、これから話すことにタイトルを付けてもらう。「仕様について、質問です」「実装について、相談です」といった具合である。これを考えてもらうだけでも、話はかなり整理される。合わせて、話のゴールも設定してもらう。承認してほしいのか、アドバイスがほしいのか、工数を伸ばしてほしいのか。大抵の場合、話を持ちかけるからには理由があるはずだからだ。

 それでも整理がつかないときの問いかけとして、山口氏は「何の話をしたいのかな?」「何かしてあげられることある?」といった例を示した。ここで1つ、明確な禁じ手がある。先回りして「つまり○○だよね」と要約してしまうことだ。

 「そうではなくて、本人に考えてもらいます。対話を通じて課題整理を学んでもらうのが重要です」と山口氏は言う。同じ内容を伝えるにも、「つまり○○ということかな?」と問いの形にすれば、考える主体は相手のままでいられる。

 ここまでは、質問する側と、質問を受ける側の技術の話である。だが山口氏自身は、新人の頃、まったく質問できない人間だったという。

次のページ
3週間、聞けなかった

この記事は参考になりましたか?

「CEDEC2026」レポート連載記事一覧
この記事の著者

斉木 崇(編集部)(サイキ タカシ)

株式会社翔泳社 ProductZine編集長。1978年生まれ。早稲田大学大学院理工学研究科(建築学専門分野)を卒業後、IT入門書系の出版社を経て、2005年に翔泳社へ入社。ソフトウェア開発専門のオンラインメディア「CodeZine(コードジン)」の企画・運営を2005年6月の正式オープン以来担当し、2011年4月から2020年5月までCodeZine編集長を務めた。教育関係メディアの「EdTechZine(エドテックジン)」...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

CodeZine(コードジン)
https://codezine.jp/article/detail/29297 2026/08/20 09:00

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー