安全に進んでいるのに、チームは学んでいるのか
私たちの組織では、四半期に一度、全員のメンバーが対面で集まるイベントを実施しています。
2026年度1QではOSTを実施しました。その中で「AI駆動開発で開発が面白くなくなった」というテーマが出ました。
AI駆動開発によって、開発は確かに速くなりました。今までよりも早く動くものを作れるし、詰まったところもAIと一緒に突破できる。開発者にもチームにも、良い変化になると思っていました。
それなのに、「開発が面白くなくなった」という言葉が出てきました。しかも、そのテーマで話してみると、思った以上に場が盛り上がりました。つまり、一人だけの特殊な感想ではなく、複数のメンバーがどこかで感じていた違和感だったのだと思います。
「面白さ」はどこにあったのか
話していく中で、開発の面白さには「問題を打開できた」という感覚と、「理解できた」という感覚が大きかったのではないか、という話になりました。
その過程の中に、開発の面白さがあったのだと思います。単にコードを書くことが好きというだけではなく、「自分で前に進めた」「チームで突破できた」という感覚が大きかったのかもしれません。
これは、自己決定理論でいう、『自律性・有能感・関係性』に近い話だと思います。自分で決めている感覚がある。できるようになっている感覚がある。誰かと一緒に進んでいる感覚がある。そうしたものが、開発の楽しさを支えていたのではないかと思いました。
話を聞くと、AI駆動開発の初期にKIROなどでバイブコーディングしていた頃は、楽しい感覚があったようです。
AIとやり取りしながら、動くものを作って、詰まっていたところが動き出す。分からなかったことが少しずつ理解できる。その手触りが楽しかった、という意見でした。コーディングそのものというより、手触りのあるモノづくりの体験が楽しかったのだと思います。
ただ、バイブコーディングの進め方には品質や設計の不安もありました。
特に、ジュニアメンバーが多いチームで、受託案件として一定品質を守りながら開発を進めるには、自由にAIを使って作っていけばよい、とはなかなか言えません。エンタープライズの現場で、チームとしてAIを使う以上、AIの出力をそのまま信じるわけにもいかず、一定ガードレールの整備は必要でした。
ガードレールを整えた結果、何が起きたのか
だから、ガードレールやルールをかなり整備しました。
計画、設計、実装、テスト、レビューの流れを整理し、Claude Codeをどう使うかもある程度決めました。バックログと画面、DB、デザインの整合性を一部自動でチェックしながら進めるフローを作成しました。
実装に関しても、計画 → 要件定義 → テストケース作成 → 実装 → テスト → リファクタリングと、細かくフェーズを切りながらAIの作業を人も確認しながら進めるフローを作成しました。
実装したらテストし、レビューする。問題があれば戻す。そういう検査と適応の流れを、ジュニアメンバーでも迷わず回せるようにしたかったからです。
この判断自体は、今でも間違っていたとは思っていません。実際、手戻りは減り、一定のスピードで開発ができる手ごたえはあります。ジュニアメンバーでも一定品質で案件を進めやすくなったと思います。
ガードレールを作ったことで、開発は安全に進むようになりました。
でも、その一方で、開発者が自分で判断する余白が減りました。
モブワークでは
・3人でAIが動いている画面を眺めている。
・処理が終わる。
・出力を見て、「まあ問題なさそうですね」と確認する。
・そして次へ進む。
こういった流れが続くことが多くなってきました。そうなるとつらいです。モブで集まっているのに、チームで考えている感じがしない。同じ画面を見ているのに、問いが生まれていない。議論しているというより、AIの処理を一緒に監視している感覚に近いです。
もちろん、すべてがそうだったわけではありません。うまく議論できている場面もあります。それでも、「ただ見ている時間」が増えると、開発している感覚は薄くなります。自分で問題を打開した感じも、理解が深まった感じも得づらく、だんだん「作っている」というより、「処理を進めている」感覚に近づいていきます。
私がショックだったのは、AI駆動開発そのものではありません。
私はもともとメンバーが自律的に考え、チームで創造性を発揮できるようにしたくて、アジャイルのマネジメントを学んできました。
ウォーターフォール的な開発の中で、もっとクリエイティブに仕事を進めたいと思っていました。決められたものを決められた通りに作るだけではなく、チームで考え、変化に適応し、よりよいものを作っていく。そういう状態を目指したくて、アジャイルを学び、実践してきたつもりです。
その先に見えたものが、チェックシート通りに動くマシンのような働き方だった。
大げさに言えば、自分が目指していたアジャイルの先に、ディストピアが見えてしまった感覚でした。
低位安定の罠から抜けるには
今回の状態を、私は「低位安定の罠」と捉えています。
進捗は出て、品質も一定保てています。
だから、一見すると開発はうまく進んでいるように見えます。
ただ、長期的に見ると、メンバーの判断力や学習意欲が育ちにくくなっているかもしれません。そうなると、短期的には進んでいても、チームとしての伸びしろは小さくなってしまう。ただし、短期的には成果が出ているので、その問題に気づきづらいです。
安全に進んでいることと、チームが学習していることは同じではありません。今回、一番引っかかったのはそこでした。
AI駆動開発では、ガードレールやチェックシートは必要です。特に、大企業や受託案件、ジュニアメンバーが多いチームでは、自由にやってみようだけでは進められません。品質も守る必要がありますし、顧客への説明責任もあります。だから、型を作ること自体は自然です。
ただ、その型を外から与え続けるだけだと、チームは低い位置で安定してしまう気がしています。
ではどうするか。
今考えているのは、下記3点になります。
1．ガードレールをチームで育てていく
ガードレールの修正自体をメンバーに渡していくことです。ツール・チェックシートを「守るもの」ではなく、「自分たちで育てるもの」に変えていく。
このチェックは本当に必要なのか。この順番で進める意味はあるのか。
AIに任せ、人が考えるべきところはどこか。
そうした問いを、メンバー自身が持てるようにしたいと思っています。
2.スクラムマスターとの1on1
また、スクラムマスターとメンバーの1on1も定期的に実施しながら、個人として何をやりたいのか、どこに困っているのか、何に意味を感じるのかを言語化していきたいです。
チームとして、自分たちはどうなっていきたいのか、このプロダクトをどうしたいのか、どんな開発をしたいのかを話していく必要があると思っています。ただし、いきなりチームでの問いを出しても難しそうなので、1on1で個人的な動機を引き出しながら徐々にチームのカラーを作っていければと思います。
3.要件/ビジネスへの染み出し
仮説検証活動やビジネス上のインパクトなどをどう作れるか、どう寄与できるか？等、開発メンバーのモノづくりの範囲をもっと広げていけるように促していければと思っています。
上記3点はいずれも学習がキーになると思っています。
AI駆動開発における学習とは、単にプロンプトがうまくなることだけではありません。決められたフローを効率よく回せるようになることだけでもありません。
今のルールを前提に改善するだけではなく、その前提自体を問い直せること。いわゆるダブルループ学習のように、開発の進め方そのものをチームで変えられることが重要となります。
ダブルループ学習は自分たち自身を一歩引いてメタ認知することが非常に重要になります。この点はスクラムマスターのコーチングの動きが重要になります。
AI駆動開発をチームでうまく実施するには、開発のフローを整理したり、CLAUDE.mdやスキルを整理したりする以上に、チームとどう向き合うか？という点が問われていると感じました。
まだ答えは見えていませんが、引き続き探究を深めていきたいと思っています。
