トピックス

 SWEST15は，2013年8月22-23日に岐阜県下呂市で開催され，160名を超える方々が参加されました．

ASDoQからは，山本雅，小林，森川が参加し，ポスター発表とセッション：夜の分科会を行いました．

１．ポスター発表

ポスター発表では，まだまだASDoQをご存じない方が多数いることが確認できました．お越しいただいた方と開発文書品質に関する課題を共有しましたが，学生さん含め予想以上に文書への関心度が高く驚きました．私たちの活動とASDoQ大会2013の開催をご紹介できました．発表資料はこちらから．

2013年6月28日～29日に，長野県松本市の美ヶ原温泉 ホテル翔峰にて，ASDoQサマーワークショップ2013を開催しました．
今回のワークショップでは，「ソフトウェア要求仕様書」と「ソフトウェア・アーキテクチャ設計書」を題材として，システム開発文書に求められる品質特性を明らかにすることをテーマに掲げ，参加者全員で議論を行いました．
文書の品質特性というと文書の構造や文法，文章表現などいろいろな候補が挙げられますが，今回は，文書の利用者（読み手）の立場から文書品質を議論することにしました．

第1日：6月28日 13:30-17:00
以下の手順を念頭に置きつつ，「ソフトウェア要求仕様書」を対象文書として議論を始めました．
 (Step1) 対象文書の読み手を列挙し整理する
 (Step2) 読み手の立場で文書の目的を整理する
 (Step3) 読み手の立場で文書に求める要件を列挙し整理する

ソフトウェアの受託開発企業がソフトウェア要求仕様書を作成する場合，その読み手として，以下が挙がりました．

• 発注者（客先に対して開発内容の承認を得るため）
• 設計者（社内の開発者が設計を行うため）
• テスト技術者（社内のテスト技術者が総合テスト仕様書を作成するため）
• レビュー担当者（社内の開発プロセスに準拠し要求仕様書をレビューするため）

システム開発文書に求められる品質特性（システム開発文書の満たすべき性質）を探るうえで，まずは「どのようなシステム開発文書で困っているのか」という，システム開発文書の問題を挙げてみました．参加者からは，次のような意見が出ました．

＜こんな開発文書（要求仕様書）が困る！＞

• 目的と手段が分けられていない．
  -　例）画面表示の指定として「○○は○色の太線で表示する」などと書いてあるが，目立たせることが重要なのか，その色であることが重要なのかなどが判別できない．ここで，使用している表示装置の都合で，その色の太線表示をしても目立たない場合を考える．この場合，目立たせるためにという目的を達成しないので仕様の改訂が必要になるが，仕様の目的が明示されていないのでその判断ができない．
• 重要な指定とどうでもよい指定の区別がない．
  -　優先度がすべて「高」になっている．あるいは，優先順位はついているが，順位付けした理由が不明確．この状況では，要求者の意図を理解した設計ができない可能性がある．
• 要求（目的）が分からず，仕様だけが書いてある．
  -　受注側から提案ができないのが困る．
  -　その仕様が矛盾していて，その通りに設計すると動かない，ということもある．

参加者の意見を整理するため，「システム開発文書の品質特性（満たすべき性質）」と「システム開発文書の問題」について，付せんに書き出して一つの模造紙に貼る，という作業を行いました．
品質特性はオレンジ色の付せん，問題は青色の付せんです．お互いに，ほかの人が貼った付せんを見ながら，思いついたことを追加していきました．


オレンジ色の付せん（品質特性＝満たすべき性質）として，「理解容易性（わかりやすいこと）」，「納得感がある」なども挙がりましたが，納得を目指すのは理解を目指すよりも難しい，という指摘がありました．
複数の付せんをまとめるキーワードとして貼ったのが，黄色の付せんです．

第2日：6月29日 9:00-15:00
第1日に挙げられた品質特性の候補を整理し，まとめる以下の作業を行いました．
(Step4) 対象文書のシステム開発文書品質特性を整理する
まず山本 雅基さんが，「理解」と「行動」の関係について前の晩に考察したことを披露しました．



その後，システム開発文書の品質特性としてどのようにまとめればよいのか議論しました．
要求仕様の規格「IEEE 830」は，要求仕様書に「何を書けばよいのか」という記述項目と，「どのように書けばよいのか」という品質特性（満たすべき性質）を示しています．
ここで，具体的な記述項目だけでなく，「対象とする範囲を明確にする」，「目的と手段を分ける」などの，文書を理解しやすくするために必要な構造（のようなもの）もあるのではないか？ という意見が出ました．



また，「システム開発文書の品質特性（満たすべき性質）」としては，まずIEEE 830に書かれている八つの品質特性（ソフトウェア要求仕様書が満たすべき品質）はそのまま当てはめられるという意見で一致しました．また，それ以外に，人間が介在する際に重要な特性として，「経済性（開発文書を読んで理解/行動するのにコストがかからないこと）」が挙がりました．その前には「理解容易性（理解しやすいこと）」がキーワードとして挙がっていたのですが，理解容易性は経済性の概念の中に含めるとし，最終的に残ったのが，経済性，というキーワードでした．
なお，IEEE 830に書かれている八つの品質特性は「正当性」，「無あいまい性」，「完全性」，「一貫性」，「順位付け」，「検証容易性」，「修正容易性」，「追跡性」ですが，用語のイメージを各自で想像するのではなく，IEEE 830に定義されている内容を改めて理解しておく必要があることを再認識しました．

参考文献
・山本修一郎；連載 要求工学　第3回 要求仕様，月刊ビジネスコミュニケーション．
http://www.bcm.co.jp/site/2004/2004De ... 04-youkyuu-kougaku-12.htm
 

4月12日に名古屋大学にて第5回研究会（定期総会）を開催しました．

今回の研究会では，会員から発表をいただき，今年度の研究の進め方を討議しました．

はじめに，山本樹さんが「アルゴリズム的思考法による論理的文章力養成の一検討」と題して，高等教育機関において論理的文章作成力を養成するための取り組みを紹介しました．
論理力や文章力を高めるために，アルゴリズム思考力と論理的文章作成力に共通点があると考え，プログラムを作成するように，論理的文章を作成する教育の事例を示しました．C言語のプログラミングのテスト結果と論理的文章作成のテストの結果に相関があったと報告しました．

討議では，以下の意見や質問が出されました．
・プログラムが書ける学生は論理的に考えられているとあったが，社会人ではプログラムをうまく書ける人が開発文書も書けるとは限らないのではないか．
・繰り返しや分岐などの決められた方法で表すことよりも，深く考えたり，俯瞰して考えたり，汎化したりができるかどうかなどの能力が求められるのではないか．
・詳しく掘り下げることはそのうちできると考えるが，何にもとづいてどう考えたのかという根拠が表されていない場合が多いと感じる．理由や根拠を捉えてあらわすことができるかどうかが重要なのではないか．

次に，海上智昭さんが「開発文書の品質を考える」と題して，文書と品質の解釈，読み手が嫌う曖昧さ，読みやすさの追求について，紹介しました．
文書は他者に影響を与え，文書には読者が存在し，等しく伝えることが求められており，品質とは，似たようなものに対して優劣をつけることを意味していると解釈しました．
曖昧さは，複数に解釈されることを意味しており，文章や論文では嫌われているが，完全に防ぐことはできないといわれていることを紹介しました．
文書の品質を下げないために，読み手の特性を知って，決断に必要なコストを抑え，順序と方法を洗練し，構成を統一するなどの配慮が必要であることを示唆しました．

さらに，塩谷敦子さんと山本雅基さんが「文書開発プロセスの考察」と題して，ASDoQウィンターワークショップ2013での活動をきっかけにして考えた，文書作成活動のモデルについての考察を発表しました．

初めに，塩谷敦子さんが，ASDoQウィンターワークショップ2013では，目的や意図を明らかにする「文書計画」と，構造を考える「文書設計」，規範に沿って書く「文書実装」に分けられるのではないかという結果になったことを紹介しました．それらの工程をソフトウェア開発プロセスの「要件定義」や「アーキテクチャ設計」「詳細設計」「実装」などに当てはめて整理した試みを紹介しました．

続いて，山本雅基さんが，開発プロセスのカイゼンのために，文書上の問題を明らかにするために，文書品質を見える化することが必要であると述べ，さらに，品質を改善するために，文書開発プロセスの評価・テストに該当する，赤ペンによる指導が必要であると示唆しました．赤ペンでは，書き直すことよりも，指摘だけを行う方が効果的であると結論付けました．

討議では，以下の意見や質問が出されました．
・機能安全の認証などのために，第三者に説明するための文書が必要になる場面がある．そのような場面で必要な要件があるので，その要件を満たすために，文書群を定義する必要があると思われる．
・文書間のトレーサビリティが取れている必要があるので，文書間の関係を定義することも必要である．
・「文書群要件定義」や「文書群要件定義」などに対応する文書診断項目が定義できるのではないか．

発表の後，2013年度定期総会にて，各議事の承認をいただき，作業部会での2012年度活動報告と2013年度の活動予定，及び，新作業部会の紹介をしました．

ロードマップ部会から，山本佳和さんが，2012年度には，ホワイトペーパV0版を公開し，KBSE研究会での研究発表，ASDoQ大会参加者の意見を整理，開発文書品質の欠陥モード分析木を具体化したことを報告しました．
2013年度には，開発文書品質の具体的な課題分析のためにASDoQ会員へのアンケート調査，現場の開発文書品質問題領域への解決策を具体的に整理，開発文書品質解決ガイドを用いたワークショップを具体化する計画であることを紹介しました．

 用語定義部会から，塩谷敦子さんが，2012年度には，「システム開発文書品質」を構成する「ASDoQ標準用語」とシステム開発に関連する「関連用語」を定義したことを報告しました．
2013年度には，ASDoQ会員全員が参加して「用語集Wiki版」を作成して，用語の定義を議論し表現を改善して、継続した活発な活動となることを目指す計画を紹介しました．さらに，システム開発文書の品質に関連する既存技術を整理し、索引として活用できる，「文書技術一覧」を作成する計画であることを紹介しました．

 人材育成部会から，山本雅基さんが，2012年度には，ムーブレボ通報システムのソフトウェア要求仕様書のサンプルを複数作成し，ソフトウェア要求仕様書の関連文書を調査していることを報告しました．
2013年度には，事例が複数できた所で公開することや，「文書」ではなく「文」「パラグラフ」のサンプルを作成する計画であることを紹介しました．

 新設部会である教育教材部会から，藤田悠さんが，プログラミング技術を習得したレベルにある，企業の技術者や高等教育機関の学生を対象にして，技術文書を作成する能力を高めるために，実際の教材を作成して，その教材を用いた実践的な教育を，直近に実施する計画であることを紹介しました． 

最後に，研究会での研究方針について，参加者の皆さんから意見をいただいて，討議しました．

 開発文書の品質が悪い事例を集めることや，文書の悪い例を公開するときの問題，文書品質の分類，ASDoQとしての文書品質の構築などについて，意見が交わされました．
その結果，ASDoQでのこれまでの活動での成果，会員の経験，文献などの属性を集めて，抽象的な定義を具体化して，ASDoQとしての文書品質の体系を構築していく方針でまとまりました．