どれかひとつでも心当たりがあれば、この記事は役に立つと思います。

先に結論です。測るものには、2種類あります。

前者を管理項目、後者を点検項目といいます。どちらも、日本の品質管理の規格に定義がある言葉です。

この記事は、その規格の考え方をもとに、どんな仕事に、どんなものさしが向いているかを整理したものです。私自身が測れずに詰まった話も、正直に書きます。

この連載が扱う範囲

業務改善を任された人が、どんな基準で測り、どんな成果を見せるかという話です。引き継ぎや、特定の人しかできない業務をどうほどくかという話は、別の連載にします。

全3回の予定です。今回は1回目、「測るものは2種類ある」の話です。

「一般的な基準に合わせよう」の、その次で止まる

改善の話になると、必ず「効果測定をしましょう」「KPIを決めましょう」という話が出ます。

そして、たいてい止まります。理由は、基準が共通の認識になっていないからだと思っています。

数字そのものは、決めれば決まります。問題はその先です。「その数字で本当に測れているのか」について、関わる人の理解がそろっていない。だから、決めた本人以外は見なくなります。

声の大きい人の基準が通る、という話もよく聞きます。それは実際そのとおりで、だからこそ、その人たちと認識を合わせる作業が要ります。合わせないまま決めた基準は、決まっているようで決まっていません。

「一般的な評価基準に合わせればいい」。ここまでは、たいていの人が思いつきます。

ですが、実際に自分の業務に当てはめようとするところで、うまくいかない。規格を見にいっても、書いてあることは正しいのに、自分の仕事に重ならない。

この記事は、そこで止まった人に向けて書いています。私自身が、そこで止まった一人です。

正直に書くと、最初は時間しか測っていませんでした

ある委託先の定型業務を、自動化したことがあります。マニュアルどおりに進める作業でした。

改善後、1件あたりの処理時間は短くなりました。時間は測れば出ます。ここは分かりやすい。

ただ、当時の私が測っていたのは、時間だけでした。

品質がどうなったかは、測っていません。現場の方に話を聞いて、体感的な感想をもらいながら進めていました。「やりやすくなった」「前より楽になった」。その手応えを頼りに、次の手を決めていたわけです。

感想を聞くこと自体は、悪いことではありません。むしろ必要です。ただ、それは報告に使える形になっていませんでした。

品質を上げるために、ダブルチェックも入れました。マニュアルに沿って、「こことここを見てOKかどうかを判断する」「表計算の数式が正しいかを確認する」といった観点で見るものです。対応としては、間違っていなかったと思います。

ただ、それだけでは改善を測ったことになりません。

チェックの観点は決まっていました。それでも、そのチェックで何件見つかったのかを、改善の指標としては見ていませんでした。 外から見れば、確認の工数が増えただけにも映ります。

正しいことをやったはずなのに、成果として示せない。この居心地の悪さが、この記事を書いているきっかけです。

足りなかったのは、ひとつでした。結果として見るものと、原因として見張るものを、分けていなかったことです。

測るものは、2種類ある

先に、身近な例で入ります。

請求書の発行を改善したとします。 見たいのは「発行が遅れた件数」や「金額の誤り」。これが結果です。一方で、それを左右するのは「請求のもとになるデータが揃っているか」「テンプレートが最新か」。こちらが原因です。

問い合わせ対応ならどうでしょう。結果は「返事までの時間」「同じ質問が繰り返し来た回数」。原因は「よくある質問がまとまっているか」「そもそも聞かれやすい書き方になっていないか」。

この、結果と原因を分けて置くこと。 それだけの話です。ただ、名前がついていると扱いやすくなります。

結果を見るもの=管理項目

管理項目
目標の達成状況を監視し,必要な処置をとるために選定した評価尺度
——JSQC-Std 00-001:2023『品質管理用語』13.3

目標に対していまどうなっているかを見て、外れていたら手を打つためのものさし、ということです。

期限内に終わった割合。ミスの件数。1件あたりの処理時間。どれも管理項目になります。

ひとつだけ、置くときの条件があります。期の途中で見られること。 終わってからしか分からないものは、手の打ちようがありません。

売上を管理項目にしてはいけない、という意味ではありません。売上は、小さな会社にとって最も身近な数字です。問題は売上だけを見ることです。

原因を見るもの=点検項目

点検項目
工程異常の発生を防ぐ,又は工程異常が発生した場合に容易に原因が追究できるようにするために,プロセスの結果に与える影響が大きく,直接制御が可能な原因系の中から,定常的に監視する特性・状態として選定した項目.
——JSQC-Std 00-001:2023『品質管理用語』13.5

長いので、条件に分解します。点検項目に選んでいいのは、次の4つを満たすものです。

  1. 原因の側であること(結果ではない)
  2. 結果への影響が大きいこと
  3. 自分たちで直接動かせること
  4. ふだんから見られること

品質管理では、この2つを「管理点」と「点検点」と呼んで分けます。品質管理検定(QC検定)の出題範囲にも「管理項目(管理点と点検点)」として入っています。

実務でいちばん効くのは、3番です。

「売上が落ちたのは景気のせい」。これは原因かもしれませんが、点検項目にはなりません。動かせないものを見張っても、打ち手が出ないからです。

線引きは、思ったより細かくなります。たとえば「依頼内容の不備率」。依頼を出しているのが他部署や取引先なら、その入力の質は直接動かせません。動かせるのは、こちら側です。依頼フォームの必須項目を変える。テンプレートを配る。そこまで手が届くなら、点検項目になります。

点検項目を選ぶときの問いは、ひとつだけです。「それ、自分たちで変えられますか?」

現場に行って、見る場所が変わった話

これを実感した場面があります。

ある委託先の現場で、入力作業の改善に関わったことがありました。

最初に目についたのは、人によって入力の速さや正確さが違うことです。ITの仕事をしていると、見落としがちな点でした。パソコン操作はできて当たり前だと、どこかで思っていました。

現場では、誰もがPC操作に慣れているとは限りません。そこを「慣れてください」で終わらせても、改善としては弱いと思いました。

そこで見直したのは、人の能力ではありません。入力の方法そのものです。

手で打つ箇所を減らし、バーコードなどで読み取れる形にしました。現場に行って作業を見て、働いている方の意見を聞いたうえで、これなら筋が通ると判断して入れたものです。

現場の声で、原因の見方が変わりました

導入後にあらためて話を聞くと、「やりやすくなった」という声をもらいました。

そのなかに、思っていなかった話がありました。

「読み方が分からない漢字を打つのが、いちばん困っていた」

その業務では、人の名前を入力する場面がありました。名前は、読みが分からないことがあります。読めなければ、漢字変換で出せません。手が止まります。

これは、パソコンの習熟度の問題ではありませんでした。

読み方の分からない文字を、読みで打たせる。その業務の作りが原因でした。慣れている人でも止まります。

つまり、私が最初に「人によって差がある」と見ていたものは、原因の見立てとしてずれていたわけです。現場で聞かなければ、たぶん気づいていません。

具体的な数値は、社外に出せないため書きません。数字を出せない以上、成果を大きく見せる書き方もしません。

ただ、見るべき原因は、はっきり変わりました。

「入力が苦手な人がいる」ではなく、「読めない字を、読みで打たせている」。ここに変わりました。

点検項目にするなら、どれか

当てはめると、こうなります。

候補 点検項目にできるか
PC操作のスキル ✗ すぐには動かせない。人を責める形にもなる
手入力が残っている箇所の数 自分たちで変えられる。影響も大きい
読みが要る項目の数 ○ 変えられる。原因に直結している

スキル差を責めるのではなく、スキル差があっても間違いにくい形に変える。 自分たちで変えられる原因はどこかを見ると、打ち手が変わります。

いま同じ業務を担当するなら、私はここを定点で見ます

当時は、そこまで整理できていませんでした。いま同じ業務を任されたら、こう置きます。

置くもの
管理項目(結果) 後工程での差し戻し件数、1件あたりの入力時間
点検項目(動かせる原因) 手入力が残っている項目の数、読みが要る項目の数
管理水準(異常の線) 手入力の項目が◯個を超えたら見直す

点検項目の「手入力が残っている項目の数」が、この業務の要だと思います。

これは月に一度、画面を見れば数えられます。減っていれば、間違いにくい形に近づいている。打ち手にも、そのままつながります。

冒頭の「測れなかった話」を、分けてみる

最初に書いた、ダブルチェックの話に戻ります。あのとき何が起きていたのかを、2種類に分けるとこうなります。

見たかったもの どちらか ひとこと
後工程まで流れてしまった誤りの件数 管理項目 本当に見たかった結果はこれ
チェックで見つかった件数 管理項目(ただし単独では見ない) チェックを強めた直後は増えます。上の行とセットで
ダブルチェックを実施したか 点検項目になるはずだった 記録していませんでした
チェックの観点が書かれているか 点検項目になる ここは満たしていました
チェックする人の能力 点検項目にしにくい 直接は動かせない
間違いが起きやすい画面や手順 点検項目になる 変えられるなら、これが強い

ダブルチェックは対策であって、改善が測れた証拠ではありません。

いま振り返ると、痛いのは3行目です。

ダブルチェックは「やることになっている」前提でした。 だから、実施したかどうかを記録していません。もちろん、そこで何件見つかったかも数えていません。

点検項目の4つ目の条件を思い出してください。「ふだんから見られること」でした。

記録がなければ、見られません。つまりあのダブルチェックは、点検項目の条件を満たしていなかったわけです。動かせるし、影響も大きい。惜しいところまで来ていて、記録だけがありませんでした。

「工数が増えただけ」に見えたのは、打ち手だけ入れて、測る側を置かなかったからです。

当時の記録と、いま足すもの

数字は出せませんが、何をどう記録していたかなら書けます。

工程 測っていたもの 当時の記録 いまなら足す記録
入力 所要時間 あり(動画で計測) 手入力が残っている項目の数、読みが要る項目の数
確認(ダブルチェック) なし(実施が前提だったため) 実施したかどうか、そこで見つかった件数、後工程へ流れた件数

この表が、当時の私に足りなかったものの全部です。

左半分は埋まっていて、右半分が空でした。 時間は測れる。だから測っていた。測りにくいものは、そのまま置いていました。

定型業務は、動画で測れることがあります

では、管理項目の側はどう測るか。定型業務なら、有効な方法があります。

作業を撮って、長さを測ることです。

冒頭の委託先の業務も、この方法で測りました。ポイントは、1件まるごとではなく、1工程ごとに区切って測ったことです。

まるごと測ると、「速くなった」しか分かりません。工程で区切ると、どこが長いのかが分かります。改善する場所を選べるのは、こちらです。

ただし、どの業務でも撮れるわけではありません。個人情報や機密が映り込む場面、取引先との関係で撮影が難しい場面もあります。撮れないなら、次回書く抜き取りの方法に切り替えてください。

測らせてもらうときの伝え方

現場で測るときは、何のために測るのかを先に伝えてください。

私の場合は、委託している業務でしたので、こう伝えていました。コスト削減を検討しているので、現場を深く分析していきたい。そのために協力をお願いしたい。

目的が会社としての方針であることも、あわせて説明しています。長い取引のなかで、必要なこととして理解してもらえていました。

ここを飛ばすと、測定そのものが警戒されます。 評価のために測っているのではない、と最初に伝わっているかどうかで、そのあとの協力の得やすさが変わります。

なお、取引先に協力を求める場面では、取引上の立場に配慮が要ります。依頼の仕方によっては、単なるお願いで済まないこともあります。気になる場合は、専門家に確認してください。

そして、時間が測れても、品質が測れたことにはなりません。冒頭で詰まったのは、まさにそこでした。時間は管理項目のひとつにすぎません。

数字にできない業務は、どうするか

「うちの業務は数字にできないから、効果なんて測れません」。よく聞く言葉です。

これにも、規格に答えがあります。

代用特性
要求される品質特性を直接測定することが困難な場合,同等又は近似の評価として用いる他の品質特性
——JSQC-Std 00-001:2023『品質管理用語』3.9

直接測れないときは、近いもので代わりに測っていい。 これが用語として定義されています。

本当に見たいもの 代わりに測れるもの
業務の分かりやすさ 質問された回数
手順の整い方 差し戻しの回数
判断が言葉になっているか 判断基準の文書があるか(あり/なし)
仕組みが定着したか 新しい手順で処理された件数の割合

注意がひとつあります。代わりだと明記してください。

質問された回数が減っても、分かりやすくなったとは限りません。単に聞きにくくなっただけかもしれません。代用は代用です。黙っていると、数字がひとり歩きします。

業務のタイプ別に、何を置くか

まずAとCだけ見てください。 多くの業務は、このどちらかに近いはずです。残りは、当てはまるものがあれば読む、で十分です。

どんな業務か 管理項目 点検項目
A 繰り返しが多い定型業務
(請求書発行、データ入力)
同じことを何度もやる 1件あたりの処理時間、ミス件数 手入力が残っている箇所、テンプレートの更新日
C 判断が中心
(発注量、優先順位、受注可否)
「どれを選ぶか」が課題 判断のやり直し回数、判断が止まった回数 判断基準が文章になっているか
B 件数は少ないが1件が重い
(見積、契約、採用)
数が少なく1件が大きい 期限内の提出率、差し戻し回数 依頼フォームの必須項目、確認の手順
D 突発対応が多い
(クレーム、問い合わせ)
割り込みが読めない 初動までの時間、再発件数 よくある質問の整備状況と更新日
E 成果が出るまで時間がかかる
(教育、営業)
結果が遅れて出る 期中は実施回数・到達段階 計画に対する実施率
F 品質が主観的
(資料作成、接客)
良し悪しが人による 修正回数、段階評価 チェックリストの実施率

厳密な分類ではありません。 実際の業務は、いくつかにまたがります。

Dで、間違えてはいけないこと

突発対応では、「件数をゼロにする」を目標にしない方がいい場面があります。問い合わせをゼロにしようとすると、報告されなくなるからです。数字は良くなり、実態は悪くなります。

ただし、ここは分けてください

ゼロを目標にしない 問い合わせ件数、相談件数、想定内の例外
ゼロを目標にする 重大な事故、誤送信、個人情報の漏えい、二重請求

起きて当たり前のことと、起こしてはいけないことは別です。

「どこからが異常か」の線を引く

測るものを決めたら、次は線です。

管理水準
安定した又は計画通りの,プロセスの状態を表す値又は範囲
——JSQC-Std 00-001:2023『品質管理用語』13.4

つまり、「ここを超えたら見直す」という線のことです。

注目してほしいのは「値又は範囲」です。ぴったりの目標値である必要はありません。

上限だけ決める(◯時間を超えたら異常)。下限だけ決める(◯%を下回ったら異常)。範囲で決める(◯〜◯なら正常)。どれでもかまいません。

そして、一度決めた線は変えていい。これは規格がはっきり書いています。

管理水準は……(実施計画の進行に応じて段階的に変わっていかなければならない).
——JSQC-Std 33-001:2016『方針管理の指針』

実態と合わない線を守り続けると、誰も見なくなります。

なお、規格でいう「異常」とは、プロセスが管理状態にないことです。不良品が出たこととは別です。管理水準を外れた状態が、異常。 早めに気づくために引く線だと考えてください。

成果は、どう見せるか

改善を任された人にとって、ここが最後の関門だと思います。

規格には、成果を見せるための道具についても書かれています。「管理帳票」と呼ばれています。

……これらの水準や実際の値,及び水準が未達成の場合の原因や処置を書き込み,関連者が進捗の状況をすぐに把握できるようにしたグラフ・表
——JSQC-Std 33-001:2016『方針管理の指針』

つまり、数字・原因・打った手を、一枚で見られるようにした表です。

ここに、成果報告に必要なものが全部入っています

  1. 決めた線(水準)
  2. 実際の値
  3. 線を外れたときの原因
  4. 打った手

多くの報告は、2番だけを出します。だから「で、どうなの」と聞かれます。

4つをそろえると、報告は「数字の報告」から「判断の報告」に変わります。 効果が出ていない場合でも、原因と打った手が書いてあれば、報告として成立します。

効果なし、悪化。どちらも結果です。 効果が出たかどうかと、測定が成功したかどうかは別の話です。

ひとつだけ、扱いを分けてほしいものがあります。「判定できなかった」場合です。これは結果ではなく、測り方の見直しが要るサインのことがあります。期間が短すぎた、件数が少なすぎた、途中で前提が変わった。隠さず報告したうえで、次はどう測るかまで書いてください。

決めた基準を、社内でどう握るか

基準は、決めるより握る方が大変です。

これについても、規格に手順が書かれています。「すり合わせ」と呼ばれています。

上位の管理者と下位の管理者(複数)が集まってすり合わせを行い……下位の管理者は自分が担当する部門の状況を踏まえて提案を行い,上位方針に対する追加・修正を行う
——JSQC-Std 33-001:2016『方針管理の指針』

つまり、上が方針を出し、現場がそれを直す場が、手順として用意されているということです。

下から修正提案を出すことが、手順に含まれています。

つまり、担当者が「その基準では、うちの業務は測れません」と言うのは、抵抗ではありません。手順の一部です。

進め方は、3つだけです。

  1. 基準を決める場に、その業務を実際にやっている人を入れる
  2. 上は「何を達成したいか」を説明し、現場は「その数字で本当に測れるか」を返す
  3. 決めた基準は書き出して、誰でも見られる場所に置く

ひとりでやっていて相手がいないなら、過去の自分と握ります。決めた日付と、決めた理由を書いておく。次に開いたときの自分が、すり合わせの相手です。

よくある失敗

失敗 何が起きるか
改善前を測っていない 比べる相手がなく、効果を示せません
時間だけを測る 品質が変わったかどうかが、最後まで分かりません(私の失敗です)
対策を「やる前提」にして、実施を記録しない 効いたか確かめられません(私の失敗です)
対策だけ入れて、測る側を置かない 工数が増えただけに見えます
平均だけ見る 「月末だけ地獄」「あの人だけ地獄」が消えます
点検項目を増やしすぎる 改善ではなく記録作業が増えます
件数を減らすことが目的になる 記録されなくなり、数字だけが良くなります

最初は、管理項目をひとつ、点検項目をひとつで十分です。 一覧表を作ることが目的になった時点で、だいたい続きません。

書き写せる表

紙でもスプレッドシートでもかまいません。この4列だけ作ってください。

業務 管理項目(結果) 管理水準(異常の線) 点検項目(動かせる原因)
(例)データ入力 後工程での差し戻し件数 月◯件を超えたら見直す 手入力が残っている項目の数

1行埋まれば、それで始められます。

印刷して書き込める版を置いています

この4列に加えて、業務タイプ別の早見表、限度見本シート、成果報告シートまでまとめたA4・9ページのワークブックを用意しました。無料です。登録も要りません。

👉 業務改善の効果測定 スターターキット(PDF)

印刷して、まずひとつの業務で埋めてみてください。

FAQ

Q. ISOの認証を取らないと使えませんか?
A. いいえ。ここで紹介した考え方は、認証のための規格ではなく「指針」に書かれているものです。この記事で紹介した無料公開の資料を読む範囲なら、費用はかかりません。

Q. 製造業の話ではありませんか?
A. 用語は製造業を背景に整理されてきました。ただ、元になっている『日常管理の指針』は2025年の改正で、飲食店の接遇業務などサービス業の例が追加され、DXやAIの活用にも触れています。

Q. 数字にできない業務は、どうすればいいですか?
A. 「代用特性」で近いものを測ります。直接測れないときに、近い別のもので測る考え方で、規格に定義があります。

Q. 管理項目と点検項目、どちらから決めますか?
A. 管理項目からです。「何がどうなってほしいか」が先で、「そのために何を動かすか」が後です。

おわりに

基準を決めるのは、評価されるためではありません。次に判断するときに、迷わないためです。

私は最初、時間しか測っていませんでした。品質は、現場の感想を頼りに進めていました。悪いことをしたつもりはありません。ただ、成果として示せる形にはなっていませんでした。

今日できることを、ひとつだけ挙げます。

いま気になっている業務について、「結果として見るもの」をひとつと、「自分たちで動かせる原因」をひとつ、書いてみてください。それだけで、基準の骨は立ちます。

一覧表は要りません。ひとつずつで十分です。

そして、改善に手をつける前に、いまの数字を測っておいてください。 比べる相手がなければ、どんな改善も証明できません。

次回は、品質管理の測り方を、事務仕事に持ち込む話を書きます。全部を数えなくていい抜き取りの考え方、数字にできない品質を扱う「限度見本」、そして事務仕事にそのまま使える「直行率」という指標の話です。

「うちの業務だと、何を管理項目にすればいいのか」。そこで手が止まる方が多いところだと思います。

さきほどの4列の表、その1行目を一緒に決めるところからお手伝いできます。業務の流れを整理する要件定義から、自動化した後の保守まで対応しています。

参考にした資料(すべて無料で読めます)

読めるもの 出典
管理項目・管理水準・点検項目・代用特性の定義 日本品質管理学会『品質管理用語』(JSQC-Std 00-001:2023)
方針管理の考え方、すり合わせ、管理帳票 同『方針管理の指針』(JSQC-Std 33-001)のサンプル
管理項目が何級の範囲か 品質管理検定(QC検定)レベル表(日本規格協会)

JIS本文(JIS Q 9023、JIS Q 9026)そのものは、日本産業標準調査会のサイトで無料閲覧できますが、利用者登録とログインが必要で、印刷やダウンロードはできません。そのためこの記事では、JIS本文からの引用はしていません。代わりに引用したのは、そのJISの原案を作った学会が、自分で無料公開している用語規格です。

関連記事
- あの人の「勘」は、なぜ引き継げないのか──暗黙の判断を、会社の基準に変える
- 「一番つらい業務」から自動化してはいけない──改善の順番を外さない選び方

ママゴトラボは、業務の自動化ツールを要件定義から設計してつくる開発ラボです。
属人化した業務の見える化から、自動化ツールの開発・保守まで承っています。
👉 ママゴトラボ|業務自動化の開発ラボ

その業務、自動化できるかもしれません

「毎回手でやっている作業」を、要件定義から見直してツールにします。GAS・Python・VBAでの自動化のご相談を承っています。

ココナラで相談する →
ブログ一覧に戻る