見出し画像

チームが強くなるマニュアルの作り方:大事なポイントは2つだけ

新人教育/通常オペレーション/イレギュラー対応などのマニュアルの作り方について、「チーム作り」という人事の視点を交えて、弊社で大切にしていることをご紹介します。

弊社が提供している「現場向け動画教育システム tebiki」の重要な機能の一つはマニュアル作成で、まさにこの記事で書いたエッセンスを活かしてプロダクト開発しています。

※tebikiは動画がメインで、現場が苦労してテキストで作っていたマニュアルを動画に置き換えるサービスです。弊社の社内マニュアルは、UIの参考にしたいこともあって、Googleドキュメント、esa、そしてもちろんtebikiの3種類を使い分けています。 本記事のスクショはすべてGoogleドキュメント。

( 貴山 @tkiyama )

「マニュアル」とは

一般にマニュアルというと、電気製品の取扱説明書みたいなものをイメージする人が多いと思いますが、弊社では、基本方針/ガイドライン/作業手順/対応記録/プレイブック/ワークフローなど、全てひっくるめて「マニュアル」と呼んでいます。

効率的に定常業務をこなすためだけでなく、イレギュラー対応や、新機能リリース時のオペレーション構築等を含めて、全てのドキュメンテーションが対象。弊社のマニュアルは作って終わりではなく、オペレーションとともに中身を常に更新しています。

良いマニュアルと悪いマニュアルの違い

マニュアルの良し悪しは、時間が経つとすぐにわかります。

「良いマニュアル」は、生き物のように変化します。「育っていく」感じ。イレギュラーケースが発生する都度、中身が精査されて使いやすくなって、ページ数が増えすぎたドキュメントが分割されたり廃止されたりします。

「悪いマニュアル」は、どんどん現実とそぐわなくなって使われなくなるので、最後は放置されます。「マニュアルないの?」とスタッフに聞いたとき、「あるんですけど、あのマニュアル間違ってるんですよ」と言われたら管理者失格。スタッフを混乱させるマニュアルが存在していて、かつそれを放置しているチームに未来はありません。

※弊社のあるマニュアルの改訂履歴。最初に作ってから1年以上経っていますが、今も頻繁に更新されています。

開発ブログ_改訂履歴

なぜマニュアルが大切かを人事の視点から

業務改善、ユーザー対応方針の統一、事業開発のスピードアップとかも大事だけど、私がマニュアルを重視する一番の理由は、 「ちゃんとマニュアルを作成・維持できるチームを作らないと、スタッフが辞めちゃうから」です。

オペレーションスタッフの定着率が低いチームは、たいていここができてない。マニュアルがないから、業務が難しくて、忙しくて、人が足りなくて、スタッフが辞めてしまう悪循環になるわけです。

マニュアルがイマイチだとどうなるのでしょうか。

・対応方針が明確じゃないからアクションを間違えて、そのミスは対応したスタッフが悪いとされます。

・イレギュラー時の対応方針がわからず、毎回ゼロから考えないといけません。人員配置は通常業務を想定しており、イレギュラーケースはかなり業務時間を圧迫するので、忙しい中でストレスフルな仕事を一生懸命やることになります。

・口伝のノウハウで引き継ぎが遅いので、先輩社員の負担が大きかったり、先輩が偉くなったりします。逆に、先輩社員からすると新入社員の覚えが悪いのでイライラしてチームがぎすぎすしてくる。

・どんなに努力しても必ずクレームは発生します。でも、方針が明確であれば鋼の心で乗り越えられるけど、方針が不明瞭だと拠り所がないので耐えられない。

マニュアル作ろうよという話をすると、やらない理由のダントツ1位は「イレギュラーケースが多すぎてマニュアル化できない」ですが、対応方針のガイドラインは作れるはず。ガイドラインがあるかどうかで、効率も精度も10倍ぐらい変わります。

「マニュアル作るヒマがあるなら事業成長にフォーカスすべき」みたいな誤解もよくありますが、マニュアルはすぐ作れます。時間がかかりすぎるのはチームの能力が足りないだけ。明確な方針と手順がないことで、どれだけ事業に損失が出ているか考えてみてください。

※弊社のWebミーティングマニュアルの目次の一部。段取りやトラブルシューティングを明確にすることで、Webミーティングの中身に集中できるようにしています。

開発ブログ_webミーティング目次

マニュアルのテンプレート(雛形)

こちらは弊社のマニュアルのテンプレートの目次。テンプレートとTIPSを兼ねています。

開発ブログ_雛形

様式を統一した方が読みやすいので決めている程度で、実はテンプレートにあまり意味はないです。いろんな業務があるので、かっちりしたテンプレートを作っても役に立たない。

ちなみに、数字の全角と半角を混在させる人は多いです。こういう細部に気づけるビジネスパーソンになって欲しい。「割れ窓理論」の通り、こういう小さなところからドキュメント管理全体が乱れるので。

マニュアル作成で大事なことは2つだけ

良いマニュアルを作るために必要なポイントは、「Whyを明確にする」「責任者を一人決める」の2つだけです。この2点さえ押さえておけば、時間とともに必ず良いマニュアルになっていきます。

「良いマニュアル」を作るポイントその1: Whyを明確にする

マニュアルなので、「何をやるのか(What)」「どうやるのか(How)」は明確ですが、よく忘れられるのが「なぜやるのか(Why)」です。

日々の業務をこなしていると、「なぜ/なんのために、この業務をやっているのか」をいつしか忘れていきますが、Whyをマニュアルに明文化しておくことで、想定外の事態が発生したときもすぐに対策がとれるし、「そもそもこの業務、意味ないよね?やめようよ」という見直しもしやすくなります。

「良いマニュアル」を作るポイントその2: 責任者を一人だけ決める

弊社のマニュアルでは、全てのマニュアルに責任者が一人だけいます。

「みんなでマニュアルを良くする」は間違い。
「みんなの意見を聞きつつ(文句を言われながら)、一人が責任をもってマニュアルを改訂する」が正しい。

大事なのは部分最適ではなく全体最適。一人が責任と権限を負うことで、マニュアルが放置されることもなく、全体最適を保持したままブラッシュアップすることができる。

業務プロセスを、そのままの形で少しずつ改善するのか、KPIを変えるのか、根本的に見直すのかは、責任者に任されます。結局のところ、そのオペレーションを担当しているスタッフが一番わかっているし、そのスタッフができないのであれば、上から指示してもうまくいきません。

各マニュアルに責任者を置くことは、スタッフ育成も目的としています。小さいながらも自分が責任を負う業務を作ることで、責任感、視野の広さ、言語化、チームマネジメントなどを培うことができます。

スモールスタートを支えるマニュアル

弊社では、営業やCSからの「これシステム化してください」という要望を、エンジニアが却下するということが頻繁に起こります。いまシステム化してしまうと負債になるだけではないのか、外部サービスを活用した方がいいのではないか、エンジニアリングより人力の方がコストが低いのではないか、そもそももっと考えてから持って来い、などなどが理由です。

新しい打ち手はまず手作業。コードを書かない。自動化しない。 だからこそ、手作業オペレーションマニュアルを作って、考え方を明確にしておくことが重要です。 ここで基本方針と段取りを明文化できると、後にシステム化する時に、マニュアルがそのまま要件定義書になるので、開発がすごく早くなる。

あえて最初からシステム化せずに、新しいパターンが生まれる都度、マニュアルを改訂して、完全にオペレーションが固まったところでシステム要件の最終調整に入ります。 このやり方だから、コードが負債化することなく、手戻りを最小限にしながら、思いついたらすぐ変更、ができるわけです。

※この記事で書かれている「文書化する」というのとまさに同じ。

最後に

よく誤解されてるけど、マニュアル作りは難しくないし、時間もかからない。ちょっと訓練すれば誰でもできるようになります。

マニュアルを育てず、同じことに毎回無駄な時間とミスを繰り返すのは、チームを不幸にして会社に損失を与えているだけ。良いマニュアルとは、そんなところで足を引っ張られることなく、事業成長に集中するためのものです。筋肉質で強いチームを作るために、この記事が少しでも役に立ってくれると嬉しいです。


ピナクルズ社では一緒に働く仲間を募集してます!

tebikiという、店舗/倉庫/工場などの「現場向け動画教育システム」を提供しています。社員一桁台になりたい人、会社の看板じゃなくて自分の力で事業をつくって世界を変えたい人、一緒にやりましょう!!




この記事が気に入ったらサポートをしてみませんか?