増12．「人月の『実』話」について

スキル

» 2012/09/10

●今回の発端

　いにしえのブルックスより現在に至るまで、ソフトウェア開発に対する報酬は人月単位で払われています。

　成果に基付く報酬など、別案もありますが、かちんとして受け付けられません。

　１つ理由みたいなものを思い付きましたので、披露致します。

●頭としっぽ

　また、アンビバレントな話です。

ソフトウェアは簡単である。

ソフトウェアは学んでも尽きないほど高度である。

　どちらも正しく聞こえます。そうすると、例によってまた、隠れた構造があることが予測されます。

　筆者は、それが「束構造」ではないかと思いました（図は、束 (代数学) wikipedia 日本語より）。

　つまり、ソフトウェアは“要求は簡単で、作っている最中は難しく、できたら簡単になる”と考えると、上記のつじつまが合うということです（もちろん上流工程の要求も、下流と実情は同じで“できたら簡単になる”のだと思います。上流工程の要求は常に簡単だといっているわけではありません）。

●成果に基付く報酬なんてとんでもない！

　これ以降、上記の構造が妥当だとして話を進めます。

　要するに、成果物で推し量られると、やっていけないほど損になるのです。どうしても成果物で量ることをされると、多分作る側は半製品を完成品だとして納品することになると思います。

　人間の根源的・部族的感情からしても、できた簡単な成果物より、途中までの難しい成果物の方に価値があり、学術的にも優れているように見えると思います。筆者も職業的立場から離れてみるなら、そうだと思わざるを得ません。

　しかーしっ！！！それはどう考えても「技術的負債」以外の何者でもありません。

●（突然ですが）資格審査報告

　この次の段で、ある侮蔑的な言葉を言いますが、筆者は言っても問題ないだろうことを示すエピソードを述べます。

　筆者は前に、汎用機のデータをRDBに変換するプログラムを作ったことがあります。その際の条件として、

VSAMのマスタは読むだけ

特定のVOL=SERで中間ファイルは作り放題

もう、その汎用機はあまり使っていないので、SUBMITもし放題

で、結局、2本マッチング、3本マッチングをぐちゃぐちゃに織り交ぜて、何とかRDBの世代データにすることができました。

　その際、つい同僚にその言葉を言ったのですが、同じフロアに居た別の会社の人が、ものすごい形相でにらんできました。しかしながら次の日、（多分筆者の作ったソースを見たのだと思いますが）「まぁ、おまえなら言ってもいいや」とかぼそっと言ってくれました。

　もちろん、これで万事とは言いませんが他社さんの（ある意味）ピアレビューとして、取りあえずこの場で、その侮蔑的な言葉を言うだけの根拠にはなると思います（その人は名前も存じ上げませんし、その後もお会いしたことはありませんが、この場で感謝したいと思います。）

●コボラーとはなんだったのか

　あーあ、言っちゃった（笑）

　しかしながら、このコボラーという侮蔑も、「束構造」で考えると見通しが良くなります。そしてもちろんかなりの部分が不当なものだと反論できるようになります。

●コボラーに対する典型的な非難

　思いつく限りでも、

コピペである。ソースを表か何かのように画一的に作る
変数を階層的に長く作る
部品化しない

　とかありますが、すべてネタは同じです。それはコボラー側には「難しい作っている最中」の状態を割り当て、非難する側は「簡単なできた」状態を割り当てているということです。上図を見ていただくと分かりますが、プログラミングが（当コラムの仮定により正しいとした）「束構造」であるならば、1．も2．も最適中の最適ですし、部品化とは出来てからが部品化で、作っている最中に部品化言われても「なんのこっちゃ」です。

●もう1つ、別の話ですが

　不案内な分野なので、ご案内にとどめますが、ソフトウェアの「見積もり」というのも、「簡単な要求」から「難しいものを作っている最中」を推し量るものだと整理できるのではと思います。もしそうなら（筆者はそうだと思っていますが）確かに大変な仕事だと思います。

まぁ、今回はこんなところです。

●コラムのコメント欄の方針

　コメントに対し、当意即妙の回答を、それなりのタイミングでする自信がありません。

　ですので、このコラムで、