「業務を仕組み化しました。」
マニュアルを作った。
担当者を決めた。
業務フローも整理した。
これで担当者が変わっても仕事が止まらない。
そう思っていたはずなのに、半年後には、
「これは〇〇さんに聞かないと分かりません。」
という状態に戻っている。
そんなことがあります。
私は、仕組み化とは一度仕組みを作れば終わるものではないと考えています。
仕組みは、運用し続けなければ再び属人化します。
マニュアルを作っただけでは、仕組み化ではありません
属人化を解消しようとすると、
「まずマニュアルを作りましょう。」
という話になることがあります。
もちろん、マニュアルは大切です。
しかし、マニュアルを作っただけで仕事が仕組み化されるわけではありません。
例えば、半年前に作ったマニュアルがあります。
その後、
使用するシステムが変わった。
料金が変わった。
担当者が変わった。
承認フローが変わった。
お客様への対応方法も変わった。
それなのに、マニュアルだけが半年前の状態だったらどうでしょうか。
担当者はマニュアルを見ても、実際の運用と違うことに気付きます。
そして、
「〇〇さんに聞いた方が早い。」
となります。
ここから、属人化がもう一度始まります。
「聞いた方が早い」が仕組みを壊していく
仕事をしていれば、マニュアルに載っていないことは必ず起こります。
そんなとき、
「これ、どうすればいいですか？」
と詳しい人に聞く。
詳しい人が、
「今回はこうしてください。」
と答える。
ここまでは問題ありません。
問題は、そのやり取りが仕組みに戻されないことです。
次に同じことが起きたときも、また同じ人に聞きます。
その次も聞きます。
気付けば、
マニュアルではなく、
「〇〇さんに聞く」が正式な業務フローになっています。
本人も、いつの間にかその仕事の相談窓口になっています。
これは、以前書いた「気が付く人に仕事が集まる」という話にもよく似ています。
最初は少し助けただけだった。
でも、それが繰り返されるうちに「あの人の仕事」になってしまう。
仕組みも同じです。
例外を放置すると、少しずつ人に仕事が戻っていきます。
管理者が属人化を強化していることもあります
もう一つ、属人化に戻ってしまう原因として見落とされやすいのが、管理者の言葉です。
仕事に詳しく、何を聞いてもすぐ答えてくれる人がいると、
「〇〇さん、頼りにしてるよ。」
「分からなかったら〇〇さんに聞いて。」
「〇〇さんなら分かるから。」
と、管理者が周囲へ伝えることがあります。
もちろん、本人を評価しているつもりでしょう。
実際、その人が組織を支えてくれていることも事実だと思います。
しかし、これを繰り返していると、
「分からないことがあったら、仕組みを確認する。」
ではなく、
「分からないことがあったら、〇〇さんに聞く。」
という新しい業務フローが出来上がります。
すると、その人に質問が集中します。
本人は自分の仕事をしながら、周囲からの質問にも答える。
トラブルが起きれば呼ばれる。
新人が入れば質問される。
担当者が変わっても質問される。
そして管理者は、
「やっぱり〇〇さんがいないと困るね。」
「頼りにしてるよ。」
と、さらにその人を頼るようになります。
そして、こういう役割を引き受けている人は、決まって優秀です。
周囲をよく見ています。
責任感があります。
自分で考えて動けます。
困っている人がいれば助けます。
だから、仕事が増えても何とかしてしまいます。
本来の担当業務に加えて、質問に答える。
抜け漏れに気付けば対応する。
誰も判断できなければ代わりに判断する。
それでも仕事を止めないので、周囲から見ると問題が起きていないように見えます。
しかし、問題がないのではありません。
その人が問題を引き受け続けているだけです。
そして、ある日限界を迎えます。
「もう続けられません。」
そう言って退職する。
そこで初めて会社は気付きます。
誰もこの仕事を知らない。
判断基準が残っていない。
取引先との経緯も分からない。
マニュアルを見ても、実際の運用とは違う。
そして、
「〇〇さんが辞めたから大変になった。」
という話になります。
でも、本当は違います。
その人が辞めたことで問題が起きたのではなく、その人がいたから問題が見えていなかったのです。
頼りになる人を評価することと、頼り続けることは違います。
優秀な人を長く活かしたいのであれば、その人に仕事を集めるのではなく、その人が持っている知識や経験を組織へ戻していく必要があります。
新しい担当者へ口頭だけで教えていませんか
担当変更のときにも、属人化は戻りやすくなります。
新しい担当者が入る。
前任者が横について教える。
「これはこうしてください。」
「この場合は私に聞いてください。」
「ここはマニュアルと少し違うんですけど……。」
口頭では仕事が引き継がれています。
でも、その内容がマニュアルや業務フローへ反映されていなければ、仕組みは更新されていません。
さらに、その担当者が次の人へ同じように口頭で教える。
少しずつ人によってやり方が変わっていきます。
やがて、
「正式なやり方が分からない。」
という状態になります。
引き継ぎとは、人から人へ仕事を渡すことだけではありません。
仕組みから人へ仕事を渡せる状態を保つことも大切です。
仕組みにも、管理者が必要です
では、どうすれば仕組みを維持できるのでしょうか。
私は、
仕組みを管理する人を決めておくこと
が必要だと考えています。
誰がマニュアルを更新するのか。
業務フローが変わったら誰が反映するのか。
新しい例外対応が発生したら誰がルールに追加するのか。
いつ見直すのか。
ここまで決めておく。
意外と、
「マニュアルを作る担当者」
は決まっていても、
「マニュアルを更新する担当者」
は決まっていないことがあります。
作った瞬間は最新です。
しかし、仕事は翌日から変化していきます。
だから、更新する仕組みまで作らなければ、マニュアルは少しずつ現場から離れていきます。
仕組みは、現場に合わせて変わっていい
一度決めたルールを変えてはいけない。
そんなことはありません。
むしろ、運用してみたからこそ分かることがあります。
この手順は時間がかかる。
この確認はいらない。
この場合の判断基準がない。
この作業は自動化できる。
そうした現場の声を拾って、仕組みを改善していく。
私は、それが本当の意味での仕組み化だと思っています。
仕組みに人を無理やり合わせるのではありません。
人が迷わず仕事を進められるように、仕組みの方も育てていく。
その視点が必要です。
AIを使う場合も同じです
これは、最近書いているAI活用にもつながります。
AIに会社の判断基準を渡した。
業務マニュアルを読み込ませた。
それで終わりではありません。
会社のルールが変わったのに、AIへ渡している情報が古いままであれば、AIは古い基準で回答します。
人に渡す情報も。
AIに渡す情報も。
会社の運用が変われば、一緒に更新する必要があります。
AIを導入したから仕組み化できるのではありません。
更新できる仕組みがあるから、AIも活かせるのです。
仕組み化とは、「作ること」ではありません
マニュアルを作る。
業務フローを作る。
担当者を決める。
それは仕組み化のスタートです。
大切なのは、その後です。
運用する。
問題を見つける。
改善する。
更新する。
そして、また運用する。
この繰り返しによって、仕組みは会社の中に定着していきます。
私は、属人化を防ぐために必要なのは、完璧なマニュアルではないと思っています。
担当者が変わっても仕事が続く。
仕事のやり方が変われば、仕組みも一緒に変わる。
例外が発生したら、それを次の判断基準として残す。
そんな状態をつくることです。
善意を仕組みにする。
経験を仕組みにする。
判断を仕組みにする。
そして、その仕組み自体も更新され続ける。
私は、そこまで設計して初めて、「仕組み化された組織」と呼べるのだと考えています。
