D-Case を用いたレビューを見える化する方法の導入事例小林展英† An experience of Introducing D-Case based Review method KOBAYASHI Nobuhide ねらい本報告では、D-Case を用いることでレビューにおける説明を見える化し、その内容に基づいてレビュー対象成果の妥当性を判断する仕組みを導入した事例を紹介する。キーワード D-Case、GSN、レビュー、説明、合意形成 Target: This report is to introduce an experience of introducing D-Case based review method. Keywrds: D-Case, GSN, review, explain, consensus １．想定する読者・聴衆本報告はソフトウェア開発のレビューにおいて対象成果の妥当性を説明する担当者、およびその説明に基づいて対象成果の妥当性を判断する顧客、あるいは上位者を想定している。 2．背景昨今、米国におけるトヨタ自動車の大規模リコール問題のように欠陥のない製品であっても訴訟に発展し、見える化する手段として文献 [3] で提唱されている D-Case を採用し、D-Case を用いたレビューの方法をソフトウェア開発のレビューに導入した事例について紹介する。依頼側・開発側ともに理解していること（世の中の常識）開発側の背景（組織の常識）依頼側の背景（組織の常識）受け取る情報の前提（議論毎の常識）受け取る情報伝える情報の前提（議論毎の常識）文書伝える情報和解金の支払い等の損害を受ける可能性がある。この背景には、文献[1]にも述べられている通り第三者が納得できる形で製品の妥当性を説明できていない実態が考え方考え方語彙語彙相手あると予想される。こうした状況を踏まえて自動車業自分図 1 説明モデル界では説明責任を果たすための取り組みが重要視されつつある。本論文ではその取り組みの一つとして、ソフトウェア開発におけるレビューに着目し、レビューの説明内容を見える化して自分と相手が正しく議論できる方法を導入した事例について紹介する。 3．課題上位者の指示通りに成果物を作成してもレビューで承認されないと感じる担当者、あるいは何度同じ指示をしても担当者が意図通りに成果物を作成してくれな背景で紹介した問題と同様に相手が納得できる形で自分の伝えたいことを説明できていないことに起因すると考えられる。文献[2]にも述べられている通り、自分の伝えたいことを相手に正しく説明するためには、図 1 に示した自分の使う語彙や常識といった議論の前提、および説明に用いる考え方が相手と共有できている必要がある。このため、このモデルに基づく説明の構造を見える化してレビューに臨めば先に述べた問題を解方に相当する情報を D-Case の戦略ノード、文書に相当する情報を D-Case の証拠ノードに対応づける表記規約とした。また、従来の方法との変化点として図 2 に示す 4 つの手順を定義している。手順1：前提となる文書を揃える・相手と合意形成できている文書を揃える・不足する場合は右記の４状態を念頭に新規に用意する相手フトウェア開発の現場で耳にするこのような事例は、今回の取り組みでは、図 1 の説明モデルに示した語彙や常識に相当する情報を D-Case の前提ノード、考え知らない知っているいと感じる上位者は少なからず存在すると考える。ソ 4．提案・実験 ③文書化 ④一緒にして理解を文書化する得る ②教えて ①合意形成もらってできている文書化知っている知らない自分手順4：D-Caseで説明する・"構造に関する文書"に基づいて説明したいことを手頃な大きさに分解して説明する・説明の妥当性は、"条件に関する文書"を成果物が満足していることで納得を得る・上記流れで相手の納得を得られなければ手順１から再チャレンジ！手順2：説明の構造を設計する・手順１で揃えた文書を前提として説明の "説明したいこと" 構造を設計するゴール前提構造に関する文書前提条件に関する文書は妥当である前提に従って説明する構造の構成要素は妥当である戦略・・・手順3：成果物を証拠に紐づける・説明の妥当性を最終的に支える証拠として条件を満足できる成果物を紐付ける条件に関する文書構造の構成要素は妥当である条件を満足できる成果物図 2 D-Case を用いたレビュー方法の手順消できる可能性が高い。次章以降では、説明の構造を 1 従来のレビュー方法と D-Case を用いたレビュー方法説明対象の構造や合格基準との関係を明確に表現でき、を比較するため、同じ事例に対して両者の方法に従っ議事録に従った説明では見落としてしまっていた不備てレビューを実施した結果を以降に記す。を検出できたと考える。図 3 は従来のレビュー方法に従った説明内容を示しまた、体系的な導出には至っていないが、D-Case のており、担当者は図中左下に記載した表形式の議事録描き方と成果物の品質の相関関係から以下のアンチパに従って ConvMsec()に仕様追加された変換規則②に対ターンを導出することができている。するテスト実施結果の妥当性を説明している。・複数のゴールが一つの証拠に集約している場合、一方、図 4 は承認する立場にある上位者の考える合複数の視点が一カ所に混在した文書になってい格基準を D-Case の前提ノードとして見える化し、それる場合が多い（文書品質が低い可能性が高い）。に基づいて分解されたゴールを支える証拠として担当・戦略にレビュー対象の構造や属性を示した前提者が作成した成果物を紐付けた結果である。D-Case 中が関連づけられていない場合、分解されたゴールの G4 の合格基準を示す C3 を満足できていない成果物が網羅的でない場合が多い（納得感が薄い）。 Sn4〜Sn6 の存在が検出できており、D-Case を用いたレ・ゴールに証拠の判断基準となる前提が関連づけビュー方法の有効性が確認できたと考える（本事例でられていない場合、証拠のレビュー基準がレビュは G7 の証拠となるテストを実施した結果、処理の流れーアの感覚の場合が多い（客観的な根拠がない）。上述したアンチパターンに合致する D-Case は、担当中の欠陥を発見できた）。者の作成した成果物の内容や構造が上位者の考える合 ① secを1000倍した値を*msecに格納し、E_OKを戻り値とする。 ② secが255より大きい場合は*msecに255000を格納し、 E_OVERを戻り値とする。： Ver.1.01改訂テスト項目数は十分であるか？：仕様を満足することが確認されているか？妥当性証拠判断 OK テスト仕様書： OK ：テスト報告書 sec＞255 ⑦ ⑥ sec = MAX; ② 妥当性判断の根拠既存処理をコードレビューで押さえ、追加処理の境界値に関するテスト項目を抽出。：テスト仕様書の該当項目がすべて合格している事前に担当者とアンチパターンを共有しておくことで、 ret = E_OK; ① ※ ＜設計品質レビューの報告内容＞確認事項格基準を満たしていない場合に出現する。このため、成果物の品質向上につながることが期待できる。それ以外 ret = ConvMsec(unsigned short sec, unsigned long *msec); ＜変換規則＞＜処理の流れ＞ 6．まとめ(今後の課題・謝辞等) 本報告では、D-Case を用いて上位者の考える合格基 tmp = sec×1000;③ sec==MAX ⑧ ⑨ ret = E_OVER ④ 準と担当者が作成した成果物を紐付け、レビュー時にそれ以外＜インタフェース仕様＞ *msec = tmp; ⑤ ※MAX=255 図 3 従来のレビュー方法に従った報告内容議論すべき内容を見える化することで、表形式の説明では見落としがちな成果物の不備を検出できることを確認できた。また、構造化された図解表現の特性から成果物の不備を視覚的に推測できるアンチパターンもいくつか導出することができた。今後は、D-Case 中の前提ノードに記述された判断基準や上述したアンチパターンを上位者の経験として資産化し、次の開発時に再利用できる開発サイクルの確立に取り組んでいきたいと考えている。最後に、D-Case に関する体系的な知識をご教授頂いた名古屋大学山本修一郎先生、および本取り組みの導入に協力頂いた全社員の皆様に感謝します。 7．文献 [1] 保証ケース議論分解パターン[応用編], 月刊ビジネスコミュニケーションズ 2013 年 5 月号 http://www.bcm.co.jp/site/youkyu/youkyu100.html [2] プロジェクトコミュニケーション管理プロセスの適用評価, SEC Journal 32 第 9 巻図 4 D-Case を用いて報告内容の構造を見える化した結果 https://www.ipa.go.jp/files/000028900.pdf [3] 実践 D-Case ディペンダビリティケースを活用しよう！ 5．効果 http://www.dcase.jp/pdf/JissenDCase.pdf [4] 「レビューの質モデル」による品質向上について D-Case を用いたレビュー方法を導入したプロジェク http://www.ipa.go.jp/files/000005324.pdf トは、文献[4]で述べられているように議事録の確認事項に従った手順中心の説明に陥り、本来議論すべき成果物そのものの品質に関する議論が薄くなってしまう傾向にあった。今回、D-Case を説明に用いたことで、 † Denso Create Inc., 3-1-1, Sakae, Naka-ku, Nagoya, Aichi, Japan E-mail: [email protected] 2