はじめる前に頭に入れておきたいこと！

レビュー活動に対する課題

　レビューの効果は、いろいろな文献や図書で示されています。しかしながら、「レビューの効果はわかるのだけど、組織的になかなか定着しない」と思っている方も多くいると思います。また、「レビューの重要性は分かるのだけど、時間がもったいないので、今はプログラミングとテストを優先して」と言うマネジャーの方々もいます。

　ほとんど誰もがレビューの効果を理解しているはずなのに、なぜ、レビュー活動がうまく実践できないのでしょうか？まずは、レビュー活動に対する課題を少し洗い出してみましょう。

　下記のような課題は、多かれ少なかれ、思い浮かぶのではないでしょうか。このような課題を解決するためには、レビューの重要性を組織のみんなが理解したうえでルールに基づいたレビューを実践し、レビュー活動を組織文化として根付かせる必要があると思います。

レビュー活動をうまく実践するためのポイント

　レビュー活動をうまく実践するためのポイントは何か考えてみましょう。まずは、「ソフトウェア開発201の鉄則」（詳細は参考文献）から、レビューに関係する鉄則を3つ選んでみました。

　1つ目が「原理136：うまく話し合う技術は必須である」です。「ソフトウェア開発201の鉄則」にはこうあります。

　『プロジェクトで人を採用しようとするときは、チームワークと話し合える能力の重要性を過小評価してはならない。どんなに優秀な設計者でも、確信していること、聞いていること、または妥協することを伝えることができなければ、あまり役に立たない。』

　2つ目が「原理98：コードを細かく審査（Inspection）せよ」です。「ソフトウェア開発201の鉄則」にはこうあります。

　『ソフトウェアの詳細設計とコードの審査は、「プログラム開発でエラーを減らすための設計とコードの審査」と題するMichael Faganの論文によって最初に提案された。それで見つけたエラーは、そのソフトウェアで見つけたすべてのエラーの82％を占めたという。このように、審査は、エラーを見つけるためのテスティングよりはるかに効果的だ。これを実施するには審査の完了基準を規定せよ。審査を通して摘出したエラーのタイプを継続的に記録せよ。Fagan流の審査は、開発資源の約15％を費やすが、トータル開発コストを正味25から30％を低減する。』

　『当初のプロジェクト日程計画は、すべてのコンポーネントを審査し、修正する時間を考慮すべきである。あなたのプロジェクトは、そのような「贅沢」には耐えられないと思うかもしれないが、審査を贅沢と考えてはいけない。データは、テストの時間さえ、50から90％も低減できることを示している。もし、これが刺激にならないというなら、何をかいわんや。ついでに言っておくが、審査がどれほど効果的かを支援するデータや助言は、参考文献に山ほど載っている。』

　3つ目が「原理126：エラーを個人のものにするな」です。「ソフトウェア開発201の鉄則」にはこうあります。

　『ソフトウェアを書くということは、いまだかって人類が到達し得なかった詳細さと完璧さのレベルを要求する。従って、我々は、完璧さではなく、継続的な改善に向けて努力すべきである。コードのエラーが、自分自身または他の人の何れかによって摘出されたときは、オープンに議論せよ。自分だけで反省する代わりに、それを自分自身と他の人々のための学習経験として利用せよ。』

　原理96では、「コードを細かく審査せよ」というタイトルになっています。コードだけではなく、ソフトウエア開発工程で作られるさまざまなドキュメントに対しても、同じことが言えると思います。

　この3つの原理で言っていることを整理すると、以下のような内容に整理できます。

・チームワークと話し合う技術が大切
・コードやドキュメントを細かく審査し、品質を保証する
・レビューに適切な時間をかける
・エラーを共有し、学習経験として利用する

　上記のことが組織やチームで実践できれば、図1で示した課題の多くは解決できるはずです。