アウトプットから始まるエンジニアのキャリア戦略
なる勉強会を視聴した。片手間で聞いてたので全てはカバーしてないが、気になった話をメモしておく。
勉強会の内容は、普段アウトプットしている人たちに、アウトプットの仕方や考え方を聞くもの。
「アウトプットするとこんな良いことがある」といった話がなかったのが意外だった。
- 自分の整理になる
- feedbackをもらえる
- 関連した話を教えてもらえる
など、よくある話を予想してたが、そのへんはすっ飛ばされて聴衆の興味ある話にフォーカスされてたので、いい意味で期待を裏切られた。
スピーカー２人は有名な人らしい。 ツイッターをフォローしようとしたら、すでにフォローしていたので、そういうことなんだろう。
発信/アウトプット方法
冒頭、「視聴者はどんな手段で普段アウトプットしていますか」と質問が投げられた。
回答はQiitaが多かった。
私は記事は（あんまり書かないが）はてなに書くくらいで、QiitaもZenn もNote も書いてない。 登壇もしたことないし、たまにtwitterに書くくらい。
スピーカー２人の回答は対照的で面白かった。
一人は、vtuber やイベント登壇で、発話でアウトプットするのがメインらしい。もう一人は文章としてアウトプットしたくて、記事執筆や出版が多いとのこと。
私も話すより文字としてアウトプットして残しておきたいタイプなので、後者に共感した。逆に前者はデザイナー/クリエイティブな方面の人に多そう。
他の人のアウトプットを見て良いと思うこと
良いと思うアウトプットはどんなの？という質問に対し、「課題の解法だけでなく、その背景も書いてある」「正しい論理展開で議論されてる」と回答されていた。
私も同意だ。
以下、文脈等話されていたことを補足する。
腰を据えて書く長大な技術記事でない限り、日常的なアウトプットは、「こんな課題に直面して、こうしたら解決しました」といったトラブルシューティングの記事になることも多い。
そういう記事を書く時、課題と解決法だけを書くと、なぜそれで解決したのか、本当にその解決法でいいのか、がわからない。
記事執筆者が求める要件はその方法で満たされたかもしれないが、別の要件では必ずしも解決策とならない場合がある。何を実現したかったのか、なども合わせて書くことが大事である。課題の背景も合わせて記載することで、「たしかにそのケースならこの解決で十分だな」と客観的に正しい主張になってると、良い記事といえる。
ちなみに、客観的な正しさを普段から意識するために、直感で得た回答に対してなぜなぜ分析をしていくと良い。直感は意外と正しいこともあれば、全く間違ってることもあるので、深ぼって損はない。
アウトプットの方法
継続的にアウトプットのための時間をとってますか？みたいな趣旨。
スピーカーは二人共天才肌で、書きたくなったら夜でも寝ずに書いてしまう。気づいたら途中で寝てる、みたいなことがよくあるらしい
これは再現性ないな...
アウトプットのネタ
ネタは貯めてますか？思いついたら書いてますか？という質問。
この質問の回答も対照的だった。
一人はネタ帳があって、いろんなアイデアを書き溜めてるらしい。 旅行など非日常下でアイデアが湧いてくるそうだ。創造性などの文脈でよく聞く話だが、本当なんだな。
もう一人は思い立ったらその場でアウトプットし切って、書きたいものがたまってる状態ではないらしい。それはそれで極端に感じた
情報収集
文脈は聞き逃したが、情報収集の手段についても話された。
ざっくり以下をメモった
- よく有益な情報発信してる特定の人のツイートをslackに流す
- AWS のwhat's new のポストを全部キャッチアップする
- ポイントでみると何が起こっているかわからないが、毎回見ていると理解できる、（らしい）
- Githubのフィードを見る
- Githubで特定の人(強い人)がスターを押したレポジトリを見てみる
情報があふれるこの時代では、情報をいかに取捨選択して消化するかが大事だと思うので、このセクションは「へー」くらいで聞いてた。
終りに
構成考えずに書いたので、どこが勉強会の内容で、どこが私の主張か読みづらかったら申し訳ない。
