今日はROMを焼き終えて一区切り付いてから、プログラマ全員に「明日の日曜は強制休み」との通達があった。大晦日・元日を除けば２ヶ月半ぶりの休み。あまりに突然で心の準備ができていない。こんな状態で休むのもなんだか不安で落ち着かない。何をしようか？
■ プログラミングとは経営判断の集積である 
どの部分を汎用的につくり、どの部分をやっつけで作るか、そして、どの部分をパフォーマンス優先でつくり、どの部分を可読性優先でつくるかは、そのソフトウェアステムを使って今後どのようなビジネス展開をするか、ということと一体不可分だ。プログラマーは、絶え間なく改変されていく部分と、財産として今後も使われつづけそうな部分を意識しながらコーディングする。そして、ここでいう財産とは、プログラマが財産とみなすものであるだけでなく、同時に経営的・財務的な意味においても財産であり、会社のバランスシートの「資産」の項目に登場するような性質のものだということは、多くのエンジニアが漠然としかいしきしていないように見える。
そして、それがいかに困難な作業であるかを、エンジニアが十分に理解してないケースがよくある。経営やマーケティングの人間が、ソフトウェア開発について無理解であり、理不尽な無理難題を言ってくるのの逆だ。ソフトウェア開発は、高度な頭脳労働であり、高度に知的な判断が必要であり、単なる「製造」という行為とは、まったく異なる次元のものだが、そんなことは、営業や経営の人間には漠然としか理解できていないし、甘く見ている。だから、エンジニアが、ビジネス的に大切な仕様変更に対して「技術的な理由」から抵抗すると、頭に来て、影でそのエンジニアの無能さをこき下ろす。ボロクソに悪口を言う。しかし、じつは、経営やマーケティングも、ソフトウェア開発と同等か、時としてそれ以上に、高度な専門的スキルを要求される、高度な頭脳労働なことを、実感値として理解しているエンジニアはほとんどいない。だから、多くのエンジニアは、自分がマーケティングや経営のスキルを磨く訓練をろくにしてもいないにもかかわらず、どのような技術仕様にすべきかを自分は判断できると思い込んでいるし、技術的にやっかいな仕様変更を要求するビジネスマンや経営者の陰口を叩くことはさほど珍しいことではない。
なんとなく自分がすっきりするから、という独りよがりで脊髄反射的な判断で、あるルーチンをクラスライブラリにすることに決めてしまったりするなどのように、資本のコストという、財務分析においては基本中の基本とも言える大切な概念が、エンジニアに決定的に欠落していることが珍しくない。資本のコストを考えるなら、資本は常に、利回りを生み出すものだから、そのクラスライブラリによって、得られるメリットを利回りに換算して、その労力を他のことに使った場合の利回りと比較してみなければ、そのクラスライブラリを開発すべきかどうかは判断することはできないはずだ。たとえば、そのルーチンを共通化することに時間を使うのではなく、ほかのやっつけアプリをさっさと仕上げて売り上げをたてて、さっさとキャッシュをゲットして、そのお金で別の人間を雇って、より多くのやっつけ仕事をやらせて、それで浮いた時間を使って、クラスライブラリを開発した方が、結局トータルの利回りはずっと大きいかもしれないのだ。少なくとも、そういう思考スキルを持っているエンジニアとそうでないエンジニアでは、同じ一行のソースコードが生み出す価値の単価が大きく異なってくるだろう。
