レビューが必要とされる理由
ソフトウェア開発現場の現状
現在は経営環境が激しく変化しています。そして、その経営環境に適応させながら企業活動は行われています。企業活動を支える情報システムにとって辛い時代なのかもしれません。なぜなら、その激しい経営環境、それに合わせた企業活動の変化に情報システムもついていかないとならないからです。
その結果、ソフトウェア開発はますます短納期、低価格、高信頼性が求められてきています。アジャイル開発、RADツールの高機能化など厳しい要求が求められているソフトウェア開発を支援する考え方、道具はでてきています。しかし、ソフトウェア開発は最終的には人間が行うものです。開発スピードを上げていくにも限度があります。
ヒトは間違いをおかすものです。どれだけ高性能、高機能の道具を使っても間違いがゼロになることはありません。逆に高性能、高機能の道具に振り回されてしまうこともあります。ヒトがつくったものは、方法は様々ですが最終的にヒトが確認してこそ品質の高いソフトウェアが出来上がります。そこでテストやレビューの重要性が再認識されてきています。
ソフトウェア業界における悪循環
このヒトの重要性を話しながらもヒトのモラールを下げてしまうような悪循環がソフトウェア開発には存在しています。低価格化、短納期開発、高信頼性の要求がますます厳しくなるにも関わらず、ヒト、時間、コストというソフトウェア開発での必須資源を十分に使えない状況があります。これらの必須資源を削って品質の高いソフトウェアをつくるのは困難です。
その結果、受入・出荷後に品質問題が発生し、そのリカバリー処理にまた、ヒト、時間、コストをかけざるを得ない状況になります。この状況が次の開発案件のスタートのタイミングを圧迫していきます。つまり次のソフトウェア開発が最初から苦しい状況でスタートしなければならなくなるのです。
いつまでたっても楽にならならない、悪く言えばドンドン苦しくなっていくソフトウェア開発の現場の状況が見えてきます。そして本質的な問題がまだ隠れています。ヒトのモラールを下げてしまうと言うことは、新しい技術を学ぼうと言う気持ちも削っていってしまいます。先程、ヒト、時間、コストはソフトウェア開発で大切な資源と書きましたが、まだ他にもあるのです。それが知識と経験です。
「学ぼうと言う気持ち」を削ってしまう状況は、知識が向上せず、企業や技術者にとって致命的ともいえます。経験はプロジェクトをこなせば付くのかもしれませんが、対処療法で済ましたプロジェクトのどれくらいのことが次のプロジェクトに活かせるでしょうか？よほど「失敗学」を意識しないと難しいと思います。
モラールの低下が、体を蝕み、やがて心を蝕んでいくことが考えられます。今、IT業界で課題となっている「心の病」の増加につながっていくと思います。
レビューが必要とされる理由
先の悪循環でもっとも目を引くのは、「システムテストや運用テストでの工数増大」「納品後のバグ対応や仕様変更への対応を引きずる」といった最終工程、もしくは最終工程以降の問題です。これらの作業はプロジェクトクローズには必要なことです。しかし「もぐらたたき、賽の河原ののような作業」はみんなのモラールを下げていきます。
よく言われることですが、上流工程重視のプロセスへの改善が悪循環を断つ重要な方法です。上流工程での問題は後工程に持ち越され、またそこで伝染病の拡大のように問題は広がっていきます。その問題に対応するために修正、修正を繰り返し、結果、デグレード、修正後のテスト不十分などにより品質低下を招いてしまい、悪循環に陥る･･･。また、悪循環と言う言葉が出てきましたが、悪循環を断ち切るには、後工程への問題の持越しを少しでもへらす工夫が必要です。
ここで、レビューの必要性が見えてきます。これから、レビューのやり方、留意点はコラムでもドンドン書いていきたいと思います。まずは今回のコラムではレビューの必要性までを見ておきたいと思います。
最後に、もうひとつ注意ですが、今回の論点である「上流工程重視のプロセスへの改善」はとても大切です。しかし、かといって「下流工程のプロセスも軽視できない」事にも留意しておきたいと思います。それは上流工程（外部設計までと定義）はユーザと接する機会が多く、自然と方法はともかくレビュー回数は増えていきます。しかし、下流工程になると内部的な作業が増え、意識的なレビューの回数が減ってしまい問題発見の機会が減ってしまいます。ここも留意しておきたい点です。
参考「ソフトウェア・レビュー技術（織田 巖著）」
関連コラム
レビューが実施されない理由（後編） 2007年10月22日記述
レビューが実施されない理由（前編） 2007年10月08日記述
レビューの基礎知識 2007年10月01日記述
レビューが必要とされる理由 2007年05月14日記述
システム運用の大切な役割 2007年04月09日記述
ドキュメントコミュニケーションのポイント 2007年04月02日記述
ドキュメントコミュニケーションの必要性 2007年03月26日記述
不満ゼロの要求定義を目指すには 2007年03月19日記述
これからＳＥになるヒトへ 2006年04月10日記述
システム統合でのトラブルについて考える 2005年09月05日記述
システム再構築の留意事項 2004年07月26日記述
2007年05月14日 宿澤直正 記