はじめに
ソフトウェア・シンポジウム2020で、「要求仕様の誤解釈を検出する Domain Word Modeling の提案」というタイトルの発表をした。
この発表へのフィードバックを通して得られた知見を記録しておく。
発表資料
発表内容の概要
状況
要求仕様の誤解釈による手戻りが発生していた．誤解釈は，「抽象的に表現された用語」を「不足している前提知識」で解釈することにより発生していた．
問題
要求仕様のレビューは実施していても，このような用語の誤解釈を防止しきることはできていなかった．
フォース（制約）
解決策の導入障壁を下げるために以下の条件を満たす手法とする．
・実開発で使用されている要求仕様の形式を変更せずに実行できる
・考案手法を未経験の状態からでも，手法の説明を受けただけで実行できる
・フリーソフトウェアで実行できる
解決策の有効性と効率性は，「モデリング実施者とモデルのレビューアがもっている前提知識」と「入力文書の質」に依存する．
解決策
Domain Word Modelは，要求仕様と前提知識を入力として，用語の関連を木構造で表現する．モデリング実施者とモデルのレビューアの間で解釈の相違を検出するために，用語を解釈するための前提知識を，モデルで可視化し，レビューする．モデルの作成とモデルのレビューを通して，「抽象的に表現されている曖昧な用語」と「解釈のための前提知識が不足している用語」を検出する．
発表へのフィードバックから得た知見
- 同義語が多いと、モデリング（解釈）のための準備に、かなり時間がかかる。同義語を使わないor検出するための仕掛けは、何か必要。
- 理解できていない概念は、モデルが書けない。モデリングを通して、理解できていない概念が特定できる。モデリングを通して、獲得すべき知識（伝えるべき知識）が絞り込める。
- 出来上がるモデルがモデリング実施者のもつ前提知識の影響を受けすぎる。個人個人の解釈が可視化でき確認できる反面、誰がやっても同じようなモデルが作成できないとなると、モデルを後工程の入力としては使いにくい。
- 実プロジェクトに導入するために必要なことは、導入障壁を下げた手法なので、あとは「やっみよう」という気持ちと回答したが、実際には自分がマネージャでないプロジェクトでは導入されないかもしれない。そもそも、仕様の誤解釈をどうにかしたいという問題意識を持てていないと、手法に興味を持てない。まずは、問題があるかを把握することが必要。
- 本手法では誤解釈の可能性のある用語を特定できるだけ（偽陽性の可能性もある)。モデリングによるフィードバックに対して、「解釈できるだろう。問題ないだろう。」と判断されやすい。フィードバックを真摯に受け取り活用するには、要求仕様定義者が、”自分は「わかったつもり」になっている”と認識することが大切だと思う。モデリングのレビューで、「なるほど」等の気づきが得られたことによる発言があるとよい。
- モデリングとモデリングのレビューを通して、解釈を共有するための良い議論ができる。顧客・ユーザや後工程の人たちのために、出来る限り厳密な表現をしようと考え、手間を惜しまないチームであれば。異なる意見があることを、良いことだと考えるチームであれば。
- モデルをレビューする人が、モデリング実施者と同等レベルの知識をもっていなければ、レビューアからよいフィードバックが得られない可能性が高いかも。
- モデリングはペアワーク・モブワークでやるのは効率的かも。モデリングしてレビューするという段取りとペアワーク・モブワークでやるという段取りを比較してみたい。
- 要求仕様定義者とテスト設計者（orテスト分析者）が、ペアワーク・モブワークでモデリングをするというのは、よいプラクティスになるかも。
- モデリングをどこで終了するかという基準も必要か？モデリングの参加者全員が納得感を感じたら終わりという基準ではあいまいか？終われないか？
- モデリングは大変な作業。モデリングを楽しい・効果的と感じられる人しか続けられないかも。
- マインドマップは書き方がない。マインドマップだったら、書き方の指摘はでない。書き方の指摘は論理に対する指摘となる。
関連記事