「ソフトウェアの複雑さ」がよくわからない

ソフトウェア開発の難しさについて考える。
ソフトウェアの複雑さについて、またソフトウェアの成長についての、二点を考える。

「ソフトウェアの複雑さ」がよくわからない

大規模なソフトウェアは複雑であり、それが開発の難しさだという意見はよく聞く。この複雑というのがどういうことなのか、僕はあまりよくわかっていない。顧客の数が多いとか、専門用語が多いとか、組織固有のノウハウに依存しているとか、システムの目的や領域が混在しているとか、なんかそういうビジネス上の多様な問題を統一的に扱おうとすることから生じる複雑さなのかな、という印象がある。だからソフトウェアの複雑さというのは複雑なビジネス領域を体験しないとよくわからないのかな、と。そういうイメージを与えてくれる文章を引用してみる。

『エリック・エヴァンスのドメイン駆動設計』p.43
部屋に入った時にまず目に入ったのは、すべてが書き込まれたクラス図だった。このクラス図は大量の紙に印刷されて、巨大な壁を覆っていた。これは私にとってプロジェクト参加初日のことだったが、このプロジェクトすでに頭の切れる人々が何ヶ月もの時間を費やして、ドメインについての詳細なモデルを慎重に調査し、開発していた。そのモデルに含まれる典型的なオブジェクトは、他のオブジェクト3、4個と複雑に関連していて、この関連の網の目には自然な境界がほとんどなかった。その点では、アナリストはドメインの性質に忠実であったと言える。

この「壁一面のクラス図」とか「何ヶ月もの時間」とか「オブジェクト間の3、4個の関連」とかが、複雑さの具体例として理解できる。
でもじつはこの引用部、この分析はビジネスの専門家の目線では優れていたにもかかわらず、関連がややこしいせいでアプリケーションの設計にはぜんぜん役に立たなかった、という話につながる。あるビジネスの複雑さをありのままにモデル化しても、ソフトウェアの設計には使えないらしい。複雑なビジネス領域のためのソフトウェアをつくるには、専門家の目線から複雑なビジネス領域を理解して、さらにソフトウェア技術者の目線から理解を整理しないといけない。ここもまた難点に思える。
ソフトウェア開発における複雑さの問題、そのひとつは、ビジネス領域そのものの複雑さを理解する問題である。そして、その複雑さをアプリケーションの設計にかみ砕く、複雑さの整理問題である。
また別の視点として、ソフトウェアが、従来のあらゆるものづくりと異なる、概念構築のものづくりであることが言及されることもある。概念構築ならではの複雑さ、僕はあまりぴんとこない。これはビジネス領域の複雑問題とも重なっていそうな気もする。
僕の感覚に正直なまま理解を言葉してみるとこうなる。ソフトウェア開発における複雑さとは、ビジネス領域の複雑さそのものである。プログラミングやアーキテクチャ、そういう技術領域の複雑さは、ついでの問題である。なぜソフトウェア開発に限ってそういうビジネス領域の複雑さが問題にあるかというと、アプリケーションの設計に（「人間同士の会話」とは対照的に）その明示的かつ整合的かつ理解容易な解釈が必要だからである。
（この場の思いつきだけれど、行き当たりばったりコピペプログラミングでソフトウェアは簡単に難しくできるけれど、そういうのは「乱雑さ」とでもよぶのが適当かなと思った。そういう現実的な乱雑さを排除しようとしてもなお残る本質的な複雑さとはなんだろう、というところに興味がある）

理想のソフトウェアはつくりはじめないとわからない

理想のソフトウェアはつくりはじめないとわからない、こちらは僕の素直な感覚である。ソフトウェア開発は難しい、なぜなら理想のソフトウェアはつくりはじめないとわからないからである、と言われれば、納得できる。
もうちょっと分解してみる。理想をはっきりさせるために何が要るか。目的とか要件みたいなもの、目的に関わる領域の知識とかルール、目的を実現させる手段。要求理解、ドメイン知識、技術。
要求理解。これは「顧客は自分が何を求めているかわかっていない」とかの刺激的な言葉に象徴される。奇妙な体験だけれど、「自分がほしいもの」をつくろうとしたとき、それをつくっているいろんな段階で「自分がほしいもの」は、じつは見えていなかったことに気づいたり、やっと見えてきたり、と思えば姿を変えたりする。変な言い方をすれば、「自分がほしいもの」をつくるという問題は、「自分がほしいもの」という言葉の意味をつくる問題を伴う。「これだ！」とあたまに沸いてきたアイデアが、じつはとんでもなくあいまいなものであったと気づくのは、手を動かしてからだ。
ドメイン知識。世の中には見たことも聞いたこともない知識がたぶんいっぱいである。でも知らないんだから、どれくらいいっぱいあるかはわからない。知らなかったことっていうのは、どこから出てくるかわからないから、知らなかったことにびっくりするのはあたりまえのことだ。たとえばさっき引用した本では、発生主義会計というドメイン知識が例に出ている。そんなもん知るか、って思った。でもそういう知識がスマートな設計のヒントになるんだから仕方ない。
技術。実装しないといけない。ドメイン知識はビジネス領域の数だけバリエーションがあるから包括的な理解は難しい、でも技術はそうではない、とかいう期待は、ハッカーでもなければ打ち破られる。現実に我々は「はまる」という事態に陥る。思ってもみないところで、はまる。どこから出てくるかわからないあっとおどろくドメイン知識と同じなんだけど、出てこられても困るだけというのがいやな違い。
三つの問題を挙げてみた。それぞれがなぜ起こるのか、どう対処するかというのも重要だけれど、いまは置いておく。これは、現実にそういう問題があって、無視できないっていう、個人的な現状把握。
だからソフトウェアは開発するのではない、育成するのだ、みたいな考え方が『人間の神話』ですでに出ているのが、いまさらびっくり。
以上、ソフトウェアの複雑さというのがよくわからない件と、ソフトウェアの成長における問題の自覚でした。