わかりやすい業務マニュアルの作り方(入門編)

初めに

あなたは業務マニュアルを作ったことがあるでしょうか?
「手順を書くだけでしょう、その程度簡単に作れるよ」と思ったそこのあなた、少しだけ待ってください。それは本当にわかりやすい業務マニュアルと言えるでしょうか?
本記事では「わかりやすい業務マニュアル」の作り方について、業務で200個以上のマニュアルを作成した筆者がおさえるべき基本について解説していきます。

0.業務マニュアルとは

業務マニュアルとは、それを読むことで「誰であっても一定以上のレベルで同じ業務を行えるようにする事」が目的の冊子やスライド、動画といった情報のことです。PC上で実行すると決まった結果が帰ってくるプログラムのようなものと言ってもいいかもしれません。

「プログラムなら、なぜ同じではなく一定以上のレベルなのか?」と疑問に思う人がいるかもしれません。ここで重要な観点は「どんな人でも」という点です。

マニュアルを読んで作業する人(以後、作業者と記載します)にはそれぞれ持っているスキルや経験、業務に関する知識のレベルに差があります。PCに例えるならば、OSのバージョンやメモリ、インストールされているソフトが違うようなものです。その為、マニュアルではあくまでもそういったスキルや知識に依存せず、作業者が誰であっても達成可能な「一定のレベル」というものを予め考えて制作するのが重要だとと考えています。

1.業務の目的

さて、業務マニュアルとは何であるかを述べた所で、早速業務の手順について細かく記述して……という訳には行きません。
具体的な業務手順を伝える前に欠かせない要素、それは「何の為の業務か」を明らかにすることです。

簡単な業務であれば影響は少ないかもしれませんが、複雑な業務となると、目的を伏せた状態で業務手順を伝えることは業務理解の難易度と、ミス発生のリスクを上げてしまいます。目的地も分からずにマラソンをはじめたらゴールするのは難しいですよね。

また、きちんと目的を伝えることで以下のような効果が期待できます。

  • 手順の予測
    「何の為の」という目的を知る事で、作業者は、業務全体の流れをある程度想像予測可能になります。予測が正しければ当然マニュアルの理解が早まりますし、外れていた場合であっても印象に残り業務理解に役立てることができます。

  • 注意箇所の予測
    手順の予測と合わせ、目的が分かれば注意が必要な箇所にあたりをつける事も出来ます。例えば「ウェブサイトの画像を更新する」と聞けば、画像のサイズや形式、画像デザインのレギュレーション、コピーライト……等と連想して注意が必要そうな項目を予測できますよね。

この様に業務の目的を伝える事で、単に記載した以上の情報を作業者に与えることが出来ます。必ず「何の為」の業務かを記載しましょう。

2.業務情報の分解・整理

さて、導入が長くなりましたが、ここからはより核心的な内容に踏み込んで解説して行きます。業務マニュアルを作る上で最も重要と言える作業、それは「業務情報の分解・整理」です。

そもそもここで述べている「業務」というのは、ある目的を達成するための一連の作業と言い換える事ができます。この一連の作業を構成する情報は、基本的に次の3つの種類に分けて整理することが出来ます。

タスク

【業務開始から完了までの作業を役割や、意味毎に分解したもの】
プログラムに例えるなら関数のようなものです。
タスクへ分解するときは個々のタスクが持つ役割のレベルが、同列となるよう意識するとよりわかりやすいマニュアルとなります。

例:更新用のファイルをつくる、バックアップをデータを作る、データを反映させる

フロー

【誰がどのような順番・流れでタスクを処理するのかという情報】
関数を呼び出す順番や条件による処理の分岐(if)、繰り返しの処理(for)を想像すると分かりやすいかもしれません。
簡単な業務の場合、順不同で処理可能なタスクも多いですが、自由な手順を許容しすぎると予期せぬミスが生まれるのである程度固定した方が業務の質が安定します。

例:デザイナーが画像を作る > ディレクターがチェックする > コーダーがサイトに反映する

変数

【同じ業務であっても、対応する毎に変化する要素】
簡単な所ではリネームの必要なファイル名等が挙げられます。これまでに述べたタスクに含まれる他、タスクやフローそのものが変数として捉えられる事もあります。
プログラムでもそのまま「変数」が登場し、同じ処理であっても変数に入る値によって結果が変わってしまいます。業務にとって、作業結果に変化を与える重要なポイントと言えます。

例:あるサイトの画像更新を行うとき、更新の処理、手順は同じでも画像やalt・リンクURL等が異なる

業務の種類や難易度によって、それぞれの情報ヘ分解する際の方法や粒度には差がありますが、タスク・フロー・変数の3つを整理して記述することで基本的なマニュアルの構造を作る事が出来ます。

3.マニュアルのフォーマット

書くべき情報を整理出来たら、次に考えるべきは「記述の型・フォーマット」です。マニュアルを作成する上で考えるべきフォーマットは、以下の2つに分けられます。

  • マニュアル自身のフォーマット
    パワーポイントやWiki、動画などマニュアルそのものを記述するツールや枠組み

  • 情報を記述する際のフォーマット
    章に分けた記述、箇条書き、表組みの使用、フロー図……といった情報を記述する際の書式

どちらも説明する業務の特性によって適したフォーマットは異なります。その為、業務ごとにフォーマットを変えて……と言いたい所ですが、それは大きな間違いです。

わかりやすいマニュアルの為に一番重要なのは「型を揃える」事です。

そもそも業務マニュアルの読み手は、新入社員や異動直後の人員などマニュアルを複数読みこんで、いくつもの業務を覚えなければならない場合が多いでしょう。そのような場面において、読むマニュアル毎に型が異なるとそれだけで手間を一つ増やしてしまいます。
逆に、型を揃えることで「何処に何の情報が記載されているか」が明確となる為、読めば読むほど全体の業務習得の効率が上がっていきます。

4.記述のルール

情報と書式がまとまった所で、実際の記述に移ります。
業務の手順を伝えるというマニュアルの特性上、誤解が生まれるような表現を避ける必要があります。誤解なく伝える際に特に重要なルールは以下の4つです。

対象の明示

業務に慣れた人間であれば気にしない「管理表」「エクセル」「○×管理表.xlsx」……といったような表記の揺れであっても作業者にとっては理解を妨げる大きな障害になります。編集・参照するファイル名やツール名などの表記を揃え、対象を明示する事が大切です。

一意的な表現

マニュアル内で「Excelと画像2個を編集する」と書かれていたらあなたはどう読み取るでしょうか?

  • Excel×1、画像×1を編集する

  • Excel×1、画像×2を編集する

このような簡単な例であれば、文脈から誤解せず読み取れるかもしれませんが、作業が複雑になるほど複数の意味で受け取れる文章は、作業者にとって大きな障害となります。
曖昧な文章表現は避け、意図が確実に伝わる表現が大切です。

簡潔な記述

タスクとして分解済みの作業であっても、「Aして、Bした後に、CをDに……」といった形で書き連ねてしまっては、非常に分かりにくい文章となります。文章が長くなるほど「一意的な表現」の例と同様に誤解が生まれやすくなります。
また、頭から通しで読むのではなく、部分的に作業内容を振り返りたい場合も冗長な表現はネックとなります。
可能な限り簡潔に記述することを心がけましょう。

当たり前の記述

「このくらいは当たり前だから省略して良いか」という考えは、マニュアル作成者にとって一度は通る道かもしれません。しかし、これは大きな落とし穴です。
「0.業務マニュアルとは」で述べたようにマニュアルの読み手は、その知識・経験・スキルに差があります。マニュアル作成者は、多くの場合業務の習熟度が高い為、「書くまでもない」と判断する内容が多くありますが、それが作業者にとって当たり前かどうかは別です。

どこまで当たり前のことを書けば良いのか、という問いは中々に難しいですが、マニュアルを使う可能性がある人の知識・スキルの平均がどの程度になるのかを踏まえてレベルを調整できると良いでしょう。

5.マニュアルが出来上がったら

マニュアルを作り上げたらそこで終了、という訳にはいきません。次は定期的な更新が待ち受けています。
業務内容の変更や使用ツールの変更、マニュアルそのものの精度を上げる為、等様々な理由から情報の更新が必要となります。ここで更新を怠ってしまうと、せっかく作り上げたマニュアルも無駄になってしまいます。
マニュアルを作る際は、マニュアルをどのように作るかだけでなく、どのように管理・更新するかも合わせて考える事が重要です。

最後に

いかがだったでしょうか。
作業内容をまとめる、と一口に言っても考えなければいけない事がこれだけある訳です。本記事はあくまで「入門編」であり、概説的な内容が多い構成でしたが、実際のマニュアル制作にあたっては分かりやすく伝えるための具体的な表現手法や情報をまとめるテクニックがさらにたくさん存在します。機会があれば実践編として、さらに具体的な方法論についてまとめられればと考えています。

「分かりやすいマニュアル」に終わりという意味での「完成」はありません。この様にいうとマニュアル制作のハードルが非常に高く感じられるかもしれません。しかし、これは「最初から完成度を高くする必要が無い」とも言えます。

まずは作ってみる、そこから始めてみましょう!


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