【DFSS とは何か、連載目次】
前回、その2では DFSS のフレームワークや主に使われるツール類など、少し詳細なことに触れてみました。良いことばかりの DFSS ですが、実際に導入しようとすると、色々と障害があるものです。今回は、そんな DFSS 導入の難しさです。
1. 皆、スパーヒーローが大好き
バットマンやスーパーマン、キャプテン・アメリカにスパイダーマン、皆、スパーヒーローが大好きです。最後にやって来ては悪人どもを叩きのめします。でも、よく考えてみれば、どうして最後にやってくるのでしょうか。すでに街も壊され、多くの命が亡くなってからやって来ても遅いと思うのです。それよりも、悪人が出てこないように日頃から何らかの対策をするとか、もし悪人が出てきてしまっても、被害が大きくなる前に何らかの予防策を施すとか、もっと効果的なやり方があるはずです。
日頃からそのような対策を施す街の職員や警察の方が、よっぽど重要なのに、何故か後からやってくるスーパーヒーローの方が良い仕事をしているように見られるのは、どうも納得が行きません。
映画や TV だけでなく、同じような事は職場にもあります。不具合の少ない丁寧な設計をスケジュール通りに完了するエンジニアと、納期間際まで残業を続け、納入後も不具合対策で深夜まで働き続けるエンジニアと、どちらが給料が高いでしょうか。どちらが出世するでしょすか。恐らく不具合対策に力を入れるエンジニアの方が、会社のウケは良いでしょう。少なくとも僕が以前働いたことのある会社はそうでした。
DFSS は不具合が少ない良い仕事をするので、残念ながら、あまり認めてもらえないのです。
一方、リーンシックスシグマのブラックベルトやグリーンベルトはスーパーヒーローです。何か問題が発生したら、さっとやって来て、問題を解決してしまいます。問題が実際に発生しているので、解決の前と後の比較も容易です。リーンシックスシグマの知名度が高いのはこのためでしょう。
DFSS は問題が発生する前の予防策みたいなものなので、その評価がとても難しいのです。津波を想定して、防波堤を建築するようなものです。津波が実際に来るまで、だれもその防波堤を認めようとはしません。
DFSS を導入しようとする際の最初の壁は、ここにあります。皆、トラブルが発生した時には高いお金を払ってでもスーパーヒーローを簡単に受け入れようとするのですが、トラブルを未然に防ぐために街の職員や警察を増やして給料を上げようとすると、一斉に反対するのです。
2. DFSS は余計な仕事
DFSS は顧客要望や仕様を詳細に数値化し、理解しようとします。また考えられるリスクを予め洗い出し、その予防策を施します。つまり設計・開発の前段階での作業が比較的重たくなります。この作業は「やり直し」を防ぐことで、後段階（テストやリリースなど）での作業を軽くするのが目的なのですが、それがなかなか理解してもらえません。
「仕様分析やリスク分析をする時間があったら、さっさと設計を始めた方が良い」と大抵は思われるのです。特にスケジュール管理をしているプロジェクト・マネジャーは、スケジュールを遅らせる余計な事は一切やりたくない、と思う傾向が強いようです。もともと彼らのスケジュールには「やり直し」など入っていないのですから、「DFSS はやり直しを防いでコストを削減し、スケジュールを短縮する」と言っても通用しません。
どうしても DFSS は余計な仕事を追加するように思われがちなのです。これが第二の壁です。
3. プロジェクトが進むまで、分からないことばかり
プロジェクトの前段階での作業が比較的重たいと書きました。つまりプロジェクトの前段階で、色々と考えることが多いのが DFSS の特徴です。ところがその反論として上がってくるのが、「プロジェクトが進むまで、詳細なことが分からない」「分からないところで知恵を絞っても意味がない」というものです。
確かにソフトウェア開発で使われる Agile 手法などは、その発想を元にしています。「取り敢えずソフトウェアを作りながら、もし新しいことが分かったら、追加・修正していこう」という考えです。これはソフトウェアだからできることであって、ハードウェアやサービスの設計では無理があるし、危険でもあります。しかし DFSS 反対論者はこれを論拠に反論してくることがあります。これが第三の壁です。
もしそれが新しいことで、まだ何も知らなければ、なおさら時間をかけて DFSS をやるべきです。時間をかけて顧客の要望を理解しようと努め、リスクを深く分析しなくてはなりません。もし理解や分析が間違っていたら、新しい知識で修正していけば良いだけです。何もしないことと比べれば、製品やサービスの品質は格段に高いものになるでしょう。
