実装が詰まる原因は、コードの前にあることが多い
実装が詰まったとき、ついコードの書き方や技術選定に原因を求めてしまいがちです。しかし、実際の体験を振り返ると、本当の原因はもっと手前にあることが少なくありません。
それは「何を解こうとしているのか」「何を解かなくてよいのか」が、十分に整理されていないまま実装に入ってしまっている状態です。
問いが曖昧なまま実装を始めると、途中で判断が揺れます。最初は正しいと思っていた設計が、少し要件を確認しただけで崩れることもあります。その結果、コードを書いては戻し、また書き直す、というサイクルに入ってしまいます。
これは実装スキルの問題というより、問いの立て方の問題に近いと感じています。
AIのサポートが当たり前になったことで可視化された問いの質
AIを日常的に使うようになってから、この傾向は以前よりもはっきり見えるようになりました。
技術的な相談をAIに投げると、前提が曖昧な質問には、それなりに曖昧ですが一見もっともらしい答えが返ってきます。
一方で、目的や制約、背景を整理したうえで質問すると、返ってくる回答はかなり具体的になります。そのまま実務に転用できるレベルの示唆が返ってくることも珍しくありません。
ここで重要なのは、これはAIの性能差ではないという点です。
問いの質の差が、そのままアウトプットの差として返ってきているだけです。
そして、この現象はAI特有のものではありません。人に相談するときも、設計レビューをするときも、本質的には同じことが起きています。
問いを整理することは、AI向けテクニックではない
問いを整理することは「AIをうまく使うためのテクニック」ではありません。
問いを言語化できている時点で、問題空間はすでにかなり切り分けられています。
実装に入る前に考えるべきことが明確になっていれば、実装中の判断は自然と一貫性を持ちます。逆に、問いが曖昧なまま実装を始めると、実装中に何度も立ち止まることになります。
これは個人の能力差というより、思考のプロセスの差です。
実装前に整理しておきたい三つの観点
当たり前の観点でもありますが、実装に入る前に次の三点を言語化すると思考の整理ができるでしょう。
1. 目的
この変更で何を達成したいのか。
性能改善なのか、保守性の向上なのか、将来の仕様変更への備えなのか。ここが曖昧なままだと、途中で判断基準がぶれます。
2. 制約
既存仕様、影響範囲、チーム体制、スケジュールなど、理想論ではなく現実として無視できない条件です。
「できたらこうしたい」と「今回はできない」を分けて考えます。
3. 不確実性
将来変わりそうな部分と、当面は変わらなさそうな部分の切り分けです。
ここを意識するだけで、どこまで抽象化すべきか、どこを固定してよいかが見えやすくなります。
この三点が整理されているだけで、実装中に迷う場面は減っていくでしょう。
チームマネジメントにも効果
この話は、個人の実装スタイルの話に見えるかもしれません。しかし実際には、マネジメントの文脈とも強く結びついています。
問いが整理されていない状態で実装が始まると、レビューは重くなり、手戻りが増え、結果としてチーム全体のスループットが下がります。逆に、実装前に問いが整理されていれば、レビューは軽くなり、判断の背景も共有しやすくなります。
「実装に入る前に立ち止まる」ことは、スピードを落とす行為ではありません。
チームとしての無駄を減らすための、再現可能なプロセスです。
これは属人的なセンスではなく、チームにインストールできる習慣だと考えています。
実装が速くなった時代だからこそ「問い」が重要
AI時代になり、コードを書くスピードそのものは確実に上がりました。調べる時間も、試す時間も短縮されています。その一方で、考えるフェーズを雑にすると、その雑さがそのまま成果物に反映されてしまいます。
実装が速くなったからこそ、問いを整理する力の差が、以前よりも結果に直結するようになりました。
問いを整理するという行為は、特別な才能ではありません。実装前に数分立ち止まり、自分が何を解こうとしているのかを書き出すだけでも十分に効果があります。
AI時代だからこそ、この地味な作業が、技術とマネジメントの両方に効く基礎体力になっていくと感じています。
Discussion