◆レビューは、羅針盤
システムの出来具合と進捗状況は、適宜、業者から報告を受けるのは、リスク管理の面から当然である。また、悪い知らせを早め々に聞き出して、先回りして対策を打つことも重要である。しかし、これは、いずれも間接的な情報である。やはり、重要なポイントでは、自らの目で確かめることが必要だ。 織田信長は、間接的な情報だけに頼った情勢判断では、「今、そこにある危機」に対する勘が働かず、手遅れになることを恐れたため、３現主義（現場、現物、現実）を徹底していたといわれている。また、トヨタの強さの一端にも、徹底した３現主義があると言われている。
システム構築は、成功率が３０％程度といわれるほどリスクの高い仕事である。これを、他人任せ、業者任せにして、間接的にしか関与しないようでは、成功はおぼつかない。建築においても、欠陥住宅を防止するために、竣工までに３回は、現地において第三者の専門家と共に、自分の目で、建築検査を行うように推奨されている。システム構築における検査にあたるのが、レビューである。レビュー無しで、システム構築を行うのは、羅針盤無しで、荒海に乗り出すようなものであり、難破するのは必至である。
レビューをマイルストーンにおいて実施することで、品質と進捗状況の両方をチェックすることができる。例えば、品質上の問題が発見された場合、その重大度、影響度によって、今後の進捗が、どの程度遅れる可能性があるかを事前に予知することができる。一般に、進捗状況は、計画に対して、実績がどれくらい進んだか、どれくらい遅れたかの過去形の報告しかされず、「この先、どれくらい遅れそうか」ということは報告されない傾向にある。そして、実際に品質上の問題などの解決に手間取り、遅れが表面化してから報告される。このような場合でも、レビューによって品質上の問題を事前に把握することができれば、遅れる前に、適切な技術者を手当てするなどの対策を打つことがでる。
確かに、専門の技術用語が飛び交うレビューに、素人が口をはさんでも、どれだけ意味があるかという疑問があるかもしれないが、レビューに数多く参加することで、リスクを嗅ぎ分ける勘が鍛えられ、内容に関わらず「ヤバイ」状態にあるか、ないかを知ることができるようになる。専門的に、どうしても心配があれば、建築における第三者としての建築士や、医療におけるセカンド・オピニオンとしての医師と同様に、第三者の専門家として、システムアナリストやＩＴコーディネータ、別の業者のサポートを受ける手もある。
以下に、できるだけ専門的な内容に入り込まずに品質と進捗状況を、顧客の立場からチェックするためのレビュー・ポイントを述べるので、臆せず、ぜひ、レビューを実施し、参加してほしい。まずは、いつ行うかであるが、建築検査では、基礎工事、棟上げ、竣工の格完了時に３回実施することが推奨されているが、システム構築では、基本設計又は外部設計で２回、詳細設計又は内部設計で１回、統合試験で２回行うことを推奨する。
基本設計は、作業進捗が３０％と７０％の時点で実施し、詳細設計は進捗７０％の時点、統合試験は、試験計画作成時点と試験７０％完了時点で実施する。いずれにしても、作業完了時点では、問題が発見された場合、即、スケジュール遅れとなってしまうので、その前に実施する。問題発生による手戻りは、「必ずある」という前提で考えておけば、残りの作業の中で、対策を事前に打って、遅れを防止できるか、遅れても被害を最小に抑えられる。基本設計では、大きな方向性が固まるのが３０％程度の進捗時点。ここで、一度レビューを実施し、方向性に大きな違いが無いかを確認しておくことで、後から、大きな手戻りが発生するリスクを抑えることができる。
ただし、これは３０％程度の作業で、全体の方向性が決まるように設計作業をすすめることが前提となる。全体設計をせずにできるところから順次、プログラムを作成するようなやり方の場合は、完成の都度レビューをすることになる。その場合、作業の完成間際に全体の方向性を覆すような設計変更が発生した場合は、かなりの手戻りを覚悟しなければならない。これは、ちょうど基礎を全部作らずに、間取りが決まった部屋から家を建てるようなものである。
最近は、小さな部分に分割して、早くユーザに使えるシステムを提供し、フィードバックを得ながら、要求仕様を盛り込んでシステムを順次構築するようなやり方を提案する業者もいるが、基幹業務システムのように、基礎に巨大なデータベースを必要とするような場合は、せめてマスタ・データベースの基本構造とキー項目（データ識別子）や基本の画面・帳票構成くらいは、後で変更することのないように全体設計をすることをお勧めする。
統合試験では、試験を実施する前に、試験計画を作成した時点でレビューを実施することで、試験の妥当性をチェックする。試験の内容が必要十分であるか、人手を必要以上に掛けていないかをチェックする。万一、スケジュールが遅れているようであれば、比較的業務に影響が少ない機能については、試験内容を簡略化することで、さらなるスケジュール遅れを防止することもできる。とかく業者は、責任感から全ての機能に対して、綿密な試験を計画するが、それゆえに漏れや手抜きも発生する。発注者側が、イニシアチブをとって、機能ごとに重要度やリスクを考慮してメリハリを付け、重要な機能は徹底的に集中して試験し、そうでなければ、良い意味での手抜きをすることも必要である。
次にレビューでのチェックポイントであるが、できるだけ専門的な内容に入り込まずに危機的状態にあるか、今後、危機的状況に陥る可能性がどれくらいあるかを感じ取るには、要件定義書と要求仕様書に基づいて確認する。つまり、コンピュータ上の専門的な内容ではなく、あくまで、顧客からの観点に立って質問すればよい。一つは、基本設計や詳細設計、試験計画の内容が、要件定義や要求仕様のどの項目に対するものか、その追跡性を確認する。
専門用語ではトレーサビリティというが、全ての設計内容とプログラム、及び試験内容は、必ず要件定義と要求仕様から文書上で追跡できなければならない。その追跡が文書上ではっきりしない、質問しても明確に答えられないようなら、危険度大である。また、明確になっていれば、さらに、漏れや抜けが無いかをチェックできる。漏れや抜けを事前に発見できれば、手戻りを防止できる。漏れや抜けの他にも、過度の設計や試験にも目を光らせたい。要件定義や仕様書で要求されてもいないのに、技術者が、余計な気を使って、過度に機能を盛り込んだり、信頼性を上げたり、必要以上に執拗な試験をしたりと、これらは、追加費用は発生しないかもしれないが、スケジュール遅れや余計な問題を誘発するリスクを抱えている。トレーサビリティを確認することで、「過不足なく」仕事が進んでいるか否かをチェックできる。
トレーサビリティを確保する単純かつ確実な方法は、要件定義や要求仕様の各記載項目に項目番号を付けておき、設計書の記載項目番号やプログラム番号あるいはサブルーチン名、クラス名等と対応つけた対応表を作成することである。
もう一つ質問すべき点は、トレーサビリティ確認表を元に、設計なりプログラムの内容について、要件定義なり要求仕様を満足するために、なぜ、そのような設計にしたのか、あるいはプログラムにしたのか、あるいは、その試験内容で良いと判断できるのかである。技術者は、設計した結果について、専門用語を使って詳細に説明することはできるのであるが、この「なぜ」という基本的な質問に、しっかりと答えられないことがある。慣例的に、あるいはマニュアルに書いてあったからとか、という答えでは、はなはだ心配である。「なぜ、そうしたのか。なぜ、それで要件なり要求を満足できると考えたのか。」これを、顧客に分かるように、要件定義書及び要求仕様書に関連つけて、しっかり説明できる技術者であれば、ほぼ安心していて良い。
専門的な内容はさておき、要件や要求仕様に対して、しっかりした技術的根拠を持って、設計なりプログラムなりを作成し、試験を実施したことが、レビューで確認できれば、ほぼ、レビューは成功である。もし、問題点が発見されても、それ以降に適切な対策がとられ解決されると見てよいだろう。反対に、要件や仕様に対するトレーサビリティも不明確で、明確な技術的根拠も無く作業が進められており、専門用語ばかりを並べて、しどろもどろ。顧客が分かるように説明できないようであれば、危険度はかなり大である。
これが、基本設計の３０％の段階で判明し、改善が見られないようであれば、技術者の交代を要請することで、早い段階にリスクを緩和できる可能性が高い。さらに、技術者を交代しないとか、説明責任を果たせる技術者が出てこないようであれば、早めに業者を乗り換えることもできる。これが、詳細設計以降に発覚しても、もう手遅れである。高い出費を覚悟で、いわゆる「火消し」を雇うか、システム構築を放棄するしかなくなってしまう。
このようにレビューは、必ずしも専門知識を必要とせずとも、仕事が順調に進んでいるか、この先、問題が発生する可能性が、どの程度あるかを知ることができる。レビューを重ねることで、内容以前に、技術者の説明の仕方や態度で、「ヤバイかヤバクないか」を感じ取ることができるようになる。また、質問も表面的なことだけでなく、深く突っ込んだ質問もできるようになる。例え、専門的内容に対して判断を下すことが出来なくても、その技術的根拠がはっきりしていれば、他の技術者に意見を聞いて比較することもできる。万一、後で問題が発生しても、他の技術者の援助を受けるなどして解決策を見出すことも可能である。少なくとも、システム構築プロジェクト全体が、泥沼に陥ることだけは、かなりの確立で防止できるのである。
コメント