2025年4月14日

2025年現在、AI開発支援が組織に与える現実的なインパクト

import LinkCard from ’../../components/LinkCard.astro’;

日本でもすでに動きは起こっているので整理します。

開発人材・外注ニーズの変化と凋落

簡単なことはAIに任せれば良い、ジュニアレベルのエンジニアは不要になるとよく言われています。

ここで、どのような業務が任せられるかもう少し分解して具体的に考えてみましょう。

以下のような部分を委託することは以前からよく行われてきました。

これらはすべて、現在のAIが得意する領域であり、すでに実務で取り入れられ、高速で解決されています。

したがって、以下の採用は大きく抑制されます。

使い捨てのスクリプト、社内用の管理ツールが容易に作成できます。

開発者は定義的にも他者のために効率化をしますが、意外と自分たちの効率化ツールを作らないものです。(feature factoryの罠)

生成AIそのものだけではなく、生成AIで作ったミニツールにより、人手で行っていたものが効率化されます。そして人手で行っているようなものはあまり難度が高くない傾向にあることから、ニーズが変わります

AIにより開発できる機能の分量が増えれば増えるほど、リリースプロセス全体がボトルネックになります。

もしリリース頻度を増やせず、複数のものをまとめてリリースすることになれば災害が起こります。アイテムごとの障害率を考えれば、まとめることで障害確率は当然増えますし、組み合わさった新しい障害が生じることもあります。原因特定が難しくなり時間がかかりることもあれば、ロールバックが難しくもなります。

残念ながらほぼすべての日本企業はリリースが貧弱であり、基本中の基本であるロールバックすら期待される水準に達していないことが多いようです。

リリースをより速く、より頻度を増やし、より安全にするには以下のようものを手に入れる努力が必要です

デプロイとリリースの分離、フラグによるコントロール、セグメンテーションとステージドロールアウト、それらごとのモニタリング、自動ロールバック、GitHubフローに類するブランチモデル、CI/CDの高速化…

上記の概念を聞いたことがないなら、それだけ差がついているということでしょう。これらを導入するには、工数も時間も技術力も優先順位変更も必要です。

一方、VercelやCloudflareを基盤としているごく最近のスタートアップなら、基盤に組み込まれているので容易でしょう。

E2E含めた自動テストの拡張が必須です。外部の会社にQA作業を委託している企業が多いようですが、手動テストでは間に合わなくなるでしょう。

顧客へのリリースとコミュニケーションプロセス改善、文面作成プロセスの効率化、開発以外の部分の単純化、慣性の打破、なにより意思

リリース改善はプロセス改善であり、人間に関わる難しい問題です。ここで実力に差が生まれます。

組織の中には、開発者ほどではなくとも時折プログラミングがタスクになる人がいます。

このような人たちはプログラミングが専門というわけではないですが素養がある傾向にあります。そして社内受託に近く、極小の人数で評価されないわりに多くの要求に苦しんでいます。

こんなときAI支援によりプログラムやツールをサクサク作れれば効率化が見込めます。開発とその他の狭間でボールが落ちがちなので支援できると良いですね。

個人がAIを使うのは簡単ですが、組織的な変化によって初めて大きな成果が生まれます。気づいて動きましょう