エンジニアのアウトプット戦略を、技術Tipsから体験ログへ変える

この記事で考えること

エンジニアとして何かをアウトプットしたい気持ちはあっても、実際に何を書けばよいのかで止まることがあります。特に今は AI があるので、単なる技術Tipsを書く意味が少し揺らぎやすくなりました。

この記事は、shino.log の開始宣言というより、そうした時代にエンジニアがどんな形でアウトプットを続けられるのかを考えるためのメモです。自分の中では、最初から完璧な技術記事を目指すより、まずは体験ログを起点にする方がよいのではないかと考えています。

技術Tipsだけを書くことが難しくなってきた

技術記事を書くハードルは、前からずっと高かったと思います。自分が書こうとしている内容はすでに誰かがもっと詳しく書いているのではないか、もう少し検証しないと信憑性が足りないのではないか、と考え始めると手が止まりやすいからです。

そこに今は、AI という要素が加わりました。細かい実装方法や調査の入口は、かなりの速度で返ってきます。その結果、単に情報をまとめるだけの記事だと、「これは自分が書く意味があるのだろうか」と迷いやすくなった感覚があります。

もちろん、技術記事そのものの価値が無くなったわけではありません。ただ、自分にとっては「有益な記事を書かなければ」と思いすぎるほど、書く前に止まりやすくなっているのも事実です。

「それ、AIに聞けばよくない？」という問い

今は AI に聞けば、コード例も、比較対象も、調査の入口もかなり返ってきます。だから、単に知識を並べるだけの記事は、以前より相対的に弱くなりやすいのかもしれません。

ただ、それは個人が書く意味が無くなる、という話ではないとも思っています。むしろ個人が書くなら、その人がどういう状況で、何を見て、どう判断したのかが見える方が価値になるのではないか。少なくとも自分は、そういう方向へ少しずつ重心が移っているように感じます。

これは一般論として断定したいわけではなく、自分が書き続けるための考え方に近いです。AI が強くなるほど、情報そのものより、その人の経験や判断の跡が気になる場面が増えていくのではないか、という仮説です。

それでも個人が書く意味はどこにあるのか

それでも個人が書けるものとして、まず思い浮かぶのは体験です。

• 実際にやってみてどうだったか
• どこで詰まったか
• 期待と違ったところは何だったか
• なぜその選択をしたのか
• 後から振り返ってどう感じたか

こうしたものは、単なる技術情報ではなく、その人のログになります。うまくいったことだけでなく、迷ったことや判断の揺れも含めて残せるところに、個人の文章の意味があるのかもしれません。

一次情報としての体験記

自分が実際にやったことは、自分にとっての一次情報です。会社の外で試したものでも、個人プロダクトでも、このブログの構築でも、生活テックでも、ゲームのサポートツールのようなものでも、実際に触った体験そのものは自分の手元に残ります。

その意味では、体験記は最初から完璧な網羅記事でなくても書き始めやすいです。何かを説明しきることより、どう触ったか、どこで引っかかったか、どう判断したかを残すことなら、もう少し自然に始められます。

最初から大きなナレッジ記事を書くのではなく、まずは体験の温度を残しておく。その考え方を自分は大事にしたいと思っています。

体験ログからナレッジを切り出す

体験ログを起点にすると、あとから育てる流れも見えやすくなります。

体験記を書く
↓
詰まった点を切り出す
↓
技術Tipsにする
↓
設計判断ログにする
↓
必要ならZenn/Qiitaにも再編集する

たとえば、SwitchBot の導入ログから賃貸スマートホームの記事を作ることもできますし、shino.log の構築ログから Vercel や MDX 運用の記事を切り出すこともできます。日々の設計経験から、判断の部分を記事として育てることもできそうです。

最初から「これは技術記事に値するか」を判断するより、まずログとして残し、後から切り出せるものを見つける方が、自分には続けやすい運用に思えます。

継続するために、完璧な記事から始めない

アウトプットで一番難しいのは、たぶん継続です。有益かどうかを考えすぎると止まるし、網羅性を求めすぎると公開までたどり着きません。慎重さは必要でも、完璧主義だけで進めると、何も出せないまま終わってしまうことがあります。

だから、まずはログとして残す。量が出てくると、その中から育てるべき記事も見えやすくなります。最初の文章が少し粗くても、あとから整理できる余地がある方が、自分にとっては前に進みやすいです。

ここで AI との音声対話や要約を使うのも、そのためです。全部を書かせたいわけではなく、書くまでのハードルを下げたい。話した内容をたたき台にして、そこから自分の考えを整えていく形なら、止まりにくくできそうだと感じています。

shino.logで試したいアウトプットの形

shino.log は、技術Tips だけを並べる場所にはしたくありません。体験記、設計ログ、AI 活用ログ、日常テック、キャリアの試行錯誤のようなものを置いて、その中から必要に応じてナレッジ記事を育てていく場所にしたいと思っています。

そうしていくと、単に知識が並ぶだけでなく、自分がどう考える人なのか、どんなところで迷うのか、何を面白いと感じるのかも少しずつ見えてくるはずです。スーパーエンジニアとして有名になりたいわけではなく、こういうエンジニアもいる、という一つの事例になれば十分だと思っています。

まとめ：技術情報ではなく、判断の跡を残す

技術情報を残すだけなら、すでにたくさんの場所があります。でも、自分が何を見て、何に迷い、どう考えたかは、自分が残さないと残りません。

shino.log では、まず体験をログとして残し、そこから必要に応じて記事へ育てていきます。技術情報そのものではなく、判断の跡を少しずつ残していく。そのやり方が、今の自分には一番自然なアウトプット戦略になりそうです。