読者です 読者をやめる 読者になる 読者になる

要求の複雑性とアーキテクチャの複雑性

なんか朝ふと考えたこと特にまとまってない状態で書いてみる。もしかしたら今年最後のエントリになるかもしれないエントリがそれでいいのかっていう気がしなくもないけど。

僕たちのようにソフトウェアをつくている人たちは本質的に複雑性に立ち向かうことが主な営みである。世の中というのは複雑であり、その複雑な世の中で問題とされていることを解決しようとするとその中でもとりわけ複雑な領域を取り扱わなければならない。そうでなければそもそもソフトウェアなど必要ないことになる。人間がそれをやるにはワーキングメモリが少なすぎるとか、時間がかかりすぎるとか、原因は何かわからないけど何らかの理由によりちゃんと遂行できないものこそソフトウェアをつくって解決するべきなのだということになる。

逆に言えば僕たちソフトウェア産業従事者が今も仕事を手に出来ていてちゃんとご飯が食べられているのは世の中が複雑であることの恩恵かもしれない。シンプルな世の中にはソフトウェアなんて必要ないという可能性は全然あって、そうであるとするならば僕たちがソフトウェアをつくるという上において「世の中の複雑性を受け入れる」というのはスタート地点であり、大前提であるような気がする。「その仕様は複雑すぎる。そんなことはできない。」とか「そんなものは必要ない。もっとシンプルにするべきだ。」というのは局所的なシチュエーションで経済とか政治的な利害が絡む場合には重要な指摘であり必要な議論だと思うけど、もっと大局的に世の中を見つめたときに「世の中はもっとシンプルであるべきだ」と思ってるんだとするとそれだったら僕たちはどうしてここにいるんだっけ?ってなる。

ただ、世の中は確かに複雑なんだけど、その問題を解決するためのソフトウェアもまた複雑な構造を持っていて、実はこれをすごく厳密に区別するのはなかなか難しい。これらをそれぞれ「要求の複雑性」と「アーキテクチャの複雑性」という風に呼ぶことにしてこのエントリのタイトルにした。

例えば DDD とかオブジェクト指向設計が目指しているのは人間のメンタルモデルとアーキテクチャを近づけることによって設計を支援するとともに変更の影響を小さくしようとする行為である。特に DDD はドメインモデルと UI とインフラストラクチャを明確に区別するため、厳密に実践するとドメインモデルが要求をそのままあらわすようになる。この状態だと要求の複雑性とアーキテクチャの複雑性は決して混じらないし、要求の変更に対する耐性もある程度は保たれる。ただしこれはドメインエキスパートの存在とその人とドメインモデラーとの密なコミュニケーションを前提としていて、相応のコストが発生する。このコストを支払う価値がある領域はそれなりに限られてくるのではないかというのを正直最近は結構思う。*1

僕が最近感じているのは「実は要求はだんだんシンプルになってきているのではないか」ということだ。

ソフトウェアの利用用途として業務効率化やビジネス活動の支援が支配的であれば(かつてはそういう時代だったはず)そこにはある程度形式的な業務ルールと業務フローがあって、それは複雑なルールだったかもしれないけどそれを分析すれば仕様を決定することができた。ただ現在ではエンターテイメント目的のソフトウェアも多く、ユーザはただひたすらコンテンツを消費したいだけだったり暇な時間をどうにかしたいだけだったりして、業務システムほど明確な目的意識やルールは存在しない。この場合、むしろ要求はとてもシンプルでそれを解決するアーキテクチャのほうが複雑になる。それは例えば検索アルゴリズムかもしれないし、レコメンドアルゴリズムかもしれないし、レスポンスタイムかもしれないし、ユーザビリティかもしれないけど、いずれにしてもユーザ自身が「仕様」と認識しているわけではない。ユーザ自身も自分がどういうシステムを欲しいかわかっていないのだ。

これは DDD では決して解決しない。要求は複雑で、それを解決するためのアーキテクチャも複雑だから、せめてそれを明確に分離して前者だけでもシンプルにするか、あるいはどの程度複雑かを可視化できるようにしようとするのが DDD であると思うのだが、今はすでに要求自体はシンプルなのだ。シンプルな要求に対してアーキテクチャだけが複雑化している。

僕はソフトウェア開発とは世の中の複雑性に立ち向かうことだと思っていた。

だけどそれが(一部の業界では)そうではなくなっていてむしろ複雑なアーキテクチャにどう立ち向かうかということが重要な問題になってきているのだとすると、なかなかこれは興味深い流れだと思うし、アーキテクチャを人間のメンタルモデルに近づけていこうとする動きの真逆をいく盛大な揺り戻しなのかと思ったりもする。

もしかしたらその動きのひとつが microservices なのかもと思ったりして、今後もそのへんのトレンドは追いかけていきたいと思う次第である。*2

*1:僕自身 DDD の考え方は大好きなので悪く言ってるつもりはないです。あくまで客観的に見たときのひとつの意見です。

*2:microservices については言いたいことがたくさんあるので別途ブログ書く予定。