月単価切り下げ圧力の根源について。
時給で働くような技術者の単価が切り下げられていくのは仕方がない気がします。市場で価格が決まるからでしょう。
これから書くのは、ムーアの法則のソフトウェア部門についてです。
何度いっても分かってもらえないのですが、純粋な最終製品としてのソフトウェアはごくわずかなのです。シェアウェアを売って稼ぐとか、特殊な演算をまとめたライブラリパッケージとか。
ほとんどのソフトウェアは、ハードウェのおまけであったり、サービスを実現するための手段でしかありません。
極端な場合では、部品表から部品を減らして見かけだけのコストダウンを実現するためだけのプログラムまであります。
製品自体のコストダウン圧力は競争によって常にかかりますから、製品全体からすればごく一部分にすぎないソフトウェアに対する圧力もまたかかりつづけるのです。
ご存知の通り、ムーアの法則に従って、1年半ごとに半導体のトランジスタ搭載数は倍に増えます。しかもコストは同じです。
DRAMなら、容量が1.5年で倍になるのです。フラッシュメモリも半導体なので、DRAMと同じように容量が増え続けます。ハードディスクは少し事情が違うようですがSSDに追い上げられればゴードンムーアの呪いから逃げることはできないでしょう。逃げ切れなければ消え去るのみです。コアメモリのように。
増えるメモリは何かで埋めなければなりません。ソフトウェアの肥大化はときおり議論になるようです。最近もBKさんがネタにしてました。
Joel on Software – ストラテジー･レターIV：ブロートウェアと80-20の神話
ジョエルさんの記事を引用されているわけですが、リンク先を読めば分かるように、ソフトウェアの肥大化について占有メモリや外部記憶装置のサイズを指差して批判するのは的外れだということです。
また、純粋にソフトウェアについてだけ肥大化の問題を議論するのも的外れかもしれないことをささやかに指摘させていただきます。
増えるメモリと外部記憶を埋めるためにごみデータとごみコードでかさ上げしても、誰も買ってくれません。
ですが、同じコストで1年半後には倍の容量を得ることができるのは誰もが同じ条件なのですから、1年半後にリリースするソフトウェアを開発している暢気なみなさんは、それを念頭に置かなければならないのです。そうでなければ、無駄に無意味にダイエットした寸足らずのソフトウェア機能によって、確実に競争相手に水をあけられてしまいます。
省メモリやインストールサイズが小さいことをカタログのスミに売り文句として書くのはかまわないが、追加機能は1年半後に倍になるメモリサイズを超えなければいくらでも搭載してよいのです。
時折見かけるのは、アプリケーションの開発現場で、使用メモリサイズのグラフを描いていることです。それがムーアの法則に収まっているにもかかわらず、
使用メモリ削減計画
なるものをうちたて、さらに
各モジュール、各レイヤごとのノルマ
まで設定して、1年もかけてせっせとコードのダイエットをしている間抜けな様子もしばしば見受けられます。しかも100MBの使用メモリが10MBになるわけではないのです。
ご丁寧にもグラフには、
メモリ1MB当り10ウォンコストかかる
などと赤字でキャプションがつけられているのです。その10ウォンは1年半後には5ウォンか3ウォンに下がっているでしょうに、1年で50人月も100人月もかけて『見事なコストダウン』を成功させるわけです。
それがどれくらい間抜けなことかお分かりでしょうか。ジョエルさんの有名な「作り直しはアカ～～～ンいうてますのんや～～～！」（ここで山田スミ子のアップとBGMとともに赤フン男登場）というのがありますが、
同じ工数を機能追加に振り向ければ、何個追加できるでしょうか。
もちろん使用メモリのダイエットは、フィールドに出てしまったハードウェア製品への保守作業としてはある程度の効果があります。ですが、保守は保守です。どうせなら増設メモリを売ったほうが、ダイエット失敗でエンバグして迷惑をかけるよりもユーザは喜ぶでしょう。もっと言えば、メモリが倍増した後継製品に買い換えてもらうロードマップを示すほうが生産的でしょう。
誤解して欲しくないのですが、リファクタリング全般に対して批判しているのではないことです。動作速度や、保守性の向上のためなら既存のコードを弄繰り回してかまわないと思います。ただしプログラムは書くよりも読むほうが難しいので、きっと高くつくでしょう。グランドデザインが悪ければそれの改良版もいまいちになりますしね。それと、動作速度にも法則があるので、基本アルゴリズムの変更などのようなドラスティックな手法でない限り、やるだけ無駄の場合もあります。
最後にコストの話に戻ります。倍のサイズのメモリは1年半待てば誰でも手に出来ます。倍に増えたメモリをコードとデータで半分ずつ担当して埋めているとすると、コードを1年半で倍に増やさないといけません。
極端な場合、2010年末に100万行のコードツリーがあるとしたら、2012年の夏までには100万行追加しないといけないのです。
ちょっと耳寄りな情報：OSのカーネルや広く使われるライブラリはほうっておいてもムーアの法則にしたがって肥大化してくれます。カーネルが対応するハードのリストを増やしたら、そのハードを搭載すればドライバやモジュールの追加でメモリを埋めることが出来ます。同じライブラリを使っているだけでも、より新しいバージョンのソースに差し替えてリコンパイルするだけで使用メモリは増えているはずです。ただし、まれにメジャーバージョンアップで使用メモリを劇的に減らしている場合があるので、リリースノートは慎重にチェックするべきです。（笑
過去に100万行のコードを書くのに3年かかったのだとしたら、その2分の1の期間で同じ100万行を書かなければならないのです。
人月の神話が成り立つ泉の周りでは、過去3年に投入した人月を1年半の間に投入すればよいことが簡単に分かるでしょう。しかしそれでは年当りの開発コストが2倍に膨らんでしまいます。
同じ年当りの開発コストで、となれば、開発スタッフの時給を半分に値切って倍の人員で臨むしかありません。
ここでは分かりやすい例を書きましたが、ムーアの法則の影響を一般化すれば、1年半ごとに、時給は半分になるはずです。同じ人員で期間を倍にするのがどうしてだめなのかは説明するまでもありません。
手取りが半分にならないのは、いくつか要因が考えられるでしょう。
- 同じプログラム行数でより多くのメモリを埋める方法論が適用されている？
- コードを書くのが早くなっている？
- コンパイラがどんどん馬鹿になっている？
- 意外とデータの肥大化速度が速い？
- 間抜けな調達部門が割高なメモリを買っている？
- 中抜き業者の企業努力？
- 予算はオーバーするものさ（肩をすくめる）
- ひとカゴのパンを300人に分配する奇蹟？
毎年同じ開発費を投入できる場合の話です。縮小し続けるような市場に対する製品などではムーアの法則を無視した、談合や寡占で乗り切るしか選択肢はありません。その先は尻すぼみです。
目次：
