マニュアルライター（マニュアルを書くことを専門とするテクニカルライター）は学び続けなければならない職業です（他の職業と同じように）。ここでは、マニュアルライター／テクニカルライターが学ぶべきことについて書きたいと思います。新しくこの分野に入ってこられるかたの参考になれば幸いです。

制作技術

制作技術は実践をとおして学ぶものではありますが、書籍は重要な情報源です。役に立つ本が世の中にたくさんあるなかで、わたしがおすすめする本を、あえて相異なる分野から挙げてみました。

  • 一般財団法人テクニカルコミュニケーター協会『日本語スタイルガイド』

    日本のマニュアル業界でおそらく最も読まれている、テキスト執筆用のスタイルガイドです。しっかり読んでおくべき本です。

  • 木下是雄『理科系の作文技術』

    有名な本です。私が印象的だったのは、漢字とひらがなのビジュアル的な違いが文節区切りを示すのに役立っているので、ある単語について漢字で書くか平仮名で書くかを統一することはできないと書かれていることでした。例えば、他のところで「雨が少ない」と書いていても、「比較的」に続けるときは「雨が比較的すくない」のように書いたほうがよいということです。いつもこのポリシーを採用できるとは限りませんが、なるほどと思いました。

  • 佐藤直樹＋ASYL『レイアウト、基本の「き」』

    ページデザインは難しいものです。この本をひととおり読むと、何に気を付けると美しく読みやすいページになるのかが分かります。

  • 佐藤洋一『技術英文の発想法』

    英語を書く機会はなくても、この本で言われていることはたいへん面白く、ためになります。いくつもの違った英訳が可能な日本語文の例は日本語ライターにとって教育的です。文章の背後や行間を読みながらのリライトはシャーロック・ホームズの謎解きのようで、読むだけで楽しいです（深読みしすぎの可能性もあると思いますが）。

  • 林千晶、高橋宏祐『Webプロジェクトマネジメント標準』

    マニュアルライターになると、自分の担当するマニュアルのプロジェクトマネジメントをしなければなりません（プロジェクトマネジャーが別に任命されている場合を除く）。マニュアルの企画段階から、デザイナーによるデザイン、自分の執筆、イラストレーターによるテクニカルイラスト作成、複数言語で作成する場合は翻訳など、さまざまな関係者の仕事をマネージしていく必要があります。

    世の中にプロジェクトマネジメントの書籍は多くありますが、どんなプロジェクトにも適用できるように抽象的な書き方がしてあったり、前提とされているプロジェクトが大規模すぎたりします。そのようななかで、ウェブ制作のプロジェクトは、サイズ、内容ともにマニュアル制作と似ているので参考になります。

  • 高橋麻奈『やさしいXML』第3版

    近年マニュアル制作業界ではDITAというXMLスキーマ／ボキャブラリが注目され多く使われていますが、DITAをやるのであれば、まずXMLの基本を身につけることをおすすめします。この本の最初の何章かだけ読めば十分です。（Xpath、XSLT、DOM、SAXの知識はとりあえずなくてもライティングはできます。）

  • 伊藤敬彦、吉村孝広『ドキュメント作成システム構築ガイド ー GitHub、RedPen、Asciidoctor、CIによる モダンライティング』

    XMLでライティングをするとなるとXML専用のエディターを使うのが通例です。XMLエディターは高価な場合も多いので、もっと簡単に、専用エディターなど用意しなくても構造化文書を作れないか、と多くの人が感じると思います。それを可能にしてくれるものとして軽量マークアップ（Markdown、AsciiDoc、reStructuredText、Re:VIEWなどの記法）が存在します。本書は、軽量マークアップで書いたドキュメントをプログラムのソースコードと同様のツールで処理してPDFやHTMLを生成する手法（Docs as code）を解説しています。

  • 山本陽平『Webを支える技術 HTTP、URI、HTML、そしてREST』

    以前は、マニュアルというものは、紙に印刷され、製品に同梱されるものでした（数年前までは、ソフトウェアのマニュアルでさえそうでした）。しかしこれからはウェブを使って情報を配信すること、つまりHTTP(S)に載せてユーザーに届けることがメインになっていくはずです。ウェブはどういうしくみになっているのか、基本から説明してくれます。

  • Krista Van Laan “The Insider’s Guide to Technical Writing”

    テクニカルライティングの方法論だけでなく、チームでうまく働くにはどうしたらよいか、自分のキャリアをどうつくるべきか、どうやって社外の人とのネットワークをつくるか、といったことにも言及しています。日本語のテクニカルライティングの本ではあまりこのような記述を見たことがありません。実践的なガイドです。

  • Mark Baker “Every Page Is Page One”

    これは、これまでわたしが読んだテクニカルコミュニケーション関連の本のなかで、最もおもしろかった本です。トピック志向的な考え方を、ドライブ感のある文章で説明しています。

    サーチエンジンによって全世界のウェブページのインデックスが作られ、分からないことがあったら真っ先にサーチエンジンで検索が行われる世の中では、読者は順繰りに「はじめに」「警告」「本製品の概要」などを読んでくれるわけではないということ、どのページも読者が最初にたどり着いて読み始めるページである（Every Page Is Page One）し、また、そのようなユーザー行動に合ったコンテンツを作らなければならないという哲学が熱く語られています。

ライティングをする対象の製品の知識（subject matterに関する知識）

ここで言っているsubject matterとは、掃除機のマニュアルを作るなら掃除機、石油プラントのマニュアルをつくるなら石油プラントのことです。当然ながら、その製品分野の知識を身につける必要があります。

その分野の書籍が世の中に存在するのであれば、どんどん買って読む、または分からなくても片っ端から眺める、ということが重要です。

このような本を読む場合、全体像を大雑把につかむことと、正確に詳細を理解することの両方が必要ですし、両方とも意味があります。いきなり正確な詳細を理解できなくても落ち込む必要はありません。入手できた情報源をながめ、一番最初に読むべきものはどれなのかを見定め、まずはそこから理解します。一番最初に読むべきものはどれなのかを見定めるためにも、できるかぎりたくさんのものを最初に眺める必要があります。

直接触れることができる製品が対象ならば、なんとかして触れる機会、取材の機会を得なければなりません。直接触れると理解が立体的になります。そこで五感を使って得たことは、仮にそのときには役立たなくても、将来役に立つときがやってきます。

英語

英語でテクニカルライティングができたら素晴らしいです。世の中の求人情報を見ていると、英語でライティングができる人には、日本語とは違う種類の仕事が見つかります。英語で書くことに努力してみる価値はありますが、いまの英語力が十分ではない場合、マニュアルのライティングができるレベルに到達するには相当な時間と努力が必要です。

ですが、英語でライティングするのでなくても、情報収集のために英語は必要です。製品の専門分野に関する情報、制作技術に関する情報、ライターとしての心構えやキャリアに関すること、いずれも、英語で情報収集すると、日本語にはないものが見つかります。海外のライターの仕事について知ると、彼我の違いに驚くこともあります。英語の情報が他の言語の情報より優れているということではなく、ただ、情報が多いということです。たとえばインドのテクニカルライターと中国のテクニカルライターとチェコのテクニカルライターが情報交換すると（シンポジウムとか、ウェブ上の掲示板とか）そこで使われる言語は大抵のばあい英語になります（本当はエスペラントだとよいのですけど！）。そうすると、そのような情報に触れるために、英語は確実に役立ちます。

英会話が必要になることもあるかもしれませんが、何よりもまず、英語を読めることが必要です。そして、読むだけであれば、物怖じするほど高度な読解力、語彙力は必要ありません。幸いにして、テクニカルコミュニケーションの世界は、難しい言葉を使わずに、簡潔に表現することを良しとする分野であり文化です。そのため、テクニカルコミュニケーション分野の書物の英語は、一般の新聞などの英語よりもわかりやすいです。（わたしは、自分の専門がこのような文化であって幸運だったと思っています。）

プログラミング

プログラミングが流行しています。みんながコードの書き方を勉強しています。誰がいつどのようにプログラミングを学ぶのが望ましいかは議論があります。ですが、マニュアルライターにとっては、プログラミングは確実に役立ちます。マニュアルライターの仕事の多くがテキスト、数値、あるいはイラスト、画像の処理なので、これら効率的におこなうための助けになるからです。なんらかのプログラミング言語を勉強することをおすすめします。

身近に活用することができれば、どの言語を勉強しても良いと思います。身近に活用する場があることが大切です。

  • Microsoft Officeを使う仕事が多いならVBA（Visual Basic for Application）

  • Adobe Illustrator、InDesign、Acrobatなどで自動処理をしたいならJavaScript

  • そして、上記と並行して、コマンドラインインターフェイスの基本的な使い方（cmd、PowerShell、bash）

  • テキスト処理をしたいなら、正規表現と、それを使うためのRubyまたはPython等の入門しやすい言語（あるいはgrep、sedなどのUNIXツール群）

さらに、プログラミングを勉強するとおまけとしてついてくるのが、「見通しのよい情報をつくる技法」です。記述の順序、インデントや空行による情報のまとめ方、名前の付け方、本質的なかたまりを関数として切り出すこと、どのように抽象化すればメンテナンスしやくなるのか（オブジェクト指向やデザインパターンやメタプログラミング）、といったことです。

わたしたちは、職業プログラマーになることを目指しているわけではありません。それ自体が売り物になるほど高品質なコードを書く必要はありません。また、現実問題として、マニュアルライターが業務で大規模なコードを書く機会はないでしょう。小規模なプログラムしか書かないとすると、実用的な意味ではオブジェクト指向やデザインパターンの必要性は小さいと思います。それでもこれらの技法は、プログラミングを勉強すると特典としてついてくる、いわば「おトクなおまけ」であると感じます。これらの技法自体がむずかしくも面白いものだからです。