キャリア

エンジニアの情報発信。何を書き、どう続けるか

技術記事を書くべきか。続けている人には理由がありますが、必須ではありません。この記事では、判断の材料を整理します。

なぜ発信するのか

強制されるものではありませんが、続けている人には理由があります。

理解の確認。説明できないことは理解できていません。書く過程で、曖昧な部分が見つかります。

記録として。過去に解決した問題を、自分で参照することがあります。

市場価値の可視化。職務経歴書に書けない部分を示せます。採用の場面で参照されることがあります。

機会が来る。登壇の依頼、仕事の相談、転職の誘い。発信を通じて声がかかる例があります。

ただし、これらは結果です。効果を期待しすぎると続きません。

何を書くか

書くことがないという声が多いので、材料を整理します。

• 詰まって解決したこと／同じ問題に当たる人がいる。最も需要がある
• 調べて分かったこと／公式資料を読んで整理した内容
• 選択の理由／なぜその技術を選んだか。判断の過程に価値がある
• 失敗したこと／うまくいかなかった経験。成功例より参考になる場合がある
• まとめ／散らばった情報を1か所に整理する

1つ目が最も書きやすく、読まれます。自分が検索して見つからなかった情報は、他の人も探しています。

新規性は不要です。既に誰かが書いていても、書き方や状況が違えば価値があります。

続ける工夫

多くの人が、数本書いて止まります。対処を整理します。

完璧を目指さない。誤りがあれば直せばよく、公開が前提の記事である必要もありません。

長さを決めない。短い記事でも構いません。長文を書こうとすると、着手できなくなります。

作業しながら書く。後からまとめようとすると、詳細を忘れます。手を動かしながら記録します。

反応を期待しすぎない。読まれない記事も多くあります。自分の記録として価値があると考えるほうが続きます。

頻度を決めない。週1回といった目標は、達成できないと止まる原因になります。

注意すべきこと

発信には、注意点もあります。

業務情報の扱い。顧客名、システムの構成、未公開の情報。秘密保持契約に抵触する可能性があります。

所属先の方針。発信を制限している企業もあります。事前に確認が必要です。

誤った情報。間違いを書くこともあります。指摘を受けたら直す姿勢が前提です。

他者への言及。特定の企業や製品への批判は、慎重に扱うべきです。

これらを理由に発信しない選択も、十分に合理的です。

形式の選択

発信の手段はいくつかあります。

技術ブログ。検索から読まれやすく、蓄積されます。自分のサイトか、投稿サービスか。

SNS。短い発信。反応が早い一方、流れて消えます。

登壇。勉強会、カンファレンス。準備の過程で最も学べる形式です。

公開する成果物。作ったものを公開する。コードそのものが説明になります。

社内向け。外部に出さず、社内の記録として残す。これも十分に価値があります。

しなくてもよい

最後に、率直に書いておきます。

発信しないことが不利になるわけではありません。実務で成果を出している技術者の多くは、発信していません。

向き不向きもあります。書くことが負担なら、その時間を別のことに使うほうが有益です。

ただし、記録を残すこと自体には価値があります。公開しなくても、自分用のメモでも構いません。

要は、学んだことを言語化する習慣です。その手段が公開である必要はありません。

続けた人に起きること

発信を継続した結果として、報告される変化を整理します。

説明が上手くなる。書くことは、構造化の訓練になります。設計書や提案の質にも波及します。

知識が整理される。断片的に知っていたことが、書く過程でつながります。

相談が来る。詳しい人として認識され、社内外から質問が来るようになります。

選択肢が増える。転職、登壇、執筆の依頼。直接の収入にならなくても、機会につながります。

ただし、これらは年単位の話です。数本書いて効果を期待すると、続きません。

何から始めるか

着手のしかたを具体的に示します。

まず、自分用のメモから。公開を前提にすると、書き始められません。

詰まって解決したことを記録する。何に困り、何を試し、何で解決したか。この形式なら、書く材料は日常的に発生します。

公開するかは後で決める。書いてから判断すれば十分です。

社内から始めるのも選択肢です。社内の記録として残し、同僚に読んでもらう。反応が得やすくなります。

形式にこだわらない。整った記事である必要はありません。