設計・開発の赤信号：度重なる仕様変更に、文書管理せず口頭で指示出し
広域機関システムの開発プロジェクトでは、システム品質へ直接的に影響を与えかねない赤信号も灯っていた。ドキュメント管理の放置が、それだ。
システム開発プロジェクトでは通常、システム仕様書に基づいてプログラムの設計書を作り、設計書に従って技術者がプログラムを開発する。そして、作成した個々のプログラムやシステム全体のテストでは、設計書あるいは仕様書のとおりにプログラムやシステムが正しく動作するかを確認する。
テストの結果、想定したアウトプットや性能が得られない場合は、仕様書や設計書に基づいて不具合などを突き止めて改修したり、必要があれば仕様や設計を見直したりして可能な限り不具合が少ないシステムに仕上げる。つまり、正確な仕様書と設計書はシステム品質の重要な根拠の1つになる。
システム稼働後の機能追加や改修を安全かつ効率よく進めるうえでも、現状を漏れなく反映した仕様書と設計書が欠かせない。機能追加の際にプログラム間で処理の整合性を確保するのはもちろん、改修内容が他のプログラムの動作に悪影響を及ぼさないようにするためだ。
ところが、広域機関システムのプロジェクトでは、2015年9月頃から計画系機能に関する仕様書や設計書の更新が滞った。全面自由化が刻々と迫る中で繰り返される仕様変更により、日立は仕様書の修正もままならない状況になった。
システム仕様の追加や変更が発生すると、日立は技術者に口頭で内容を伝えたとされる。また、プログラムの開発工程が遅れていたことから、設計書の作成よりプログラム開発体制を強化し、システムの稼働時期を死守したいと考えた。
システム品質に関しては、早々に赤信号が点灯していたわけだ。この事実は、第三者評価委員会によるプロジェクト関係者へのインタビューで初めて明らかになった。
もっとも、全体の進ちょく状況と課題を報告する月次の定例会議でほぼ毎回、日立から遅延報告が繰り返されたこともあり、広域機関は赤信号に気づいていた。その証拠に広域機関は2015年8月までに、日立に対して「仕様書が書ける人材が欠けている」と何度も陣容強化を要請していた。だが、広域機関システムを理解して仕様書を作成できる技術者の養成に時間がかかり増員は困難、と日立は判断した。
仕様書も設計書も事実上、存在しない。人材もいない。広域機関システムの計画系機能を開発する日立の部隊は、もはや破たん状態だった。そう言っても過言ではない。
現に、どの機能が完成しているのかを確認するため、広域機関の担当者が2016年2月に日立に乗り込んだところ、納得できる回答は得られずじまい。進ちょく状況を管理する案件管理表もなく、現況を把握できなかった。
そのため広域機関の担当者は、日立からの委託でプログラムを開発するITベンダーの技術者に直に状況を確認。広域機関にとって再委託先となる技術者の情報を基に自ら資料を作成した。この段階で初めて、基本的な機能やインタフェースの開発が抜け落ちていることが判明したが、時すでに遅し。広域機関システムへの機能実装は、2016年3月末までに間に合わなかった。
これだけ数々の赤信号が灯っていたのに、広域機関システムの開発プロジェクトは、どうして軌道修正できないままトラブルに向かって突き進んでしまったのか。次回はマネジメントや人材など体制の面からプロジェクトの課題をみていく。
