なぜエンジニアという職能が、人を「強制的」に成長させるのか

BASE株式会社執行役員の柳川です。金融事業の事業責任者をしています。
私はエンジニア→PdM→事業責任者というキャリアを歩んできました。
現在は事業戦略、プロダクト戦略、組織戦略全ての責任を持ちながら、事業責任者を務めさせていただいています。

仕事柄、「人はどういう時に成長するのか？」という問いを普段からよく考えています。

人が成長する要素の一つに、「普段どのような仕事（職能）に従事しているか」があると思います。この要素は、成長しやすい環境や、思考の癖、習慣の延長線上にあるものです。 今回は、「普段エンジニアという職能で働いていることが、いかに成長に影響するか」をテーマに書いてみます。

あくまで大まかな傾向を独断と偏見で書いているだけなので、ご笑覧ください。現場や環境にもよると思います。「それエンジニア以外にも言えるでしょ」という項目もあるかと思いますし、生成AIの台頭で状況が変わっている部分もあるでしょう。 ただ逆に、生成AIに頼ることで失われてしまう「良い習慣」もあるような気がしています。そんなことも含めてつらつら書いております。

成長とは具体的に何か、の定義は様々あると思いますが、この文章では仕事ができるようになること。特に非定型な仕事で、抽象的な案件を具体化していく企画に近しい仕事の能力伸長を念頭に置いているという想定の元読んでください。

あと本文章でのエンジニアが指すものは主に、Webアプリケーションを作るサーバーサイドエンジニアだと想定して読んでください。それ以外も当てはまると思うけど一旦。

エンジニア最高でほかの職種下げるぞ！という内容ではないのです。一定続けられれば、エンジニアは成長しやすい構造の中にいるのではという話。そしてそこそこ続けやすい構造もある話。いきましょう！

1. マシンに矯正され続ける

基本的にマシンの方が正しくて、自分が間違っています。 文法が間違っていれば、コンパイラに指摘され、そもそも動きませんし、動いてもプログラムは書いた通りに実行されます。「正しく書いているはずなのになぜか動かない」。それは、正しく書けていないからです。 エラーが出たり、あるいは何も言わずに動かなくなったりする中で、原因究明に頭を悩ませ続ける。絶対的に正しいマシンを相手にする以上、矢印を自分に向け（自責）、悩み続けるしかありません。

この「悩む時間」は、実はとても贅沢なものです（生成AIに奪われつつありますが）。
マシンと対峙し続ける中で、自分に対する「健全な猜疑心」が生まれます。 「自分が間違っているかもしれない」という自覚を持つことは、本来なかなか難しいものです。余談ですが、マネジメントの最大の課題は「いかにできていないことを自覚させるか」だと個人的には思っているくらいですから。

エンジニアの仕事、特にコーディングをする場面においては、細かいPDCAが高速で回る上に、そこに曖昧さがありません。動く時は動くし、動かない時は動かない。
他職種の場合、上司にゴン詰めされたとしても、その根拠は割と曖昧で、他責にする余地があったりします。でも、マシン相手には言い訳が無効です。強制的に自責思考にならざるを得ないのです。
部下への指示だって事細かに1行ずつ記載しません。どこかで汲み取ってくれることを期待して支持を出します。
コーディングをするというのはそういう甘えが一切ない。本当に書いた通りにしか動かない。

これほど高頻度で「お前は間違っている」とダイレクトに具体的に突きつけられる仕事は、エンジニア以外にないと思いませんか？
そして「お前は間違っている」だけではなくて、一定の明確な答えがある頻度も高い仕事です。つまり間違ってるの数だけ、合ってるがあって、小さな成功が積み上げやすい仕事でもあります。「お前は間違っている」だと病みますからね。継続的に達成することで自己効力感を継続するのも大事なのです。

正直エンジニアになってはみたものの「エンジニア自分には向いてないかも」と思う人も居るかも知れません。
この記事の内容全体的に、前提として「エンジニアを少なくとも3年くらいやってれば身に付く」というと前提が入ってしまっています。向いてないのに続けるのは辛いと思います。しかし辛くても「このような構造の中に自分は居るんだ！得るものがあるんだ！」と考えられると耐えられる気がしませんか？

2. テストコードを書くということ

前述のとおり、プログラムは書いたとおりにしか動きません。書いた通りにしか動きませんので、期待通りの動きなのかを自らテストコードを書き、成果物を検証する癖があります。
例えば「テスト駆動開発」ではまずテストコードを書き、それが失敗する（＝できていない）状態からコードを書き始めます(概念であり実際はそんなことなかったりもするが)。これは前述の「健全な猜疑心」に近いですが、「できていない状態」を直視することから思考をスタートする習慣です。少しだけ言い換えると、仮説を持つみたいなことにも近いと思います。これは仕事をする上でめちゃくちゃ大事です。この思考の癖付けが日常業務でできるのは大きな強みです。できてない人たくさんいます。

3. 「コトに向かう」レビュー文化

レビュー文化も、他職種から見るとかなり特殊です。
一般的に人から間違いを指摘されるのは辛いものです。そしてしてする側も辛い。辛いから、なかなか指摘しないし、されません。端的に言えば、指摘はコストです。
他職種では、新卒時代くらいではないでしょうか、手取り足取り指摘されるのは。 （新卒時代というのは、「教わる側・教える側」という前提条件がお互いに揃っているから、相互に指摘ができるわけです。）

辛いことであるにも関わらず、指摘するのもされるのも重要なソフトスキルです。本気でプロダクトや状況を改善したければ、指摘は欠かせません。 「人ではなく、コト（コード/設計）に対して指摘する」。 この分離が文化として根付いているのは稀有です。この分離が根付いてないとレビューに耐えられませんからね。そしてこの分離は相互に訓練が必要なのです。

役職が高いマネージャーであっても、このマインドセットが染み付いていないケースは多々あります。

4. インシデント対応

追い込まれた状況の中で事象を分析し、切り分け、原因を特定して対処する。 これはマジですごいです。普通はテンパります。もちろんエンジニアもテンパりますが、すぐに「どうにかするしかない」という思考に切り替わります。
なぜなら、ガチで俺がどうにかするしかないからです。 この極限状態が、強制的に「課題解決脳」を鍛え上げます。

5. 本当の意味での「ラストマン」

インシデントの話にも繋がりますが、エンジニアは本当の意味でラストマン（最終防衛ライン）です。
エンジニアがコードを書いてリリースしないとユーザーに価値は届かないし、トラブルが起きればエンジニアが直すしかない。プロダクトで稼ぐ以上、それが宿命です。
事業責任者ももちろんラストマンの気概でやっていますが、技術的な最終局面ではエンジニアに頼り、祈るしかないこともあります（エンジニア自身も祈るしかない時はありますが）。

日々のアラート対応などを含め、「最後は自分の手でなんとかする、なんとかしてきた」という意識や実績の積み重ねです。これが手触りのある形で身につく仕事はそんなに多くありません。

自分が実装を終えないとデリバリーされない、自分がバグを直さないと復旧しない。最後は自分がなんとかするしかないんだなを骨の髄まで叩き込まれた経験は財産です。

6. 具体と抽象を当たり前に日々行き来し深く思考する

具体と抽象の行き来は他の職種でもあります。でも深さと頻度が違います。
最終的に自分がコードを書かないと動かないという

「具体」と、ドメインを捉えて設計をする「抽象」。この両極を日々行き来して訓練することになります。これをとてもとても繰り返す。
「具体と抽象の行き来が大事」という言葉はよく使われますが、本当にコードという直接的な「具体」に触れながら構造を考える仕事はそう多くありません。コードを書いたら、コードを書いた通りに動きますからね。
ここでいう具体は、デリバリーの最前線である、くらいの意味で書いています。最終的にユーザに届くところです。

「抽象」についてもすこし補足します。エンジニアはいろんなパターンに再現性を持って答える装置を作っています。いろんなケースを想定して、それを最小限の形にまとめて、再現性を持たせた形でデリバリーする。これがソフトウェア開発の一つの側面です。ただ、これがかなり難しいのです。一つのパターンだけに答えればいいわけではないし、一つのパターンに手をいれるだけに見えても、いろんなことに連鎖的に影響するわけです。連鎖的に影響しないためにはできるだけ抽象で捉えておかなきゃ。みたいなことが起きるわけです。

そして具体と抽象を行き来するために、エンジニアは深く思考します。よく「会議が細切れに入ると集中力が切れる」とエンジニアが言って若干微妙な空気になることがありますが、これは深く思考する必要があるからなのです。必然なのです。

7. アジャイルの本質

本当の意味でアジャイルに物事を進める必要がある仕事です。 個人的にアジャイルの真髄は、「わからないこと」と「わかるところ」を切り分け、わからない部分を小さく検証しながら進めることだと思っています。 開発手法としてのアジャイルを採用しているかどうかに関わらず、エンジニアは日々この「切り分けと検証」を行っています。多分。
手法としてのアジャイルを経験していましたみたいな話は、瑣末なHowにすぎません。
もちろんエンジニア以外でもこれができている人はいますが、あんまり必要に迫られることもなさそうで再現性がなさそうな気はしている。

8. 勉強会とシェアの文化

LT、登壇、技術ブログ。「当たり前」のようにそんな文化があるわけですが、冷静に考えると意味がわからないですよね。
社会人が仕事以外の時間で、必要に迫られていなくても勉強し、それをシェアして血肉にする。 そんなことが「当たり前」の文化になっているのは凄すぎます。これ以上ないほど良い習慣です。いい当たり前。

9. UNIXという考え方

「UNIXという考え方」という最高な本を知っていますか。
電子書籍ないけどシンプルなので読みましょう。
この本に書いてある、シンプルなツールを組み合わせ、一つのことをうまくやるという哲学は、複雑な課題を解くための強力な指針になります。
エンジニアリングの知識も大事なんですが、エンジニアの思考のフレームワークみたなものもものすごく大事なんですよね。そしてわかりやすくその思考を実践する機会があるというのが大事なのです。本だけ読んでも本当の意味では分からないですからね。

１０. エンジニアという世界の捉え方

歴史的にみても、抽象と具体の落差が大きい仕事をしているのがエンジニアだと思うんです。その性質そのものもだし、それを乗り越えるための様々なプラクテクティスも含めてエンジニアという世界の捉えの目線が養われていきます。もう少しかっこよくいうと思想体系みたいな、思考の型みたいなもの。

​これを僕は「コンテキスト力」と呼んだりしています。複数の前提条件（コンテキスト）を同時に抱えたまま、矛盾を解決し、最適解を導き出す力です。
その積み重ねそのものに価値があると考えます。
特に不確実性に挑む場面において顕著に。

成長しやすい構造の中で磨かれてきたエンジニアは守備範囲を広げていこう

ここからはポジショントークになりますが、エンジニア経験者が他職種へ越境する意味はめちゃくちゃあると思います。 だって成長しやすい構造の中で強制的に、「自責で考え、高速で学習し、具体と抽象を行き来しながら問題を解決するOS」をインストールされているからです。そのOSを搭載したままビジネス領域へ染み出すことは、組織にとって最強の武器になりまするのではないでしょうか。

例えば「事業計画（PL）」の基礎は算数です。「利益 = 売上 - 原価 - 販管費」などのシンプルな式の中で、どの変数を動かせば事業が成長するかを考える。これは皆さんが普段やっているコーディングやアーキテクチャ設計と似ているし、より簡単です。
個人的には事業計画を作って事業をマネジメントするのはテスト駆動開発に似てる思うのですよね。

世の中には分かることと分からないことの切り分けも出来ずに、すべてを不確実性だと認識して、すべてをやってみないと分からないと思ってしまう人もいます。
そういう人が事業マネジメントするよりも思考力があり切り分けのできる人が曖昧さや不確実性を許容できるようになる方が芽がある気がするのですよね。
必要以上にキツイ書き方しちゃったんですが、頭のネジが飛んでたりサイコパスじゃないと事業やれないみたいなノリが嫌なんですよね。できない可能性を考えられてしまうゆえに「あいつは出来ない理由ばかり思いつく」みたいな感じ。
確かにエンジニアは「健全な猜疑心」を持つので出来ない理由ばかり思いついているように思われがちですが、「健全な猜疑心」を持つ人のみが「でもこうすれば出来る」を発想できるのです。

「具体（実装）」を知っているエンジニアだからこそ、「この計画なら実装はこうなる」「この実装なら計画はこう変わる」というシミュレーションが誰よりも高速にできるはずなのです。

増えて欲しいなー、そういう人が。というポジショントークです。
「健全な猜疑心」をうまく使って欲しいのです。コード書いたり開発する時は「健全な猜疑心」なんだけど、それ以外の時にただの猜疑心になってしまったり、そもそも猜疑心を持てなかったりする。ちょっとした発想の違いなんですけどね。うまく応用できる人が増えて欲しい。エンジニアは以外にビジネスを作るための基礎スキル身についているから。まだまだエンジニアバックグラウンドの事業責任者というと珍しがられてしまう。

もちろん自分の経験や能力を、過大評価するべきではないけど、過小評価も良くない。いろんな職種を経験してきたらこその目線を書いてみました。

この文章はエンジニア贔屓で書きましたが、いろんなバックグラウンドの事業責任者がいたほうが良いと思っています。

あえて弱点を言うと

一方で、曖昧さに対する耐性は低くなりがちかもしれません。 普段向き合うマシンには曖昧さがありません。「0か1か」の世界です。そのため、人間の持つ「よくわからない曖昧さ」が許せなくなりがちだったり、理解できなくなったりという側面はあるかもしれません。
実際世界は曖昧なことで溢れています。不確実性の塊です。ロジカルなことばかりじゃありません。実際僕もPdMになり関わる人が増えて、「よくこんな曖昧な前提や結果で仕事進められるな」と思うことありました。「ロジック破綻してるじゃん」、と思うこともありました。
でもそういう時はこの記事を思い出して、「経験していることの差による差分があるんだな、みんな経験してること違うもんな」と理解してください。

あとコンテキストスイッチの切替も苦手になりがちだと思います。エンジニアは一つのことを集中して考える時間が取れる仕事だし、その時間をとるべき仕事です。それゆえの深い思考が得意にならざるをえない。これがエンジニアリング以外でも役に立つ場面もあるけど、足かせになる場合もあります。
複数のコンテキストを切り替えなければいけない場面とか。実際PdMも事業責任者も同時並行作業が多いです。僕もなれるまで大変だった記憶。

この弱点になりそうなことは、PdMや事業責任者になる場合にボトルネックになりそうなことを想定して書きました。
しかし考えてみれば、生成AIを活用した開発でも上記は壁になってきそうですよね。生成AIは結構曖昧だし、エージェント使って開発してると同時並行で考える機会が増えて、待ち時間とかも増えて、ずっと集中してると言う感じでも無かったりします。AIエージェントを活用した開発は今までと違う疲労感だ、みたいな話もよく聞きます。構造が変化していってるのでしょうね。

エンジニアも「会議が細切れに入ると集中力が切れる」とか言ってられない世界線が来るかもしれませんね。

生成AIも人も嘘つくし、でも最終的なアウトプットは自分の責任。

あとがき

エンジニアの仕事の特性上、強制的に伸びやすい能力があるよね、という話でした。 実際に僕もエンジニアからPdM、事業責任者になったわけですが、エンジニア時代に身についた考え方だったり、手癖に大いに助けられています。
そして裏テーマとしては、生成AI以前と以後でこの構造はどう変わるのか？ということも念頭に置いていました。

AIエージェントを活用するコーディングが主流になると、これらのいくつかの要素は獲得しにくくなるのかもしれません。そうすると「ミドルエンジニアになるまでの時間は半分になるけど、シニアになるまでの時間は3倍かかる」みたいな未来になりそうです。
シニアになるには、思い詰めて考える贅沢な時間の累積が大事だと思うんですよね。思考力を強制的にトレーニングされるみたいな時間。深く長く考える時間。生成AIを活用していくと、そのような「悩む時間」が少なくてもミドルになれてしまう環境になると思うのです。
しかし答えっぽいものへのアクセスが容易になったら、人はそれ以上考えません。答えが分からなくて動かないから仕方なく考えるのです。これは強制される構造が大事だという主張です。
オートマ全盛の時代にマニュアル訓練したくないですからね。訓練してると思わずに訓練できていたことは幸せなんだろうと思います。

答えがない状況に耐える力は失われていくんだろうなと思います。

思考力を強制的にトレーニングされる時間を過ごさざるを得なかった「エンジニア」という仕事は、何者でもない、天才ではない人間が、なんとか自分をトレーニングして這い上がるための機会を提供していたと思うのです。 もちろんそこには苦しみは伴うし時間も一定かかるけれども、苦しみなくして人は変わらない。
そして適度に苦しめられながら継続できるかどうかというのは、どういう構造の中に身を置けばいいのかという話なのです。
人間は弱い。継続できないという意味でもメンタルに限界があるという意味でも弱いから。それでも適度に苦しめられながら継続できる構造に身を置くことが大事だと思います。

すこしふわふわした話もします。
この文章で書いているような、「従来的なエンジニアとしての訓練」をしなくても、生成AIを活用してデリバリーまで一貫してできるようになると、いろんな人がミドルエンジニアに類する認知を獲得することになるんのだろうなと考えます。ある意味エンジニアが独占していた具体と抽象の行き来が一部民主化される。そうすると何が起こるのだろうか。他の職種がシニアになりやすくなるかも？いや、他の職種においてもシニアまでの道のりは倍になる？
結果としてどの職種にとってもシニアになる近道は、「従来的なエンジニアとしての訓練」に近いことをすることになったりして。

でもこういう考え方もあるかも。AIでコーディングが楽になった時間を使って、あえてより複雑な「事業（Business）」という難題に挑むのが、次世代のシニアエンジニアへの近道なのかもしれません。「Dev x PM x PL」を全部やる。それが、思考力を鍛え続けるための新しい道場になるはずです。

昔は環境構築が鬼だった話とかも入れたかったけど、うまく組み込めなかった。

本文章は「Developers Summit 2026」に向けての観測気球ですので、ご意見ご感想お待ちしております。
エンジニアだけじゃないよとか、エンジニアの中でも濃淡あるよとか、他の職種だとこういうのあるよとかあればその辺りもご意見ご発信お願いいたします。