日経SYSTEMS「設計ミスをなくそう」特集でのインタビューで思ったこと

日経SYSTEMS 3月号「設計ミスをなくそう」特集でインタビューいただいた。事前に大まかな話題をいただき、「俯瞰的な話」として回答差し上げた。ソフトウェアレビューを研究テーマの1つとして進めているので当然なのだが、普段細かい話や計測結果等を相当に近視眼的にみているので、視点を変えて考えるよい機会をいただけたと思う。

詳細は日経SYSTEMSをご覧いただきたいが、事前の話題をいただいた時点で考えたことは以下のとおり。

• ここ10年くらいの文献の変化をみると「網羅的にとにかく全てのエラーを発見する」という考えから規模の増大に伴って「どこ（あるいは何）に注力してエラーを発見するか」という考え方に変わりつつある。（そのようなレビューが適しているソフトウェア、プロジェクトの割合が増えてきていることを反映したものだと思う。これにあてはまらないものもあるだろう）
• レビューの形骸化の主要な原因には、作業量が多すぎる、目標設定が不明確（でどこまでのレベルの指摘をしてよいかわからない）、（なぜか）プライドを守る場になっていて指摘を認めない、あるいは、それを察して指摘自体をしない、が挙げられる。
• 開発担当者が自発的にはじめるアドホックなレビュー（部分的かつ臨機応変に実施する）を、網羅的、計画的に実施するレビューにスケールアップする際には、いろいろ役割分担を考えて負荷を軽減する仕組みが必要。

特集はレビューの問題点と解決策、様々な組織での工夫が紹介されていて、とても参考になる。私の研究グループでも相談ベースで様々な組織の方とお話をしたり、アンケート調査等で現状把握したりしている。それらを踏まえて読んでみても特集の内容は的確だと思う。

また、紹介されている組織におけるプロジェクトの事情やソフトウェアに求められる要件に対して、どのような工夫をされているかを読み取ることが大事だ。もちろん事情や要件が一致していれば、その工夫を取り入れるてもよいし、別に「たいへん気に入った」という理由でもよさそうに思うが「～だから、…の工夫をしている」という背景を理解した上で工夫や技法を取り入れておけば、使わなくてもよい状況を判断したり、カスタマイズ、テーラリングする際に役立つ。ソフトウェア開発全体にいえることだと思うが、成功事例を丸々コピーしてうまくいくことはなかなかないだろう。

また、同特集には1ページの記事を寄稿した（レビューの形態の分類を書いた）。また、ソニー永田氏のインタビューや日本IBM細川氏の記事も掲載されている。いずれも興味深い。一読されてみてはいかがだろうか。レビューの特集ではないが、同誌の「事例に見る 問題解決の軌跡 東京証券取引所　1500枚の要件定義書に困惑，リスト化し設計レビューを進める」という記事も興味深かった。ここから購入できるようだ。