開発システムの品質向上に貢献できる技術ドキュメントについて考える ―― ASDoQ大会2012

　2012年10月5日，愛知工業大学 自由が丘キャンパス（名古屋市千種区）にて，システム開発文書の品質について考えるシンポジウム「ASDoQ大会2012」が開催された（写真1）．開発文書の品質の捉え方や品質確保のための方策について，標準化や技術者倫理，フレームワーク適用など，さまざまな観点による講演が行われた．主催はシステム開発文書品質研究会（ASDoQ）．

写真1　ASDoQ大会2012の様子

●開発システムの保証書としても文書が重要に

　基調講演として，名古屋大学 情報連携統括本部 情報戦略室 教授の山本 修一郎氏が「開発文書とその品質をどう考えるか？ ～開発文章改善，標準化，開発文書管理の視点から～」と題した講演を行った（写真2）．開発文書技術についての議論は，ソフトウェア工学が議論され始めた40年前から行われている．しかし，いまだに手法が確立されず，開発現場では開発文書の品質が問題になっているという．

写真2　基調講演を行う山本 修一郎氏（名古屋大学 情報連携統括本部 情報戦略室 教授）

　まず，システム開発文書について考えるときは，「開発対象についての文書」と「開発プロセスについての文書」を明確に分けて考えるべきである，と山本氏は述べた．また，システム開発文書における文書品質を，そのシステムの品質の確認書のようなものだと説明し，通常の製品に保証書がついてくるように，システム開発においても品質を保証するためのエビデンス（証拠）としての文書が必要な時代になるだろう，とした．

　例えば，2012年6月に起きたファーストサーバ事件^注1では，ファーストサーバは顧客に対して「稼働率100％」をうたっていたが，顧客が被害を防ぐためには，「稼働率100％」をどのように保証するのかをあらかじめ確認するべきだったという．

注1：2012年6月，レンタル・サーバ会社であるファーストサーバの作業ミスにより，同社が管理していたWebサーバのデータが消失するという事故が起こった．データのバックアップの取り方などがパンフレットにうたっていた内容と実際で異なっており，バックアップも含めてデータが消失するという事態に至った．

　要求工学の分野では，要求仕様書の章節構成や記述項目間の関係，記述項目，記述文の構文，用語などについて，標準化されたものが多く存在する^注2．しかし，日本語訳されているものが少ないせいか，国内ではあまり知られていない．

注2：例えば，要求仕様書の章節構成のテンプレートとしてはIEEE標準 830-1998が，要求記述文の文法のテンプレートとしてはEARS（Easy Approach to Requirements Syntax）が，文で使用する用語についてはOMG（Object Management Group）が策定したSBVR（Semantics of Business Vocabulary and Rules）がある．

　次に山本氏は，開発文書の品質を測る方法に言及した．開発文書に対していくつかの観点を設け，それぞれの目的に沿って達成度を測ることで，品質を測れるのではないか，という．例えば，文書一般に関する観点では，章節構造や段落構造，複文，単文，用語などがある．開発文書の観点では，開発対象システムと開発プロセスがある．章節構造や開発対象システムについては目的合理性の達成度を，用語については統一性の達成度を測ることで，文書の品質を数値化できるのではないかと述べた．

　また，開発システムの品質を保証するためのアシュアランス・ケース^注3も開発文書品質に関係してくると述べ，開発文書品質とひと口に言っても，複数の要素がからまりあっていることを指摘した．

注3：アシュアランス・ケース（Assurance Case；保証ケース）とは，開発システムが重要な安全性を満たしていることを示すために使用する，要求を確認するための事例記述である．ISO/IEC 15026で定義されている．以前は安全ケースと呼ばれていた．主に，GSN（Goal Structuring Notation）という表記法で記述する．

　開発文書というと，要件定義書や設計仕様書，テスト仕様書などの公式文書がまず思い浮かぶが，山本氏は，開発計画書や契約書から，システムの利用シナリオや会議資料，メール添付資料，メールやWiki，SNS，ソース・コードや構成管理情報に至るまで，すべてが開発文書とみなせる，という（写真3）．それぞれの文書によって，持つべき性質（品質特性）は異なる．例えば，公式文書は正確性が重要となるが，メールやWikiには迅速性が，FAQには有効性が重要となる．

写真3　開発文書情報の分類例

表を見ると，公式文書の中に，「知識」に関する文書が存在しないことに気づく．山本氏は，知識についてもなんらかの形で公式文書として残しておく方がよいのではないか，と述べた．

※ 写真をクリックすると拡大できます

　2011年3月に改訂された，ISO/IEC/IEEE 15289/D4（システムおよびソフトウェア工学に関するIEEEのドラフト仕様）には，文書の目的に応じて内容を定義することが推奨されている．山本氏は，文書は人間が読むためのものであり，開発文書は，後工程の担当者が読むことを考慮して作成するべきである，と述べた．例えば，要件定義書を作成する場合には，ただ要件を定義すればよいのではなく，この定義書に基づいて後工程が設計できるのか，テストできるのかを考える必要がある．要求定義においても，ステーク・ホルダ（利害関係者）が何を求めているのかや，この要求で運用可能なのかなどについても考える必要がある，とした．