ソフトウェアファクトリーとは？
最近、ソフトウェアファクトリーについての話をよく耳にします。AIがソフトウェアをつくる仕事をより多く担うことで、生み出せる量を増やし、アイデアから完成した製品までの時間を短くできる、という考え方です。
先日、Syntaxのエピソード「WTF is a Software Factory?」を見ました。それをきっかけに、ソフトウェアファクトリーとは実際に何なのか、そして今後どのようなものになっていくのかを考えるようになりました。
私にとってソフトウェアファクトリーとは、ソフトウェアをより効果的につくるために、人、モデル、ツールを組み合わせた仕組みです。問題を調べ、設計を提案し、コードを書くモデルに加えて、結果をテストするツールや、仕事の方向を示し、その成果をどう扱うか判断する人が含まれるかもしれません。
ファクトリーはモデルだけを指すものではありません。依頼を役に立つ成果に変える、プロセス全体のことです。そして、そのファクトリーをつくるうえで特に難しいのが、成果物が仕事に必要な品質基準を満たすようにすることです。
では、生産が速くなる利点を生かしながら、その成果を役に立つものにするにはどうすればよいのでしょうか。答えの手がかりは、ソフトウェアより前から存在してきた工場にあると思います。
手作業から機械へ
繊維工場が広まる前、糸を紡いだり布を織ったりする仕事の多くは、家庭や小さな工房で行われていました。人々は使い方を理解している道具を使い、自分たちで使うため、あるいは売るために糸や布をつくっていました。
産業革命はそれを変えました。新しい機械が仕事の一部を自動化し、生産の場は次第に工場へと移っていきました。機械を操作する人は、同じ仕事を手で行うよりも多くのものをつくれるようになりました。
仕事がなくなったわけではありません。機械を操作し、材料を供給し、設備を保守し、問題を解決し、何をつくるか決める人は、引き続き必要でした。変わったのは働き方です。
機械が進歩するにつれて、同じものを手作業でつくることは、経済的に正当化しにくくなりました。手仕事ならではの良さに追加の手間をかける価値がある場面では、手作業は有用であり、今もその役割があります。ただ、市場の多くでは、機械による生産が競争力のある選択肢になりました。
ソフトウェア開発も、同じような転換期を迎えているのかもしれません。エンジニアは、すべての部分を手でつくる代わりに、調査し、コードを書き、テストし、修正できる機械とともに働くようになってきています。
私は、ソフトウェア開発の多くの仕事で競争力を保つには、高性能なAIツールの利用が必要になると考えています。それは、関わる人が不要になるという意味ではありません。その人たちの時間や判断が最も価値を持つ場所が変わるのです。
つくっているシステムを理解している人は、これからも必要です。基盤となるコードに近いところで仕事ができる人も、その中に含まれます。ただ、その仕事のより多くの部分が、ソフトウェアを生み出す機械に方向を示し、その動きを確かめ、改善することになっていくかもしれません。
人が手作業で製品をつくるときは、材料に直接触れながら作業し、途中で問題に気づくことができます。機械がその仕事をより多く引き受けるようになると、責任を持つ人が一つひとつの工程を見る機会は、以前と同じではなくなります。
一つの方法は、すべての成果物を、手作業でつくったものと同じくらい詳しく検査することです。しかし、それに自分たちでつくるのと同じだけの手間がかかるなら、機械によって得られる速さの利点は大きく失われます。
機械の利点を生かしながら品質目標を達成できるプロセスが必要です。そのためには、何を、いつ確認し、どの時点で人が介入する必要があるのかを決めなければなりません。
監督と方向のずれ
問題に早く気づくほど、やり直す仕事は少なくて済むかもしれません。
あるエージェントが、機能の追加を依頼されたとします。プロセスの早い段階で、要件を誤解したままアーキテクチャ上の判断を下します。そして、その判断を前提に機能を実装します。別のエージェントがテストを書き、レビュアーはコードが設計に沿っているかを確認します。
各工程は、うまくいっているように見えます。コードはコンパイルでき、テストは通り、レビューでも明らかな実装上の誤りは見つかりません。しかし、プロセス全体では、誤った前提の上に解決策を組み立ててしまっています。
各工程の判断は一致しています。ただし、同じ誤った前提の上で一致しているのです。
実装を始める前に誰かがそのアーキテクチャ上の判断を検討していれば、短い話し合いで誤解に気づけたかもしれません。その判断がコードやテスト全体に広がってからでは、修正のために、それまでにつくったものの多くをいったん解体しなければならなくなることがあります。
これは、人がすべての判断を承認しなければならないという意味ではありません。どこで介入するかが重要だということです。
大きな手間のかかるアーキテクチャ変更の前にレビューすれば、その後に発生する多くの仕事を防げるかもしれません。一方、日常的な書式変更を一つ残らずレビューすると、節約できる時間よりも多くの時間がかかるでしょう。適切なプロセスは、仕事の内容、そこで必要になる判断、そして機械が何を扱えると実証してきたかによって変わります。
問うべきなのは、どこで監督を行い、誰がそれに責任を持ち、どれくらいの頻度で介入する必要があるのか、ということです。
モデルが役に立つのは、依頼を解釈し、私たちが細かく指定していない判断を下せるからこそです。しかし、その自由があるからこそ、判断を評価する必要もあります。モデルは、一見もっともらしくても、システムに合わなかったり、意図した問題を解決しなかったりする選択をすることがあります。
要件を明確にし、ツールや検証を改善し、自動化する仕事について経験を積むことで、監督の量を減らすことはできます。ただ、モデルが生み出すものに誰かが責任を持つ必要までなくせるとは、私は思いません。
その人は、タスクの最初から最後までモデルと直接やり取りするかもしれません。あるいは、プロセスを監視し、例外を調べ、選んだ結果をレビューするのかもしれません。どちらの場合も、機械が役に立つ仕事をしているか、いつ止めるべきかを判断するための理解と権限を持つ人が必要です。
単に機械が何かを生み出しているかどうかが問題なのではありません。間違ったものを生み出しているときに誰かがそれに気づけるか、そして、その問題に対処する機会がプロセスに用意されているかが重要なのです。
これは、工場が以前から直面してきた問題でもあります。
機械には止まる仕組みが必要
自動車工場にとって、生産ラインを止めることは大きなコストです。止まっている間は、自動車を生産できません。
従来の大量生産では、ラインを動かし続けることが優先されていました。作業者が問題に遭遇しても、生産は続け、後から検査や手直しで不具合に対処することができました。
トヨタは、別の方法を取りました。作業者は問題を知らせ、時間内に解決できなければラインを止めることができました。機械も、異常を検知すると停止できました。生産中に問題を見つけて対処することが、プロセスそのものに組み込まれたのです。
問題を調べるために意図的に生産を止めることは、最初は工場の生産性を高める方法として奇妙に思えるかもしれません。しかし、ラインから出てくる自動車の台数は、成果の一部にすぎません。その自動車が、工場の品質基準を満たしている必要もあります。
必要な許容範囲を外れた部品は、修理したり廃棄したりしなければならないかもしれません。問題が見過ごされれば、工場は不良品をつくり続けてしまいます。その部品が、後の工程でさらに仕事を増やすことにもなります。
止めると、その時点では時間がかかります。しかし、責任を持つ人たちには、目の前の問題を直し、再発を防ぐ機会が生まれます。そうした改善を積み重ねることで、不良品と、その修正に必要な仕事の両方を減らせるようになります。
だからといって、すべての部品を可能な限り精密につくることが目標なのではありません。許容範囲の設定が、その仕事に対して厳しすぎることもあります。製品にそこまでの精度が必要ないのに、非常に精密な部品を少量だけつくる工場は、必要以上の仕事をしているかもしれません。
目標は、その仕事に必要な品質を満たす、役に立つ成果物を十分な量つくることです。量は重要ですが、使えない成果物には、生産数から想像するような価値はありません。
ソフトウェアファクトリーも、同じようなトレードオフに直面します。
今、多くの関心が速さに向けられています。エージェントはどれほどのコードを書けるのか、いくつのタスクを完了できるのか、変更をどれほど速くパイプラインに流せるのか、ということです。
しかし、成果物が増えても、役に立つ成果が増えるとは限りません。ファクトリーは、一見もっともらしいコードを大量につくりながら、間違った問題を解決し、不要な複雑さを加え、改善するはずのシステムに合わないものを生み出すことがあります。いずれ誰かが、その仕事を理解し、修正し、あるいは取り除かなければなりません。
反対に、小さな操作のすべてを人が確認するようにすれば、プロセスが遅くなりすぎて、自動化する意味がなくなるかもしれません。
問われるのは、許容範囲をどこに設定し、いつ介入するかです。機械はどの判断を確実に行えるのでしょうか。どの結果を自動で検証できるのでしょうか。どの時点でプロセスを止め、問題を人に戻すべきなのでしょうか。
私は、モデルを使って信頼できるソフトウェアを生み出すうえで、人による監督は今後も重要な役割を持つと考えています。これは、いつまでも人がすべてを検査しなければならないという意味ではありません。
介入には、その都度時間がかかります。ファクトリーの多くの部分が、人による成果物のレビューに依存しているなら、その監督が処理できる仕事量の上限になります。
タスクをより具体的にし、検証を追加し、人の判断が特に重要になる箇所を見極めるなど、プロセスを改善してその負担を減らすことができます。
もう一つの方法もあります。人の監督のもとでモデルを使い、毎回同じ判断をモデルに求めることなく、繰り返しの仕事を実行できる機械をつくるのです。
どちらの方法にも役割があります。私はゲームを開発しながら、後者の方法を試してきました。
AIで機械をつくる
1年前、AIが生成した3Dモデルを見て、もう少しだと感じました。結果には明らかな問題がありましたが、あと数か月進歩すれば、自分のゲームで使えるようになると考えても不思議ではありませんでした。
私が求めていた品質は、特別高いものではありません。完璧なモデルを求めていたわけではなく、互いに調和し、スタイルが統一され、目につく不自然な箇所や形の崩れがないアセットが必要でした。
私が見てきた限り、それを安定して得るのは今も難しいと感じます。生成されたモデルは、最初はよさそうに見えても、使う前に直さなければならない問題が後から見つかることがあります。モデルがその修正を確実に行えなければ、アセットをBlenderで開き、自分で手を加える必要があります。
何度もモデルを生成し、確認して、良いものを選ぶことはできます。しかし、選ぶだけでは十分でないかもしれません。選んだモデルにも手作業での修正が必要なことがあり、同じゲームの一部として、ほかのアセットと調和していなければなりません。
そうなると、そのプロセスが実際にどれだけ時間を節約しているのかを考えなければなりません。役に立つ出発点にはなるかもしれませんが、生成し、選び、修正し、使える状態に整えるために、やはり時間がかかります。モデルが偶然生み出したものに合わせるために、表現の方向性を妥協しなければならないこともあります。
画像、動画、音楽でも、似たような難しさを経験してきました。結果が自分の求めるものに近く見えることと、プロジェクトに必要な品質を満たす、統一感のある一式を生み出せることは違います。
アセットを生成し、それを組み合わせてゲームにするファクトリーをつくることはできるでしょう。何かをすばやく生み出せるかもしれません。しかし、私が見てきた限りでは、その結果がArcanex Onlineで求めている品質を満たすとは限りません。
そこに、単に成果物を生み出すことと、プロジェクトに必要な許容範囲を満たす成果物を生み出すことの違いがあります。
AIとともにプロシージャル生成のためのコードをつくることで、別の道が開けました。アセットを一つひとつモデルに生成させる代わりに、それを生み出すコードを書くのを手伝ってもらうのです。
求めているものを説明し、作例や参考画像を示しながら、モデルとともにジェネレーターを開発できます。そしてコードを調べ、特定のルールを変え、出力を再現できます。一部分を調整したければ、ジェネレーターの中でその部分を担当している箇所に手を加えられます。
自分のゲームでは、AIとともに、マップを決定論的に生成するコードを書いてきました。同じ入力を与えれば、同じ結果を再現できます。これは、必要に応じて世界の一部をメモリーから取り除き、後でまた戻せるようにするために重要です。
既存の3Dモデルをもとに、マテリアル、衣服、道具、そのほかのアイテムをつくるためにもコードを使ってきました。その仕事には、引き続き試行錯誤と判断が必要です。しかし、ジェネレーターが意図どおりに動くようになれば、毎回すべての判断をモデルに求めることなく、再利用してバリエーションを生み出せます。
同じ考え方は、音楽にも応用できます。モデルに、楽曲を生成するコードを書くのを手伝ってもらうのです。その後は、開発を進めながらルール、楽器編成、構成を調整し、結果を再現できます。
いずれの場合も、モデルは機械をつくるのを手伝っています。そして、実際に動く機械になるのはコードです。
決定論的なコードだからといって、自動的に正しいわけではありません。役に立つ結果を再現するのと同じくらい確実に、誤りを再現することもできますし、ジェネレーターが表現上の目標を満たさないアセットを生み出すこともあります。それでもコードがあれば、ロジックを調べ、振る舞いをテストし、出力を再現し、狙った箇所を変更できます。
ソフトウェアファクトリーは何でできていくのか
私は、最も価値のあるソフトウェアファクトリーは、その大部分がコードでできているものになると考えています。
人はモデルとともに、ジェネレーターや、そのほかのツールをつくり、改善していくでしょう。そのツールが、ファクトリーの目的であるコード、アセット、音楽、あるいはそのほかの成果物を生み出します。
ファクトリー自体がソフトウェアになります。その中の機械の一部は、さらにソフトウェアを生み出し、別の機械はアセットをつくったり、ほかの種類の仕事をしたりします。その上の層では、モデルが人を助けて、問題を調べ、新しいツールを開発し、ファクトリーを改善します。
これによって、開発者の仕事は一つ上の層へと移ります。最終製品のすべての部分を、必ずしも人が手で書くわけではありません。モデルとともに、その製品を生み出す機械をつくり、動かし、改善するのです。
コードは、繰り返しの仕事に役立ちます。中身を調べ、テストし、何を期待できるか理解できるからです。あるプログラムが、意図した範囲の中で信頼できると確かめられれば、毎回人が介入することなく、繰り返し実行できます。
ファクトリーの責任は、引き続き人にあります。保守と管理を行い、必要なものがそろっているかを確かめ、成果物を、設計時に定めた品質と効率の目標に収める必要があります。何かがうまくいかなければ、誰かが問題に気づき、介入し、その機械を直せるだけの理解を持っていなければなりません。
モデルはその仕事も手伝えますが、ファクトリーに責任を持つ人の代わりにはなりません。生み出されたものの責任を問うことができるのは、人だけです。人の監督のもとで使うAIと信頼できるコードを組み合わせることで、その人たちは、以前ならはるかに多くの時間と労力が必要だったことを行えるようになります。
私は、よくできたソフトウェアファクトリーが、ソフトウェアの作成と保守のコストを大幅に下げ、それを持たない組織が競争するのは難しくなると考えています。また、以前ならはるかに大きな組織が必要だったシステムを、小さなチームでつくれるようにもなるでしょう。
これは、コストだけの問題ではありません。チームを大きくすると、調整、引き継ぎ、コミュニケーションも増えます。少人数のチームにより良い機械を提供すれば、そうでなければ、規模や費用の面で実現が難しい組織を必要とした問題にも取り組めるかもしれません。
初めて実現可能になるシステムもあるでしょう。以前から技術的には可能でも、つくりたいと思う人たちの手元にある資源では実現できなかったシステムもあります。
私は今、MMORPGであるArcanex Onlineをつくろうとしています。この種のゲームでは、大きなチームと、数千万、あるいは数億という規模の予算が必要になることがあります。私にはそうした資源がないので、より良い機械を使えば、ずっと小さなチームで何ができるのかを知ることに、個人的にも強い関心があります。
私にとっての可能性は、そこにあります。単にソフトウェアを速く生成することではなく、力のある人たちに、以前はつくれなかったものをつくるための道具を届けることです。