そのマニュアル、持ち主は誰ですか

古くなって使われなくなったマニュアルの話をうかがうと、原因はたいてい「更新が止まったから」に行き着きます。ではなぜ更新が止まるのか。さらにたどっていくと、多くの場合、ある一点に突き当たります。そのマニュアルの持ち主が、そもそも決まっていなかった、ということです。

作った人が現役でいるうちは、なんとなく回っています。おかしいところがあれば、その人が気づいて直すからです。ところが、その人が別の部署へ異動したり、退職したりした瞬間、状況が変わります。残されたマニュアルは、誰のものでもなくなります。中身が古くなっても、直す人がいない。正確に言えば、直す責任を持つ人がいないのです。

持ち主のいないマニュアルは、誰の仕事でもありません。誰の仕事でもないものは、放っておかれます。更新が止まる根っこには、多くの場合、この持ち主不在の問題があると私たちは考えています。

この記事では、マニュアルのオーナー不在という問題を軸に、なぜそれが起きるのか、そしてどうすれば各マニュアルに持ち主を置いて生かし続けられるのかを整理します。更新を軽くする具体的な進め方については更新されず古くなるマニュアル問題への対処で扱っていますので、本記事は所有と責任、体制のほうに焦点を当てます。

持ち主がいないと、なぜ腐るのか

マニュアルが放置される場面を思い浮かべると、たいてい共通した空気があります。「誰かが直すだろう」という空気です。全員がそう思っていると、結局、誰も直しません。

「気づいた人が直す」は、裏を返せば「誰も直さなくてよい」と同じです。責任が特定の誰かに紐づいていないと、気づいても見て見ぬふりをする理由がいくらでも作れます。忙しいから、自分の担当ではないから、勝手に触ってよいか分からないから。こうして、おかしいと気づいている人が何人もいるのに、直されないまま古くなっていきます。

とりわけ危ういのが、作った人がいなくなる場面です。作成者が異動や退職で職場を離れると、そのマニュアルの背景を知る人が消えます。なぜこの手順なのか、どこは変えてよくてどこは変えてはいけないのか。そうした文脈ごと失われると、残った人は怖くて手を出せません。結果として、古いと分かっていても放置される、という最悪の形で固まってしまいます。これは引き継ぎがうまくいかなかったときの典型的な症状でもあります。

なぜオーナーが決まらないのか

では、なぜ持ち主が決まらないのでしょうか。現場の怠慢ではなく、仕組みの側に理由があると私たちは考えています。いくつかに分けて見ていきます。

作成が一過性のプロジェクト扱いになっている

マニュアル作りが、期限を切った一回きりの仕事として扱われることがよくあります。「今期中に手順書を整備する」といった号令のもとで一気に作り、作り終えたら解散します。作る体制はあっても、作ったあと誰が面倒を見るのかは決めていない。プロジェクトが終わった時点で、持ち主も一緒に消えてしまうのです。

責任の所在があいまいなまま始まる

そもそも「このマニュアルは誰のものか」を最初に決めないまま運用が始まる場合も多いです。作った人がなんとなくの持ち主になりますが、それは正式な役割ではありません。だからその人が抜けても引き継がれず、宙に浮きます。所在が言葉になっていないと、抜けたときに穴が見えません。

更新が評価につながらない

もうひとつ根深いのが、マニュアルを直す仕事が、あまり評価されないことです。新しく作れば目立ちますが、こつこつ直し続けても表立って褒められる場面は多くありません。評価されない仕事は、どうしても後回しになります。持ち主を決めても、その役割が報われない構造だと、負担だけが残って長続きしません。

持ち主を置いて生かし続ける

では、どうすれば各マニュアルに持ち主を置き、生きた状態を保てるのでしょうか。ここも観点に分けて整理します。

各マニュアルに責任者を割り当てる

まず、一つひとつのマニュアルに責任者をはっきり紐づけます。個人名でも、役割でも構いません。むしろ、その人が抜けても役割が残るように、「この工程の担当者」といった役割に紐づけておくほうが安全です。人に紐づけると異動で消えますが、役割に紐づけておけば後任へ自然に引き継がれます。

更新のトリガーを決める

次に、いつ見直すのかを決めます。放っておくと更新のきっかけは訪れないので、きっかけのほうを仕組みにします。手順が変わったときに直す、という変更ドリブンのトリガーと、半年に一度など定期的に棚卸しするトリガー。この二つを組み合わせておくと、大きな変更も、じわじわ進む小さなずれも、どちらも拾えます。定期的な棚卸しは標準化を保つうえでも効いてきます。

更新を軽くして属人化を防ぐ

責任者を置いても、更新そのものが重いと結局回りません。だからこそ、更新の作業を軽くしておくことが、持ち主を続けさせる条件になります。直すのに専門知識や特別な手間がかかると、その人しか直せない属人的な状態に逆戻りします。

誰でも直せる状態にしておく

そして、責任者を置くことと、その人だけしか触れないことは違います。責任の所在は明確にしつつ、実際には現場の誰もがおかしいと気づいたときに直せる状態にしておくのが理想です。責任者は最終的に面倒を見る人であって、更新を独占する人ではありません。この二段構えにしておくと、責任者が忙しいときでもずれが放置されません。

持ち主を役割で置き、更新のきっかけを仕組みにし、直す作業を軽くして、誰もが直せるようにしておく。責任は明確に、更新は開かれた状態に。この組み合わせが、持ち主不在への一番の備えだと私たちは考えています。

Flowbaseでの考え方

ここからはFlowbaseの話を、確実に言える範囲だけ正直に書きます。

私たちは、持ち主が続けやすい状態を、仕組みの側から支えたいと考えています。Flowbaseは作業の様子を撮った動画からマニュアルを作るので、手順が変わったら変わった部分を撮り直すだけで更新できます。文章を一から書き直す重さがないぶん、責任者の負担が軽くなり、持ち主を続けやすくなると考えています。更新が軽いことは、属人化を防ぐうえでも効いてきます。

編集の権限を役割で分けられるので、誰がそのマニュアルの編集者なのかをはっきりさせられます。責任の所在を、運用のルールだけでなく仕組みの上でも見えるようにできる、ということです。あわせて、変更の履歴をたどれるバージョン管理を備えているので、いつ誰が何を直したのかが残ります。持ち主が変わったときにも、これまでの経緯を追いながら引き継げます。こうした仕組みは、ナレッジマネジメントを特定の個人に依存させないための土台になると考えています。

一方で、確証のないことは書きません。仕組みを整えれば持ち主の問題がすべて解決する、とは考えていません。誰を責任者にするか、更新をどう評価に組み込むかは、それぞれの組織で決めていく体制づくりの話であって、ツールが肩代わりできる部分ではないからです。私たちにできるのは、その体制を回しやすくすること、更新を軽くし、責任を見えるようにし、履歴を残すことです。あらゆる現場で検証できているわけではないので、お客様のご相談をいただきながら、合う形を一緒に探させていただきたいと考えています。マニュアル運用や乗り換えの進め方については、更新されず古くなるマニュアル問題への対処やマニュアルツールの乗り換え・移行で確認することもあわせてご覧ください。

よくある質問