「自走できるエンジニア」とは何か。求められる4つの力と、伸ばし方

「もっと自走してほしい」——1on1やレビューでこう言われたことがある人は多いと思います。ただ、この言葉ほど曖昧なものもありません。言われた側は「言われる前に動けということ？」「質問するなということ？」と受け取ってしまい、かえって手が止まることすらあります。

この記事では、実務でいう「自走」を4つの力に分解し、それぞれをどう伸ばすかを整理します。

「自走」は性格ではなく、分解できるスキル

まず前提として、自走は「やる気」や「主体性」といった性格の話ではありません。判断に必要な材料を自分で集め、決めて、動き、結果を検証できるという一連の手続きのことです。手続きである以上、分解して練習できます。

逆にいえば、自走できていないと言われる状態は、この手続きのどこかが欠けているだけです。どこが欠けているかを特定できれば、対処は具体的になります。

自走を構成する4つの力

1. 要件を自分で詰める力

渡されたチケットをそのまま実装するのではなく、「この機能は誰のどんな困りごとを解決するのか」「書かれていない条件は何か」を自分で確認しにいく力です。

伸び悩む人の多くは、仕様の曖昧さに気づいていないのではなく、気づいているのに確認せず、自分の解釈で実装してしまいます。手戻りの大半はここで生まれます。

練習方法はシンプルで、着手前に「この実装で合っていますか」ではなく「この条件のときはAとBのどちらを想定していますか」と聞く形に変えることです。前者は判断を相手に丸投げしていますが、後者は自分で論点を切り出せている証拠になります。

2. 設計を選べる力

実装は動けば終わりではありません。「なぜこの構成にしたのか」を説明できるかどうかが、3年目以降の評価を大きく分けます。

• この処理はどこに置くべきか（コンポーネント / hooks / サーバー側）
• 状態はどこが持つべきか
• あとから仕様が変わったとき、どこを触ることになるか

これらに答えられないまま書かれたコードは、レビューで「動くけど直したい」と言われます。設計を選べる力は、選択肢を2つ以上思いつけて初めて発揮されるので、普段から「別の書き方だとどうなるか」を1つ考える癖をつけるのが最短です。

3. 詰まったときに切り分ける力

質問すること自体は自走の反対ではありません。問題は質問の粒度です。

「動きません」で止まる人と、「この行までは期待通りの値が来ていて、この関数を通ったあとに undefined になります。原因はこの2つのどちらかだと思っています」まで持っていける人とでは、同じ質問でも意味がまったく違います。

切り分けは技術力というより手順の問題です。どこまでが正常かを二分探索していけば、誰でも到達できます。

4. 自分の市場価値を把握する力

意外に思われるかもしれませんが、これも自走の一部です。社内の評価だけを基準にしていると、「社内では優秀だが外では通用しないスキルセット」に気づけません。

• 自分が今できることは、求人票のどのレベルに相当するか
• 次に必要とされている技術は何か
• 自分の実績を、社外の人に伝わる言葉で説明できるか

キャリアを自分で選ぶには、この現在地の把握が前提になります。

AI時代に、自走の価値はむしろ上がっている

コードを書くだけなら生成AIで足ります。だからこそ、「何を作るべきかを決める」「設計の妥当性を判断する」「出てきたものを検証する」という部分の重要度が上がっています。

これらはすべて、ここまで挙げた4つの力そのものです。AIに仕事を奪われる側と、AIを使って生産性を何倍にもする側を分けるのは、この判断力の有無です。

まとめ

「自走できるエンジニア」は曖昧な精神論ではなく、

1. 要件を自分で詰める
2. 設計を選べる
3. 詰まったときに切り分ける
4. 自分の市場価値を把握する

という4つの手続きの集合です。自分がどこで止まっているかを特定し、そこだけを練習すれば必ず伸ばせます。

4つ目の「市場価値を把握する」については エンジニアの市場価値を上げる方法 で、この力がAIの登場でどう効いてくるかは AI時代に生き残るエンジニアは何が違うのか で詳しく書いています。

ただし、この4つはひとりで学習していても身につきにくいという難しさがあります。要件の詰め方も設計の選び方も、自分より先を行く人にレビューされて初めて「何がズレていたか」が分かる性質のものだからです。

JISOU は、この「自走できるエンジニア」になるまでを現役エンジニアが伴走する、経験者専門のプログラミングスクールです。今の詰まりどころがどこにあるのかを整理するところから相談できます。