アイフォース・コラム No.7 「巨大システム開発に挑む」 その3
10万項目のシステム試験手順書
さて、昭和63年の夏に結成したシステム試験企画チームは、5名のチームから20名のチームに増大していた。いよいよ開始されるシステム試験を目前に控えて、念入りに手順書の校正を行っていたのである。
基本設計が終了して既に半年が経過していた。
当然だが、その間に仕様の変更や、追加、あるいは解釈の齟齬が発生し、当時作成していたシステム試験手順書にも構成が必要になったのである。
プロジェクトマネジメントの教科書とされるPMBOK(Project Management Body of Knowledge)では、基本設計工程に相対する試験工程がシステム試験工程であると定義されている。我々は当時、PMBOKを意識していたわけではないが、経験的にその事に気が付いていた。
どういうことかというと、基本設計工程のレビューでは、常にシステム試験企画担当者が同席し、Q＆Aを繰り返すこととしていた。そのQ&Aは将来、システム試験項目を企画する際に大いに参考になった。基本設計内容に不足や矛盾がない事を確認するために、システム試験の項目が大いに役に立つのである。
逆にいえば、要件定義として認識される一つの機能に対し、必ず一つの試験項目が用意されていなければならない。常に１：１の関係になるように工夫をした。正常系機能を１とすると、当然ではあるが異常系や、準正常系のパターンが存在するため、１つの要件定義項目に対し、試験項目が複数になると考える場合もあろう。
しかし、そういった１：Nの概念で基本設計を進めると、いつになっても「N」が明確にならない のである。特に大規模プロジェクトでは、先々のリスクを完全に見通すことが非常に難しいため、いつになっても「N」が決定しない。
すなわち、いつになっても全体像が見えない、開発規模が定まらないという状況に陥る。そうなっては、プロジェクトマネジメントとして「大失格」なのである。
我々は予言者ではないので、未経験の分野に対するリスクを予言することなど到底できない、しかし、明らかになったリスクに関しては、必ず一つの要件定義を起こすようにすれば、いつでも１：１の関係、要件定義＝試験項目の関係がはっきりするのである。
こうする事で、異常系や準正常系のパターンが後になって判明した場合でも、容易に試験項目を追加する事が出来るし、モジュール毎の試験項目数を統計する事によって、要件定義の咀嚼が足りていないモジュール（設計が甘いモジュール）というものが見えてくるのである。
新同期MUXの重要機能のひとつに、絶対1秒警報判定という機能がある。詳しい説明はここでは避けるが、この警報判定のパターンが、非常に多数あり、これを「言葉」で表現する事は、極めて困難で、尚且つ難解なドキュメントになってしまう事が想定された。
そこで、我々はあるアイディアを思いつくのである。試験項目の手順書に、試験結果（期待する試験結果）を明記しなければならないのだが、専門用語を並べたてて記述すると、膨大な文章となってしまう。書き間違いも発生するだろうし、読み違いも発生してしまう。そこで「アイコン」という概念を思い出したのである。
簡単にいえば、数百パターンの試験結果を文章で表現するのではなく「記号」で表すことにした。
数百のパターンを大中小項目に分けるとすると、大項目は、○、□、△で表し、この図形の塗り分けで中項目～小項目を表現することにした。しかも、１０万項目という大量の項目を効率良く作成するために、これらの図形の形をかたどった「スタンプ」を作成した。
これは、大ヒットだった。なにせ、仕事が楽しくなる。ペタペタとカラーインクを使ったスタンプは、ドキュメントをカラフルにし、非常に見やすくすることができた。当時は、カラープリンタなど一般的ではなかった時代である。ドキュメントがカラフルに彩られている事は、とても画期的だったし、見やすさを大幅に向上させるとともに、作業者たちの効率も大幅に改善させる事が出来た。
１０万項目のシステム試験項目。今だったら、紙のドキュメントなどではなく、データベース化され、イントラネット上のサーバーで管理されることであろう。平成元年当時は、すべて紙のドキュメントとして管理され、書棚数台分の分量となった。この膨大な量の試験項目の全てに合格しなければならないと考えると、気が遠くなる思いであった。
大活躍したシステム試験企画チーム
この１０万項目に及ぶシステム試験の全てに合格すべく、3か月間の試験工程がスタートした。
本来であれば、システム試験を十分に実施するにはあまりにも時間が足りないスケジュールであった。しかし、国内初の新型伝送装置の開発は、言いかえれば、日本の高速デジタル通信時代の幕開けになくてはならない重要なプロジェクトである。納期を延期するなどという事は、到底考えられないばかりか、許されるはずのないことだった。
3ヶ月間のシステム試験を実施するために、我々は、チームを複数に分割して管理することにした。すなわち、シフト体制。24時間無休で作業を継続させ、絶対的な作業日数をフルタイム活用するための方法だ。
試験計画を推進し、バグチケットの管理を行う、システム試験企画チーム、試験を実施するオペレーションチーム、そしてデバッグとファイルリリースを行う開発チームに大きく分類した。さらにそれぞれを3チームに分割し、8時間毎のシフト制を組織した。
もうこの日からは、昼もなく夜もなく、日曜も休日もない日が続く。プライベート時間は食事の時間と睡眠の時間のみである。その他のすべてのエネルギーをシステム試験突破のために費やした。
そして、これまで練ってきた作戦が成功であったことが判明してくるのである。
まず80％以上の比率のメンバーが新入社員であるメリット、そう、若さである。どんなに苦難が続こうと、その先に差し込むであろう光を信じ、希望を常に忘れずに頑張ってくれた。3ヶ月間、一滴のアルコールも飲まなかったというエンジニアがほとんどだった。それ位に集中して作業に没頭する事が出来たのである。
次に、基本設計工程の当初から組織したシステム試験企画チームが大成功だった。なんと、システム試験工程が始まる頃には、どんな先輩エンジニアよりも、システム全体の事を熟知していた。どの機能は、どんな構成になっているのか、設計時、何が問題だったのか・・・そう、中には、試験項目になかった試験手順をアドリブで実行し、見事に潜在バグを発見した新入社員もいた。
なんといっても、試験を企画している本人たちが、いわゆる「一次切り分け」の判断が可能になっていた事が大きな力となった。通常、バグらしき事象が発生すると、そのバグの原因はどこにあるのか、ソフトウェアが悪いのか？ハードウェアか？あるいは仕様上の問題なのか、あらゆる可能性を検討し、分析する必要がある。これを「一次切り分け」と称するのだが、通常、こういった分析作業は、システム開発を担当した本人が検討しなければ判断できない場合が多い。
そうすると、シフト体制をとっているために、切り分けに着手する事が出来るのが、最悪の場合16時間以上後になってしまうのである。もし、そのバグがブロッキング事象であった場合には、下手をすると全ての作業が、その1件の事象の分析待ちとなってしまい、大きな遅延原因となってしまうのである。
今回の場合、この一次切り分けの分析作業のほとんどを、システム試験を管理しているシステム試験企画チームで実施する事ができた。これは素晴らしいことだった。
システム開発者自身が、自分のミスであると認めるよりも、第三者に明示される事で、自然とデバッグ作業の優先順位が決定でき、効率的に作業を進める事が可能になったのである。
信じられない話だが、Open中のバグ数は決して100を超える事がなかったのである。それほどに効率的にデバッグ～ファイル更新作業が行えたのも、エンジニアが一次切り分けの面倒な作業から解放されたことが理由ではなかったかと思っている。
結合試験工程の当時、問題だった100msec周期タスクは、信じられないほど順調だった。バグゼロとは言わないが、メジャーな問題が発生せずに順調にシステム試験が進められていた。
絶対1秒警報判定モジュールもいくつかの大きな問題を乗り越え、極めて順調に試験工程を消化していった。
ドキュメントチームは、毎日のように全ての設計書、試験報告書をメンテナンスした。
数百人の新入社員メンバーが物凄いエネルギーを発揮し、今、信じられないような仕事をやり遂げようとしている。まさに、目の前でその様子が繰り広げられている。
平成元年3月末。国内初めての新同期インタフェースを実装した最新の伝送装置「モジュールB」のソフトウェア開発が終了した。同年4月、「モジュールA」完成。同年９月「クロスコネクト」および「D1／D2モジュール」完成。すべての新同期MUXシリーズのソフトウェアがリリースされた。
そしてわが国の高速データ通信・インターネット時代が本格的に開始されるのである。
大変なプロジェクトであったが、素晴らしい経験を得たと感じた。そして素晴らしい仲間達にも巡り合えた。この時の経験、気持ちが、今になっても心のどこかでエネルギーの源になっているような気がする。