トピックス

  
投稿日時 2019-08-25 20:21:23 (7766 ヒット)

 2019年8月23-24日に京都市にて,ASDoQサマーワークショップ2019を開催しました.

 
毎年ASDoQでは、夏の京都で合宿形式のワークショップを開催しています.鴨川のせせらぎに涼しさを感じつつ,開発文書について熱い議論を交わしています.
今年のサマーワークショップでは,ASDoQが提唱している文書品質モデルの使い方ガイドライン作成に向けて,例とする開発文書を用いて,指摘,文書品質との関係づけ,改善を,モブワークの方式で実施しました.
◆システム開発文書品質モデルについてはこちら
 
例とした開発文書は,SESSAMEの「話題沸騰ポット要求仕様書 (GOMA-1015型) 第6版」(最新版は第7版)です.ワークの対象として「6.エラー検知」の章を選びました.
 
ワークは,昨今話題になっているモブワークの方式で行ないました.
◆モブワークとは
3~4人でチームを組み,皆で同じ表示を見ながら課題に取り組みます.
PCを操作して入力する人は1人(ドライバー)です.他の人はナビゲーターとなり意見を出し合います.意見には,まず,肯定的な反応をします.すると,どんどん意見が出てきます.全員参加により,1人で作業するよりも早くて完成度が高いアウトプットが出せます.
今回は,Googleドキュメントを用いて、各チームで1つの文書を共有しスクリーンに投影して同じ画面を見ながら、指摘や改善の作業を進めました.
最後に皆でバンザイをして,達成を祝います.最初は恥ずかしかったのですが,やってみると,一体感を得られますし,ワークの疲れもとれて爽快でした.
 
以下は3チームに分かれモブワークを実施した振り返り(KPT:Keep, Problem, Try)の中で,モブワーク自体に対する意見の抜粋です.
◆良かった点,継続したい点(Keep)
・記述品質(品質特性での可読性や理解容易性や論理性)に着目して改善しようとすると、情報品質(品質特性での完全性、とくに正確や妥当)の不備に気づけた.
・チームで理解を深めて共感しながら進めることでチーム力が向上した.
・Googleドキュメントを使うと,皆で並行作業できた.
・ナビゲーターが議論中、ドライバーはリファクタリング作業ができる(文書をレビューできる).
 
◆改善したい点,良くなかった点(Problem)
・一つの点に議論が集中して,当初計画した分量の文書を処理するうえで,計画よりも時間がかかった.
・Googleドキュメントを使ったので,全員がドライバーになりファイル操作をした時間帯があり,ドライバーとナビゲーターの境目が曖昧になった.これは,モブワークの基本的なやり方とは,ズレている.ただし,記述改善の説明や理由を共有することがはできていたので,このようなモブワークのやり方にも価値があると感じた.
 
◆次に挑戦すること(Try)
・作業の効率がよい作業の進め方を決めて,進行のスケジュールを定めて行う.
・振り返りの結果を,次回のモブワークに適用してモブワークのやり方をブラッシュアップする.
・モブワークの原則に従い,皆で同じ画面を見て作業する.
 
各チームの発表の様子を写真でご紹介します.
 
◆チーム1
 
話題沸騰ポットは水温が一定以上上昇するとエラー検出する仕様です.チーム1は,水温検知のサンプリング間隔の記述漏れに気づき,仕様書に書かれているグラフの修正もしました.
 
◆チーム2
 
元の文書は多様な情報がフラットに書かれていました.チーム2は,要求仕様書の章立てを細かくし,さらに,各章の文章に適切に表を挿入しました.これらのことで,要求仕様で伝えたいことが構造化され,文書品質の論理性が高まりました.
 
◆チーム3
 
元の文書は,一般的ではない用語が使われていました.チーム3は,用語を変更して,本質をわかりやすく伝える努力をしました.
 
 このように,それぞれのチームは様々な議論を展開しました.そして,各チームに共通して以下の点を認識しました.
・1つ1つの文を査読する際,章全体を意識して行うことで,文書品質の論理性を高めることができる
・長文で記述すると,読み取るコストが増える.文書品質の可読性と理解容易性を高めることが必要.そのように丁寧に文書を書くと時間がかかるかもしれないが,開発全体で見ると,読み取る時間が減り誤りも起こりにくくなるので,にコスト削減に繋がる
・助詞や接続詞を適切に使う努力をすると,文書品質の論理性が高まる.
 
最後にバンザイすることで達成感が得られます(これもモブワークならでは).
 
今回の討議結果を基に,文書品質モデルのガイドライン作成を進める予定です.

 


投稿日時 2019-06-29 13:32:24 (2172 ヒット)

2019年6月28日に、令和初の2019年度総会・第21回研究会を大崎ウエストギャラリー(東京都品川区)にて開催しました。

 
はじめに、2019年度定期総会を開催しました。出席者が27名で委任状が53個提出されており総会の成立条件(会員数の1/2)を満たしていることを確認しました。そして、2018年度の事業報告と決算報告、2019年度の事業計画と収支計画と役員改選について事務局から説明しました。皆さんの承認をいただき、無事に総会を終了しました。
総会では、文書品質モデルの普及や実用化に向けて、活動を活性化すべきとの意見を頂戴しました。この研究会は、皆さんとご一緒に進めています。今年度も、ワークショップや大会などへのご参加を含めて、ご協力くださいますようお願いします。
 
次に、第21回研究会では、新森昭宏さん(インテック)からご講演「自然言語処理技術の最近の発展と日本語文チェックへの適用について」と、ASDoQからシステム文書品質モデルに関するワークショップを行いました。
新森さんのご講演では、ご自身が開発され、社内で文書改善のために取り組まれている日本語文チェックツールについてお話しいただきました。
日本語文チェックツールはインテック社内の議事録・設計書・報告書等のチェックに使われています。ツールのポイントは下記です。
  • オープンソースソフトウェアツール(redpen他)を最大限に活用した
  • 特にExcelファイルからのテキスト抽出を工夫した

しかし、ルールベースのため指摘の質に改善の余地があるそうです。具体的には下記です。

  • 文脈を把握した上での指摘
  • 指摘するだけでなく、OK例の提案
新森さんは現在、自然言語処理のための最先端言語モデルである「BERT」の成果を日本語文チェックツールに応用する研究をされており、その研究内容や今後の可能性もご紹介くださいました。BERTに関して、ご自身でプログラミングしたりCourseraのeLearningで学ばれたご経験を踏まえて、分かりやすく解説していただきました。フロアからは質問が飛び技術的な議論が交わされ、充実した時間でした。
BERTは、例えば、学習していないシステムにとって新しい文を与えたときに、それが曖昧であるか否かを識別できる能力を持ち得ます。この技術を発展させることで、ASDoQで関心を持つ文書品質のいくつかの指標を、自動的に測定できる可能性がありそうです。
講演の後には、文書品質モデルの普及と実用化への取り組みとして、測定項目をより使いやすくするためのワークショップを、以下のステップにて行いました。
  1. 個人ワークにて文書品質モデル内の測定項目に関して、次の点を考察
    • 説明文(意味の確認)
    • NG例
    • 他の品質特性との関係
  2. グループワークにて、それぞれの理解や考察を共有
  3. グループ毎に発表し、議論
今回は6グループに分かれて作業をしました。

1班:読み手と書き手の知識量に乖離があるという事実に着目し、用語定義の必要性を提案くださいました。

2班:例文を作成し、どの測定項目に違反しているか整理していく中で、測定項目に一意性が無いことを発見しました。

3班:測定項目の説明として「NG例」「NG理由」「NGの影響」「OK例」を提案くださいました。

4班:完全性の正確性(記述内容が検証可能である)に着目し、非曖昧性や合目的性との繋がりを発見しました。

5班:上流(書き手)と下流(読み手)の暗黙値について着目し、闇雲に指摘検証するのも考えものという新しい発想を得ました。

6班:NGの具体例は必須と提案くださり、さらに測定項目は実は最小粒度ではないというアプローチをしてくださいました。
発表いただいた内容を後日に事務局でまとめ、サマーワークショップ(*)のインプットにします。

(*)サマーワークショップ
毎年ASDoQでは、夏の京都@鴨川で合宿形式のワークショップを開催しています。鴨川のせせらぎに涼しさを感じつつ、開発文書について熱い議論を交わします。
今年は8月23日(金)-24日(土)を予定しています。会員の皆様には,MLでご案内しました.申込みURLを以下に示します.
皆さんのご参加お待ちしております。

今年度も研究会、ワークショップ、ASDoQ大会を計画しています。皆さんからのご意見やご要望を取り入れながら進めていきたいを思いますので、どうぞよろしくお願いします。


投稿日時 2019-03-02 16:05:15 (1899 ヒット)

2019年2月20日 名古屋ウインクあいちにて、第20回研究会を開催しました。

今回の研究会では、ASDoQ大会2018で審査員特別賞を受賞された発表チームのお一人であるデンソークリエイトの山路厚さんに、より詳しく話して頂きました。「開発文書の品質の可視化」と題して、原理的思考に基づいた正しく伝わるレビューの記録方法の講演とワークをして頂きました。

ワークでは実際に文書のレビューを行いました。 相手に正しく伝わる指摘を作成する難しさを改めて体感できました。

現場のレビュー指摘内容は間接情報が多く、指摘内容を理解するのにかなりの労力を使っています。 デンソークリエイトでは、指摘内容を直接情報で理解できる仕組み(Lightning Review)を導入しているそうです。それにより以下のような効果が出ているそうです。

・差し戻し件数が1/8に減少した
・軽微な指摘も全て記録になった
・カイゼンのための材料(記録)を蓄積できるようになった

そして、レビュー指摘の記録がどのように文書品質に役立つかを皆で議論しました。

次に、ASDoQ運営委員の山崎伸洋さんの司会で、システム開発文書品質モデル(ASDoQ発行)の継続的な改訂のために改善点の討議を行いました。主に以下のようなトピックで議論をしました。

・文書品質モデルがなぜ必要か
・使いにくい、わかりにくい点はないか
・どのように使えるのか

個人ワークの後はグループで討議しました。


発表の様子(グループ1)
・文書として体を成すという視点で文書品質を定義しているのは有意義
・分類が難しいため、ツールで分類を自動化できないか
・人のスキルに依存する


発表の様子(グループ2)
・レビュー時に有効(指摘傾向の分析)
・分類に時間がかかるのがネック
・完全性、規範適合性がイメージしにくい


発表の様子(グループ3)
・教育に活用したい
・使う人に応じた使い方ガイドラインが必要(初級編、中級編等)


発表の様子(グループ4)
・具体的にカウントできるものを持ってくると、基準がわかりやすく測定しやすくなるのでは(SQuaREが適していそう)
・完全性という項目のネーミングを見直してみてはどうか
・フローチャート等で分類ガイドを作る


発表の様子(グループ5)
・使い方ガイドが必要
・項目が多く分類を難しくしているため、項目を減らす
・項目は技術/テクニカルライティングの2つに分ける

まとめますと、以下の必要性が分かってきました。

・各品質特性の更なる明確化
定義と範囲の更なる明確化、及び、特性の分類を可能にする具体例
・使い方のガイドライン
使う場面にあわせて、文書品質モデルの有効性と使い方を示すもの

 

引き続き、システム開発文書品質モデルの有効な活用のための改善を進めていく予定です。


« 1 ... 5 6 7 (8) 9 10 11 ... 27 »

メニュー

サイト内検索

ログイン

ユーザ名:

パスワード:

次回からIDの入力を省略



パスワード紛失