トピックス

2012年4月17日に名古屋大学にて，第3回研究会（定期総会）を開催しました。
今回の研究会には，会員および非会員の方合わせて35名の方がご参加くださいました．

発表として，愛知工業大学の阿部圭一先生が，「あいまいな日本語表現」考と題して，
「情報伝達型」の文章・文書のための日本語おける，
あいまい表現についての網羅的な考察を，タイプ別に分けて具体例を用いて紹介してくださいました．

その後，定期総会を行い，2011年度の報告と2012年度の計画などへの承認をいただきました．

引き続き，活動報告を行いました．

はじめに，ロードマップ部会の活動報告を山本修一郎さんが行いました．
システム開発文書品質ロードマップWhite Paperの作成を通じて整理した技術課題と，
システム開発文書品質に関する技術知識体系案について発表しました．

次に，用語定義部会の活動報告を塩谷敦子さんが行いました．
ASDoQ の活動を進めるうえで共通の概念として統一しておくべき用語を抽出して
定義する作業を進めていることを報告しました．

最後に，人材育成部会の活動報告を山本雅基さんが行いました．
一人乗り移動体を題材に，システム要求仕様書を各自が執筆し，
互いに執筆した文書を読みあって，
気づいた点を共有する作業を進めていることを報告しました．

さらに，2012年2月17-18日に行ったウィンターワークショップの報告を山本樹さんが行いました．
作業部会の活動では，実際に集まったからこそできる討議になったこと，
さらに，ナイトセッションや全体討議，食事を含めて，有意義であったと報告しました．
次回には，ぜひ皆さんにも参加してほしいと呼びかけました．

その後，シェジローにて情報交換会を開催しました．

ご参加くださった皆様，ありがとうございます．

2012年2月17日から18日の2日間にわたって、松本市浅間温泉にてASDoQウィンターワークショップを開催しました。

ロードマップ部会、用語定義部会、人材育成部会それぞれの部会では、膝を突き合わせることで、メールやウェブ会議ではなかなか出来ない議論へと深められました。討議の結果だけでなく、そこに至る過程が価値を持つ活動であると感じられました。

ナイトセッションでは、ライトニングトークスとして全参加者が5分の持ち時間で、自己紹介や、自身が行っている文章表現や修練の工夫や、ASDoQ で具体的に活動してみたいことや、ASDoQ の運営上の工夫案などについて自由に話しました。

通常の討議などではなかなか聞けない、人の歩みや、所属している立場ならではの文書の捉え方や、大っぴらには話せない開発文書の実情など、ウィットに富んだトークが行われ、大変貴重な時間でした。

このワークショップをきっかけにして、作業部会活動を力強く進めてまいります。

ソフトウェアテストシンポジウムJaSST’11 Tokaiにて，代表幹事の山本(雅)と運営委員の森川が、ポスターセッションとSIG(Special Interest Groups)に参加しました．

実施報告

1. ポスターセッション

開催時間：13:00～13:30

山本(雅)と森川はASDoQの活動を紹介しました．ほとんどの方がASDoQの名前さえもご存知無く，直接説明した方と周りで聞かれていた方を合わせて15名程度の方にASDoQの存在を知っていただくことができました．

ディスカッションを通じ，ほとんどの方が文書品質に対して高い関心を持っておられる様子をうかがい知ることができました．何名かの方からは，ASDoQに参加したいというご意向も頂戴できました．

その一方で，立ち上がったばかりの研究会のため本当に成果が出るのかわからない，参加したくても会社の理解を得にくい，という意見もいただきました．

多くの企業様に理解・協力していただけるよう，このような会で継続して広報活動を行います．

2. SIG「テスト工程の開発文書品質」

開催時間：16:15～18:15
SIGオーナー：山本(雅)，森川
SIG参加人数：12名（SIGオーナーを除く)

 概要

山本(雅)の進行の下，次の項目を実施しました．

• 文書品質の現状の説明
• テスト工程の現状の確認テスト工程で作成される開発文書と作成順序
• 上流工程の開発文書に対して感じる問題点
• まとめ

当初の計画では，テスト工程における開発文書の品質を参加者がどう考えるかを，主に聞く予定でした．しかし，参加者が置かれているテスト工程の現状確認に予想以上の時間を要しました．ただし，上流工程の開発文書品質に，テスト工程は影響を受けていることは確認できました．

テスト工程の現状の確認

「仕様書がない」，「仕様書に書かれていることは全てではない」という状況において，テストが行われている現状を知り，我々２人は唖然としました．

上流工程の開発文書の品質が良くないために，テスト技術者は困難な作業を行っています．テストエンジニアは，不完全な文書を基に，テストを考えなければなりません．そのため，どうしても「テストが漏れる → 不具合が見つからない →　品質低下 」という悪循環に陥っています．

たとえ，テストに必要な情報が上流工程の開発文書に記載されていたとしても，複数の仕様書に散らばっているケースが多いようです．そのため，テストケース（テスト条件の組み合わせ）の洗い出しがとても難しく，テスト漏れが発生しています．

テスト工程で作成される開発文書と作成順序

SIG参加者は，テストを次の手順で行っていました．作成される開発文書が明らかになるように，話をお聞きしました．開発文書をカギ括弧で囲み以下に示します．ただし，時間不足のために，我々の理解が不十分な点を含みます．

(１）「テスト計画書」の作成
「テスト計画書」には，次の項目が記載される：テスト対象物の概要，テスト戦略，テスト期間 など

(2) 「テスト仕様書」の作成
「テスト仕様書」には，次の項目が記載される：テスト対象物の概要を明確にしたもの，具体的なテストのやり方(テスト環境など) など

(3) テスト工程に対応する上流工程の開発文書のレビュー

(4) 「テスト設計書」の作成
「テスト設計書」には，テストの要求分析を実施した結果が記載される．

(5) 「テストケース仕様書」の作成
「テストケース仕様書」には，次の項目が記載される：前提条件，入力，期待出力，手順書，スクリプトなど

(6) テストの実行
テスター＝テストを実行する人
実行結果＝テスト結果（出力値の羅列）

(7) 「テスト報告書」の作成
テスト計画に対する報告書という位置づけ．
「テストプロジェクト完了報告書」とも呼ばれる．

上流工程の開発文書に対して感じる問題点

 参加者の方に，普段，上流工程の開発文書に対して感じている問題点を，付箋紙に書き出してもらい，模造紙に貼り付けて整理しました．そこから，上流工程における開発文書とその作成者に対して，次の問題点が見えてきました．

問題点１：品質の悪い開発文書が書かれている

• 文書の読者にわかりやすい記述がされていない．
• 他の文書に定義されていることが記載されていない．全体像が網羅できる記述が無い．
• 暗黙知の記載が省略されている．
• 日本語や記法がわかりづらい．解釈は読者に任せられている．
• 用語統一がされていない．
• 文書の不具合が多い．
• 上位工程の文書と下位工程の文書で，記載内容がずれている．作成者が異なるため．
• メール等でやりとりした情報が，設計書に反映されていない．
• 箇条書きの条件項目にて，AND条件とOR条件が区別されず，混在している．
• 正常系しか書かれていない．
• 非機能要求が書かれていない．

問題点２：開発文書を意図的にあいまいに記述し，責任逃れをする人がいる

• テスト実施後にしか，仕様書を完成する気がない．
• レビューさえ通ればよい．
• レビューに参加できる人が少ない時間に，レビューを設定する．

問題点３：言い訳をして，開発文書を書かない人がいる

• “工数が足りない”という理由で，品質の低い文書を作成していることを悪いと感じていない．

問題点４：開発文書の改訂によって生じる影響に無関心な人がいる

• テストエンジニアがテスト設計・実施をしている間に，設計書が平気で変更され，何処が変更されたのかを教えてくれない．
• テストエンジニア自らが間違い探しをしなければならない．量が膨大すぎて大変．
• 変更履歴にはざっくりしか書かれていないので，どう変更されたかがわからない．

まとめ

• 上流工程の開発文書の品質が低いため，テスト工程にしわ寄せが来ている．

• テスト工程内の開発文書も品質が高いと言えない．

3. JaSST’11 Tokaiに参加した所感

ASDoQの取り組みを多くの方に知っていただけ，非常に関心を持っていただけたことがよかったです．是非ASDoQに入会いただければと思います．

また，テストエンジニアが抱える問題の原因の１つに，上流工程の開発文書品質の低さがあることがわかりました．また，テスト工程内の文書についても同様の品質問題を抱えていることがわかりました．そのため，ASDoQの活動によって，文書品質を向上できれば，テストに関する多くの問題が解決できそうだと感じました．ASDoQの活動の必要性を再確認できました．

（森川）