前回は DFSS のフレームワークや主に使われるツール類など、少し詳細なことに触れてみました。良いことばかりの DFSS ですが、実際に導入しようとすると、色々と障害があるものです。今回は、そんな DFSS 導入の難しさについて書いてみようと思います。
1. 皆、スパーヒーローが大好き
バットマンやスーパーマン、キャプテン・アメリカにスパイダーマン、皆、スパーヒーローが大好きです。最後にやって来ては悪人どもを叩きのめします。でも、よく考えてみれば、どうして最後にやってくるのでしょうか。すでに街も壊され、多くの命が亡くなってからやって来ても遅いと思うのです。それよりも、悪人が出てこないように日頃から何らかの対策をするとか、もし悪人が出てきてしまっても、被害が大きくなる前に何らかの予防策を施すとか、もっと効果的なやり方があるはずです。
日頃からそのような対策を施す街の職員や警察の方が、よっぽど重要なのに、何故か後からやってくるスーパーヒーローの方が良い仕事をしているように見られるのは、どうも納得が行きません。
映画や TV だけでなく、同じような事は職場にもあります。不具合の少ない丁寧な設計をスケジュール通りに完了するエンジニアと、納期間際まで残業を続け、納入後も不具合対策で深夜まで働き続けるエンジニアと、どちらが給料が高いでしょうか。どちらが出世するでしょすか。恐らく不具合対策に力を入れるエンジニアの方が、会社のウケは良いでしょう。少なくとも僕が以前働いたことのある会社はそうでした。
DFSS は不具合が少ない良い仕事をするので、残念ながら、あまり認めてもらえないのです。
一方、リーンシックスシグマのブラックベルトやグリーンベルトはスーパーヒーローです。何か問題が発生したら、さっとやって来て、問題を解決してしまいます。問題が実際に発生しているので、解決の前と後の比較も容易です。リーンシックスシグマの知名度が高いのはこのためでしょう。
DFSS は問題が発生する前の予防策みたいなものなので、その評価がとても難しいのです。津波を想定して、防波堤を建築するようなものです。津波が実際に来るまで、だれもその防波堤を認めようとはしません。
DFSS を導入しようとする際の最初の壁は、ここにあります。皆、トラブルが発生した時には高いお金を払ってでもスーパーヒーローを簡単に受け入れようとするのですが、トラブルを未然に防ぐために街の職員や警察を増やして給料を上げようとすると、一斉に反対するのです。
2. DFSS は余計な仕事
DFSS は顧客要望や仕様を詳細に数値化し、理解しようとします。また考えられるリスクを予め洗い出し、その予防策を施します。つまり設計・開発の前段階での作業が比較的重たくなります。この作業は「やり直し」を防ぐことで、後段階（テストやリリースなど）での作業を軽くするのが目的なのですが、それがなかなか理解してもらえません。
「仕様分析やリスク分析をする時間があったら、さっさと設計を始めた方が良い」と大抵は思われるのです。特にスケジュール管理をしているプロジェクト・マネジャーは、スケジュールを遅らせる余計な事は一切やりたくない、と思う傾向が強いようです。もともと彼らのスケジュールには「やり直し」など入っていないのですから、「DFSS はやり直しを防いでコストを削減し、スケジュールを短縮する」と言っても通用しません。
どうしても DFSS は余計な仕事を追加するように思われがちなのです。これが第二の壁です。
3. プロジェクトが進むまで、分からないことばかり
プロジェクトの前段階での作業が比較的重たいと書きました。つまりプロジェクトの前段階で、色々と考えることが多いのが DFSS の特徴です。ところがその反論として上がってくるのが、「プロジェクトが進むまで、詳細なことが分からない」「分からないところで知恵を絞っても意味がない」というものです。
確かにソフトウェア開発で使われる Agile 手法などは、その発想を元にしています。「取り敢えずソフトウェアを作りながら、もし新しいことが分かったら、追加・修正していこう」という考えです。これはソフトウェアだからできることであって、ハードウェアやサービスの設計では無理があるし、危険でもあります。しかし DFSS 反対論者はこれを論拠に反論してくることがあります。これが第三の壁です。
もしそれが新しいことで、まだ何も知らなければ、なおさら時間をかけて DFSS をやるべきです。時間をかけて顧客の要望を理解しようと努め、リスクを深く分析しなくてはなりません。もし理解や分析が間違っていたら、新しい知識で修正していけば良いだけです。何もしないことと比べれば、製品やサービスの品質は格段に高いものになるでしょう。
4. 機能が多すぎるので、すべての機能で DFSS をやってられない
確かに、すべての機能で DFSS をやっていたら大変な労力（人、金、時間）になってしまうし、また意味もありません。
しかし僕が知る限り、それが同じ企業である限り（仮にスタートアップ企業でも）、全く内容の分からない 100% 新しい製品やサービスということはほとんどありません。いくら新しい製品やサービスと言っても、大抵 80% 程は既存の製品やサービスの焼き直しです。DFSS は 20% の新しい機能のためだけに使えばよいのです。Kano モデルなどを使って、NUD（New、Unique、Difficult）の機能だけに絞ればよいのです。
DFSS を導入するには、DFSS を理解した管理職の存在が不可欠です。トップダウンでなければ、DFSS を導入するのは難しいかもしれません。
はじめまして。
masanobuと申します。どうぞよろしくお願いいたします。
最近会社で、DFSSについてほんの少しですが話題になりまして、
調べていくうちに津吉さんのブログに遭遇いたしました。
内容が面白く、とても勉強になりましたので、以降いろいろと記事を読ませていただいております。
まだ社内でDFSSを導入とまではいかないのですが、知識として知っておきたい（メンバーに周知したい）と思っており、何か入門書でご推薦のものがあれば教えていただけないでしょうか。
また、話は変わるのですが、津吉さんは品質管理ほとんどを英語で勉強されてらっしゃいますが、どのような理由でそうされていらっしゃいますか？
自分もできれば英語で学べたらいいなと憧れるのですが、そこまでの英語力はなく、
留学経験などがおありで英語で学ばれていらっしゃるのでしょうか。
もしよろしければ差し支えない範囲で、参考までに教えていただけないでしょうか。
すみませんが、よろしくお願いいたします。
コメント頂き本当にありがとうございます。
DFSSに興味を持って下さる方がいるだけでも嬉しいのですが、さらに僕のブログも見て下さり本当に感謝しています。最近はブログの投稿が滞っていましたが、masanobu さんのコメントに励まされました。
品質管理についての日本語の書籍はたくさんありますが、DFSS に関する日本語の書籍は殆ど見当たりません（少なくとも僕は知りません）。2018年1月13日の投稿で紹介した「図解リーンシックスシグマ」という本の中で、「新しいプロセスを設計するときはDFSSを使う」という文脈で、ほんの少しだけDFSSを紹介していますが、それくらいしか僕は知りません。そのため僕は英語の書籍からDFSSを学んでいます。
DFSSに限って言えば、DFSSプロジェクトの90%以上が新製品開発で、残り10%程度が新しい業務プロセスの設計にDFSSを僕は使っています。その立場でもし一冊だけDFSSの入門書を選ぶとすれば以下の本を推奨します。
Commercializing Great Products with Design for SIX SIGMA
(Randy C. Perry, David W. Bacon)
ISBN: 0-13-238599-6
入門書というよりも専門書に近いかもしれませんが、この一冊でDFSSのブラックベルトの範囲をカバーできます。DFSSのトレーニングやコンサルティングで有名なSBTI (Strategy Breakthrough Transformation Innovation）社のトレーニングでもこの本を推奨していると聞いています。
これからも宜しくお願いします。
入門書をご紹介いただき、ありがとうございました。
DFSSについてもっと知りたいので、これを機に英語の書籍で勉強する事にチャレンジします。専門書だけに一般的な書籍よりも高価ですが、昨日上司にお願いし購入する事にしました。頑張って読んでみたいと思います。
分からないことが沢山出てくると思いますが、また質問させて頂いてもよろしいでしょうか。
今後ともどうぞよろしくお願いいたします。
こちらの方こそ宜しくお願いします。どんな質問でも嬉しく思います。お待ちしています。