> ## Documentation Index
> Fetch the complete documentation index at: https://lib.findy.co.jp/llms.txt
> Use this file to discover all available pages before exploring further.

# テックブログの運営と記事の書き方 — 企画から公開まで

> 企業のテックブログで外部発信するために、編集体制と執筆フロー、執筆前の企画審査と執筆後の品質レビュー、テーマ選定と表現のリスク管理、記事の書き方、公開と拡散の進め方を解説します。

## 概要

テックブログとは、企業が自社のエンジニアリングに関する知見を記事として社外に公開する技術メディアです。記事は個人の名前で書かれますが、読者には「その会社の見解」として受け取られます。

このページでは、テックブログを組織として運営する側と、記事を書く側の両方の視点を扱います。まず運営の仕組みと執筆フローを定め、テーマの選び方、表現と情報のリスク管理、記事の書き方、公開と拡散を順に説明し、最後にファインディでの具体的な運用を紹介します。

## テックブログの位置づけ

テックブログは、発信の形式のうち「判断とその理由を分量をかけて説明し、後から読める形で残す」役割を担います。登壇やイベントと異なり、記事は検索から長期にわたって読まれ続けるため、1本の記事が組織の技術的な水準を示す資料として残ります。

個人ブログとの違いは、責任の所在です。個人ブログでは許容される比喩や断定、他社製品との比較も、企業の公式メディアでは会社の立場として読まれます。そのため、テックブログの運営では「書きたいことを書く」だけでなく、公開してよい内容かどうかを組織として確認する仕組みが必要になります。

一方で、確認の仕組みが重すぎると書き手が減り、発信が続きません。運営の目的は、記事の品質と安全性を保ちながら、書き手が継続して書ける状態をつくることです。

## 運営の仕組み

### 役割を分担する

テックブログの運営には、少なくとも3つの役割があります。

| 役割 | 担うこと |
| - | - |
| 書き手 | 企画を立て、記事を書き、セルフレビューを済ませてからレビューを依頼する |
| 上長 | 書き手の業務内容を知る立場から記事を確認する |
| 編集部 | 記事の方針がテックブログ全体の方向性とずれていないか、表現にリスクがないかを確認する |

編集部をチームとして指定し、メンバーのうち1名の承認で通過とすると、特定の人にレビューが集中しにくくなります。

### 執筆フローを決める

記事の内容は、書き始める前と書き終えた後の2回確認します。書き始めてから方向性のずれが見つかると、大幅な書き直しが必要になるためです。

**1. 企画を登録する**

タスク管理ツールに記事の企画を登録し、初稿の期日・レビューの期日・公開予定日を決めます。期日を先に決めておくと、レビューの担当者が予定を確保できます。

**2. 企画の全体像をレビューしてもらう**

仮のタイトル、書こうとしている内容のサマリ（箇条書きで構いません）、結論をまとめ、上長と編集部にレビューを依頼します。この段階では文章の品質ではなく、テックブログで公開してよいテーマか、結論が明確かを確認します。

**3. 企画の価値を審査する**

執筆を始める前に、企画が読者にとって新しい知見を含むかを審査します。審査の観点は次の節で説明します。

**4. 下書きを書き、セルフレビューする**

執筆ガイドラインとチェックリストに沿って下書きを書き、レビューを依頼する前に自分で品質を確認します。

**5. 記事をレビューしてもらう**

上長と編集部に下書きのレビューを依頼し、指摘を反映して承認を得ます。

**6. 公開日時を設定して公開する**

タイトル、読後の導線、アイキャッチ画像を確認したうえで、公開日時を予約します。

**7. 公開した記事を拡散する**

社内のチャンネルや個人のSNSで記事を共有し、より多くの読者に届けます。

### 執筆の前後で企画審査と品質レビューを行う

執筆前の確認を企画審査、執筆後の確認を品質レビューと呼びます。2つは確認する対象が異なります。企画審査は「この記事を書く価値があるか」を、品質レビューは「この記事を公開できる状態か」を判定します。

企画審査では、次の観点をすべて満たすかを確認します。

| 観点 | 確認すること | 通過しない例 |
| - | - | - |
| 非自明性 | 主張が、経験を積んだ読者にとってすでに既知ではないか | 「テストは大事」のような正論だけで終わる |
| 独自性 | 数値・失敗の詳細・手順・Before/Afterなど、その記事でしか得られない要素が2つ以上あるか | 公式ドキュメントや既存記事の焼き直し |
| 実務転用性 | 読者が翌日から変えられる行動が1つ以上あるか | 「〜を意識しましょう」で終わる |
| 想定読者 | 職種と経験年数（ジュニア・ミドル・シニア）が明確か | 誰に向けた記事か特定できない |
| So What? | 「だから何？」と聞かれたときに、誰の何が変わるかを答えられるか | 「AIを使うと便利です」 |

品質レビューでは、「記事を書く」で説明する構成・表記・セルフレビューの観点で記事を確認します。

> [!TIP]
>
> 企画審査と品質レビューのどちらも、通過した結果を企画のIssueや記事のプルリクエストにコメントとして残します。レビュー担当者は審査済みの観点を確認し直さずに済み、残りの観点に時間を使えます。

## テーマを選ぶ

### 推奨するテーマ

テックブログに向いているのは、自社の具体的な経験に基づくテーマです。

| テーマ | 書くときの注意 |
| - | - |
| 技術的な知見の共有 | チュートリアルを試しただけの簡単すぎる内容は避ける |
| ケーススタディ、成功事例・失敗事例とふりかえり | 経緯と判断の理由まで書く |
| 開発プロセス、アジャイル、チームビルディングの経験談 | 一般論ではなく自チームで起きたことを書く |
| オープンソースへの組織としての貢献 | 貢献の内容と背景を具体的に示す |
| 採用、組織の紹介、チーム間の協業 | 組織の実態が伝わる具体例を添える |
| 業界や技術の動向、海外の情報 | 事実関係と出典を確認する |
| 技術イベントやセミナーの参加レポート | 印象に残った内容と学びを書く |
| 入社エントリー、エンジニアのキャリアパス | 個人の感想より、会社や組織に関する情報を中心に書く |

テーマは企業のブランディングにも関わるため、推奨テーマであっても公開できない場合があります。リストにないテーマも、企画の全体像のレビューで相談できます。

### 避けるテーマ

次のテーマは、企業の公式メディアとして扱うリスクが大きいため避けます。

| テーマ | 避ける理由 |
| - | - |
| ツールや製品の比較 | 取引のあるベンダーもあり、一方を上げるともう一方を下げることになる |
| 批判・否定・ダメ出し | 会社全体の意見として受け取られる |
| 競合他社の批判、競合他社名への言及 | 会社間の関係に影響する |
| 機密情報・個人情報・他社の情報 | すでに公開されている情報でも、再掲の是非を確認する必要がある |
| 自社の今後の戦略や追っているKPI | 外部から事業の判断を推測される。一般論に近い内容であれば扱える |
| 法律に反する内容 | 著作権侵害、不正アクセス、規約に反するスクレイピングなど |
| 未検証の情報 | 引用する場合は出典をリンクする |
| カジュアルすぎる内容 | おふざけの要素が強いと、企業の発信として不適切になる |

## 表現と情報のリスクを管理する

### 表現の倫理

表現のリスクで判断の基準になるのは、書き手の意図ではなく、読み手がどう受け取りうるかです。炎上したときに「そういう意図ではなかった」という説明は通用しません。

企業の公式メディアでは、次の表現を避けます。

* 人を動物・モノ・機械に喩える表現（非人間化）。
* 「配属」「マネジメント」「部下」といった職場・人事の語彙に、動物や架空の存在を当てはめる表現。
* 動物・宇宙人・ロボットなど極端な設定を使った思考実験。本文で「比喩です」と断っても、タイトルや見出しだけが切り取られて拡散されます。

公開前には、次の4つのテストで誤読の可能性を確認します。

| テスト | 確認すること |
| - | - |
| タイトル単体テスト | 本文を読まない人がタイトルだけを見たとき、どう解釈するか |
| 切り取りテスト | 記事の一部だけがSNSで拡散されたとき、文脈なしでどう見えるか |
| 最も傷つく人テスト | この記事で傷つく可能性があるのは誰か。その人の立場でどう感じるか |
| 国際基準テスト | 海外、特に英語圏の読者がその表現をどう受け取るか |

### 機微情報

スクリーンショットや写真には、意図しない情報が写り込みます。社内チャットやドキュメントのスクリーンショットでは、アイコン・個人名・時刻・プロジェクト名をぼかします。ぼかしが薄いと判読できることがあるため、十分に塗りつぶします。デスクの写真では、モニタに映った画面や卓上のメモも確認します。

ソースコードは、変数名や数値から内部の構造や脆弱性が推測される場合があります。サンプルコードを載せるときは、自社固有の変数名・関数名・クラス名を汎用的な名前に置き換え、APIキー・トークン・内部URL・IPアドレスを含めないようにします。

> [!WARNING]
>
> 書き手は、画像やスクリーンショットが出してよい情報かどうかをレビューの前に自分で確認してから、記事に追加します。

## 記事を書く

### 構成

記事の種類によって、読者が期待する構成が異なります。

| 記事の種類 | 推奨する構成 | 文字数の目安 |
| - | - | - |
| 技術解説 | 背景と課題 → 解決策の検討 → 実装の詳細 → 結果（Before/After） → 今後の展望 → まとめ | 3,000〜5,000文字 |
| イベントレポート | イベントの概要 → 内容の紹介 → 学んだこと → おすすめの対象者 | 2,000〜3,000文字 |
| 体験談・考察 | — | 2,000〜3,500文字 |
| 詳細なチュートリアル | — | 5,000〜8,000文字 |

体験談・考察と詳細なチュートリアルは、決まった構成を定めず、文字数の目安だけを示しています。

文章量よりも、主張が明確で根拠があることを優先します。ただし、極端に短い記事は内容が薄い印象を与え、長すぎる記事は読者が離脱しやすくなります。長くなる場合は、シリーズ記事への分割を検討します。

見出しはh2から順に使い、「1つ目」「2つ目」ではなく内容を示す言葉にします。各h2だけを読んで記事の全体像がわかる状態が目安です。自己紹介の直後、本文に入る前に目次を置きます。

### タイトル

タイトルは、記事の中身と同じくらい読まれるかどうかを左右します。結論が伝わるタイトルにし、先頭にツール名や技術名など具体的なキーワードを置きます。

AIが生成しがちなパターンは避けます。たとえば「〜の3つの教訓」「失敗を成長に変えた〜」「〜完全ガイド」「〜を徹底解説」「〜への道」「〜の秘訣」です。短いタイトルは印象に残りやすいものの、内容が伝わることを優先します。

### 導入とまとめ

導入では、読者が「自分に関係がある記事か」を判断できるように、次の内容を冒頭で明らかにします。

* 何のツール・技術・イベントについての記事か
* 想定する読者と、読むと何がわかるか
* 記事を書いた背景や動機

まとめでは、記事で最も伝えたかった結論、読者が持ち帰れる知見や行動、今後の展望を書きます。「いかがでしたでしょうか」で始めたり、「参考にしていただければ幸いです」だけで締めたりすると、結論が読者に残りません。

### 数値と根拠の示し方

改善を主張するときは、Before/Afterを数値で示します。「処理が高速化しました」ではなく「2時間から5分に短縮しました」と書き、「カバレッジはほぼ100%」ではなく「90%超えを維持」のように確認できる値を書きます。

数値には、計測した環境（本番・ステージング・ローカル）、サンプル数や期間、比較の基準を添えます。外部の情報を引用するときは、本文中に番号付きの参照を付け、記事の末尾に参考文献として公式ドキュメントやイベントページへのリンクを載せます。

### トーンと表記

文体は、固すぎずカジュアルすぎない調子にします。「〜では価値が出しにくくなっています」のような不安を起点にした書き出しより、「〜に加えて、より〜が求められるようになってきました」のように次につながる表現を選びます。課題を書く場合も、先にそのツールや手法の良い点に触れます。

表記は記事内で統一します。

* 製品名・技術名は正式な表記で書く（GitHub、JavaScript、Cloud Runなど）。
* 英単語と日本語の間にスペースを入れない。
* 「以下」ではなく「次の」を使う。
* 太字は1つの見出しにつき1〜2か所までにし、斜体・下線・色・水平線は控える。
* 段落の中で1文ずつ改行せず、段落の区切りに空行を入れる。

箇条書きの多用、常に3項目でそろえた列挙、「**項目名**: 説明」形式の機械的なリストは、AIが生成した文章に見えやすい表現です。説明が必要な内容は文章で書きます。

### セルフレビュー

レビューを依頼する前に、記事を3回、視点を変えて読み直します。1回の通読では見落としが残るためです。

| 視点 | 確認すること |
| - | - |
| 書き手 | 最も伝えたいことを一文で言えるか。それを支える根拠があるか。タイトルと結論が一致しているか |
| 読者 | 前提知識がなくても理解できるか。「なぜ？」「具体的には？」に答えているか。持ち帰れる知見があるか |
| 批判者 | 反論や例外を想定しているか。他社への批判、自慢や上から目線と受け取られる表現がないか。個人の意見が会社の公式見解と誤解されないか |

あわせて、目次と採用情報へのリンクがあるか、「TODO」などの仮テキストが残っていないか、リンクが切れていないかを確認し、プレビュー画面で見た目を確かめます。

## 公開と拡散

### 公開前の確認

公開の前に、レビューの指摘がすべて解消されていること、タイトルを見直したこと、読後の導線（採用情報や関連記事へのリンク）があること、アイキャッチ画像が設定されていることを確認します。アイキャッチ画像は共通のデザインで作成すると、ブログ全体に統一感が出ます。タイトルを変えた場合は、画像も作り直します。

### 公開のタイミング

公開日時は、自社ブログの閲覧データから読まれやすい曜日と時間帯を把握し、それに合わせて予約します。公開と同時に、公式SNSアカウントからも告知します。

### 拡散と分析

公開後は、書き手が社内のチャンネルと自分のSNSで記事を共有し、社内のメンバーにも拡散を依頼します。社内のメンバーが記事を読み、反応することが、社外に届くきっかけになります。

記事の閲覧状況は、アクセス解析ツールと検索パフォーマンスの計測ツールで確認します。発信の効果は個々の記事に帰属させにくいため、1本ごとの数値で書き手を評価するのではなく、十分な期間の蓄積で活動全体を評価します。

### 公開済みの記事を修正する

公開後に誤りが見つかった場合は、記事を修正します。修正の前に、ブログサービス上の最新の状態を手元に取り込みます。ブログサービスの編集画面で直接更新した内容が手元に反映されていないまま修正すると、その更新が失われるためです。

## ファインディでの運用

ファインディでは、テックブログを「はてなブログ」で公開し、記事の原稿をGitHubのリポジトリで管理しています。記事のレビューをコードと同じくプルリクエストで行うことで、エンジニアが普段の開発と同じ流れで執筆・レビューできるようにしています。

はてなブログとGitHubリポジトリの同期には、はてなが公開している[Hatena-Blog-Workflows-Boilerplate](https://github.com/hatena/Hatena-Blog-Workflows-Boilerplate/)を使わせてもらっています。下書きの取得・同期や公開記事の反映といったGitHub Actionsのワークフローは、このボイラープレートをもとにしています。

### 執筆から公開までの流れ

**1. GitHub Projectsで企画を管理する**

テックブログ用のGitHub Projectsにタスクを作成し、記事テンプレートからIssueを起票します。Issueには記事タイトル（仮）、サマリと結論、初稿期日・レビュー期日・公開予定日を記入し、ステータスを「Todo」にします。

**2. Issueで企画のレビューを受ける**

直属の上長と、編集部のGitHubチームをレビュアーとしてメンションします。編集部はチームとして指定し、メンバーのうち1名の承認で通過します。

**3. Claude Codeで企画を審査する**

企画審査用のClaude Codeのコマンドで、企画を非自明性・独自性・実務転用性・想定読者・So What?の5観点で審査します。Issueの内容を読み込んで審査するほか、対話形式で企画を聞き取って審査することもできます。PASSを受けてから執筆を始め、審査結果をIssueにコメントします。

**4. はてなブログで下書きを作り、GitHubに同期する**

はてなブログの編集画面で、`ユーザー名-日付`のような一意のタイトルで下書きを保存します。GitHub Actionsの下書き取得ワークフローにそのタイトルを渡して実行すると、下書きを含むプルリクエストが自動で作成されます。

**5. プルリクエスト上で記事を編集する**

下書きのプルリクエストにプッシュすると、GitHub Actions経由ではてなブログの下書きに同期され、プレビューで表示を確認できます。画像はリポジトリの年月別ディレクトリに追加して記事から参照すると、はてなブログにアップロードされます。

**6. Claude Codeで品質をレビューする**

品質レビュー用のClaude Codeのコマンドで記事をレビューします。90点以上になるまで修正と再レビューを繰り返し、結果をプルリクエストにコメントします。

**7. 上長と編集部のレビューを受ける**

プルリクエストのレビュアーに上長と編集部のチームを指定し、承認を得ます。

**8. 予約投稿で公開する**

下書きであることを示す`Draft: true`の行を残したままプルリクエストをマージし、はてなブログの編集画面で公開日時を設定して予約投稿します。このとき、公開と同時にXへ投稿する設定を有効にし、公式アカウントから告知されるようにします。

**9. 社内外に共有する**

公開後、全社や開発組織のSlackチャンネル、自分のtimesチャンネルで記事を共有し、SNSでの拡散を依頼します。

### 品質レビューのコマンドが行うこと

品質レビューのコマンドは、執筆ガイドラインをもとに次の手順を順に実行します。

| ステップ | 内容 |
| - | - |
| リスク確認 | 炎上リスク、機微情報、比較や批判、根拠のない断定を検出する。問題があれば修正してから再実行する |
| 機械チェック | 誤字脱字、表記ゆれ、空白、Markdownの構文を機械的に検出する |
| Self Review | チェックリストと3つの視点で記事を確認し、100点満点で採点する |
| Fix Plan | 90点未満の場合に、具体的な書き換え案を提示する |
| 企画との整合性と俯瞰チェック | Issueの企画と記事の内容が一致しているか、記事全体の流れが一貫しているかを確認する |
| プルリクエストへのコメント | 90点以上の場合に、確認のうえでレビュー結果をプルリクエストに投稿する |

ガイドラインはリポジトリ内のファイルを唯一の正とし、Claude Codeのコマンドと、GitHub Copilot ChatのAgentモードによるレビューの両方から参照されます。どちらのツールを使っても、同じ基準でレビューを受けられます。

### 運用上の決まりごと

> **公開のタイミング**
>
> 拡散を最大化するため、月曜日か金曜日（祝日の場合は翌営業日）の7:00〜10:00に公開します。予約投稿の場合は7:00に設定します。

> **記事の末尾**
>
> すべての記事の最後に、採用情報へのリンクを定型文とともに入れます。

> **製品名の表記**
>
> Findy、ファインディ株式会社、Findy Team+、Findy Tools、Findy Freelance、Findy Conferenceのように、製品名と社名は正式な表記で書きます。「FINDY」「株式会社ファインディ」などは使いません。

> **アイキャッチ画像**
>
> 統一感を出すため、共通のデザインテンプレートのうち決められた配色の画像を使います。

> **初めて投稿する人の準備**
>
> はてなIDを作成して管理者に伝え、はてなブログのメンバーに追加してもらいます。誰が書いたかわかるように、はてなのプロフィールで名前とアイコンを設定します。

## 関連ページ

> **[DevRelの役割](/ja/devrel/engineering-culture.md)**
>
> テックブログを含む発信が、組織にとってどんな役割を果たすかを扱います。

> **[エンジニア育成](/ja/organization/engineer-growth.md)**
>
> 記事の執筆を、学習と共有を通じた育成の中にどう位置づけるかを考えるときに読みます。

> **[オンボーディング](/ja/organization/onboarding.md)**
>
> 入社エントリーを書く新しいメンバーが、組織の中で自律して動けるようになるまでの支え方です。


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.