技術記事を書く＆楽しむチームの作り方

2022-10-26 Hatena Engineer Seminar #22
https://hatena.connpass.com/event/263147/

Transcript

1. 技術記事を書く ＆楽しむ チームの作り方 Hatena Engineer Seminar #22 2022-10-26 id:onk 1
2. 自己紹介 • 大仲 能史 a.k.a. id:onk • 株式会社はてな チーフエンジニア ◦ エンジニア組織のマネージャの一人 ◦ アウトプット推進担当 2
3. 3 今日の話
4. 4 技術記事を書く ＆楽しむ チームの作り方
5. 技術記事について、2つのテーマで • 技術記事に対しての階段の存在 • 他人の仕事を面白がれるコミュニティ作り 5
6. 主にカジュアル面談で話した内容 6 https://jobs.qiita.com/employers/hatena-corp/dev_talks/255
7. 7 ご応募お待ちしています
8. 8 技術記事に対しての階段
9. よく聞く質問 • 書いたら成長に効くとよく言われているのは 知っている • 書いてみたいと思っているが、こんな書き方 をしてはいけない、と言われるのが怖い • 良い記事を書くコツはあるか 9
10. 技術記事は以下に類型化される 10 類型 記事の目的・価値 学習ノート 筆者による理解の復習・確認やアウトプット の練習のために書かれる。 教科書 読者に対する知識の提供を主な価値とする。 論文 単なる知識だけでなく、アイデアや技術の新 規性を提供する。 https://zenn.dev/uhyo/articles/technical-articles
11. コミュニティに正の価値を与える のは難しい 11 https://speakerdeck.com/line_developers/writing-technical-articles-as-you-like
12. 他人と同じ内容の記事にも価値がある 12 https://naomichi-h.hatenablog.com/entry/2021/07/13/152908
13. きっと、まったく同じ内容にはならな い 13 https://lacolaco.hatenablog.com/entry/2021/03/08/100228
14. 14 という前提の上で、付け 足せることがあるとした ら
15. 作業メモを書きましょう • 「こうなると思ったのに違った」を探す • 作業メモに以下を書き残す ◦ ◦◦したいので◦◦する (e.g. 検索、コマンド実行) ◦ 何が起きると考えているか ◦ 実行してみたらどんな結果が得られたか ◦ 得られた結果は、実行前に考えたものと比べてどうか 15
16. 作業メモを書きましょう • OSS Gateのプラクティス ◦ どんな粒度で書いていくのかの動画もある 16
17. 作業メモを書きましょう • この章は最高なので読んで欲しい ◦ https://github.com/oss-gate/first-feedback-gui debook/blob/master/chapters/what.md 17
18. 18 https://github.com/oss-gate/first-feedback-guidebook/blob/master/chapters/what.md
19. つまずきに敏感でいる • 作業メモを残すと、メモの中につまずきが 書き残されていく ◦ OSS Gateの場合、メモの隙間にも注目できるように サポーターを配置している • 慣れてくるとメモを簡略化してもつまずきに 気づけるようになる 19
20. 20 前半のまとめ
21. 前半のまとめ • 技術記事は以下に類型化される ◦ 学習ノート、教科書、論文 • 最初はコミュニティに正の価値を提供せず、 学習ノートで良い ◦ 学習ノートにも良い学習ノートはある • 正の価値を提供するには気づきが必要 • つまずきに敏感でいるために作業メモを書く 21
22. 作業メモとWorking Out Loud • WOLはチーム開発を円滑に進めるテクニック 22 https://blog.studysapuri.jp/entry/2018/11/14/working-out-loud
23. 23 他人の仕事を面白がれる コミュニティ作り
24. よく聞く質問 • 「いるだけで成長できる環境(※) 」を作りたい ◦ 技術の話題で盛り上がれるコミュニティ • 社内から技術記事が湧いてくるようにしたい 24 https://tech.pepabo.com/2015/11/17/pepabo-tech-blog-has-started/
25. 話題が出ない →出る、に変えるには • 場を作る • 面白がりの信頼 25
26. 場を作る • 非同期よりも同期コミュニケーション ◦ 例えば、Slackに気になった技術記事のURLを投げた ら自然と会話が発生するかというと、そうでもない ◦ はてな社内でも、#engineer なら何かしら発生するが #ruby は会話が生まれづらい、とかがある ◦ 昼会で話題に出すと、URLだけよりも圧倒的に会話が 発生しやすい 26
27. 場を作る • 昼会に1h使っているチームもある 27 https://www.slideshare.net/takafumionaka/ss-251487630
28. 場を作る • 仲間を作る ◦ 例えば、いきなりesaやQiita Team等を導入しても、 まず上手くいかない ◦ 普段から会話がある中で、ストックとして書き残そう という動きとして発生するのが望ましい ◦ SaaSを使うのではなく「wikiを作る」をすると、一 緒に作った人は愛着もサンクコストもあるので、複数 人が投稿する場になるかも？ 28
29. 場を作る • ヒーローインタビュー ◦ 誰がどんな仕事をしていたかを把握した上で、 各仕事の興味深いところを紹介して、一言コメントを 求める、という辺りから始めると良い ◦ 自分から「こんな仕事があって〜」は出てこなくて も、水を向けられたら、楽しかったところ、難しかっ たところのコメントは出てくる 29
30. 場を作る • ヒーローインタビューの準備をするのは大変 ◦ 足を使って情報を集める必要がある ◦ 各プロジェクトのふりかえりから抽出する ▪ コメントにしやすい教訓が生まれているので、話題を振ると 教訓が出てくる ◦ 1on1を上手く使うと勝手に集まってくる ▪ 最近やったことを聞く中で「これをコメントして貰うと盛り 上がりそう」が分かる 30
31. 面白がりの信頼関係 • 1on1を基点にするのはオススメ ◦ 誰がどんな技術を使っているのかを、少なくとも自分 が知っている状態を作れる ◦ 誰がどんな技術に興味があるのかを、少なくとも自分 が知っている状態を作れる 31
32. 面白がりの信頼関係 • 1on1を基点にするのはオススメ ◦ その話題を面白がる相手が少なくとも自分1人はいる ぞというのを伝えられる ◦ 「面白がって貰える安心感」を渡す ▪ 成功体験になるので、ヒーローインタビュー時にも、出して 欲しいコメントが出てくる 32
33. 面白がりの信頼関係 • 面白がって貰える自信・信頼を構築すると、 場を用意するだけで書いて貰えるようになる ◦ 各チームの大小様々なやっていることを共有する会を やったら予想外に盛り上がった話 - Sexually Knowing ◦ 「他チームの人が面白いことをやっていること」に興 味を持つ状態を前段で作っておくと上手く回る 33
34. 面白がりの信頼関係 • 色んな粒度のコミュニティを用意する ◦ チームの昼会 ▪ チームで使っている技術の話題は興味を持って貰いやすい ◦ 技術勉強会 ▪ 人数が多い、誰かに伝わる、知らないことを知るのは楽しい ◦ サブ会 ▪ 特定技術に興味がある人が集まっているので、そもそも興味 がある 34
35. 35 　後半のまとめ
36. 後半のまとめ • 話題が出ない→出るに変えるには ◦ この人なら絶対この話題に食いつくだろう、という信 頼感を醸成していく ▪ 同期コミュニケーションで反応を引き出すことで、食いつき の確信を得ていく ▪ 同じ興味を持つ人を入れるハコを作る 36
37. 37 技術記事を書く ＆楽しむ チームの作り方
38. ご応募お待ちしています 38 https://jobs.qiita.com/employers/hatena-corp/dev_talks/255