RDDの直しどころを、全部棚卸ししてみた話

RDD（Ratchet-Driven Development）という開発プロセスを、「ループ・エンジニアリング」と「グラフ・エンジニアリング」という2つの物差しで採点した前回の記事に続き、実際の改善点を7項目で整理しました。著者が想定していた「2〜3個の直しどころ」が、数え直してみると7項目に増えたという、開発プロセス自体の可視化の話です。項目としては「ツール許可の整理」「進行ログの構造化」「要件レビュー役の新設」など、確認作業の効率化と役割分担の精密化が中心になっています。

AIの鬼として見えるのは、このプロセス設計の誠実さです。多くの開発チームは「確認が多すぎる」と感じると、「とにかく確認を減らそう」と走ります。しかし著者は「どの確認を減らすか」を分類し、「計画段階の確認を先に強化してから、実装段階の確認を減らす」という依存関係を明示しています。つまり、プロセスの「どこを削るか」ではなく「どこに順序があるか」を考えているわけです。これは、自動化や効率化が流行る時代に、人間の判断の構造を言語化し、その構造の上で初めて自動化を乗せるという、逆転の発想です。また「あえてやらないこと」を明記している点も重要で、自動化のリスク（夜中に無人で動くリスク）と利得を天秤にかけた取捨選択が見えます。

中小企業の開発チームにとっては、このアプローチは即座に応用できます。何の確認を減らすか、どういう順序で減らすか、どの判断は残すべきか。プロセスの再設計は、目先の速度ではなく「どこに人間の判断を集中させるか」から始まるという教訓です。プロセス改善を社内で検討するときは、7項目の分類と依存関係を参考に、自分たちのチームの「確認ボトルネック」を言語化することから始まります。