リスバーガーのリスクに有効なのは「教育」

かおるんさんのブログにあった「リスバーガー」のお話は色々と考えさせられました。

認定スクラムマスター(CSM)研修のお話らしいので、プロダクトオーナー(この場合は顧客)の判断に従って開発を進めることの大切さを説明したものだと思います。しかし、これを読んでいて、開発者が勝手な判断をするリスクはどんな開発にもあることに気付いて、ゾッとしました。

例えば、何らかの条件で無限ループに入る、メモリーを破壊する、CPUを使い切る、システムを止めてしまう、などなど、です。静的アナライザや安全な言語、ライブラリによって防げることも多いでしょうが、完璧なレビューを行わなければ防ぎようのない問題もあるでしょう。

そんなに完璧なレビューもできないのに、なぜ開発ができるのか私自身も不思議です。よく考えると、「そんなバカじゃない」と開発者を信じているというのが、現実なのでしょうね。

では、どうすべきかと考えると、レビューで無理ならテストとも考えられます。しかし、すべてを自動テストできるなら話は別ですが、後から埋め込まれる危険は減るものの、基本的には下流で防ぐよりも上流で防ぐ方がコストは少ないはずです(でも難しい)。また、形式手法なども考えられますが、アルゴリズムの問題でなくコーディングレベルの問題なら変換ツールで形式化ができなければ効果は期待できません。

さて、基本に戻って考えるなら、リスクは以下の式で表されます。

　　リスク　＝　影響　×　発生確率

この発生確率を「発見し損ねる確率」と考える所に無理があるのかもしれません。素直に「埋め込む確率」と考えれば良いと思います。つまり、開発者を信用せざるを得ないのだから、信用を高めればよいのです。安全な開発をするには、安全な開発が行えるようにするのです。

以上から、人に依存するリスクの低減に効果的なのは「教育」だと思いました。かつてテストで有名なＮ先生が「武士道の極意は刀を抜かずに人を切る、テスト道の極意はテストをせずにバグをなくす」といわれていました。危険なバグ(問題)を作らないように教育するということは、とても大切なフロントローディングの方法なのだと思いました。

いかがでしょうか？