ASDoQ大会2014(4)：パネルディスカッション「開発文書はどのように進化すれば良いのか」
2014/10/17(金)に開催されたASDoQ大会2014の聴講内容を紹介します。
今回(最終回)は、パネルディスカッション「開発文書はどのように進化すれば良いのか」です。
なお、過去に書いた記事は下記を参照ください。
ASDoQ大会2014(1)：講演1「自動車分野・機能安全分野での文書要求と開発プロセスの対応」 - MasaoApril's Library.
ASDoQ大会2014(2)：講演２「ここがダメ！日本人技術者の文書力」 - MasaoApril's Library.
ASDoQ大会2014(3)：講演3「アジャイル開発における ドキュメンテーションの考え方」 - MasaoApril's Library.
以下、パネルディスカッションの内容をパネリスト毎にキーワードとして紹介します。
パネルディスカッション「開発文書はどのように進化すれば良いのか」
- モデレータ：山本雅基(ASDoQ代表幹事/名古屋大学)
- パネリスト：安倍秀二(パナソニック株式会社)、細谷泰夫(三菱電機株式会社)/ディン・ティエン・フゥン(FPTジャパン株式会社)/山本修一郎(ASDoQ/名古屋大学)/藤田悠(ASDoQ幹事/長野工業高等専門学校)
安倍秀二(パナソニック株式会社)
[1]D-Case
要求と証拠のインターフェイス
[2]文章品質向上
設計スキル：スクラッチから書く人
[3]テンプレート
「テンプレートの内容ではが書きにくい」「テンプレートに書く時間が無い」と言うエンジニアがいる。
→どのようにテンプレートを変えたら書きやすくなるか、提案してほしい。
細谷泰夫(三菱電機株式会社)
[1]D-Case
- SQiPシンポジウム2014の発表(【経験発表】D-Case導入によるシミュレーションS/Wの期待結果明確化と合意形成)の実例では、ステークホルダ間で合意を形成する手法として適用した。
- 要求が厳しいけど、制約は緩い。
→例えば、「データの遅延をどこまでみるか？」についてどのイテレーションで実施するかを決めている。
[2]自部署での実例：新人教育
- ソフトウェア設計未経験の新人：ソフトウェア開発工程(要求仕様～テスト)を経験
- 新人がこれから配属される部署：ハードウェア設計や生産設備管理など多種多様の業種
- 開発スタイル：アジャイル開発
→理由：毎日フィードバックして短期間でソフトウェアライフサイクルを体験させるため - 新人とベテランと共に主語や動詞を明確にした上で議論
S/W構造を模造紙で書いたところ...
- クラス構造が得意な人：複雑なクラス図
- クラス構造が不得意な人：シンプルなクラス図
という結果となった。良いところ、改善するところが明確になった。
[3]ユーザストーリー
- 目的を明確に書く
- 日本語能力が必要
- ユーザストーリーの不足点は、図で書いて表現
[4]トレーニング手段の一例
- 電子メール
- インシデントレポート
ディン・ティエン・フゥン(FPTジャパン株式会社)
[1]D-Case
文章では理解が難しいので、図の表現で理解が促進されるのでは？
[2]結果だけでなく、考え方も書ける人
設計ができること
山本修一郎(ASDoQ/名古屋大学)
[1]D-Case
- 自分がやったことを第3者が理解するか？→説明責任
- 一方で、「厳密に説明する必要があるか？」という議論が欧州である。
[2]QA活動
KKD(勘/経験/度胸)
→人依存：「もし担当者がいなくなったらどうなるか？」
[3]アシュアランスケース
- ○○の危険に対し、△△の対策を行っている。
- 証拠を残す
- 想定外の異常
[4]世の中あいまいな事が多い
大学は正解がある(と教育されてきた)。
→他人より優れた解を見つける人が価値がある。
[5]あいまいな新聞記事
主語/目的語などを分解する
→やり方を知っていれば、新しいモデルが出ても書くことができる。
[6]参考資料
http://www.mhlw.go.jp/shingi/2010/02/s0202-4.html
藤田悠(ASDoQ幹事/長野工業高等専門学校)
[1]D-Case
文章の品質特性：分解の理由を関連付ける
[2]接続詞
- 重要と考えている。→理由：流れが明確なため。
- 逆説で例えると、「飲み会はやります、が伏見で開催します」
所感
パネルディスカッションを一言で表現すると、
- 「相手に伝える」
- 「自分が理解する」
- 「自分と相手が認識を合わせる」
の3点が大切な要素と捉えました。
私が関わっているプロジェクトでテスト仕様書を書いていますが、テストベースとなる外部設計書や過去のテスト仕様書などを参照すると、
「誰にとって何を実現する機能なのか？」
「どのような入力条件で動作するのか？」
「機能における制約条件は？」
「何に着目して確認したいのか？」
など、担当者に記述内容の意図を質問することで理解を進めたり、誤解しない書き方を提案することがあります。自分が記述したテスト仕様も相手によっては、理解しづらい/意図が分からないこともありますので、要素を分解して論理的な繋がりが明確になるよう、論理的思考のトレーニングが必要と痛感しました。
