経済的な視点を持ってソフトウェア開発を見直す

先に書いたエントリーで、「経済的な」という単語が出てきたので、ちょっと補足。

「経済的な」というのは、費用のことを考えてプログラミングをする（ソフトウェア開発をする）ということで、マクロ的なところではオフショアな話から、ミクロ的なところでは2時間悩むぐらいであれば3000円の書籍を買ったほうがよい、という話だったりします。

対費用効果を考えるとき、学生時代には時間がたくさんあった（たくさんあった、というよりもお金がなかった）ので、費用（経費）のほうが時間よりも大切で、自分で調べるなり先輩に聞くなりネットで調べるなり（当時はネットなぞなかったので、図書館でってことになりますが）する方法を取るわけですが、いざ社会人になって「プロ」になる、時間の費用のほうが高くつくので、なにかと費用を掛けたほうが手早くできあがったりします（無料にこだわらなくてもよくて、ある程度の費用ならば捻出可能であるという意味で）。

これをソフトウェア開発のプロジェクトという枠で捉えると、プロジェクト自体の予算があり、人件費があり、ということで、割り算すれば単位時間あたりの費用が簡単にでてきます。この単位時間あたりの費用を如何に有効に使うかとうことが優先される…はずなのですが、まぁ、そうでないこともたびたびなのですが。

なので、作業時間というものを見積もった上で、その作業時間が自分の単価により非常に高くつくのであれば、別の手段に置き換えたほうが安く済むイコール「効率が良い」ということになります。ここでいう「効率」というのは、対費用効果という視点からですね。
なので、「2時間ほど悩むのであれば、3000円の書籍を買うほうがよい」というパターンは、あれこれとネットで探して悩むよりは、さくっと初心者本なりを買って、その数ページだけを活用してしまえばよいということです。それで、その本の価値（この場合は私から見た価値）は十分足りているということになります。
なんか、非常に効率が悪いように見えますが、本屋での立ち読みよりも、さっくりと amazon で買うなり、本屋でざっくりと選別して買うとい方式を取ります。
業務に使う場合は、専らこのパターンです。資料的に切り取りという感じで。

これを、もう少しマクロな視点からプロジェクトでの開発工程全体に広げてみると、

• ツール購入の対費用効果
• 自動化ツール作成の対費用効果
• 重箱の隅的な議論の対費用効果
• 複雑すぎる仕様に対する対費用効果

などを考えていきます。IT 屋さんの営業的には、ツール購入の対費用効果が持ち出されるわけで、過剰なところでは「5秒の作業時間が削減できます」とかなんとか。昔、実際にあった宣伝文句です。
が、そのツールを購入して習熟して実行するところまで考えたときには、ツール自体に費用に値するかどうか、は結構別な話で、むしろ、「習熟して実行する」ところまでの対価（イコール人件費）のほうが大きくて、対費用効果がマイナスということもあります。つまり、ツール自体が0円であっても、習熟までの人件費を考えれば、マイナスうん十万円という損が出る可能性があるということです。

どこかの経済書か経営書にありましたが、結果的には人には「時間」のみが平等に割り振られているわけで（時間の少ない方もいるんので、必ずしもそうという訳ではありませんが）、どの位の時間で何をするのか、それがオーバーしそうなのか、オーバーするのであれば作業を止めるべきか、ということまで考えて行動すると、「経済的な」ソフトウェア開発に近づきます。

と言うほど、私自身はできていないわけですが、業務的なところは業務的なところで追及するとして、人生の楽しみとしては楽しみとして追及させていただくという話です。談志のように？