レビューの基本を3つだけ挙げろと言われたら何を挙げますか？
ソフトウェアレビューの半日集中講座を担当することにしました。これからレビューをはじめようとする方、レビューの改善に携わる方に手応えのある内容にしています。「レビューを強化する」という号令の元、具体的にどこから着手してよいか悩んでいる方にも参考になる内容にしています。レビューのあるべき姿と現状のレビューとを比較することで、どこに問題点があるかを発見でき、強化につながるからです。
これまでに依頼いただいた講演は、実務者の方向けにレビューの研究動向や我々の研究グループでの事例を紹介してほしいというものが中心だったことと研究テーマは基礎的な内容は成り立ちにくいというのが理由で、基本の解説をしたことがありませんでした。また、大学院でソフトウェア工学の講義をすることはあっても、レビューに長い時間を割くことはありませんでした。
今年の4月から日経SYSTEMSでレビューの連載記事の執筆依頼をいただき、基本や基礎を振返ることになり、これまでの書籍等では紹介されていない部分があると認識しました。この連載を踏まえて、以下のような基本と原則を講座で紹介します。
- レビューではどのような欠陥を発見すればよいか
やみくもに誤りだけを検出、指摘するだけでは、いくら時間があってもたりない。どのような欠陥を検出、指摘することがレビューの効率化につながるのか考え、検出の開始前に設定する必要がある。 - 欠陥を発見するスキルとそれを伝えるスキルの両方が必要
誰も簡単には指摘できないような欠陥を見つけたとしても、その伝え方が適切でなければ、修正されなかったり軋轢を生んでしまう。また、伝えるスキルだけあってもレビューとしては成り立たない。 - レビューで発見すべき欠陥種別と発見にいたる着眼点の設定
プロジェクトやソフトウェアに求められる品質からレビューで検出すべき欠陥を設定し、設定した欠陥をどのように見つけるかを考えなければならない。 - ありがちな間違い
「他の人が指摘をしているから、なんとなく自分も」とか「あの人の担当部分を指摘すると逆上するからなぁ」といった欠陥指摘や欠陥検出に人間関係を持ち込んではならない。特定部分にだけ力をいれすぎていて、残りの部分がなおざりになっている。
また、今回の講座では、プロジェクトに持ち帰る際の注意点も含めており、特に若手～中堅の方向けに新しく知っていただいたことをどうプロジェクトに活かしていくかをガイドしたいと思っています。欠陥指摘（レビュー会議）の際に「～あるべきです。チュートリアルで習いました」といっても、「あぁ、それならやってみよう」とすぐに同意を得られることはそれほど多くないでしょう。ひょっとすると反感を買ってしまうかもしれません。まずは自分が実践し、学んだ知識やスキルが活かせるか試してみて馴染むようであれば利害関係のあるメンバを巻き込んでいくといった点も解説します。
これらは実務での経験をベースに、レビューの研究を進める上で観察実験や検出欠陥、指摘内容等の実データを見ながら感じてきたことに基づいており、レビューの解説に足りないと私が常々思ってきたことを解説できそうです。今回は、4時間の講座ですが、メトリクス、役割、リーディングテクニックには、ほとんど触れていません。実際に開発で使うドキュメントを用意し、検出、指摘を演習も含めます。
また、今回は特定のドキュメントや工程に限定しないことにしました。要求定義書、要求仕様、ソースコード、テスト仕様、設計書、どのような工程、レビュー対象であっても通用する内容にしています。
これからレビューをはじめようとしている若手の方、「自分がやっているレビューのどの部分が、基本といえるのかよくわからないなぁ」という中堅の方、今一度組織のレビューの実態を整理して、改善していきたいとお考えのベテランの方を想定しています。部下や後輩の方にもお勧めいただければと思います。
9/7(水) 13:00～17:00 早稲田大学でソフトウェア品質シンポジウムの併設チュートリアルとして実施します。詳細はこちら。申込みはこちら。