技術力は上がっている。任されるスコープも広がった。それでも、どこかで成長の天井にぶつかっている——。そのような感覚を味わったことはありませんか？
連載「技術の“先”を聞きに行く」では、技術力の前に立ちはだかる壁を超えたエンジニアに、その感覚をどう突破したかを聞きに行きます。
第2回は、株式会社ログラス VP of Technology（技術基盤本部本部長）の川村剛司（@k0j1iii）さんです。川村さんはDevelopers Summit 2026で、エンジニアのスキルを4領域×40項目で可視化した分析結果を発表。その内容をまとめたnoteが反響を呼びました。
リーダー層とそれ以外の層を比較したとき、最も差が小さかったのは「技術スキル」であり、最も差が大きかったのは「本質課題の特定と抽象化」や「マルチステークホルダーとの合意形成」といった、技術の“先”にあるスキルだった。この結果について川村さんは「全く驚きのない、現場での肌感覚を裏付けるもの」だったと振り返っていました。
会社とは何か、自分はその中でどういう存在か。前提から順に考えていけば、判断の軸は自然に決まる——。もちろん、技術力はその前提条件。その土台の上にロジックが乗って、はじめて壁を越える武器になります。前提の整理から現場での判断まで。川村さんの思考経路をたどります。
技術力ではなく、ビジネスへの「接続」が壁になっている
ーー デブサミで発表されたスキル分析で、リーダー層との差が最も小さかったのが技術スキルだったという結果がありました。その結果に、驚きはなかったそうですね。
技術力はとても高いのに、それが社内で評価につながっていないケースは珍しくありません。社内の第一人者に迫るような実力があるのに、なぜか評価とは結びついていない。技術力と評価は直結しないということには、以前から気づいていました。だから、データとして出てきた時も意外性はなかったんです。
ーー 技術力ではないとしたら、何が評価を分けているのでしょうか。
技術力が高いのに評価につながっていないケースは、技術そのものが足りないのではありません。その技術を使ってビジネスに貢献するという「接続」が抜けていることが多いのではないかと思います。
大前提として、会社はビジネスを行う場であり、そこに貢献することが評価の基本になります。そう考えると、評価の指標は「何の技術を使ったか」だけではなく「その技術でビジネスにどう貢献したか」という視点が不可欠です。
もちろん、高い技術力や深い探求心は非常に重要ですし、私自身も大切にしています。
ーー つまり、技術力だけでは壁を越える条件として不十分だということですか。
正確に言うと、技術力は次のステージに進むための「必要条件」です。ただし、それだけでは「十分条件」にはなりません。技術力という土台があった上で、それをビジネス貢献にどう接続するか。そこが抜けていると、どれだけ技術を磨いても評価とは結びつかないんです。
この「接続」をどう生み出すか。実はこの問いには、自分自身もずっと向き合い続けています。
経験がなくても、ロジックで判断軸はつくれる
ーー 「向き合い続けている」とは、具体的にどういうことですか。
ビジネスで成果を出すことがゴールなら、その手段は技術でなくてもいいですよね。営業でもいいし、他の職種でもいいわけです。でも、私は技術で自分の活動を縛っている。「この選択が本当に正しいのか？」という思いは、正直ずっと持っています。
それでも技術を選んでいるのは、エンジニアリングにはコントロールできない変数が少ないからです。個人的な感想ですが、外的要因に大きく左右される領域よりも、システムとして課題を構造化しやすいエンジニアリングのほうが性に合っていたのだと思います。
物事がどうなっていて、なぜこうなっているのか。その構造を解きほぐしていく作業が、純粋に面白いんですよね。それは技術の課題でも組織の課題でも同じで、問題を解くこと自体が好きなんだと思います。
ーー 技術を手段として選んだ上で、仕事におけるご自身の役割をどう捉えていますか。
私は仕事の場では、自分をビジネスを動かす役割の一つだと位置づけています。であれば、判断の軸がビジネスゴールに行き着くのは自然なことです。これは誰かに教わったわけではなく、ロジックに沿って考えたらそうなった、という感覚です。何か劇的な経験があったわけでも、転機があったわけでもありません。
あくまで、仕事においてビジネス視点を持つというスタンスの話で、人生の価値観としてビジネスをゴールにしろと言っているわけではないですよ。
ーー そのスタンスを持っていないエンジニアは、どこかで止まってしまうのでしょうか。
そうかもしれません。技術への情熱やこだわりが強いからこそ、ビジネス課題の解決に目線が向きにくくなってしまうケースは珍しくありません。せっかくの高い技術力が評価に結びつきづらくなるのは、非常にもったいないと感じます。
一方で、ビジネス視点だけを持てばいいというわけでもありません。ビジネス視点はもちろん重要ですが、エンジニアとしての確かな技術力が伴わなければ、課題を自ら解決しきることは難しくなってしまいます。
先ほどお話しした必要条件・十分条件の話に戻ります。技術力は必要条件です。その上にビジネスゴールを軸にするというロジックが乗って、十分条件になる。両方が揃ってはじめて、技術がビジネスを動かす武器になるんです。
だからこそ、私は「技術の研鑽も決しておろそかにしないでほしい」と伝えています。技術力という強固な土台がなければ、どれほどビジネス視点を持っていても、それを実行し、形にする手段がありませんから。
現場でロジックを実装して、作るべきものを見極める
ーー そのロジックが、実際の現場でどう機能するのか伺いたいです。ログラス入社の経緯から教えてください。
私は2025年4月に入社しました。ちょうどログラスが新規事業を立ち上げるタイミングで、新規事業のエンジニアリングマネージャーとして参画しました。複数の領域を、それぞれ小規模なチームで回していく体制です。
参画したのは新規事業の立ち上げ初期ということもあり、「何を作るか」も含めて自分で型を決めていくことが期待されているフェーズでした。そうした正解のない状況であっても、「ビジネスゴールを軸にする」というスタンスさえあれば、環境が変わっても何を優先すべきかはおのずと明確になります。それはログラスという新しい環境でも同じでした。
ーー 新規事業の立ち上げで、どのような課題に直面しましたか。
今回の新規事業は、既存プロダクトの対象領域とは異なる新しい課題ドメインに挑戦するものでした。そのため、既存のSaaSの枠組みをそのまま適用するのではなく、お客様の課題に対して「何をどう作れば応えられるのか」をゼロから検討するアプローチが必要だったのです。
そこで、お客様先に入り込んで一緒に検討するところから始めました。営業やコンサル的な役割のメンバーと並走しながら、非常に短いイテレーションで開発を回していきました。
その中で徹底していたのは、「自分たちが作りたいものを作らない」ということです。目指していたのは、お客様の課題を理解し、お客様自身にイメージを湧かせること。まだプロダクトとして売るフェーズではないので、それがこの段階でのゴールでした。
ーー 不明確な状況で、何を作るかはどうやって判断していたのですか。
お客様側で対応してくださる、いわゆるチャンピオンのような方がいます。その方が今押さえたいポイントをしっかり押さえること。それが、このタイミングで目指すべきことです。
そのために何が必要かを話し合い、整理し、必要最小限のものを見せていく。時間は有限ですから、「これは必要、これは今はいらない」という取捨選択を常に行っていました。
お客様に「こういうイメージですね」と言われたら、「じゃあちょっと作ってきます」と、すぐに自分でプロトタイプを作って次のチームミーティングに持っていく。話し合って、作って、見せて、また話し合う。このサイクルを短く回し続けることが重要でした。
ーー このサイクルを回す中で、判断の軸として大切にしていたことは何ですか。
お客様が最終的に欲しいものと、今確認したいことを区別することです。
お客様が「欲しい」とおっしゃっても、最終的に欲しいものと今この瞬間に確認すべきことは別です。チャンピオンが今押さえたいポイントはどこか。そこを見極めて、そのために必要なものだけを作ることが求められます。
この判断を的確に行うには、ビジネスのゴールを深く理解している人と、それを技術で即座に形にできる人が揃っていることが不可欠だと思っています。ビジネスゴールが見えているからこそ「何を作らないか」を判断でき、確かな技術力があるからこそ「いま必要なもの」を素早く提供できる。ビジネス側の視点とエンジニアリングの力がチームとして結集してはじめて、このサイクルが回るのです。
ーー その動き方は、ログラスでは組織として再現しようとされているんですよね。
はい。今お話ししたような動き方を、個人ではなく組織として再現できるようにするために、ログラスではFDE（フォワードデプロイドエンジニア）というポジションを新たに設けました。
このFDEとも関連しますが、ログラスでは「ビジネスリードエンジニア」を増やしていきたいと考えています。AIのサポートによってゼロからコードを記述する時間が大幅に削減された分、エンジニアはより上流の課題解決に時間を使わなければなりません。
一方、お客様の課題解決に直結しない機能をどれだけ提供しても価値にはつながりませんから、クリティカルなものをちゃんと見極める必要がある。PdMと並走しながら、エンジニア側からも能動的に課題提起をしていくぐらいの気概を持ったエンジニア。それがビジネスリードエンジニアです。
道具は変わっても、判断の軸は変わらない
ーー AIエージェント時代に入って、その判断の軸に変化はありましたか。
軸は変わっていません。ビジネスのゴールを理解し、技術で形にするという本質は、AIがあってもなくても同じです。
むしろAIが出てきたことで、明確になったことがあります。それは「意思決定はAIに任せられない」ことです。
コードを書く作業の多くを、AIがサポートする時代になっていますよね。ただ、AIの出力を判断し、修正するのは人間の役割です。これが不要になったとしたら、エンジニアという職業自体がいらない世界ですが、今はまだそうではありません。
そもそも、AIが登場しても、技術を使って成果を生み出すという行為の本質は変わっていないと考えています。機械語、アセンブリ、C言語、Pythonと進化し、今度はAIが登場した。段階を踏んでいるだけで、プログラミング言語というインターフェースが、自然言語に置き換わったにすぎません。大工さんが電動工具を駆使するようになったのと同じで、道具が進化しているだけです。
ーー それでも、技術の基礎を学ぶことには意味があるのでしょうか。
コンピュータサイエンスという学問があり、先人の知恵が蓄積されています。体系化されている分、後から押さえても十分に力になるはずです。
たとえば、便利なフレームワークを使って開発する際も、その裏側でどう動いているかという仕組みの理解があるかどうかで、課題解決の深さが変わってきます。基礎的な理解が薄いと、どうしても表層的な対応にとどまってしまうことがあるからです。
ビジネスのアウトカムに本当にコミットするためには、根本的な課題解決が求められます。AIが生成したコードの良し悪しを見極めるにも、お客様の課題に対してどの技術で応えるかを判断するにも、技術への深い理解が前提になります。
知識を積み重ねて引き出しを増やすことで、はじめてより深い課題にアプローチできるようになります。知識だけで全てが解決するわけではありませんが、ビジネスを前に進めるための土台として、やはり欠かせないものだと思います。
ーー 技術力を磨き続けた先に、もう一つ必要なことがあるとしたら何ですか。
コミュニケーションをとって、相手を理解することです。上司が何を考えているのか、お客様が何に困っているのか。まず自分の周りにいる人を知ることから始めてほしい。手段は何でもよくて、コーヒーに誘うのでもいいんです。いずれにしても、受け身でいたら見えるものも見えてきません。
ログラスではエンジニアが展示会に行くこともあります。私も新規事業のデモを持って行ったのですが、お客様の声をダイレクトに聞けるんですよね。「こういうことができると嬉しい」「こういう課題があるけどマッチしますか」と、ニーズがその場で聞ける。それを持ち帰ってすぐにプロトタイプを修正し、次の機会にまた見せる。相手を理解するとは、このサイクルを回すことだと思っています。
エンジニアは、お客様やビジネスの現場から物理的にも組織的にも距離があることが多いですよね。だからこそ、意識しないとこの一歩はなかなか踏み出せないんです。そういったコミュニケーションを少し面倒に感じる方もいるかもしれませんが、苦手なことって意識しないとできないんですよね。私もそうで、苦手なことはいっぱいあります。でも、意識するところから始めれば、最初の一歩は踏み出せる。ぜひ、そこから始めてみてほしいです。
