【フェーズ2-8】 技術ブログで、学びを言語化する。書く発信で、読める形の記事として残す 【ITエンジニアの卵に贈る、就活の書】
この記事は「ITエンジニアの卵に贈る、就活の書」シリーズの一本です。シリーズ全体の目次はこちら（扉記事）からご覧いただけます。
エンジニアを目指す学生のみなさん、こんにちは。クオリティアーツの池田です。
ITエンジニアの卵に贈る、就活の書・フェーズ2-8の記事です。前回のフェーズ2-7では、就活と学業と個人開発を束ねる時間設計の話をしました。今回はフェーズ2「作る」の実践各論11本のうちの6本目として、技術ブログで、学びを言語化するというお話です。
技術ブログは、コードとは違う軸で、あなたの学びと考え方を、世界に開いておく場所です。GitHubに残したコードが「何を作ったか」なら、技術ブログは「なぜ作ったか、どう考えたか、何を学んだか」を残す場所です。就活の書類選考の担当者は、コードとブログの両方を見て、あなたの技術的な思考の型を推し量ります。
新卒の就活中の方はもちろん、第二新卒として他社の面接に臨む場面でも、技術ブログの積み上げは、そのまま面接での対話の素材になります。
1. 技術ブログは、プロフェッションとしての言語化訓練
序章-1で紹介したIEEE-CS/ACMのソフトウェアエンジニア倫理綱領・第8原則は、自己（Self）の継続的な自己研鑽と、専門知識の共有を求めています。SWEBOK v4.0の18の知識領域のなかには、ソフトウェアエンジニアリング・プロフェッショナル・プラクティスという領域があり、そこでは知識の伝達と共同作業の重要性が明確に位置づけられています。
技術ブログを書くという行為は、この視座から見ると、プロフェッションとしての言語化訓練そのものです。自分が学んだこと、詰まった箇所、乗り越えた工夫を、初めて読む他人にも伝わる形に翻訳する。この翻訳の作業を通じて、あなた自身の理解が深まり、次に学ぶ誰かの入口になります。
世界のエンジニアが集まる場所では、書くことが仕事の一部として組み込まれています。Google Engineering Blog、Meta Engineering、Netflix Tech Blog、Stripe Engineering、GitHub Blog、Cloudflare Blog、Anthropic Blog、OpenAI Blog、Vercel Blog、Datadog Blog、Airbnb Tech Blog、Uber Engineering。
世界基準の会社ほど、社員のエンジニアが技術ブログを書き、その文化が組織の中心にあります。
2. 技術ブログを、就活で見られる形にする3つの軸
学生時代の技術ブログを、就活で見られる強い成果物にするには、3つの軸を意識します。
2-1. 軸1：世界に開いていること（公開性）
ブログは、検索エンジンで見つかる公開の場に置いてください。ログインしないと読めない場所、限られた仲間だけが読める場所は、就活の書類選考の場面では届きません。フェーズ2-2で扱った公開性の原則が、ここでも同じ形で効いてきます。
学生時代のみなさんが選びやすいプラットフォームには、次のようなものがあります。それぞれ、公開の場としての強度は十分にあります。
Zenn：技術記事とスクラップ、書籍形式にも対応。GitHub連携でMarkdownでも管理できる。エンジニア向けの読者層が厚い
Qiita：長年の蓄積で、日本語圏の技術記事のプラットフォームとして広く読まれている
はてなブログ：技術ブログの定番の一つ。個人のエンジニアが長年書き続けている例が多い
note：技術記事だけでなく、キャリアや働き方の記事も書きやすい。エンジニア以外の読者にも届く
Medium：英語圏の技術記事プラットフォーム。海外志向の学生さんが英語で発信する入口になる
Dev.to：英語圏のエンジニアコミュニティに強い、CC BY-SA でオープンなプラットフォーム
Substack：ニュースレター形式で継続的な発信に向く
独自ドメインの静的サイト：Astro、Next.js、Hugo、Jekyll などで組み、GitHub Pages、Vercel、Cloudflare Pagesにデプロイ。独自ドメインで技術ブログを持つこと自体が、書類選考でのそこそこ強い技術的シグナルになります
複数のプラットフォームに書き分けてもよいですし、1つに集中してもよいです。大切なのは、公開の場に、継続的に、記事が積み上がっていることです。
2-2. 軸2：質と誠実さ（内容）
書けばよい、というわけではありません。フェーズ2-2で触れた「質」の話は、技術ブログにも同じように効いてきます。質の低い記事を大量に公開することは、かえってあなたの評価を下げるということも、覚えておいてください。
質の高い技術ブログには、いくつかの共通点があります。
一次情報にあたっている：公式ドキュメント、RFC、W3C勧告、論文、企業の公式ブログを、まず自分で読んでから書く
他の記事の引き写しになっていない：既存の記事を要約するだけの記事は、書いた本人の学びを深めず、読者の役にも立ちにくい
実装や実験を伴っている：概念の説明だけでなく、自分で書いたコード、動かした結果、GitHubリポジトリへのリンクが添えられている
詰まった箇所と、その乗り越え方を書いている：完璧な成功だけを書くのではなく、詰まった箇所と、そこをどう解決したかを丁寧に書く記事は、読者にも書き手にも学びが大きい
参考文献を明示している：出典と参考リンクを明記する。これは、フェーズ2-2で触れた「事実優先」の原則の実践
生成AIの登場で、技術記事の質のばらつきが広がっています。ChatGPT、Claude、Gemini、Perplexity といったツールで下書きだけを作って、そのまま公開してしまう記事も増えています。
AIに手伝ってもらうこと自体は問題ありません。ただし、公開する前に、自分の手で実装し、自分の言葉で書き直し、自分で事実確認をしてください。フェーズ2-4で扱ったAIツールとの向き合い方が、ここでもそのまま活きてきます。
2-3. 軸3：継続していること（連続性）
1本の名記事も価値がありますが、続いているということは、それ以上に強いシグナルになります。書類選考の担当者があなたのZennやQiitaのプロフィールを開いたとき、そこに数ヶ月から数年にわたる記事の一覧が並んでいると、あなたが学び続けるエンジニアであることが、記事の中身を読む前に伝わります。
継続の入口としては、フェーズ2-7で触れた週1本のリズムをおすすめします。長い記事を月に1本より、短くても実装を含む記事を週に1本のほうが、GitHubのContributionsグラフと並んで、学生時代の日常性を伝えます。
3. 何を書くか。学生さんが書きやすい6つの型
「何を書けばいいか分からない」という学生さんは多いです。書きやすい型を6つ、紹介します。
3-1. 型1：授業や技術書の学びを、自分の言葉で再構成する
フェーズ2-3、フェーズ2-4で扱ったとおり、授業と技術書は、学生時代のもっとも大きな学びの源です。ここで学んだ概念を、初めて学ぶ人にも読める形で書き直します。
たとえば「TCPの輻輳制御アルゴリズム（Reno、CUBIC、BBR）を比較する」「BツリーとLSMツリーの使い分け」「Transformerのself-attentionを、行列演算から丁寧に追う」「イベントループを、Node.jsとDenoのコードで追う」「フェーズ2-4で読んだテストの技術書を、自分の個人開発に適用してみた話」。
授業のノートや技術書の該当章を、自分の視点で再構成すると、それだけで質の高い1本になります。
3-2. 型2：詰まった箇所と、その乗り越え方を書く
個人開発やハッカソン、授業の演習で詰まった箇所と、その解決策を書く記事は、学生さんが最も書きやすく、読者にも役立つ型です。「Next.js App Routerで◯◯を実装したときに詰まった話」「PyTorchのDataLoaderで◯◯にハマった」「RustのライフタイムをTypeScriptから来た自分がどう理解したか」。同じところで詰まる次の学生さんに、あなたの記事が入口になります。
3-3. 型3：新しい技術を、公式ドキュメントを追いながら試す
公式ドキュメントを一次情報として読み、自分で試し、自分の手で書き残す。この型は、シンプルですが強いです。「Cloudflare Workersで◯◯を作る手順」「Anthropic ClaudeのAPIで、簡単なチャットボットを作る」「PyTorchの新機能を、公式ドキュメントに沿って試す」「Deno 2 の Web 標準APIを、Node.jsと比較する」。
公式ドキュメントを起点にすると、事実の正確性が担保されやすく、二次情報の引き写しにもなりにくい、というメリットがあります。
3-4. 型4：OSSのソースコードリーディング
世界のOSSのコードを、自分で読み、自分の言葉で解説する。この型は、書き手にとって最高の学習になり、読者にも強く伝わる型です。Next.js、React、Vue、Svelte、Deno、Node.js、PyTorch、FastAPI、Rustc、Go、Kubernetes。世界を支えるOSSは、GitHub上で公開されていて、あなたも読むことができます。
読んだ結果を、READMEの図解、コードの要約、設計判断の考察として書く。フェーズ2-12で扱うコミュニティに参加する動機にもつながり、フェーズ2-5で触れた「OSSへの小さな貢献」の入口にもなります。
3-5. 型5：品質・テストの学びを言語化する
個人開発やハッカソンで、テストを書いて初めて気づいたことは、独立した型になるくらい書きやすいテーマです。「テストを書いたら、仕様のあいまいさに自分で気づいた話」「テストがなかった状態でリファクタリングして壊した話と、そこから学んだこと」「境界値分析・同値分割という技法を知って、テストケースの考え方が変わった話」。
バグを見つけたときは、再現条件を言語化する過程そのものが、良い記事の題材になります。「なぜこのバグが起きたか」「再現するテストをどう書いたか」「テストがある状態とない状態で、修正のしやすさがどう変わったか」。品質やテストは地味に見られがちなテーマですが、正確に言語化できる学生さんは、実はそれほど多くありません。だからこそ、書く価値があります。
3-6. 型6：就活の学びを、就活が終わってから書く
就活期に感じたこと、面接で聞かれた質問、自分が調べて分かったIT業界の実像。就活の学びは、就活の当事者にしか書けない一次情報です。就活が終わってから、時間を置いて、感情を整理してから、公開できる範囲で書き残すと、次の学生さんの入口になります。
このシリーズ自体、私自身の就活支援と自社での育成の経験を書き残そうとしているものです。あなたが書いた1本が、5年後の後輩の入口になることは、十分に起こり得ます。
4. 品質・テストの学びを、技術ブログで言語化する型
型5で触れた品質・テストのテーマを、もう少し具体的に展開します。私自身が最も専門とする領域であり、また、学生時代からこのテーマで発信している人が実は多くない領域でもあります。書ける学生になるだけで、書類選考での差別化がしやすくなる、狙い目のテーマです。
4-1. テスト設計技法を1つずつ試して、記事にする
ソフトウェアテストの世界には、テスト設計技法と呼ばれる、体系化された考え方の道具箱があります。ISTQBやJSTQB（Japan Software Testing Qualifications Board）のFoundation Level Syllabusで扱われる技法は、そのまま技術ブログの題材になります。
同値分割 (Equivalence Partitioning)：入力値を同じ挙動を示すグループに分け、各グループから代表値を選んでテストする
境界値分析 (Boundary Value Analysis)：仕様の境目（0、1、最大値、最大値+1など）でバグが出やすいことを利用してテストする
状態遷移テスト (State Transition Testing)：状態の遷移図を書き、遷移の1つ1つをテストする
デシジョンテーブルテスト (Decision Table Testing)：条件と結果の組み合わせを表にして、抜けなくテストを設計する
原因結果グラフ (Cause-Effect Graphing)：入力と出力の論理関係を図にしてテストケースを導く
ペアワイズテスト (All-Pairs Testing)：パラメーターの組み合わせ爆発を、実務的な数に抑える
これらを、Vitest、Jest、pytest、Go の testing パッケージ、JUnit などの言語標準のテストツールで実際にコードとして書いてみて、詰まった箇所とともに1本の記事にする。
「Vitestで境界値分析を素朴に書いてみた」「pytestのパラメトライズで同値分割を試した」「状態遷移テストを、TypeScriptの状態機械（XState）に対して書いた」といった記事は、GitHubリポジトリへのリンクを添えて公開すると、書類選考の担当者に、テスト設計技法を実践的に理解している学生であるという確かな印象を残します。
4-2. ISTQB／JSTQB学習の記録を、章ごとに1本ずつ書く
JSTQB Foundation Level のSyllabusは、JSTQBの公式サイトで無料公開されている100ページ強の文書です。ISTQBのSyllabusも同様に、ISTQBの公式サイトから無料でダウンロードできます。
この教科書を、1週間で1章ずつ読み、章ごとに1本のブログにする。たとえば「JSTQB Foundation Level 第1章 テストの基礎を読んだ記録」、「同 第2章 ソフトウェア開発ライフサイクル全体を通してのテスト」、というような連載型の技術ブログは、学生時代の日常性と体系的な学びを、同時に伝えます。ISTQBは世界共通の認定資格でもあり、Foundation Level受験の学習記録としても、記事の価値が残ります。
4-3. E2Eテスト、リグレッションテストの実装記録を書く
単体テストから一歩踏み出して、画面操作を通したE2Eテスト（End-to-End Testing）を書く経験は、学生時代のうちに1回だけでもしておくと、就活での説得力が違います。Playwright、Cypress、Puppeteer などの世界標準のE2Eテストツールを、個人開発のアプリに対して1つ書いてみる。
詰まった箇所（要素の待ち方、非同期処理、テストの遅さ、フレーキーテスト）と、その乗り越え方を、1本の記事にする。たとえば「Playwrightで初めてE2Eテストを書いた記録」は、実は書ける学生がとても少ない、貴重な1本になります。
同様に、過去に直したバグが再発しないことを確かめるリグレッションテストを、バグ修正のたびに1本追加する運用を、個人開発で試してみる。「バグを直す→そのバグが再発しないテストを1本追加する→GitHub Actionsで自動で回す」の一連の流れを1本の記事にすると、就活の書類選考の担当者に、品質を仕組みで守る姿勢がしっかり伝わります。
4-4. 「詰まった→調べた→試した→学んだ」の型に、品質観点を織り込む
型2で触れた「詰まった箇所と、その乗り越え方」の型に、品質・テストの観点を織り込むと、単なるバグ体験記が、テスト文化への入門記事に変わります。「なぜこのバグが起きたか（原因分析）」「再現するテストをどう書いたか（テスト設計）」「テストがある状態とない状態で、修正のしやすさがどう変わったか（Testability）」「同じクラスのバグを、他の場所でも探したか（バグの群れ）」。この4つの観点を意識するだけで、記事の深さが一段変わります。
私自身、25年エンジニアの世界を歩いてきた中で、技術ブログで最も反響が大きかったのは、テスト設計技法を自分の手で試して、詰まった箇所を正直に書いた記事でした。「知っている」ではなく「試した」、「試した」ではなく「詰まった」、「詰まった」ではなく「乗り越えて言語化した」。この階段を1段ずつ登る記事は、書き手の学びも、読者への価値も、いちばん大きくなります。
4-5. 世界基準の道具立てと、その対極
ここで、書く場所とスタックの話にも一言触れます。世界の技術ブログのプラットフォームは、書き手の道具立てにも一定の傾向があります。Zenn、Qiita、はてなブログのような日本の主要プラットフォームは、そのまま使えば十分ですが、もう一歩進むなら、GitHub Pages、Vercel、Cloudflare Pages上にAstroやNext.js、Hugo、Jekyllで組んだ独自ドメインの技術ブログを持つ道もあります。
海外のエンジニアの多くは、独自ドメインで技術ブログを持ち、Markdownソースを自分のGitHubリポジトリで管理し、Pull Requestベースで記事を更新しています。この道具立て自体が、書類選考での確かなシグナルになります。
いっぽう、日本の一部の技術ブログには、Windows Server + IIS + ASP.NET Framework 4.x（.NET Coreへの移行前の世代）+ WebForms の運用ノート、Struts + JSP + Servlet の改修事例、jQuery依存フロントエンドの保守記録など、レガシー環境の保守記録に寄った内容の記事群もあります。繰り返しますが、これらの保守は社会インフラを支える重要な仕事で、正確に書かれた保守記録には一定の需要があります。
それでも、就活で「学びのアクティブさ」を示す軸としては、こうした保守記録だけでは足りません。新しい世界基準の道具立て（TypeScript + Next.js、Go + Docker、Rust、Python + FastAPI、Playwright、GitHub Actions など）に触れた記事を、少なくとも数本は混ぜて公開しておく。この重ね方が、あなたの技術ブログの厚みを、書類選考の担当者にはっきり伝えます。
5. 書いたら、どこにリンクを置くか
書いたブログは、フェーズ2-5で扱ったGitHubプロフィールREADMEに、リンクを添えてください。GitHubのアカウントページを開いた採用担当者が、そこから技術ブログにも辿れる導線を作っておくのが、公開の場のハブとしてのGitHubの使い方です。
さらに、次のような場所にもリンクを整えます。
Zenn / Qiita / はてなブログのプロフィール欄：X、GitHub、独自ドメインへの相互リンクを整える
X（旧Twitter）のプロフィール欄と固定ポスト：主要記事のリンクを固定しておく
LinkedIn のプロフィール：海外志向がある場合、LinkedInにも記事へのリンクを整える。日本国内の就活でも、Wantedly、YOUTRUST、Findy などのプロフィール欄に、技術ブログのURLを載せる
Speaker Deck / Docswell のアカウントページ：登壇スライドと並べて、関連する技術記事のリンクを添える
あなたの名前を検索したときに、複数の場所からあなたの技術発信に辿り着ける。この状態が、公開性のいちばん強い形です。
6. AIコーディング時代の技術ブログの書き方
いま学生時代を過ごすみなさんは、AIコーディングアシスタントと共に技術を学ぶ最初の世代です。技術ブログでも、AIとの向き合い方は、少し丁寧に整えておく必要があります。
AIに下書きを作らせて、そのまま公開しない：これは、あなたの学びを深めず、公衆にとっても価値が低い記事になります
AIに聞いた結果は、自分で試し、自分の手で書き直し、自分で事実確認する：フェーズ2-4で扱った3拍子（読む→作る→書き残す）が、AI時代でも変わりません
AIを使った過程を、記事の中で誠実に書く：「Claude Codeにこのエラーの原因を聞いたところ、◯◯を提案された。自分で試したところ、◯◯という別の原因が見つかった」というような、思考の道筋を含む記事は、AI時代の新しい強い型になります
参考にした情報源を明示する：AIが提案した内容、参考にした公式ドキュメント、読んだ他人のブログ、GitHubの該当コミット。すべてを明示すると、記事の信頼性が上がります
Anthropic、OpenAI、Google、Meta、xAI などの生成AI企業は、いずれも公式ブログで「AIとの共同作業をどう記述するか」を継続的に発信しています。学生時代からこの視座を持って書くことが、社会人になってからのプロフェッションとしての発信の土台になります。
7. プロフェッションとして育つ環境を持つ会社は、書く発信を大切にしている
シリーズ全体を貫く上位原則を、この記事でも確認します。その会社は、エンジニアをプロフェッションとして育つ環境を持っているか。
プロフェッションとして育つ環境を持つ会社は、多くの場合、社員エンジニアが技術ブログを書くことを、経営として支えています。会社の公式技術ブログを持っている、社員個人の技術ブログを歓迎する文化がある、業務時間内に記事執筆の時間を取ることを認めている、社内勉強会で書きかけの記事をレビューし合う場がある、Zenn Publications や Qiita Organizations などの会社アカウントを運用している。
株式会社サイバーエージェント、株式会社ディー・エヌ・エー（DeNA）、株式会社メルカリ、株式会社リクルート、株式会社ZOZO、GMO インターネットグループ株式会社、SmartHR株式会社、freee株式会社、株式会社カヤック、はてな株式会社、Sansan株式会社、株式会社エムスリーなど、多くの会社が公式技術ブログを継続的に運営しています。
ただし、ここに挙がるのは、対外的な発信文化が育ちやすいメガベンチャーやWeb・SaaS系の会社に偏っています。実際にエンジニアを目指す学生さんの多くは、人数の割合で見れば、こうした会社ではなく、メーカー系・地方・中堅・中小企業に就職していきます。技術ブログを持たない会社が、技術力や育成環境で劣っているとは限りません。対外発信の文化がまだ育っていないだけの会社も多くあります。この実例リストは、あくまで「良い技術ブログの具体的なイメージを持つための一部の例」として受け取ってください。
募集要項の中に、技術ブログの実績や、公式技術ブログのURLが自然に登場するかどうか。これは、その会社が書く発信をどう捉えているかの、いちばん地味で正直なシグナルの一つになります。
入社後の話にも一言だけ触れておきます。良い会社では、社員の個人技術ブログを、業務評価の対象として位置づけています。ブログの執筆時間を業務時間の一部として認める、社内Slackで発信を共有する、社員の登壇や執筆を採用ページで紹介する。個人の発信を「業務外の個人活動」ではなく、会社の技術文化の一部として扱う姿勢が、社員の名前と会社の名前が並んで社外に見える形として現れます。応募先を眺めるときに、社員の技術ブログの活発さと、会社としての発信支援の姿勢を、併せて確かめてみてください。
まとめ
本記事では、技術ブログで学びを言語化するお話をしました。要点は次のとおりです。
プロフェッションとしての言語化訓練は、IEEE-ACM第8原則やSWEBOKのProfessional Practicesにつながる実践です。就活で見られる3つの軸は、世界に開いていること、質と誠実さ、継続していること。学生さんが書きやすい6つの型は、授業や技術書の再構成、詰まった箇所と乗り越え方、公式ドキュメントを追う、OSSソースコードリーディング、品質・テストの学びの言語化、就活の学びです。
品質・テストの言語化は、同値分割・境界値分析・状態遷移テスト・デシジョンテーブルといったテスト設計技法を1つずつ試して記事にする、ISTQB／JSTQB Foundation Level Syllabusを章ごとに読んで記録する、Playwrightで初めてE2Eテストを書いた記録を残す、といった具体の型があります。
書いたら、GitHub Profile READMEを軸に、X、LinkedIn、Wantedly、YOUTRUST、Findy、Speaker Deckへ相互リンクを置いてください。世界基準の道具立て（Astro、Next.js、Hugo、Cloudflare Pages、Playwright、GitHub Actions）に触れた記事も、少なくとも数本は混ぜて公開しておきましょう。AI時代の書き方としては、下書き丸投げをやめ、思考の道筋も含めて誠実に書くこと。育つ環境の会社は、業務時間内の執筆、公式技術ブログ、社内レビュー文化を経営として支えています。
次のフェーズ2-9では、書く発信と並ぶもう一つの発信軸として、技術イベントや勉強会で、発表するというお話に進みます。
エンジニアの卵のみなさんへ、エール
書くという行為は、思考の解像度を上げる、いちばん地味で強い方法です。私自身、ソフトウェアテストのブログを2000年代前半から書き続けてきました。技術書『マインドマップから始めるソフトウェアテスト』も、その延長線上の1つの成果物です。
書き始めるまでは、腰が重いです。「こんなことを書いていいのだろうか」「もっと詳しい人がいるのに」という声が、自分の中から自然に聞こえます。ただ、書き始めてしまえば、その声は、次に書きたいテーマの声にゆっくり変わっていきます。
今週、なにか一つ、書いてみてください。今学期の授業で学んだ概念を1つ選び、Zennに1本記事にする。フェーズ2-4で読んだ技術書の1章を、自分の言葉でQiitaに書き直す。ハッカソンで作ったプロダクトの技術選定の理由を、はてなブログに1本残す。どれか1つで、本記事の1歩目です。
一緒に歩きましょう。ボン・ボヤージュ。素敵な旅を。
次の記事はフェーズ2-9「技術イベントや勉強会で、発表する。話す発信で、第三者の目利きを通す」です。
#エンジニア就活 #新卒エンジニア #技術ブログ #Zenn #エンジニアの卵に贈る就活の書
