システム開発の当初に作成される要件定義や基本設計のドキュメントの善し悪しは、最終的なシステムの品質や、各工程の生産性に影響を及ぼす。
以前CodeZineでは、株式会社シーイーシーが提供する、ドキュメント品質を高めるためのドキュメントあいまい度診断ツール『ClearDoc(クリアドック)』の機能を紹介した。今回は、ClearDocの開発担当である沼倉靖弘氏と、システム開発のコンサルティングを行う株式会社アーキテクタス 代表取締役社長 細川努氏との対談を通じて、実際の開発現場におけるドキュメントの重要性について考えてみたい。
要求の明確化プロセスは、よりよいシステム開発の条件
細川氏は、金融系シンクタンクで20年ほど金融や流通のシステム構築などのマネジメントに関わった後、4年前に独立。中央省庁のシステム最適化や、大手損害保険システム子会社の技術顧問など、システムや業務の要求開発・要件定義や調達仕様書作成に関するコンサルティングを行っている。
「よりよいシステム構築を行うためには、本来はユーザー企業自身も、要求・要件を明確に記述した調達仕様を作る必要がある」と細川氏は言う。「しかしながら、実際の調達仕様書を見ると、要件があいまいな記述、単なる思いつきレベルで必要性が不明確な記述が多く見受けられます。一方、システム構築を受注するSI企業の側としても、調達仕様書の要求・要件の質をちゃんとチェックして、不明確な部分を確認しないと、システム開発段階でのドキュメントにも大きく影響することになります」と語る。
要求が不明確だと文もあいまいになり、
後工程に悪影響を与えてしまう
シーイーシーのPROVEQサービス事業部では、要件分析から設計、実装、テストといった各工程における第3者検証サービスを提供している。中でもClearDocは、仕様書などの文のあいまい度を計測し診断するツールで、日本語文の複雑さやあいまいさを数値化し、その要因をガイドする機能を持つ。
開発担当の沼倉氏は「ドキュメントのあいまい度診断は、仕様書などのドキュメントに書かれた誤理解に繋がる項目をチェックすることで、基本設計以降、実装時やテスト時の手戻りをなくすことを目的としています。要件定義は、要求を正確に調査した上で整理されていることが重要ですが、ClearDocによるチェックは、要件定義においても誤理解に繋がる項目の改善に効力を発揮します」と話す。
PROVEQでは、設計工程のドキュメント作成と同時にテスト設計を行うサービスも提供している。テスト設計の段階では、仕様書どおりにプログラムが動くかどうかの準拠性の確認はもちろん、仕様書には明記されていないが、プログラムが動くことのできるすべてのテストケースも妥当性を確認する目的で設計する。「仕様書で、そのシステムのアウトプットが明確に書いてあれば、そのままテストケースに流用することもできます。しかし、中には抜けを恐れているのか、何でもかんでも書いておきたいという雰囲気の仕様もあります。記載する仕様項目の目的が明確でないうちに文章化してしまうと、読み手によってさまざまな解釈ができるあいまいな文になり、後工程に影響を与えてしまいます。ClearDocではこうしたあいまいな文を整理できます。ただ、重要な問題は他にもあり『そもそも挙っていないが、実は必要な要件』を見つけ出すことです。そのような場合の対策はどのようにすればいいのでしょう?」と沼倉氏は尋ねた。
ユーザーの要求をただ組み入れても、
よいシステムにはならない
この質問を受けた細川氏は、「ユーザーの要求をそのまま詳細化しても、よいシステムにはなりません。ユーザーの隠れた要求を引き出すためには、ユーザーへのフィードバックが必要になります。現在、フィードバックを行う手段としては、アジャイル開発のように実際にプログラム機能をリリースする方法もありますが、外部設計などの仕様書による確認も重要だと思います。すなわち、『必要な要件』が明確に記述されていれば、その分、漏れている要件も早期に発見することができるのです」と仕様書の品質を高めることの重要性について語った。