雑感いろいろ（書庫）（9）

マニュアル制作的な文書コンサル業務とか

さてここのところ、文書コンサル関連の業務に携わることが多いのです。文書コンサルといってもそれほど大げさなものではなく、業務上必要とされる内容は十分網羅されているのかを実際の文書ベースで評価したり、記載情報の標準化や構造化を含めた業務文書開発のための枠組みづくりを支援したりというようなものです（ぼかした言い回しですが、業務直結系の話なんでご容赦ください）。SI系の会社からご依頼いただくこともある関係上、制作環境だけでなく文書システムに対する知識が要求されることも多いです。

この辺の業務に関してはマニュアル制作系のスキルを持った人材であれば十分対応可能だという感触はこれまでも持っていたのですが、まあ何とか対応できているようです（大汗）。ただ気になるのが、こうした業務を依頼してくださるお客様が口を揃えて「こういう仕事をできるところが少なくて . . . 」とお話になることです。どうも現場と開発／制作プロセスの両者をつなぐ役割を担当できる会社／人材が、少ないようなのです。マニュアル制作に携わっている人材にはこのような仕事はうってつけのはずなんですが、これは一体どうしたことでしょう？

上流／下流という言葉はあまり好きではありませんが、開発プロセスやメーカーのマニュアル制作部門などの上流で決定された事項を前提として無条件に受け入れ、その枠の中でマニュアル制作（文書開発）をすれば十分であると考えている人が多いようです。日々の業務から前提自体のあり方を問い直したり、前提の構築のされ方自体を改善したりしようという問題意識の持ち方は十分可能なはずですし、そのような問題意識なくして（品質の高い成果物の制作という）問題解決は得られないはずなんですが、う〜ん。いっとき「仕様書の読めないライター」が問題になったことがあるんですけど（今もですかね）、なんか問題の根底は共通のような気がします。まあこれも漠然とした、勘みたいなものなんですけど。　（2002.10.28）

MECE的マニュアルの限界

世の中は論理思考ブームのようで、MECE（mutually exclusive, collectively exhaustive）つまり「互いに重ならず、すべてを網羅する」というキーワードを聞く機会が増えました。

そもそも論理思考がブームで良いのか？という話は置いておくとして、実はこれまでの紙媒体のマニュアル制作の基本精神とは、まさにこのMECEだったんですよね。つまりページ増を防ぐために情報は重複させずに、すべての機能説明や注意を網羅しなければならない、という訳です。経験を積んだマニュアル制作者が論理思考や情報の構造化に強いと言われる所以は、ここにあったのです（最近はこの能力の低下が目立ってきているようですが）。

なんですが、メーカーなどの情報の提供側からするとMECEで良くても、ユーザー側にはとんでもない話となります。これは当たり前の話で、情報が他の見出しと重複しているかどうかなんてユーザーには関係ない訳で、とにかく直接必要な場所を見るだけですべて完結していて欲しいというのは当然の欲求ですよね。マニュアルではなく攻略本が評価されるのは、このような側面もあります。ここまではMECE的マニュアルのME部分の問題と言えるでしょう。

また、マニュアルが些末な情報まですべてカバーすることで、情報の伝達効率が低下するという問題もあります。以前取り上げたこともありましたが、操作の柔軟性という名目で複数の操作方法を提供しているような機器の場合、すべての場面ですべての方法を説明させようとするメーカーのなんと多いことか。結果として重要な情報が埋もれてしまうだけでなく、ユーザーの読む気を損なったり、さらには情報量増によるコスト増につながったりとロクなことがありません。これがMECE的マニュアルのCE部分の問題です。

さすがにこの辺の問題にはマニュアル制作者も気付き始めていますので、情報量の制約が少ない電子マニュアルでは、MEなんか無視してトピック内で情報完結するのが基本となっています（重複を避けてリンク参照なんて、誤操作を招くので愚の骨頂です）。紙マニュアルでも、導入編などの最優先で伝達効率が要求される領域に関しては、重複を厭わずに情報完結を狙うことが増えています（当研究所もこの方法で構成を組んだことがありますが、好評でした）。

しかし、CEの壁はまだまだ厚いのが現実です。追加した機能はすべて説明を入れたがる表面的なスペック重視も相変わらずですし、些末なユーザークレーム回避のための逃げ道という発想もなかなか減りません。最終的なユーザーの利益と伝達効率を考慮した上で、メーカーがユーザーに提供しなければならない「すべての機能の情報」とは一体なんだろう？ということをゼロベースで検討することなしに、この問題はおそらく解決しないでしょう。

論理思考の考えかたとしてのMECEはともかくとして、マニュアル制作の考えかたとしてはMECEはもう限界！というお話でした。　（2002.11.12）

面倒でも仕様書は . . .

マニュアル制作には仕様書（特に外部仕様書）が必要不可欠なのですが、良いドキュメントが支給されることは少ないのが現実です。主な問題としては、記載量が少なすぎることと、内容がアップデートされていないことの二点にあります。

仕様書の記載量が少なすぎる問題がある場合に共通しているのは、物理的なボタンにせよ画面上の各種コントロールにせよ、オブジェクト単体の機能仕様しか記載されていないことです。リファレンスマニュアルならこれでもなんとかなりますが、ユーザータスク中心のマニュアルを起こすには情報が決定的に不足します。これは実際にユーザーがあるタスクを行う上で、どのような操作の流れの上に特定のオブジェクトを利用するのかが、まったく理解できないからです。他のUIからの連想でカバーできることもありますが、経験に基づいた職人芸的解釈に依存する文書が仕様書というのはいかがなものかと。まあ外部仕様書に記載して欲しい情報内容というのはだいたい決まっていますので、何かの機会にまとめて取り上げたいと思っています。

内容がアップデートされていないという問題に関しては、言うまでもないですよね。このようなケースでは現物優先でと指示されることが多いのですが、現物自体がβ程度の出来だったりすると、もう何が何だかわからない世界に突入です。つまり仕様書も現物もどちらも最終仕様として信用できないわけで、これでは一体何をよりどころにしてマニュアル制作をすれば良いのやら。この場合、担当者間でも意志疎通が取れていないことが多いので、本当に泣きが入ります。

このような問題の背景としては、ソフトウェア開発の（ウォーターフォール型から）反復型への移行という理由がありそうな気がします。どうも「文書（仕様書）重視はウォーターフォール型の文化だから、反復型なら現物重視（文書軽視）でOK」という思い込みまでもが広がっているようで . . . 。でもこれはすごく変な話で、文書が残っていないと実装前の操作性レビューもできないですし、開発プロジェクト全体を通した成功／失敗例の教訓となる、意志決定プロセスの記録も残らないことになってしまいます（反復型の開発に関しては「仕様は逐次変わるものだから、最初から最終仕様を意識しなくてもOK」のように、外野からすると設計段階での熟慮を最初から放棄してるのか？としか思えないとんでもない認識も出てきているようなのですが、これは別の話なのでまたの機会に）。

どうも仕様書（特に外部仕様書）の問題は「マニュアル制作者のためだけに仕様書を支給するのは面倒だから、口頭伝達で良いじゃん」という認識にありそうなのですが、これは大誤解と言わざるを得ません。マニュアル制作者だけではなく、実は営業担当者やサポート担当者など、製品に関わる多くの人たちも仕様書に記載されているべき情報を把握する必要があるのです。機能の特徴や想定利用場面、機能制限などを知らずして、営業／サポートできますか？ ほら、絶対に文書化が必要でしょう？　というか、そもそもしっかり形に残らないような仕様の決めかたなんかしてるから、いつまでたっても製品の操作性が（以下略）。（2002.12.09）