AIが苦手なエンジニア、実はスクラムが苦手なだけ説

はじめに

って露骨にタイトル狙ってすみません、が結構スジはいい気がするんですよね...ってことで許してください。
ということで。

AIコーディングを日常的に使っているのですが、

• 技術力は高くて経験年数もある。なのにAIを使いこなせないエンジニアがいる
• 逆に、経験が浅くても自然にAIを使いこなしている人がいる

この差は一体なんなのかなーと思うことが多々ありました。

※ここで「AIを使える」とは、Claude CodeやCursorが単に使えることではなくて、実際に高い生産性を出すまで使いこなしている状態を指すものとします。

いくら「こんなに早く実装できた！」とかメリットを聞いても「もうエンジニア不要では？」とか危機感を煽られてもなんだかAIを使いこなせない、もうちょっというとAIを「また新しい技術トレンドが来た」程度にしか受け取っていない人が一定数います。

なぜだろう...と日々悶々としていたのですが、最近何周目かのスクラムガイド読み合わせ会をやるうちに

「AIが苦手なエンジニア、実はスクラムが苦手なだけ説」

タイトル文言だと狙いすぎて伝わらないのできちんと言えば「AIコーディングが苦手なエンジニアは、実はスクラム開発も苦手なのではないか」

という仮説で言語化できるのではないか？？とひらめきました。

果たして、この説は成立するのか。状況証拠を積み上げて検証？妄想？してみたいと思います。

状況証拠① AIコーディングの本質は「実装」ではなく「探索」

まず、AIを「速い実装ツール」だと思っている人はここで認識がズレていて実際のAIコーディングとは、こういう作業の繰り返しです。

曖昧な指示を出す
  → 出力を評価する
  → 軌道修正する
  → また投げる
  → 繰り返す

本質は探索問題であって、実装問題ではありません。AIコーディングとは

「どう書くか」より「どこを探索すべきか」

という、ゴールがまだぼやけている状態で動き始め、対話しながら収束させていく作業です。

普段AIエージェントを活用して開発されている方は、おそらくここに異論ないと思います。

状況証拠② AIが苦手な人には、ある共通点がある（気がする）

AIを使いこなせない方を観察しますと、

• 「仕様を固めてから作業したい・AIにお願いしたい」
• 「そもそも仕様が曖昧なまま進めるのは気持ち悪い」
• 「AIエージェントは嘘をついたりする、一発で正しいものを出してほしい」
• 「わからないことをAIに聞くという意味がわからない」

というマインドが強いのではと感じることがありました。つまりエンジニアとしての能力が低いわけではなくて逆に個人としての実装能力が高い、もしくは対象領域の解像度が非常に高い、ただAI時代でもこれまでの成功パターンと同じ開発スタイルを続けている、のではと。

これは例えると ゲームのルールが変わったのに、前のゲームの戦略を使っている なのではないかと。

逆にAIを自然に使いこなしている人には、

• 漠然とした状況でも動き始められる
• 「とりあえず試す」に抵抗がない
• 失敗を情報として扱える
• ゴールを対話しながら定義できる

が自然とできている...そうこれどっか（スクラム）で見たましたよねと。

状況証拠③ スクラムの本質と、完全に一致する

スクラムの本質とは、フレームワークで定義されるデイリースクラムやスプリントレビューのようなイベントを実施することではないです。

本質は、

• 完全な仕様がなくても動き始める
• 小さく試して、フィードバックを得る
• 仮説を修正しながら収束させる

という繰り返し可能な作業プロセスのループにあります。
これはAIコーディングの開発プロセスと比べると非常に近いのではないでしょうか？？？

AIコーディングが得意な人	スクラムの本質
不確実でも動き始める	完全仕様がなくても動く
とりあえず試す	小さく試してフィードバックを得る
失敗を情報にする	仮説を修正しながら収束させる
ゴールを対話で定義する	反復しながら方向を決める

ただしここで「スクラム経験者」と「スクラムが身についている人」は別物です。

• スクラム経験者 ≠ スクラムのマインドセットが身についている人

たとえば「スクラムやってるけどAIコーディングは苦手です」という方もいらっしゃるかもしれないですが、それは多分「形式だけスクラム」をやっているのではと思われます。

形式だけスクラム	本質スクラム
手順を守る	不確実性を前提にする
計画通りに進める	仮説を持って動く
スプリントをこなす	小さく試してフィードバックを得る
完全なバックログを作る	まず動かして修正する

例えば経験を積んだスクラムチームであれば、詳細な仕様書やカンバンなどのタスク管理ツールも不要、なんなら単にパワポ１枚でもスプリントは有効に機能します。そういうチームでの経験が重要です。

こうやって言語化すると普段のAIコーディングでは、例えるなら「一人で１日スプリントのスクラム」を高速で回している感覚があるのではないでしょうか？？

仮説を立てる          ← スプリント計画
  → AIに投げる        ← スプリント実行
  → 出力を評価する    ← スプリントレビュー
  → 修正する          ← レトロスペクティブ
  → 繰り返す

人間のチームでやるスクラムと比べると一人AIスクラムは「実装待ち」がなくなった結果、スプリントのベロシティに対するボトルネックが変わったという話はまた別のお話。

以前のボトルネック	今のボトルネック
実装速度	問題設定の精度
コード量	評価と収束の速さ
手作業デバッグ	探索の方向感覚

判定：説、ほぼ成立。ただし条件付き。

問い	判定
AIコーディングが苦手な原因は技術力？	❌
AIコーディングが苦手な原因はITリテラシー？	❌
スクラム経験者はAIコーディングが得意？	△ 形式スクラムだけなら関係ない
スクラムのマインドセットがある人はAIコーディングが得意？	✅ おそらくYes

AIコーディング活用への壁は技術ではなくシンプルに開発に対するゲームルールの変更に気づけるか＆順応できるかで、そのゲームを攻略するにはスクラムのマインドセットを学ぶほうが早いかもしれないという結論に達しました。

ただし、スプリントをチーム作業に取り入れるのがAIエージェント活用への道という簡単なロジックではなく、スプリントでのメイン作業となっていた「実装待ち」が時間的な制約を受けなり先の比較のようにボトルネックが変わってしまったため、チーム開発でスクラムを適用すべきかには一定の疑問はあります。

問い	判定
チームスクラムがAI時代に有効？	⚠️ 別の難しさがある

ただ、スクラムを学ぶことはおそらくAIエージェント時代にも有効で、むしろプログラミングのような領域ではなく

• デザイン思考のワークショップ
• スポーツの戦術的なふりかえり

のようなむしろあえてエンジニアリング以外の文脈で学んだほうが、純粋にマインドセットだけが鍛えられるのかもしれません。

ということで、スクラムはやっぱり大正義 だったとの結びで。