BLOG

はじめに

こんにちは、Code Chrysalisでカリキュラム開発のR&Dを担当しているSoichiroです。

今回は、日々のR&Dを通して考えるようになった、「AIを使った開発の本質って、本当に開発速度を上げることなのだろうか？」という問いを共有します。

昨今、AIエージェントコーディングの話になると、よく聞かれるのが「開発速度が何倍になった」「少人数でもプロダクトを作れるようになった」という話です。

もちろん、それ自体は素晴らしい変化です。これまで数週間かかっていたものを数日で形にできるなら、開発の可能性は大きく広がります。

しかし、ここで一度立ち止まって考えてみたいことがあります。

開発速度が上がれば、本当にユーザーの問題は解決され、ユーザーは幸せになるのでしょうか。

速く作ることと、価値のあるものを作ることは、必ずしも同じではありません。むしろ、誰もが大量のソフトウェアや機能を作れるようになるからこそ、ユーザーに別の負担を生んでしまう可能性もあります。

この記事では、「ユーザーにとって何がよいのか」という視点から、AIエージェントコーディングと、これからのソフトウェア開発について考えてみます。

---

AIは「作るコスト」を下げた

GitHubが行った実験では、Copilotを使った開発者は、指定されたJavaScriptの課題を平均55％速く完了しました。

一方、METRが熟練OSS開発者を対象に行った実験では、AIを使うことで作業時間が19％増えました。AIが常に開発を速くするとは限りませんが、「仕様が比較的明確なものを形にするコスト」が下がっていることは確かです。

しかし、これはあくまで提供側の視点です。

作れるソフトウェアや機能が増えれば、ユーザーはそれらを比較し、選び、操作を覚え、既存の業務へ組み込み、アップデートに適応し続けなければなりません。

つまりAIは、提供側の開発コストを下げる一方で、ユーザー側の選択・学習・運用コストを上げる可能性があります。

「Feature Fatigue」の研究でも、購入前には多機能な製品が魅力的に見えても、実際の利用時には複雑さが満足度を下げることが示されています。研究を見る

便利な機能も、増えすぎれば負債になります。

---

作れるからこそ、作らない判断が必要になる

ソフトウェア開発の目的は、コードや機能を増やすことではありません。ユーザーが抱えている問題を解決し、状態をより良くすることです。

極端に言えば、100個の機能を作る必要はありません。たった一つでも、重要な問題を解決できればよいのです。

AIは正しいものを速く作れるようにしました。しかし同時に、間違ったものを高速かつ大量に作ることも可能にしました。

さらに、すでに問題が明確で、解決方法も簡単に思いつくものであれば、ユーザー自身がAIを使って解決できる場面も増えていきます。

「このデータを一覧にしたい」「毎週の集計を自動化したい」「社内情報を検索できるようにしたい」といった課題なら、既製品を探さなくても、AIと一緒に小さなツールやワークフローを作れるかもしれません。

そうなると、提供側がユーザーから言われた機能をそのまま実装することの価値は、相対的に下がっていきます。

だからこそ、これからは「何を作れるか」以上に、次の判断が重要になります。

1. その要求は、本当に解くべき問題なのか
2. ユーザー自身では解決できない問題は何か
3. ソフトウェアを作らずに解決できないか
4. どの機能をあえて作らないのか
5. 作った結果、ユーザーの行動や成果は変わったのか

作ることが簡単になるほど、作らない判断は難しく、価値のある仕事になります。

そして、分かりやすい問題をユーザー自身が解決できるようになるほど、ソフトウェアを提供する側の価値は、ユーザーから与えられた問題を解くことから、ユーザー自身もまだ気づいていない問題を発見することへ移っていくのではないでしょうか。

---

ユーザーも、自分の本当の問題を知らない

ユーザーは自分の業務には詳しくても、問題の構造まで理解しているとは限りません。

例えば「ダッシュボードが欲しい」と言われたとします。

しかし、本当の問題は画面がないことではなく、データ更新の遅さかもしれません。部署ごとに指標の定義が違うことや、誰が意思決定するのか決まっていないことが原因かもしれません。

ここで要求どおりにダッシュボードを作れば、「依頼されたもの」は完成します。しかし、本当の問題は残ったままです。

Nielsen Norman Groupが実際のユーザーとAIによる仮想ユーザーを比較した調査でも、AIは一般的なニーズを大量に挙げられる一方、現実の行動や優先順位を浅くしか捉えられませんでした。調査を見る

必要なのは、ユーザーの言葉を無視することではありません。それを最終回答として額面どおりに受け取らず、実際の行動、制約、データ、回避策と照らし合わせることです。

ユーザー自身も気づいていない問題を、ユーザーと一緒に発見する必要があります。

---

AIで高速化するのは「問題の学習」

AIを使う目的を、実装の時間短縮だけに置くべきではありません。

重要なのは、仮説を試作品にし、ユーザーに触ってもらい、その反応から問題の捉え方を更新することです。

つまり短縮すべきなのは、次の時間です。

1. 仮説を検証できるまでの時間
2. 本当の問題を学ぶまでの時間
3. ユーザーの状態が改善するまでの時間

正しい答えを一発で作るのではなく、間違いから素早く学ぶ。AIは、そのための実験装置として使うべきです。

---

なぜProduct Manager・Product Designer・Developersの3ロールが必要なのか

この開発を一つの専門性だけで実現するのは困難です。

PDは、ユーザーの発言だけでなく、行動や感情、環境、回避策を観察し、まだ言語化されていない問題を探索します。

PMは、発見された問題のうち何に取り組むのかを判断し、何を作るか以上に、何を作らないかを決めます。

Devsは、要求された機能を実装するだけではありません。最小の実装で仮説を検証し、技術だからこそ可能になる新しい解決方法を提示します。

ただし、これは「PDが考え、PMが決め、Devsが作る」という一方向の分業ではありません。

三者が発見、判断、実装、検証を往復し、得られた事実から問題を何度も定義し直す。そのループ全体が、これからの開発チームに必要な能力です。

---

おわりに

AIによって、作ることはこれからもっと簡単になります。

そんな時代だからこそ、AIを使って大量のコードを生成できる人ではなく、作る前に問い、作らないものを決め、まずは最小限に作って確かめる。そして、その結果からもう一度問い直せる。そんな人たちを育てたいと考えています。

AI時代の開発速度とは、コードを書く速度ではなく、ユーザーの問題について学習する速度なのではないか。

という、カリキュラム開発のR&D中にふと思った、よもやま話でした。

みなさんはどう思いますか？