技術力は上がっている。任されるスコープも広がった。それでも、どこかで成長の天井にぶつかっている――。そのような感覚を味わったことはありませんか？
新連載「技術の“先”を聞きに行く」では、技術力の前に立ちはだかる壁を超えたエンジニアに、その感覚をどう突破したかを聞きに行きます。
第1回は、株式会社CARTA ZERO 上級執行役員CTOの河村綾祐（@r_kawaiimura）さん。河村さんは2026年2月に公開したテックブログ「CARTAで『事業をエンジニアリングする』とはどういうことか」の中で、エンジニアの成長を阻む「見えない壁」について書いています。「与えられた問題を技術で解く」ことと「解くべき問題を自ら見定める」こと。この2つの間にある隔たりこそが壁の正体であり、河村さん自身も長い間その存在に気づかなかった、と。
キャリアの中で壁をどう認識し、何をきっかけに越えてきたのか。AIがコードを書く時代に、その壁の越え方に変化はあるのか。テックブログでは語られなかった、河村さん個人の経験――エンジニアリングする対象を試行錯誤の中で広げてきた道のりを辿ります。
ひたすら技術を磨き続けた20代と、視野が広がった転職
― 河村さんはテックブログで、「与えられた問題を解く」ことと「解くべき問題を自ら見定める」ことの間に壁があると書かれていました。まだ壁の手前にいた頃のご自身について教えてください。
20代の頃がまさにその状態だったと思います。
1社目のSIerにいた頃は、「エンジニアなんだから技術で勝負しよう」とがむしゃらにやっていました。誰の何の課題を解くかというよりは、目の前の課題をどう解くか。つまり「How」の部分に注目していましたね。
「パフォーマンスが良くなった」「新しい技術を使えた」そういうことが自分にとっての目的であり目標でした。
当時はマネジメントにも関心が薄く、プロジェクトリーダーまではやっていましたが、プロジェクトマネージャーにはなりたくなかったんですよね。当時の会社のPMは、工程管理であったり、その工程にいくら予算を使うかを設計するような役割でした。今ではそういう仕事も必要だと理解できますが、当時は数字よりも技術と向き合っていたかったんです。
― 当時、仕事やキャリアの中で一番大事にされていたことは何でしたか。
人の夢をデジタルで叶える。技術を使って叶える。それがずっとやりたかったことです。
こういうものをつくりたい、と言ってくれた人の想いを技術で実現する。そのためには引き出しをたくさん持っていなければならないし、どこかの領域を突き詰めなければならない。だから、ひたすら技術を磨いていた20代でした。
― 「How」に集中されていた当時、視点が変わり始めたきっかけはありましたか。
転職先での経験が大きかったです。
小さな自社サービスの会社だったのですが、つくったものを運用する人も、それを売る人も、すぐそばにいる環境でした。営業に同行して顧客にヒアリングをしたり、フィードバックをもらって反映したりする中で、見える景色が変わっていきました。
営業中心の会社で、ものをつくる人が少なかったので、要望に対してエンジニアの手が圧倒的に足りないんです。だから自然と、使う人にとって一番レバレッジが効くのはどこか、という優先順位を考える癖がついていきました。
― その頃から「何のために解くのか」「そもそもこれは必要なのか」と考えられるようになっていったのでしょうか。
そうですね。キャリアの初期には考えもしなかった問いが、お客様や運用担当者の近くにいることで自然と出てくるようになりました。具体的に何かきっかけがあったというよりも、環境が変わって関わる人たちが増えたことで、結果的に視野が広がったのだと思います。
経営に踏み込んではじめて見えた「技術力の使いどころ」
― その後、さらに大きな転換となった経験があったのでしょうか。
社会人になって10年が経過した頃の経験が大きかったですね。ある外資系スタートアップの日本法人で、当初は日本サイドの技術責任者として仕事をしていました。
その後、MBO（経営陣による買収）を経て経営側に入りました。経営の立場で会社全体を見回すと、技術以外の課題に向き合う必要があることに気づいたんです。自分が技術を追求したいと思っても、それが事業として成り立つかどうかはわからない。技術だけに閉じていても、未来にはつながらないですから。
それ以降は、事業全体を見たときに、その瞬間瞬間でどこに技術を使えばバリューが出せるかを考えるようになりました。
― 過去のインタビューで、既存のプロダクトを捨てて3か月でつくり直したという当時のエピソードが語られていますね。あの決断の背景を聞かせてください。
背景としては2つあります。
1つは、つくるべき範囲の見極めです。それまで「借り物のシステム」を担いで日本でビジネスをしてきました。ピボットを重ねながら8〜9年ほど開発・運用を続けるうちに、さまざまな機能がコード的にも複雑に絡み合い、メンテナンスがしづらい状態になっていました。ですが、そのシステムが何を実現しているかは把握できていたので、日本でビジネスをする上で削ぎ落としていい部分はどこか、この期間でできる量はどれぐらいかを見積もることができました。
画面は究極的にはデータベースの中身を表示しているだけなので、まずはデータの流れさえ設計できればいい。そう判断して、一旦「画面なし」で、3か月で日本独自の基盤にリプレイスしました。
もう1つは、日頃からアイデアを温めていたことです。ビジネスとシステムの全体像を理解した上で、自分だったらこうする、こうすれば実現できそうだ、という考えを普段から持っていました。だから、やると決めるまでは早かったですね。他の経営陣からしたら「マジでやるの？ できるの？」という感じだったとは思いますけど（笑）。
― 河村さんは先述のテックブログで、「事業をエンジニアリングする5つの視点」を挙げていましたが、今のお話はまさにその実践に聞こえますね。
そうですね。「なぜそれが必要なのか（Why）を考える」という話だと思っています。
引用元：CARTAで「事業をエンジニアリングする」とはどういうことか
3か月でできたのは、全体を俯瞰してどこを削れるかが見えていたからです。制約は期間だけだったので、実装の前に設計で勝負する必要がありました。それができたのは、日頃からアイデアを温めていたことが大きいですね。
ただ、技術選定については反省もあって、当時ちょっとやんちゃな技術スタックを使ってしまい、後からリプレイスすることになりました。とはいえ、そのシステムで3年ぐらいはもちましたからね。
AI時代もWhyは人間が握る。試行錯誤の中でつかんだ実感
― ここまでのお話は、すべてご自身の判断と手で積み上げてきた経験ですが、今はAIという道具があります。AIに任せることと自分で握ることの線引きは、どのように判断されていますか。
判断基準はシンプルで、自分でなくてもいい領域は任せるようにしています。 コードを書く、設計書を書くといった作業は基本的にAIに任せる。ただし、骨子や制約はちゃんとしたためた上で、これに沿って書いてほしいという形で渡すことが多いです。
ただし最初からそうだったわけではなく、当初はGoogle検索の代わりぐらいにしか思っていませんでした。その後、Claude CodeやCodexが出てきて、CLIの中でできる領域が広がったことで、この線引きが見えてきた感じです。
ただ、任せるといっても丸投げではありません。LLMは同じ質問をしても毎回違う回答が返ってきます。揺らぎがある。その揺らぎの幅をどう狭くするのか、あるいは許容するかどうかを、ちゃんと人間が考えて判断する。 それが今の自分の立ち位置だと思っています。
― 任せる範囲が広がると、そのぶん複雑になりそうです。実際にはどのように管理しているのですか。
ソフトウェアのライフサイクルで言うと、設計、実装、テスト、デプロイ、運用、監視とありますよね。私たちにはフルサイクル開発という考え方があるので、このサイクル全体をどう回すかをまず考える。その中で、自分が担うのは「何を解くか」の判断と設計までです。骨子と制約を決めたら、実装以降はAIに任せてみようというのが出発点でした。
そうするとタスクを並行で回せるようになる。自分の下にAIの部下（AIエージェント）が10人いるような状態ができるわけです。その10人が意図どおりに動けるようにするには、TDDでなければダメだよね、レビュワーは分離しなければダメだよね、10人を束ねる役割が必要だよねと、設計上の判断軸（ガードレール）が次々に出てきます。
ただ、10人が並行で動くと、何が起きているかを人間が把握しきれなくなります。そのときに大事なのが、事実を残すことです。AIエージェントのログはローカルに残りますが、普通はそこまで見ないですよね。表面上うまくいっているように見えても、中で何が起きたかはわかりません。私はそれが怖くて、AIエージェントが使う小さなプロセス（コマンド）をたくさんつくって、その間に事実を残すような設計にしています。自分が見たい角度で見れるようにインターフェースも用意しています。
― たしかに事実を残すのは重要ですね。AIとの協業で、想定どおりにいかなかったことはありますか。
全然あります（笑）。完璧にガードレールを敷けているわけではなくて、逸脱することもしばしばです。
たとえば、AIエージェントに設計を任せると、自身の仕様上の制約を度外視した提案を出してくることがある。SkillsからSkillsを呼び出せないとか、サブエージェントがさらに別のサブエージェントを呼び出せないとか、そういう制約があるのに、それを無視した設計を出してくるんです。「お前のことなんだけど」と思いましたね（笑）。
こうした試行錯誤のプロセスを仕組みとして形にしたのが、個人で開発しているcekernelというツールです。社内でも少しずつ使われ始めています。
参考：速さは設計を代替しない — cekernel Reviewer の試行錯誤から
手段は変わり続ける。残るのは「なぜ解くのか」を問う意志
― ここまでのお話を通じて、河村さん自身も日々模索し続けていることが伝わってきました。「何を解くか」を見定める力をつけるために、読者がまずやるべきことは何でしょうか。
5つの視点の中でも、やっぱり「Whyを考える」ことが一番重要だと思っています。他の視点はAIが補える部分も大きいですが、何を与えるかを考えるのは人間にしかできないので。
具体的には、「なぜこの設計にしたんだっけ？」と自分に問い直してみてほしいです。 人に説明するのでもいい。それを習慣にすることが大事だと思います。私が積み上げてきたことを、AIの進化によって今の若い人たちは圧縮された状態で始めています。だからこそ、使えるものは使いながら、その問いだけは手放さないでほしいですね。
そして、「与えられた問題を解く」から「解くべき問題を見定める」へ、その壁を越えるには自分の現在地を認識することが必要です。そこから「じゃあ自分には何が足りないのか」に目を向けられるか、そして「足りないものを補うために行動できるか」どうかだと思います。
― 壁を超えてからも変化は続きますよね。その中でも活躍し続けるエンジニアには、どんな共通点がありますか。
こだわりは持つけど、こだわらない。 難しい話をしていますけど（笑）。
エンジニアとして好きな技術があるとか、この設計で勝負したいとか、そういう個人としてのこだわりは持っていてもいい。それがモチベーションになるし、自分の引き出しを増やす原動力にもなるので。でも、いざ事業やプロダクトの課題に向き合うときに、その手段に固執してしまうと判断を誤ることがあります。事業のフェーズもチームの状況も変わる中で、何が最善かを客観的に選べるかどうかが大事です。
こだわりという軸は持ちつつ、目の前の課題に対しては手段を選ばない。それが変化の中でも生き残ってきた人たちに共通する部分だと思います。
ちなみに私は自分の職業を名乗るとき、あえて「エンジニア」とだけ言うんですね。何をエンジニアリングするかはその時々で変わるし、変えていくものなので。組織、業務、システムをエンジニアリングの考え方で設計・実装していく。それが私にとって「事業をエンジニアリングする」ことだと思っています。
― 手段も、エンジニアリングの対象も変わり続ける。その中で河村さんが変わらず大事にしてきたことは何ですか。
問いを立てる力です。AIにどう聞けば欲しい答えが返ってくるのか。壁打ちしながら引き出せるのか。返ってきた答えを技術的に打ち返せるのか。経験としてそれがわかっているかどうかが大きいです。一発で正解が返ってくるものではないですが、自分を磨き上げるプロセスの中で育てていくものだと思っています。
何を聞くか、どう聞くかは、結局「何を解くべきか」を考え続けてきたかどうかで決まります。私が積み上げてきた経験も、AIに対する問いの精度として活きているんです。
AIと壁打ちしていて、「人間に残された作業は、今は意志を持つことだ」という結論にたどり着いたことがあります。何をエンジニアリングするかは変わっても、「なぜそれを解くのか」を問い続ける姿勢は変わらない。それが私の今の答えです。
