Leo's diary

日々の生活の中で考えたこと、学んだことを整理して伝えるために書いています。

テクニカルライターという仕事

 SIerシステムインテグレーター)には様々な仕事があります。プログラマー、アーキテクト、テスター、インフラエンジニア、コンサルタント、マネージャー、営業…。

 ドキュメントを書く仕事も多いです。私はその中でも、「テクニカルライター」という仕事を半年ほどしてきました。書く対象はWebシステムの操作マニュアルです。以下に、具体的な仕事内容を記します。

  基本的には、システムを操作してみて、その動作を言葉で書いていきます。適宜、画面キャプチャーも載せます。そして同じ動作なら同じ書き方になるようにします。当然、語句統一もします。マニュアルの担当が変わったときに、前任者が書いた文章の校閲・編集をしたこともありました。

 システムに機能追加があるたびに、マニュアルにもページを追加していきます。またシステムの画面上の動作が変更になれば、マニュアルも書き換えます。ボタン名が1箇所変わっただけでも、対象の画面全部のキャプチャー画像と言葉を置き換えていきます。

 システムを操作するだけではわからない部分は、仕様をまとめた資料を確認します。また、不明点は開発チームに直接確認します。「このように書いてほしい」という指示・要望があることもあります。顧客から「マニュアルを読んだがわからない」というメールがあったときに、私の判断でマニュアルを書き換えることもあります。書き換えた内容は、顧客と調整を行っているアーキテクトに確認してもらいます。

 業務マニュアルではなくシステムの操作マニュアルであるため、原則として業務に関する部分は書きません。しかし、どのような使い方をするかがわからないと、操作ができない部分もあります。そこで必要に応じて、業務に関する部分を書くことがあります。そのような場合、業務に関する部分をどこまで書くかは難しいところです。適宜、アーキテクトに相談します。 

 やりがいは、「どのように書くか」を考えることです。正確にわかりやすくなるように、言葉を選び、文章構成を考えます。エンジニアならすぐにわかるような言葉でも、一般的な用語に置き換えます。深く考えるというのは、私の得意とするところです。また、「何を書くか」を考えることもあります。日頃から顧客からのメールや、開発チームの資料をチェックし、今のマニュアルに足りないところはないか考えます。情報を広く集めて整理するというのも、私の得意分野です。

 マニュアルはエンドユーザーの視点で書きつつも、仕様や動作に関する部分は開発者の視点で確認します。エンジニアとしてマニュアル用のアカウントを作ったり、マニュアル用のデータを作ったりもしました。エンドユーザーと開発者をつなぐ、というところがこの仕事の意義です。 

 最後に、私のキャリアとしては、一昨年大学新卒で就職してプログラミング研修を受けた後、インフラエンジニアとして働いていました。その後テスターを少し経験した後に今の仕事を任されています。ITエンジニアとして開発スキルを身につけるという観点からすると、大分遠回りなキャリアパスです。

 しかし、顧客の目に触れる文章をたくさん書く経験が積めたことは、無駄にはならないと思います。書くことを通して自分を表現したい、という気持ちに気づくこともできました。ブログを1年ぶりに再開することもできました。内向的な私が自己表現をする手段として、書くことはとても有効だと思っています。

 まだしばらくマニュアル執筆の仕事は続きますが、今後は開発の仕事をやる予定です。今回身につけた、必要な情報を整理するスキルを生かして働いていこうと思います。