今日はお仕事で書いた記事を基に自分がものを書くときに意識していることを言語化してみようと思います。今年を振り返る「なんかかく」アドベントカレンダー 11 日目です。
対象読者
仕事でものを書くときに自分の成果物をもっと底上げしたいと思う人へ。
結論
以下ステップを踏んでいます。
- 対象読者像を最大限可能な限り明確に定義する。
- 結論を述べる。
- その根拠を分解して述べる。
- 参考文献をまとめる。
- 1 ～ 4の内容をまとめる。
- タイトルを決める。
解説
<対象読者像を最大限可能な限り明確に定義する>
細かければ細かいほど書きやすくなります。いわゆるバズる記事は対象が広いわけですが、対象が広いと話がぼやけることが多いのでそこを目的としないほうが良いです。
- 〇〇に困っている
- 〇〇というエラー メッセージに直面している
- 社内向け・社外向けの〇〇向け
- 経験者向け・初心者向け
<結論を述べる>
対象読者が解決したい問題・課題への答えを冒頭で述べます。
<その根拠を述べる>
箇条書きにして、それを節に分けます。
<参考文献をまとめる>
参考にした記事 URL を書きます。
<内容をまとめる>
内容を締めくくります。
<タイトル>
「結論を述べる」で書いたことを 1 つのフレーズにします。
解説の背景
今年お仕事で書いたもの。今週は Logic Apps と Logic App とロジック アプリ #Azure - Qiita を書いたのでこちらも読んでいってください。
Logic Apps 関係の記事
Logic Apps をこれから使い始めようという方へ | Japan Azure Integration Support Blog
Standard Logic Apps で Azure OpenAI アプリ内コネクタがパブリック プレビュー | Japan Azure Integration Support Blog
従量課金版 Azure Logic Apps の料金体系を理解するポイント | Japan Azure Integration Support Blog
Logic Apps で日付や時刻を判定してワークフローを制御する | Japan Azure Integration Support Blog
Logic Apps で日付や時刻を判定してワークフローを制御する (2) - 毎月第 1 月曜日に起動したい | Japan Azure Integration Support Blog
MSMQ 関係の記事
MSMQ のトランザクション メッセージ | Japan Azure Integration Support Blog
意外と気を遣っている
「料金体系を理解するポイント」ってやつは結構考えに考えたタイトルです。料金体系の解説じゃなくて「料金体系を理解するための要点」ということです。「ここに気をつけて読んでくれ」ということを書きたいわけで「This is 料金体系」というわけではないのです。
同じように意外と私は想定読者に気を配るようになりました。ワークフローの制御の説明も決してコードゴルフをしたいわけじゃなく、読みやすさ伝わりやすさの公約数を考えて粒度を調整したり、仮定で話しておいてヒアリングにつなげることをしたりしてします。文書は文学ではなく「読み手」に伝わるかどうかでしかないという当たり前のことに気づくわけです。
たとえ話
- 「新宿に行きたい」という読者がいたとして
- 新宿の「どこ」かによる、が答えになってしまうので、その人が最短で行きたい新宿に行けるように指示する。例えば〇〇まで行って次の人に聞けなど。
その他に役に立つ記事
まとめ
読者と読者の求めていることを明確にして答えていきたい。「ものを書いてお金を頂きたい」が人生の野望の一つであった私にとっていま携わっている自分の仕事は結構悪くないなと常々感謝しています。一応自分で書いたステップに従ってこの記事も書き直してみました。と言いつつ「仕事でものを書くときに自分の成果物をもっと底上げしたいと思う人、または、筆者はこうやってるんだなー、ということをご参考にお手並み拝見したい方へ。」くらいの方が正確かもしれないです (話の真のオチ)。
以上です！！