みなさん、こんにちは。
Claude CodeやCodex CLIの進化、本当に凄まじいですよね。開発現場の風景も激変していて、最近ではIDEよりもターミナルを開いている時間の方が長い、なんて方も多いのではないでしょうか。
凄腕のエンジニアがIDEでAIの支援を受けながら一生懸命手を動かすよりも、ターミナル型AIに「丸投げ」した方が、はるかに速くて高品質なコードが上がってくる……。そんな場面も、もはや珍しくありません。IDEからターミナルへの移行は道半ばかもしれませんが、こと「人間の手作業から生成AIへの移行」に関しては、もうほぼ完了したと言っても過言ではないでしょう。
こうした状況の中で、よくこんなことが言われています。
- 実装力だけがウリのエンジニアは、もう厳しい。
- 残るのはコードレビューの能力だけ。
- いや、AIの精度が人間を超えれば、レビューすら不要になるかも。
- だからこそ、これからは「設計力」や「ドメイン知識」が必要だ！
- 「何を解くべきか」という課題設定ができる人だけが生き残る。
話の筋としては、すごく納得感がありますよね。私自身も、生成AIをパートナーとして「設計力」を高めていく方向性は間違いないと感じています。
実際、プランニングからAIに任せる「仕様駆動開発」は当たり前になりつつありますし、以前私は「意図駆動開発」を推奨する記事も書きました。
「ドメイン知識を身につけよう」の落とし穴
ここで、どうしても引っかかる問いがあります。
- そもそも、ドメイン知識ってどうやって身につけるの？
- 知識さえあれば、正しく課題設定ができるようになるの？
実は、この問いに対して具体的な方法論を語っている記事は、ほとんど見かけません。
それもそのはず。この種の議論を発信しているのは、多くの場合「AIによる自動生成が当たり前になった現状」に強い危機感を覚えたエンジニア自身だからです。
彼らは「正しく課題を設定する方法」を体系的に学んだ経験があるわけではなく、ドメイン知識を武器に課題を解決してきたキャリアも、実はそれほど長くなかったりします。結果として、「これからは課題設定が重要だ！」とは言えても、「具体的にどうやるか」までは語れないのが実情なのです。
私の結論 – 先に「ドメイン知識」を狙いに行かない
ここからは私自身の考えをお話しします。結論から言うと、私は「最初にドメイン知識を身につけること」をおすすめしません。
なぜなら、現場を見渡してみると、ドメイン知識（業務知識）に詳しい人はすでにたくさんいるからです。
しかし、その知識豊富な人たちの多くは、
- 与えられた要件
- 既存の業務ルール
- 「昔からこう決まっているから」という説明
これらを、そのまま疑問を持たずに受け入れてしまいます。つまり、「問題を問題として認識できていない」のです。
だからこそ、先に身につけるべきは知識ではなく「問題認識能力」です。
問題をしっかり認識し、課題を設定するプロセスの中で、必要に応じて知識を深めていく。この順番こそが、課題設定の精度を上げる近道です。
解決策 – エンジニアこそ「リーンキャンバス」を書こう
では、どうやって「問題認識能力」を鍛えればいいのでしょうか？
私のおすすめは、「リーンキャンバス」を書くことです。 以前、新規事業の文脈で紹介しましたが、今はむしろエンジニアこそが活用すべきツールだと思っています。
なぜなら、リーンキャンバスは単なる企画ツールではなく、
- 思いついた課題をいったん言語化してみる
- それは「誰の」課題なのかを問い直す
- 「課題」と「対象」を往復して、本質的な問題に近づく
という、問題認識そのものを訓練するツールだからです。
最初から正解を書く必要はありません。「なんとなくこれが課題かも？」という直感からスタートできるのが、このツールの良いところです。
具体例 – よくある「システムが使いにくい」の正体
ITの現場でよくあるケースを考えてみましょう。
❌ 表層的な課題設定
「社内システムが使いにくいから、UIを改善したい」という課題（依頼）をもらったエンジニアは、すぐこう考えがちです。
- 画面遷移を分かりやすくしよう
- ボタンの配置を整理しよう
- 入力項目を減らしてスッキリさせよう
しかし、リーンキャンバスの視点で「それは誰の課題か？」を掘り下げていくと、意外な事実が見えてきます。
- 現場の担当者：「慣れているから、今のままでも問題ない」
- 管理職：「入力が遅い！数字が揃うのが遅い！」とイライラしている。
つまり、課題から遡れる問題の本質は「UIの見た目」ではなく、管理職側の「体験悪化」にあったのです。
✅ 本質的な課題設定
さらに深掘りすると、真の課題が浮き彫りになります。
- 入力ルールが曖昧で、人によってバラバラ
- データの定義が部署ごとに違うため、集計に時間がかかる
- 運用ルールが複雑すぎて、入力自体が後回しにされている
これらを踏まえた本当の課題は、「業務プロセスとデータの定義を整理し、入力の意味を明確にすること」でした。
ここを解決しない限り、いくらボタンの配置を綺麗にしても、管理職のイライラ（体験悪化）は決して解消されません。
課題設定が変われば、設計は自然に良くなる
問題の本質に気づいた瞬間、課題設定は「UI改善」から「業務とデータの再定義」へと大きく変わります。課題の精度が上がれば、解決方法（設計）の精度も自然に上がります。
- どの入力項目が本当に必要なのか？
- どのタイミングでデータを確定させるべきか？
こうした設計が、ここで初めて意味を持ち始めます。「正しい課題」「明確な対象」「目的の共有」が揃えば、あとは生成AIを使った設計・実装も非常にうまく回ります。
逆に言えば、問題認識がズレたままでは、どれだけ高度な生成AIを使っても有益なシステムは生まれません。
最後に – 今、最も価値のあるエンジニアとは
実業界で本当に求められているのは、
- 新しい言語を知っているエンジニアでも
- 実装スピードが異常に速いエンジニアでもなく
「本当に有益なシステムを開発できるエンジニア」です。
その出発点は、実装力でも設計力でもなく、「問題を問題として正しく認識する力」にあります。
ぜひ、リーンキャンバスを書くことを習慣化してください。 それは新規事業のためだけの道具ではなく、生成AI時代を生きるエンジニアのための、最強の思考トレーニングツールなのです。
本日も最後までお読みいただき、ありがとうございました。
それでは、よいエンジニアライフを！
