CTQツリーとは：クリティカル・トゥ・クオリティの定義方法
Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
CTQツリーは、Six Sigmaの中でも最も実践的なツールの1つです。「信頼できる製品が欲しい」といった漠然とした顧客ニーズを取り上げ、エンジニアやプロセスチームが実際に取り組める具体的で測定可能な要件へと分解します。この変換プロセスがなければ、チームは聞こえは良いものの顧客が本当に重視していることとはかけ離れた指標を最適化することになりかねません。
正式名称はcritical to quality（CTQ）ツリーで、通常はDMAICのDefineフェーズで最初に使われるツールの1つです。生の顧客の声とプロジェクトの目標指標との間をつなぐ役割を果たします。
CTQツリーとは何か
CTQツリー（critical to quality tree）とは、顧客ニーズをドライバーというカテゴリーに分解し、さらに目標値が定義された具体的で測定可能な品質特性へと落とし込む、構造化された図です。 左から右へ展開する形式で、1つのニーズに対して2〜4個のドライバー、各ドライバーに対して2〜4個の測定可能なCTQが定義されます。
このツールの目的は精度です。「顧客は迅速な配送を求めている」はニーズです。方向性は示しますが、目的地までは示しません。CTQツリーは、顧客にとって「迅速」とは実際に何を意味するのか（注文から出荷までの時間なのか、ドアツードアの輸送時間なのか、リアルタイムの追跡可視性なのか）を問い、そのニーズを満たす測定可能な仕様を定義することを強制します。
CTQツリーはVoice of the Customer（VoC）調査に由来します。VoCは生の顧客の言葉を捉えます。CTQツリーはその言葉をエンジニアリングおよび業務上の用語に変換します。そこから、それらのCTQはDMAICやDMADVプロジェクトの土台となるY（従属変数）になります。
重要なポイント
- 品質指標を顧客要件に直接結び付けている企業は、社内基準のみの仕様を使う企業と比較して、不良コストを20〜30%削減しています（American Society for Quality、2023年State of Qualityレポート）。
- 品質不良は、品質システムの成熟度に応じて、米国製造業の総売上の概ね5〜30%のコストとなっています（ASQ Quality Cost Survey）。
- 検証済みのCTQツリーから始まったSix Sigmaプロジェクトは、測定システムが最初から正しくスコープされているため、平均でImproveフェーズに40%早く到達しています（iSixSigma業界ベンチマーク）。
CTQツリーの3つのレベル
すべてのCTQツリーは正確に3つのレベルで構成されます。各レベルはそれぞれ異なる問いに答えます。
| レベル | 名称 | 答える問い | 例 |
|---|---|---|---|
| レベル1 | ニーズ | 顧客が最終的に求めているものは何か | 迅速な配送 |
| レベル2 | ドライバー | そのニーズが満たされるかどうかを左右する要因は何か | 注文処理速度、配送業者の輸送時間、追跡の透明性 |
| レベル3 | CTQ（クリティカル・トゥ・クオリティ） | ドライバーが満たされていることを証明する具体的で測定可能な特性は何か | 注文確定から24時間以内に発送、標準注文の輸送時間3日未満、4時間ごとのリアルタイム追跡更新 |
レベル3のCTQは必ず目標値と仕様限界を持たなければなりません。「3日未満」はCTQです。「迅速」はCTQではありません。合否判定テストを書けないのであれば、まだレベル3には到達していません。
CTQツリーと他の品質ツールとの違い
CTQツリーは単独では機能せず、一連のツールチェーンの一部として機能します。他のツールとの位置関係を理解することで、どのツールをいつ使うべきかの混乱を防げます。
**Voice of the Customer（VoC）**は、アンケート、インタビュー、サポートチケット、NPSコメントなどを通じて顧客が自分の言葉で語ることを捉えます。定性的で、しばしば曖昧です。VoC調査では「注文プロセスがわかりにくい」といった声が出てくることがありますが、これはニーズではあっても測定可能な仕様ではありません。
CTQツリーはVoCのすぐ下流に位置します。その生の顧客の言葉を取り上げ、3段階の階層に構造化します。ツリーのアウトプットは、目標値が付いた測定可能なCTQのリストです。これらのCTQは、次に測定計画に反映されます。
KPIは、事業が継続的に追跡する業務指標です。顧客のCTQに対応する場合もあれば、しない場合もあります。ツリーはその対応関係を確認する手段です。あるKPIがCTQツリーのドライバーやニーズに遡れないのであれば、それは顧客が気にしていない社内的な何かを追跡している可能性があります。
Quality Function Deployment（QFD）（House of Quality）は、CTQを設計やプロセスのパラメータにマッピングします。CTQツリーが先で、QFDはそのアウトプットを使って行う作業です。
DMAICプロジェクトでは、ツリーはDefineフェーズに位置し、VoCがツリーに情報を供給し、ツリーがMeasureフェーズの測定システムに情報を供給します。
よくある間違い
レベル2で止まってしまう。 チームはしばしばドライバーを定義しただけでそれをCTQと呼んでしまいます。「注文処理速度」はドライバーであり、CTQではありません。もう一段階踏み込んで、数値目標を割り当てる必要があります。
測定できないCTQを作ってしまう。 チームにそのCTQに対するデータを取得できる仕組みがなければ、それはまだ機能するCTQではありません。測定のギャップを埋めるか、仕様を見直してください。
社内のプロセス目標と顧客のCTQを混同してしまう。 「倉庫でのピッキング時間を15%短縮する」は社内の業務目標です。あるドライバーを支える場合もありますが、顧客がピッキング時間そのものを気にしているのでない限り、それはCTQではありません。CTQはプロセスオーナーの視点ではなく、顧客の視点に立つものです。
CTQが多すぎる。 1つのニーズは現実的には6〜10個のCTQで支えられます。1つのニーズに対して30個のCTQを生成するチームは、通常ニーズを混同しており、プロジェクトのスコープが肥大化します。ツリーは引き締めておきましょう。1つのよく練られたCTQは、重複する5つのCTQよりも価値があります。
検証を省略してしまう。 実際の顧客データと照合せずに会議室で作られたCTQツリーは、あくまで仮説にすぎません。確定させる前に、必ずドライバーとCTQを実際のVoC入力と照合して検証してください。
CTQツリーの作り方
顧客の根拠を集め、1つの成果ニーズを定め、ドライバーを特定し、測定可能なCTQを定義し、すべての目標値を検証します。
ステップ1：Voice of the Customerデータを収集する
何かを描く前に、まず生の顧客の声を集めます。インタビュー、アンケート、クレームログ、NPSの自由回答、営業通話の録音などです。パターンを見出すには、少なくとも20〜30件の異なる顧客の発言が必要です。似た発言をテーマごとにグループ化します。
ステップ2：顧客ニーズを特定する
VoCのテーマから、平易な顧客の言葉で1つのニーズ文を書きます。アウトカムレベルにとどめてください。「注文を早く、無事な状態で受け取りたい」は良いニーズ文です。「オンタイム配送率98%を達成する」は既に解決策を先取りしてしまっています。
1つのニーズにつき1つのCTQツリーです。3つの異なるニーズがあれば、3つのツリーを作成してください。組み合わせてはいけません。
ステップ3：ドライバーをブレインストーミングする
問いを立てます。「どの要因がうまく機能すれば、このニーズは満たされるか」。ドライバーはパフォーマンスのカテゴリーであり、まだ測定値ではありません。「注文を早く、無事な状態で受け取りたい」であれば、ドライバーは注文処理速度、配送業者のパフォーマンス、梱包の完全性、追跡の可視性などになるでしょう。
1つのニーズにつき2〜5個のドライバーを目指します。それより少なければ何かを見落としている可能性が高く、5個を超えるようであれば、一部のドライバーが実はCTQである可能性があります。
ステップ4：目標値を持つ測定可能なCTQを定義する
各ドライバーについて、2〜4個のCTQを定義します。各CTQには次が必要です。
- 明確で測定可能な特性（例：「輸送時間（営業日）」）
- 目標値（例：「3日」）
- 仕様限界（例：「99%の注文で5日以内」）
このタイミングで、プロセスのSIPOC図を確認してください。プロセスのどのアウトプットが実際に各CTQに対応するかを確認でき、どこでデータを収集すべきかがわかります。
ステップ5：顧客と検証する
CTQの草案を顧客サンプルに持ち帰ります。「この目標を一貫して達成できれば、あなたのニーズは満たされますか」と尋ねます。相手が肩をすくめるようなら、そのCTQは間違っています。「はい、ただし」という条件付きの回答であれば、新たなドライバーやより厳しい仕様が必要ということです。
このステップは、最もよくあるプロジェクトの失敗を防ぎます。それは、顧客が実際には気にしていない指標の最適化に何週間も費やしてしまうことです。
ステップ6：優先順位を付けてプロジェクトのスコープを決める
すべてのCTQがプロジェクトの焦点になるわけではありません。顧客満足度への影響と、現在のパフォーマンスと目標のギャップに基づいてCTQをランク付けします。ギャップが最も大きく、顧客への影響が最も高いCTQから着手します。DPMOとシグマレベルの計算を使って、各CTQ仕様に対する現在の不良率を定量化してください。
CTQツリーの実例
この実例は、「配送が予測不能で遅い」という顧客フィードバックに対応するオンライン食品配送会社のケースです。
| レベル | 項目 | 目標値／仕様 |
|---|---|---|
| ニーズ | 予測可能で迅速な配送 | |
| ドライバー1 | 注文準備速度 | |
| CTQ 1.1 | 注文確定からレストランでのピックアップ準備完了までの時間 | 95%の注文で15分未満 |
| CTQ 1.2 | ピックアップ時の注文正確率（品目の正しさ） | 99.5%以上 |
| ドライバー2 | 配達員の輸送パフォーマンス | |
| CTQ 2.1 | 標準注文のドアツードア配送時間 | 90%の注文で35分未満 |
| CTQ 2.2 | 提示ETAに対するオンタイム配送率 | 85%の注文でETAの5分以内 |
| ドライバー3 | 追跡の可視性 | |
| CTQ 3.1 | 配送中のステータス更新頻度 | 少なくとも3分ごと |
| CTQ 3.2 | 配達員が2分圏内に入った際の通知 | 全注文の100% |
プロジェクトチームはその後、各CTQ仕様に対する現在のパフォーマンスを評価し、どの項目がどの程度、プロセスのどの部分で未達なのかを判断します。それが直接DMAICのMeasureフェーズにつながり、そこで各CTQのプロセス能力（Cpk）が計算されます。
ベストプラクティス
ニーズ文は顧客の言葉のままにしておく。 ビジネス用語にきれいに整えたい誘惑に負けないでください。「迅速で予測可能な配送」の方が「注文からドアまでのサイクルタイムを最小化する」よりも顧客に近い表現です。
ツリーに日付を入れる。 顧客の期待は変化します。2022年のEコマース向けに構築されたCTQツリーは、2026年の基準では目標が緩すぎる可能性があります。CTQは毎年、あるいはVoCデータが満足度ドライバーの変化を示すたびに見直してください。
各CTQをプロセスのアウトプットに紐付ける。 CTQのアウトプットを生み出すプロセス上のステップを特定できなければ、測定はできません。SIPOC図を併用資料として使うと、この作業が速く進みます。
測定計画を省略しない。 データ収集計画のないCTQは、願望に過ぎません。ツリーを確定する前に、データソース、測定頻度、担当者がすべて割り当てられていることを確認してください。
ステップ3にプロセスチームを巻き込む。 プロジェクトリーダーだけでブレインストーミングされたドライバーは、現場スタッフが知っている業務上の実情を見落としがちです。混成セッションの方が、より良いドライバーセットが生まれます。
顧客ニーズを測定可能な仕様に変換することは、あらゆる品質改善プロジェクトの土台です。その変換がなければ、チームは間違ったものを改善してしまいます。CTQツリーがあれば、すべてのプロジェクト指標が、実在する顧客が実際に気にしていると語った何かに結び付きます。それこそが、満足度スコアを動かすプロセス改善と、単に数字だけを動かすプロセス改善とを分ける違いです。
関連記事
