- Authors
- Name
- Youngju Kim
- @fjvbn20031
言語について。 以下でリンクした記事はすべて韓国語で書かれています。説明は筆者自身のものですが、リンク先は韓国語のページです。
最初の一編は簡単で、十編目が難しい
技術ブログを始めよという助言はどこにでもあります。プラットフォームを選んで最初の記事を出すところまでは、たいてい難しくありません。問題はその次です。二編目は何を書けばよいか分からず、三編目あたりでは、この程度の内容はもうみんな知っている気がして手が止まります。サイドプロジェクトも同じです。初期の設計は楽しく、公開の直前で力尽きます。
そこで今回の一覧は、始め方を扱う記事をほとんど入れませんでした。代わりに続けさせる条件を扱う記事を集めました。なぜ書くのか、どう負担を減らすのか、どこに書くのか、そして作ったものをどう最後まで引っ張るのかに関する記事です。
この一覧の作り方
順位ではなく編集者個人の選択です。閲覧数や人気を測る手立てはなく、測ってもいません。三つの基準を使いました。
第一に、自分の経験から出た判断を含む記事を選びました。一般論をまとめた記事より、実際にやってみて考えが変わった地点を書いた記事を優先しました。
第二に、講座やコーチングの販売が主目的の記事は除外しました。候補の中に事例のように見えて本文のあちこちが有料プログラムにつながるページがあり、そうした記事は判断の基準を曇らせるので外しました。
第三に、リンクを直接開いて確認しました。接続が塞がれている、サービスエラーが出る、実際の内容が検索結果の説明と違う候補は捨てました。実際にこの段階でいくつか落ちました。
リンクは2026-08-12に直接開いて確認しました。個人ブログの記事は消えたり住所が変わったりすることがあります。
開発者が文章を書く理由
三編とも同じ問いに答えますが、結論が少しずつ違います。合わせて読むと自分の理由を選びやすくなります。
開発者の文章書き
ブランチ(Brunch) — 쿠우보이 · 2019年1月30日
プログラミング教育がコードで終わってはならず、書くことと話すことを含むべきだという主張を込めた記事です。
こんな人に — 文章を書くことを開発とは別の仕事だと考えてきた人。
この記事の中心的な主張は、文章を書くこととコーディングが別の仕事ではないということです。どちらも意図を明確に表現し論理的な構造を作る作業だという点で同じであり、だから一方が得意な人が他方をできないなら、それは好みではなく訓練の問題だと見ます。教育課程に文書作成と学習記録を入れるべきだという提案まで進むので、個人の習慣ではなくチームの制度として考える余地も与えます。古い記事ですが論旨は今もそのまま有効です。
開発者として文章を書く理由
ブランチ(Brunch) — swimjiy · 2020年7月29日
履歴書のためではなく自己理解のために技術ブログを書くという観点を整理した記事です。
こんな人に — ブログを就職用としてだけ考えてきて、そのせいで書き続けるのがつらい人。
動機をどこに置くかが持続性を決めるという点を突く記事です。就職が目的なら目的が達成された瞬間に書く理由が消えますが、理解を目的に置けば書き続ける理由が残ります。そして文章で説明してみると自分がどれだけ分かっているかが露わになるという指摘が、この記事の中心にあります。分かっていたつもりのことを書いていて詰まる経験は大半の開発者がしているはずで、その経験を学習の道具として読み替えます。
開発者の文章
ベロッグ(Velog) — 콜트 · 2021年7月24日
技術ブログをより楽に書くための原則と、記事の種類を四つに分けた分類を提案した記事です。
こんな人に — 完璧に理解していない主題は書けないと思って手が止まった人。
この一覧で最も実用的な記事です。主題意識を捨てて題材意識を持てという助言、読者の水準ではなく自分の水準に合わせて書けという助言が、いずれも書き始める敷居を下げる方向を向いています。そして記事を四つの種類に分ける分類がとくに有用で、自分の記事がどの種類かを決めれば構造が自動的に決まるからです。すべてを説明しようとせず足りない部分はリンクに委ねよという助言も現実的です。
書く習慣と書く場所
理由を決めたなら、次は維持する問題と場所を選ぶ問題です。
文章を書く習慣の作り方
ブランチ(Brunch) — 글장이 · 2024年4月7日
反復と儀式という二つの装置で、文章を書く習慣を作る方法を整理した記事です。
こんな人に — 書く気はあるのに毎回始めるのを先延ばしにする人。
この記事の有用な点は、習慣を意志ではなく環境と合図の問題として扱うことです。同じ時間に同じ場所で書き、書く直前にいつも同じ短い行動を繰り返せば、始めるかどうかを毎回決めなくて済みます。習慣は悩みを減らしてくれるという表現が、この記事の要旨をよく捉えています。開発者を対象に書かれた記事ではありませんが、むしろそれゆえに技術的な主題と無関係に適用できます。
開発者のための文章術の本
ブランチ(Brunch) — gnugeun · 2023年5月24日
論理的な文章を訓練と見る観点から、役に立った本を数冊紹介した記事です。
こんな人に — ブログ記事を数編書くだけでは足りず、きちんと学びたい人。
本の紹介記事ですが、選んだ基準が明確なので読む価値があります。文学的な文章と論理的な文章を区別し、後者は才能より努力の領域だという前提から出発します。一般的な文章術の本と開発者向けの本を分けて紹介するので、今の自分に必要なほうを選べます。推薦した本の中で見つけた誤りまで書いておく態度が、この記事の信頼度を高めます。
開発者のためのブログプラットフォーム比較分析
ベロッグ(Velog) — 박은미 · 2021年6月15日
複数のブログプラットフォームの長所と短所を比較し、そのひとつを選ぶまでの判断を書いた記事です。
こんな人に — どこに書くか決められず、まだ最初の記事を書いていない人。
プラットフォーム選びはしばしば過大評価される決定ですが、だからこそこの段階で長く止まる人が多いです。この記事は候補を並べてそれぞれの性格を整理したうえで、自分の基準でひとつを選ぶ過程を見せるので、同じ決定を早く終わらせる助けになります。結論に同意しなくても判断の軸を得られるという点が重要です。ただし古い記事なので、各プラットフォームの機能と方針は今と違いうります。
開発ブログとしてブランチはどうか
ブランチ(Brunch) — 홍기린 · 2024年8月8日
コード表示が不便だという弱点を知りながら、特定のプラットフォームを選んだ理由を説明した記事です。
こんな人に — 皆が使っている場所ではない選択肢を考えている人。
前の記事と対にして読むとよいです。同じ決定を別の基準で下しているからです。この記事の筆者は機能的な優位ではなく、反応が来るかと読みやすいかを基準にし、その基準が自分の目的と合っていたから短所を受け入れます。道具の選択において正解ではなく目的との整合性が重要だという点を示す事例です。決定を他人に委ねず自分の基準で下すやり方そのものが参考になります。
開発ブログ運営記
공부 블로그 Blue log — Lee Jeongan · 2024年4月7日
三年近く個人ブログを運営しながら、どんな記事が残りどんな記事が意味がなかったのかを整理した記事です。
こんな人に — ブログを数年やってきて、これを続ける理由を探している人。
時間が積み重なった人にしか書けない記事です。自分の記事を三種類に分けたうえで、単なる情報伝達の記事より自分の経験と成長を記録した記事が残ると結論づけますが、この判断は数年やってみなければ出てきません。閲覧数を目標にした瞬間ブログが義務になるという指摘も正確です。ブログを考えを整えるフィルターと見ようという結論が前の記事群とつながり、この節を自然に締めくくります。
サイドプロジェクトが収益になるまで
作ることと売ることは別の問題です。二編ともその隔たりを扱います。
サイドプロジェクト、MVPから収益化まで
ベロッグ(Velog) — 정선교 · 2024年9月25日
自ら作ったサービスを一年間運営しながら、最小機能の製品から収益化まで至った過程を整理した振り返りです。
こんな人に — サイドプロジェクトを作ったのに利用者が来ず止まってしまった人。
この記事の最大の教訓は、マーケティングより製品の完成度と素早い公開を前に置いたという選択です。そして成長のかなりの部分が広告ではなく検索からの流入だったと記録するのですが、この構造はひとりで作る人にとってとくに重要です。広告費を使えない条件では、検索に引っかかる製品を作ることが唯一持続可能な流入経路だからです。チームで働きながら経験した問題まで併せて書くので、ひとりではなく二、三人で始めようとする人にも参考になります。
サイドプロジェクトを月収4,500万ウォンの事業へ
ブランチ(Brunch) — 솔비나 · 2024年10月27日
海外の一人開発者が個人の財務管理サービスをサイドプロジェクトとして始め、数年かけて育てた過程を紹介した記事です。
こんな人に — サイドプロジェクトを長く続ける人たちが実際に何に耐えているのかが気になる人。
この一覧で唯一、他者の事例を取材して整理した記事です。だから本人の振り返りではあまり表に出ない部分が見えるのですが、とくに公開初期の失敗と度重なる燃え尽きを併せて扱う点がそうです。価格を誤って決め、無料体験の期間を長く取りすぎたといった具体的な失敗が書かれているので、同じ段階を控えた人が点検表として使えます。成長が広告ではなく長い時間の改善と率直な記録から出たという結論も前の記事と重なります。ただしこの事例の数字は特定の個人の結果であり、一般的な期待値ではありません。
このブログの関連記事
- エンジニアのための説得する文章 — 技術文章の次の段階に当たります。
- AIでブログ記事のパイプラインを作る — 草稿ではなく検証がボトルネックだという話です。
- AIが書いた文章が崩れる地点 — 道具を使っても何を自分で確認すべきかを扱います。
- Diátaxisを四つのフォルダと誤解する理由 — ひとつの記事に複数の目的を混ぜるとなぜ崩れるのかに関する記事です。
この一覧の限界
十編のうち八編が文章の側で、サイドプロジェクトは二編だけです。この不均衡は意図したものではなく検証の結果です。サイドプロジェクトの収益公開記事は候補が多かったのですが、開いてみると有料講座や会員制につながるページであるか、接続できない場合が多くありました。基準を下げて埋める代わりに、通過した二編だけを載せました。
そして収益の事例を読むとき、ひとつだけ心に留めておかれるとよいでしょう。公開されるのはたいていうまくいった事例であり、同じやり方で始めたはるかに多くのプロジェクトは記録として残りません。ここに載せた記事も方法の保証ではなく、ひとりが通ってきた経路として読まれることをお勧めします。