こんな記事に触発されて。
富士通、業務プログラム開発支援ツール「Interdevelop Designer」を販売開始：ITpro Active
・・・未だにこんな事やってるのか。
正直、驚きと失望と倦怠感と怒りと哀れみと嘲笑がないまぜに押し寄せて、(･_･)こんな顔になりました。
SIerにとって、ソフトウェア開発に銀の弾などないということが、どれほど真摯に理解されているのかが窺い知れる良いニュースだったと思います。
今から約30年前にブルックナーさんが言ったことですが、ソフトウェアが解決しようとしている問題そのものが持つ、本質的な複雑性を避けて通ることはできません(偶有的な複雑性は避けられる)。
そもそも、人間が扱う複雑性を封じ込めるためにソフトウェアというものは存在しているので、ソフトウェアの複雑性を封じ込めたいというのは、１段抽象レイヤーが上がっただけで、相似形をなします。
同じレイヤー上で、別の手段で圧を逃がそうとしても、今度はそちらが複雑になるだけで意味が無いというのは、少し考えれば分かりそうなものですが、少しも考えずに突っ走ってしまったのでしょうか。お偉いさんが言い出して、止めることができずに現場が頑張っちゃった結果なのかな。何れにせよ、かわいそうな人達です。
ソフトウェアの複雑さについて
そして、掲題の話ですが、ソフトウェアの複雑性は回避しようがない、絶対的な法則だというところを前提にしてしまいたいのですが、少し説明します。
ソフトウェアの役目は、コンピュータをより良く動かすことにあります。そしてこの「より良く」というのは、「人間様にとって」というのが暗黙的な前提となりますから、恣意的です。誰かにとって、何か便利な現象が起きて欲しいと願ってソフトウェアを書くわけです。人間が居ないソフトウェアの理想郷では、ソフトウェア達が自由に動きまわって、恐らく人間にとっては全く意味のない情報を出力し続けるのでしょう。
残念なことに、現実世界では人間が邪魔をするので、ソフトウェアは、人間社会を写す鏡となります。人間社会の複雑さを内に取り込み、自身も限界まで複雑になっていきます。
思えば、人類の進化とはソフトウェアの進化の歴史でした(と言うのは1世紀ぐらい早いかもしれませんが)。
人間社会はどんどん複雑になっていました。その複雑さは、それを生み出した人間達の手にも余るようなものでした。そんな時に、ソフトウェアが誕生します。ソフトウェアは、誕生とともに人間社会の複雑さをどんどん吸収し始めます。最初は、手書きの伝票と算盤を使って行っていた作業をバッチ処理とドットインパクトプリンターのけたたましい作動音に置き換えるような仕事が多かったようです。ソフトウェアの効果は抜群です。一度動き始めたシステムは、間違えることなく、同じ仕事をこなしていきました。複雑さの封入に成功したわけです。
目の前の複雑さから開放された人類は、末永く幸せに暮らしたかというと、そうではありませんでした。あろうことか、封入された複雑さを足がかりに、自分たちの社会を更に高度に複雑化させたのです（ああ、なんでかわいそうな生き物なんでしょう！）。
そして、それからは、ソフトウェアと人類は二人三脚のパートナーとなり、一緒に歩み始めます。ソフトウェアは、人間社会の複雑さをどんどん取り込んで肥大化していきます。そして、人間社会は、肥大化したソフトウェアの上に更にソフトウェアを組み上げていきます。
今では、天にも届くような巨大なソフトウェアがネットワークを張り巡らせ、ぐるりと世界を覆っています。人類は、その上に築いた楼閣の上で、自分たちの複雑さを誇り、繁栄を謳歌していました。
そして、そんな二人のパートナーシップは永遠に続くかと思われました・・・
続・ソフトウェアの複雑さについて
っと。うっかり物語調になってしまいました、しかも、ソフトウェアがなぜ本質的に複雑なのかについて、伝わるような伝わらないような。
話を戻すと、ソフトウェアは複雑です。そしてそれは、逆説的に言えば、人間社会の複雑さを反映するという性質上、複雑でないソフトウェアは、役に立たないと言えるでしょう。
この前提に立つとすると、プログラマーは、どこまで行っても苦労してコードを書く必要がありそうだということです。
ソフトウェアの複雑さに対抗する
では、プログラマーは、ソフトウェアの複雑さに合わせて複雑なソフトウェアを書き続けなければならないのかというと、そうではありません。
ソフトウェアの複雑さは、難しさに変換できるのです。
これは、質量保存の法則のようなもので、相互に変換可能なものだと考えます。簡単にすると「複雑さ×難しさ＝ソフトウェア」のような式で表せる筈です。
ここでいきなり「ソースは俺」の話になります。
JavaやRubyやC/C++やDelphiやScalaやHaskellを扱ってきましたが、同じ言語を扱っていても、より高度に抽象化されたライブラリやフレームワークを利用し、コードを短くしたほうが複雑さは減ります。同じ問題を扱うのであれば、より難易度の高い機能を扱える言語のほうが、コードの複雑さは減る傾向にあると思います。
もちろん、自分で書くプログラムでも、より難しいテクニックを使用したほうが、コード自体はシンプルになるということは、多く経験してきました。実際には、「本質的な複雑さ」を取り巻く「偶有的な複雑さ」も多いし、単純にノイズの含有率もあるので、一概には言えませんが、そう感じさせる何かが潜んでいるのは間違いないと思います。
結論すると、ソフトウェアの複雑さに対抗するには、ソフトウェアをドンドン難しくしていけば良いという事になります。
なんか、パワーが足りなければスピードで補え！みたいな身も蓋もない話になって、軽く絶望しますが、プログラマーの宿命として諦めるしか無いですね。
難しさに挑戦せよ
今後のプログラミングの進化の方向性ですが、一言で言うと「難しくなる」と思います。
ソフトウェアの複雑さは、放っといても肥大します。それは、自分が今向かい合っているソフトウェアでも言えることだし、マクロな視点でソフトウェア全体を見た時にも同じことが言えるでしょう。
それに対抗するためには、ソフトウェアを難しくしていくしかありません。こちらは、放っといても何も起きません。自分のレベルが上がらなければ、昨日と同じ難しさのソフトウェアを書くだけです。
意識して、より難しい話題に挑戦するべきです。プログラマーとしてのレベリングが必要です。
このレベリングは、かなりのクソゲーで無理ゲーです。トッププログラマーたちは、今でも新たな複雑な話題に取り組んでいます。しかし、少なくとも複雑さの増加スピードに比べれば、進歩のスピードはゆっくりとしているし、先端に近づけば近づくほど、範囲が狭くなっていくという特徴があります。
どっちに進むもどうせ地獄なら、チャレンジしてみても良いんじゃないでしょうか。なんせ、
オレはようやくのぼりはじめたばかりだからな
このはてしなく遠いプログラマー坂をよ…
未完
