はじめに
私自身、アウトプットの仕方について悩んでいたのでとても参考になるイベントでした。
スピーカーの御三方がお話しされていた内容を軽くまとめていこうと思います。
技術記事を書くメリット
- 他のエンジニア(コミュニティ)に記事を通して価値を提供できる
- 自分の勉強になる
- 自分がよくわかっていなかったことが浮き彫りになる
- 読者からのフィードバックがもらえる
- 知名度や信頼が得られる
- twitterのフォロワーが増えた(やめ太郎さん)
- 楽しい
- 転職の際ポートフォリオとして使える
- 技術記事からその人の人となりが見えてくる
- 面接という短い時間では伝えきれないような、自分のいいところを「見える化」できる
間違った記事を書かないために
- タイプミスやリンクミスを公開前にチェックする。できれば自分だけでなく、他の人にもチェックしてもらう
- 信頼できる情報源を参考にする
- 専門用語など言葉の使い方に気を配る
- 普遍的な正しさではなく、局所的な正しさを語る
- 「特定のバージョンでは」こう動きますみたいに、話題にしている対象を特定する(狭める)
- 「この記事は間違えている!」と勘違いされないように、記事の前提を書く
- ex) 「良いコードの書き方」 良いコードとは何か?など
初心者の情報発信のやり方
- 記事の正しさにはちゃんとこだわる
- そもそも正しい、間違いみたいな議論になりにくい発信から始めるのもいい
- 勉強会やカンファレンスに参加した感想
- 自分なりのこだわり
- インストール、作業ログ
- 最初は他の人の役に立てなくてもいいので、自分の成長やフィードバックを狙った記事を書く
- 防御呪文を使う
- 「以下の内容には誤りが含まれる可能性があります」
- 読む人も注意して読むことができる
- 「と思います」
- 客観的事実ではなくて、主観的な意見・推測であることを示せる
- 「以下の内容には誤りが含まれる可能性があります」
記事の独自性、新規性について
他の人がもうすでにいい記事を書いてしまっている、、、
→ 大事なことは誰が何回書いてもいい
新規性のある記事を書くには
- (わかりにくい話題を噛み砕いたりして)わかりやすい記事にする
- 即効性はないが将来性のある最新情報を記事にする
- マニアックな情報を記事にする
- 英語でしか手に入らない情報を日本語に翻訳する
(この辺りの話をパネルディスカッションしていたが、子供が乱入してきて全然聞けなかった、、、、)
継続して技術発信するには
- 自分にとって書きやすい書き方を見つける
- 無理して書かない
- 技術発信が辛くならないようにする
- LT駆動発信
- LT会を探して登壇の予約をしてしまうことで、技術発信をしなければならない状態をあえて作り出す
- twitterを利用する方法(twitter駆動発信?)
- 学びをtwitterに発信していき、ある程度溜まってきた段階で記事にする
- 自分専用のハッシュタグをつけると、対象ツイートを探しやすいので後々まとめるときに便利
Qiita、Zenn、自分のブログの使い分け
パネルディスカッションにて出ていた意見をまとめる。
Zenn
- 知識系(uhyoさん)
- 真面目な技術記事を求めている人向けの記事(うさみさん)
Qiita
- 時事ネタ(uhyoさん)
- ネタ記事(uhyo うさみさん)
- 多くの人に見てもらいたい記事(うさみさん)
ブログ
- 自分の思想(uhyoさん)
まとめ
自分の技術ブログを作ろうかなあと思っていたので、発信媒体の棲み分けは特に参考になりました。
正しい内容の記事を書くことを大前提としつつ、楽しみながら技術記事を書いていこうと思います。
資料
- uhyoさん
- 無職やめ太郎さん