一條です。
私が言ってもあれなんで、
デマルコのピープルウェア 新版のＰ．２４３の上段に書いておることをお読みくだ
さい。
また、整理しなおしますが、濱井さんが言っていたのは、
「コスト削減を生産性向上というな。」
これだけであって、コストを計るなとも、
見積もるなとも言ってないわけですから、
手戻って議論を仕切りなおしてください。
少なくとも、効率化だけで生産性向上を図るべきではなく、
必ず価値を伴って判断すること。
価値のほうが優先順位が高いこと。
この主張を認めるのならば、別に認識の相違はないことになります。
極端な反例といいますが、
計測して評価基準となった数値には、恐ろしい力が宿ります。
ディスファンクションの罠はいたるところに仕掛けられることになるのです。
少なくともソフトウェア開発組織のテーマが
開発効率の向上。
あと１０％ソフトウェア開発を効率化しよう。
こういうテーマで部門全体が運営されていない場所にいることが重要です。
大丈夫ですか？
さて、上のようなスローガンでやっていた場合、
ユーザからクレームがあがりました。
対してどう反応しますか？
客：「ＸＸという機能だが、私が思っていたのとは違う。直してくれ。」
あなた：「いえ、これは、数ヶ月前にきちんと承認印をもらっている正式仕様で
す。」
客：「そうだっけ？しかし、それは違うんだよ。こういう意味なんだ。」
あなた：「そうなのですか？でも、もうすでに、仕様書に書いてあるように全体が動
いています。ほぼ開発完了していますし、これからやりなおすわけにはまいりませ
ん。」
客：「...」
部門で開発効率の向上があげられているのならば、手戻りは大きな失点になります。
あなたは絶対に避けなければならないのです。
機能仕様書にはハンコも押されているし、プロセス実行状況は完全です。
ＣＭＭレベルも維持できる見込みです。
客をいつものように、丸め込んで納得させればすむ話なのです。
さぁ、どうですか？
いつものことだから別にどうってことはないのですが、
計測して第一指標にすればそれが常態になります。
結果は、客とあなたの会社の信頼関係の減少でしょう。
１，２箇所だけなら別にかまわないのですが、
全部その調子で大丈夫ですか？
そして結局は、単価を下げられる。
あるいは、単価があがることはなく、
最悪は、乗り換えられるハメになるわけです。
これでも、効率化を第一指標にしますか？
濱井さんが問いかけているのは、そういう点なんだと思うのですが、
なぜ、そこに思いいたらないのかが不思議です。