開発プロセス論

http://d.hatena.ne.jp/tonotonotono/20050623#1119490901

開発プロセスを持っている技術者に張り付き、手順を逐一メモして、判断基準となる事柄を羅列する。何がどうだからコレはいい、わるい。今どういう状況が出てきたからあれをやろう、これをやろう。などなど。この気の遠くなるような手間隙をかけて取得したメモを元に、高レベル技術者のロジックを丸裸にするのを繰り返した後にでも、集計作業を行えば何かしらの共通点はみつかると思えるしねぇ。( ´∀｀)

統計を取れるからといって，その統計に意味があるとは限らない．むしろ意味のある統計を取る方が難しい．

統計でウソをつく法―数式を使わない統計学入門 (ブルーバックス)

ことソフトウエア開発に至っては，そもそも生産性を計測すること自体が不可能に近く，「何がベストであるか」を知ることさえ容易ではない．またソフトウエアの設計を表記する方法も，計測する指標も未だ存在しない．幾つかのメトリクスは存在するしそれなりに役に立つが，絶対的なものにはほど遠い．

もっとも，そういう意味でのベストプラクティス集ならとっくに出ている．ただし，それを理解し活用するにもそれなりの専門技術が必要になるし，それを使ったからと言って，あらゆる開発で絶対に失敗しないという保証はない*1．ベストプラクティスは，誰でも簡単に高い品質のソフトウエアが失敗なく確実に作れるようになるという，銀の弾丸にはならないのである．

しかして、標準化に繋がる道はちいさな可能性はここに残ったのだ。あとはだれがやるか〜だ。

計測する人はまだいい．最大の課題は計測される側，シグマ計画と同じく「一体誰が犠牲になるか」だ．

「どこのバカが自分の作ったベストプラクティスを，それを開発プロセスとして使う将来の商売敵のために無償で提供するのだ？」

これはナレッジマネジメントにおける基本的な課題だ．*2

*1:誰にでも理解でき，皆が認めるベストプラクティスは「常識」と呼ばれるようになる．MVCやgoto文不要論，デザインパターンなどがコレだ．

*2:ナレッジマネジメントにおいては，通常は「知識」そのものに対する(相当な)対価の支払いという形で解決する．しかしソフトウエア開発では値段付けが難しく，そもそも開発者に対する評価やその知識や技術のように形のないものに対する評価も異様に低い．書籍についても「専門書は全然儲からない」というのが，物書きの常識になっている．それがどれほど優れた名著であったとしてもだ．この状況下では専門家のベストプラクティスに対する対価が雀の涙ほどになるのは目に見えており，優れた技術を持つ真の専門家が協力してくれるとは考え難い．