ある職場の話を、架空の例として書きます。
受注から出荷までの手順書は、三年前に作られたまま更新されていません。担当の一人は手順書どおりに進め、もう一人は自分なりの早いやり方で進めています。どちらが正しいのか、誰も決めていません。先月、出荷が一日遅れた一件がありました。原因を聞くと「確認が戻ってきた」「いつもはそんなことはない」と、人によって説明が違います。
「手順書を作り直して、守ってもらう」の落とし穴
こうしたとき、まず思いつくのは次のような手です。
- 手順書を作り直し、全員に同じやり方を守ってもらう。
- ツールを入れて、やり方を画面で固定する。
- 遅れを出した担当者に、次から気をつけてもらう。
どれも間違いではありません。新しい手順書やツールで、しばらくは効果も見えるでしょう。けれども、担当者が替わったり、忙しい時期が続いたりすると、いつの間にか元のやり方に戻っている。
平拓では、この現象を「改善の揺り戻し」と呼んでいます。一度変えたやり方が、担当の交代や忙しさをきっかけに、元に戻ってしまうことです。改善が続かない理由の一つに、やり方を決めることより、決めたやり方を誰がどう更新するかが決まっていない、ということがあります。
見落としやすい条件
標準は「最短の手順」ではない
標準というと、決められた手順書を思い浮かべるかもしれません。ここでは、標準を「いまの時点でいちばん良いやり方についての合意」として考えます。そこには手順だけでなく、どんな品質なら完了とするか、どこで判断するか、どんな例外があるか、どんなときに作業を止めるかも含まれます。いちばん速い手順だけを固定しても、例外のたびに崩れてしまうからです。
標準を更新する手順と責任が決まっていない
手順書が古くなるのは、怠けているからとは限りません。誰が、どんなきっかけで、どう書き換えてよいのかが決まっていなければ、現場で良いやり方が見つかっても、手順書には戻ってきません。反対に、手順書の更新日が古くても、それだけで「使えない」とは決められません。見直したうえで、今も有効だという場合もあります。
部分の速さが、別の場所の負担になっている
組織図と、実際に価値を届けている仕事の範囲は、一致しないことがあります。一つの部署の仕事が速くなっても、確認や入力のし直しが、別の部署や取引先、お客様の側に移っただけかもしれません。手順を変えるときは、その仕事の受け手の側で何が起きるかまで見る必要があります。
変える前の状態を、記録していない
改善の効果を確かめるには、変える前の状態を記録しておく必要があります。変える前の記録がないまま始めた変更は、あとから良くなったのかどうかを判断できません。
背景にある考え方
ここでは、改善の分野の考え方を三つ取り上げます。手法の名前を持ち込むことより、考え方を自社の仕事に置き換えることを大事にします。
守る回し方と、変える回し方。 改善の話では PDCA（計画・実行・確認・処置）がよく知られています。改善の分野では、その手前に、決めたやり方で回し、確かめて、ずれを直す「SDCA」という回し方も紹介されています。まず今のやり方を標準として安定させ、それを基準に改善し、成果が出たら標準を書き換える。書き換えておくことで、改善の成果が消えずに積み上がっていきます。
価値の流れを、受け手から見る。 仕事を、受け手の側から順にたどります。受け手は何を期待しているのか。依頼はどう届き、社内でどんな仕事が行われ、何が渡され、受け取られ、使われているのか。注文から届くまでの、モノと情報の流れの全体を一枚の図に描く「バリューストリームマッピング」の考え方を手がかりに、部分の作業時間と、全体として届くまでの時間を分けて見ます。
異常に気づいたら、止まる。 トヨタ生産方式の柱の一つである「自働化」は、異常が起きたら機械が止まる、あるいは人が止められるようにして、不良を次の工程へ流さない考え方です。問題が起きたとき、「気をつける」「もっと頑張る」で終わらせると、同じことがまた起きます。情報が足りなかったのか、権限がなかったのか、人手が足りなかったのか、道具が合っていなかったのか、判断の条件が曖昧だったのかを比べて考えます。この考え方は、AI やシステムを設計するときにも欠かせません。AI の出力がおかしいとき、そのまま次の工程に流れていくのではなく、止まって人に渡る。そうした仕組みがあって初めて、現場は安心して新しい道具を使えます。
標準に書いておくこと
手順書を作り直すなら、手順に加えて、次のことを書いておくと、例外や担当の交代に強くなります。
| 書いておくこと | 例 |
|---|---|
| 手順 | 受注から出荷までの順番と、使う画面・帳票 |
| 完了の条件 | どこまで確かめたら「出荷してよい」とするか |
| 判断の基準 | 誰が、何を見て決めるか |
| 例外と対応 | 特急品、仕様変更、在庫不足のときにどうするか |
| 止める条件と知らせる先 | どんなときに作業を止め、誰に知らせるか |
| 更新の手順と責任者 | 誰が、どんなきっかけで書き換えてよいか |
| 最後に見直した日と理由 | 何を、なぜ変えたか |
最後の二行が、改善を続けるための部分です。誰が、なぜ、いつ標準を変えたのかが残っていれば、次の人がそれを引き継いで更新できます。
効果は、変える前から測り始める
効果を判定するときは、「改善」「変化なし」「悪化」に加えて、「未計測・判断できない」を分けておくのがおすすめです。判断できないときに、無理に「改善」と書かないためです。
時間が短くなったら、その余裕が何に使われたかまで確かめます。生まれた余裕が別の仕事に吸い込まれていれば、成果はまだ出ていないかもしれません。
自社で確かめる問い
- いまの手順書を最後に更新したのは、いつ、誰ですか。更新した理由は残っていますか。
- 同じ仕事で、人によってやり方が違うところはどこですか。どちらが良いかを決めるのは誰ですか。
- 「完了」とする品質の条件は、書かれていますか。
- 例外が起きたとき、作業を止めて知らせる先は決まっていますか。
- 改善の前の状態を、何で記録していますか。
- 速くなった工程の後ろで、誰かの確認や手直しが増えていませんか。
選択肢
手順書を全面的に作り直すことだけが答えではありません。
- 最近の一件を、関わった人と一緒にたどる。 誰が、何を見て、どこで判断したか。手順書と照らして、どこが同じでどこが違うか。そこから「いまの時点でいちばん良いやり方」を暫定の基準として書き出し、次の一件で確かめる。手順書を作り直すのは、その後でも遅くありません。
- 頻度と影響の大きい工程から始める。 すべての仕事に手順書を作ろうとすると、作ること自体が目的になりがちです。
- 今の手順書を見直して、使い続ける。 古くても有効なら、更新の手順と責任者だけを決める。
- ツールで固定する前に、運用で試す。 画面でやり方を固定すると、良いやり方が見つかっても変えにくくなります。
- 必要な部分だけをシステムにする。 例外の記録や、止めて知らせる仕組みなど、人の注意に頼ると崩れやすいところから。
改善のアイデアを出すときには、「なくせないか」「まとめられないか」「順番を入れ替えられないか」「簡単にできないか」という四つの問いかけ（ECRS と呼ばれる考え方）も役に立ちます。ただし、問いの順番だけで効果や費用の優劣を決めず、その仕事の目的と条件を確かめてから比べます。
関連する支援
平拓が目指しているのは、一時的に効率を上げることではなく、関わった企業が自分たちで問題を見つけ、改善し続けられる状態です。業務の改善、AI・システム開発では、仕事の流れを整え、人によって違うやり方をそろえ、現場が自分で更新できる手順と、改善を続けるための見方を一緒につくります。どこから手をつけるべきかが分からない段階なら、診断から始められます。
参考
- トヨタ自動車「トヨタ生産方式」（自働化・ジャスト・イン・タイム・日々改善の説明）
- Mike Rother, John Shook “Learning to See”（Lean Enterprise Institute）（バリューストリームマッピングの手引き）
- Lean Enterprise Institute 用語解説「Kaizen」（標準を基準に改善し、成果が出たら標準を書き換える考え方）
※本文の職場の例は、説明のための架空の例です。
