お客様から発注されたソフトウェアを請負で開発する場合に悩ましいのが、顧客(発注者)レビューの扱いだ。そもそもソフトウェアの設計をレビューすること自体が難しいアクティビティである。その難易度に加えて、ソフトウェア開発の専門家ではない顧客(発注者)に要求や設計をレビューするのだから、相当難しい。結果として、大量の顧客(発注者)指摘事項が出てきて途方に暮れる、というのがソフトウェア開発の現場でよく見る風景だ。顧客(発注者)レビューのうまいやり方というのは無いのだろうか。
指摘に苦しめられた(?)特許庁システム
膨大な指摘で苦戦する話、で思いだすのは2012年初めに報じられた特許庁基幹システム刷新中止の件だ。公開されている議事録別紙資料などを見ると目眩がするようなグラフが書かれている。スライド9ページあたり。
- 特許庁情報システムに関する調査委員会報告書(技術検証チーム)ご指摘に関する状況について(PDF)
- プロジェクトのマスタースケジュールがよくわからないのだけれども、2010年12月に60MStepの見積りが出されているようだから、まだ設計関連のフェーズだったんだろうか
- 2010年7~8月に設計書の1割をチェックしたら2600件の指摘あり
- その後残件を解消していくが、横展開で要対応数はむしろ増加
実際のところがどうなのかはわからないけれども、大量の指摘によってソフトウェア開発プロジェクトが破壊されていく様は想像に難くない。指摘事項とその対策はソフトウェア開発プロジェクト序盤戦における大きな山場だと考えている。
顧客レビューの難しさ
過去に読んだ事のある書籍でも、あまり「顧客レビュー」に関して書かれたものは無いような気がする。ネットで少し調べてみてもあまり参考になる情報は見当たらない(検索ワードがうまくない可能性はあるのだけれども)。というわけで、勘と経験で顧客レビューの難しさについて考えてみる。
指摘の品質に関する問題
以前にてにをは症候群とその処方箋という記事でも書いたのだけど、開発者が欲しい指摘やフィードバックが得られず、意図しない書き振りに関する指摘(例えば「てにをは」についてのコメント等)が大量に湧いて出てしまうことがある。レビュー実施のタイミングで、狙った品質の指摘を貰えるようにする必要があるのだけれども、あまり有効な手が無いように思う。
- 要件定義フェーズ
- 開発者が欲しいのは例えば「スコープの漏れや過不足に関する」フィードバック
- 顧客(発注者)から指摘されがちなのは「全体よりも個別各論に関する点」や「誤字脱字・形式、微細欠陥」に関するもの
- 設計フェーズ
- 開発者が欲しいのは、リスクの大きい重大な認識相違点についてのフィードバック
- 顧客(発注者)から指摘されがちなのは「誤字脱字・形式、微細欠陥」に関するもの
ソフトウェアライフサイクルと契約
狙った指摘が得られにくい理由の一つに、顧客(発注者)側のソフトウェアライフサイクルに関する不理解と、契約に関する恐れもあるのではないかと考えている。
- どのフェーズ(工程)で、どのような問題を見つけるべきか
- どんな問題は見逃しても良いのか判断できない
- 問題のリスクの大小が顧客(発注者)側では区別できない
- 実際には、上流工程における各論は後続工程で洗練・詳細化されていくので早い段階で確定する必要はなかったり、微細欠陥についてもテストの局面で自然と解消していくことも多いのだけれども、このあたりが顧客(発注者)とうまく共有できない
- 特にウォーターフォール型開発プロセスに顕著な「後戻りできない」恐怖
- 「言い忘れた事があると、後で追加請求されてしまうのではないか」
- ある種の見落としはプロジェクトに大きな手戻りを発生させ得るのだけれども、そうでないものもある。どういった種類の見落としなら許容されるのかを顧客(発注者)とうまく共有できない
では、どうすればよいか?
手元で実験する手頃なプロジェクトが無いので机上の空論になるのだけれども、例えばこのような進め方をすれば顧客レビューが上手く行くのではないかと考えている。
ソフトウェアライフサイクルも意識したレビューポイントマップをまず顧客(発注者)と共有する
まず、フェーズ(工程)におけるレビューの目的と狙いをきちんと整理して顧客(発注者)と共有するのが良いと思う。
- レビューの目的
- どのような指摘が重要なのか、または重要ではないか。重要度を判断するための簡単な指針
- 何を見つけるべきか。逆に見落としてもリスクの低い事項とは何か
- このフェーズで「確定」するものは何か。逆に「次工程以降の指針であり確定事項ではない」ものは何か
- どんな見落としが仕様の変更やコストの変更に繋がるのかについての情報提供と共有
- どのような指摘が重要なのか、または重要ではないか。重要度を判断するための簡単な指針
また、「誤字脱字・形式」に関する指摘の取扱いもある程度話し合っておいたほうが良いだろう。
- 「誤字脱字・形式」に関する指摘の取扱い
- ソフトウェアのバグ・欠陥・不良を引き起こす可能性のある誤りは、リスクに応じて修正する
- ソフトウェアのバグ・欠陥・不良を引き起こす可能性が低い、または後続工程で十分に品質保証できる類の誤りは、指摘量に応じて修正するか否かを判断する
- ソフトウェアのバグ・欠陥・不良に無関係な誤りは、原則修正しない
レビューの練習、あるいはアジャイルインスペクション
目的や方向性について共有しても、いきなり本番の(顧客)レビューを行うのは乱暴だと考えている。本来の目的用途とは異なるのだと思うけれども、アジャイルインスペクションの考え方を取り入れて、作成途中のドキュメント等を題材にレビューの練習をすることで、レビュー指摘の品質を上げる事ができるのではないだろうか。
- アジャイルインスペクション - 目的は早期修正ではなく品質推定 -:森崎修司の「どうやってはかるの?」:オルタナティブ・ブログ
- アジャイルインスペクションの実際(PDF)
- 産学連携によるデザインレビュー改善事例(PDF)
私の念頭にあるのは「産学連携によるデザインレビュー改善事例」のスライド8のイメージである。
- 仕様書作成序盤から段階的にレビューする
- 良いレビューと、悪いレビューについて顧客と意見交換をする
- 体裁や記述方法について早期にすり合わせていく
もちろん顧客レビューについての銀の弾丸は無いのだけれども、プロジェクトの特性によって事前に手を打つことによって、できることはある気がする。