開発者がマジで読むブログ記事の書き方！読まれる記事には〇〇が必須だった
引用元：https://news.ycombinator.com/item?id=43503872
俺の意見だけど（ブログちょっと人気あるんだよね）、テキストは基本的にインバーテッドピラミッド型がマジで最強。ツイートくらいの短さで記事の内容をタイトルとか最初の段落に入れると良いよ。手っ取り早く要点伝えて、それから詳しく説明する感じ。こうすれば、途中で読むのやめても大事な部分は持って帰れるし、細かいこと気になる人は最後まで読めばOK。読者集めるには、自分が何について書いてるかハッキリさせるのが一番。インバーテッドピラミッドはそれに役立つ。興味ない人を引き込んでも意味ないしね。新規読者より既存読者大事にしろって話。画像は、内容にめっちゃ関係あるなら良いけど、そうじゃないなら邪魔なだけだと思う。マジで。気を散らす要素は減らすべき。画像は絶対に面白くしちゃダメ。
＞インバーテッドピラミッド型がマジで最強”って言うけど、それって俺が30年くらい前に高校で教わったジャーナリズムの書き方と似てる気がする。新聞の記事書くときって、最初の文に誰が、何を、いつ、どこでって全部入れなきゃいけないんだよね。読者は最初の文で基本的な情報ゲットして、あとは詳細を読み進める感じ。これって読者だけじゃなくて、編集者が記事短く切る必要あるときにも便利で、最後のほうから削れば良いだけだし。
＞俺が30年くらい前に高校で教わったこと”
それ今でも教えるべきじゃない？あんま変わってないと思うけど？俺が学校行ってた10年前も、同じようにエッセイ書いてたよ。参考になるサイトはここにあるよ。
https://owl．purdue．edu/owl/subject_specific_writing/writing_…
https://owl．purdue．edu/owl/general_writing/academic_writing/…
https://owl．purdue．edu/owl/general_writing/the_writing_proce…
あと、色んな書き方があるし。論文以外にも色々書くじゃん。
新聞がインバーテッドピラミッド型を使うのには歴史的な理由があるんだよね、特に配信記事とか。レイアウトするときに、記事を途中でぶった切っても問題ないようにするためだったんだ。雑誌の記事はそこまで厳密じゃないけど、やっぱり重要な情報は最初の方に持ってきてるよね。
＞途中でぶった切る”ってマジで物理的に切ってたんだよ！俺が学生新聞で働いてた時（プロ用の写真植字機材があった）、二流の“埋め草”記事は長いコラムで組んで、レイアウトボードに貼り付けて（接着剤はホットワックス）、スペース無くなったらカッターで切ってたんだよね。レイアウト担当は、締め切りの11時までに終わらせるために、その辺の記事はマジで読んでなかったと思うわ。
俺も学生新聞やってて、その後別の学校で新聞創刊したんだけど、どっちも配信記事は使ってなかったけど、記事の長さを調整する必要はあったよね。
インバーテッドピラミッドは冷水シャワーみたいなもんで、最初はキツいけど、ライターとしての実力アップにはマジで良いんだよね。まず、自分の言いたいことを理解して、それを凝縮する必要がある。特に事実に基づいたニュース記事じゃない場合は難しいんだけど。そして、ダラダラ書かずに、すぐに核心に迫る。読者は好きなとこで読むのやめられるし。広告収入モデルには合わないかもだけど、サブスクモデルならめっちゃ合理的だと思う（たぶん、このルールはそこから生まれたんじゃないかな）。大学で学んだ数少ない役立つことの一つだわ。
＞最初の文に誰が、何を、いつ、どこで”って書かない最近の長文記事マジで嫌い。記事の3分の1くらいまで読まないと何も分かんないとかありえない。
長文記事だけじゃないよ。小学校から大学まで教わる基本の5段落構成のエッセイも、この原則に反してるじゃん。文章書くの習うときって、先生が読んでくれる前提じゃん？だから、要点を伝えることよりも、“読者の興味を引く”ことに重点が置かれるんだよね。だから、長文記事は魅力的な人物描写から始まることが多いんだよ。でも現実世界では、人の注意を引かないといけないし、誰もあんたの書いたもの読む義務ないんだから。情報を伝えたいなら、要点手っ取り早く伝えるべき。物語を語りたいなら、急ぐ必要ないけど。
この記事は、あなたのために書かれたものだよ。もしつまらないと感じるなら、あなた向けに書かれたものではないのかもね。
＞記事はあんたらに読んでもらうつもりだったんだよ。
それか、ページをもっとスクロールさせて広告読み込んだり、動画を自動再生させるつもりだったのかもね。
良いエッセイは、まず主張から始めて、それを展開して、最後にまた主張に戻るじゃん。
ジャーナリズムが情報発信っていう目的のためにうまく機能してる形式から離れる理由なんてないよね。他に目的（例えばエンゲージメントを長くするとか）があるなら別だけど。
フィクションとノンフィクションの違いってことじゃない？
作者が自分の作品をどう見せるか決めればいいんじゃないかな。
え、ピラミッドって上が頂点で、逆ピラミッドって頂点が下にあるんじゃないの？今まで間違ったピラミッド見てた？
いや、ピラミッドの見方は間違ってないよ。
ここでズレてるのは、ピラミッドの”幅”が何を意味してるかってこと。
ジャーナリズムの逆ピラミッドの考え方では、ピラミッドの幅が情報の”重要度”と関係してるんだ。
だから最初に一番重要な情報（ピラミッドの底辺、一番上）から始めて、その後に重要な情報をサポートするために面白くて必要な詳細（ピラミッドの先端、一番下）を埋めていくんだよ。
＞逆ピラミッドはほとんどの場合、文章の正しい形式だよ。
これって「読者に響く面白いストーリーを提供する」ってことと矛盾しない？
例えば、逆ピラミッドで問題と解決策を書くなら、「問題はこれ、解決策はこれ、方法はこれ」って構造になるよね。でもストーリーなら時系列順で「問題はこれ、試した方法はこれ、解決策はこれ」ってなるじゃん。
両方いける？結末を先に言ってから良いストーリーにするのって可能？
“逆ピラミッド…”
俺は”アイスバーグ記事”って呼んでる書き方を開発したんだ。
ｈｔｔｐｓ：／／ｊｏｈｎ．ｋｏｚｕｂｉｋ．ｃｏｍ／ｐｕｂ／ＩｃｅｂｅｒｇＡｒｔｉｃｌｅ／ｔｉｐ．ｈｔｍｌ
逆ピラミッドだけど、いくつか追加の属性がある。
この記事が自己言及的で、隠された情報の宝庫にリンクしてるんじゃないかって期待しちゃった。せめて、理論的な話じゃなくて、実例へのリンクくらいは欲しいな。
期待通りだよ - ”ｂｏｄｙ”リンクをクリックすると、トピック全体が完全に展開されてるのがわかるよ：ｈｔｔｐｓ：／／ｊｏｈｎ．ｋｏｚｕｂｉｋ．ｃｏｍ／ｐｕｂ／ＩｃｅｂｅｒｇＡｒｔｉｃｌｅ／ｂｏｄｙ．ｈｔｍｌ
イメージは絶対に面白くしちゃダメだって？マジで言ってんの？中東紛争ブログじゃあるまいし、テック業界のブログでしょ？ユーモラスなスクショがあった方が絶対おもしろいじゃん！もちろん、内容と全く関係ない画像を貼るのはNGだけどさ。そんな絶対的なこと言う理由がマジでわからん。
お堅い文章に面白い画像を入れると、急にテンション変わって読みにくくなるんだよね。伝えたいメッセージが薄れるし、読者が画像だけ見て内容を飛ばしちゃう危険性もあるし。それに、なんか自信なさげで子供っぽく見えるかも。例外はあるけど、基本はやめとくのが吉。 それ、下手な例えだよね。「逆ピラミッド」って、一番大事な情報（最初にくるやつ）が土台ってことじゃん？土台＝デカい＝重要ってことだけど、それって逆に混乱するわ。ピラミッドの頂点を重要情報って言ってもよくね？頂点＝簡潔＝要点＝重要、みたいな。 ＞どこが逆なの？ あの図を見ても、形と内容がどう関係あるのかマジでわからん。普通のピラミッドでも同じこと書けるし、そっちの方が理にかなってる気がする。一番上に小さくて狭いけど重要な情報を置いて、下に行くほどコンテキストとか詳細を付け加える方が自然じゃね？ ブログには使えるかもだけど、ちょっと長めの文章とか、複数のポイントがある場合は無理があるよね。あと、LinkedInの投稿が全部同じに聞こえる理由もこれかも。「いつもと変わらない月曜日だった。まさか、あの日が人生を変える日になるとは…」みたいな。 なんで逆ピラミッドが長文に向かないと思うの？複数のポイントがあるなら、それは別々のエッセイに分けるべきじゃない？最初の例は、月曜日がいつもと変わらないって話なら逆ピラミッドになるけど、次の文でその前提崩れてるじゃん。 本でも同じだよ！中心となるテーマ、見出し、そしてもっと読みたいと思わせる一文があるべき。「ペットは命を救う」ーペットを飼っている人が長生きする6つの理由、みたいな。各章にも同じことが言える。「触れ合い」ー猫を撫でるとなぜ癒されるのか、とかね。 読んでくれてありがとう、Viktor！ ＞深刻な話にユーモアを混ぜると、信憑性が薄れるって？ 絶対にユーモアを使うなってわけじゃないけどね。たまに俺の投稿にもジョークが混ざるし。でも、少ない方が良いと思うよ。シットコムの笑い声が聞こえてきそうな文章もあるし、至る所にギャグが詰め込まれてたりするし。 冗談だって分かってるけど、実際はもっと複雑だと思うな。HNのコメントでジョークがウケるのは、ジョーク自体が目的じゃなくて、本質的な意見をサポートするためのジョークだったり、意味のあるコメントに付随するジョークだったりする場合だよね。redditとかと比べると、HNは議論を促進する文化があると思う。 HNはジョークに寛容だと思うよ。本当に面白くて新鮮ならね。でも、ありきたりな引用ネタとか、古いミームはダメだね。 コンサル時代に、これを“トップダウンコミュニケーション”って呼んでたな。まず、キーメッセージから始めるんだ。ストーリーテリングとは対照的だね。 そのコンセプト、すごくいいね。知らなかった。テック業界以外でも、そういう話し方をする人がいたら注目しちゃうかも。 別名、バーバラ・ミントのピラミッド原則: 別名、BLUF（Bottom Line Up Front）とも言うね。 あのねー、ブログを誰かに読んでもらうことばっか考えたら、99%の人は書く意味なくなっちゃうと思うんだよね。別にこの記事のアドバイスが悪いってわけじゃないんだけどさ。読まれることばっか気にしてたら（例えば、HNのランキングとか、まだない記事を書くとか）、多分いつか書くのやめちゃうよ。だって、ウェブにあるものってほとんど読まれないし、読まれるためだけに書くのはモチベーションにならないもん。 作者だよ！読んでくれてありがとね！ あんたは、たくさんの人に読まれるものを書くのがマジで上手いよね。それが最優先事項なんだろうね。 ＞ウェブサイトのリンクには「Write Blog Posts that Developers Read（開発者に読まれるブログを書く）」って書いてあるけど、なんで開発者に読まれるブログを書くのがworthwhile（価値がある）のか説明してほしいと思ったよ。“ 返信ありがとね。言いたかったのは、99%の人はコンスタントに高い読者数を維持できないってことなんだよね。だから、これを目標にしたり、記事の出発点にすると、いつか書くのをやめてしまうから危険だよ。 ＞言いたかったのは、99%の人はコンスタントに高い読者数を維持できないってことなんだよね。だから、これを目標にしたり、記事の出発点にすると、いつか書くのをやめてしまうから危険だよ。“ 書くことはそれ自体が役に立つと思うけど、「自分のために書く」場合でも、誰かに向けて書くつもりで書いた方がもっと役に立つ。 views とかランキングとか気にしないで、まずは自分のために書くことが、本当の価値を生むんじゃないかな。 もしルールを一つだけ選ぶとしたら、「自分自身が実際に読みたいものを書く」だね。問題は、人間の脳は自分に嘘をついて、自分が作ったものをすごいものだと思わせるようにできてるってこと。実際には、他の人が書いたものなら絶対に読まないのにね。客観的になって、自分の文章を far-from-perfect mess（完璧とは程遠い mess）として見れるようにすること。 ＞自分自身が実際に読みたいものを書く“ わかるー、HNとかredditの議論って、レスが遅いと誰も読んでくれないんだよね。本当は数分で返信するんじゃなくて、一度キューに入れて何度も見直してから返信すべきなんだけど、そうするとフロントページから消えちゃって誰にも見てもらえない(返信相手くらい)。だから、ざっと目を通してスペルチェックだけする。数時間後じゃないと意味不明な点に気づけないんだよね。頭の中ではわかってるつもりでも、後で見ると全然意味わかんないこと書いてたりするし…(これで返信するけど、ちゃんと伝わるかな…) 声に出して読んでみるのもアリだよね！無理ならAIに読ませるとか。そっちの方が問題点に気づきやすいし。マジで同意。 ＞脳みそって、自分が作ったものを実際以上に良く見せようとするようにできてるんだよね。他人のが書いたものだったら絶対読まないようなものでも。 自分が読みたいものを書くっていうルール、マジで良いね。 ＞誰かが実際に読んでくれるものを書く Steve BallmerはBill GatesみたいにMicrosoft株を分散しなかったけど、めっちゃ金持ちになったよね。Gatesより今はお金持ちらしい。でも、一つの会社に全集中するのが良いってわけじゃないよね、たぶん。 ＞Goは「賢い」開発者向けじゃない たくさんあるよ。 作者です。 編集：HNの記事よりコメント欄を読んでいるかも。面白いよね！ サンプルサイズ1。サイズを2にするには： 記事の構成がしっかりしてれば（この記事がそうだって言ってるみたいだけど）、開発者が読んでシェアしたくなるブログにする方法は2つあると思う。 ブログの読者がいないうちは、頑張って調べたり努力したりしない方がいいと思う。ブログが確立されてないせいで、よく考えられた記事が全然読まれなかったり、適当に書いた記事がHNで上位に表示されたりするのを何度も見てきたから。 自分の経験とは違うかな。HNは、記事の深さを増して意見を減らした途端に、すごく歓迎してくれるようになった。 自分は1つの記事に5ヶ月くらいかけてるよ。オリジナルのリサーチで、実際に貢献できるような記事を目指してるんだ。 ＞自分は2番目のアプローチに集中してるから、記事を完成させるのに時間がかかる。だから月に1本くらいしか書けない。 ＞記事の構成がしっかりしてれば（この記事がそうだって言ってるみたいだけど）、それが一番大事だってことみたいに聞こえる。 兼ね合いだよ！多層システムを作るのがおすすめ。 正直言うと、この分野で経験豊富な人（HNのフロントページに69記事載せる予定。今は55記事）として、半分くらいは記事に自分がワクワクしてるかどうかだと思う。ワクワクしてないと、それが伝わっちゃって、読者に叩かれたり、フラグ立てられたりする。sink or swimだよ。 棒人間の例、マジでAIアートより分かりやすいね。皮肉なことに、そのAI画像があったからこそ、それが際立ったんだよね。AIのストックフォトってマジでつまんない。棒人間と比べてもそう思う。反AIアートの人たちがヒューマンクリエイティビティとかでギャーギャー言うよりも、この2つの画像の方が遥かに価値があると思う。 ＞ひどいMS Paintの絵でもAI生成画像より面白いのはマジで事実だよね。なんでみんなFlickrとかのCC BY-SAの画像を使わないんだろう？記事にAI生成画像があると、記事全体がAI製に見えちゃうんだよね。 https://refactoringenglish.com/tools/hn-popularity で紹介されてる人気ブログの多くが、ここで提案されてる内容と真逆のことやってるのが面白いよね。でも、まだ自分のスタイルを探してる人とか、人気を最適化したい人には、良いアドバイスだと思うよ。 読んでくれてありがとね！上位の著者たちは、ここで言ってるテクニックと合致してると思うよ。Paul Grahamは違うけど。Krebs、Julia Evans、Dan Luu、John Gruber、Simon Willisonとかは、みんな要点を手早く伝えて、広い層に向けて書いてるよね。Dan LuuとJohn Gruberは画像とか見出しをあんまり使わないけど、Krebs、Evans、Willisonは使ってるよね。 画像と構成で、説明するより見せるっていうリマインダー、マジ感謝！開発ブログってテキストの壁になりがちだけど、ざっくりした図とか、流し読みしやすい見出しがあるだけで全然違うよね。 Refactoring Englishも予約したよ！数年前のコース、”Hit the Front Page of Hacker News”がマジで好きだったんだよね。初心者向けに、予備知識とか前提知識なしで書くのが大事ってのが一番の学びだった。HNで紹介されてる記事で、自分の分野外なのに、全然バカにされてる気がしない記事にいつも感動してたんだよね。おかげで、白紙とにらめっこすることがなくなったよ。マジ感謝！本も楽しみにしてるね！ 読んでくれて、そして優しい言葉をありがとう！前のコースが役に立ったみたいで、マジ嬉しい！ 皮肉なことに、最初の数段落を流し読みして、注目を集める秘訣は”要点を手早く伝えること”ってのが分かった。で、一番下までスクロールして見出しだけ読んだけど、もうどうでもよくなっちゃった。コメントの方が興味あるんだよね。編集：やっぱりそう思ってるの俺だけじゃないみたい。 個人ブログランキング、作ってくれてありがとう！確かハードウェアのビジネスを最近売ったんだよね？コンテンツビジネスに移行した動機って何？このプロジェクトには興味あるし、本も買うと思うけど、もっと大きくて、難しくて、技術的なことに挑戦してる姿が見たかったなっていうのも正直ある。前の仕事はマジで刺激的だったんだよね。価値がないとは思ってないけどね。ただ、A地点からB地点への経緯が気になるんだ。 読んでくれてありがとね！ あの石の写真を撮るのに、瞬間接着剤どんだけ使ったの？ 一番上の石はコラージュかもしれないけど、下３つの石は本物だと思うよ！ ハハ、個人的には使ってないけど、カメラマンは使ったかもね。フリー素材の写真だよ。[0] 細かいことだけど、入れ子状の円グラフじゃなくて、ベン図の方が正確だと思うな。全ての開発者がブログを読むわけじゃないし。 だよねー。ベン図も考えたんだけど、重なりを強調してるように感じたんだよね。今回はただ同心円にしたかっただけなんだ。 そもそも、なんで技術ブログを書きたいのか？って自問自答すべきだよね。名声と富のためなら、好きなマイナー技術についてブログを書くのは一番簡単な道じゃないかも。もっとコメントを表示（1）
三角形が逆さまになってるってことだよ。
https://en．wikipedia．org/wiki/Inverted_pyramid_(journalism) 見てみ。
＞画像については、テキストにめっちゃ関連してない限り、あんまり賛成できないな。ただの飾りはノイズになると思う。
そこは意見が分かれるね。やりすぎは良くないけど、読者はテキストの壁を見ると飽きちゃうと思うんだよね。まあ好みの問題だけど。
＞画像は絶対に面白くしちゃダメ。
これはマジで反対。技術ブログでジョークは絶対ダメって言ってるのと同じじゃん。なんで画像が面白くちゃいけないの？ユーモアと技術的な洞察を混ぜることだって絶対できるじゃん。xkcdとか最高の例だよ。
ユーモアのセンスがない人だけじゃない？(笑)”,
＞画像は絶対に面白くしちゃダメだよ
😊
https://www.mckinsey.com/alumni/news-and-events/global-news/…
書くって、たとえ誰にも読まれなくても、マジで価値があるし、楽しいんだよ！自分の考えをまとめるために書くことで、そのテーマについてもっと深く学べるし、自分自身についても知れる。記事を公開することで、考えを再確認できるけど、一番のメリットは書こうとしてることについてもっと学べることだと思う。
だから、アドバイスとしては、自分のブログで面白いと思ったことを自由に書けばいいんじゃないかな。アクセス解析とか入れないで、ただ書いて、公開して、LinkedInに載せる。そうすれば、いつか誰かが見てくれるよ。
＞ブログを誰かに読んでもらうことばっか考えたら、99%の人は書く意味なくなっちゃうと思うんだよね。“
作者が自分のために書くのは全然アリだと思うけど、そういう人はもっと少ないと思うな。5～10%くらい？
ほとんどの作者は、自分の書いたものを読んでもらえることに満足感を得てると思う。何百万人もじゃなくてもいいけど、数時間かけて書いた記事が数人しか読まれないのは、ほとんどの人が満足できないんじゃないかな。
だから、すべてのブロガーが広い読者層を目指すべきだとは思わないけど、もしそうしたいなら、この記事のアドバイスは役に立つと思うよ。
ウェブサイトのリンクには「Write Blog Posts that Developers Read（開発者に読まれるブログを書く）」って書いてあるけど、なんで開発者に読まれるブログを書くのが worthwhile（価値がある）のか説明してほしいと思ったよ。
＞何百万人もじゃなくてもいいけど、数時間かけて書いた記事が数人しか読まれないのは、ほとんどの人が満足できないんじゃないかな。“
俺は誰にも読まれないブログを書いてるよ。記事を公開しても、何人が読んだか確認しない。ブログに特定のテーマはないし、ただ頭に浮かんだことを書いてる。もちろん、文章力を上げて、自分の考えをもっとうまく表現できるようになりたいけどね。でも、多くの人に読まれることが当然の目標だと思ってる人は、ちょっと怪しいと思っちゃうんだよね。
[Edit]：ああ、やっとわかった！あんたは、どうすればブログが読まれるようになるかってことを書いてるんだね。しかも、それが上手いから、たくさんの人があんたのブログを読んでる。当然、読者は自分の文章を読んでもらいたい人たちだ。あんたは読者と交流するから、みんなブログは読まれることを目標に書いてると思ってるんだ。
この記事は、自分の文章をもっと多くの開発者に届けたいと思ってる人向けなんだ。タイトルを見て記事にたどり着いたってことは、すでに多くの読者を求めてるはずだから、その時点で説明する必要はないと思ったんだよね。
もし「How to vertically center a div using CSS（CSSでdivを垂直中央に配置する方法）」って記事をクリックして、その記事がなぜdivを中央に配置したいのか説明してたら、ちょっと変だし、時間を無駄にしたくないと思うんじゃないかな。
＞俺は誰にも読まれないブログを書いてるよ。記事を公開しても、何人が読んだか確認しない。ブログに特定のテーマはないし、ただ頭に浮かんだことを書いてる。もちろん、文章力を上げて、自分の考えをもっとうまく表現できるようになりたいけどね。でも、多くの人に読まれることが当然の目標だと思ってる人は、ちょっと怪しいと思っちゃうんだよね。“
それは全然いいと思うし、応援するけど、この記事の対象読者じゃないってことだね。
本のウェブサイトには、読者を増やす戦略じゃなくて、技術について書いた記事もあるから、そっちも興味あるかもね。[0]
[0]
https://refactoringenglish.com/chapters/もっとコメントを表示（2）
でも、views/front page をたくさん取ることが出発点なら、アドバイスには全面的に賛成。
いやいや、「高い」数字じゃなくても、このアドバイスは当てはまると思うよ。
例えば、HNとかredditに投稿し続けること以外に戦略がないブロガーがいて、なかなか traction（牽引力） が得られなくて、落ち込んで諦めてしまうことがある。
そういうブロガーに伝えたいのは、最初からどんなトピックについて書きたいのか、どんなチャネルを使えば読者に届けられるのかを考えれば、読者を見つけられるってこと。たとえ数十人に読んでもらいたいだけでも、そのテクニックは有効だよ。
（原則として、「他の人が実際に読みたいものを書く」こともできるけど、こっちの方がずっと難しいと思う。だって、他の人がどう反応するかを知るのは難しいから！もし自分自身が読みたいと思えるなら、俺たちはそんなにユニークじゃないから、他の多くの人も読んでくれるはず。）
あと、このリアリティ溢れる写真にprops（敬意）！
https://refactoringenglish.com/chapters/write-blog-posts-dev…
これは良いルールだね。最初のテストは「3回 proof-reading（校正） を乗り越えたか？」だね。
校正すらしない人が書くgarbage（ゴミ）！3回読めば（数日空けて読むのが理想）、ほとんどの kinks（欠点） に気づくよ。
そして、声に出して読む！それが無理なら、AI voice actor（AIボイスアクター） に読んでもらうだけでもいい。そうすれば、もっと多くの問題に気づけるよ。
最初は記事に入れようと思ったんだけど、他の記事であまり触れられてないアドバイスに絞りたかったからやめたんだよね。でも、いつも人に勧めてるよ。AIだと効果薄いかも。声に出して読むと、文章を自然に言い換えたくなるときがあって、それが元の文章より良くなってることが多いんだ。
まさに俺のポエムのことだ(笑)。でも、これは仕様だと思ってるから、世間がどう思おうと書き続けるぜ。
このニュアンスが重要だよねー。多くの人が、自分を客観的に見て、他人がなぜ興味を持つのか判断するのが苦手なんだよね。
他の人の役に立つように文章力を上げたいとは思ってるよ。でも、より多くの人に読んでもらうためにコンテンツを広げると、薄っぺらくてお決まりのクリックベイト記事になっちゃうんだよね。読んでも書いても楽しくない。文章を書くことは自分の考えを深めることでもあるから、読者のためじゃなくて自分のために書きたい。でも、読んでくれる人には感謝してるよ。
Hacker Newsで人気のある記事って、ZigとかRustとか、Goは「賢い」開発者向けじゃないとか、PL理論とか、Lispのノスタルジーとか、ブログを書くべき理由とか、Small internetとか、そういうのばっかりだよね。9割は記憶に残らない。記事よりもコメントの方が勉強になることが多いし。特定の層に響くような記事は書きたくないんだ。
基本的には、今自分が取り組んでいることとか興味のあることを書いてる。過去の自分や未来の自分が役に立つようなものを書くようにしてるかな。読者向けに書くのとは全然違うよね。アクセス数は少ないけど、ブログには月数千人の訪問者があるよ[1]。リクルーターが記事を見てオファーをくれたこともあるし。書き方としては違うけど、今のやり方に満足してるよ。
[1]: https://rednafi.com/
っていう例って何かある？
https://news.ycombinator.com/item?id=37192467
https://news.ycombinator.com/item?id=9266184
コメントから、少なくとも最後のセクションは読んでくれたみたいだね: )
でも、見出しと構成が意図した通りに機能してるってことだね。ざっと目を通して、内容を理解して、自分には合わないと判断したんだ。
見出しから興味がないと判断できたなら、同じ情報を別の方法で提示しても、たぶん興味を持たなかっただろうね。
個人的には全然ありだと思う。
興味のある分野か、すでに知っていること以外は、リンクを開く前にコメントをチェックするようにしてる。時間の節約になるし。
記事を開いて、作者がちゃんとわかってる人だってことを確認できたから、次のブログを書く前にちゃんと読もうと思ってブックマークした。
もし最初にnannaのスパゲッティレシピみたいなブログの話をされたら、そうしなかったかも。
1．とにかくたくさん書く。そうすればいつか当たる。
2．めっちゃ調べて頑張る。
記事の冒頭の「開発者は面白い洞察を持っていた」ってくだりは、ブログがつまらない意見ばかりだったってことみたいに聞こえる。意見記事で成功する人は少ないけど、一番書きやすいんだよね。知らない人が書いても誰も興味ないから、めっちゃ調べて深掘りして面白くするしかない。
自分は2番目のアプローチに集中してるから、記事を完成させるのに時間がかかる。だから月に1本くらいしか書けない。全部自信作にしたいし、構成を調整したり、冗長な表現をなくしたり、読みやすくしたりするのに時間をかけてる。文を太字にすることが多いかな。画像も使うようにしてるけど、開発者向けのコンテンツで役に立つ画像を見つけるのは難しい。イラストレーターを雇うのはいいけど、お金を払えるライターは少ないんじゃないかな。
記事を面白くするために、カスタムコンポーネントを作って、ブログで使えるコンポーネントライブラリを育ててる。でも、うまくいかないこともある。例えば、前の記事ではイースターエッグを数時間かけて作ったけど、インタラクトしたのは22人（0.1%未満）だった。
HNがあんまり興味を示さない分野もある。例えば、web accessibilityとか。（他のプラットフォームの方が反応が良かった）でもそれは、writerとかblogの問題じゃなくて、テーマの問題だと思う。もっとコメントを表示（3）
まさにそれなんだよね。コードを書いたり、同じようなコードを複数のプロジェクトで書き直したりして、それを共有すると役に立つかもって気づくのがきっかけ。
次に、コードをブログに全部貼り付けて、記事の構成を考え始める。このコードが正しい（あるいは使うのに十分な程度に正しい）って主張するために、どんなコンテンツを追加する必要があるかな？コードの代替アプローチを調べて、それについて書く時間も必要。
完成した記事には満足してるけど、書くのに時間がかかるんだよね。今書いてる記事は、まだリサーチがたくさん残ってて、ちょっと書けなくなってる。リサーチして記事にするモチベーションがわかないんだ。でも、それは普通だと思うし、いつかまたやる気になるはず。
著者です。
構成が全てだとは思ってないから、そう思わせてたらごめん。
面白いテーマを選んだり、うまく書いたりするのは当たり前だと思ってて、この記事ではあまり語られてないアドバイスに焦点を当ててみたんだ。
まず短い記事をたくさん書いて、どれが異常に読まれたり、自分がよく参照したりするかを見てみる。
それから、頑張って時間をかける。
こうすれば、人気のないものに無駄な投資をせずに済むし、何度もチャンスがある。
例：
https://www.swyx.io/bottom-up-ideas
あと、流し読みする人向けには画像がマジで効果的。文章の流れを区切ってくれるからね。見出しの色を変えるのもアリだけど、markdownと普通のCSSじゃあんまりやらないよね。
コンテンツビジネスに乗り出す動機って何？ このプロジェクトには興味あるし、本も買うと思うけど、もっとデカくて難しくて技術的なことに挑戦して、その過程をシェアしてくれる方が嬉しいかな。前の仕事はすごく刺激的だったんだよね。
技術的なことについて書いて、それが経済的に成り立つようなビジネスを探してるんだ。読者の興味にも合ってるようなやつね。
TinyPilotを運営してた時、やってることを色々書きたかったんだけど、ビジネスのペースが速くて書く時間が全然なかったんだ。それに最初の数ヶ月以降、ブログがビジネスに与える影響はほとんどなかったし。役に立ってると思ってたんだけど、他のことに時間を使った方がいいから、ブログに時間を割くのが難しかったんだよね。
ブログがTinyPilotの役に立たないのも当然かも。ブログの読者と製品に興味のある人の間には重なりがあるけど、完全に一致してるわけじゃないし。インディーズビジネスに興味がある人が、必ずしもKVM over IPデバイスを買いたいわけじゃないし。
ブログで稼ぐ方法はいくつかあるけど（広告、アフィリエイト、有料メンバーシップ）、一番魅力を感じるのはJulia Evans[0]みたいなやり方かな。彼女は自分の興味のあることをブログに書いて、読者が経済的に貢献できる有料プロダクト[1]を持ってるんだ。
最終的にはSaaSとかソフトウェア製品に戻りたいけど、本がうまくいくか試したいんだよね。教えたいことがたくさんあるんだ。
教育的なプロダクト（”情報プロダクト”）は残念ながら偏見を持たれがちだけど、顧客発見、マーケティング、販売のプロセス全体を学べる良い方法だと思うんだ。長期的な約束じゃないから、うまくいかなくても、次のことに移ればいいだけだし。
イラストレーターにカバーデザインを依頼したんだけど、AIの使い方で気に入らないことがあって、結局自分で2時間で適当なカバーを作ったんだ。[1]
問題は一番上のカテゴリーだよね。”プログラマー”を厳密に含むようなものに変えるべきかも。
自分の理解のためなら、写真が足りてるかとか、最初の段落がTikTokに対抗できるほどドーパミンが出るかとか気にしなくていいし。未来の自分が一番重要な読者になるんだから、記事を読み返してる時点で興味があるってことだし。代わりに、将来自分が理解できるように、詳細で正確な言葉に集中すべきだよね。
プロとしての評価を高めたいなら、コンテンツがどれだけキャッチーかは評価されないだろうし。
