情報システム部門・IT部門が強くなるためのプラットフォーム

攻めの情シス研究所

情シスにノウハウを。
情シスが会社を強くします。

マニュアルは誰が作るんですか?

2024

12/04

マニュアルは誰が作るんですか?

プロジェクトで必ず出てくる質問

「マニュアルは誰が作るんですか?」

ある現場で、情シスメンバーから質問をいただきました。

現在、基幹システム再構築プロジェクトが後半に差し掛かっています。

この質問は、どのプロジェクトでも必ず聞かれます。

なぜかというと、選択肢が3つあり、その全てがありえそうだから。

選択肢とは、次の3つです。
① ベンダー
② 情シス
③ ユーザー

はたして、マニュアルはこの中で、誰が作るべきでしょうか?

マニュアルの種類

マニュアルを大別すると「システムマニュアル」と「業務マニュアル」があります。

システムマニュアルは、システムの機能を網羅し、操作方法を記載します。家電製品の「取扱説明書」のようなものです。

他方、業務マニュアルは、「業務目線」で書かれるものです。現場の業務として、新システムは道具の1つにすぎません。そのシステムをどう利用し、運用していくか。そのため、業務マニュアルは、システムマニュアルの一部を含みますが、使われない機能などは書かれません。

また、業務マニュアルでは、業務の流れに沿って、新システム以外の要素も説明する必要があります。

例えば、連携する他システムやエクセル、電話/メール/FAXなども登場します。他部署への手続きや電話での確認内容など、システム外のプロセスも説明します。

その上で、現場にとって重要なマニュアルはどちらでしょうか?

考えるまでもなく「業務マニュアル」ですね。

現場のユーザーにとって、日常業務をどう進めていくか。その指針となるのが業務マニュアルなのです。

業務との関連性が薄いシステムマニュアルは、業務の全体の流れがわかりません。現場目線で、探したいものが見つからず、ほとんど使われなくなっていきます。

そのため、プロジェクトでは「業務マニュアル」の作成を目指していくことになります。

業務マニュアルの目的

では、あらためて業務マニュアルの目的は何でしょうか?

ざっくり5つに分けて考えてみます。

① 新システムのユーザー教育、研修

これが最大の目的。新システムの操作に慣れてもらい、新しい業務へスムーズに移行するためです。また、受入テストを行う際にも、このマニュアルは重宝します。
 

② 新システムに対するクレーム対策

新システム導入には必ず「抵抗勢力」が存在します。そのクレームの最たるものが「操作方法のマニュアルがない(からできない)」と抵抗し、批判するもの。マニュアルは「見るか見ないか」とは別に「有るか無いか」も問われます。
 

③ 業務プロセスの最適化と標準化

真に重要なのは、新システム導入をきっかけとして「業務改革」を行うこと。業務を合理化し、最適化したものをシステムで「固定」する。それをマニュアル化することで標準化が実現できるのです。
 

④ 問い合わせ削減

マニュアルがあることで、ユーザーが「自己解決」するケースが増えます。問い合わせの削減につながり、窓口の負担も軽減できます。そのためには、わかりやすさ、探しやすさが重要となります。
 

⑤ 引き継ぎと属人化抑止

マニュアルは「属人化」を防ぎます。新しく異動または入社してきた人への引き継ぎも簡単になります。属人化が解消されると、特定の人への業務集中がなくなり、業務量の平準化もできます。
 

どれも大事なので、業務マニュアルは必須ということですね。

マニュアルは誰が作るべきか?

では、本題です。マニュアルは誰が作るべきでしょうか?

先ほど触れた「システムマニュアル」であれば、ベンダーが作るのが合理的です。システムを作った張本人であり、システムに一番詳しいからです。

例えば、パッケージシステムであれば、ベンダーが「パッケージ標準マニュアル」を持っていることでしょう。それをもらうだけです。

ただし、ベンダーから受領するためには、成果物として定義されている必要があります。事前にRFP(提案依頼書)で「システムマニュアル」を成果物として要求事項に盛り込んでおくとよいでしょう。

しかし、本当に作りたいのは「業務マニュアル」です。

この業務マニュアルは、誰が作るべきでしょうか?

まず、「ベンダー」か「自社」かで言えば、「自社」です。

ベンダーは業務理解が浅いので、業務マニュアルは作れるはずもありません。新システム以外のことは、全く書けないでしょう。

業務マニュアルは、現場業務を熟知している人しか作れません。

つまり、業務マニュアルは「ユーザー」が作るべきです。

話は簡単じゃない

この説明をすると、情シスの皆さんは腑に落ちない顔をします(笑)

その理由は、ユーザーに丸投げしても「やってくれないだろうな〜」と思うからです。

ユーザーが「私が作りますよ!」と快く引き受けてくれれば、任せても大丈夫でしょう。しかし、これはレアケース。

大抵は、「え?私が作るの?」という反応です。この反応の場合は、ユーザーはマニュアル作成を押し付けられたと受け止め、そのタスクは必ず「後回し」となっていきます。

なぜなら、ユーザーはマニュアルを作ったことがないからです。急に言われても、どう作っていいのかわかりません。

そこで、情シスの出番です!

マニュアル作成はあくまでユーザー主体であるべきですが、情シスが「支援」するのです。

具体的には、マニュアルの「たたき台」を作っていきます。最低限のシステム操作を記載し、画面をペタペタと貼っていきます。業務知識が不足する情シスであっても、「業務フロー」を見れば流れは理解できます。

そのように作ったマニュアルの「たたき台」をユーザーに引き継ぎます。

「業務観点は素人なので、追記・更新をお願いします!」と渡します。

このたたき台は、完璧でなくていいです。あえて隙だらけのマニュアルを渡して、ユーザーに更新してもらった方が、ユーザーも着手しやすいでしょう。

要は、情シスがユーザーに寄り添い、一緒に助走するのです。重い腰を上げてもらうために、お膳立てをして、背中を押してあげるのです。

あくまで、マニュアルの主担当はユーザーです。そのスタンスは崩してはいけません。その前提の中で全力でサポートします。

理由は、その後の運用フェーズにもあります。そこでの問い合わせ窓口をユーザーに担ってもらいたいからです。マニュアルのメンテナンスもユーザーにやってほしいからです。

情シスが業務システムの窓口を担当すると、負担が大きくなります。業務知識が浅いので、ユーザーに聞いて回ることになり、伝言ゲームとなるだけです。全く合理的ではありません。

ユーザーが「一次窓口」となり、そこでインフラ関係やシステムエラーなど技術的な問題が出てきたら、情シスが「二次窓口」となる。これが運用フェーズでのあるべき姿です。

その運用体制を見据えて、情シスはマニュアル作成の「支援」に回るのです。

ファイル形式は?

ちなみに、次の質問もよくいただきます。

「マニュアル作成はExcel、Word、PowerPointのどれで作るのがいいですか?」

これに正解はないのですが、個人的にはWordをオススメしています。

① Word

Wordを推す理由は、見栄えを少しでも良くして、ユーザーに活用してもらえる確率を高めるためです。日本語を美しいインデントで整え、見た目でわかりやすく表現できます。

Wordは、表示された内容のままPDFにもできます。項目番号を自動で振り直してくれるのも便利。目次も自動更新できるので、見栄えが非常に整います。

ただし、Wordはクセが強すぎて、ユーザーが敬遠するのも事実(情シスでも敬遠する人います…苦笑)。ここでも情シスの出番です。まず情シスがたたき台をWordで作って、操作方法も含めてユーザーに引き継ぎます。更新であれば、ユーザーもWordで対応できます。要は「慣れ」です。
 

② Excel

Excelは「作りやすさ」が最大のメリットです。目的別にシートをたくさん作って、画面をペタペタ貼っていくだけで簡単です。現場にあるマニュアルで最も多いのが、このExcelで作られたマニュアルでしょう。
しかし、それは作り手の都合です。見る側にとっては「とっつきにくい」のが最大のデメリットです。見た目がチープに見えるのも難点です。
画面に吹き出しで説明が書かれていると、文字列検索に引っかからず、利便性も損ないます。印刷やPDFする際にはページをはみ出したり、変な改ページになったり、ページ総数も把握できなかったりします。
 

③ PowerPoint

PowerPointは、見栄えがよく、作りやすく、検索性も高いので、悪くはありません。ただ、ページを挿入した際に、全体の項目番号や目次を手動で修正しないといけないのはデメリットです。スライド形式で、画面を貼り付けると、どんどんページ数が増えていくのも難点です。
スライド単位で作れるのは便利ですが、後でつなげてみたら表現がバラバラということもよくあります。文章の「構造」や「一貫性」を保つという面では、PowerPointよりもWordの方が優れているといえます。

情シスはプロジェクトの先導役

情シスはプロジェクトを先導する役割があります。

ユーザーが不慣れな部分を先回りして、たたき台を作成したり、ノウハウを提供して進め方を案内したりします。

マニュアルもその一環です。

プロジェクトに不慣れなユーザーに寄り添い、プロジェクトを強力に支援していく。その積み重ねで、情シスの信頼性が少しずつアップしていきます。

だからこそ、情シスはPMOの経験値がモノを言うし、過去のプロジェクトはアーカイブしていつでも取り出せる状態にしておく必要があります。プロジェクトにレギュラー参加する情シスにしかできない芸当です。

貴社のIT部門・情報システム部門は、マニュアル作成を強力に「支援」していますでしょうか?

関連コラム

御社のシステム発注は、なぜ「ベンダー選び」で失敗するのか

情シスコンサルタント
田村 昇平

情シス(IT部門、情報システム部門)を支援するコンサルタント。

支援した情シスは20社以上、プロジェクト数は60以上に及ぶ。ITベンダー側で10年、ユーザー企業側で13年のITプロジェクト経験を経て、情シスコンサルティング株式会社を設立。

多くの現場経験をもとに、プロジェクトの全工程を網羅した業界初のユーザー企業側ノウハウ集『システム発注から導入までを成功させる90の鉄則』を上梓、好評を得る。同書は多くの情シスで研修教材にもなっている。

また、プロジェクトの膨大な課題を悶絶しながらさばいていくうちに、失敗する原因は「上流工程」にあるとの結論にたどり着く。そのため、ベンダー選定までの上流工程のノウハウを編み出し『御社のシステム発注は、なぜ「ベンダー選び」で失敗するのか』を上梓し、情シスにインストールするようになる。

「情シスが会社を強くする」という信念のもと、情シスの現場を日々奔走している。

著書の詳細は、こちらをご覧ください。