「技術ブログを始めても、何を書けばいいのか分からなくなりそう」と思っていました。
私はインフラエンジニアとして7年働いた後、社内SE・クラウドエンジニアへ転職しました。AWSやOCIの実務経験はありますが、技術について何でも詳しく説明できるわけではありません。そのため、最初は技術ブログと呼べるほどの記事を書けるのか不安でした。
実際に記事を書き始めてみると、詳しい技術解説だけがブログの題材ではないと気づきました。転職で迷ったこと、資格勉強で間違えたこと、実務で知識不足を感じたことも、同じ状況にいる人にとっては一つの情報になります。
この記事では、私が実際に書いたテーマをもとに、インフラエンジニアがブログに書きやすい記事ネタを15個紹介します。
技術ブログは高度な技術解説だけでなくてよい
技術ブログというと、AWSの構成図やコマンド、障害対応の詳しい手順を書くイメージがありました。しかし、仕事で扱った内容をそのまま公開することはできませんし、自分より詳しい人はいくらでもいます。
そこで私は、「自分が実際に経験したこと」と「当時の自分が知りたかったこと」を中心に書くようにしました。
- なぜその選択をしたのか
- どこで迷ったのか
- 失敗した後、どう改善したのか
- 転職や勉強の前後で何が変わったのか
このような内容なら、専門書のような説明はできなくても、自分にしか書けない記事になります。
インフラエンジニアが書きやすい記事ネタ15選
1．転職しようと思った理由
給与、評価制度、残業、仕事内容など、転職を考えたきっかけは人によって違います。不満だけで終わらせず、「次の会社で何を変えたかったのか」まで書くと、読者が自分の状況と比べやすくなります。
私は、評価制度や給与への不満に加えて、プロジェクトが細分化され、経験できる範囲が狭かったことを書きました。
2．転職活動にかかった期間と応募数
「何社くらい応募すればよいのか」は、転職を始める前に気になるところです。私は働きながら約2か月半活動し、約40社へ応募、10社ほど面接へ進みました。こうした数字は、個人の体験でも一つの目安になります。
3．内定先を比較したポイント
年収だけでなく、業種、仕事内容、働き方、社員の雰囲気、将来のキャリアなど、実際に比較した項目を書きます。私はSIerと社内SEの2社から内定を得て、クラウド案件へ積極的に携われる社内SEを選びました。
4．オンライン面接の失敗と改善
うまくいかなかった経験も記事になります。私はPCでオンライン面接を受けた際、部屋が暗く、面接官からも雰囲気が暗く見えると言われました。次の面接ではカーテンを開け、事前テストをして改善しました。
5．転職エージェントを利用した感想
求人紹介、書類添削、模擬面接、日程調整、条件交渉など、実際に受けた支援を整理します。担当者との相性によって感想が変わるため、「私はこう感じた」と体験の範囲を明確にすることが大切です。
6．職務経歴書で工夫したこと
ページ数、案件の書き方、数値で示した経験、添削で見直した部分などは、同じ職種の転職希望者に役立ちます。私は4ページにまとめ、AWS・OCIやセキュリティ、インフラ構成の自動化などを記載しました。
7．資格を取得した勉強方法
勉強期間、使用教材、勉強した時間帯、難しかった分野を書きます。私はAWS SAAを約2か月、主に電車での移動時間を使って勉強しました。まとまった勉強時間を取れない人にとって、時間の使い方も参考になります。
8．資格試験で迷った問題
合格体験だけでなく、可用性、コスト、運用負荷など、判断に迷った条件を整理する記事も書けます。私は間違えた分野をChatGPTに記録してもらい、似た問題を繰り返し出してもらいました。
9．転職後に感じた知識不足
経験年数があっても、環境が変わると知らないことは出てきます。私はAWSの運用保守と追加開発を約3年経験していましたが、転職後にTGW、WAF、CloudFront、API Gateway、コンテナなどに触れ、サービスの使われ方や構成の知識が足りないと感じました。
10．転職前に勉強しておきたかったこと
今だから分かる不足分野を整理します。私の場合はIaC、セキュリティ、ネットワークです。「勉強しておけばよかった」で終わらず、今どのように学んでいるかまで書くと、前向きな記事になります。
11．クラウド移行で担当した工程
公開できる範囲で、調査・設計・構築のどこを担当したか、何に難しさを感じたかを書きます。会社名、顧客名、具体的なIPアドレスなどは出さなくても、考え方や学びは共有できます。
12．Terraformを実務で覚えた過程
最初から新規コードを書いた話でなくても構いません。私は前任者からの引き継ぎでTerraformを初めて教わり、既存コードの修正から担当しました。実務だけでは理解に時間がかかったため、参考書やWebでも基礎から学び直しました。
13．難しい作業をどう乗り越えたか
マニュアルやベンダーサポートがない中で調べた経験も記事になります。私はストレージをクラスタ構成へ組み込む際、Webや動画を調べながら対応しました。守秘義務に配慮しながら、調査の進め方や切り分けの考え方を書くことができます。
14．SIerと社内SEの働き方の違い
同じエンジニアでも、所属する会社によって仕事の受け方や関係者が変わります。私はSIerから社内SEへ移り、社内や事業会社の人と直接話して仕事を進める場面が増えました。自分に合う働き方を考える記事にできます。
15．実際に使った教材やサービス
資格の参考書、学習サービス、転職サービスなど、実際に使ったものを紹介します。よかった点だけでなく、合わなかった点や注意点も書くと、宣伝だけではない記事になります。
実務を書くときに気をつけていること
インフラやクラウドの仕事は、公開してはいけない情報が多い分野です。私は記事にする前に、次の点を確認するようにしています。
- 会社名や顧客名を特定できる情報を書かない
- IPアドレス、アカウント情報、具体的な内部構成を出さない
- 現在の勤務先の副業・情報発信ルールを確認する
- サービス仕様は公式情報でも確認する
- 自分の体験と一般的な事実を分けて書く
詳しく書くことより、公開してよい範囲を守ることの方が重要です。構成の詳細を出せない場合でも、「何に困り、どのような順番で調べたか」なら書けることがあります。
最初の記事は身近な悩みから選ぶ
15個すべてを書く必要はありません。最初は、少し前の自分が検索していたことを一つ選ぶのがおすすめです。
- 当時、何に困っていたか
- どのような選択肢を比べたか
- 最終的に何を選んだか
- 実際にどうなったか
- これから同じ経験をする人へ伝えたいこと
この順番でメモを作ると、記事の形にしやすくなります。完璧な解説を書こうとすると手が止まるので、まずは自分の体験を事実ベースでまとめるようにしています。
まとめて下書きし、少しずつ公開する
書きたいことを思いついた日に、すべての記事を完成させる必要はありません。タイトルと見出しだけ下書きし、時間がある日に本文を追加する方法なら、忙しくても続けやすくなります。
私は複数の記事を下書きにして、3日ごとに公開されるよう予約しています。記事数だけを急いで増やすのではなく、自分の体験がきちんと伝わる内容にすることを優先しています。
これから技術ブログを始めるなら
とりあえず文章を書いてみたい場合は、無料ブログでも始められます。一方で、自分のドメインで記事を長く残したい場合は、WordPressブログも選択肢になります。
私はConoHa WINGを使い、サーバー、独自ドメイン、WordPressをまとめて準備しました。無料サーバーや無料ブログとの比較、開設時に戸惑ったことは、次の記事にまとめています。
インフラエンジニアがConoHa WINGでWordPressブログを始めた体験談
自分では当たり前だと思っている経験でも、これから同じことを始める人にとっては役立つ情報かもしれません。私も、まずは一つずつ書き残していこうと思います。
