ドパガキ駆動開発（DDD）とは？元ネタと許される範囲を解説

Xで拡散した「DDD（ドパガキ駆動開発）」のスライドを見て笑ったあと、自分の開発にも心当たりがあると感じたことはないでしょうか。

ドパガキ駆動開発は、2026年8月に高専キャリアのイベントで発表されたLTのネタで、AIが生成するコードを信用して速度を追えば爆速で開発できる、という冗談めいた開発スタイルを指します。

AIコーディングツールを毎日使う開発者が増えたいま、生成されたコードを読み切らないまま先に進む場面は、誰にとっても身近です。提唱者自身も、ネタとして受け取ってほしいとしたうえで、用途と用法を守って使うよう補足しています。

笑い話で済むかどうかを分けるのは、そのコードを誰が使い、誰が保守するかです。

この記事では、以下の内容を解説します。

• ドパガキ駆動開発の意味と、高専キャリアのLTで生まれた元ネタ
• バイブコーディングとの違い
• ドパガキ駆動開発に当てはまる行動と、笑い話で済まない理由
• どこまで許されるかの線引きと、歯止めをかける7つの対策
• AIに任せきりにした場合のエンジニアの市場価値への影響

AIコーディングツールを日々の業務で使っている現役エンジニアの方に、ネタを楽しみながら開発の質を保つための線の引き方と対策をお伝えしているので、ぜひ参考にしてください。

ドパガキ駆動開発（DDD）とは

ドパガキ駆動開発は、AIコーディングツールが日常になったいま生まれた、ネタとしての開発手法名です。名前の成り立ちと中身は、次の3つに整理できます。

• 「ドパガキ」と「駆動開発」を組み合わせた造語である
• 略称のDDDはドメイン駆動設計のもじりになっている
• AIが生成したコードを信じきって速度を追う開発スタイルを指す

以下、名前の由来から順に、この言葉が何を指しているのかを確かめていきます。

「ドパガキ」と「駆動開発」を組み合わせた造語である

ドパガキは、ドーパミン中毒のガキを略したネットスラングです。ショート動画やSNSのように、すぐに快感が得られる刺激を求め続ける状態を指して使われています。

一方で、駆動開発はTDD（テスト駆動開発）をはじめとする開発手法の名前にならった言い回しです。エンジニアの間では、何を原動力にして開発を進めるかを「〇〇駆動開発」と言い表すネタが、以前から定番として使われてきました。

この2つを合わせたドパガキ駆動開発は、名前のとおりに読めば、「動いた」という快感を原動力にして開発を進めるスタイルを表した造語です。英語では「Dopagaki Driven Development」と表記し、頭文字を取ってDDDと略されます。

参考：hannahilea「Dopamine-driven development (DDD), spite-driven development (SDD), and other DDs」（TDDを起点とする「〇〇駆動開発」の命名慣習）

略称のDDDはドメイン駆動設計のもじりになっている

ソフトウェア開発でDDDといえば、ドメイン駆動設計（Domain-Driven Design）の略として広く知られています。業務の専門家と対話しながら、扱う業務の知識をモデルに落とし込んで設計を進める手法です。

ドパガキ駆動開発は、この定着した略称に同じ3文字を重ねた言葉遊びです。名前を借りているだけで、手法としての関係はありません。

とはいえ、両者の中身を並べると対照がはっきりします。ドメイン駆動設計は業務への理解を積み上げてからコードに反映し、ドパガキ駆動開発は理解を飛ばしてでも速度を優先しています。

AIが生成したコードを信じきって速度を追う開発スタイルを指す

提唱者のスライドでは、ドパガキ駆動開発を、AIが生成するコードをすべて信用して速度を追い求めれば、ソフトウェア開発を爆速で進められるという考え方として紹介しています。実際の開発に置きかえると、次の流れを繰り返す状態です。

1. やりたいことをAIに伝えてコードを生成させる
2. 生成されたコードの中身を読まずに動かす
3. 動いたことを確かめたら、すぐ次の機能に進む

注目したいのは、スライドの「信用」の後ろに（?）が添えられている点です。提唱者自身もXで、LTはネタとして発表したもので、真面目に受け取らないよう補足しています。

X上では、POCや趣味の開発ならみんな自然にやっている、という反応も見られました。全面的にAIを信じろという主張ではなく、多くの開発者に心当たりがある進め方に名前を付けたネタとして読むのが自然でしょう。

ドパガキ駆動開発の元ネタと広まった経緯

ドパガキ駆動開発という言葉は、1本のLTから広まりました。発表から拡散までの流れと、言葉の背景は次のとおりです。

• 高専キャリアのLTで「爆速開発の秘訣」として紹介された
• スライドがXで拡散し、派生ネタが続いた
• 提唱者自身が「現実はそうもいかない」と条件を挙げている
• 「ドーパミン駆動開発」という言い回し自体は以前からある

LTで実際に何が語られたのかを、スライドの内容に沿って見ていきます。

高専キャリアのLTで「爆速開発の秘訣」として紹介された

ドパガキ駆動開発の元ネタは、2026年8月30日に開かれた高専キャリアの夏のイベントで発表されたLTです。発表者は高専生のCrysta1221さんで、X上ではくりすたさんの名前で活動しています。LTのタイトルは「爆速でソフトウェア開発をして他人を驚かせましょう！」でした。

LTでは、まず発表者がその年にリリースした3つのソフトウェアが紹介されています。

そのうえで、同じ年にこれだけの数を作れた理由として示されたのが、ドパガキ駆動開発でした。冒頭のTL;DRからして、AIを使えば爆速で開発できるという一言で締めくくられており、全体が笑いを取りにいく構成のLTです。

参考：Crysta1221「高専キャリア LT 発表内容」（Speaker Deck）

スライドがXで拡散し、派生ネタが続いた

ドパガキ駆動開発が広まったきっかけは、スライドの画像を付けたXへの投稿でした。「#高専キャリア」のハッシュタグとともに拡散し、高専生のコミュニティの外にいる現役エンジニアにも届いています。

拡散のあとには、次のような投稿が相次ぎました。

• 自分の個人開発もドパガキ駆動開発だと名乗る
• AIに任せて作ったものの末路をネタにする
• noteで自分の開発を振り返る記事を書く

このように、ネタとして笑うだけでなく、自分のAIの使い方を重ねて語る人が多かったことが、この言葉の広がり方の特徴です。笑いと同時に心当たりも呼び起こしたため、学生の間のネタで終わらずに広まったと考えられます。

提唱者自身が「現実はそうもいかない」と条件を挙げている

ドパガキ駆動開発を紹介したページのすぐ次で、発表者は「現実はそうもいかない」と続けています。そこで挙げられている条件は2つです。

1つ目は、せめてコードのどこに何があるかは把握しておくことです。コードベースが大きくなるほどファイルの置き場所が分からなくなるため、ある程度はコードの設計を理解しておくべきだと説明しています。

2つ目は、デザインを軽く見ないことです。アプリの顔となるデザインを適当にすると、機能がよくても使ってもらえないとして、事前にモックアップを作っておくよう勧めています。

さらに発表者は、LTの翌日にXで補足を投稿しました。自身はコードチェックやデザイン、ファイル構造を確認したうえで開発していると述べ、場合によっては問題が起きるので、どう正しく使うかは使う人次第だと呼びかけています。

この投稿から、ドパガキ駆動開発は、最低限の把握を人間が手放さない前提で成り立つネタだと分かります。

参考：Crysta1221「高専キャリア LT 発表内容」（Speaker Deck）

「ドーパミン駆動開発」という言い回し自体は以前からある

ドーパミンを開発の原動力にたとえる言い回しは、英語圏ではAIコーディングが今ほど当たり前になる前から使われていました。

2023年9月にMediumで公開された記事は、Dopamine Driven Developmentを、達成感を味わえるように仕事を組み立てて開発者のやる気を保つ考え方として紹介しています。2024年9月の個人ブログでも、周囲からの注目や称賛を燃料にして作業を進めるやり方を、dopamine-driven developmentと呼んでいます。

どちらも、やる気をどう保つかという動機付けの話で、AIが生成したコードとは関係がありません。ドパガキ駆動開発は、以前からある〇〇駆動開発の言葉遊びに、AIコーディングの時代ならではの「動いた」の快感を重ねた新しいネタなのです。

参考：CriticalProgrammer「Dopamine Driven Development」（Medium）

参考：hannahilea「Dopamine-driven development (DDD), spite-driven development (SDD), and other DDs」

バイブコーディングとの違い

ドパガキ駆動開発とバイブコーディングは、どちらもAIにコードを書かせて開発を進める話なので、同じものとして扱われがちです。ただし、2つの言葉が指しているものは違います。

バイブコーディングは開発の手法に付けられた名前で、ドパガキ駆動開発は、開発している人が速度の快感に流されている状態に付けられた名前です。

それぞれが何を指しているのかを、名付けられた経緯から見ていきましょう。

バイブコーディングはAIとの対話でコードを作る手法を指す

バイブコーディングは、AI研究者のAndrej Karpathy氏が2025年2月にXへの投稿で名付けた言葉です。コードを1行ずつ書く代わりに、やりたいことを自然な言葉でAIに伝え、出てきた結果を見ながら指示を重ねて作っていく進め方を指します。

もともとの説明では、雰囲気に身を任せ、コードが存在することさえ忘れて作る、という書き方がされていました。つまり、生成されたコードを読まないこと自体が、バイブコーディングの定義に含まれています。

ただし、Karpathy氏はこの進め方を、使い捨ての週末プロジェクトで試すものとして紹介していました。読まない代わりに、壊れても困らない範囲で使うという前提は、言葉が広まるにつれて見落とされがちです。

その後、バイブコーディングは英国のコリンズ英語辞典が2025年の今年の言葉に選ぶほど広まり、AIを使った開発全般を指す言葉としても使われるようになりました。

参考：Andrej Karpathy氏のX投稿（2025年2月）

ドパガキ駆動開発は「動いた」の快感に流される状態を指す

ドパガキ駆動開発は、手法ではなく、開発している人の状態に付けられた名前です。AIが生成したコードが動いた瞬間の手応えに乗って、中身を確かめないまま次へ進んでしまう状態を指しています。

同じようにコードを読まない場合でも、両者の違いは、読まないことを自分で選んでいるかどうかにあります。

バイブコーディングは、壊れても困らない範囲に限って、読まないと決めて使う手法です。一方でドパガキ駆動開発は、速度の快感に引っぱられて、読む手間を気づかないうちに飛ばしている状態を表します。

バイブコーディングをしていても、範囲と自覚を保っていればドパガキ駆動開発にはなりません。

反対に、補完されたコードを読まずに受け入れ続ければ、バイブコーディングと名乗っていなくても、ドパガキ駆動開発の状態に入っていきます。

ドパガキ駆動開発に当てはまる5つの行動

ドパガキ駆動開発は、日々の開発の中のありふれた行動として表れます。代表的なものは、次の5つです。

• エラー文をAIに貼っては再生成を繰り返す
• 生成された差分を読まずにコミットする
• 「動いた」ことを完了の基準にしている
• テストもAIに書かせ、通れば安心している
• AIが提案したライブラリをそのまま追加する

どれも、AIを使って開発していれば一度は経験のある行動でしょう。それぞれがどんな場面で起き、どこがドパガキ駆動開発らしいのかを見ていきます。

エラー文をAIに貼っては再生成を繰り返す

エラーが出たらメッセージをそのままAIに貼り付け、返ってきた修正を当てて、もう一度実行します。この往復を、原因を自分で考えないまま何度も繰り返す行動です。

エラー文をAIに渡すこと自体は、調べる時間を減らす使い方として合理的です。問題は、修正の中身を読まずに当てるのを繰り返すところにあります。

何回目かで動いたとしても、何が原因で、どこを直したら解決したのかが手元に残りません。そのため、同じ種類のエラーが再び出たときも、またAIとの往復から始めることになります。

直った手応えが数分ごとに返ってくるので、理解するより往復を回すほうが気持ちよく感じられる点が、ドパガキ駆動開発らしいところです。

生成された差分を読まずにコミットする

AIエージェントに機能の追加を頼むと、複数のファイルにまたがる差分が一度に返ってきます。数百行の差分を前にして、動作だけ確かめてそのままコミットしてしまう行動です。

差分は量が多いほど読まれにくくなります。数行の修正なら目を通せても、ファイルをまたいで書き換えられていると、読む前に気持ちが折れやすいでしょう。その結果、頼んでいない箇所の書き換えや既存の処理の変更が、誰にも気づかれないまま履歴に残ります。

コミットした時点で、そのコードは自分が書いたものとして扱われます。 チーム開発であれば、レビューする人も、作者が中身を理解している前提で読むことになるでしょう。

「動いた」ことを完了の基準にしている

画面に期待どおりの結果が出た時点で、タスクを完了扱いにしてしまう行動です。確かめたのが正常な入力の1パターンだけでも、動いたという事実が完了の合図になってしまいます。

ただ、動くことと正しいことは別の話です。たとえば、次のような場面での振る舞いは、1回動かしただけでは分かりません。

• 空の入力や想定外の値を渡す
• 権限のないユーザーが操作する
• 扱うデータが大量になる

AIが生成したコードは、正常な流れを手早く形にする反面、こうした例外の扱いが抜けている場合があります。動いた瞬間がいちばん手応えを感じる場面だからこそ、完了の基準がそこで止まりやすくなります。

完了の条件を先に決めておかないと、動作確認と受け入れ確認の区別がなくなってしまうでしょう。

参考：note「ドパガキ駆動開発と笑えるうちに...」

テストもAIに書かせ、通れば安心している

実装をAIに書かせたあと、そのテストも同じAIに書かせ、すべて通ったことで大丈夫だと判断する行動です。テストでOKが並ぶと、品質を確かめた気持ちになりやすいでしょう。

ただし、実装を見ながら書かれたテストは、コードが今どう動くかをなぞっただけのものになりがちです。仕様の読み違いが実装にあれば、テストも同じ読み違いを前提に書かれるため、誤りがそのまま通ってしまいます。

さらに、外部とのやり取りをすべてモックに置きかえて、実際には何も検証していないテストが混ざることもあります。

テストが通ったことは、仕様どおりに動くことの証明にはなりません。何を確かめるテストなのかを人間が決めていなければ、テストの数が増えても、確かめられている範囲は広がらないままです。

AIが提案したライブラリをそのまま追加する

AIに実装を頼むと、目的に合いそうなライブラリを提案され、インストールのコマンドまで示されることがあります。その提案を、メンテナンスの状況やライセンスを確かめないまま実行し、依存してしまう行動です。

依存しても問題ないのは、次の条件を満たすライブラリです。

• 最近まで更新が続いている
• ライセンスが利用条件に合っている
• 実在する正しいパッケージである

とくに3つ目は見落としやすいでしょう。AIは、もっともらしいが実在しないパッケージ名を提案することがあり、その名前を第三者が先に登録すれば、悪意のあるコードを入れてしまう攻撃にもつながると指摘されています。

依存先を1つ増やすと、自分が読んでいないコードを丸ごとプロダクトに取り込むことになります。

ドパガキ駆動開発が笑い話で済まない6つの理由

ドパガキ駆動開発は、自分だけで完結しているうちは笑い話で済みます。ところが、仕事のコードで続けると、次の6つの不利益が少しずつ積み重なっていきます。

• 中身を説明できないコードが積み上がる
• 不具合が起きたときに原因を追えない
• 「それらしい」誤りがレビューをすり抜ける
• 脆弱性や不要な依存が紛れ込む
• 保守のコストが後から膨らむ
• エンジニアとしての判断力が育ちにくい

前の5つはプロダクトに、最後の1つは開発者自身にはね返ってくる不利益です。実際の開発で何が起きるのかに沿って、ひとつずつ確かめていきましょう。

中身を説明できないコードが積み上がる

レビューで「この処理はなぜこう書いたのか」と聞かれても、答えられないコードが増えていく状態です。1か所なら問題になりにくくても、機能を足すたびに説明できない部分が重なると、プロダクトの中に、チームの誰も中身を知らない領域ができあがります。

そうなると、改修のたびに影響範囲を見積もれません。どこを触れば何が壊れるのかが分からないので、変更のたびにまたAIに聞き、出てきた修正を信じるしかなくなります。

説明できないコードは、コミットした本人が休んだり異動したりした時点で、誰も手を入れられないコードに変わります。

不具合が起きたときに原因を追えない

本番環境で不具合が起きると、まずログを読み、どの処理がどの順番で動いたのかをたどって原因を絞り込みます。ところが、問題の箇所が中身を理解しないまま取り込んだコードだと、本来どう動くべきなのかの見当がつきません。

障害対応は時間との勝負です。その場でゼロからコードを読み解くことになれば、復旧までの時間はそれだけ延びます。AIに聞けば修正案は出てきますが、本番のデータや設定まで踏まえた答えとは限らず、的外れな修正を重ねて被害を広げることもあるでしょう。

ふだん速く作れていた分の時間を、障害が起きた日にまとめて払うことになります。

「それらしい」誤りがレビューをすり抜ける

AIが生成したコードは、変数名が整い、構造もきれいで、一見すると経験のある人が書いたように見えます。そのため、条件分岐が逆向きのままだったり、境界値の扱いがずれていたりする誤りが、見た目の整い方に隠れてしまいがちです。

この悩みは、多くの開発者に共通するものです。2025年に世界の開発者を対象におこなわれた調査では、AIツールへの不満として最も多かったのが、ほぼ正しいが完全ではない答えを返されることで、回答者の66%が挙げていました。

レビューする側も、ふつうは作者が中身を理解している前提で読んでいます。作者が理解しないまま出したコードでは、レビューする人だけが誤りを見つける最後の確認役になってしまうため、見逃しがそのまま本番に入りやすくなります。

参考：Stack Overflow「2025 Developer Survey」

脆弱性や不要な依存が紛れ込む

AIが生成したコードには、入力値のチェックや権限の確認といった、安全のための処理が抜けていることがあります。

100以上の大規模言語モデルにコードを書かせた検証では、生成されたコードの45%がセキュリティのテストに通らず、新しく大きなモデルほど安全になるという傾向も見られませんでした。管理された課題での結果のため、実際のコードの45%に脆弱性があるという意味ではありませんが、モデルの性能が上がれば自然に解決する問題ではないことが分かります。

加えて、不要な依存パッケージも紛れ込みやすくなります。数行で書ける処理のためにライブラリが追加されると、その分だけ更新の手間と、攻撃を受ける入口が増えるでしょう。

どちらも、動作確認だけでは見つかりません。動くことを完了の基準にしている限り、脆弱性も余計な依存パッケージも、気づかれないまま本番に残り続けます。

参考：Veracode「2025 GenAI Code Security Report」

保守のコストが後から膨らむ

AIは頼まれた機能をその場で形にするのが得意な反面、既存のコードとの整合までは気にかけないことがあります。その結果、似た処理が別の場所に重複して書かれたり、依頼のたびに書き方がばらばらになったりします。

こうしたズレは、作った直後には問題になりません。困るのは数ヶ月後、仕様変更で同じ修正を何か所にも入れる必要が出たときや、新しく入ったメンバーがコードを読もうとしたときです。速く作れた分の時間が、改修のたびに少しずつ利子をつけて戻ってくるイメージです。

コードを生成する速さが、チームがコードを理解する速さを上回ると、その差がそのまま保守の負担として積み上がります。

エンジニアとしての判断力が育ちにくい

設計の良し悪しを見分ける力や、不具合の原因に当たりをつける力は、自分で考えて決め、ときには失敗した経験の積み重ねで育ちます。ドパガキ駆動開発では、その考えて決める部分をAIに渡したまま進むため、機能は増えても判断の経験が手元に残りません。

この変化は、開発者自身も感じ始めています。AIツールへの不満を答えた開発者のうち、20.0%が自分の問題解決力に自信がなくなったと答え、16.3%がコードがなぜ動くのか理解しにくいと答えていました。動くコードを作れることと、そのコードを説明できることが、別々の力になりつつあるわけです。

経験年数は積み上がっていくのに、判断できることが増えていない状態は、本人がいちばん気づきにくいものです。AIを使うかどうかではなく、AIが出したものを自分で判断する場面を残しているかどうかで、数年後の差が生まれます。

参考：Stack Overflow「Getting ready for 2026 results: A look back on Developer Survey findings」

ドパガキ駆動開発はどこまで許される？

どこまで許されるかを決めるのは、個人開発かPOCかといった場面の名前ではありません。そのコードが壊れたときに、困るのが自分だけか、他人にも及ぶかです。

この基準で見ると、判定は次の3つに分かれます。

• 自分しか困らないコードなら笑い話で済む
• 他人が使う・保守するコードでは許されない
• 個人開発やPOCでも、人の手に渡った時点で扱いが変わる

ここでの線引きは、AIを使うかどうかではなく、理解しないまま進めてよいかどうかについてのものです。それでは順に見ていきましょう。

自分しか困らないコードなら笑い話で済む

壊れても損をするのが自分だけで、使い終わったら捨てる前提のコードであれば、ドパガキ駆動開発は笑い話で済みます。たとえば、次のような使い方です。

• 技術を試すために書いて、すぐに捨てる
• 自分だけが使う作業用のスクリプトを作る
• 学習や趣味のために個人のプロジェクトを作る

こうした場面では、中身を読み込むより、まず動くものを手早く作って試すほうが合理的です。アイデアを形にするまでの時間が短くなり、AIに何ができて何ができないのかを肌で知る機会にもなります。

速度を優先してよいのは、失敗の後始末を自分ひとりで引き受けられる範囲に限られます。

他人が使う・保守するコードでは許されない

チームで保守する本番環境のコードは、自分以外の人が読み、直し、障害が起きたときに原因を追うことを前提に書かれています。理解しないまま取り込むこと自体が、この前提と両立しません。そのため、他人が使う・保守するコードでドパガキ駆動開発をすることは、ネタの範囲を超えています。

誤解しやすいのは、ここで許されないのはAIを使うことではないという点です。本番のコードでも、AIに書かせたものを人間が読み、説明できる状態にしてから取り込むのであれば問題ありません。許されないのは、理解を飛ばしたまま他人の使うコードに混ぜることです。

とくに、決済や個人情報、ログインの認証にかかわる機能は、誤りの影響が利用者に直接及びます。不具合が起きれば、自社の損失だけでなく、利用者のお金や情報が危険にさらされるため、ほかの機能以上に慎重な扱いが求められます。

個人開発やPOCでも、人の手に渡った時点で扱いが変わる

最初は自分しか困らないコードでも、途中で他人が困る側に入ってくることがあります。たとえば、次のような場面です。

• POCとして作ったものを、そのまま本番で使い始める
• 個人開発のサービスで、他人の注文やログイン情報を預かる
• 公開したライブラリが、他人のプロジェクトに組み込まれる

なかでも、POCの本番昇格は起きやすいでしょう。検証のつもりで作ったものが思いのほかうまく動くと、作り直す時間を惜しんで、そのまま使い続けたくなるためです。また、コードを書けない人がAIで作った個人のサイトでも、利用者の情報を預かるなら同じことが言えます。

提唱者のCrysta1221さんも、作ったソフトウェアを学校の玄関で稼働させたり、配布したりしています。そのうえで、コードのどこに何があるかの把握や、デザインの確認は自分で手放さないことを、スライドやXで示していました。

他人の手に渡った時点で、ネタとしての速さより、理解して引き受ける責任のほうを優先しましょう。

ドパガキ駆動開発に歯止めをかける7つの対策

ドパガキ駆動開発を止めるために、AIを使うのをやめる必要はありません。AIに任せる前、書かせる前、書かせた後のそれぞれで、人間が手放さない部分を決めておけば十分です。

対策は次の7つで、うち2つは提唱者自身がLTで挙げていた条件でもあります。

どれも、明日から1つずつ試せる大きさのものです。順に見ていきましょう。

AIに任せる範囲と人間が決める範囲を分ける

最初に決めておきたいのは、どこまでをAIに任せ、どこからを人間が決めるかの線です。線がないまま使うと、いつのまにか判断までAIに渡してしまいます。目安は次のとおりです。

AIに任せやすいのは、正解の形がある程度決まっていて、間違えても見て気づける作業です。反対に、仕様の判断や全体の構造のように、あとから変えると影響が大きいものは人間が決めましょう。

決済や個人情報、認証の処理は、AIに書かせる場合でも、人間がすべて読んで説明できる状態にしてから取り込みます。判断は人間、作業はAIと分けておけば、AIを使う量を増やしても、決める力は手元に残ります。

参考：Zenn「ドメイン駆動設計から、ドメイン駆動開発プロセスの時代へ」

書かせる前に仕様とデザインを固める

AIへの指示があいまいなままだと、AIは足りない部分を推測で埋めてコードを書きます。そこで、書かせる前に次の3つを用意しておきましょう。

1. 何を作るかと、完了の条件を文章にする
2. 異常な入力や権限など、例外の扱いを書き出す
3. 画面があるなら、モックアップを作っておく

完了の条件が先にあれば、動いた時点で手を止めずに、条件を満たしたかどうかで判断できます。

3つ目は、提唱者がLTで挙げていた条件です。デザインを後回しにすると機能がよくても使ってもらえないとして、事前にモックアップを作ること、ふだんから良いと思ったデザインを保存しておくことを勧めていました。

AIに渡す前の数十分の準備が、あとの手戻りを減らします。

テストで振る舞いを固定してから修正を任せる

期待する振る舞いを先にテストとして書き、そのうえで実装や修正をAIに任せる進め方です。テストの中身は人間が決めます。テストコード自体をAIに書かせる場合も、何を確かめるかは仕様から人間が指定し、できあがったテストにも目を通しましょう。

テストが先にあれば、AIが書いたコードが仕様どおりかどうかを、テストの結果で機械的に判断できます。AIに既存コードの修正を頼むときも、今の振る舞いをテストで固定してから任せれば、意図しない変更があった時点でテストが落ちて気づけます。

テストを、AIの出力を判定するための物差しとして人間が先に用意しておくのが、この対策の考え方です。実装から後追いで書いたテストでは、この物差しの役目を果たせません。

生成コードは人間がレビューしてからマージする

AIが生成したコードも、人間が書いたコードと同じようにレビューを通してからマージしましょう。チームのレビューに出す前に、まず自分でひととおり読むのが前提です。

読むときは、次の3点を確かめます。

• 頼んだとおりに変更されている
• なぜこう書いたのかを自分で説明できる
• 頼んでいない箇所が書き換えられていない

レビューを続けるコツは、差分を小さく保つことです。AIに一度に大きな機能を頼むと、数百行の差分が返ってきて読む気力がなくなります。

機能を小さく分けて頼み、1回の差分を読み切れる量に抑えれば、レビューは現実的な作業になるでしょう。

コードのどこに何があるかは自分で把握しておく

提唱者がLTで最低限の条件として挙げていたのが、コードのどこに何があるかを把握しておくことです。すべてのコードを1行ずつ読む必要はありません。どの機能がどのディレクトリにあり、主な処理がどこからどこへ流れるのかを、自分の言葉で説明できる状態を保ちましょう。

レビューとの違いは、見る範囲です。レビューは1回ごとの変更が正しいかを確かめる作業で、ここでの把握というのは、コードベース全体の見通しを持っておく作業のことです。

AIにファイルの分割や移動を任せたときは、構成がどう変わったのかを確かめ、構成のメモやREADMEもあわせて更新しておきましょう。

どこに何があるかさえ分かっていれば、不具合が起きたときも、まず見るべき場所に自分でたどり着けます。

別のAIにもレビューさせて二重に確認する

実装に使ったのとは別のAI、または別のセッションに、生成コードのレビューを頼む方法です。

これは経験があるかもしれませんが、同じ会話の中で書いたAIに確認させると、書いたときの前提をそのまま引き継いでしまい、同じ見落としをしやすくなります。前提を共有していない相手に読ませるほうが、誤りに気づきやすいでしょう。

頼むときは、観点を具体的に指定すると精度が上がります。たとえば、次のような点を探してもらいます。

• 入力値のチェックや権限の確認の抜けを探す
• 境界値や空の入力での誤動作を探す
• 使われていない依存パッケージを探す

ただし、AIのレビューは人間のレビューの代わりにはなりません。人間のレビューの前に、もう一枚の網を張るくらいの位置づけで使いましょう。

意志ではなくCIやルールで止める仕組みにする

ここまでの対策も、忙しい日や締め切り前には省きたくなります。「今日は急いでいるから」と一度飛ばすと、その例外がいつのまにか当たり前になってしまうでしょう。

そこで、人の意志に頼らず、仕組みで止まるようにしておくのがおすすめです。

• lintとテストをCIで必ず通す
• 静的解析と依存パッケージの脆弱性チェックを入れる
• レビューの承認がないとマージできない設定にする
• プルリクエストに、AIに任せた範囲を書く欄を設ける

チームでまだ何も決まっていないなら、最初の一歩はテストをCIの必須条件にすることです。仕組みが1つ入れば、ドパガキ駆動開発のまま本番に進もうとしても、どこかで機械的に止まります。気が緩んだときでも止まる場所を、あらかじめ用意しておくことが、ほかの対策をまとめて支えます。

AIに任せきりだとエンジニアの市場価値は下がる？

結論から言うと、AIに任せきりにすれば市場価値は下がりやすく、任せ方しだいでは上げられます。

AIが広まるほど、コードを書く作業そのものの価値は相対的に下がり、AIが出したものを判断できる力の価値が上がるためです。

この変化を、差がつきにくくなる部分と、価値が上がる部分に分けて見ていきます。

コードを書く速さだけでは差がつきにくくなる

AIコーディングツールを使えば、誰でも一定の速さでコードを書けるようになりました。以前は手の速さや言語の知識の量が差になっていた部分も、ツールを使う人どうしでは差が縮まっていきます。

この流れは、IT職種のスキルの予測にも表れています。米国の大手テック企業などが参加するコンソーシアムは、47のICT職種のうち90%以上で、主要なスキルの半分以上がAIによって変わると予測しました。そのうえで、基礎的なプログラミングやプログラミング言語のスキルは、重要性が下がる側に分類されています。

AIに任せきりで速く書けることは、強みとして見られにくくなるでしょう。 書く速さで評価されてきた人ほど、これから何で評価されるのかを考え直す時期です。

参考：IPA 調査分析ディスカッション・ペーパー「AI時代のデジタル人材育成」

生成コードを読み、直し、判断できる人の価値は上がる

AIがコードを書くほど、その出力を読み、直し、使うかどうかを判断できる人の価値は上がります。AIは速くそれらしいコードを出せますが、それがこのプロダクトにとって正しいか、使う人にとって使いやすいかまでは判断できません。

評価される力と、日々の開発でそれが鍛えられる場面の対応は次のとおりです。

ドパガキ駆動開発に歯止めをかける習慣は、そのまま市場価値を上げる練習にもなるわけです。AIを使う量ではなく、AIの出力に対して自分が下した判断の量が、これからの評価を分けます。

ただし、こうした判断の経験を積めるかどうかは、職場でのAIの使われ方にも左右されます。レビューが形だけだったり、速さだけが評価されたりする環境では、本人が意識していても判断の機会は増えにくいでしょう。

AI活用が進んだ開発環境への転職ならテックゴー

AIを使った開発で判断の経験を積めるかどうかは、職場の体制に大きく左右されます。

たとえば、AIが生成したコードのレビュー基準が決まっているか、レビューに必要な工数が見込まれているか、AIに任せてよい範囲がチームで合意されているかといった点です。

こうした点は求人票からは見えにくいため、技術の話が通じる相手に相談しながら応募先を選ぶほうが、入社後のずれを減らせます。

テックゴーは、エンジニア特化の転職エージェントです。元エンジニア・ITコンサル出身のアドバイザーが多く、開発の進め方まで踏み込んで職場選びを相談できます。

• 技術の話が通じるアドバイザーに、職場選びの軸を相談できる
• 設計や判断を担う上流案件の求人を紹介してもらえる
• 面接対策は回数無制限で、設計判断の説明も練習できる
• 平均年収アップ金額は144万円で、年収を上げる転職の実績がある
• 年収交渉はアドバイザーが代行し、条件面の話し合いを任せられる

AIとの付き合い方を見直したいと感じたら、今の経験がどう評価されるのかを聞いてみるだけでもかまいません。みなさまのご相談をお待ちしております。

まとめ

この記事では、ドパガキ駆動開発の意味と元ネタ、笑い話で済む範囲と済まない範囲、歯止めをかける対策を解説しました。

ドパガキ駆動開発は、AIが生成したコードを信じて速度を追う開発をネタとして名付けた言葉で、提唱者自身も、コードのどこに何があるかの把握やデザインの確認は手放さないことを前提にしています。許されるかどうかを決めるのは、そのコードが壊れたときに困るのが自分だけか、他人にも及ぶかです。

AIを使うこと自体をやめる必要はありません。仕様と完了の条件を先に書く、差分を読んでからマージする、テストをCIの必須条件にするといった対策から1つ選び、明日の開発で試してみましょう。そうして判断の経験を積み重ねることが、AI時代のエンジニアとしての評価にもつながります。

一方で、判断の経験をどれだけ積めるかは、職場のレビュー体制やAIの使い方にも左右されます。今の環境で成長を続けられるか迷ったら、テックゴーに相談してみましょう。

元エンジニア・ITコンサル出身のアドバイザーが多く、上流案件・ITコンサル領域にも強いため、設計や判断を担えるポジションへの転職を一緒に考えられます。