トピックス
トピック一覧
- 第35回研究会を開催しました(2025-04-12 09:54:26)
- ASDoQ大会2024を開催しました(2024-11-08 05:15:23)
- ASDoQサマーワークショップ2024を開催しました(2024-09-21 15:50:02)
- 2024年度定期総会・第34回研究会を開催しました(2024-06-10 20:47:50)
- 第33回研究会を開催しました(2024-04-06 15:21:54)
2013年9月27日に名古屋大学 ES総合館にて，「ASDoQ大会2013」を開催しました．第2回となる今回は，「文書の悩み，一緒に解決しませんか？」をテーマとして，第1部 チュートリアル，第2部 講演会，第3部 情報交換会・ポスター発表という3部構成で実施しました．
会員および非会員の方を合わせ64名が，開発文書に対するなんらかの感心や興味を持って集いました．そして，参加者がそれぞれの視点から意見を交わし，開発文書の課題を共有しました．主催者を含めた参加者にとって，今後のヒントや新たな気づきを得る場となったのではないでしょうか．
[森川さん]
[君島さん]
[戸田山さん]
[酒匂さん]
[近美さん]
[左から栗田さん，近美さん，山本(修)さん，君島さん，酒匂さん]
[山本(雅)さん]
SWEST15は，2013年8月22-23日に岐阜県下呂市で開催され，160名を超える方々が参加されました．
ASDoQからは，山本雅，小林，森川が参加し，ポスター発表とセッション：夜の分科会を行いました．
１．ポスター発表
ポスター発表では，まだまだASDoQをご存じない方が多数いることが確認できました．お越しいただいた方と開発文書品質に関する課題を共有しましたが，学生さん含め予想以上に文書への関心度が高く驚きました．私たちの活動とASDoQ大会2013の開催をご紹介できました．発表資料はこちらから．
２．セッション：夜の分科会
「良い開発文書を書くための拡散思考・収束思考トレーニング」と題して，8月30日（木）21：00～22：30に開催しました．40名程の方に参加していただき，非常に盛り上がりました．発表資料はこちらから．
私たちは，議論や思索の結果を分かりやすくまとめ上げ（収束思考），議事録や設計書などの開発文書として著わします．情報が上手に整理できていれば，比較的容易に分かりやすく文書化できたという経験は，多くの方がお持ちと思います．しかし，私たちは，文書にまとめる前に，様々なアイディアを提案して議論したり思索したりもしています（拡散思考）．具体的には，お客様の実現方法を皆で議論したり，不具合の原因を複数想定したりしています．つまり，私たちは，拡散思考と収束思考の結果として，様々な開発文書を作成しているのです．
そこで本セッションの目的は，文書化の直前までに私たちが行っている重要な活動である「拡散思考」と「収束思考」を取り上げ，そのトレーニングをすることにしました．しかし残念ながら時間の都合のため，本セッションでは「拡散思考」のみトレーニングを行いました．
山本雅が，開発文書を書く能力として何故「拡散思考」と「収束思考」が必要なのかについて説明をしました．また，Google Glassの紹介も行いました．
その後メインの演習では，発散思考のテーマを「Google Glassをはじめとしたウエアラブルコンピュータの新用途を考えること」とし，数名のグループ毎に発散思考をして頂きました．近くに座っている人達で自由に集まって，議論を開始していただきました．参加者は全員，夕食時にアルコールを飲んでいたため，皆さん自由に楽しく議論されていました．
最後に挙手をして頂き，話し合ったことを発表して頂きました．今回，文書を書ける状態ではなく，時間も無かったので，文書化までは行わずに単に口頭で発表するに留めました．発表してくれた中で最も若い人は学生でした．彼はゲームにウェアラブルコンピュータを使うことを発表してくれました．彼に，山本雅の私物であるサザンオールスターズのポンチョ（ピースとハイライトを買ったら付いてきた）を差し上げて，幕としました．
日々の多忙な業務の中，拡散思考をじっくり行う余裕の無い方が多いと思います．本セッションでは短い時間でしたが，拡散思考を経験することができ，よい気づきを得ることができたのではないかと思います．参加いただいた皆様，どうもありがとうございました．
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
