【わかりやすいマニュアルの作り方】第10回　 目次構成案はテストが必要？

【わかりやすいマニュアルの作り方】第10回です。
やっと２桁といったところです。

少しずつ継続して読んでくださっている方も増えていらっしゃるようなので、改めて気合いを入れていこうと思います。

前回までで、まずは目次構成案の叩き台ができたとします。
しかし、これはまだ完成ではありません。
目指す目次構成案はそのままライティングにかかれる完成度のものです。
ここで妥協して中途半端なものを作ると、かえって「目次構成から修正」というもっとも手間の大きい修正・手戻りが発生してしまいます。これはスケジュールの大幅な狂いと、作業の増大を意味します。
では、そうならないようにするにはどうしたらよいでしょうか。

真っ先に思いつくのは「綿密にチェックをする」という方法です。しかし正直なところ…この方法は大概は役に立ちません。せいぜいが誤字・脱字が減る程度です。これはこれで重要なことですが。

なぜなら、目次構成案をつくる人も、チェックをする人も立場が同じだからです。
目次構成案をしっかりするという作業は論理的にはデバッグと同じです。デバッグをする際にコードのトレースだけしかしなければ、必ずバグは残ります。

デバッグはどのようにして行う？

では、デバッグはどのようにして行うでしょうか。
デバッグは条件を設定して（テストを設計して）、テストを実行します。
これと同じことを行えばよいのです。
テストは、異なった環境下での振る舞い（たとえばOSのバージョンのちがい）や、正常値以外の値が入力された場合（入力エラーの対処）、異常系の動作（「こんなときには・困ったときは」など）を想定して、チェックシートを作成してチェックしていくわけです。
このチェックシートは制作者やクライアントごとに異なってもかまいません。
続きます。