AI時代に、受託開発エンジニアはどう動くか
AIのおかげで、コードを書くスピードは驚くほど上がった。要件を伝えれば画面とロジックが組み上がり、テストまで書いてくれる。 以前なら数日かかっていた作業が、数時間で終わる。
便利になった一方で、「この仕事は、そのうち需要がなくなってしまうのではないか？」というような不安を抱えているエンジニアも多いだろう。
私も受託開発で生計を立てている一人として、同じ不安を感じている。
この記事では、その不安を分解して、どう備えるかを考えてみたい。
減る仕事、残る仕事
一番影響を受けるのは、画面の前で完結し、成果物だけで評価される仕事だろう。
仕様を受けとり、その通りに作り納品する。
これはAIが最も得意とするので、人がやる必要がなくなっていく。
参考になるのは、いまブルーカラーの賃金が上がっている現象で、その理由は大きく2つが考えられる。
- （いまはまだ）AIが物理世界にそれほど進出していない
- 人口が減り、人手が足りない
つまり、その価値の源泉は「その場にいないとできない」ことと、「代わりがいない」ということ。
エンジニアやホワイトカラーの仕事に置き換えると、テキストになっていない業務の暗黙知の把握、判断して責任を取ることや、なにを解決するかの課題を決定する、などは価値を維持しつづけるはず。
3~5年後、どうなっているか？を考えると、実装するだけの仕事は激減し、何を実現するか？の上流工程と、業界特化の仕事が残ると予想する。
3〜5年後を見据えて、どう動くか
AI時代のキャリア論でよく出てくるのが、「自社プロダクトを持つ」という施策だ。
理屈としては正しいと思う。
ただ、プロダクトで食べられるようになるには時間がかかるし、新規事業の収益の予測は難しい。
その間に、受託の稼ぎ口のほうが先に細っていくかもしれない。受託とプロダクトは同じ自分の時間を奪い合うので、その間に谷ができてしまう。
一つの仮説：受託とプロダクトをつなげる
動き方の一つの考えとして、受託とプロダクトを別々の賭けにせず、つなげてみるという案がある。
- 受託で現場に入り、1社の困りごとを深く知る
- その困りごとを小さなツールにして、受託の中で使ってみる
- 同じ困りごとを抱える人が、外にもいるかを探す
- いれば、プロダクトとして届ける
うまく回れば、受託はプロダクトの種を拾う場になり、プロダクトは受託を楽にする道具になる。
ただ、これは新規事業の立ち上げのルートの一つでしかなく、実際にやってみないと分からないことが多い。
仮説を検証する
少なくとも次の不確実な点をクリアしていく必要があると考える。
- 1社の困りごとは、他の会社にもあるのか
- 受託で作ったものを、外に出せるのか（権利や守秘義務）
- 汎用化の手間とコストがどのくらいかかるのか
- 知らない相手に売れるのか（作ることと売ることは別の能力）
どれも考えるだけでは答えが出ない。小さく試しながら確かめていくしかない。
まとめ
AIで作ることが安くなるなら、売るのはコードではなく、現場の暗黙知をつかみ、何を解くかを決めて、責任を持つことだと思う。
まだAIが浸透していない、非効率な現場に入り、AIとプロダクトで効率化する。受託とプロダクトをうまくつなげられるかは、まだ分からない。いまは、この形を試している途中だ。
3年後にこの記事を読み返して、答え合わせをしてみたい。