計画と納得

計画をたててみたが合意が得られず、単なるメモ書きになってしまうことがある。計画をたてることはテクニカルな領域で解決できる場合があるが、合意はテクニカルな領域だけで解決することは難しい。

両者は一体と考えることもできるし、別々のものと考えることもできるだろう。これらは主従の関係にはなく、計画と納得のバランスが大事だと思っている。ソフトウェア開発全体において計画と納得が不十分という議論や意見もありそうだが、ソフトウェアレビューでは、特にその傾向が顕著ではないかと思っている。

次のような場面に出くわしたことはないだろうか？（@ITの記事より抜粋）

──ある日のこと……

担当者	「Xサブシステムの設計レビュー、どうしましょうか？」

リーダー	「エラーを見逃すと、結合テストのときにバグがたくさん出るだろうしな、きちんとレビューしておこうよ。C課長、D主任、E主任、あとは君と私でやろう。日程調整してもらえるかい？」

──ところが、レビュー会議当日になってみると……

D主任	「これはまだレビューできる状態じゃないと思いますね。例えば『機能一覧』なんて抜けが3カ所もあるし。それよりさっき顧客から電話があってね、そっちの対応が緊急なので、すみませんが抜けさせてください」

リーダー	「仕方ない……。ところで、E主任は？」

担当者	「来るはずだったんですけど、どうも外出中のようです」

リーダー	「……Cさん、すみませんが、3人でやっちゃいましょう」

C課長	「よし、じゃひととおり説明してくれる？ まだ読んでないんだよ」

リーダー	「はい。まず『機能一覧』ですが……」

C課長	「ふんふん、なるほど。ところでさ、最後のページの用語集なんだけど、用語を選ぶ基準が不明確だよね。今日はとりあえず用語集を徹底的に修正しよう」

リーダー	「……はぁ」

──Xサブシステムのソフトウェアテスト結果を見て……

リーダー	「うーん……。異常系のテスト結果がひどいな。設計レビューでの見逃しが多すぎる」

ここには2つ問題がある。1つは計画が不明確であること、もう1つはそもそも関係者がレビューに関して納得していないことだ。他の開発アクティビティにおいてここまで大胆に計画を逸脱されてしまうことはそれほど多くないだろう。たとえば、テスト計画を大幅に変更して独自のテストをやろう、と言いだすメンバはいないだろうし、テストをさぼってどこかに行ってしまうメンバがいれば、問題になるだろう。現状では、レビューではこれが見逃されてしまう組織もあるのではないかと思う。

そこで、レビューの計画の立案、関係者を巻き込むやり方の1つとして、@ITに記事（「全関係者の“納得”が、レビュー成功の大前提」）を寄稿した。何らかの気づきを提供できれば幸いだ。