2014年6月9日から11日に秋田にて行われたSS2014に、ASDoQとして参加しました。ASDoQから提示したテーマ「システム開発文書品質」に関して、ワーキンググループにて討議しました。
このテーマの下に集まったワーキンググループ参加者は5名でした。少人数ではありましたが、自身の開発経験をあらためて振り返る方、開発文書を考える機会を初めて得た方など、それぞれの立場からの意見が活発に出され討議が進みました。
1日目には、ASDoQで2014年度ASDoQ総会前に実施した、会員の皆さんからのアンケートと、今回の参加者からのアンケート結果から、「システム開発文書の品質として何を重視しますか?」という質問項目に対する回答を整理し分析しました。
1日目での回答の整理と分析の様子
2日目には、SSの今年からの試みにより、複数のワーキンググループで議論する機会が設けられており、我々「システム開発文書品質」グループは、「ソフトウェアエンジニアリングの遺言」というテーマのグループ(7名)と議論しました。このグループには、ソフトウェアに関連する長年の経験をお持ちの方々が集まっていました。
この複数のワーキンググループでの話題の中心は、「遺言」よりむしろ私たちのグループのテーマである「開発文書品質」に関する内容になりました。そして、私たちが1日目に整理した内容に対して「遺言」のグループの方から意見をいただく場となりました。主な意見は、次のとおりです。
・用語集を作成して、用語と概念を一致させて理解を統一する。
・文書の必要性を見極めて文書を作り、無駄な文章は作らない。
・品質特性に関して多く議論されてきているが、それらを満たす有効な技術は出されていないので、定義自体を考えるだけではなく、個々の特性に対する解決手段を考えることが求められる。
3日目には、1日目にまとめた性質を基に、それぞれの性質に寄与する具体的な手段を考えました。文書に求める性質ではあるのですが、文書だけでは対処できないことも明らかになり、文書と文書外における活動を分けて考えました。その結果、以下の表のようにまとめられました。
性質 |
開発文書内で求められること |
開発文書の運用として求められること |
文書化する |
文書の目的を明示する |
開発要領を作成する |
構造化する |
文書目的から必要な項目をあげる |
開発要領を作成する |
追跡できる |
要求の番号を振る |
構成管理する |
正確である |
ツールにかける、読み返す |
レビューする |
整合している |
文書形式を工夫する |
作業のインプットを確認する
レビューツールを活用する
レビュールールを決める |
必要十分である |
コピペしない、参照先を書く |
要求と機能の対応チェック |
曖昧でない |
NG用語集・用語集を書く |
概念(用語)を整理する |
使いやすい |
読み手を明確にする |
開発環境を整備する |
3日目に、文書に寄与する具体的な手段を考えた作業の様子
最後に、まとめ発表会にて、開発文書に求める特性と、それぞれの特性に対応する活動をまとめた結果を紹介しました。
秋田での開催ということで、お酒・お料理・自然環境も合わせて楽しむことができました。
無限堂で行われた情報交換会での食事(秋田の名物づくし、いくつお分かりになりますか?)