何故か一般化しない制作基準

ブラックボックス

マニュアルで技術的な要件をどこまで詳細に説明するかにあたって、エンジニアと攻防戦を展開することがよくあります。
エンジニア側としては製品側の動作原理や挙動を正確に伝達して欲しいという思いがあるでしょうが、そういった情報はマニュアルに求められている情報とは違うのです。ユーザーは「だから結局どうすればいいワケ？」という疑問に答えてくれる情報をマニュアルに求めているわけで、ハードやソフトなどの製品自体はブラックボックスでも十分なのです。

もちろん摩訶不思議な機能制限など、ユーザーに疑念を起こさせるような問題についてはある程度のフォローが必要となります。マニア向けの製品では、技術的な詳細解説を加えてユーザーの満足心を高める工夫も必要でしょう。ですが、一般的な製品に自己満足のような説明を加えても、何の役にも立ちません。
マニュアルは製品仕様書ではなく、ユーザーに対して取扱情報を伝達するためのツールなのです。この程度の話はそろそろ説明不要の基本前提となって欲しいところなのですが、まだまだ現実は厳しそうです。（2000.11.06）

説明対象に依存したグルーピングはやめよう

情報をユーザーの視点で構成するということはマニュアル制作の基礎原則なのですが、いまだにこの原則が理解されていないという話をしばしば耳にします。どうも旧態依然としたマニュアル制作者にも理解していない人が多いらしいという、本当にお寒い状況のようです。
当研究所がことあるごとに主張しているように、デバイスやシステムなどといった、説明対象に依存する論理で情報をグルーピングしてしまうのはいい加減やめて欲しいものです。リファレンスマニュアルではこうした構成手法を取ることが効果的な場合もありますが、一般的にはユーザーの欲求とタスクを中心に情報を構成するべきでしょう。

何故でしょうか？
それは情報を説明対象に依存して構成すると、製品を詳しく知らないユーザーは必要な情報を探し出せないからです。この問題はソフトウェアのリファレンスマニュアルにありがちなのですが、知りたい情報がどのジャンルに属しているかをユーザーがあらかじめ理解していないと、必要な情報を探し出せないのです。これはとんでもない話で、「知る者は知ることができ、知らざる者は永遠に知り得ない」ような情報提供を行うものを、マニュアルとは呼びません。
一般のマニュアルでも、トラブルシューティング系の情報構成で説明対象に依存した情報構成を取っているものが散見されますが、これもこの問題のひとつの例ですね。トラブルを抱えたユーザーは、原因の切り分けができないのが普通ですから、ユーザーの目にする現象や疑問だけから原因を切り分け、必要な情報を探し出せるようにトラブルシューティングの情報を構成する必要があります。そうでもなければ「トラブルシューティング」する前に、ユーザーがシューティングされてしまうようなことになりますので . . .（苦笑）。（2000.11.20）