これは、AIの時代における自分の立ち位置が気になるミドル〜シニアの開発者たちへ。
IT業界では、尽きることのない議論があります。「AIは開発者を置き換えるのか？」と。私はAluSoftBelのテックリードです。そして、開発者としての視点と、ビジネスのステークホルダーと直接仕事をする立場の視点の両方から、自分の考えを共有したいと思います。ネタバレですが、答えはあなたの予想を裏切るかもしれません。
AI生成コードの“居心地の悪い真実”
はっきり言います。AIモデルが生み出すコードの品質は低いです。ですが、もう一つの面もあります。AIが登場して以来、企業は開発スピードが上がったと感じており、今や「もっと多くの機能を、より速く」と求めています。
これは典型的な利害の衝突を生みます。ビジネスはもっとお金を稼ぎたい。開発者は、後で自分たちの首を絞めないために、保守しやすく品質の高いコードを望む。どちらも正しい。問題は、そのバランスをどう取るかです。
私たちが実際にAIを使う方法：現実のワークフロー
ここからは、私たちの会社で採用したアプローチを順を追って説明します。
フェーズ1：まずMVP — 品質は後で
最初の一歩は、いつだってMVPです。速く、ガチで、品質への配慮ゼロ。目標はただ一つです。売れる動くプロダクトを出すこと。
ええ、技術的負債が積み上がります。ええ、ぐちゃぐちゃです。でも、プロダクトはすぐに本番へ到達し、（なんとか）動く。それで十分です。そこから積み上げられます。プリセールで見せられる、案件をクローズできる、予算を承認してもらえる。
重要な洞察はこうです。MVPは単にデモを提供するだけではありません。強み、弱みが何かを見極めて、深刻な投資が行われる前に進路修正できる、実際に動くプロダクトを提供するのです。
フェーズ2：売ったら、ちゃんと計画する
プロダクトが売れたら、テックリード、ビジネスアナリスト、PMが集まって、現実的な開発計画を作ります。私は技術的な実装を見ます。アナリストはビジネス要件を見ます。これで、もはや当て推量はしません。具体的で現実のケースを扱い、すでにあるものを削り落としていくのです。
同時に、ビジネス側は実際のユーザーフィードバックを集めます。何がうまくいくか、何がダメか、何がストレスなのか。仮説ではなく、実在するケースです。そこからPMとアナリストが、明確な要件と現実的なプロダクトビジョンを備えた適切な仕様書を作ります。そしてその後で初めて本格的な開発が始まります。
フェーズ3：後始末に向き合う
次に来るのは、技術的負債の清掃です。私のケースでは、MVPはまさにvibe-codingそのものでした。AI支援で、監督の目が薄いままの素早いプロトタイピングという意味です。コードは3〜4回書き直され、その過程で、使われないモデル、孤児化したデータベーステーブル、使われないライブラリ、壊れたレガシーコードが残りました。
清掃が終わったら、きちんとしたテックスタックへ分解していきます。実際の設計パターンに基づく構造化されたアーキテクチャへすべてを移していくのです。混沌から秩序へ。これこそが、AIが単純にはできない仕事です。
本当のコスト：メリットとデメリット
❌ デメリット
- 1〜2人にかかる過剰な負担。 誰かが巨大な作業を一人で背負い、普段のリズムから外れ、残業をする必要が出ます。私の場合は——それが私でした。
- 場当たり的に選ばれる技術。 GitHubのスターが数個のライブラリ、実験がそのまま本番で実行される、事前の調査なし。すべてを「大変なやり方」でテストし尽くしたわけです——そしてそれは時間とメンタルを消耗します。
- チームは結局その代償を払う。 MVPの後、チーム全員が集まって、ぐちゃぐちゃになったコードを読み、分解をやり直さなければなりません。「速いスタート」が痛みを遅らせるだけで、消し去るわけではありません。
似たような状況、聞き覚えありませんか？ コメントしてください。MVP後の後始末を、あなたのチームはどうやって回しているのか気になります。
✅ メリット
- ビジネス側は比較的少ない費用で概念実証（PoC）を得られる。 もしアイデアが機能すれば、適切に投資して本物のプロダクトを作れる。ダメなら、損失は最小限。実質的にリーン・スタートアップのモデルをそのまま運用しているのに近いです。
- チームはプロジェクトと投資を得る——そして（正直に言うと）仕事も得られる。 今日の自動化への不安が広がる環境では、この最後の点が、人々が認めている以上に重要です。
- このアプローチで、当社の技術的負債のほぼ全てを解消できました。AIはスタートを加速しましたが、残ったのは人が片付けて、長く使えるものを作ったということです。
それで、AIは開発者を置き換えるの？
私の経験に基づく結論は：いいえ、そして理由があります。
作られるプロダクトの数は増えていくはずです。つまり、作業量も増えます。サイクルはこうなります。AIが素早くMVPを立ち上げる→検証される→ローンチされる——そして結局、どこかの誰かが「スケールしてちゃんと動く」ものを作り込む必要がある。
AIはデータベース設計、インデックスの選定、アーキテクチャパターンの決定、適切なテックスタックの選択の場面でミスをしがちだからです。これらは例外的なケースではありません。真面目なプロダクトの中心そのものです。結局、シニアもジュニアも関係なく、開発者が入ってそれを直し、拡張し、保守します。AIは仕事を生みます。消すわけではありません。
ええ、いま市場が一時的に落ち込んでいて、しばらく続く可能性はあります。でも私の賭けはこうです。経済が再調整される。そして私たちは、ソフトウェア開発とテクノロジーの本格的なブームへ向かっている。
活躍できる開発者は、AIを使うことを拒む人ではありません。AIを使いこなす方法を知っている人です——そして後始末のやり方も知っている人です。
TL;DR
- AIのコード品質は低いが、アイデアを検証するには十分な速さがある
- MVP → 売る → その後ちゃんと作り直すためにvibe-codingを使う
- 「速いスタート」は、本物の開発者にとって現実のオーバーヘッドを生む
- AIはプロダクト数を増やす → 開発者の需要を増やす
- 置き換えではなく、ツールとしてAIを学ぶ
vibe-codedなMVPを出荷しましたか？ 作るのより、後始末の方が時間がかかりましたか？ コメントしてください。戦記（失敗談・学び）を比べましょう。
