つまり、ソフトウェアのあらゆるパラメータで、要求が低いときには工夫をしないほうが品質が高くなるという法則。
たとえば、アルゴリズムというのは理論的にはデータが増えたときに性能悪化がゆるやかなもののほうがよいということになってる。
でも多くの場合で、よいアルゴリズムは、少ないデータ数では単純なアルゴリズムに負ける。ソートなんかだと、データ数が一定以上のときはクイックソートだけどデータ数が少ないときはマージソートを使うということがよく行われる。「指数時間」かかると言われるアルゴリズムは遅くて使い物にならないということだったけど、それをがんばって「多項式時間」という使い物になるはずのアルゴリズムに改良したら複雑になりすぎて、通常のデータ数なら「指数時間」のアルゴリズムよりも遅いということがよくある。
データの格納にしても、データベースは便利だけど、データ数が少ないときは単純なテキストファイルのほうが検索も速かったりする。
セキュリティでも、日常業務のためのパスワードくらいだと、凝った仕組みを考えて長いパスワードを定期的に変えてもらうより、短いパスワードを使い続けてもらったほうが、トータルのセキュリティが高くなったりする。複雑な運用だと、パスワードを紙に書いて貼る人が増えたり、覚えれなくて平文メールで問い合わせる人が増えたり。
使いやすさも、ソフトウェアが小さかったり短期しか使わなかったり教育が行き届かないときには、あまり凝らないほうがよかったりする。紙をいかに使うかが大事になったり。
こういったことは、あたりまえのように受け入れてるけど、あまりにも どのパラメータでも成り立つのが面白い。そしてソフトウェアの社会的性質を決めてる。
実は、この法則があるからこそ、アイデアだけでも勝負できるソフトウェアができる。要求が低いときには、むしろソフトウェアを不勉強な人が短時間で作ったシステムのほうが便利だったりする。
そうでなければ、あらゆる分野を勉強した人じゃないと実用的なソフトウェアは作れないということになってしまう。
そして、今まで「高い要求」だったものが、ハードウェアの進歩とライブラリの普及で「低い要求」になっていってる。
そこで、どんどん、あまり勉強しなくてもそれなりに役に立つものが作れるようになってる。
逆に、差をつけようと思って勉強しても、少々のことでは「低い要求」として可能な範囲を越えたものは作れず、目に見える差を出すことが難しくなっている。
とはいえ、ソフトウェアでメシを食っていくからには、なんらかの差をつけたい。
そこで、この、低要求のときの工夫したものと工夫してないものの品質の逆転について、一般的な性質があるのかとか、考えてみると面白いかなと思ってみた。
あと、ソフトウェアの性質として、明示的に踏まえておいたほうがいいんじゃないかと。
