「君のやり方を、そのまま手順書にしてくれればいい」。そう頼んで出てきた手順書は、よくできていた。誤字もなく、ステップも漏れていない。
ところが、それを見ながら別の担当者に作業させると、なぜか同じ結果にならない。手順書には書いていない何かを、ベテランは毎回やっている。
その「何か」を本人に聞いても、「いや、普通にやってるだけです」と返ってくるだけだった。
連載の第3回です。前回までで、業務マニュアルが難しい理由を「書く本人」の視点から見てきました。
最も書くべき判断ほど熟練によって無意識に沈み、本人にも見えなくなる。だから一人の内省だけでは、最後の一歩に届かない（第2回はこちら）。
今回からは視点を変えます。
マニュアルを「書いてもらう側」 ― 上司やチームリーダー、業務改善を担う社内の指導者の立場です。
本人に見えていない判断を、外から引き出すには何が要るのか。冒頭の無力感は、引き出す側なら誰もが味わうものです。
引き出す側の話は、二回に分けます。
今回は、具体的に手を動かす前に必要な「考え方」 ― どこに力を入れるかの見極めと、標準化に本当に効く頭の使い方。
次回（第4回）で、隠れた判断を実際に引き出す具体的な道具を扱います。
まず、どこを締め、どこを緩めるかを見極める
引き出す作業に入る前に、引き出す側がやるべき判断があります。
すべてを厳密に書かせようとすれば、本人も疲弊し、文書も膨れ上がって使われません。だから「どこを締め、どこを緩めるか」を先に見極める。
その軸は二つです。
- 軸1：間違えたときの損害の大きさ ― ミスが重大な事故や大きな損失につながり、しかも頻度が高い工程は、徹底的に締める。曖昧さを残さない。
- 軸2：判断に必要な専門知識の深さ ― 経験や勘がそのまま価値を生むような判断は、無理に締めず、余地を残す。締めるとかえって質が落ちる。
具体例で考えてみます。
製造現場の検査や段取りのうち、手順を一つ間違えると不良品が大量に出るような工程は、軸1に当てはまります。
ここは数値と条件で締め切る。一方、顧客対応のように、相手の状況を読んで打ち手を変える判断業務は、軸2の色が濃い。マニュアルで縛りすぎると、機械的で的外れな対応になってしまいます。
引き出す側の最初の仕事は、目の前の業務がどちらの性格なのかを見立て、力を入れる場所を定めることです。
「プログラミング的思考」を、現場の言葉に直す
力を入れる場所が決まったら、次は頭の使い方です。ここで、近ごろよく聞く言葉をひとつ整理させてください。「プログラミング的思考」です。「うちの現場に、プログラミング的思考なんて要るのか」と感じる方も多いと思います。結論から言えば、必要なのは特定のプログラミング言語の知識ではありません。むしろ標準化の役に立つのは、この言葉が指す「頭の使い方」のほうです。
まず、第2回で出てきた「アルゴリズム」とは別物だという点を押さえます。アルゴリズムは手順そのもの、つまり成果物です。一方プログラミング的思考は、その手順を生み出すための頭の使い方、能力や態度のことを指します。レシピがアルゴリズムなら、プログラミング的思考は段取りよく考える力にあたる、と言えば近いでしょうか。
この言葉は、日本では文部科学省が小学校のプログラミング教育のために整理した概念です。趣旨をかみ砕くと、「やりたいことを実現するために、どんな動きをどう組み合わせ、どう改善すれば意図に近づくかを、論理的に考える力」とされています。学術的には、ジャネット・ウィングが2006年に提唱した computational thinking（計算論的思考）が対応する考え方ですが、日本語の「プログラミング的思考」は範囲がやや広く、論じる人によってぶれがある言葉でもあります。だからここでは、用語そのものより中身を見ます。
その中身は、おおむね四つの要素に分けられます。
- 分解：大きな問題を、小さな手順に切り分ける。
- 抽象化：枝葉を捨て、本質的なパターンを取り出す。
- 順序立て（アルゴリズム化）：手順を正しい順番と条件分岐で組む。← これが狭い意味でのアルゴリズムにあたる。
- 改善（試して直す）：結果を見て手順を直し、意図に近づける。
ここで気づいてほしいことがあります。私たちが「アルゴリズム」と呼んでいたものは、この四要素のうち3番にすぎません。プログラミング的思考は、分解し・抽象化し・組み・試して直すというプロセス全体で、アルゴリズムよりずっと広いのです。
「アルゴリズムを書く力が要る」は、半分しか当たっていない
よく「標準化にはアルゴリズムを書く力が要る」と言われます。間違いではありませんが、半分しか当たっていません。
これまで見てきたとおり、標準化の最大の壁は、熟練者の無意識の判断が書き漏れることでした。これは、手順を順序立てて組む力（3番）が足りないせいで起きるのではありません。原因はむしろ別のところにあります。
ひとつは、分解（1番）が粗いこと。本当はいくつもの判断が詰まっている作業を、「確認する」の一行でまとめてしまう。すると、その中に詰まっていた判断が、刻まれないまま塊の中に埋もれてしまう。もうひとつは、改善（4番）をしないこと。書いた手順を他人に試させて、詰まったところを直すという反復を回さない。だから書き漏れが永遠に表に出てこない。
つまり、標準化で本当に要るのは、きれいなアルゴリズムを書く力ではなく、「作業を細かく分解する力」と「試して直すデバッグ的な姿勢」です。この二つこそ、プログラミング的思考の中核にある要素なのです。
標準化につまずくのは、手順を組む力が足りないからではない。粗く分解し、試して直さないからだ。
「分解」と「改善」は、別々の壁に効く
ここで、第2回の話とつなげておきます。
前回、「言葉にできない」には二種類あると述べました。
(a) 感じているが言葉にできないもの。
(b) そもそも気づいていないもの。
この二つに、いまの「分解」と「改善」がきれいに対応します。
分解が効くのは、主に (a) のほうです。
本人が薄々感じてはいるが「確認する」の一行にまとめてしまっている判断 ― これは、行を細かく刻み直せば表に出てきます。
分解は、感じているのに塊に埋もれていたものを、ほどいて取り出す道具なのです。
けれど、分解だけでは (b) には届きません。
本人がそもそも気づいていない判断は、いくら細かく刻もうとしても、刻む対象として意識に上ってこないからです。
ここに必要なのが、もうひとつの改善 ― 他人に試させて、詰まったところから書き漏れを発見する反復です。自分の意識の外にあるものは、他人のつまずきという形でしか見えてきません。
つまり、分解は (a) を開く道具、改善は (b) に届く道具。役割が違います。
この対応を頭に入れておくと、次回紹介する具体的な道具が、それぞれどの壁を狙っているのかがはっきり見えてきます。
難しい言葉を覚える必要はありません。やることは、細かく刻むことと、試して直すこと。その二つが、別々の理由で効くのです。
考え方の地ならしは、ここまでです。
次回は、この「分解」と「改善」を現場で実際に回すための具体的な道具 ― 動詞で終わる行の疑い方、異常時の埋めさせ方、そして他人に手順書だけで再現させる検証法を見ていきます。
HABAねっとは、北陸を拠点に中小企業・個人事業主のDX伴走支援を行っています。
「どこを締め、どこを分解するか」の見極めは、業務標準化やDXの設計そのものです。
「ツール選定」ではなく「課題」「業務」「人」から設計するDXを、一緒に組み立てます。