はじめに
DRBFM（Design Review Based on Failure Mode）をご存じでしょうか？
トヨタ自動車株式会社が開発した、製品開発における品質確保の手法の一つです。
この記事では、DRBFMの進め方についてご紹介します。
そもそもDRBFMとは？
「変更点」と「変化点」に着目し、品質を高めるための手法です。設計やプログラムの「変更」によって、思わぬバグが生まれるという経験は、開発者であれば、誰でも経験があるのではないでしょうか。
そうした問題を未然に防ぐため、「変更点」を出発点として考えるものです。なお、自動車業界やハードウェアの開発に限らず、クラウド上でのサーバアプリやウェブアプリなど、さまざまなソフトウェア開発で活用できるものです！
実施の流れ
DRBFMの実施の流れは以下の通りです。
① 変更点と変化点を抽出する
② 変更点と変化点から、問題点や心配点を分析する
③ 問題点や心配点に対する設計方針を検討する
① 変更点と変化点の抽出
まずは、どのような「変更」をするのかを抽出しましょう。これは、工程ごとに抽出するレベルが変わってきますので、基本設計DRBFMであれば、基本設計として、設計を「変更」する内容を抽出します。
また、その変更をすることで、どういう「変化」が生じるのかも抽出します。ここで抽出したい変化点は、動作上の変化だけではありません。
あくまで一例ですが、以下のような変化点も抽出することが求められます。
- 設計変更することで、メモリ使用量が変化する。
- 設計変更することで、呼出先のAPIの呼出頻度が変化する。
- 設計変更することで、サーバ間の通信量が変化する。
- 設計変更することで、当該機能の呼び出されるタイミングが変化する。
② 変更点と変化点から、問題点や心配点を分析
続いて、これまでに抽出した「変更点」と「変化点」それぞれが起因して発生するかもしれない心配点を考えていきましょう。
変更点・変化点を「縦軸」、システム内の機能やモジュールなどを「横軸」にして分析することで、別機能や別モジュールにも影響していることに気づくきっかけになります。
一例として、以下のような切り口で洗い出すことが有効です。
- できない
- できるけど違う
- できるけど多い
- できるけど少ない
- できるけど遅い
具体的には、以下のような問題点や心配点が上げられます。
- メモリ使用量の変化に起因して、メモリ不足例外が発生して正常動作しなくなる
- 呼出先のAPIの呼出頻度に変化に起因して、クラウドの利用コストが増える
- サーバ間の通信量の変化に起因して、タイムアウトが発生する
- 当該機能の呼び出されるタイミングの変化に起因して、正常動作しなくなる
③ 問題点や心配点に対する設計方針を検討
最後に、これまでに分析した「心配点」や「問題点」に対する設計方針を検討します。問題点・心配点が起こる要因をなぜなぜ分析することで、より真因にフォーカスした設計方針を検討できるようになります。その方針に基づいて設計できているか、できていなければどういう設計にするべきかを考えていきます。
一例ですが、考え方として以下のようなものがあります。
- その心配点・問題点が起こらないようにする設計を考える
- その心配点・問題点が起こったときに、サービスが停止しないようにする設計を考える
- その心配点・問題点が起こったときに、検知できる設計を考える
まとめ
上記のDRBFMの手順で検討することで、ある「変更点」に対して設計すべき点が浮かび上がってきませんか。これが、DRBFMを実施する効果です。
DRBFMが開発プロセスになくても、設計DRでDRBFMの流れに沿った議論をすることで、検討すべき内容が見えてくるかもしれません。
ぜひ、皆様の品質向上に向けて、DRBFMの活用を検討してみてください。
