引き続いて昨日の勉強会のネタです。メモは取ったもののだんだんと記憶があやしくなってきております。森崎さんのお話で、とても意外に思ったことがありました。

ソフトウェア開発の進捗度合いを管理するために、バグの発見件数とその解決に要した時間を把握するためのグラフを作図することで分析を行う手法があるそうです。そのグラフに出現したピークを早めに見つけることで、後工程で起こり得る問題を未然に防いだり、軽減したりできるのでは？というお話でした。

質疑の時間に、「個人単位で作成しないんですか？」という質問が出ました。結論的には、個人単位で作って「お前はバグが多いからだめなやつだ！」というつるし上げはお勧めできないそうです。仮にやるならば、経験年数ですとか、スキルレベルなどで分類をすることで、集団としての傾向・法則性を見つけるようにするとのことでした。

これは意外でした。私は情報処理技術者試験のプロジェクトマネージャの試験に合格したときに、午後2の試験で個人をつるし上げる内容の論文を書きました。もちろん、実際の現場ではよほどの人が来てしまわない限りそのようなことは起こり得ません。あくまで論文の話です。そもそも問題文が「プロジェクト遂行中のチームの再編成について」という課題であり、要員スキルの見込み違いなどがあったら交代も検討しますよね？あなたならどうします？というものでした。私の回答は、ドキュメントの不具合指摘率などで要員の管理を行い、ひどいやつがいたから交代してもらった、というような要旨になりました。（一番強く主張したのは、要員のOUTよりも代わりの要員をINさせるための「見つけ方」でした。）

その事を昨日の話を聞いてから考えてみると、確かに個人を追い出してもお互いに得るものがありません。クビにした人は二度と戻って来ないケースが多いでしょうし、首にした側にまた別の悪い人が来たら同じ事の繰り返しになってしまいます。しかし、何らかの属性を持つ集団がいけてない人達だった場合は、「お前ら揃って明日から来なくていい」といっても代わりの要員が調達できないことでしょう。ですのでその代わりに、類似プロジェクトでは同じ属性を持つ人をそもそもアサインしないですとか、アサインする場合は仕様の説明やレビュー規約、コーディング規約などを工夫することで品質を確保できるかもしれません。

個人攻撃を認めると、品質記録で嘘をついて良く見せようとするということも多発するかもしれません。うろ覚えですが、航空事故などでは、事故を起こした機長は正直に話す代わりに責任を軽くされることがあるそうです。同様に、正確に品質記録を提出してもらうためには、「正直に報告したらプロジェクトを外された」というケースを無くさねばならないでしょう。

ということで、2日連続になってしまったのですが森崎さんならびにEASEプロジェクトからは多くの気付きをプレゼントされました。ありがとうございました。

# 森崎さんによると、ソフトウェア開発に関するどこかの研究者憲章で「個人のダメなところを明確化して、摘まみ出すような研究はしてはいけません」という項目があるというようなことをおっしゃっていたような気がします。ソースを聞きそびれてしまったため、ご存知の方は良ければ教えて頂けると幸いです。

# 2007-09-27 森崎さんのコメントを受けて追記
上の段は、正しくは『個人のスキルを評価する（ひいては個人の排除の引き金となる）ことだけを目的とした研究論文を採録することを推奨しないコミュニティがある』とのことでした。 なるほど。