開発文書の品質を「見える化」,ソフトウェア品質監査制度の導入促進に貢献 ―― システム開発文書品質研究会 第1回研究会 レポート

Tech Village編集部

tag: 組み込み

レポート 2011年7月15日

 2011年7月11日,名古屋大学 東山キャンパス(愛知県名古屋市千種区)にて,「システム開発文書品質研究会(ASDoQ:Association of System Documentation Quality)」の第1回研究会および設立総会が開催され,40名強が参加した(写真1).本研究会は,要求仕様書やアーキテクチャ設計書などのシステム開発文書について,その文書の品質を定義し,品質の計測手法を定め,普及させることを目的としている.名古屋大学 大学院情報科学研究科 附属組込みシステム研究センター ディレクタの山本 雅基氏が代表幹事を務める.

 第1回研究会では,本研究会のアドバイザである独立行政法人 情報処理推進機構の田丸 喜一郎氏と,本研究会の運営委員である名古屋大学 情報連携統括本部 情報戦略室の山本 修一郎氏が講演を行った.

写真1 システム開発文書品質研究会(ASDoQ) 第1回研究会の様子

 

●国際競争力をつけるには「品質説明力」がかぎ

 独立行政法人 情報処理推進機構(IPA)の田丸 喜一郎氏は,「技術ドキュメントの品質確保から始まる品質説明力強化 ~品質説明力強化に向けた政府の取り組みと研究会への期待~」と題した講演を行った(写真2).これまで日本の製造業は高品質なもの作りを得意としてきたが,その品質の高さを,根拠に基づいて説明することが苦手だったという.一方海外では,「説明できる品質が“品質”だ」という認識があり,品質説明力がないと競合企業に対する優位性を示せない.例えば自動車業界では,2011年8月末か9月に自動車の電子制御系に関する機能安全規格「ISO 26262」が正式発行され,規格に沿って開発していることを証明する必要が出てくる.

写真2 独立行政法人 情報処理推進機構(IPA)の田丸 喜一郎氏


 これらの流れを受けて,経済産業省と情報処理推進機構は,ソフトウェア品質監査制度の導入を検討しているという.これは,会計監査と同じように第3者がチェックを行うことで,監査対象が正しく保たれていることを確認する.すでに米国では,航空機分野や医療機器分野,国防省やNASAのシステムなどについて監査相当のしくみがあるという.

 品質を監査するには,結局,ドキュメント(文書)を見ることになる.つまり,監査を行うにも,文書が理解しやすいものでないと効率的に監査できない.具体的に挙げると,「文法が間違っている」,「単語が間違っている」,「あいまいで正確に理解できない」,「必要なことが記述されていない」ような文書では監査できない.また,「内容をすぐに理解できない」,「必要な情報がすぐに見つからない」ようでは監査の効率が低下する.「分かりやすく効率的に読める」文書を書けるようにするために,本研究会の活動に期待しているという(写真3).技術文書の品質を向上させるためには,文法(国語力)や単語(分野知識)の習得のほか,論理的思考や記述項目の定義,利用者や利用シーンの明確化,文書構造の設計などが必要だと思われ,それらについて本研究会の活動が貢献することを期待しているという.

写真3 技術文書の品質向上段階と本研究会のスコープ

 

●プロジェクトの成否を要求仕様書の記述が左右する

 名古屋大学 情報連携統括本部 情報戦略室の山本 修一郎氏は,「開発文書品質研究の可能性」と題した講演を行った(写真4).同氏はかつて,日本電信電話公社(現NTT)で日本語構文を入力としてAdaコードを生成する設計言語プロセッサを開発していた経歴をもつ.

写真4 名古屋大学 情報連携統括本部 情報戦略室の山本 修一郎氏


 山本氏は,開発プロセスや開発スタイルによって「開発文書」の定義が異なる可能性を指摘した.ソフトウェア開発では,既存のソース・コードを保守・改造する開発が3割を占めるという.一般的なソフトウェア開発プロジェクトにおいて生産される文書としては,提案書,見積書,要件定義書,詳細設計書,プログラム(ソース・コード),試験成績書などが考えられるが,開発プロジェクトによっては顧客との議事録と発注指示書,ソース・コードが開発文書のすべてであるような場合もあるという.また,オープン・ソース・ソフトウェアの開発では,メーリング・リスト上の議論とソース・コードが開発文書である場合もある.

 また山本氏は,仕様書のテンプレートを用意する場合,システムそのものに関する要求(システムの入出力や処理,ふるまいといった機能要求と,性能や信頼性,保守性などといった非機能要求)だけでなく,外部環境(目的や利害関係者,利用特性,設計制約)やプロセス(資源制約や生産性など)についても見ていくべきであると述べた.これらは,ソフトウェアの要求仕様書の書き方に関する標準「IEEE 830」にも記載されている.また,ある調査によると,開発を予定通りに完了できたプロジェクトの要求仕様書はIEEE 830で定義した各項目についてバランス良く記述していたのに対し,納期やコストが超過してしまったプロジェクトではバランスの悪い記述となっていたという.具体的には,そのシステムについて,目的や定義,概要,要求仕様のうち次の開発に延期される可能性のある要求についての記述などが欠ける一方で,具体的な機能についての要求記述が多いというアンバランスが見つかった(写真5).

写真5 プロジェクトの成否とIEEE830の項目記述に関する調査結果


 山本氏は,同研究会の活動を始めるにあたり,「ASDoQスタイル」と呼べる開発スタイルを確立し,開発文書に「ASDoQ」のロゴを付けることがブランド価値になるような活動に育ってほしい,と期待を述べた.

1  2  »
組み込みキャッチアップ

お知らせ 一覧を見る

電子書籍の最新刊! FPGAマガジン No.12『ARMコアFPGA×Linux初体験』好評発売中

FPGAマガジン No.11『性能UP! アルゴリズム×手仕上げHDL』好評発売中! PDF版もあります

PICK UP用語

EV(電気自動車)

関連記事

EnOcean

関連記事

Android

関連記事

ニュース 一覧を見る
Tech Villageブログ

渡辺のぼるのロボコン・プロモータ日記

2年ぶりのブログ更新w

2016年10月 9日

Hamana Project

Hamana-8最終打ち上げ報告(その2)

2012年6月26日