高難易度コードレビュー依頼

最近、ダークファクトリーを目指している。

ダークファクトリーというのは、もともとは人間がほとんど介在しない工場のことだ。人間がいないから照明をつける必要もない。そんなわけで暗い工場、ダークファクトリーである。

これをソフトウェア開発にも持ち込もうという話だ。

まあ、ライトのオンオフに関わらず、もはやかなりの部分を AI が作るようになってきた。実装だけでなく、テストもコードレビューも AI が担当するようになりつつある。

そこで、いくつか疑問が出てきた。

GitHub と Pull Request は必要なのだろうか？

コードレビューは現実的なのだろうか？

コミットメッセージには、どこまで書くべきなのだろうか？

そもそも、設計は本当に、本当に必要なのだろうか？

人間が読まないコード

まず、コードレビューである。

AI がコードを書き、別の AI がレビューし、修正まで済ませてしまうとする。そうなったとき、Pull Request に人間向けの説明を書く必要はあるのだろうか。

コミットメッセージもそうだ。

変更した理由や背景、何をどう修正したのか。これまでは人間に伝えるために書いてきた。しかし、AI が必要に応じて変更履歴を調べ、理解できるなら、そもそも人間向けの文章として残す必要はあるのか？

もちろん、何かあったときに人間が調査する可能性は残る。

とはいえ、調査だって AI に任せればよい。

そう考えていくと、もう少し厄介な疑問にたどり着く。

アーキテクチャはどうなるのだろう。

MVC やクリーンアーキテクチャのような設計手法には、複雑なソフトウェアを人間が理解し、変更できるようにするという目的がある。人間の頭では巨大なプログラムのすべてを一度に把握できないから、責務を分離して、層を分ける。

もちろん、変更の影響を限定するとか、テストを容易にするとか、それ以外の目的もある。

しかし、基本的に AI しかコードを読まないとしたら？

人間にとって理解しやすい構造を、わざわざ維持する必要はあるのだろうか。

ソフトウェア工場の話

ここで、日立製作所が1969年に設立した「ソフトウェア工場」を思い出した。

ソフトウェア開発を工業生産として扱い、工程を標準化し、品質を管理するという取り組みである。

この時代には、個々のプログラムを検査し、組み合わせて全体を検証するという品質保証の考え方が発展していった。単体テスト自体は日立が発明したものではないけれど、ソフトウェアを部品に分け、それぞれの品質を確認するという考え方は、工場という発想によく合っている。

ここで大切なのは、品質をどこで保証するのか、ということだと思う。

部品が要求されたとおりに振る舞うことを確認する。部品を組み合わせたときにも、期待された機能を満たすことを確認する。

そのためには、内部実装のすべてを人間が理解している必要はない。

ブラックボックスとして扱い、振る舞いを検査することもできる。

もちろん、単体テストだけで製品の品質が保証できるわけではない。結合テストも必要だし、性能、信頼性、セキュリティといった非機能要求も検証しなければならない。

でも、発想としては実にわかりやすい。

そして、ダークファクトリーが普及したとき、この考え方が再び強くなるのではないかと思っている。

AI が内部実装を担当し、人間は要求と、その要求が満たされているかを確認する。

内部実装については、AI が都合のよい形に最適化していく。

さて、そうなったとき、何が起きるのだろう。

謎設計の謎言語

ある日、何かのきっかけで、普段は AI に任せきりのコードを読んでみたくなったとする。

リポジトリを開いてみる。

そこには、見たこともない設計の、見たこともない言語が広がっていた。

そんな未来があるんじゃないだろうか。

今のところ、AI も人間が使っているプログラミング言語や開発ツールを利用している。その方が学習済みの知識も多いし、コンパイラやデバッガ、テストツールも揃っている。

だから、すぐに謎言語が登場するとは思わない。

しかし、AI だけがコードを書き、AI だけが読むのであれば、いつまでも人間のために作られたプログラミング言語を使い続ける必要があるのだろうか。

そもそも、今のアーキテクチャが AI にとって最適である保証もない。

人間に理解しやすいように名付けられた変数や関数、人間が追いやすいように整理された依存関係。これらは AI にとっても便利かもしれないし、そうではないかもしれない。

そして、何年も AI が改修と最適化を繰り返した結果、人間には理解しがたい何かが出来上がっている可能性もある。

何しろ、人間が読めることを品質要求に含めていないのだから。