Web開発は特に、ほとんどOSSの組み合わせと言ってよい。自分では何を書くかというと、ユニークなコアロジックや、アプリケーション固有のビジネスロジック、そしてそれらとOSS同士をつなぐ「接着コード」と言ってよいのだが、ビジネスロジックと接着コードは癒着しやすく肥大化しやすい。そうすると技術負債になる可能性が高い。
なぜ接着コード肥大化するかというと、「ちょうどいい粒度の部品」がないからだ。別にぴったりちょうどいいOSSがあればそれを使いたいのだが、それがないから接着コードにロジックを書いて、OSSの組み合わせを新たに書く。それがビジネスロジックと地続きに癒着していってしまう。
というわけで、ちょうどいい粒度の部品がなければ、必ずしも小さく汎用的でなくてもいいので、それ自体をパッケージとして別途開発する。それを完璧に動作するようメンテし続ければいい。
例えば自分も、OSSのテンプレートエンジンに変数を流し込み、別のOSSメール配信クライアントで配信する、というコードを数限りなく書いてきた。別に好きなテンプレートエンジンとメール配信を組み合わせたOSSがあれば、それを使えばよかった。だが、そういうぴったり好みのプロジェクトはないから仕方なく書いてきた。
要はビジネスロジックとOSSの延長プログラムをひとりの人間が書いてきたわけだ。それは癒着もするだろう。
そこでテンプレートエンジンとメール配信を組み合わせた部品をテストも含めパッケージとして完璧に作る。誰も使わないかもだが、公開しても困らないので本当にOSSにしてもよい。
AIもOSSもほぼブラックボックス
そんな細かいことにまでいちいち時間をかけてられるか！メンテはどうするんだ！となったのはもう過去の話で、今は開発・メンテに加え、なんならドキュメンテーションまでそこらの人間よりAIが完璧にこなしてくれる。
このようなアプローチにはもうひとつ根拠がある。AIはOSSから学習していると思われるので、成果物はOSSスタイルに寄せるほうがきっと相性も良いのだ。
一方、人間からすると中身を把握しきれないコードを使うわけで、それが怖いという意見もあるだろう。自分も先日まではそうだった。
だが、よく考えたら普段お世話になっているOSSのほとんどもそうなのだ。その叡智まで知ることなく、「なんか動くから使っている」「本当に困ったらソースを読む」のが実態ではないか。
では大掛かりな仕様変更が発生したらどうするんだ？ 中身がわからないと直せないではないか？ それに対する答えは直さなくてよい。新しくAIに作らせればよい、である。そもそも中身の把握に苦労するような規模の部品にはしないという方針だ。
OSSの部品やフレームワークを信頼するように、AIが作った部品を信頼する。そうするとエンジニアは接着コードから離れ、真のビジネスロジック、コアロジックに前線を移動できる。全体の見通しも非常によい。
6ヶ月の工期が3週間になりそうなAI委譲の開発スタイル
現在開発しているプログラムだが、90%の汎用的なコードはAIで部品として開発し、OSSとして公開することにした。
なんだかんだ掛け持ちもあるし、安定するまでは6ヶ月かかるかも…と覚悟していたプロジェクトだが、2週間でほぼ完璧にテストされた部品が揃い、あとはビジネスロジックに乗せて組み合わせていくだけとなった。組み上げには1週間もかかるまい。
OSSにして別に多くの人に使って欲しいわけではないが、別に隠す必要もないからだ。例えばこのプロジェクトなどが一例だ。
- ideamans/go-backup-cleaner: A Go package for cleaning backup files based on capacity constraints. It automatically removes old files to meet specified disk usage targets and can clean up empty directories.
- ideamans/go-living-lock: Go言語によるロックファイル排他制御パッケージ
AIに自分の代わりを任せる方法を、これから躍起で追い求める人も多いだろう。それ自体は面白いプロジェクトなのだが、プログラミングに関して言えば自分の分身を作りプロジェクトにジョインしてもらうより、ソフトウェア自体の設計方針を変え、AIの責任範囲を定めて大きく委ねた方がスムーズでスケールもすると感じている。
DXとは結局、人の方が変わる営みでないと上手くいかないのだ。