【PdM】課題特定と改善について：フレームワーク

どの業界、企業、チーム、プロダクトにおいても問題はつきものだと思います。これらの問題をどうやって特定していくのか？特定した課題をどう解決するべきか？どうすれば同じような問題の再発を防げるのか？といった疑問に対して役に立つフレームワークを紹介する記事を書きたいと思います。

QCC

Quality Control Circle（QCC）とはざっくりいうと定期的に抱えている問題を洗い出す会を開催し、ディスカッションを行い、洗い出した課題とそれの解決策をまとめる取り組みです。1950年代に発案されたようで、現在も使用されています。

Quality

現状Quality（質）を向上しないといけない部分は何か？
ここでは事前に合意した項目別に質問を聞くと良いでしょう。例として職場環境の質、成果物・仕事の質、QOL（Quality of Life人生の質）などの三軸でまとめるなどがあります。

Control

洗い出した課題の原因は何で、どうに解決すればよいのか？
原因を明確にし、参加者全員で解決策を練ります。ここでの手法は自由ですが、例としてロジックツリーを使った仮設などが良いでしょう。

Circle

提案された解決策は効果があるのか？
考えだされた解決策を実際に現場で運用してみることで効果検証を行います。これで効果が実感できるようであれば、通常業務・プロセスの一部として取り込みプロセスの改善が見込めます。思い通りの結果にならなかった場合、再度QCCを通します。

Root Cause Analysis

Root Cause AnalysisとはQCCをより簡素化した考え方の一つともいえます。
いたってシンプルであり、目的は起きてしまった問題を今後二度と起こらないようにするという名目のもと、二つの質問を問います：
1．課題・問題は何か？
2．なぜその課題・問題が発生するのか？

しかし肝心なのは2の問に対して深堀をすることです。「お店の売り上げが少ないのは、お客さんが来ないからだ」という例でいうと、「ではなぜお客さんが来ないのか？」という風に問い続けることが重要です。客が来ないのは立地のせいかもしれませんし、もしくは一か月前に近隣にライバル店ができたかもしれません。ライバル店ができたとして、ではなぜ顧客はそちら店舗へ向かってしまうのか？内装や雰囲気だったり値段かもしれません。どんどん「なぜ」を繰り返すことで本質をとらえ、課題解決と再発防止に努めましょう。

CIRCLES Method

このフレームワークの根本は目的を明確にして、制約を特定し、現状をりかいすることを重要視しています。
そのうえでCIRCLEを作る7つ頭文字・ステップは以下の通りです：

1. Comprehend the situation： 問題が発生している状況・背景を理解する

2. Identify the customer：プロダクトが誰に向けたものか理解する

3. Report customer's needs：顧客リサーチに基づくペインポイント・課題を明らかにする

4. Cut, through prioritization：必要ないアイディア、タスク、解決策を排除する

5. List solutions：最も実現性の高い解決策のみをキープする

6. Evaluate tradeoffs：解決策が生むインパクト、遅延の影響、コストなど様々な観点からプロコンを精査する

7. Summarize your recommendation：決断し、理由を説明する

CIRCLESの各ステップを踏むことで柔軟に考えれるようにし、結論へ急がないようにするなどの効果が見込めます。

PDCA

PDCAは多くの人が知っている有名な目標達成プロセスだと思うので、詳細までは書きませんが、重要なの課題特定と解決のかなめにもなりうるということです。

Plan

計画を立てて、実行に必要な準備を行います。過去にあった失敗や新しい改善プロセス、仮説や目標設定などすべてを取りこみ、最善の計画をしっかりと組んでいきます。課題特定・解決という観点でいうと、この部分でブレストや先に考えることで、起こりうる課題への対応だったり、課題発生を未然に防ぐことができます。

Do

計画をもとに実行へ移します。

Check

計画をもとに実行したアクションに伴う結果を精査します。
ここで重要なのは「結果は想定通りか？」と「想定外だった場合、何が違ったのか？」。これらの質問をもとに結果を分析し、結果が思い通りにいかなかった時の要因分析を行います。結果としてここで新しい課題が特定できるかもしれません。ここではなるべく定性・定量的データの二つを集めて、後程検証できるようにしましょう。

Action

改善の部分になります。検証結果に基づき、解決策や改善案を練ります。Checkでの分析が重要となっており、前段の部分でつまずくとここでの改善は意味がなさないものになってしまうかもしれません。

Actionを終えた後は序盤のPlanへ戻り、改善を踏まえたうえで再度サイクルを回します。Agile開発のコンセプトに似ている部分がありますね。

まとめ

数あるフレームワークや手法の中からいくつか紹介しましたが、なんとなく「課題が存在・起きていて、それに対応する」Reactiveアプローチ（受動的な対応）を仮定している風に書いているかと思います（主観）。
一方で我々が目指すべき姿というのは「課題が発生する前に未然に防ぐ」というProactiveアプローチ（主体的な対応）パターンもカバーする必要があると思っており、課題の発生前と発生後への対策を網羅することで、課題特定と改善のプロセスを完璧にできると思っています。

ではどうすればよいのかというと、課題が起きる前に想像を膨らませて各フレームワークを使えるようになる必要があると思います。プロジェクトやプロダクト開発の初めはReactiveアプローチになりがちでも、回数を重ねるごとに「こうなるかもしれない」というアイディアのもと、Root Cause Analysisを事前に行ったりすることで、そもそも課題を発生させないということも実現可能となってきます。
決して簡単なことではないですが、ReactiveとProactiveアプローチをカバーできたContinuous Improvement（継続的な改善）という状態が目指すべき姿だと思っています。