システム開発の当初に作成される要件定義や基本設計のドキュメントの善し悪しは、最終的なシステムの品質や、各工程の生産性に影響を及ぼす。
以前CodeZineでは、株式会社シーイーシーが提供する、ドキュメント品質を高めるためのドキュメントあいまい度診断ツール『ClearDoc（クリアドック）』の機能を紹介した。今回は、ClearDocの開発担当である沼倉靖弘氏と、システム開発のコンサルティングを行う株式会社アーキテクタス 代表取締役社長 細川努氏との対談を通じて、実際の開発現場におけるドキュメントの重要性について考えてみたい。
要求の明確化プロセスは、よりよいシステム開発の条件
細川氏は、金融系シンクタンクで20年ほど金融や流通のシステム構築などのマネジメントに関わった後、4年前に独立。中央省庁のシステム最適化や、大手損害保険システム子会社の技術顧問など、システムや業務の要求開発・要件定義や調達仕様書作成に関するコンサルティングを行っている。
株式会社アーキテクタス 代表取締役社長 細川努氏
「よりよいシステム構築を行うためには、本来はユーザー企業自身も、要求・要件を明確に記述した調達仕様を作る必要がある」と細川氏は言う。「しかしながら、実際の調達仕様書を見ると、要件があいまいな記述、単なる思いつきレベルで必要性が不明確な記述が多く見受けられます。一方、システム構築を受注するSI企業の側としても、調達仕様書の要求・要件の質をちゃんとチェックして、不明確な部分を確認しないと、システム開発段階でのドキュメントにも大きく影響することになります」と語る。
要求が不明確だと文もあいまいになり、
後工程に悪影響を与えてしまう
シーイーシーのPROVEQサービス事業部では、要件分析から設計、実装、テストといった各工程における第3者検証サービスを提供している。中でもClearDocは、仕様書などの文のあいまい度を計測し診断するツールで、日本語文の複雑さやあいまいさを数値化し、その要因をガイドする機能を持つ。
開発担当の沼倉氏は「ドキュメントのあいまい度診断は、仕様書などのドキュメントに書かれた誤理解に繋がる項目をチェックすることで、基本設計以降、実装時やテスト時の手戻りをなくすことを目的としています。要件定義は、要求を正確に調査した上で整理されていることが重要ですが、ClearDocによるチェックは、要件定義においても誤理解に繋がる項目の改善に効力を発揮します」と話す。
株式会社シーイーシー 沼倉靖弘氏
PROVEQでは、設計工程のドキュメント作成と同時にテスト設計を行うサービスも提供している。テスト設計の段階では、仕様書どおりにプログラムが動くかどうかの準拠性の確認はもちろん、仕様書には明記されていないが、プログラムが動くことのできるすべてのテストケースも妥当性を確認する目的で設計する。「仕様書で、そのシステムのアウトプットが明確に書いてあれば、そのままテストケースに流用することもできます。しかし、中には抜けを恐れているのか、何でもかんでも書いておきたいという雰囲気の仕様もあります。記載する仕様項目の目的が明確でないうちに文章化してしまうと、読み手によってさまざまな解釈ができるあいまいな文になり、後工程に影響を与えてしまいます。ClearDocではこうしたあいまいな文を整理できます。ただ、重要な問題は他にもあり『そもそも挙っていないが、実は必要な要件』を見つけ出すことです。そのような場合の対策はどのようにすればいいのでしょう？」と沼倉氏は尋ねた。
ユーザーの要求をただ組み入れても、
よいシステムにはならない
この質問を受けた細川氏は、「ユーザーの要求をそのまま詳細化しても、よいシステムにはなりません。ユーザーの隠れた要求を引き出すためには、ユーザーへのフィードバックが必要になります。現在、フィードバックを行う手段としては、アジャイル開発のように実際にプログラム機能をリリースする方法もありますが、外部設計などの仕様書による確認も重要だと思います。すなわち、『必要な要件』が明確に記述されていれば、その分、漏れている要件も早期に発見することができるのです」と仕様書の品質を高めることの重要性について語った。
ユーザー企業とSIerの良好な関係を築くClearDoc
細川氏によると、要求に関する仕様の取りまとめ方にはいろいろなスタイルがあるという。例えばヨーロッパでは、要求管理や構成管理をしっかりと行う傾向があるという。一方アメリカはあまりドキュメントを作り込まないスタイルが多くみかけられる。そして、日本はその中間ではないかとし「日本のSIerも顧客企業の業務知識を十分に持ち、企業側もSIerに任せきりにしないで一緒になって作り込もうとしますが、ドキュメントの出来／不出来は、発注側（ユーザー）と設計者の力量に頼る部分が大きいです」と解説した。
ユーザー企業とSIerの役割分担
システム開発の基点は、ユーザー企業だ。しかし、ユーザー企業の要望だけをきいて仕様を作成した場合、セキュリティ面などを見落としてしまい、致命的な不具合が生じ、最悪の場合、ユーザー企業のイメージが損なわれる恐れもある。沼倉氏は、SIerがユーザー企業に対し、どこまで検討したかを証明するためのドキュメントの必要性を感じていると語る。
この意見に対し細川氏は「SIerとユーザー企業は、それぞれの境界線を踏まえつつ、どこまでをドキュメントに残すかが大事。具体的には、ユーザー企業は業務設計、業務フローなど、業務においてシステムをどう使うかを明確にする必要があるのです。一方、SIer側は、ユーザー側の要件が的確に反映された仕様書を作成し、フィードバックする責任があります。すなわち、ユーザーとSIer双方が役割分担を踏まえ、お互いに品質を高めていくことが重要です」と語った。
設計段階での品質の定量化
沼倉氏が先に挙げた質問のとおり、現状のClearDocは、要求の抜けまでは解決しない。あくまでも書かれてある文を診断するツールとなっている。だが、今後のバージョンでは、情報の偏りを端的に把握するため、ドキュメントの中にどのような情報が書かれているかといった分類ができるようなバージョンアップが計画されている。
細川氏は「設計ドキュメントの品質は、プログラム開発やテストに対して大きな影響を及ぼします。システム設計の段階で、仕様書における情報の偏りや分類を評価できることは、設計品質を確認する手段の一つとして、SIer側のみならず、受け入れ側のユーザー企業にとっても有益ではないでしょうか」と話した。
システム保守・再構築のコスト
続いて細川氏は、システムの保守や再構築についての話題を切り出した。
「最近はオープン系システムが増え、5年経つとハードウェア、ミドルウェアのサポートが切れて、システムを再構築しなければならない場合が多いです。新規開発の時には仕様書がしっかり作られていても、保守や追加開発が繰り返された結果、仕様書の品質が保てなくなるのです。そうなると、ソフトウェア維持保守のコストは膨らみ、さらには、5年後にシステムを再構築する際には設計からやりなおさなければならないといった事例を多く見かけます。ソフトウェア維持保守、再構築は、システム新規構築以上にコストがかかるにも関わらず、こうしたライフサイクルを通じて仕様書などのドキュメント品質を維持する有効手段はあまり存在しませんでした。こうした局面でもこのツールは有効に活用できるかもしれませんね」と、保守段階におけるドキュメントの品質維持でのClearDocの活用に期待を示した。
日本のシステム開発のレベルアップのためにできること
ClearDocは、ドキュメント全体を通したあいまい度もグラフで見ることができるため、作成者ごとの品質も明確になる。このことから沼倉氏は、ドキュメントを作成する担当者の再教育やスキルアップにも役立つと説明した。
これを受けて細川氏は、「ドキュメントの品質を定量的に評価することが可能になれば、そうした品質を作り出している担当者のプラクティスを評価し、横展開することもできるのではないでしょうか。また、ドキュメント品質を高めることは、単に作り手側の問題でなく、ユーザー企業に付加価値を提言することにも繋げていけると思います」と感想を述べた。
日本の品質の高さをいかにビジネス価値につなげるかが課題
さらに細川氏は、マサチューセッツ工科大学でソフトウェア戦略について研究しているマイケル A. クスマノ教授による生産性・品質の比較についての論文を踏まえて解説した。「日本とアメリカのエンジニアを比較すると、日本は生産性、品質の両方ともアメリカよりも優れているにも関わらず、ソフトウェアのビジネスでは圧倒的にアメリカが優位に立っていると指摘されているんです。私も日本のエンジニアは真面目で生産性が高く、テストもきっちりこなすにも関わらず、それがなかなかビジネス価値に繋がらないところが課題だと感じています。日本のエンジニアのレベルの高さを示す手段としても、ClearDocのようなツールが使えるかもしれませんね」と細川氏。
その後対談は、日本のエンジニアが得意とする「品質」を世界に売るというテーマで展開されていく。細川氏は「仕様書の品質を早期の段階で確保することは、なかなか難しい問題であり、多くのプロジェクトマネージャーが悩んでいることだと思います」と語る。
ユーザーのニーズに応じた品質レベルの可変性が必要
沼倉氏は「PROVEQでは、携帯電話が出始めたころから第三者による検証サービスを提供しています。世界中に携帯電話が広まっている中で、日本の携帯電話の品質は、異常といってもいいくらい高く、多機能です。この品質を維持していくほうがよいのでしょうか？」と細川氏に尋ねた。これに対し細川氏は「もちろん、品質は重要ですが、必要以上に高い品質はコスト増につながり、結局価格面で競争力を失ってしまいます。つまり、ユーザーの要求レベルに応じて、必要な品質・性能を提供することが重要になります」と回答した。
もっとも大事なのはユーザー企業とよりよい関係を築くこと
現在では、ユーザー企業もコストにより厳しくなり、SIerにはコスト削減努力に加えてスピードも求められる。細川氏は最後に「SIerは、ユーザー企業のよりよいパートナーになることが大事。受け身の姿勢ではダメで、ユーザーと一緒に品質とビジネス価値を作り上げていくことが、次代のSIerやパッケージベンダーなどのソフトウエア産業に必要なことだと感じます。こうした変化はこれからますます加速するのではないでしょうか。例えば、SaaS、PaaSなどのクラウドサービスが普及してくると、ビジネスに役立つものをタイムリーに提供することが今まで以上に求められます。新しい潮流に対応することは大変ですが、エンジニアやソフトウェア企業にとって、よりチャンスのある時代になるという考え方もできます」と語り、対談を終えた。
本稿で紹介した内容を具体的な事例などを交え紹介するセミナーが、2010年10月8日に恵比寿で開催されます。「改善フローと事例」および「製品の活用ポイント」の2部構成のセッションで、どちらも定員60名。参加無料。詳細および参加申込はシーイーシーのサイトを参照してください。
