トピックス

  
投稿日時 2014-09-21 20:25:26 (1606 ヒット)

SWEST16は,2014年8月28-29日に開催されました.私たちは,8月28日 21:00-22:30の夜の分科会のセッションを担当しました.

 タイトル:開発文書と感情の意外な関係
 参加者: 山本雅,小林,森川
 内容:私たちは感情を持つ人間ですが,システム開発は,過度に感情的(特にネガティブ)にならずに,冷静に論理的に行うべきです.でも,時々感情に振り回されてQCDを下げる失敗もします.原因は様々ですが,開発文書がきっかけになることもあるはずです.この分科会では,開発文書を読み書きしている時に感じたことを分かち合います.感情という一見場違いな側面から見つめることで,開発文書に対する理解が深まるのでは無いでしょうか.開発文書をイヤイヤ書いたり読んだりすることから卒業しませんか.
 使用したスライド:こちらからどうぞ
 
SWESTの夜に開催されるセッションは,夕食後に開催されます.夕食では,アルコールを飲まれている方が多く,私もその一人です.セッションが居酒屋での愚痴の言い合いにならないようにすることは,モデレータとして注意すべきことです.その試みが上手く行ったか否かは,参加者の皆さんが判断されることです.
 
 
 
何はともあれ,セッションには,40名程度の方にご参加頂き盛況になりました.色々な方にご発言頂き,90分があっという間に過ぎました.
 
発言の多くは想定の範囲内でしたが,多くの方からご意見を頂くと,改めて開発文書の抱える課題が見えてきました.「あいまいに記述された文書に苛ついた」「締め切りを目の前にして焦って書いていた」などの体験談が,参加者の皆さんから披露されました.
 
現在,私たちは,開発文書の品質を考えています.開発文書という「成果物の品質」です.しかし,私たちは,その他に「プロセスの品質」を考えていく必要があるはずです.開発文書を「書く」「読む」という「プロセス」に着目することは,幅広く開発文書の品質を考えていくために,必要なことだと思うのです.
 
「プロセスの品質」へのアプローチは多様です.その中の一つに「一人称としての感情を観察する」と言うアプローチがあっても良いのではないでしょうか.
 
このアプローチは,開発に要する時間やバグ曲線などのデータ分析ではなく,「わたし」という一人称が開発プロセスを通じて「感じる」ことを丁寧に観察することです.生身の人間である「わたし」や「あなた」が,開発という仕事をするのです.品質の追求は,「わたし」や「あなた」の幸せに通じるべきです.
 
開発文書の品質についての追求は始まったばかりです.これから,様々な機会を通じて,取り組んでいきましょう.
(報告:山本雅)
 


投稿日時 2014-07-10 11:18:50 (1921 ヒット)

6月30日に第8回研究会を名古屋大学にて開催しました。

今回の研究会では、活動報告及び品質定義に関する話題提供を行い、 「品質定義プロジェクト」の一環として、 システム開発文書の品質の整理を行いました。

ソフトウェアシンポジウム2014 ワーキンググループ実施報告

藤田が、6月9日から11日まで秋田で行われたソフトウェアシンポジウム2014にて開催した ワーキンググループ「システム開発文書品質」の活動報告をしました。 ASDoQ会員を対象に実施したアンケート結果を基に、 開発者が求める品質として8性質を定義し、それぞれの品質を高めるために寄与する活動をまとめました。

 

人材育成部会の作業報告と討議-私たちが関心を持つ文書作成規則の傾向

山本雅が、人材育成部会で進めてきた活動について報告しました。テクニカルコミュニケーター協会のスタイルガイドを基に、例文を考える活動についてのまとめを紹介しました。 例文が作られたルールと作られていないルールの傾向を分析し、活動の結果からシステム開発文書の品質の上位特性として7特性を提案しました。

 

システム開発文書品質の特性に関する考察

前回の研究会で紹介したシステム開発文書品質の5特性を、塩谷さんが改めて説明しました。 これまでの作業部会で検討した品質特性や、システム開発に関連する品質特性との関係づけの試みなどを紹介しました。

 

システム開発文書の品質の整理

5人ほどからなる3グループに分かれて、 話題提供で示された3種類の品質特性を基に、 システム開発文書品質について整理し、ラベルづけなどをして、 品質特性をまとめる活動をしました。

グループ1では、 何を書くか、どう伝えるかという視点から、2種類の性質に分けられるのではないかという議論になりました。上流工程と下流工程における、品質評価の重みづけに違いがあるのではないかとい意見もありました。

 

グループ2では、 「内容」と「表記」の軸と、品質特性の軸に分けて分類しました。「目的」は全体にかかるので、「前提条件」として別に扱うことにしました。ステークホルダによって、求める品質が異なるので、ステークホルダーを決めて検討することが必要ではないかということが提起されました。

 

グループ3では、提案された3種類の品質特性を、「書くときに必要な品質特性」と「読むときに必要な品質特性」に分けました。「合目的性」については、読む人と書く人それぞれの目的があると考えました。さらに、文書を作成するプロセスに沿って品質特性を位置づけました。

 

 各グループによる発表後、発表全体に対して以下の意見がありました。

  • 「内容」と「表現」に大きく分けられている傾向がある
  • ステークホルダーという視点が重要である
  • 測定を踏まえて特性を検討する必要がある

今後も、会員の皆さんとの討議を進めながら、システム開発文書の品質を定義する活動を継続していきます。


投稿日時 2014-06-22 23:57:58 (1622 ヒット)

2014年6月9日から11日に秋田にて行われたSS2014に、ASDoQとして参加しました。ASDoQから提示したテーマ「システム開発文書品質」に関して、ワーキンググループにて討議しました。

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


« 1 ... 13 14 15 (16) 17 18 19 ... 28 »

メニュー

サイト内検索

ログイン

ユーザ名:

パスワード:

次回からIDの入力を省略



パスワード紛失