水曜日か木曜日くらいに次の資料を読んだ。
多少、色が付いているし、永和さんのエンジニアさんの資料なので、まあ、こんな感じで煽っていくスタイルなんだな～と思いつつ読んでいて、僕の苦い過去を思い出したので、少しだけまとめておくのと、やはり統計が云々なので、統計の観点から(僕は統計をよく知らん)少しだけ考えてみた。
開発体制
資料上、受託の開発体制はこんな感じでした
顧客
↑
↓
ネクタイ(顧客のことわかってない) - 品質管理のおっちゃん(開発わかってない)
↑
↓
これは、半分合ってて、半分間違ってると思いました。
おそらく、ネクタイな人が入るようなプロジェクトだと、こんな感じになるはず。
本当のユーザー
↑
↓
IT部門(ユーザーがやってることわかってない)
↑
↓
ネクタイ(開発もわからんし、仕様もわからん) - 品質管理のおっちゃん(開発わかってない)
↑
↓
何やってるかわからんおっちゃん(品質管理)
この人はユーザーがやってることわからんIT部門の人から叩かれてます。これをデベロッパーダイレクトにすると作るプロダクトとは関係のないことに煩わされてデベロッパーさんの時間がなくなります。
で、何やってるかわからんおっちゃん、とりあえず数字を見せればいいやと考えて、指標とかなんとかを作り出します。
品質指標の話
コード何行あたりバグ件数が何件というやつ、ネクタイだらけの現場に行けば指標値の上下±何%までは可的な揺るぎ(せいぜい20～30%)設定があるので、200行で1件という指標に対して400行で1件だろうが、100行で1件だろうが、50%とかでも品質に問題あり判定されるはずだし、どっちも品質悪い(前者はテストが足りてない、後者はコードの品質がアレ)と判断されるでしょう。
コード行数
コード行数が基準として出てくるなら、仕様に対しての標準的なコード行数も定めてないとダメなんじゃね？と思った。仕様からコードの標準的な行数が割り出せるか！とネクタイのおっちゃんから叱られそうですが、形式手法で仕様を記述すれば、それなりに指標となるような数値は出せるのではないかと思うわけですし、仕様に対してのバグ件数も指標となる数値が出せるのではと思ったわけですが、形式仕様記述のことよくわかってないので、こっから先は僕は口をつぐむ…
以上、どうでもよい話でした
