利用者（顧客）要求の定義、システム設計、詳細設計、コード化作業に誤りはつきものという前提で仕事をしなければ、信頼性が高いシステムを開発することはできません。設計書を書き、コード化が終了すると、はやる気持ちが抑えられず、テスト工程に入ってしまうのは犯し易い誤りの１つです。自分が書いたプログラムが思った通りに動作するのは楽しいことだからです。直ぐにでも結果を見たいばかりに途中の仕事をすっ飛ばして直ぐ実行してみたくなる気持ちは今も昔も変わりません。前の工程をほどほどにして次の工程に進んではいけません。設計書を書き、コード化する前にレビューが必要です。コード化が終わってテストする前にもレビューが必要です。

　システム設計者やプログラマのはやる気持ちだけが、現在工程の仕事を完了させずに、次の工程に入る要因ではなく、当初の計画が遅れてくると、とりあえず先の工程に手をつけたがる管理者の心理も要因となっています。前稿「ITプロジェクトにおける知識継承」の図３（下図は図３の引用）を参照してください。図３は時間軸と作業との関係を示しています。一番外側の長方形が縦線２本と斜線３本で区切られています。縦線はこの時期までにそれ以前の工程の作業をすべて完結させる必要があることを意味しています。斜線は時間軸で見ると複数の工程が重複しても良いことを意味しています。斜線は複数の工程の重複を徒に許しているのではなく、クリティカルパス（ある作業が終了しなければ、次の作業に入れない関係を考慮した作業手順）と平行可能作業とを考慮して要員を配置し、要員の空き時間をなくし、最も短期にプロジェクトが終了するよう計画されることを前提にしています。あるモジュールの詳細仕様設計途中で、コード化を始めても良いという意味ではありません。テストについても同様です。

　軽量級の方法論で、テスト・ファーストという用語が使われるようになりました。テストし、確認しながらソフトウェアを構築するのです。確かに、品質がどうか確認できないまま、大規模のソフトウェアを作成して、後工程でテストを始めると、取返しがつかないような事態になることは防止できます。しかし、テスト・ファーストよりもっと効果的なのはレビュー・ファーストです。テストよりもコストミニマムに、確実に品質を確保する手段はレビューなのです。

　なぜレビューが必要なのでしょうか。今更説明するまでもないことですが、多くの人は何をするにしても、はじめから正確に行うことはできません。誤りを修正しながら、完全に近づけて行きます。人間が誤りを犯し易い存在だということは、ソフトウェア開発という複雑な作業において、より顕著に現われます。そうであるにもかかわらず、レビューの重要性を忘れてしまうのです。今私はこの文章を書いていますが、何度も行ったり来たりしながら、ようやっと書いているのが実状です。ソフトウェア開発も同様です。何度も見直しているのですが、見過ごしてしまうことが沢山あります。文章は人が読んで、適当に解釈してくれますが、ソフトウェアはそうは行きません。コンピュータは人の瑕疵を許してくれません。適当に解釈し、正しく認識してくれたらいいのですが、誤りはそのまま不具合となって現われます。

　Waterfall型モデルでは、誤りを犯した工程と顕在化した工程が離れているほど解決に要する費用は大きくなります。上流工程の誤りは下流工程に大きく影響し、修正は誤りを犯した工程の作業からやり直さなければならなくなるからです。最も費用がかかるのは、要求仕様（外部仕様）に利用者（顧客）の要求を正しく反映せず、総合テストで発見された場合です。最も費用が軽くて済むのはコード化工程での誤りです。しかし、それはソフトウェアの開発期間中の話です。システムを利用者（顧客）に導入した後では、誤りの影響は大きく変化します。要求仕様（機能仕様）の誤りは致命傷となることがあります。コード化工程での誤りも軽く見ることはできません。既に利用者（顧客）で運用されている段階で、その誤りが顕在化した場合、システム設計者やプログラマにとっては、軽い誤りと見えても、利用者（顧客）にとっては重大なことになることがあります。そのような場合、誤りを取り除いても、利用者（顧客）は疑いの目を向けてきます。いきなり信頼が崩れる瞬間となることもあります。また、ソフトウェアの規模が大きい場合、再インテグレーションや再テスト、再導入に要する費用も見逃すわけには行きません。デグレードしようものなら、悲惨な結果が待っています。

　このような事態から逃れるために、軽量級の方法論が着目されたのですが、軽量級の方法論にも限界があります。多数の関連し合ったモジュールからなる構造のシステムの開発には向いていません。もちろん、軽量級の方法論が向いているならば、それを使用することをためらう理由はありません。ただ、その場合でもテスト・ファーストよりもレビュー・ファーストが有効であることは知っておくべきです。テストにはかなりの費用がかかるからです。

　テストはあくまでも念のための実行確認が主な目的であることを忘れてはなりません。一般に、テストの目的はソフトウェエアの誤りを見つけ修正することだと考えられています。誤りを見つけた後の作業を考えてください。当然ながら、誤りの種類によって対策は異なります。いわゆる論理エラーといわれる誤りは、設計が不完全だったのですから、テストで指摘された誤りに関して、改めて設計をやり直すということになります。「テスト工程で設計し直す」のです。これが当然だとお考えの方は、考えを改めていただく必要があります。テスト工程で設計し直すのは止むを得ない作業であると認識して欲しいのです。前の工程に戻って作業するのですから、当然費用が増え、プロジェクト進捗は遅れます。このような論理エラーの数がそのプロジェクトが許す期間と費用の許容範囲内であれば事なきを得るのですが、超えたときは失敗ということになります。経営的には、利益減あるいは赤字になることを意味します。

　テストで検出された論理エラーには、システム設計者やプログラマーの集中力を引き出すという効果があります。誤りを指摘されるまでは、「いいはず」とか「問題ない」と暗に思い込んでいるだけなのですが、いざ、誤りを指摘されると、目標がはっきりして、俄然頭が働き始めます。問題が明確なほど人の頭は集中力を発揮します。しかし、このようなやり方では、先に述べたように、やり直しをするのですから、生産性は上がりません。可能な限り設計やコード化の不完全さを排除するため、レビューをしっかり行う必要があります。

　今まで述べたことは至極当然のことです。レビューの重要性は誰もが認めることでしょう。しかし、下手をすると、レビュー作業と称して無駄な時間を過ごすことがあります。設計やコード化の完全性をどのようにして確認するのかはっきりと認識されていないことが原因です。

　例えば、「コード・レビューをしなさい」とプログラマに指示すると、プログラマがプログラム自身になってしまうことがあります。制御の流れを追いかけてしまうのです。これではレビューになりません。プログラマの意識はプログラムを設計する立場でなければならないのです。プログラムに指示する立場のプログラマがプログラム自身になってしまっては困ります。レビューとは設計やコード化の成果物を、同じやり方もしくは別のやり方で、もう一度見直すことです。

　また、「コード・レビューをしなさい」という指示に対し、自分が書いたプログラムをしばし眺めて時間を過ごしているプログラマもいます。プログラムの頭から尻尾まで、漫然と眺めて時間を過ごすのです。眺めていてもレビューにはなりません。

　テストで論理エラーが検出されたとき、疑われたモジュールの設計者あるいはプログラマが、その原因がピンと来ないようであれば、彼／彼女は自分の設計が頭に入りきっていないのです。しっかりと頭に入れている設計者やプログラマならば、原因や誤りの個所や修正方法まで、直ぐに気づくはずです。レビューを繰り返す間に、設計書やコードのすべてが頭に定着し、自然と漏れや矛盾個所が見えてきます。このレベルになるまで何度も読み返すのがレビューです。設計やコード化は、はじめは全体を見ていますが、個別の個所を具体化し始めると、全体とのバランスが取れなくなることがあります。このような歪みをレビュー作業によって修正して行くのです。設計やコードが頭に入りきってしまえば、設計者やプログラマは心からの自信が出てきて、テスト工程以降でもたつくことがないということを確信します。

　要求仕様（外部仕様）設計、構成（構造）仕様設計、詳細仕様設計、コード化のすべての工程で、レビューを行う必要があります。当たり前のことですが、作業内容によってレビューの仕方は異なります。レビューで、集中力を発揮させるために工夫が必要になります。レビュー作業を眺めるだけの行為にしないために工夫する必要があります。

　要求仕様書のレビューは利用者（顧客）と一緒になって、機能とその動作について、できるだけ現物に近い生産物（画面、帳票、業務フローなど）を見ながら見直します。利用者（顧客）は、この機能と動作が自己の業務を満足させるものであるかを臨場感をもって見直します。利用者（顧客）はソフトウェアが完全に動作していない段階で判断を迫られますから、開発者に任せておくことはできません。

　構成（構造）仕様設計書は、システム設計者が詳細設計以降の作業の段取りをつけることです。段取りがついていれば、詳細設計以降は、一気にことが運びます。要求仕様（機能仕様）設計と構成（構造）仕様設計が詳細仕様設計工程以降の段取りとして必要十分かを確認することがこの工程のレビューです。

　詳細仕様設計は、前工程で定義されたソフトウェアの一部を担うモジュールの機能と動作を設計することです。ソフトウェアの中の当該モジュールの位置、機能が定義されていますので、その機能を具体的にコード化できるように準備するのが詳細仕様設計です。レビューは、モジュールの役割が完全に実施できるかを見直すことです。

　コード化は、詳細仕様設計書で定義された機能をコード化することです。論理は既に詳細仕様設計で定義されていますので、ここでのレビューは、間違いなくコード化されているかを見直すことです。

　設計やコードのレビューをすべて1人で行うと誤りに気づかないことがあります。得意、不得意、注意の向く方向、手馴れているかどうか、などについては人により差があります。思い込みがあるとなかなか気づきません。何人かのメンバをチームにして見直すと、レビューの効果は抜群によくなります。１人では発見できなかったことが分ることもあります。

　レビューは、チームで行うと、効率を上げます。眺める行為の回避、プログラマがプログラムになってしまう心理状態の回避だけでなく、不完全な個所の早期発見に役立ちます。

　設計レビューやコード・レビューは、チームで行うことを勧めます。１人でも忙しいときに、他人の分までやりたくないと思うのが個人的な思いですが、それですべてがうまく行くなら、それで良いのですが、うまく行かないときにどうするかということを考えなくてはなりません。チームで作業をすると、他の人の作業の仕方、考え方、工夫、知恵、知識、経験、勘所等を学び、かつ現実の仕事で相乗効果が出てきます。チームで作業をする際、レビュー･シナリオを作ることを勧めます。レビュー・シナリオは紋切り型のものがあるわけではなく、いろいろと工夫して自プロジェクトに適したものを作成します。

　例えば、要求仕様（機能仕様）設計書と構成（構造）仕様設計書のレビューは、関係者が合宿などで一堂に会して行うと効果的です。短時間に多様な知恵を結集して、問題・課題を挙げて行きます。その場で解決できるものと、時間をかけて解決しなければならないものを明らかにします。

　詳細仕様設計書やコードのレビューは、二人で行うのが効果的です。１人が詳細仕様設計書やコードを説明し、他方は疑問があれば質問します。自分の考えを他の人に説明している間に、不備や矛盾に気づくことがあります。自分のことはなかなか分らないのですが、他人のことは気づくことが多いのです。

　レビューは、レビュー観点を挙げてから始めるのが効果的です。全体を通しで見ることも必要ですが、レビュー観点毎にレビューを行うと、何を見ようとしているか、意識すべき観点がはっきりしているために集中力が上がります。テスト工程で論理エラーを指摘されたときに、俄然集中力が出てくるのと同じ効果が期待できます。

　レビューとは、設計作業、コード化の最も重要な作業です。設計やコード化を完結させずに、テストを始めることが、如何に無謀な行為であるかについて良く認識すべきです。

■