この記事でわかること
-
キャリアの柱を複数持つべき理由
-
技術選定を左右する審美眼の養い方
-
AI時代以降も活躍するソフトウェアエンジニアであるための考え方
ソフトウェアエンジニアとして働き続けるなかで、どんな技術を学び、なにを拠りどころにしてキャリアを築いていけばいいのか。そう考えることは少なくありません。
テスト駆動開発の第一人者として知られる和田卓人さんも、最初から明確なロールモデルや完成されたキャリア像を持っていたわけではありませんでした。設計も実装も自分で担いたいという思いを抱えながら、失敗と試行錯誤を重ね、そのなかで専門性を育ててきたのです。
本記事では、和田さんの歩みを通して、ソフトウェアエンジニアの思考や技術がキャリアをどう支え、どう広げていくのかを紐解きます。また、AI時代において、競争力あるソフトウェアエンジニアであるための手がかりを探ります。
▶Claude Code、Cursor、GitHub Copilot…どう使い分ける？和田卓人
タワーズ・クエスト株式会社取締役社長。学生時代からプログラマーとして働き始め、後にXP、テスト駆動開発（TDD）と出会い大きな衝撃を受ける。以来、日本におけるTDDの第一人者として「TDD Boot Camp」の全国展開や講演・執筆などを通じて普及活動に尽力する。現役のプログラマとして自らコードを書き続けるかたわら、複数企業の技術顧問として開発現場の課題解決やエンジニアリング文化の育成を支援している。
【X（旧Twitter）】：@t_wada
目次
ロールモデルは不在。でも目指したのは「設計も実装も1人で全部できる」存在
ーー大学在学中にはすでにプログラミングのアルバイトをされ、卒業後はタワーズ・クエストに正式に入社されています。そもそもソフトウェアエンジニアという仕事を選んだ原点はどこにあったのでしょうか？
和田さん：あまりかっこいい理由ではなくて、なりゆきに近いところがあったんです。私がプログラミングを始めたのは結構遅く、大学に入ってからです。ただ、いざプログラミングに触れてみると、それが好きだなと思えたんです。
その後、学外でプログラミングのアルバイトをしたり、父親が経営していた小規模なソフトウェア企業（タワーズ・クエスト株式会社）を手伝い、後に入社するのですが、そうこうしているうちに、いつしかプログラミングが仕事になっていきました。ですから、自分の中では大学の中頃からプログラマーとしてのキャリアが始まって、それがいまにいたるまでずっと連続している感覚です。
ーー当時、ソフトウェアエンジニアやプログラマーとしてどんなキャリアを思い描いていたのですか？
和田さん：それが全くなかったんです。というのも、当時（1990年代終盤）はWebエンジニアという領域自体が新しく、10歳上の先達はいても、「20歳上のロールモデル」といった存在がいませんでした。私と父は年齢が約30違うので、「30年後ってこんな感じか」と想像はできるのですが、そのもっと手前の20年後に自分がどう仕事しているか想像がつかない、まるでキャリアの見通しが立たない「暗黒空間」が広がっていました。
ただ、技術的な面では、「設計もできるし、コードも書ける。1人でシステムの全てを作ることができる人間になりたい」というイメージはあったと思います。
私の父はデータベースのテーブルやビューの設計を行う、いわゆるデータモデルの設計者でしたので、私もキャリアの最初はコードを書くよりもデータモデルの設計で対価を得るというところから入りました。しかし、私はプログラミングも学んで傾倒していたので、設計と実装、いずれも自分の手で行いたいと考えていました。
自分で設計したものを自分で実装すれば、良い面も悪い面も含めて自分で痛い目を見ながら設計の答え合わせができますし、そうしてソフトウェアエンジニアとして地力が養われていったと思います。
設計とプログラミングは本来一体のものなので、それを最初から一体として捉えられたのは幸運だったと思います。
ーー「痛い目」という言葉が出ましたが、キャリアの初期から中期にかけて、印象に残っている失敗はありますか？
和田さん：若い頃はやはり、技術選定の失敗が多かったです。例えば、25年ほど前にXMLが猛烈に流行した時期がありました。当時はXMLでなんでも定義すればコードも画面も生成できるといった、いわば「XMLバブル」のような時代で、私もその熱に当てられてしまいました。
あるシステムでXSLTを使って業務画面を動的に生成する仕組みを採用したのですが、画面数が多すぎて果てしなくXMLとXSLTを書き続けなければなりませんでした。自分で選んだ技術に自分が振り回されてしまった。もう、一生分のXSLTを書いたんじゃないかとすら思えます（笑）。
当時の私にはXMLが有望な技術、いまで言えば「ゲームチェンジャー」に見えたのですが、界隈から期待を集める技術が必ずしも正解ではないこと、そして「その状況にちょうど良い技術」を見極めるには、一度やりすぎて痛い目を見ないと気づけないことがあると学びました。
「これを学んでおいたらよい」といえるものは、技術の観点ではとくにありません。なぜなら、「これを学べば一生安泰」という技術はないからです。ですから、当時の自分に対しては、「学ぶスキル」や「学び続ける姿勢」を持ち続けることが重要、と伝えるでしょう。
また、若い方には「インプットだけでなくアウトプットの機会を作ろう」と伝えたいと思います。若いころの私はインプット10、アウトプット0の人間でしたが、有志の勉強会などで小さな発表を始めると、自分の知識に需要があることに気づきました。アウトプットを前提にすることで、知識が整理・再構築され、フィードバックが得られます。
「いきなりパブリックにして、斧を投げられるのが怖い」という場合は、社内の小さな勉強会のような「中庭（内輪の空間）」を作って、安全にアウトプットを始めることをお勧めします。
▶「3年で転職してはいけない」理由とは？
TDDが解いてくれた「完璧主義の呪い」
ーー和田さんといえば「テスト駆動開発（TDD）」の第一人者として知られていますが、TDDがご自身の「完璧主義の呪い」を解いてくれたと語られていますね。当時の苦しみや、TDDがもたらしたブレイクスルーについて教えてください。
和田さん：TDDやアジャイルソフトウェア開発、エクストリーム・プログラミング（XP）に出会う前の私は、「正しい設計をしないと正しい実装はできない」という強迫観念に囚われていました。現実を捉えた完璧な設計ができなければシステムは破綻すると思い込み、「完璧な設計ができるまでは、実装してはいけない」と開発を始めるのを先延ばしにしてしまっていたのです。
しかし、実際にコードを書き始めると、考え漏れや、逆に「そこまで考える必要はなかった」という考えすぎに必ず気づきます。もっと早く試して安全に実験できればよかったのに、と痛い目を見ることが多かったです。
そこにTDDやリファクタリングが登場しました。これらは「最初に完璧な設計を得なくても着手できる」「始めてから質を上げながら開発を継続できる」ということを教えてくれました。「やり直しができる」と分かれば、開発の足どりが重くなるのを防げますし、フィードバックを回しながら改善し続けられる。これには本当に救われました。
ーー当時の開発現場の構造的な問題もあったのでしょうか？
和田さん：そうですね。当時は設計と実装が分断されていることが多く、「設計者がつくった設計を、実装者が粛々とコードに翻訳すべき」という、一種のヒエラルキーがありました。私は設計も実装もテストも両方やっていましたが、設計者としての自分が完璧を求める一方で、実装者としての自分はボロボロで動かないシステムに直面する。
手動テストで自分が設計したものが動かない現実を浴び続け、プライドがすり減っていくのを感じていました。だから、私は手動テストが大嫌いだったんです。
しかし、自動テストとリファクタリングがセットになることで、「もっとここを改善できる」と躊躇なくコードに手を入れられるようになりました。
自動テストで保護されている間にコードを綺麗にしていくと、「最初は汚かったけれど、今の設計は明らかに良くなったな」と自分を褒められるようになります。すり減ったプライドを回復し、理想と現実のギャップを後から埋めていける。これが、精神衛生上も非常に大きかったですね。
大嫌いなテストでしたが、大好きなプログラミングを使って自動テストを書くことで、嫌いを好きで上書きできたのも幸せなことでした。
ーー和田さんが魅了されたTDD、自動テストをどのように実践し、周囲を巻き込んでいったのですか？
和田さん：自動テストは「個人スキル」であり「個人プロセス」なので、チームの承認がなくとも、自分1人で始められるのが良いところです。最初は私が手元でテストコードを書いていたのですが、それをチームに広めるにはちょっとしたジャンプが必要でした。
私が意識したのは、「正しさ」ではなく「損得」の話にすることです。「プロならテストを書くべき」なんて熱く語っても人は動いてくれません。だから、「自動テストを書いた方が動作確認がめちゃくちゃ楽だよ」「こっちの方が得だよ」と伝えていきました。
幸い、私が当時所属していたのが大規模プロジェクトの中でも技術面をリードする尖ったチーム（フレームワークチーム）だったので、話が通りやすかったという幸運もありましたね。
キャリアの柱は複数持つ。技術の「螺旋」を読み解く審美眼を養うには
ーー和田さんにとってTDDのように、長くキャリアの軸になる技術を見極めるためには、どのような視点や「審美眼」が必要だとお考えですか？
和田さん：公平を期すならば、私が自動テストなどをキャリアの主軸にできたのは「運が良かった」という側面も大きいです。私が好きでのめり込んだ技術が、たまたま時代を超えて生き残り、クラウドやAIの時代になっても重要なポジションを占め続けたからです。
それでも、若手の方に強く伝えたいのは「キャリア初期から柱を1本に絞って、自分の可能性を減らさない方がいい」ということです。破壊的な技術の登場で、たった1本の柱が競争力を失うことはよくあります。10年くらいかけて、3つほどの得意分野（柱）を持つのが安全です。
色々な技術に手を出してみて、結果的にそれが流行ったかどうか「答え合わせ」をしていくといい、とアドバイスしたいと思います。
ーー技術が流行るか廃れるかの「答え合わせ」を通じて、審美眼が養われていくのですね。
和田さん：技術の歴史は「振り子」のような単なる繰り返しではなく、少しずつ角度を変えて発展する「螺旋（らせん）」のようなものです。ベテランの数少ないアドバンテージは、1周期前、2周期前に何が起こったかを知っていて、そこから「これからなにが起こりそうか」をある程度の打率で類推できることです。
技術者の競争力とは、端的に表現すると「設計判断力」です。過去の自分がどういう状況でなにを選び、その選択の結果、なにが得られたか、という「量稽古」の蓄積が、判断の打率を高めます。この思考回数と答え合わせの回数を増やすためには、AIの力を借りて開発効率をギュッと上げるのも有効でしょう。
また、若手の方に強くお勧めしているのが、巨大なシステムの一部だけをつくるのではなく、「企画から運用まで、小さいものを全部自分1人で作る経験」を持つことです。部分的な仕事ばかりしていると、全体の中で「今決めるべきこと」と「後回しにできること」のバランス感覚が育ちません。
チームの力を借りずに、AIの支援などを適度に取り入れながら、すべてを自分で完結させる体験は、システム開発の全体観を養ううえで不可欠です。
ーーある技術が「ゲームチェンジャー」かどうかを見極める基準はありますか？
和田さん：本当のゲームチェンジャーは破壊的なので、考えるまでもなく分かります。インターネットやクラウド、そして大規模言語モデル（LLM）などがその最たる例です。こうした流れには抗わず、しっかりと波に乗って学びを深めるべきです。
そこまでいかない技術であれば、「考えること（認知負荷）をどれだけ減らしてくれるか」が基準になります。
たとえばRuby on RailsやReactは、人が1から10まで考えなくてもいいようにお膳立てしてくれ、試行錯誤を高速に行えるように支援してくれます。いわば、人間の脳みそを、より本質的な価値創造に集中させてくれる仕組みでした。複雑さを減らし、心配事を減らしてくれる技術は、やはり強いインパクトを持っています。
ーーなにか新しい技術を学ぶ際、「コスパ」や「タイパ」を気にする傾向もあります。和田さんも意識されていますか？
和田さん：私自身は全く意識していません。なぜかというと、シンプルに「好きでやっているから」ですね。技術に没頭すること自体が目的になっているので、そこにコスパやタイパという概念はないんです。
だからこそ、これを「仕事の勉強」として義務感でやっている人と、好きで没頭している人が同じ土俵で勝負するのは、どう考えてもアンフェアで残酷な話だなといつも思っています。好きでやっている人は有利になりがちだと思うからです。
とはいえ、学習の定着率を高めるための「効率の良いやり方」は存在します。意図的に思い出そうとする行為を時間を開けて繰り返す「アクティブリコール（Active Recall）」や「間隔反復（Spaced Repetition）」などですね。そうした根拠のある手法を学習に導入することで、タイパを高めることは可能でしょう。プログラミングや技術にのめり込むほどではないけれど、競争力を得るためにこれらを習得しようと思っている人には、そういったやり方がいいと思います。
でも最終的には、対象の技術を好きになり、「どんな人が、どんな問題を解決したくてこれを発明したのか」という、背後にある人や問題解決の物語に興味を持つことが一番重要で、理解を深めるための最大のコツだと思っています。
AI時代の予見。「リソース効率」から「フロー効率」へのシフト
ーーいま、AI（AgenticCodingなど）の登場で開発のあり方が激変し、凄まじい量のAIに関連する情報が流通するなかで、情報過多に陥らないためのフィルタリングはどうされていますか？
和田さん：情報量が多すぎてすべてを摂取しようとすると確実にパンクしてしまいます。ベテランは過去の事実や経験からの類推を使ってフィルタリングしています。「この構図は15年前のあれと同じだ」「AI時代で新しいように見えるけど、実は道具が変わっているだけの状態だな」と捉え、「この情報は無視していい」「こっちの情報は把握しておくべき」と判断しています。
ーーAIが物量的にコードを高速生成する時代において、開発現場ではどのような変化が起きると予測されますか？
和田さん：いまお話している「2026年3月末時点では」という前提でお伝えします。現在の大きなテーマとして、AIがコードを生み出す速度や量に、人間のコードレビューが追いつかないという問題が起きています。これは過去に、GitHubの登場によってPull Requestが急増したときに起きた現象と共通する構造があります。
そして、こうした歴史から類推すると、レビューをさまざまな場所に再配置する流れになると考えられるでしょう。再配置場所にはさまざまな議論がありますが、具体的には以下の5つがポイントとして考えられます。
- 要件定義やドキュメント整備など、事前設計の強化（AIによる強度の高いレビュー導入）
- TDDの実践。動的検査としてのテストコードの存在がAIのスケーラビリティと質を両立させるうえでファーストチョイスに
- 静的型付けや静的検査で構造的な正しさを担保する
- リスクベースでレビューの濃淡をつける（重要な部分は人間が分厚く、あとで修正可能な部分などは薄くする、あるいはAIに任せる）
- AIの発する問いに対して、即断即決できるチーム体制（モブワークやペアプロなど）をつくり、教育としてのレビューの役割を補完する
そして、これらに関連して起きる変化として、「リソース効率（とにかくたくさん並列で作らせる）」から「フロー効率（付加価値の高いものを素早く通す）」への転換が予想できます。
AIを休みなく働かせて圧倒的な物量や機能を生み出しても、それがユーザーが得る価値につながらなければ意味がありません。AIの速度に対応するためには、人間側がチームを組んで即断即決できる体制をつくり、この体制にメンバーの教育的な機能も含めながら、確実なコードを通していく。並列で処理する量を絞ってでも、スループット（フロー効率）を高める形にシフトしていくだろうと考えています。
ソフトウェアエンジニアの根源的な喜びと、AI時代を生き抜くための「構造化と言語化」
ーーAIの登場によって、コードを書く機会が減ったとしても、ソフトウェアエンジニアという仕事ならではの魅力や喜びは変わらずに存在するのでしょうか？
和田さん：プログラマーやソフトウェアエンジニアの仕事には、「自分が考えたものが、思いどおりに動く」というブロックゲームのような本能的な楽しさがあると思っています。そして、もう少しスコープを広げると、「それが誰かの問題解決に繋がる」という点です。自分が書いたコードが、誰かの困りごとを解決し、生活や人生に良い影響を与える、関与できるというのは、大きな醍醐味だと思います。
ーー最後に、AI登場以降をサバイブし、豊かなキャリアを歩むために、ソフトウェアエンジニアが磨き続けるべきスキルを教えてください。
和田さん：AIがコードを書けるようになると、「自分が思い描いたとおりに動かす」というプログラミングの根本的な価値や喜びは変質していくかもしれません。こうした流れのなかで競争力のあるソフトウェアエンジニアであり続けるための提言は、不確実性の高い現時点で語るのは難しいですが、強いて言えば「構造化」と「言語化」のスキルが重要になると考えています。
目の前にある問題を正しく構造化し、整理整頓して、それを人間やコンピュータに正確に伝える能力です。いわば、インプットもアウトプットも整理整頓できる力ですね。これは才能ではなくスキルなので、訓練で鍛えられる要素ですし、量稽古、つまり試行回数によって磨かれます。
考える技術、書く技術、システム思考やテキストコミュニケーション能力を磨くことが重要になってくるでしょう。そして、多くの人の考えに触れ、対話し、自分もまた伝えるといったプロセスが今後さらに重要になるでしょう。
ーーありがとうございました。
取材・文：はてな編集部
撮影：小野奈那子
マイナビ転職 アンドエンジニア編集部
▶【ITエンジニア本大賞2026】必読の6冊