メインフレーム全盛時代にOSの設計、それを踏まえてのSEへの技術支援をしていましたが、マニュアルが付いて回りました。書く側でもありましたが、如何に正確に書くかが問われました。マニュアルのチェックをする専門の部署までありましたが、ユーザーのシステム部門がマニュアルを見て操作したのにトラブルが起きたとなれば、その責任を問われるからでしょう。マニュアルは製品の一部という標語まであったくらいです。
中国人民銀行、中国銀行のシステム部門への技術支援で一時期北京に駐在していましたが、中国人技術者の中の優秀な人物が、マニュアルに書かれていることを全て実際にやってみたことがありました。この時、マニュアルに書かれていたようにやったのに、書かれているような結果が得られなかったという問題が出たことがありました。原因は、ピリオドがなかった、『,』がなかったというアセンブラ言語ならではの問題でしたが、パソコンが目の前にある今とは違い、メインフレームの時代に例としてマニュアルに載っているコードを実際に書いて動かしてみるとは思わなかった･･･これをきっかけにマニュアルはおまけについてくるものではなく、ハードウェア、ソフトウェア同様に製品であるという意識を持とうということになり、マニュアルの専門部署ができたきっかけの一つになりました。
そのマニュアルですが、朝日の朝刊題字下に毎回掲載される折々のことばというコラムにこんなものがありました。
正確さばかりを求めると記述が増え、分厚くなって読む気が失せる。知り合いに聞いた方が早い！マニュアルを読み込むよりも良い友人を持つ方が大事という評論家らしい主張です。彼の主張のうち、後者はその通りですが、明らかに間違っているのは後者の読む気が失せるです。
彼のいうように、分厚いマニュアルを見るといささか戦意を消失しますが、マニュアルはその性質上、小説のように全部を読むのではなく、知りたいところだけを読めば済みます。ただし、問題発生時の言い訳のために免罪符的にあれもこれもと書くと膨れてしまいます。歯切れよく要点を書き表せる文章力が求められますが、全てを文字で言い表そうとするとかなり大変です。私は、適宜絵やグラフを使いました。もちろん文章にも気を使ったのはいうまでもありません。てにをは／適切な接続詞／形容詞の位置／文章の長さは、特に気を使いました。マニュアルは小説や評論ではないので、情緒的な言い回しや冗長な表現は避けました。
もっともこれは、マニュアルに限りません。仕様書を書くときも同じです。SIerに渡した仕様書が誤解されないように書きますが、下手な文章では意図が伝わらないばかりか、誤解を招いてしまう怖れがあります。例えば、ある薬剤を処方しようとした時、その薬剤がシステムに組み込まれた薬剤マスタにないものだった場合の処理をどうするかを図解すると下図のようになります。この図が持っている情報量（エントロピ）を文章だけで誤解なく説明するのは至難の業、私には自信がありません。
マニュアルに話を戻します。配信されてくる様々なニュースがありましたが、こんなものがありました。
作業手順書、業務手順書などと言われるマニュアルですが、品揃え的に作ることが多々あります。品揃え的と呼ばれるのは、一度作ってお終いというお飾りと言う意味です。『マニュアルはあるか』に対して『あります』という程度の位置づけで、業務、作業の変更など、本来マニュアルに反映すべき事柄が発生しても反映せず、実際の業務／作業とマニュアルに記載されている内容との齟齬が発生していることが少なからずあります。それでも日々の作業は問題なく処理されているので、誰も気にせず放置されているのが現状のようです。『うちはしっかりやっている』というところも、タイムリな更新をしているかは疑問です。もちろん、作業変更などマニュアルに反映すべきことが生じた際の手順に『マニュアルに反映すること』と明記されていて、そこに✔が入らないと変更が最終承認されないというフローがあり、順守されていれば完璧･･･ではありません。❝後でやる❞ので、✔をつけておこうという場合です。
マニュアルを書く人には、次のことを旨とし、以下の項目に習って血の通ったマニュアルを書いて欲しいものです。
①現場を観察する
②現場の作業実態を理解する
③現場からヒアリングする
④ヒアリングしたことを現場に確認する
⑤現場の人に伝わる書き方をする
⑥マニュアルから逸脱すると起こり得る可能性のあるリスクに言及する
これ以外にもありますが、少なくとも、現場を知らずに机上から現場を想像して書いてはいけません。信頼し、使ってもらえる実用的なマニュアルを作れるようになりましょう。
※質問はosugisama@gmail.comにどうぞ！
※リブログを除き、本ブログの無断転載、流用を禁じます。