最近、仕事でAI-DLC的なことをしていて思うこと。
AIの稼働が高ければ高いほど、ソフトウェア開発は速い。
人が手を動かす時間が減るぶん、アウトプットの量もスピードも増していく。
一方で、商用サービスを提供するなら品質に問題がないことを担保しなければならず、その手段としては人が品質ゲートになる手法が主流（少なくとも、いまいる会社では）。
手戻りのリスクを最小化するには、この品質ゲートを品質が最大化できるタイミングで入れる必要がある。
ただ、人による品質ゲートはそのままAIの稼働を止めるボトルネックにもなる。
なのでこのボトルネックをいかに減らし、本質的なチェックだけに絞れるかが効率と品質を両立させる鍵になると思う。
そう考えると、人が確認しておかないと本当にリスクになる要素は限られてくる。
線引きの基準は「あとから直すのが可逆か、不可逆か」だと思う。
仕組みで検知して後追いで直せるもの＝可逆なものは、AIと仕組みに任せて流していい。
一方で、一度ボタンを掛け違えると後戻りのコストが跳ね上がるもの＝不可逆なものだけは最初に人が止めるしかない。
その観点で優先度が高いのは以下あたりだろう。
- ユーザーストーリー
- ユーザに対してどういう価値を提供するか
- 画面設計
- ユーザに対してどういう形で提供するか
- データ構造
- そのソフトウェアが扱うドメインを正しく表現できているか
もっとも、どこまでを「不可逆」とみなすかの線引き自体がドメインの理解を要する判断で、たぶんここが一番難しい。
逆に言えば、この見極めさえできていれば、あとは人が介入せずどんどんAIに進めてもらえばいい。
そして品質の悪化は、レビュー以外の手段で気づけるようにしておく。
こうすれば品質と開発速度を同時に最大化できる気がしている。
レビュー以外の手段とは、たとえば以下のようなもの。
- lintでの静的解析
- テストカバレッジ
- 網羅率というよりも、カバー範囲に懸念がないか
- 依存関係グラフ
- dependency-cruiserなど
- 構造としてカオスになっていないか（ドメインを正しくコードに落とし込めているか）
- 実装時に参照したドキュメント
こういう仕組みを入れてプロダクトの健全性を徹底的に可視化すれば、実装のタイミングでコードの詳細を確認しなくても品質はある程度担保できる。
可視化で見えた問題は、たいてい可逆な品質だ。
それを後追いでどんどん直していくほうが、人が逐一確認するよりも結果的に高品質だし速い。
逆に言えば、人が事前に止めるべきなのは「可視化では見えない、かつ不可逆なもの」に絞られる。
そして、これまで人のレビューが担保していた領域も、できるだけ仕組みに寄せていく。認可の抜けや破壊的変更、異常系の見落としといった、ロジックの考慮漏れに気付ける構造をつくっていく。
今のプロダクトでもこういう思想をもとに、開発ダッシュボードを用意してプロジェクトの健全性を可視化しCIを手厚くする試みをしている。
今のところ、結構良い感じに機能している気がする。
結局のところ、人の仕事は「コードを一行ずつ確認すること」から「どこに品質ゲートを置き、何を可視化するかを設計すること」へ移っていくんだと思う。
人が見るべき本質的なポイントを見極めて、それ以外はAIと仕組みに任せる。
その線引きがうまくできるほど、開発は速くそして品質も高くなる。