ユーザー企業とSIerの良好な関係を築くClearDoc
細川氏によると、要求に関する仕様の取りまとめ方にはいろいろなスタイルがあるという。例えばヨーロッパでは、要求管理や構成管理をしっかりと行う傾向があるという。一方アメリカはあまりドキュメントを作り込まないスタイルが多くみかけられる。そして、日本はその中間ではないかとし「日本のSIerも顧客企業の業務知識を十分に持ち、企業側もSIerに任せきりにしないで一緒になって作り込もうとしますが、ドキュメントの出来／不出来は、発注側（ユーザー）と設計者の力量に頼る部分が大きいです」と解説した。
ユーザー企業とSIerの役割分担
システム開発の基点は、ユーザー企業だ。しかし、ユーザー企業の要望だけをきいて仕様を作成した場合、セキュリティ面などを見落としてしまい、致命的な不具合が生じ、最悪の場合、ユーザー企業のイメージが損なわれる恐れもある。沼倉氏は、SIerがユーザー企業に対し、どこまで検討したかを証明するためのドキュメントの必要性を感じていると語る。
この意見に対し細川氏は「SIerとユーザー企業は、それぞれの境界線を踏まえつつ、どこまでをドキュメントに残すかが大事。具体的には、ユーザー企業は業務設計、業務フローなど、業務においてシステムをどう使うかを明確にする必要があるのです。一方、SIer側は、ユーザー側の要件が的確に反映された仕様書を作成し、フィードバックする責任があります。すなわち、ユーザーとSIer双方が役割分担を踏まえ、お互いに品質を高めていくことが重要です」と語った。
設計段階での品質の定量化
沼倉氏が先に挙げた質問のとおり、現状のClearDocは、要求の抜けまでは解決しない。あくまでも書かれてある文を診断するツールとなっている。だが、今後のバージョンでは、情報の偏りを端的に把握するため、ドキュメントの中にどのような情報が書かれているかといった分類ができるようなバージョンアップが計画されている。
細川氏は「設計ドキュメントの品質は、プログラム開発やテストに対して大きな影響を及ぼします。システム設計の段階で、仕様書における情報の偏りや分類を評価できることは、設計品質を確認する手段の一つとして、SIer側のみならず、受け入れ側のユーザー企業にとっても有益ではないでしょうか」と話した。
システム保守・再構築のコスト
続いて細川氏は、システムの保守や再構築についての話題を切り出した。
「最近はオープン系システムが増え、5年経つとハードウェア、ミドルウェアのサポートが切れて、システムを再構築しなければならない場合が多いです。新規開発の時には仕様書がしっかり作られていても、保守や追加開発が繰り返された結果、仕様書の品質が保てなくなるのです。そうなると、ソフトウェア維持保守のコストは膨らみ、さらには、5年後にシステムを再構築する際には設計からやりなおさなければならないといった事例を多く見かけます。ソフトウェア維持保守、再構築は、システム新規構築以上にコストがかかるにも関わらず、こうしたライフサイクルを通じて仕様書などのドキュメント品質を維持する有効手段はあまり存在しませんでした。こうした局面でもこのツールは有効に活用できるかもしれませんね」と、保守段階におけるドキュメントの品質維持でのClearDocの活用に期待を示した。
