技術ブログで、学びを言語化する。最初の1本は、1,500字からで十分です【フェーズ2-8｜ITエンジニアの卵に贈る、就活の書】

【お知らせ】本連載は、2026年9月20日に全記事を全面アップデートしました。

　この記事は本気でITエンジニアになりたい！ という学生さんたちに向けて就活プロセスを伝える「ITエンジニアの卵に贈る、就活の書」シリーズの一本です。シリーズ全体の目次はこちら（扉記事）からご覧いただけます。

　エンジニアを目指す学生のみなさん、こんにちは。クオリティアーツの池田です。

　ITエンジニアの卵に贈る、就活の書・フェーズ2-8の記事です。前回のフェーズ2-7では、就活と学業と個人開発を束ねる時間設計の話をしました。今回はフェーズ2「作る」の実践各論11本のうちの6本目として、技術ブログで、学びを言語化するというお話です。

　技術ブログは、コードとは違う軸で、あなたの学びと考え方を残す場所です。GitHubに残したコードが「何を作ったか」なら、技術ブログは「なぜ作ったか、どう考えたか、何を学んだか」を残す場所です。

　1本も書いたことがない人こそ、この記事の読者です。先に、3つ答えておきます。

• 自分より詳しい人がいるのに、書く意味があるのか：あります。詳しい人は、初心者がどこで詰まるかを、もう忘れています。あなたがいま詰まっている場所は、あなたにしか書けません

• 間違ったことを書いて叩かれないか：技術記事は、あとから直せます。2-4に、間違いが見つかったときの直し方を書きました

• 文章が苦手でも書けるのか：書けます。構成の型は決まっています。2-2に置きました

この記事のポイント

• 最初の1本は、1,500字から2,000字で十分です。構成は「詰まった→調べた→試した→学んだ」の4つでできています。

• 下手なことと、不誠実なことは違います。初めての1本が拙いのは当たり前で、避けるべきは、調べずに書くことだけです。

• 技術記事は、公開したあとから直せます。間違いを指摘されたら、直して一行添える。それで終わりです。恐れる理由にはなりません。

1. なぜ、あなたが書くのか

　エンジニアという職業には、学び続けることと、知識を共有することが、職業上の責任として位置づけられています。ソフトウェアエンジニア倫理綱領に、そう書かれました。IEEE-CSとACM（どちらも、コンピュータ分野の代表的な国際学会）が定めたものです（序章-1）。

　技術ブログを書くことは、言語化の訓練そのものです。学んだこと、詰まった箇所、乗り越えた工夫を、初めて読む他人にも伝わる形に翻訳する。この作業を通じて、あなた自身の理解が深まります。

　もう一つ、あなたが書く意味について書きます。ここが、いちばん多く聞く疑問だからです。

　「自分より詳しい人が、いくらでもいる」。そのとおりです。でも、詳しい人には書けないものがあります。

　ある技術に詳しくなった人は、初心者がどこで詰まるかを、もう忘れています。何が分からなかったのか、どの言葉でつまずいたのか、思い出せない。だから、詳しい人が書いた記事は、初心者が本当に困る場所を飛ばしてしまうことがあります。

　あなたがいま詰まっている場所は、いま詰まっているあなたにしか書けません。半年後のあなたにも、もう書けなくなります。そこに、初心者の記事の価値があります。

2. 最初の1本を、書き切る

　書き方の作法より先に、最初の1本を最後まで書いて、公開ボタンを押すところまでを扱います。ここを越えないと、他のすべてが始まりません。

2-1. 長さは、1,500字から2,000字で十分

　まず、長さの不安を消します。最初の1本は、1,500字から2,000字で十分です。読み終わるのに5分かからない量です。

　長い記事が偉いわけではありません。短くても、自分でやったことが書いてあれば、記事として成立します。レポートの最低字数を埋めるつもりで書けば、届きます。

2-2. 構成は、この4つでできています

　文章が苦手でも大丈夫です。技術記事の構成は、ほぼこの4つで決まっています。見出しを4つ立てて、それぞれに数段落書けば、1本になります。

• 詰まった：何をやろうとして、どこで止まったか。エラーメッセージをそのまま貼ってよい

• 調べた：何を見たか。検索した言葉、読んだ公式ドキュメントのページ、試したが違った情報

• 試した：実際に何をやったか。書いたコードを貼る

• 学んだ：結局、何が原因だったか。次に同じことが起きたら、どうするか

　この4つに、最初と最後を1段落ずつ足せば終わりです。最初は「何をやろうとしていたか」、最後は「同じところで詰まった人の役に立てば」。それだけです。

　この型は、あなたの体験そのものが材料になります。だから、詳しい人の記事を読んで比べる必要がありません。あなたが詰まった事実は、誰にも否定できません。

2-3. 公開するまでの手順

　書く場所は、Zenn、Qiita、はてなブログのどれかで構いません。プラットフォームごとの違いは、3-1にまとめました。

　手順は、どれもほぼ同じです。

1. アカウントを作る（無料です）

2. 新規記事を作る

3. タイトルと本文を書く。書式はMarkdown（見出しは行頭に「#」、コードは前後を記号で囲む、という簡単な記法です。エディタに書き方の案内が出ます）

4. 下書きのまま保存できます。数日かけて構いません

5. 公開ボタンを押す

　下書きのまま保存できるところが大事です。書き始めて、途中でやめて、翌日続ける。それでかまいません。

2-4. 間違っていたら、直せばいい

　いちばん多い不安が、これだと思います。「間違ったことを書いて、叩かれたらどうしよう」。

　先に、事実を1つ。技術記事は、公開したあとから直せます。紙の本とは違います。すべてのプラットフォームに編集機能があり、公開後も何度でも書き換えられます。

　だから、間違いが見つかったときにやることは、これだけです。

• 本文を直す

• 記事の末尾か冒頭に「◯月◯日追記：◯◯の記述が誤っていたため修正しました」と1行足す

　これで終わりです。むしろ、直した記録が残っている記事のほうが、誠実に見えます。

　もう1つ。「初学者向けに書いています」「学習の記録です」と冒頭に書いておいて構いません。予防線ではなく、読者への案内です。誰に向けた記事かを最初に書くのは、良い記事の作法でもあります。

　そして、いちばん大事なこと。下手であることと、不誠実であることは、まったく違います。

• 下手な記事：説明が回りくどい。図がない。用語の使い方がぎこちない。これは、誰もが最初に通る道です。問題ありません

• 不誠実な記事：自分で試していないのに試したように書く。調べずに書く。他人の記事をそのまま写す。これは、避けてください

　避けるべきなのは、後者だけです。前者を恐れて書かないことのほうが、はるかに損をします。

3. 技術ブログを、就活で見られる形にする3つの軸

　学生時代の技術ブログを、就活で見られる強い成果物にするには、3つの軸を意識します。

3-1. 軸1：世界に開いていること（公開性）

　ブログは、検索エンジンで見つかる公開の場に置いてください。ログインしないと読めない場所、限られた仲間だけが読める場所は、就活の書類選考の場面では届きません。フェーズ2-2で扱った公開性の原則が、ここでも同じ形で効いてきます。

　学生時代のみなさんが選びやすいプラットフォームには、次のようなものがあります。それぞれ、公開の場としての強度は十分にあります。

• Zenn：技術記事とスクラップ、書籍形式にも対応。GitHub連携でMarkdownでも管理できる。エンジニア向けの読者層が厚い

• Qiita：長年の蓄積で、日本語圏の技術記事のプラットフォームとして広く読まれている

• はてなブログ：技術ブログの定番の一つ。個人のエンジニアが長年書き続けている例が多い

• note：技術記事だけでなく、キャリアや働き方の記事も書きやすい。エンジニア以外の読者にも届く

• Medium：英語圏の技術記事プラットフォーム。海外志向の学生さんが英語で発信する入口になる

• Dev.to：英語圏のエンジニアコミュニティに強い、CC BY-SA でオープンなプラットフォーム

• Substack：ニュースレター形式で継続的な発信に向く

• 独自ドメインの静的サイト：自分でサイトを組んで公開する道もあります。ただし、これは2本目3本目以降の話です。ドメインの取得には年間の費用がかかります。最初の1本は、上のどれかで十分です

　複数のプラットフォームに書き分けてもよいですし、1つに集中してもよいです。大切なのは、公開の場に、継続的に、記事が積み上がっていることです。

3-2. 軸2：質と誠実さ（内容）

　2-4で書いたとおり、下手であることと、不誠実であることは違います。ここで言う「質」は、文章のうまさではありません。自分でやったかどうかです。

　読まれる技術ブログには、いくつかの共通点があります。最初の1本で全部を満たす必要はありません。1つでも入っていれば、記事として成立します。

• 自分で手を動かしている：書いたコード、動かした結果、出たエラー。ここがいちばん大事です

• 詰まった箇所を書いている：うまくいった話だけでなく、止まった場所を書く。読者にいちばん役立つのは、ここです

• 公式のドキュメントを見ている：他人の記事を写すのではなく、公式の説明を一度は開く。開いたページのURLを貼れば、それが参考文献になります

• 参考にしたものを書いている：見た記事やページのリンクを、末尾に並べるだけで十分です

　AIとの付き合い方は、7章にまとめました。

3-3. 軸3：継続していること（連続性）

　続いていることは、確かに伝わります。数か月にわたる記事の一覧が並んでいると、学び続ける人だということが、中身を読む前に伝わります。

　ただし、週1本を目指す必要はまったくありません。まず1本です。1本あれば、面接でその話ができます。そのあと、書けるときに2本目を書けば十分です。月1本でも、3か月に1本でも、続いていることに変わりはありません。

4. 何を書くか。書きやすい6つの型

　「何を書けばいいか分からない」という声を、よく聞きます。書きやすい型を6つ挙げます。

　最初の1本は、型2をおすすめします。いちばん書きやすく、あなたにしか書けないからです。

　そして、ネタが思いつかないなら、今週詰まったことを3つ、メモに書き出してみてください。それが在庫になります。詰まった直後に1行残しておくのが、いちばん確実な題材の作り方です。

4-1. 型1：授業や技術書の学びを、自分の言葉で再構成する

　フェーズ2-3、フェーズ2-4で扱ったとおり、授業と技術書は、学生時代のもっとも大きな学びの源です。ここで学んだ概念を、初めて学ぶ人にも読める形で書き直します。

　難しい題材である必要はありません。「授業で習った◯◯を、自分の言葉で説明してみる」で十分です。ソートのアルゴリズム、データベースの索引、HTTPの仕組み。授業で一度は理解したはずのことを、何も見ずに書いてみると、分かっていなかった場所が自分で見つかります。そこが、記事のいちばん面白い部分になります。

4-2. 型2：詰まった箇所と、その乗り越え方を書く

　これがいちばん書きやすい型です。しかも、2-2の4つの型（詰まった→調べた→試した→学んだ）が、そのまま使えます。

　題材は、小さくて構いません。「開発環境の構築で半日溶かした話」。「ビルドが通らなかった原因が、結局スペル間違いだった話」。「SQLで思ったとおりの結果が出なかったとき、どこを見たか」。授業や課題で詰まったことなら、何でも題材になります。

　むしろ、小さくて恥ずかしいと思う詰まり方ほど、同じところで止まる人が多い。だから役に立ちます。

4-3. 型3：新しい技術を、公式ドキュメントを追いながら試す

　公式のドキュメントを読み、自分で試し、書き残す。シンプルですが、強い型です。新しいライブラリでも、使ったことのないコマンドでも構いません。

　公式を起点にすると、事実が正確になりやすく、他人の記事の引き写しにもなりません。「公式のこのページを読んで、こう書いたら動いた」で1本になります。

4-4. 型4：OSSのソースコードリーディング

　公開されているソフトウェアのコードを読み、自分の言葉で説明する型です。難易度は高めなので、2本目3本目以降で構いません。

　大きなものに挑む必要もありません。自分が使っている小さなライブラリで十分です。「よく使っているこの関数は、中で何をしているのか」。1つの関数を追うだけでも、1本になります。

4-5. 型5：品質・テストの学びを言語化する

　授業の課題でも、テストを書いて初めて気づいたことがあるはずです。「テストを書いたら、仕様のあいまいさに自分で気づいた話」「動いていたつもりのコードが、境界の値で落ちた話」。

　バグを見つけたときは、どうやって再現させたかを書くだけで、良い記事になります。この題材を書く学生さんは多くありません。詳しくは5章に書きました。

4-6. 型6：就活の学びを、就活が終わってから書く

　就活期に感じたこと、面接で聞かれた質問、自分が調べて分かったIT業界の実像。就活の学びは、就活の当事者にしか書けない一次情報です。就活が終わってから、時間を置いて、感情を整理してから、公開できる範囲で書き残すと、次の学生さんの入口になります。

　あなたが書いた1本が、次の年の後輩の役に立つことは、十分に起こり得ます。

5. 品質・テストを題材にすると、書ける人が少ない

　4-5で触れた品質・テストを、もう少しだけ展開します。私自身が最も専門とする領域なので、ここだけ詳しくなります。興味がなければ、6章に飛んでください。

　このテーマを勧める理由は1つです。就職してから使う知識なのに、学生のうちに書いている人が少ない。だから、書けば残ります。

5-1. テスト設計技法を、1つ試して1本書く

　ソフトウェアテストには、テスト設計技法と呼ばれる、考え方の道具箱があります。代表的なものを2つだけ挙げます。

• 同値分割：入力値を、同じ挙動になるグループに分けて、各グループから1つ選んでテストする

• 境界値分析：仕様の境目（0、1、最大値、最大値＋1など）でバグが出やすいことを利用してテストする

　この2つは、授業の課題にもそのまま使えます。自分が書いた関数に、この考え方でテストを書いてみる。それだけで1本になります。「境界の値で落ちた」という発見があれば、なお良い記事です。

　他にも技法はありますが、最初は1つで十分です。全部を知ってから書く必要はありません。

5-2. 学習の記録を、章ごとに1本ずつ書く

　JSTQB Foundation Level のシラバスは、JSTQBの公式サイトで無料公開されています。テストの教科書のようなものです。読むだけならお金はかかりません（試験を受ける場合は受験料がかかります）。

　これを1章ずつ読んで、章ごとに1本書く。連載の形になるので、ネタが尽きません。「何を書くか」で毎回悩まなくて済むのが、この型の利点です。

5-3. テストを書いた記録を書く

　画面の操作を通して確かめるE2Eテスト（アプリを、人が使うのと同じ順序で自動的に動かして確かめるテストです）を、1回だけでも書いてみる。詰まった箇所と乗り越え方を1本にすると、書いている学生さんが少ないぶん、残ります。

　あるいは、直したバグが再発しないことを確かめるテストを1本足す。「バグを直す→そのバグを捕まえるテストを1本書く」。この流れを記事にすると、品質を仕組みで守る姿勢が伝わります。

5-4. 2-2の4つの型に、品質の観点を足す

　2-2の型（詰まった→調べた→試した→学んだ）に、品質の観点を足すと、バグの体験記が一段深くなります。

• なぜこのバグが起きたか（原因の分析）

• 再現させるテストを、どう書いたか（テストの設計）

• 同じ種類のバグを、他の場所でも探したか（1つ見つかった場所には、たいてい他にもあります）

　「知っている」ではなく「試した」。「試した」ではなく「詰まった」。「詰まった」ではなく「乗り越えて言語化した」。この階段を1段ずつ登る記事は、書き手の学びも、読者への価値も、いちばん大きくなります。

6. 書いたら、どこにリンクを置くか

　書いたブログは、フェーズ2-5で扱ったGitHubプロフィールREADMEに、リンクを添えてください。GitHubのアカウントページを開いた採用担当者が、そこから技術ブログにも辿れるようにしておく。これが、公開の場のハブとしてのGitHubの使い方です。

　さらに、次のような場所にもリンクを整えます。

• Zenn / Qiita / はてなブログのプロフィール欄：X、GitHub、独自ドメインへの相互リンクを整える

• X（旧Twitter）のプロフィール欄と固定ポスト：主要記事のリンクを固定しておく

• LinkedIn のプロフィール：海外志向がある場合、LinkedInにも記事へのリンクを整える。日本国内の就活でも、Wantedly、YOUTRUST、Findy などのプロフィール欄に、技術ブログのURLを載せる

• Speaker Deck / Docswell のアカウントページ：登壇スライドと並べて、関連する技術記事のリンクを添える

　あなたの名前を検索したときに、複数の場所からあなたの技術発信に辿り着ける。この状態が、公開性のいちばん強い形です。

7. AIと、技術ブログ

　いま学生時代を過ごすみなさんは、AIコーディングアシスタントと共に技術を学ぶ最初の世代です。技術ブログでも、AIとの向き合い方は、少し丁寧に整えておく必要があります。

• AIに下書きを作らせて、そのまま公開しない：これは、あなたの学びを深めず、公衆にとっても価値が低い記事になります

• AIに聞いた結果は、自分で試してから書く：試していないことを、試したように書かない。ここだけ守れば大丈夫です

• AIを使った過程も、そのまま書いてよい：「AIに聞いたら◯◯と言われたが、自分で試したら別の原因だった」。この道筋こそが、いま書く価値のある記事です。AIを使ったことを隠す必要はありません

• 参考にしたものを書く：AIの提案、公式ドキュメント、読んだ他人の記事。並べておけば、記事の信頼性が上がります

8. 書く発信を大切にする会社は、業務時間の中に執筆を置いている

　ここからは、会社の側を見ます。書く発信を、業務としてどう扱っているか。

　学び続ける環境を持つ会社は、社員が技術ブログを書く時間を、業務のなかに確保していることが多いと感じます。公式の技術ブログがある。社員個人のブログを歓迎する文化がある。業務時間内に書くことを認めている。社内で書きかけの記事をレビューし合う場がある。

　ただし、公式の技術ブログを持っているのは、対外発信の文化が育ちやすい一部の会社に偏っています。受託中心で守秘義務の範囲が広い会社、そもそも広報に人を割けない会社では、技術ブログという形そのものが成立しにくい。技術ブログを持たない会社が、技術力や育成環境で劣っているとは限りません。

　見るところは2つです。公式の技術ブログがあるか。そして、その書き手が、特定の1人に偏っていないか。書き手が複数に散っていれば、執筆が個人の趣味ではなく、業務の中に置かれていると読めます。

　個人の発信を「業務外の趣味」ではなく、会社の技術文化の一部として扱っているか。ここは、社員の名前と会社の名前が並んで社外に見えるかどうかに、そのまま表れます。

まとめ

　本記事では、技術ブログで学びを言語化するお話をしました。要点は次のとおりです。

　最初の1本は、1,500字から2,000字で十分です。構成は「詰まった→調べた→試した→学んだ」の4つ。題材は、授業や課題で詰まったことで構いません。むしろ、小さくて恥ずかしいと思う詰まり方ほど、同じところで止まる人が多い。

　下手であることと、不誠実であることは違います。説明が回りくどいのも、図がないのも、誰もが最初に通る道です。避けるべきは、調べずに書くことだけ。そして、技術記事は公開したあとから直せます。間違いを指摘されたら、直して「◯月◯日追記：修正しました」と1行足す。それで終わりです。

　週1本を目指す必要はありません。まず1本。1本あれば、面接でその話ができます。月1本でも、3か月に1本でも、続いていることに変わりはありません。

　そして、自分より詳しい人がいても、あなたが書く意味はあります。詳しい人は、初心者がどこで詰まるかを、もう忘れているからです。

　次のフェーズ2-9では、書く発信と並ぶもう一つの発信軸として、技術イベントや勉強会で、発表するというお話に進みます。

エンジニアの卵のみなさんへ、エール

　書くという行為は、思考を掴む、いちばん地味で強い方法です。

　そして、最初の1本の前には、必ずあの声が聞こえます。「こんなことを書いていいのだろうか」「もっと詳しい人がいるのに」。私にも聞こえましたし、いまも書く前には聞こえます。

　その声に、1つだけ返す言葉を置いておきます。あなたがいま詰まっている場所を書けるのは、いま詰まっているあなただけです。半年後のあなたには、もう書けません。

　今週、なにか一つ、始めてみてください。今週詰まったことを、3つメモに書き出す。それだけでいい。書くと決めなくて構いません。

　もう一歩進めるなら、そのうち1つを、2-2の4つの見出しに沿って書いてみる。公開しなくても大丈夫です。下書きのまま置いておけます。

　公開ボタンは、書き終えてから考えれば十分です。

　一緒に歩きましょう。ボン・ボヤージュ。素敵な旅を。

次の記事は、フェーズ2-9「技術イベントや勉強会で、発表する。5分のLTから、第三者の目利きを通す」です。

この連載を読むにあたって

　事実の確認について。 法令・統計・制度の記述は、一次情報にあたって確認し、出典のリンクを各記事の末尾に置いています。それでも、誤りが混じっている可能性は、ゼロではありません。数字と法令は、リンク先の原典で確かめてから使ってください。確かめる手間ごと、この連載がお渡ししたいものです。

　調査の時点について。 記事中の法令・統計・制度は、2026年9月15日時点で確認したものです。法令は改正され、統計は毎年更新されます。読んでいる時点との差は、ご自身で埋めてください。

　生成AIの利用について。 この連載は、調査と推敲に生成AIを使っています。

　最後は、ご自身で判断してください。 就職活動は、みなさんの人生の大きな選択です。この連載がお渡しするのは、判断の物差しであって、判断そのものではありません。物差しを当てるのは、みなさん自身です。

　そして、一人で抱えないでください。 相談先があります。大学のキャリアセンター。新卒応援ハローワークは全国56か所にあり、すべて無料で、専任の就職支援ナビゲーターが担当者制でついてくれます。労働条件のことは、総合労働相談コーナー（都道府県労働局や労働基準監督署などに全国378か所）でも相談できます。

#エンジニア就活 #技術ブログ #Zenn #Qiita #エンジニア志望 #技術広報 #エンジニアの卵に贈る就活の書

関連記事・参考文献等

本記事で挙げた、学生が使える情報源

• Zenn

• Qiita

• JSTQB 認定テスト技術者資格 シラバス

シリーズ関連

• 新卒ITエンジニア 新卒研修シラバス

• 新卒エンジニア、観察ノートを開く（上巻）　観察を、始める

• 新卒エンジニア、観察ノートを開く（中巻）　両輪を、回す

• 新卒エンジニア、観察ノートを開く（下巻）　道を、選び取る