マニュアル制作で発生する2つの副次的なメリット

サポート費用の大幅な軽減

サポート費用の大幅な軽減

「マニュアルは製品の一部である」という共通認識は開発スタッフなら誰もが持っているはずです。しかし、ソフトウェアを作成している最中にマニュアルの制作のことが頭にあるのは、プロジェクトリーダだけである可能性は大いにあります。エンジニアや他のスタッフは、製品がとりあえず動いて、発売またはカットオーバを迎えてから、この問題に気づくはずです。まして、その後のサポートに関して、製作の現場ではそれどころではない、というのが実情ではないでしょうか。
しかし、バグチェックも終わり、やれ出荷完了と、安堵の溜め息をもらした直後に、今度はユーザから頻繁に「問い合わせの電話」がかかってくるはずです。これに忙殺されては、次のプロジェクトにとりかかる時間を奪われてしまいます。
サポートセンターが整備されている場合でも、その設備、人件費にかかるコストは、マニュアル制作にかかる費用とは比較になりません。
せっかくよい製品、システムを開発したからには、開発時に考えぬかれた機能や特長をユーザに伝え、充分に利用してもらわなければなりません。できれば、なるべく早い段階からマニュアルの制作を手がけることが大切です。
「そもそもサポートに連絡してくる人の中には、マニュアルには触れもしない人が多い」という意見には、「マニュアル」の表紙、本文のグラフィックデザインやレイアウトを一新してみることをおすすめします。開発現場では想像もつかないことですが、ユーザには「細かい字で専門用語がびっしりつまっているマニュアルなんて開けてみる気もしない」という人も多いのです。「とにかくマニュアルを手にとってもらい、問題箇所を読んでもらってから、連絡をもらう」。これだけでも、サポートのコストは激減します。

簡単なユーザビリティテストとしての効果

簡単なユーザビリティテストとしての効果

優秀なテクニカルライターは、その製品の隅々まで針の穴を覗くように操作するプロフェッショナルです。同時に製品に触れる最初のユーザでもあります。同じ内容の入力項目なのに、場所によって名称が違うことを発見したり、バグを発見したりと、プログラムをチェックすることができます。プロジェクトのメンバーの中で、唯一ユーザの立場から客観的な視点を保てるとも言えます。テクニカルライターを単なる一スタッフとして見なすのではなく、作成しているプログラムの操作性(ナビゲーション)の「テストユーザ」として利用しない手はありません。
実際に、プログラムのメニューが緻密に構成されているとマニュアルの構成も論理的に整合性がとりやすくなります。反対に、マニュアルのページ構成(目次構成)が立てにくいプログラムは、ユーザから見ると使いにくいという事例を数々見てきました。また、経験豊かなテクニカルライターは、プログラム作成者より、さまざまなプログラム(それも社外の)を操作した経験をもっています。パラドクスはマニュアルを執筆する過程で、問題点を洗い出し、よりよいプログラムを制作するための協力者として、常に制作側にフィードバックしていきます。