はじめに
ここ毎日、テスト設計を起点にエンジニアリングのいくつかのトピックを巡りながら記事を書き続けてきました。本記事はその連投の最終日にあたります。
シリーズを通じて私が伝えたかったことは、結論から書くと一つです。エンジニアにとって問いを持つことは、AI時代だから重要になったのではなく、これまでもこれからも本質だった、ということです。
シリーズの主軸として「AI時代に設計判断は人間に残る」という主張を繰り返してきました。本記事ではその主張を一段普遍化して、設計判断の根底にある「問いを持つこと」そのものを扱います。
シリーズ全体を振り返りながら、これまで書いてきた各記事がどんな問いから生まれたのか、その問いを立てたことで何が変わったのかを整理します。
第1章: AI時代の議論を一段普遍化してみる
シリーズの主軸である「AI時代に設計判断は人間に残る」という主張を、改めて振り返ります。
この主張を最初に立てたとき、私はAI時代の文脈で「人間に残るもの」を探していました。AIエージェントがコードを書く、テストを書く、ドキュメントを整える。そういう状況でエンジニアの仕事として何が残るのか。
その答えとして「設計判断」を据え、シリーズを書き進めてきました。
書き進めるうちに気づいたのは、設計判断はAI時代に新しく重要になったわけではない、ということです。設計判断はAIが登場する前からエンジニアの仕事の中心にずっとありました。AI時代はそれを可視化しただけで、本質的な構造は何も変わっていません。
AIが優秀になればなるほど「答えの生成」のコストが下がり、相対的に「問いを立てる」「判断を下す」という人間の役割が際立つ。これは新しい現象ではなく、もともとそこにあった構造がAIによって明るみに出された、と捉えるほうが正確です。
シリーズの主軸を一段普遍化すると、こう言い換えられます。
設計判断は人間に残るという主張の根底には、問いを持つことが、エンジニアの仕事の中心にあるという、より普遍的な事実があります。AI時代だから問いを持つべきなのではなく、エンジニアという仕事はこれまでもこれからも問いを持つことから始まっています。
第2章: シリーズで立ててきた問いを振り返る
ここからは、シリーズ全体を通じて私が立ててきた問いを並べてみます。各記事は何かしらの問いから生まれていて、その問いを言語化することで答えを探す旅が始まりました。
1作目から3作目までは、AI時代のテスト設計をめぐる問いでした。「AIにテストを書かせる時代にエンジニアが磨くべき設計力は何か」「テストは仕様の実行可能なドキュメントとして読み直せるか」「仕様を先に整える人間の役割はどこにあるか」。
これらの問いはAI協働の現場感覚から自然に立ち上がったもので、シリーズ全体の主軸を形作りました。
4作目と5作目では、テスト設計の具体的な技法について問いを立てました。「そのテストは、どう設計したのか」「フロントエンドのテストはバックエンドと何が違うのか」。実装の現場で蓄積された経験を、QA技法という観点で整理し直す問いです。
6作目から10作目までは、テスト設計の各論に踏み込みました。「テスト命名はリファクタリングできるか」「フレーキーテストの正体は何か」「カバレッジ100%の先に何があるか」「テストピラミッドの形は本当に守るべきか」「V字モデルは現代に何を残したか」。
これらの問いはどれも、現場で何度も遭遇する場面から立ち上がったものです。問いを言語化することで、現場の判断に語彙が与えられました。
11作目から13作目では、AI協働と対話の文脈で問いを立てました。「ドメインを学ぶ入り口はどこか」「QAとの観点共有はどこで起きるか」「リファクタリングはAIに任せられるか」。
特に13作目はClaudeへのインタビューという形式で、AI自身に問いを投げる試みでした。問いを投げることで、対話の往復から思考が整理される構造を確認しました。
14作目から16作目では、品質投資と現場実践の文脈で問いを立てました。「CI/CDは固定的な制約か」「防御的プログラミングはどう設計するか」「SLOとカバレッジ加速度には共通の構造があるのか」。
これらの問いはどれも現場で「なんとなくそう思っていた」ものを、言語化できる形に置き直したものです。
並べてみると、シリーズで書いてきた記事のすべてが問いから始まっていたことがわかります。問いがあるから答えを探す動きが生まれ、書くことで答えを言語化できる、という連鎖です。
第3章: 問いがあるから、答えを探す
問いと答えの関係について、シリーズを書く中で改めて気づいたことを書いておきます。
答えは、問いがなければ生まれません。これは当たり前のようでいて、現場では見落とされがちな構造です。
「テスト命名のベストプラクティス」を覚えるより先に「なぜこのテスト名は理解しにくいのか」という問いを持つほうが深く学べる。「カバレッジ100%を目指すべきか」という問いを持たなければ、カバレッジの数値を追いかける作業が目的化していきます。
シリーズを書く中で、私自身が答えを持っていなかった問いがいくつもありました。「フレーキーテストはなぜ起きるのか」「ドメインモデルとは何か」「SLOコストの構造はどう理解すればよいか」。
これらは答えを知らない状態で問いを立て、書きながら調べ、調べながら考え、考えながら書く、という往復の中で答えに近づいていきました。
この往復が、エンジニアにとっての学びの本体だと感じています。答えを最初から持っている必要はなく、問いを立ててその問いに付き合い続けることで、答えに近づいていく。
逆に言えば、問いを持たないまま答えを覚えても、その答えは深く根を張りません。「ベストプラクティスはこうだ」と覚えた知識は、状況が変わると応用できないことが多い。
なぜそれがベストプラクティスなのか、という問いを一緒に持っていれば、状況が変わっても判断できます。
問いがあるから答えを探す。問いに付き合い続けるから答えが磨かれる。これはシリーズ全体を通じて、私自身が体験した構造です。
第4章: AIは答えを返すが、問いは返さない
AI時代の文脈で、問いを持つことの意味を改めて考えてみます。
AIは優秀な答え生成器です。コードを書かせれば書いてくれる、テストを書かせれば書いてくれる、ドキュメントを整えさせれば整えてくれる。問いを投げれば、それに対する答えを返してくれます。
ところがAIは自分から問いを立てることが少ない。少なくとも、現場で人間が抱えている問題を察知して的確な問いをこちらに投げてくる、という使い方は私はあまり経験していません。問いを立てるのはほぼ常に人間の側です。
13作目で書いたClaudeへのインタビューでも、構造は同じでした。私が問いを投げ、Claudeが答えを返す。Claudeは応答の中で自己分析や提案をしてくれましたが、対話を駆動していたのは私の問いでした。AIとの協働で得られる答えの質は、結局のところ、こちらが投げる問いの質に依存します。
問いの質が答えの質を決める、という構造はAI協働でも変わりません。むしろAIによって答えの生成コストが下がる分、問いの質が成果物の質を直接左右するようになっています。
良い問いを投げれば良い答えが返り、曖昧な問いを投げれば曖昧な答えが返る。問いを精密にする能力が、AI時代の成果を分けます。
これはAI時代に新しく生まれた話ではありません。問いの質が答えの質を決める、という関係はエンジニアという仕事の中にずっとありました。AI時代はそれを露わにしただけです。
第5章: 書き手自身の変化
シリーズを書く中で、私自身がどう変わったかを振り返ります。
書き始める前は、テスト設計や設計判断について「なんとなくそう思っていた」ことが多くありました。フレーキーテストは厄介だ、カバレッジ100%は目指しすぎると害がある、テスト命名は重要だ。これらは現場で蓄積された感覚としてありましたが、言語化されていない状態でした。
シリーズを書き始めて、各テーマについて問いを立て答えを探す作業を続けるうちに、自分の中の感覚が言葉になっていきました。書くことは、問いに付き合い続ける一つの方法だと感じます。
特に大きな変化は、現場の判断に語彙が与えられたことです。CI/CDの実行時間を削減する作業、防御的プログラミングと契約による設計の使い分け、SLOとカバレッジ加速度の構造的類似性。これらはシリーズで書く前は感覚的にやっていたことが、書いたあとは人に説明できる形に変わりました。
チームメンバーとの議論やAIへの指示文を書く場面で、この語彙の差は大きく効きます。同じ判断をするにしても、言語化されているかどうかで伝わり方が変わります。
もう一つの変化は、問いの立て方そのものへの意識です。書き始める前は「答えを探す」ことに意識が向いていましたが、書きながら問いをどう立てるかに意識が向くようになりました。
良い問いを立てられれば、答えへの道筋は自然に見えてくる。問いを立てる能力は答えを探す能力とは別の能力で、独立して鍛えられるものだと感じています。
シリーズをここまで書いてきたことで、自分がエンジニアとして以前より一段、問いを持てるようになった感覚があります。これは知識量の増加とは違う種類の変化で、エンジニアとしての姿勢が変わった、と言うほうが近いかもしれません。
第6章: 問いは、答えより寿命が長い
ここまで書いてきたことを、もう一段抽象化して整理しておきます。
技術の世界では、答えは絶えず変わります。10年前のベストプラクティスは今のベストプラクティスではないし、今のベストプラクティスも10年後には古くなっているはずです。フレームワーク、ツール、設計手法、これらすべてが時代とともに更新されていきます。
ところが、問いはそう簡単には古くなりません。「良いテストとは何か」「設計判断は何を根拠にすべきか」「チームで品質をどう保つか」。これらの問いは、10年前も今も、おそらく10年後も、エンジニアにとって有効な問いとして残り続けます。
問いは、答えより寿命が長い。これは私がシリーズを書きながら確認した構造の一つです。
答えを覚えるより問いを覚えるほうが、長い時間軸で見て役に立ちます。AI時代に答えの生成コストが下がるからこそ、問いの価値が相対的に際立ちます。AIに渡せる仕事は答えの生成側に集中していて、問いを立てる仕事は人間の側に残り続けるからです。
シリーズで書いてきた記事の答えは、いつか古くなるかもしれません。CI/CDツールが変わり、テストフレームワークが変わり、AIモデルが進化していけば、本記事で書いた具体的な答えは更新が必要になります。
それでも、シリーズで立ててきた問いそのものは長く有効に残るはずです。問いは答えより寿命が長い、というのが本記事を通じて伝えたかった一番のメッセージです。
第7章: シリーズの締めくくり
GW期間の連投を、これで締めくくります。
連休前の私は、毎日記事を書くことが続けられるか、自信を持てていませんでした。書き始めてみると、各テーマに対して問いを立て、その問いに付き合い続けることが思っていた以上に楽しい作業でした。書きながら自分の中で輪郭が立ち上がっていく感覚は、シリーズ全体を通じて何度も味わいました。
本シリーズで書いてきたことは、設計判断、テスト設計、ドメイン学習、AI協働、CI/CD、防御的プログラミング、品質投資、と多岐にわたります。それでも全体を貫く一つの軸として、問いを持つことが常にありました。
AI時代だから問いを持つのではなく、エンジニアという仕事の中に問いを持つことがずっとあった。それをシリーズの記事を通じて、繰り返し確認してきたつもりです。
ここまで読んでくださった方に、心から感謝します。シリーズを通じて伝えたかった一番のメッセージは、「問いを持つエンジニア」というタイトルそのものに込めたつもりです。
答えを覚える前に問いを立てる。問いに付き合い続けることで答えに近づく。問いは答えより寿命が長い。これらの構造は、私自身がシリーズを書きながら確認したことであり、これから先のエンジニア人生でも、ずっと意識し続けたいと思っています。
Discussion