シックスシグマProjectの「Define」でやること 1 「Problem Statement」の書き方

Photo by Kaleidico on Unsplash

皆さんこんにちは! 今日もどこかで改善サポート、Kusunoko-CIです。

以前、シックスシグマを使ったプロジェクトの進め方、「DMAIC」についてお話ししました。

PDCAや、トヨタの問題解決法「TBP」、あるいはFordで開発された「8D」などの手法とも、大きく変わらないのでしたね。

なぜならそれは、問題解決手法が、すべて「科学的」なものであるから。

そこで今回からしばらく、シックスシグマでプロジェクトを遂行する際の「ポイント」を順に追いかけてみたいと思います。

まずは「DMAIC」のD、Defineから「Problem Statement」の書き方です。

全てを読み通すと、あなたのシックスシグマプロジェクトも、基本にのっとった、「成果の望める」ものになるはずです!

Define:「Projectを定義する」

Photo by Dylan Gillis on Unsplash

まずはシックスシグマプロジェクトの、一番最初のステップ、「Define」。

ここでは基本的に、

  • Problem Statement(問題の記述)
  • Objective Statement(目標の記述)
  • Primary Metric、 Secondary Metric、 Consequential Metric(主要な計測基準と、可能であれば2次的なものと、そして主要計測基準を別の側面から補完することのできる基準=Consequential Metricがあるとなお良い)
  • Financial Estimates(予測されるコスト削減額)
  • Team Members(問題解決に必要なチームメンバー)
  • Macro Map(ざっくりとしたプロセスマップ)

というものがそれぞれきちんと定義され、記述されることが望まれます。

今回はこの「Problem Statement(問題の記述)」に、焦点を当ててみます。

Problem Statement

Photo by Dylan Gillis on Unsplash

この「Problem Statement」、直訳すると「問題の記述」日本になりますが、私は「取り組むべき課題」というのが一番しっくり来るかなと思っています。

「取り組むべき課題」を、はっきりさせることのメリットは、

  • 抱えている「問題」が、何なのかはっきりする
  • 抱えている「問題」が、他の人たちに伝わりやすくなる
  • 焦点がはっきりし、チームやステークホルダーとの合意が得やすくなる
  • 誤解を避けるのに役立つ

などがあげられます。

よくあるのが、Projectをなんとなく始めてしまって、あとでチーム内で齟齬が生じるとうやつですね。

そういうのは、皆さんの貴重な時間がもったいないので、ちょっとめんどくさく感じても、課題をはっきりさせる手間を、なるべく惜しまないようにしましょう。

ちなみにこの「取り組むべき課題」を記述する段階では、「解決策」や「原因」は考えないこと。

それらは、後でまた時間をかけて、丁寧に探すことになりますので、今は飛びつきたくなっても、ぐっと我慢してください。

くれぐれも、「解決策」ありきでProjectを始めないことです。

以下が、すべてを抜け・漏れなくカバーした「取り組むべき課題」を書くためのフレームワークです。

「抜け・漏れ」のない思考というのは、とても重要でしたね。

取り組むべき課題文・例題

Photo by Max Rovensky on Unsplash

ではここで、例文を一つ作ってみましょう。

例えば今、あなたは愛車を売ろうと考えています。

なるべく高く売りたいですよね。

しかしながら、エンジンに若干の不具合(異音)が発生していて、愛車の査定価格に響いてしまいそうです。

出来れば何とかしたい、という状況を思い浮かべてください。

問題解決のための「Problem Statement・取り組むべき課題」は、以下のようになるでしょう。

愛車のエンジン不具合(異音)は、20xx年の12月頃から、中距離ドライブ(50㎞程度)を走行する際に起きている。発生頻度は3回のドライブにつき、1回程度。

異音が発生すれば当然不快であるし、運転に対する不安も生じる。安全な場所に車を停車して、様子を見ることも必要になっているし、目的地への到着時間を、正確に予測できない場合がある。

中古車下取りセンターに相談したところ、最大で約30万円ほど査定額に影響(減少)が出るとの回答を得た。

このステートメントは、問題のみに焦点が当たっていて、次の要素がすべて含まれていますね。

  • 問題は何ですか?:エンジン不具合(異音)
  • どこで発生しますか? :中距離ドライブ(50㎞程度)
  • いつ始まりましたか? :20xx年の12月頃から
  • どのくらいの頻度で発生しますか?:3回の中距離ドライブにつき、1回程度
  • その問題がもたらすものは?:異音による不快感と不安感、様子見のための停車や到着時間への悪影響。また売却額が、最大で30万円ほど下がってしまいそうだ。

ここまで明確になっていれば、ご家族の方との話し合いや、また車修理(するのであれば)の際にも、状況や問題を素早く理解してもらうことができるはずです。

これも問題の「見える化」ですね。

まとめ

Photo by AbsolutVision on Unsplash

いかがでしたでしょうか。今回は「DMAIC」のD、Defineから「Problem Statement」の書き方のご説明でした。

ちなみに、冒頭で説明した、

  • Problem Statement(問題の記述)
  • Objective Statement(目標の記述)
  • Primary Metric、 Secondary Metric、 Consequential Metric(主要な計測基準と、可能であれば2次的なものと、主要計測基準を別の側面から保管することのできる計測基準=Consequential Metric)
  • Financial Estimates(予測されるコスト削減額)
  • Team Members(問題解決に必要なチームメンバー)
  • Macro Map(ざっくりとしたプロセスマップ)

という6点が、きっちりまとまると、立派な「Project charter」の出来上がりです。

現状把握や、計測基準、あるいはターゲットというものは、いずれもProjectを始める前に、必ず明確にしておかなくてはいけないものばかりですので、少し時間がかかっても、しっかり作成するようにしてください。

成功に響いてきますよ。

次回は、「Objective Statement」(目標の記述)以降に、焦点を当てていこうと思います。

今日も読んでいただきまして、ありがとうございました!

ではまた!

Follow me!

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

CAPTCHA