「ソフトウェアを作るのが意外と難しい」理由を再説明してみる
トラックバック＆感想。
これ共感しますね。
このテーマ、僕も一家言ぶちたい願望があるので、ちょっと僕の言葉で言い換えてみます。
ソフトウェア以外にも顧客の注文なり社会的な要請なりを受けて創造されるものってあると思います。
- CMの音楽を作曲する
- 美術館を建造する
- 注目があつまるフェルマー予想を証明する
といった感じに。
作曲の場合、発注者が作曲家にリクエストする内容はどんな感じでしょうか。納期と予算はまずあって、ウキウキする感じ、とか荘厳な感じとか、ポップな感じとか、曲の長さとかクライマックスがこの辺にくるとか、使う楽器とかは専門的なのであまり注文つけられないかな、とか、そういう感じでしょうか。ざっくりとしたリクエストを投げて、いくつか作ってもらってイメージに合うものを採用するというプロセスをふむと思います。
美術館の建造でしたら、予算と納期、ロケーションと広さ、建立の背景、所蔵する美術品、管理する学芸員はどんな人たちかとか、想定客はどういう人かとか、そういう感じでしょうか。
フェルマー予想はそもそも予想したのがフェルマーという数学者なので要請の発端がすでに専門家です。ただ有名なので一般人も巻き込んで注目が集まっていた。これについては作り方（証明の仕方）に注文を付けるのはかなり難しいでしょう。
さて、ソフトウエアの開発は上記の作曲、建築、数学（の定理証明）と同様に「専門知識にもとづく制約がついて回る度合い」がかなり強いものだと思います。中でも数学はとくにそうですけど、ソフトウェア開発もその数学がもつ制約の強さに似たものがあると思います。
建築はパース図のような完成イメージ図を事前に共有したりしますが、ソフトウェアもGUIレベルではモックアップやデザインカンプの共有は可能です。しかし機能的な振る舞いということになると、事前に共有するのはとても難しい。それこそ図ではなく言葉で認識の一致を確認するしかないですが、そうすると上記記事にあるとおりソフトウェアの振る舞いを表現するボキャブラリが双方に要ることになります。それは発注者が専門家ではない場合は難しいです。
そして、ソフトウェア開発の難しさと面白さは、作曲と建築と数学がもつ難しさと面白さのそれぞれをちょっとずつ持っているところにあるとも思います。
作曲における「感性とスコアが一体」という性質は、ソフトウェアにおけるユーザビリティと機能の関係と近いです。
建築における「物理的制約下での設計」という性質は、ソフトウェアももとはハードウェアという物理系の上で動かす現象ですから物理的制約が入ったうえで目的のものをビルドアップするという共通性があります。
数学がもつ「個別具体的な厳密さと抽象化」という性質は、ソフトウェアにおいても、厳密なビット演算に従って演繹的に動作するというコンピュータの普遍的な基礎があったうえで目的の抽象的なタスクを実現しなければならないという本質があるので、同様について回る性質でしょう。
これらをまとめて言い表すとしたら、「トップダウンがボトムアップに依拠するタスク」ということになると思います。
ディレクションというのはトップダウンです。注文を付ける、リクエストを投げるというのもトップダウンです。そのトップダウンのプロセスが、ボトムアップの制約から自由に解き放たれているタスクであれば問題ないですが、ここで挙げた３つのタスクやソフトウェア開発というタスクはその制約がかなり強いため、ディレクターとスタッフの間のコミュニケーションが非常に重要です。
ただ、人工知能技術が発展して、このあたりの状況が一変する可能性も十分あると思われるので、そうなったときにソフトウェア（すなわち人工知能）を作る側の立場でいられるように引き続き頑張っていきたいです。
