【非エンジニア編第12回】技術的な言い訳かどうかを見極めるための質問の仕方

※Claude Codeを使用して記事を作成しています。

前回の記事では、見積もりが妥当かどうか、感覚をつかむ方法を紹介しました。

第3部「コミュニケーション編」の最後のテーマは、

「難しい」と言われたときの確認の仕方

です。

「それは技術的に難しいです」と言われたが、本当なのかわからない
理由を聞いても、専門用語で返されて納得できない
疑っているように聞こえそうで、深掘りしづらい

非エンジニアなら、一度は経験する場面だと思います。

今回は、エンジニアを疑うためではなく、「難しい」の中身を理解するための質問の仕方を、Claude Codeを使って整理します。

最初に:「言い訳かどうか」を見抜く必要はない

タイトルに「言い訳」という言葉を使いましたが、最初に考え方を整理しておきます。

多くの場合、エンジニアの「難しい」は、嘘や言い逃れではありません。

既存の仕組みを変えると、他の機能に影響が出る
作業量が多く、期間内に収まらない
品質を守るために、今のやり方では危険がある

といった、実際の事情を短く表現しているだけのことがほとんどです。

ただし、

「難しい」の一言だけでは、判断材料が足りない

のも事実です。

そこで目指すのは、

「難しい」を、具体的な理由と選択肢に分解すること

です。

結果として、本当に難しいのかどうかも、自然と見えてきます。

「難しい」にはいくつかの種類がある

「難しい」という言葉は、実はさまざまな意味で使われます。

技術的に実現が困難
そもそも、今の技術では実現しにくい
工数的に大きい
できるが、時間と人手がかかる
影響範囲が広い
できるが、他の機能への影響確認が必要になる
リスクが高い
できるが、不具合が起きる可能性が上がる
優先度の問題
できるが、今は他の作業を優先したい

これらは、判断も対応も異なります。

「難しい」と言われたら、まずこの5つのうちどれなのかを把握することが出発点になります。

実例:「難しい」と言われた場面

ここでは、以下のやり取りを例にします。

【依頼】
商品一覧画面に、並び替え機能を追加したい。

【エンジニアの返答】
それは今の構成だと難しいですね。

この返答だけでは、何が難しいのか、どう判断すればよいのかがわかりません。

ステップ1:「難しい」の種類を整理する

まず、Claude Codeにどんな質問をすればよいか相談します。

【質問例】
エンジニアから「今の構成だと難しい」と言われました。
「難しい」の背景として、一般的にどんなパターンが考えられますか？
断定ではなく、確認すべき観点を整理するために聞いています。

Claude Codeが、以下のように整理してくれます。

【回答例】
「難しい」の背景には、一般的に以下のようなパターンがあります。

- 技術的な制約がある（使っている仕組みが、その機能に対応していない など）
- 既存のデータ構造や設計を変更する必要がある
- 変更による他機能への影響が大きく、確認に時間がかかる
- 実装自体は可能だが、工数が大きい
- 優先度や他の作業との兼ね合いで、現時点では対応しにくい

どれに当てはまるかによって、次に確認すべきことが変わります。

この整理があるだけで、「難しい」という言葉への向き合い方が変わります。

ステップ2:理由を聞くための質問を作る

次に、エンジニアに投げる質問を整えてもらいます。

【質問例】
エンジニアに「難しい」の理由を確認したいです。
疑っている印象を与えず、具体的な理由を聞き出せる質問を考えてください。

Claude Codeが、以下のように提案してくれます。

【質問の提案】

- 「どの部分が難しいのか、もう少し詳しく教えていただけますか？」

- 「技術的に実現できないのか、工数がかかるという意味なのか、
   どちらに近いでしょうか?」

- 「難しい理由を理解しておきたいので、ざっくりで構いませんので背景を教えてください」

ポイントは、

「なぜ難しいのか」ではなく「どの部分が難しいのか」

と聞くことです。

「なぜ」は問い詰める印象を与えやすい一方、「どの部分」は、状況を一緒に把握したいという姿勢が伝わります。

ステップ3:「できる方法」を一緒に探す質問をする

「難しい」で会話を終わらせず、代替案を探る質問も用意します。

【質問例】
「難しい」と言われた機能について、代替案や、条件付きで実現する方法を
エンジニアと一緒に探るための質問を考えてください。

Claude Codeが、以下のように提案してくれます。

【質問の提案】

- 「全部は難しくても、一部だけ先に実現する方法はありますか？」

- 「期間を延ばせば実現できる、ということでしょうか？
   その場合、どれくらいの期間が必要になりますか？」

- 「今回は見送るとして、将来実現するために準備しておけることはありますか？」

- 「難しい部分を避けた、似た機能の実現方法はありますか？」

こうした質問を通じて、

「できる・できない」の二択

から、

「どこまでなら、どうすればできるか」

という会話に変わっていきます。

ステップ4:返ってきた答えを理解する

エンジニアから説明を受けたら、その内容をClaude Codeで読み解きます。

【質問例】
エンジニアから以下の説明を受けました。
非エンジニア向けに、噛み砕いて説明してください。
また、説明の中で、追加で確認しておいた方がよい点があれば教えてください。

「並び替えをするためには、今のデータの持ち方を変える必要があって、
 その影響で他の画面の修正も必要になります」

Claude Codeが、以下のように答えてくれます。

【回答例】
簡単に言うと、
「並び替え機能を追加するために、データの保存の仕方を変える必要があり、
 そのデータを使っている他の画面にも修正が必要になる」
ということです。

追加で確認しておくとよい点:
- 他に修正が必要になる画面は、いくつくらいあるか
- データの保存方法を変えることで、既存のデータの移行作業は必要か
- 修正が必要な範囲を絞る方法はないか

説明の意味がわかると、
「難しい」の中身が見えてきます。

この時点で、

「確かに簡単ではなさそうだ」

と納得できる場合も多くあります。

納得できないときは、第三者の視点を借りる

説明を聞いても納得しきれない場合があります。

そのときも、エンジニアを疑うのではなく、次のような進め方が考えられます。

別のエンジニアに、技術的な観点で意見を聞く
過去に似た機能を実装した事例があるか確認する
対応範囲を小さくして、再度見積もりを依頼する

Claude Codeは、この相談の準備にも使えます。

【質問例】
エンジニアの説明を聞きましたが、まだ納得しきれていない部分があります。
別のエンジニアに意見を聞く際、どのように状況を伝えれば、
中立的な意見をもらいやすいですか？

特定の誰かが間違っていると決めつけず、

「状況を整理して、別の視点を加える」

という姿勢が大切です。

やってはいけない質問の仕方

ここで、避けたい聞き方を整理します。

【避けたい質問の例】

- 「本当は簡単なんじゃないですか？」
- 「他の人ならできると言っていましたよ」
- 「ネットで調べたら簡単そうだったのですが」
- 「やりたくないだけではないですか？」

このような聞き方は、エンジニアの信頼を損ないやすく、その後のやり取りにも影響します。

Claude Codeに、自分の質問文をチェックしてもらうこともできます。

【質問例】
以下の質問文を、相手に疑っている印象を与えないよう、
中立的な表現に直してください。

「本当に難しいんですか?簡単にできそうに思うのですが」

Claude Codeが、以下のように言い換えてくれます。

【回答例】
「実現するうえで、どの部分に難しさがあるのか教えていただけますか？
 私の方でも状況を理解しておきたいと考えています」

同じ内容でも、言い方ひとつで相手の受け取り方は大きく変わります。

Claude Codeの情報を扱ううえでの注意点

「一般的には簡単」を根拠にしない

Claude Codeが「一般的に実現しやすい機能」と答えたとしても、それは自社のシステムでも簡単であることを意味しません。

既存システムの構造や、過去の経緯までは、Claude Codeにはわかりません。

最終判断は人との対話で行う

「難しい」が妥当かどうかは、システムの事情を知る人との対話を通じて判断するものです。

Claude Codeは、その対話の質を上げるための準備として活用してください。

「難しい」を確認するための質問テンプレート

【「難しい」確認テンプレート】

1. エンジニアから「(言われた内容)」と言われました。
   「難しい」の背景として、一般的にどんなパターンが考えられますか？

2. エンジニアに「難しい」の理由を確認したいです。
   疑っている印象を与えず、具体的な理由を聞き出せる質問を考えてください。

3. 代替案や、条件付きで実現する方法を一緒に探るための質問を考えてください。

4. エンジニアから以下の説明を受けました。
   非エンジニア向けに噛み砕き、追加で確認すべき点も教えてください。
   (説明を書く)

5. 以下の質問文を、相手に疑っている印象を与えない中立的な表現に直してください。
   (質問文を書く)