挫折を乗り越え構築した「RDD(ラチェット駆動開発)」― 非エンジニアが規律をコマンドに変えた話
躓きは、私だけの弱さじゃなかった
前回、「バイブコーディングの3つの落し穴」(プロセスの穴・参照の穴・習慣の穴)を紹介しました。
今回記事を書くために参考に記事を見ると、どうやらこれは私だけの話ではなく、よくある開発の失敗パターンとして観測されていました。今回は、その"失敗の地図"を先に広げてから、私がどう手続きに落とし込んだかを書いていきます。
躓きは3層・8つのポイントに分解できる
いろいろな記事や論文を突き合わせていくと、非エンジニアにかかわらず開発の躓きは、さらに8ポイントに分解できます。
これは前回書いた3つの落し穴を、少し解像度を上げただけとも言えます。
躓きはスキル不足だけじゃない。仕組みで解決できる
ここで一つ、はっきりさせておきたいことがあります。私が陥った躓きは、よくあるパターンだったということです。
例えば、調べていく中でこんなデータがありました。
直近の監査で、AI生成コードの最大40%に脆弱性が見つかった(Vibe Coding Mistakes to Avoid)
開発者の63%が、AIが書いたコードのデバッグに「自分で書くより時間がかかった」経験がある(builder.io)
100万トークンの文脈を扱えるAIでも、指定したコーディング規約のような「深い制約」を見失う(LogRocket)
「規律を守れない」「テストを忘れる」「数ヶ月後にClaude Codeがコードを読めなくなる」。これらは私個人の甘さでもあり、エンジニアの方を含めて誰しもが陥る再現性のある落とし穴でした。だとすれば、解決策は「もっと気をつける」「レベルアップする」ではなく、「仕組みで踏まないようにする」方向を考えるべきだと思いました。
解決の発想:規律を「意志」から「手続き」へ
前回書いた通り、プロは組織のルールや規律を習慣で守れるようになります。ただ非エンジニアの私には、その習慣はないですし、今後も習慣を身につけるのが難しいかもしれません。学んだ作法を知識として持っていても、毎回それを自分の意志で守り続けるのは無理だ、というのが前回の私個人の結論でした。
そこで私が立てた方針は、一歩踏まないと先に進めない構造にした開発プロセスを作ることです。
規律を「守ろうと意識する対象」から外して、コマンドの手順そのものに埋め込んでしまう。私はこれを、次のような一連のコマンドの流れとして組み直しました。
先に断っておくと、これらのCLAUDE.md階層・feature-history・Git Worktree・GitHub Issue活用・カスタムスラッシュコマンドといった土台の部品は、前回書いた通り平川知秀さんの『Claude CodeによるAI駆動開発入門』から学んだものです。私がやったのは、それらを非エンジニアでも忘れない「一連の強制プロセス」に組み直したことでした。
メインのプロセス7プロセス（8つのコマンド）
上の８つのコマンドの中身をさらに細かくすると、次のような表になり、/issue系で17ステップ、/dev系で54ステップになります(モード分岐やサブ手順まで含めると延べ約100ステップです)。
この7つのメインのプロセスに、代表的には次のような開発上の知見を埋め込んでいます。
EPIC +Sub TaskでIssueを管理する
設計と実装のプロセスを明確に分ける
設計や実装の前に、コードを確認する
一般知識をMCPを使って取得する
TDDを順守する
Issueのラベルで開発範囲を定義して必要なスキル・ルールを読み込む
デザインシステムを遵守し、チェックする
開発終了時に関連文書を自動的にアップデートする など
そしてこの「プロセスを固定し、1つずつ進んでいく」という進め方に、私は、Ratchet-Driven Development(RDD/ラチェット駆動開発) と名付けました。ratchet(ラチェット)とは、一方向にしか回らず、回した分だけ固定される工具のことで、この開発にぴったりだと思って名付けました。
ナレッジ更新を「Issueを閉じる手続き」に結合する
この開発プロセスの白眉のところ（自画自賛ですが）は、開発のプロセスの中にナレッジの更新が含まれていることです。
前回書いた⑥「数ヶ月後のナレッジ喪失」は、私にとって一番痛かった壁でした。ドキュメントを「別途・善意で」書こうとする限り、それは続きません。忙しい時期があれば真っ先に後回しにされ、気づけば形骸化しています。
そこで私が出した答えは、ナレッジの更新を、Issueを閉じる手続きそのものに埋め込んでしまうことでした。`/issue-record` や `/dev-cleanup` を実行すると、その都度 `feature-history.md`(作った機能の履歴を溜めていくファイル)が更新され、必要な関連文書が見直されるようにしています。
Issueを閉じる、という開発上どうしても避けて通れない作業をすると、ナレッジが自動的に1段積まれる。積み上がった記録は月次でアーカイブしています。
この仕組みのおかげで、数ヶ月経ってからでもClaude Codeが作成するものが動かないという状態を回避することができました。
ナレッジ更新を「フローの外の善意」でなく、「避けられない手続き」に埋めたこと。
RDDをさらにアップデートする
今回この記事を書くにあたって、私と同じようなことに問題意識を持ち、私とはまた違ったやり方で改善をしている人を見つけました。
次回は、その先行事例と自分のやり方の違いを見つつ、RDDに「発明した」にそこから得た何を学び取り入れていきたいと思います。
