「マニュアル」についての諸相
「マニュアル」という言葉で，読者は何を連想するだろうか。
(1) 作業の手順書
(2) 接客のための決まりごと
(3) 取り扱い説明書
(1) では，「マニュアル通りにやりなさい」とよく言われるだろうし，(2) では，逆に「マニュアル通りではだめだ」と言ったりする。(3) では，「マニュアルがないからわからない」ということがよくある。
(1) と(2) は似たようなものである。(2) は接客の手順書なのだから。しかし，手順書は接客とは限らないので分けておいた。
ロバート・ツルッパゲとの対話（ワタナベアニ著：センジュ出版）に，面白い話が載っている。
俺はみそ汁が苦手です。外食で出されたモノを残すのは勿体なくてイヤなので，いつも注文するときには「申しわけありませんが，お味噌汁はいりません」と高らかに宣言するのです。〜 中略 〜
あるとき，とんかつ屋さんに行くと，「はい，お味噌汁なしでお持ちしますね。かしこまりました」とハキハキ答えてくれた女性店員（ヤマダ・仮名）がいたので俺は期待しました。ヤマダなので大丈夫だろう。やってくれるだろう，と。料理が届くと，味噌汁がついていないので，「よっしゃ，よくやった」と心の中でホメようとした，その瞬間です。ヤマダは「ご飯と味噌汁のおかわりは無料になっておりますので，お申し付けください」と言ったのです。
ーサバティーニとスターバックス
ありそうなことだ。スーパーで，袋を持っているのを目にしながら「レジ袋はごいりようですか」ときく店員とか。どうやら，「マニュアル通りにやりなさい」がかなりたたき込まれていて，瞬時の判断ができないようである。これは「マニュアル」がよいかどうか（よく書かれているかどうか）の問題ではなく，運用の問題だろう。
(1) の「作業の手順書」に戻ろう。
何かの手順を決めたときに，「マニュアルにしておこう」ということがよくある。たとえば，町内での不燃物回収を例にとると（町によって異なるだろうが）
１．業者が回収のためのコンテナを持ってくる。
これとは別に，仕分け用に作った一斗缶があるので，それを出す。
２．立て札を立てる。
３．スプレー缶は穴があいていることを確かめ，空いていなければあける。
といったようなことが，業者による回収後まで何項目かあり，初めて担当する人のために文書にするのである。これを「マニュアル化」というだろう。
このような場合は，いかに要領よく，初めての人にもわかるように書かれているかが問題だが，まあ，たいしてトラブルが起きることもないだろう。使う人も町内の人と限られている。
これに対して，(3) 取り扱い説明書 は，少し趣が異なる。取り扱い説明書といっても，家電製品の取り扱い説明書（通称トリセツ）は，あまりマニュアルとは言わないだろう。最近は家電製品のトリセツは簡素化されていて，あまり読まなくても使えることが多い。使うとしたら，エアコンの掃除の手順くらいだろうか。これも「マニュアルはどこ」とは言わず，「トリセツはどこ」というだろう。
一方，パソコンなど，OA機器関係では，何も説明がないと使い方がわからず，この場合は「マニュアル」という方が多い。サーバの使い方や表計算ソフトウェアの使い方など，マニュアルがないとわからない。これらについて解説した本が「マニュアル本」として売られているのはご承知の通りである。
もう一つ，レファレンスマニュアルというものがある。プログラミング言語の使用説明書あるいは仕様書といってもよい。記法上のルール，組み込み関数の使い方などが書いてあり，かなりのページ数になる。かなりの量の索引もついている。これが PDF化されていると，索引がなくても検索できるので便利だ。
プログラミング言語では，記法上のルールは必須で，言語により少しずつ異なるので最初に確認することになる。組み込み関数については必要になったときに参照（レファレンス）すればよい。「必要になったときに」でよいのだが，ある程度は目を通してどんな関数があるかを知っておくとよい。これは目次でも索引でも一覧表でもよい。それらのないマニュアルはきわめて使いにくい。
PDFになっていると，ある項目から関連項目へのリンクが張れるので便利だ。とはいえ，書く立場でいうと，リンクを張るのはそう簡単ではない。すべての項目が頭に入っていなければならないからだ。それだけでなく，実際に使い込んで，それぞれの項目の関連性を知っておく必要がある。本来，これは開発者が行えばいいのだが，開発者から仕様をきいてユーザー（マニュアル担当者）が行う，という方法もあり，こちらのほうがユーザーにとって使いやすいマニュアルになるだろう。
しかし，そこまであれこれ工夫してマニュアルを作っても，それでユーザーが「読む」かどうかは別問題である。
筆者は高校で「情報」の授業を担当し，簡単なプログラミングも教えているが，生徒が「マニュアルを参照しない」という状況にたびたび遭遇している。テキストでは，使用する組み込み関数についてはその都度解説しているが，基本的な書式については，はじめにまとめてやっている。その部分が「マニュアル」になるわけである。「これはどう書くのだったかな」となったら，その部分を参照することになるのだが，それをしないのである。
そういるスキルができていないといってもいいだろう。今，テキストでやっていることにだけ目が行って，前にやったところに戻る，というスキルがきちんと育っていないのだ。数学や理科の学習ではそれ（前に戻って復習する）が必須なのだが，そういうスキルが育っていないことが実習では露呈する。
よくあるトラブルについては「トラブルシューティング」として，はじめにまとめたものを実際にやってみているのだが，いつになっても「小文字が出ません」（大文字モード）とか「数字になってしまいます」（Numモード）というヘルプが出るのだ。トラブルシューティングを参照する，ということに思い至らないのである。
プログラミング言語の話に戻すと，たとえばある処理を繰り返すための書式がある。はじめに実例つきでこれをやっているのだが，課題で繰り返しが必要になったときに，さっぱり手が出ない生徒がいる。「マニュアルを参照」しないのである。
プログラミングに限らず，「わからなかったら前にやったことや，それについての説明を参照する」ということが当たり前にできるようにすることは，卒業後の生活にあたっても大切だろう。
大切だが，それをどうやって身に付けさせるかはそう簡単ではない。生徒から質問が出たときに「○○に書いてあるよ（参照しなさい）」といえばよいのだが，そうすると「教えてくれない」と思われて「次には聞かない」となるのがオチである。かといって，その場で説明してしまうと，自分で「参照」するというスキルが身につかないまま終わってしまう。実に悩ましいところである。