ライターになりませんか？ #NSStudy No.4 参加メモ - 2014/09/26(木)

2014/09/26(木) 19:30-22:00に行われた『ライターになりませんか？ #NSStudy No.4』に参加してきました

以下、講演中に取ったメモをそのまま貼り付けておきます。

イベントの募集概要（募集サイトより引用）

@IT, BuildInsider など技術情報サイトに自分の名前が載ったらかっこよくないですか？ 自分の考えや新しくキャッチアップした技術を広く知ってもらうためにブログだけじゃなくて、技術サイトにも拡げて見ませんか？

実際にご活躍中のテクニカル・ライターをお呼びして、テクニカル・ライティングのコツや心がけ、フローなどをご説明いただきます

これで明日からテクニカル・ライターだ！

1. すべてわかるテクニカル・ライティングのコツ

• 当日の資料は、事前に公開されていました
  • https://dl.dropboxusercontent.com/u/228990/itmediawriting.pdf
• [P6～P8] なぜメディアで書くのか？
  • ［1］調査した技術情報を、それを必要とする人と共有するため
  • ［2］技術者としての個人／会社のブランドを確立するため
  • ［3］技術についてより深く学ぶため
  • ［4］おこづかいを稼ぐため
  • ［5］複数のメディアに展開して稼ぐため
    • 連載記事で稼ぐ→本で稼ぐ というサイクルがある
  • ［6］文章を書くスキルを向上させるため
  • ［7］好きだから書く
• [P9] メディアの現状について知ろう
  • ブログ系（メモやQAサイトを含む）の変遷
    • ブログ最盛期： 2005～2010年
      • 実はこの頃、Webメディアも絶好調
    • まとめ記事最盛期： 2009～2012年
      • ブログの人気は、個人から組織運営もの（GIGAZINEなど）へ
    • ロングテール続伸中： 2012～2014年
      • Qiitaなどでニッチ情報も充実ブログ系とメディアは二極化
• [P10] ブログ系（メモやQAサイト含む）の変遷
  • ※あくまで個人的な印象で、裏付けデータはありません
  • ブログ最盛期： 2005～2010年
    • 実はこの頃、Webメディアも絶好調
  • まとめ記事最盛期： 2009～2012年
    • ブログの人気は、個人から組織運営もの（GIGAZINEなど）へ
  • ロングテール続伸中： 2012～2014年
    • Qiitaなどでニッチ情報も充実ブログ系とメディアは二極化
• [P11] 【出版社】現状の書籍の出版数と印税
  • IT系も出版不況： 1990年代からずっと下降
  • 初刷： 現在は、2000～3000部程度？
  • 印税： 8％前後が相場？
    • 計算例：初刷（2500部）×価格（3800円）×印税（8％）＝76万円
  • 年6冊執筆でやっと生活できるレベル？
    • ※ 通常、本の執筆には3カ月～半年はかかる
• [P12] 印税についてもう少し詳しく
  • 出版社ごとに異なる主には以下の支払い方法
  • 発行印税： 刷り部数に応じた印税
  • 売上印税： 実売部数に応じた印税
  • 売上印税＋最低保証部数： 本の実売部数が少ないと、印税が安くなってしまうのを救済するため、最低限の部数分の印税支払いを確約する
• [P13] 雑誌の状況
  • 2000年代： IT系雑誌の休刊が相次ぐ
    • 参考： f/x ITメディア・タンク http://www.fx-it.com/blog/magazine/
  • 発行部数： 最盛期は5万部前後？
  • 原稿料：Webメディアとあまり変わらない？
    • 『WEB+DB PRESS』『Software Design』『日経ソフトウェア』『日経Linux』
• [P14] 【WEBメディア】WEB記事のPV数と原稿料
  • 成長期： 2001～2008年出版不況と対極的
    • プログラマー向けで2万PVを超えることも
  • 停滞期： 2009年（リーマンショック後）
    • ※広告市場の影響
  • 回復期： 2010～2014年ほぼ回復したが、人気になるコンテンツの変化、読者の情報への接し方などが変化した
    • 新着記事の場合、8000～5000PV程度 1/2～1/4のPVという印象
• [P15] WEBメディアの原稿料
  • ※メディアによって異なります。 1本単位で価格を決めているところも
  • Build Insiderの場合： 文字数で算出
  • 最長の文字数： 7500文字＝ 4～5万円程度
    • Wordで20ページ分くらい
  • 月10本執筆でやっと生活できるレベル？
    • ※ 通常、記事執筆には3～5日はかかる
  • タイアップ記事は、1本10万円前後の原稿料
• [P17] メディアで執筆するには... 本や記事を執筆するきっかけの作り方
  • ［1］知人からの紹介
    • コミュニティ参加、イベント登壇などで仲間を増やす
  • ［2］ブログで積極的に情報発信
    • ある分野に詳しい技術者としてアピールする
  • ［3］出版社やWebメディアに応募する
    • 募集窓口から／募集していなくても／執筆グループ所属など
• [P18] ［WEBメディア］執筆から公開までのフロー
  • ［1］編集会議で企画を通す
    • 記事タイトル／概要／読者ターゲット／アウトライン案と連載回数
  • ［2］執筆する
    • 原稿提出の締め切り： 2週間後～1カ月後程度
  • ［3］編集者が、査読・編集・校正
    • 複数人でまわしている
  • ［4］著者校正
  • ［5］記事公開
• [P20] タイトルの作り方
  • ［A］SNSなどで話題になり、短期的に大ヒットさせる
  • ［B］検索エンジンで、長期間クリックしてもらう
  • ［C］学習型のコンテンツで、連載を最初から最後まで読んでもらう
• [P21]［A］SNSなどで話題になり、短期的に大ヒットさせるタイトル
  • まとめ系： 「○○のまとめ50選」「◇◇に役立つ7つの機能」
  • 新機能系： 「○○の新機能」「◇◇を試してみた」
  • “誰にどんなメリットがあるか”の説明修飾 ※ここがポイント
    • 「Web開発者の生産性が5倍になる、Chromeの新機能」
• [P22]［B］検索エンジンで、長期間クリックしてもらうタイトル
  • 説明的な長いタイトルは検索に不向き
  • 検索ヒットしやすく、クリックされやすく
  • 検索キーワードが全て入っていること
    • 例：「jQuery UIのProgressbarを利用する方法」
  • ただし、検索エンジンの順位アルゴリズムはよく変更されるので、あまりこだわりすぎない方がよい
• [P23]［C］学習型のコンテンツで、連載を最初から最後まで読んでもらうタイトル
  • ［A］や［B］のようにタイトル付けをすると、連載内の各回でタイトルがバラバラになり、まとまりや連続性が失われる
  • 連載全体をまとめて教科書的に読んでもらうのが目的なら、連載内での連続性やまとまりのあるタイトルを付けた方がよい場合もある
• [P24] アウトライン（見出しの箇条書き）の作り方
  • 「何を書きたいか」「記事をどうまとめたいか」で変わってくる
  • 参考にしたい記事の見出しレベルをまねてみる
    • 例「プログラミングやマークアップで特に役立つ、Sublime Textの標準機能 http://www.buildinsider.net/small/sublimetext/02 」
      • テキストエディターとしての機能
      • Sublime Textが提供している機能
      • 選択の拡張（Expand Selection）
      • マウスを利用した選択
      • 複数行の選択
      • ……以下、省略……
• [P26] 本や記事を書くのに文章スキルは必要か？
  • 「文章スキル」＜ 「技術スキルや知識」
  • 文章が分かりにくくても編集者が改善可能
    • ※もともとの記事内容が良くないとどうしようもない。もちろんあまりに編集の手間がかかる場合は……
  • だから必要以上に恐れる必要はない。「準備は整った」と考え、今すぐ始めよう！
• [P27] 文章にはTPO（時間／場所／場合）がある
  • 文書の目的ごとに、文章の表現方法は異なる
  • 小説： 物語を想像させるために、比喩や風景描写、会話などを駆使する
  • ニュース： 日時場所／出来事（事実）から、その具体内容に入っていく
  • マニュアル： 機能や手順を省略なく順番通りに説明する（辞書的）
  • 技術解説記事： 技術内容を分かりやすく解説する（読み物的、教科書的） ※ここがポイント
• [P28] 読者ターゲットごとに書き方は異なる
  • 例えば「DNS」関連の技術解説記事：
    • 初心者向けであれば？→ DNS自体の概説が必要。マス向き
    • 技術に詳しい人向け？→ DNS概要は省略して詳細に。ニッチ
  • だから「誰に対して、何を伝えたいのか」を執筆前に明確にしておいた方がいい
• [P29]「技術解説記事」に典型的な執筆方法？
  • 原則はあるが、統一的なルールやテンプレートがあるわけではない → 文章は人それぞれ
  • なお、本や記事の執筆の数を多くこなそうとすると、自分自身に、文章のテンプレートのようなものができてしまい、どれも同じような書き方になってしまう。これはあまり良くない
    • → 技術解説記事はあくまで読み物。記事ごとに独自性や遊びが欲しい
• [P31] 分かりやすい記事とは？（1）
  • 「文章の構造が分かりにくい」のと、「文章表現が分かりにくい」のは違う
    • ※文章構造とは、起承転結などの文章全体の論理構造のこと
  • 編集者が文章表現を修正するのは比較的楽。構造を直すのは論理構造の再構築なので大変
  • 分かりやすい文章構造を作るためのテクニックは存在する
• [P32] 分かりやすい文章構造にするテクニック
  • 『考える技術・書く技術―問題解決力を伸ばすピラミッド原則』
    • 文章構造に自信がない人は、この書籍を一読することをお勧めする
    • 分かりやすく物事を人に伝えようとすれば、例えば概要→詳細→事例→反例などのように、物事を順序立てて説明する必要がある。こういった論理立てのテクニックを、「ピラミッド原則」と呼んでいる
  • 1記事＝1テーマにする（ピラミッドの頂点）この点でも、アウトライン作成は重要
    • ※自分の場合： アウトライン作成 → あとは上から自由に執筆
• [P33] MECE： 重複なく・漏れなく（ミーシー、Mutually Exclusive and Collectively Exhaustive）
  • 論理構造に問題があると、文章全体の中にダブりや漏れが発生しやすい
  • それらを極力排除するように努力することで、過不足のない効果的なドキュメントに仕上がる
• [P35] 分かりやすい記事とは？（2）
  • 読者の知識レベルを意識しよう
    • 幅広い読者がいるマスがターゲットなのか
    • それとも専門家が主な読者なのか
  • 読者の知識レベルで、説明の強弱を変える
    • 仲間うちで通じるような簡潔な書き方が適しているのか
    • 例えば「計算式／コードを出した方が分かりやすい」など
    • マス読者用に、せめてキーワードにはリンクを入れよう ※ここがポイント
• [P36] 分かりやすい記事とは？（3）
  • 読み間違われにくい文章にしよう
  • 読者は多様。自分と知識・経験は同じではないので、必ずしも同じように読んでくれるとは限らない
  • 誤解や誤読が生まれそうなところを極力排除する
  • 自分に取って当たり前のことは、省略しがちなので注意
    • 例えば「データはログに保存される」。どこのログ？
    • 主語の省略、目的語の省略など、省略してOKか考える
    • 語句は正式名称にする。画面表記と完全一致させる
    • メソッドなのかプロパティなのかなど明示する
      • → こういったところでつまずくと、分かりにくいとなる
• [P38] 意味のない冗長な言い回しを排除する
  • 「することが」「を行う」などは回りくどい
    • 確認することができる → 確認できる
    • 確認を行ってみよう → 確認してみよう
    • これらには特段の意味はなく、言い回しが長いだけ
    • ※リズム感が悪くなる／ニュアンスが変化するケースもあるので一律に置き換えることもできないので注意すること
• [P39] 汎用表現は、具体表現に置き換える
  • 「する」などは何にでも使える汎用表現
  • 汎用表現を具体動詞に変えると文意が明確に「動詞にする」→ 「動詞に変更する」
    • → 明確になると、その文がギュッと濃縮したイメージに変わる
  • より適切な具体動詞を使う方がよい
    • その際に類語辞典が役立つ
• [P40] 好まれないことがある表現
  • 差別を連想させてしまう語： 例「片手落ち」
  • 慣用句や四字熟語： 使うべき場面では使ってもよい。だが、使わずに済む場面なら極力使わず独自表現にした方が文章が面白くなりがち
  • 「！」などの感情表現は、本質ではない部分で目立たせるものとして嫌われがち
  • 太字化（見づらい）／カタカナ化（何これ？）
• [P41] 文を分かりやすくする
  • 文はできるだけ短くする（文をつなげすぎない）
  • 主語と述語はできるだけ近づける
    • 「私は小林が中村が鈴木が死んだ現場にいたと証言したのかと思った。」（『日本語の作文技術』より引用）
  • 主語と述語が遠く離れる場合は、主語の後に読点「、」を打つ
  • 『理科系の作文技術』など、参考になる本はたくさん42 / 49 枚目
• [P43] 読みやすいWEB記事の書き方
  • 平均3文ぐらいを1パラグラフに
    • Web記事はディスプレイ上で読まれるため、空白が多い方が気楽に読める
    • そのため、紙の本よりも細かく段落化した方が読みやすい
  • 見出しも平均5パラグラフごとぐらいに
    • 同じ理由で、細かく見出しがあると視覚的に強弱が出て読みやすい
  • 画像を極力たくさん入れる
    • 文章だけの記事はどうしても息苦しい。図が全くない記事でも、文章内容の説明を図としてビジュアル化したりするなどで効果がある
• [P44] 記事の書き出し（冒頭・序文）
  • 執筆に不慣れな場合、書き出しが一番難しい
  • 解決作として、以下を提案したい
  • 書き出しの執筆は、最後に回して先に他を書く
  • 最新ニュース「イベントが開催された」から入る
  • 読者への質問「○○を知っているか？」にする
  • 記事内容を紹介する「本稿では○○を解説する」
  • 自分の感動や出来事などのエピソードから入る
• [P45] 便利なライティングの道具
  • ATOK（Mac／Windows／iOS／Android）
    • http://www.justsystems.com/jp/products/atok/
  • 辞書： 共同通信社 記者ハンドブック 第12版
    • http://www.justsystems.com/jp/products/dic_kyodo/
  • 辞書： 広辞苑
    • http://www.justsystems.com/jp/products/kojien/
  • 辞書： 角川類語新辞典
    • http://www.justsystems.com/jp/products/kadokawa/

2. アナログでアナクロなテクニカル・ライティング

• 冒頭のご挨拶にて
  • 初版で終わる場合が多い（だいたい3,000部が多い）
  • 第2版、第3版に行くことはほとんどない
  • 物書きで食べていこうとするととても大変
• [P3] テクニカル・ライティングは"料理"だ
  • 夕食の献立を決める
    • コース料理に近いイメージ
  • スーパーへ買い物に行く
  • フライパンをあおる
  • お皿に盛りつけ
• [P4] テクニカル・ライティングは"料理"だ
  • 何をどう書く：章建て
  • 文献/Webを漁る：取材
  • 草稿を起こす：執筆
  • 清書し脱稿、そして校正
    • 公開後のイメージを見せてくれる
• [P5] キホンはノートと万年筆
  • 本業があるので、なかなかまとまった時間が取れない
  • ぶつ切りになった時間（5分～10分、お昼休み、寝る前のちょっとした時間）を使って書いていかないといけない
  • 短い時間を使おうと思うと、電源要らない環境を作る
  • ノートは2冊用意している（A5版）
    • 1冊は原稿
    • 1冊はネタ帳（サンプルコードの断片を書いたり）
  • A5版にした理由
    • 電車の中で邪魔にならない
    • A4コピー用紙の半分のサイズ
  • 万年筆にした理由
    • ボールペンは縦に書く、筆圧が強いと長時間書けない
    • 万年筆だと、横に寝かせて書ける、腕が疲れない
    • 自分に気合いを入れるスイッチとして、お高い万年筆を活用
• [P6] 工程と道具
  • アナログなもの（章建て、取材、執筆、清書）
    • ノート
    • 万年筆
  • デジタルなもの（取材、清書）
    • ブラウザ・Acrobat Reader
    • Visual Studio
    • 秀丸
  • 2度手間だが、時間は2倍ではなく2割～3割増しで済んでいる
  • 清書している段階は、考えておらず、ひたすらタイピング
  • 自分の頭の中で文章を作るスピードと、キーを打つスピードが一致しない
    • じれったくなる
    • スピードが一致するものは万年筆だった
  • 手書きしたものを移す段階で、頭の中で校正がかかる
    • 手書きで草稿を書く場合、誤字脱字は気にしない、わからない漢字はカタカナで
• [P7] いつでもどこでも
  • 電源はいらない
  • ノートと万年筆だけあれば執筆ができる
  • A5で十数ページでWeb記事1つ分
  • ノート1冊でちょうど1年分
  • デジタルなものは、サンプルコードを書くときとネタを漁るときしか使わない
  • 家でもPCの電源は落としている
• [P8] スタバにお籠もり
  • 家にいると他のことをしてしまうので、やばいときはスタバへ
• [P9] こんなことを気にしながら書いています
  • 誰に読んでもらいたい？
    • 初心者から抜け出したい方を想定している
  • 今さら書けないことなんてない
    • 自分の言葉で書ける
  • 分解と再構築
    • 自分が書きたいことを分解して抽出して再構築
  • 「ものがたり」を書くつもりで
    • マニュアルを書くのは面白くない
    • どれだけモノを語るかを気にしている
    • たとえ話をあみだしたり
  • 人脈とかコネとか
    • 聞けばでてくることも多い
    • 物書きは自分一人ではできない
• [P10] 息抜きも大切よ♪

3. パネルディスカッション ライターに聞きたい！

• [Q1] どうやったらライターになれる？
  • 水増しするよりも増量（επιστημηさん）
  • 増量したあとに削る（επιστημηさん）
  • リラックスしつつ追い込みながら書くと良い（一色さん）
• [Q2] 記事を書くためのネタを探すコツは？
  • 誰かが書いているネタを書くのは大変（青木さん）
  • 誰も書いていない記事を（青木さん）
  • 2番煎じは怖い（επιστημηさん）
  • 英語のサイトからネタを探す（επιστημηさん）
  • プログラマー向けの場合、新しい製品を作っている人をウォッチしている（一色さん）
  • 編集者としてネタを考える場合は、PVを意識している（一色さん）
  • 最近ビッグワードがないので、ビッグワードでは探しにくい（一色さん）
• [Q] インターネットがなかった時代はどうしていた？
  • 人脈をフル活用していました（επιστημηさん）
  • 草の根のBBSはあった（επιστημηさん）
• [Q] 今だから話せる話は何かありますか？苦労話とか記事が書けなかった時とか
  • 連載とはいえ、キホン毎回読み切りなので、常に1本書いちゃうと次のネタがなくなる（επιστημηさん）
  • ネタのストックが持てないし、書き留めておくことができなかった（επιστημηさん）
  • よく使っていた方法として、Microsoftさんやライブラリを作っている会社に評価版を貰う（επιστημηさん）
    • 日本ではまだまだ出ていない評価版（επιστημηさん）
    • 記事書きます、下書きを渡します、等で交渉（επιστημηさん）
  • 専業ライターをやっていた時の話（青木さん）
    • 本を書いていてもあまり儲からなかった（青木さん）
    • リファレンス書籍を書くとき、1つ1つのプロパティを調べていると、誰がこんなのを使うんだと精神的に辛かった（青木さん）
  • いろんな人にお願いをしたときの話（一色さん）
    • Webの記事を書いても割が良くないので、交渉が必要だった（一色さん）
    • メディアだとリニューアルしにくい（一色さん）
    • メディアで書いた奴を転載してBlogにリニューアルをする案は社内から反対が出た（一色さん）
• [Q] PVを稼ぐ記事って？
  • 雑誌は締め切りが大変なので、Web記事を書いていた（青木さん）
  • PVを稼ぐ記事は、未だにピンと来ていない（青木さん）
  • なにがウケるかはよくわからない（青木さん）
  • たくさん書くと、たまにどれかが当たる（青木さん）
  • 渾身の一本と思ってもさっぱりの場合もあるので、PVを狙わないことにした（επιστημηさん）
  • 瞬間最大風速は狙わない（επιστημηさん）
  • いずれ役に立つ、またいつか読みに来て貰うものを狙う（επιστημηさん）
  • PVによって原稿料が変わるような場所はつらいかも（επιστημηさん）
  • PVは狙って稼げるものではない（一色さん）
  • ビッグワード系、王道系は検索に入りやすいので、トータルでPVを稼ぎやすい（一色さん）
  • みんなが使うものはPVが多くなりがち（一色さん）
  • ログ解析ツール等は、ログを解析している人しか見に来ないのでPVは低い（一色さん）
  • タイトルを工夫するのが一番効果がある（一色さん）
  • 誰にどういうメリットがあるというのを踏まえてタイトルを付ける（一色さん）
  • Webサイトで書く場合、1ページ目を面白くする（επιστημηさん）
  • 1ページ目のPVは多いが、2ページ目以降はPVが落ちる傾向にある（επιστημηさん）
  • 書き出しの部分が一番大事で大変（επιστημηさん）