USDMとDRBFMを羅針盤にして派生開発を成功に導く

NECソフト株式会社
酒井　賢

４.２　DRBFMの導入

USDMがメンバーに完全に定着した段階で、「DRBFM（Design Review Based on Failure Mode）」を導入しました。

DRBFMはトヨタのGD3（ジー・ディー・キューブ：Good Discussion, Good Design Review, Good Design）の一翼をなすもので、吉村達彦氏の造語です。「未然防止」の手法で「まだ起きていない問題の発生を予測し、それが起きないように未然に防止すること」を目的に考案されました。

・ 変更点・変化点と機能に着目
・ レビューによって心配点の発掘・探索
・ 叡智を集め対策を作り込む

という考え方の下に、次のような表を使って、レビューを行います。

図 2 DRBFM記入表

※「トヨタ式未然防止手法GD3 いかに問題を未然に防ぐか」吉村達彦著 （日科技連）を参考に作成

DRBFMは次のように行います。

私たちは、導入当初の何度かは、図2の表をそのまま使ってやってみましたが、記入やレビューに時間がかかる割に効果が現れませんでした。

メンバーに変更要求仕様書とその背景となる考え方がすでに浸透していたため、変更要求仕様書を完成させた段階で、DRBFM表の項目のような想定される問題はすべて考慮済みとなっていたのだと思います。
”思いもよらない”問題の発生を防ぐには、あまり形式ばらずに、「なんとなく怪しい感じがする」とか「ここは、あとあと何かが起きそうだ」など、理屈では説明できないけれど、経験上なんとなく焦げ臭いところを吸い上げて記録しておき、全員レビューのたびに気づきを誘発する、そんなものが必要なのではないかと思いました。「変更要求仕様書」が論理的な思考をあつかう「左脳」だとすると、予想や直感などをあつかう「右脳」に相当するものです。
そのような発想で出来上がったのが「心配点シート」です。

４.３　心配点シート

心配点シートはDRBFMを使ってみてやりにくかった点をスリム化して、変更要求仕様書とセットで使えるようにしたものです。基本的な考え方は、DRBFMと同じです。

次のような工夫を施しました。

・ 変更要求仕様書と一体化できるように、要求事項と対になるようにした
・ 詳細化しないように、わざと最上位要求という大くくりの単位で作成するようにした
・ 気づきを誘発させるためにDRBFMの表よりもゆるいフォーマットとした
・ 各工程のレビューフェーズでつねに記入できるような欄をあらかじめ設けた

試行錯誤の結果、最終的には、次のようなフォーマットに落ち着きました。

図 3 心配点シート

心配点シートは次のように使います。

変更要求仕様書と同じファイルに納める

心配点シートは変更要求仕様書と対を成すものなので、変更要求仕様書と同一のファイルに別シートとして納めます。（図4参照）
シートの単位は、変更要求仕様書の最上位要求単位として、シート名も最上位要求のIDを記入します。

図 4 心配点シート

シートの上段

上段左側に、変更要求仕様書の大要求の「要求事項」を、左側には「理由」を、変更要求仕様書どおりに記入します。

シートの下段：左側

左側に「変更するにあたっての懸案・心配点」をなるべく短く記入します。レビューで気づきを誘発するのが目的なので、詳細に書く必要はありません。今はまだ発生していないけれど、将来発生しそうな問題、なんとなくぼんやりした不安点などを、論理的かどうかは気にせず1行につき1つ記載します。

シートの下段：右側

右側には各工程のレビュー名を記載します。おそらく一般なウォーターフォール開発では、基本設計、機能設計、詳細設計、単体テスト…など細かなフェーズに分かれると思います。それらのフェーズをあらかじめすべて記入しておきます。（図3では工程を簡略化しています）

変更要求仕様書を作成しながら記入する

変更要求仕様書を作成している最中はいろんなことを気にしているはずです。多くは仕様化することで解消されるでしょうが、それでも変更要求仕様書作成段階では払拭できない心配点は少なからず残るはずです。そうした心配点を漏れなく記入しておきます。

変更要求仕様書レビュー時にレビューする

変更要求仕様書のレビューのたびに、レビューメンバー全員で、心配点が顕在化するかどうかを考えます。特に思いつかなければ「対処の必要なし」と記載して済ませます。何か気づきがあれば、「その心配を取り除くためにどんな対処をしたか（するか）」を記入します（図3の赤字の部分）。検討している最中に新たな心配点が浮かんだら追記して、さらに検討を行います。