面倒でも仕様書は . . .

2002年12月 9日

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

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

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

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

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