はじめに
どうも。鳩胸になりたい文鳥です。
- 「これからは事業がわかるエンジニアが強い」
- 「エンジニアもドメイン知識をつけて職域を超えていこう」
- 「言われたものを作るだけのエンジニアは価値が下がる」
ここ数年AI関連の盛り上がりもあって、こういう話をよく聞くようになりましたねー。
そして自分も、イベントで登壇してこういう話をすることがあります。
如何せん話が自分の長いので喋り足りずブログにしておこうと思いました。
https://note.com/kkun_22/n/n3490cba97f49
イベントレポートはこちら
ちなみに、私はこの手の話で、わりとしっかり失敗しています。
物流企業からエンジニアに転職して、前職の知識を活用してやっていけると思っていたら、
業界のことにはわかるが、たいしたこと任せられへん人
になっていました。
ドメイン知識が実際に成果に結びついているかも？と思い始めたのはそれから数年経って、エンジニアとして一通り業務をこなせるだけのスキルがついてからだったという。
- 役割を広げろ的な話の背景
- 広げたら本当に強くなれるん？
みたいなところを実体験を交えて考えてみたいと思います。
ドメインに精通した人をエンジニアとして配置するとどうなるのか？というのが気になる方には多少参考になるかもしれないです。
自身を社会実験として用いました
ポエムです。
悪しからず。
先にまとめ
長くなったので結論を先に置いておきます。
- 分業を強制していた技術的制約がある程度薄れている状況と言えるので、広げる流れ自体はある種必然
- ただし広さは足し算ではなく掛け算で、1を超えないと元より小さくなる
- ドメイン知識がある状態とは「仕様に責任を持てる状態」であって、知ってるだけは成果0
- 掛け算が成立するかは相性とフィールド次第。GKがシュートを覚えても価値は増えない
- 広げ方は、知識のインプットだけではなく判断の指標をインストールすること
- 両方深くなったら繋がって効いたみたいな感じ
続きが気になる方はどうぞ。
役割を広げろ的な話の背景
AIが出てきたからという話だけではないと思っています。
もっと前から起きている変化の延長線上にある気がするので、そこから整理します。
船に荷物を積む計算を手でやっていた時代
エンジニア以前の話です。
いきなり突拍子もない例ですが、船に荷物を積むときは、船が傾かないように重量とバランスを計算する必要があります。
昔はこれを人が手計算でやっていたそうです。
もちろん私はやってません
私が新卒の頃にはシステムがありました。
新入社員研修の時に「今の若い人は楽でええな、俺らの時代は全部手計算してたからたいへんやったんや」という感想を実際に聞いたのですが、それほど単純な話ではないと思っていました。
実際に起きたことは逆で、もっとしんどくなったのでは、とすら思っています。
手計算がなくなった結果、答えのない抽象的な問題ばかり担当することになった
積み付けそのものは計算できる。
でもそれで楽になった分リソースは削減されるし、残った問題は天候などで遅れが生じた時の意思決定など。
正解が定義されていない判断は誰かがやらないといけない。
つまり作業がシステムに移ると、人間の側に残る仕事の抽象度が上がります。
間違えずに速くできることの価値が、相対的に下がっている
これは計算機が出てきた時からずっと起きていることで、
AIはその延長で、もう一段抽象度が上がったツールだと理解しています。
電卓があっても立式できなければ解けない
数学の問題は、電卓を持っていても立式ができなければ解けません。
むしろ立式できる人の回答スピードと正確性が上がるだけです。
月次決算を事務作業するのでも同じで、やるべきことがわかっている人の仕事は電卓で高速化される。
ツールは、すでに何をすべきか知っている人にバフをかけます。
そもそも何で分業してたんやという話
もう一つ、開発現場側の変化も大きいと思っています。
SIerの文化ではこういう分業があったと思います。
彼方の世界から今もやってるわと言う声も多少聞こえてきました
SE（設計）→ 設計書 → PG（実装）
基本設計書・詳細設計書なるものがあります。
今の感覚だと「なんでわざわざ分けるん」となりますが、当時は合理的だったはずです。
- 検証環境が少ない
- DBを立てるだけでもコストがかかる
- 並列で作業できない
限られた環境を効率よく回すには、工程を切って人を並べるのが正しい。
分業は技術的制約への合理的な回答だったんじゃないかと思うわけですね。
そこにDockerやGitが来ました。
環境は各自で立てられるし、並列で作業してマージできる。
制約が消えると、設計する人と実装する人が同一である方が効率的な場面が増えます。
手戻りが減るし、そもそも詳細な設計書という中間成果物を作るコストが省けるので。
まとめると
- 作業がシステムに移り、人間側に残る仕事の抽象度が上がった
- 分業を強制していた技術的制約が消えた
この2つが重なったところにさらにAIが来ました。
なので「役割を広げよう」とかそういう話が出てくるのは、わりと自然な流れだと思っています。
じゃあ広げたら広げた分だけ強くなれるのかという話になってきます。
リレーで原付に乗れるようになったみたいな話
前章は「分業を強制していた制約が消えた」という話でしたが、
AIが加えたのはもう一段別の変化だと思っています。
専門職はみんな変換プラグを持っていると言う考え方
そもそも分業が発生する構図って、雑ですがこんな感じになってると思っています。
コンサル・SIerにおける社別の分業
コンサル → 課題解決の型と業界知識を提供
SIer → 中間管理
作業会社 → 成果物製造
事業会社における職種の分業
PdM → 価値定義と優先順位を提供
デザイナー → 体験の設計を提供
CS → 顧客の生の声を提供
エンジニア → 動くものを提供
それぞれが自分の領域の言葉を、他の職種が受け取れる形に変換して渡している。
専門職はみんな変換プラグを持っていると捉えてみます。
わかりにくいとか言わんといてー
で、このプラグには相性があって、領域が遠すぎると変換できません。
普段使っている言語帯域や見えてるコンテキストが遠すぎるのでうまくコミュニケーション取れなくなるんですね。この辺は経験ある人もいるんじゃないかと思います
実装が高速化して、専門知識が民主化した
AIがやったことは大きく2つで、作業の高速化と専門知識の民主化だと思っています。
これも前に書いたので繰り返しませんが、
結果として「人に任せるより自分でやった方が早い」の領域が以前より増えた実感があります。
4x100mリレーで全員が原付に乗った
イメージとしてはこうです。
4x100mリレーを走っているとして、全員が原付(AI)に乗れるようになった。100mを走る区間のタイムは基本的に短くなります。
ただ、乗り物に乗ったリレーで一番ロスが出るのはどこかというと、走ってる区間ではなくバトンパスです。
つまり走る速度が上がるほど、バトンパスの相対的な重さが増します。
うまく渡すために減速する必要もあるでしょう。
なら一人で400m走った方が早い場面が出てくるよねという話で、
実装が速くなった分だけ、受け渡しの回数を減らす方が効く場面が増えたということでしょう。
情報のロストも同じ構造で、仕様の意図が一番失われるのは実装中ではなく引き渡しの瞬間だと思っています。
AI時代に生成したドキュメントは分量が多く、スプリントあたりの進捗が増えるために情報の同期はより難しくなります。
とはいえ規模と難易度によります
ここで「じゃあ分業は不要やな」となると乱暴で、
中抜きはいつの時代も不要と言われ続けていますが、2026年現在もコンサルと商社は人気で給料も高いです。
一人で走り切れるのは、規模と難易度が一定の範囲に収まっている時の話。
扱う金額や複雑さが上がると、変換プラグを専業で持っている人の価値は消えません。
属人化のリスクともトレードオフです。
FDEとか出てきた
Forward Deployed Engineer という職種が話題になりました。
簡単に言うと顧客の現場に入り込んで、要件を聞きながらそのまま作る人ですね。
これも間に人を挟まなくていいというだけのシンプルな話だと捉えています。
役割が新しく発明されたというより、バトンパスを消した結果そうなった、という理解です。
じゃあみんなんFDEを理想として目指すべきなのか。
これは人によるかなぁと思ったりします。
で、広げたら強くなれるん？
ここからが本題です。
まず、最適な広さは会社の規模で変わる
一般論として、こういう傾向があると思っています。
小さい会社・事業 → ジェネラルな人が強い
大きい会社・事業 → 細分化されていて深さが要る
人が少なければ一人が複数の役割を持たないと事業が回らないし、
規模が大きくなると、一つの領域を深く掘る人が協業する場面が増える。
なので「広げるべきか」の答えは自分が今どっちの環境にいるかで変わります。
サービスや所属組織が成長する過程で求められる能力が変わると言うのもあります。
両方できますは大谷翔平？
二刀流という言葉もだいぶ馴染み深くなりましたが
あれは例外的だからニュースになっているし莫大なお金が動くのだと思います。
冷静に考えると二刀流を貫くほど、投手として見れば「打撃に時間を取られている選手」、
打者として見れば「投球に時間を取られている選手」になるので、
どちらの評価軸でも一番になりにくくなります。
何かをやるということは、何かを捨てているということですね。
プロになれるか瀬戸際の選手はどちらかに注力した方がプロになれる可能性は高いでしょう。
労働時間は有限なので、むやみやたらに広げるのは深さを捨てているのと同じです。
両方の完成度が高いと言うのはそれだけ希少であり、PalantirやAnthropicでFDEができると言うのは、ただ優秀で五角形がでかい人がいい報酬をもらえると言う話でもあります。
変換幅の大きい変換プラグ持ってると人材価値が高いと言うことでもあると思います。
ただ人材価値は希少性 × 需要の多さで決まるので、希少なだけでは値段がつきません。
掛け算には相性がある：現代サッカーのゴールキーパー
現代サッカーのGKには足元の技術が求められます。
後方から組み立てに参加できるかどうかがチームの強さに直結するので、
足元がフィールドプレーヤー並みのGKで縦パスがうまいと言うのはは非常に優位性を持ち、現代型GKと言われたりします。
これは掛け算がきれいに成立している例です。
GKという相手の攻撃を防ぐという本業に、パス能力という別領域が乗って価値が上乗せされている。
ではGKがシュートを覚えたらどうなるか
同じ「サッカーの技術を広げる」なのに、こちらは価値になりません。
出場できるポジションは1つだけだからです。
GKとFWの両方ができても、試合ではどちらか一方でしか出られない。
シュートが上手いGKは、その能力を発揮する場面が90分間ほぼ来ない。
希少性だけならトップです。
でも需要が無い。
ここが野球との決定的な違いだと思っていて、
野球 → 攻撃と守備が時間で分かれている
→ 能力さえ伸ばせれば両方やるが成立する
サッカー → 攻撃と守備が同時に起きている
→ 立てるポジションは1つ
大谷翔平が成立するのは、野球という競技フィールドのルールとしてそれが成立する。
競技のルールが違うと、同じ掛け算が成立しなくなる。
つまり掛け合わせには相性と競技特性、
近くて相性飲んいい領域を掛けると跳ねるが、遠い領域を掛けても出場枠は増えません。
エンジニアの場合はどうか
遠すぎる例を考えてみます
物売るのがめちゃくちゃ上手いエンジニアがいたとして、
商談中に実装を進められるわけではありません。
商談に出ている時間はコードを書いていないし、
コードを書いている時間は商談に出ていない。同時に立てるポジションは1つです。
プリセールスのように、技術で売ることそのものが職務になっていれば話は別です。
これはGKのビルドアップに近くて、本業の中に相手の領域が組み込まれている形なので。
なので、こう考えられると思います。
①その掛け算は、同じポジションの中で発揮できるか？（新しいポジションとして成立しうるか）
②発揮する場面が実際にあるか？
③労働時間を割った時、一番打点の高いものより成果が出るか？
②について、知識を広げてもそれを執行できる責任を持っていないと発揮する場面は来ません。
③がなかなか厳しくて、労働時間が決まっている以上、
一番高さがあるものに専念した方が成果が出る場面は普通にあります。
そして掛け算の相性が良くても、それだけでは足りません。
掛け算なので、片方が1を超えてこないと元より小さくなるからです。
業界には詳しいが大したこと任せられない人
前章の最後に「掛け算の相性が良くても、それだけでは足りない」と書きました。
実は初期から物流システムを触っていた
エンジニアになった直後、わりと早い段階から物流システムに関わった経験がある。
前職が総合物流企業なので、これは相性が良い配置だったはずです。
前章の言い方をすると、本業の中に相手の領域が組み込まれている理想的な状態ですね。
自分でもこれをねらって転職活動をして自分でも「これは強いはず」と思っていました。
思っていただけでした
ニーズはわかる。でも一人で進められない
倉庫や現場で何が起きているか、ユーザーが何に困っているかはわかります。
この画面の項目が何のために見られているかも、だいたい現場レベルでの想像がつく。
ただ、当時の自分はエンジニアとしてジュニアでした。
- 一人で実装を進め切ることができない
- 結局、先輩の手厚いレビューと承認が必要になる
- そもそも
工数が読めない
業界のことには詳しいのに、たいした仕事を任せられないになっていたのは僕です。
ざっくり工数が読めないのが一番致命的だった
振り返ると、ここが決定的だったと思っています。
ドメイン知識があると、「この機能はこうあるべき」という意見は言えます。
でも工数が読めないと、その意見が判断に使えないんですね。
「こうすべきだと思います」
→「それ、どれくらいかかる？」
→「...どうでしょう」
これだと意思決定のテーブルに自分で乗せることもできません。
やるかやらないかを決めるには、価値とコストの両方が必要なので、
片方しか出せない人の意見は、結局誰かが内容を把握して工数を見積もり直すことになります。
詳しいだけの人は、チームの工数を増やす
ここが一番痛いところで。
自分は「知識を持ち込んでチームに貢献している」ような実感がないわけではなかったです。
でも実際に起きていたのは、
- 仕様の意見を出す → 妥当性を先輩が確認する
- 実装する → 手厚くレビューされる
- 承認をもらう → 先輩の時間が減る
知識があってもその立場で執行できないと、他人の工数を増やす側に回ります。
意見の中身が正しいかどうかとは別の問題で、
承認が必要な状態で出す意見は、それ自体がタスクになるということですね。
掛け算なので、1を超えないと小さくなる
これがタイトルの話です。
ドメイン知識とエンジニアリングの相性は良い。それは間違ってなかった。
でも当時の自分は、
ドメイン知識 1.5 × エンジニアリング 0.4 = 0.6
みたいな状態でした。
掛け算なので、片方が1を割ると掛ける前より小さくなるんですね。
そしてエンジニアリングが半人前だと、他人の承認が必要な人材になるので、
使い所が難しくなります。詳しいのに任せられない、という状態がこれです。
キャリア初期は、普通のエンジニアになるのが最優先
なので今、同じ立場の人に何か言うとしたらこれです。
まず普通のエンジニアになった方がいい
異業種から転職してきた人として、前職の知識を早く活かしたくなっていました。
自分はそうでした。スキルが低いながら差別化できる唯一の持ち物なので、当然だと思います。
ただ専門職である以上、専門領域での実力が一番大事です。
エンジニアとしての成果を出せない状態では、
そもそもエンジニアとしての成果を出すことが難しい。
考えれば当たり前ですね。
今は一貫で走り切れる場面が増えた
そこから数年経って、エンジニアとしては一人前になりつつあると思っています。
そうすると何が起きたかというと、
- 仕様の意見を出しつつ、工数も出せる
- 一人で実装から検証まで走り切れる
このタイミングで、やっと物流の知識が効き始めました。
AIの活用でより効いている感じもあります。
つまり順番が完全に逆だったんですね。
広げたから効いたのではなく、
深くなったから、持っていたものが繋がって効き始めた。
ドメイン知識あるってどういう状態なん
知識を増やせば成果が出るわけではない、というのが前章でした。
ではどういう状態なら成果になるのか。自分の理解はこれです。
ドメイン知識がある状態とは、仕様に責任を持てる状態
知っているだけでは成果0です。
「仕様に責任を持てる」には段階がある
①他の人が決めた仕様で実装ができる
②企画された機能について、細部で「こうあるべき」を定義できる
③自分で企画できる
④顧客にポジティブな影響を出せる
⑤事業成果につながる
①はドメイン知識がなくてもできます。仕様書があってプログラムが分かれば書けるので。
②から先が、ドメイン知識が要求される領域です。
ジュニアの頃の自分は、②の意見は出せるのに①でサポート・承認が必要という
エンジニアとしてはねじれた状態でした。
推進力は信頼
②から⑤に上がるのに必要なものは、知識量に加えて回りとの信頼関係だと思っています。
経験上「この人が決めた仕様なら任せて大丈夫」と思われていないと、
そもそも決める場に呼ばれないこともありますし。
①〜⑤は自分で宣言して上がれるものではなくて、上げる権限は他人が持っていることが多いです。
知識を増やしても、執行できる責任を持っていないと発揮する場面がない
GKがシュートを覚えても出場枠が増えないのと同じで、
決める権限のないところで詳しくなっても、使う場面が来ない。
もちろんマイナスにはなりません。ただ成果にもならないです。
ちょっかい出してくる他部署の人にならんために
じゃあどう広げるか。
知識ではなく、判断の指標をインストールする
事実を覚えるだけだと②に届きません。
回りとのコミュニケーションをとっていく過程でその領域のドメインエキスパートや仕様決定の責任を持っている人が何を根拠にどう判断しているか判断しているかという判断軸から自分にインストールするイメージでコミュニケーションを取ります。
これが入っていると、仕様の細部で迷った時に自分で決められます。
覚えるべきは知識ではなく判断基準、という言い方でもいいかもしれません。
わかるとできるは違うみたいな話だと思います。
できるだけ「やってください」と言われる状態を作ることが円滑に成果を出しながら活躍する領域を増やすコツかなと思います。
自分から取りに行くと毎回説明と説得が要り消耗したりしますが、頼まれる方が何かとスムーズ。
特に歓迎されないやつ
これはやりがちなので書いておきます。
✗「その業務、AIで自動化できるんで巻き取って大丈夫ですよね？」
みたいに相手の仕事を軽視するような広げ方は大体うまく行かないし、
AIであなたの仕事を代替できますは、言ってることは正しくても歓迎されません。
急に否定から入られると相手も反射的に守りに入ります
与えられているポジションで成果を出す
結局これが効くなと思っています。
チームのアウトカムを最大化するという視点で見た時に、
今のポジションで一番効くことをやるのが先で、
その延長で必要になった知識が、結果的に広さになるぐらいがちょうどいいかなと
広げたから効くのではなく、やるべきことをやっていたら信頼が積み上がって勝手に広がっているみたいな状態が理想であると思います。
AIは損害賠償してくれへん
コーディングという作業を移譲したところで、責任は簡単には移せません。
答えのある問題でAIと戦っても勝てない
AIは東大の問題を一瞬で解きます。
でも四則演算で計算機と争っても勝てないのと同じで、
答えのある課題に対してAIと戦っても勝てません。
なので残るのは「何を解くべきか」の方です。
そして重要なのは、プロンプトを書けないと答えには至らないという点で、
これは立式できないと電卓が使えないのと完全に同じ構造だと思っています。
どちらかと言うと必要なのは作問と採点のスキル
具体的に何が残るのかを分解するとこうなると思っています。
①課題設定：そもそも何を解くべきか決める
②作問：どういう問いの形にすればAIが解けるか設計する
③評価指標：何が正解なのかを定義する
④検証：出てきたものが合っているか確かめる
学校の先生の仕事に近いのかなと思いました。
今後どうなっていくかわからないですが少なくとも現状は開発がまともにできるエンジニアは
ソリューションとして深いプロンプトを書けて、AIのアウトプットを承認できる能力があって使い方がうまい人にはバフがかかっている世界線
だと思っています。
システム領域でAIの成果物を判断できるスキルを備えていると言うのはアウトカムを出す上でとても重要なスキルだと思います。
で、承認するには1を超えている必要がある
ここがこの記事の話に戻ってくるところです。
③と④は、その領域で1を超えていないとできません。
何が正解か定義できない人は、AIの出力が正しいかどうかも判断できない。
つまりAI時代に価値が上がっているのは「広く浅く知っている人」ではなく、
承認できる深さを持っている人だと思っています。
専門知識へのアクセスは簡単になりました。
でも承認や責任はまだ代替されていません。
バグ出した損失をAIが補填してくれるようになればその時はまた違う能力が求められるのかなと
おまけ
最後に全然関係ない話をします。
AIと壁打ちしていても、
「馬を美少女にして競争させたら儲かります！ゲーム実装しましょう」みたいな結論には絶対に至りません。
至ったら教えてください
人間の消費行動は、そこまで構造化して整理できるものではないんですね。
なんでこれが刺さるのか誰も説明できないものが、爆発したりするんだと思います。
課題設定のスキルが大事という話をしましたが、
本当に強い課題設定は、論理の外側から出てくるのかもしれないなと思っています。
人間の持つ狂気こそ、AIには超えられない壁なのかもしれません。
みたいなこと最近考えてます。
以上、