「なぜ」と一緒に「もし」を考える

なぜなぜ分析は何らかの事象に対して真因を探る際に用いる手法としてよく聞くと思います。そしてインターネットで検索するとなぜなぜ分析に関する情報ややり方の説明、その歴史などはたくさん出てくるので、読んだことがある方もたくさんいらっしゃると思います。

では、みなさんは実際にお仕事の中でなぜなぜ分析を使ったことはありますか？またはどのようにやるかと言われたらご自身は普段自分でやっているやり方を説明できますか？もしくはなぜなぜ分析を受けた時というのはどういう時でしょうか。

・仕事で「なぜ？」と聞かれると答えづらい

「なぜ？」と聞く時は基本的に原因や理由を知りたい時です。「なぜそれをしたの？」とか「なんでそこへ行ったの？」とかですね。

筆者自身、かつても今も、いろんな方とお仕事をご一緒させて頂く際によく「なぜ？」「どうして？」と質問することはよくあります。またされることもよくあります。

でもですね、普通に考えて仕事中に「なんでこんなことやってるの？」「どうしてこんなことになったの？」と聞かれて気分がいい人はいないと思うんです。仕事でわざわざ質問されるときというのは何か問題が起こった時です。しかもそれが実際にお仕事を頂いている顧客から「なんで？」「どうして？」と聞かれて怖くないわけがないですよね（笑）。

ただ業務上「なぜ？」と問われて答えづらいときにはただ嫌な気分だからとは言い切れない部分もあります。なぜなら、相手が抱えている案件は自社が発注したものだけではないからです。発注側と受注側で機密保持契約と取引基本契約書を取り交わしているとしたら、受注側は他社とも同じ関係を結んでいます。

しかし使う設備や場所は同じ場所だったりするわけです。もしかしたら「どうしてこんなことになったんですか？」と問い質されている仕事の前には別の顧客の案件の対応をしていたのかもしれません。そうであればそこに関連する話題の一部は言えないものかもしれません。

筆者の場合、もし自分が質問する側で、回答する側が答えに詰まるようなケースが起こったとしましょう。そういった場合には「なぜ？」と聞くのを一回止めます。その代わりに「もしかしてこういうことですか？」という一言を挟むのです。

・「もし」が意味するもの

なぜなぜ分析を実施する上でのポイントとして、「質問の回答が得られたらその前段階の疑問が解消すること」というのがあります。

この時、「もしかしてこういうことですか？」とか「もしかしたらこうじゃないんですか？」とか聞くというのは「質問する側としては回答の方向性をこういう風に予測しているよ」という表明になります。そうすると回答者はそれに対して同意する場合は「そうですね」と言いながら実際の状況の様子を教えてくれたりします。違う場合には「いえ、そうじゃないんです」と言いながらやっぱり実際の状況を教えてくれます。つまり「もしかして」という一言は回答を誘発（誘導じゃないんです）するための切り札になります。

この時の「もしかして」というときの注意点としては、自分からあまり話し過ぎないことです。例えば「もしかしてこういうことですか？そうじゃなければこんなことになるなんてありえないですよね？」などと言ってしまった日には「はい、その通りです。申し訳ありません。」で話が終わってしまいます。

たまにここで話過ぎてしまう人がいます。そうするとそれに対して Yes か No の答えしかなくなってしまって、回答者が実際とは違う答えをすることも可能になってしまうので、話過ぎは禁物です。あくまで目的は相手が置かれてる状況を理解し、事象の原因・真因が何なのかをつきとめることです。

・本当に求めるべきもの

なぜなぜ分析の目的として冒頭でも書いたように「事象の真因を求めること」と言われます。まず最初に起こった事象の真因という意味で何が起こったのかを知りたいのはそうだと思います。しかしそれは本当に求めるべきことでしょうか。また実際にその事象を起こした組織が求めたいのはそれでしょうか。

本当に求めたいのは開発する際に、または生産する工程を設計する際に同じようなミスを再発しないことではないのでしょうか？製品の不具合の再発は一回事故を起こせば修正を入れることは可能ですが、そこを次回以降の製品開発時も活用可能な情報にできたらその方が理想的です。

そのためにはその製品もしくはその工程を作っている際に何を考えてそうしたのか、その時に何が漏れていたのかを明らかにしておく必要があります。顧客に対する回答としてはその製品に関する原因究明でも十分かも知れませんが、実は組織内では次回以降の製品開発の効率が上がっていくことが理想ですから、製品開発の活動全体に対する改善活動になる場合が理想です。

すなわちなぜなぜ分析を通じて、実際に業務にあたる際に想定された判断ポイントの条件分岐を想像することが求められます。そのためにはなぜなぜ分析に入る前にすることがありますので、それについては別の記事でご説明します。

著者プロフィール

Takahiro Yoshida株式会社コルプ代表 / QA+編集長 Founder & CEO, QUALP Inc. / Editor-in-Chief, QA+

2008年より精密機器メーカにて民生機器の製品開発における品質保証業務に従事。機械部品を中心としたハードウェアの保証業務5年、機器に搭載するファームウェアの品質保証を4.5年経験。設計部門と連携した開発プロセスからの品質向上、量産を見越した品質構築を実現する。ハードウェア経験も活かしつつソフトウェアの品質向上を実現し、開発会社と連携した担当機種で不具合の低減を達成。
2018年に株式会社コルプを設立、代表取締役就任。写真・映像などのPRコンテンツの製作と品質保証を中心とした業務改善で中小企業を支援。潜在的不良リスクの低減から不測のコスト増に対応できる組織構造の構築にノウハウを持つ。YouTubeチャンネル運用支援では顧客が自立してチャンネルを運用できるよう育成まで行う。業務改善支援では中小企業の30代中堅社員の業務管理方法の改善指導をした上、業務標準化を進めるなど管理面に関する支援を行う。
「判断と構造で、未来に舵を切る人のためのメディア」QA+を立上げ、編集長として各種コンテンツの製作・ディレクションを行う。