テクニカルライティングをIT企業の社員として始めて、一年強が経った。
では、テクニカルライティングとはどのような仕事なのか。
ここにソフトウェアAがあって、「ソフトウェアAはIT資産を管理できる便利なものだ」、ということが分かっているとする。IT資産管理というのは様々な機能を包括する言葉だから、「ソフトウェアAはIT資産を管理できる便利なものだ」、というだけでは分かっていることにならない。それだけでは、何も書くべきものはない。
そこで、私はソフトウェアAを動かす。すると、自分の利用するアプリケーションについて、その使用状況を項目別に表にできるということが分かる。私はアプリケーションⅠについて表にする。アプリケーションⅡについても、アプリケーションⅢについても、と続けていく。
やがて分かるのは、アプリケーションⅤが帯域を圧迫している、つまり、ネットワークにおいて送ることのできるデータの容量を圧迫している、という事実。このアプリケーションVの使用を控えれば、ネットワークの速さが改善されるであろうということ。
手を動かし、実証すると、そのソフトウェアがどのように動くのかが分かる。どのように役に立つかも。
これは、写真で見ていた魅力ある絵や建物の前に実際に足を運んだとき、その細部を理解できた喜びに近いものがある。そして、それらの芸術は世界への理解に、あるいは自分への理解に、役に立つのだと実感する喜びにも。
そして、私はアプリケーション使用状況を表とする手順を、ユーザーへ向けて書く。ユーザーが特定のアプリケーションの表を作ることに成功し、特定のアプリケーションが帯域を圧迫していることを読み取り、解決策を講じ、そうして、そのソフトウェアは役に立ちそうではなく、実際に役に立つのだと感動することを期待して。
あるソフトウェアについての説明書を書きたかったら、実証だけでは足りない。その開発者や、開発者に近しい人の話を聞いたり、既出の説明書や、関連するソフトウェアの説明書を読んだりすることも必要になる。聞く話は、読む説明書は、英語であることも珍しくないかもしれない。
いずれにせよ、強く問いをもって当たらなくてはならない。
そのとき、どのように、という言葉がキーになるように思う。そのソフトウェアはIT資産管理の画面をどのように表示するのか。ユーザーの変更はどのように可能なのか。どのようなユーザーを変更できるのか。
あるソフトウェアについて追及すればするほど、問いは出る。次第にそのソフトウェアの深みが現れる。
あなたがテクニカルライターになれば、きっと対象の真価を追及する喜びが得られる。