■操作マニュアルを書くのは簡単だ

エッセイ、小説、詩などと違い、

操作マニュアルは誰でも書けそうな分野ですね。

「事実」を書くライターには、新聞記者・雑誌記者さんもいます。

現場に出かけて取材したり、

特定の人をインタビューして記事を書きおこすよりも、

操作マニュアルはもっと簡単に書けそうです。

目の前にある、ソフトウェアを淡々と操作して、

そのとおりに書けばよいのですから。

はい。そうなのです。

必要な操作を、時間の順番に書いていけば、操作マニュアルになります。


■じゃあ、マニュアルを外注する意味ってあるの?

テクニカルライターは、その誰でも書けそうな操作マニュアルを

仕事として請け負っています。

テクニカルライターにマニュアルを書いてもらう意味がわからない。

そう思われるかもしれませんが、、、

テクニカルライターは、

　(1)読者に、どうしたら操作手順をわかってもらえるか
　(2)どの順番に機能を並べたら、理解しやすくなるか
　(3)開発中で、原稿の締め切り直前でないとソフトが使えないのに
　　 どうやってマニュアルを書くか

などなど、マニュアルのことを専門に考えているので、

そこに存在価値があると思うのです。

(1) たとえば、、、
　　注意するのもタイミングが必要なのです

この間、リライトを依頼されたマニュアルは、

1. 新バージョンのインストール

2. 旧バージョンの削除

という順番に書かれていました。

そのとおりに操作してみたら、

2.旧バージョンの削除の途中で、この操作は新バージョンの
インストール前に行ってください。

と書いてありました。

この場合は、旧バージョンを削除しないと、
新バージョンをインストールできないのであれば、

旧バージョンの削除を先に書く必要がありますね。

ただ、新バージョンから買った読者には、
旧バージョンは関係ありませんから、
旧バージョンについては、読む必要はないという案内も必要です。

テクニカルライターは、マニュアルのことに専念しているので、
操作の条件、読者の条件など、分析してから原稿を書きます。

～～～～～～～～～～～～～～～

(2)よく使う機能、たまにしか使わない機能、１回しか使わない機能
　 何を先に書いたらいいかな

よく使う機能は、そのうち操作を覚えるから中でもいいか、
たまにしか使わないけど重要だったら、探しやすいほうがいいかな、
１回しか使わないなら、どうしよう。

目次を作るときに、試行錯誤します。
正解はありません。

製品の特徴や、最初に設定しないと動かないなどの動作条件、
探しやすさなど、条件はさまざま。
目次作りには時間がかかります。

～～～～～～～～～～～～～～～～～～～～

(3) 要求定義書、外部仕様書、製品企画書、
　　メールでの質問、インタビュー、ありとあらゆる手段を使います

開発中の製品で、不具合がまだたくさんある場合でも、
操作できるほうが、できないよりいいです。
そういうバージョンから使わせていただきます。

ですが、それすらできない場合は、
ソフトウェアに関連する資料をできるだけ入手して、
画面と画面のつながりをまとめて、
操作手順を推測します。

その上で、設計者に確認。

操作手順だけではなく、できる限りその結果も解明して
マニュアルを書いていきます。

ときには、決まっていない仕様を、マニュアル側で決めてしまうことも。(^^ゞ

Webアプリケーションの場合は、操作がある程度パターン化されているので、
Windowsなどのアプリケーションよりは、操作方法を推測しやすいです。


■淡々と300ページのマニュアルを書けるか

機能別に解説する、リファレンスマニュアルの場合、

同じ流れで、淡々と操作手順を書いていく必要があります。

決められた用語を使い、解釈がひとつになるように文章を書いていく。
300ページを１か月で書くとなれば、たぶんライターは複数になる。

誰がどこを書いたのか、その個性がでないように、
統一の基準、表記で書いていきます。

そういうことができるのも、
やっぱり、マニュアルを専門に書くライターだからだと思うのです。

～～～～～～～～～～～～～～～～～～～～

もう完成しているソフトウェアの操作手順なら、
誰でも書けるかもしれない。

でも、目次の作り方、情報の配置の仕方、納期との兼ね合い、
そういうさまざまな条件でも書ける。

それがプロの仕事だと思います。