TL;DR
方法 -> なんかいい感じに中規模以上のものを継続的につくる
発表しなきゃいけない理由 -> 別にないけど、強いて言うならデメリットがないから。
これをまとめたきっかけ
最近よくGo界隈とかでLTだの通常のトークだので参加させていただく機会があるんですが、ついこの間その活動を観測してくれた人から、
- 準備やらプライベート開発の時間はどうやって作るんですか？
- 技術的に表に出るためにあと一歩欲しいけど、足りないところをどう埋めるべきですか？
- なんで登壇するんですか？（本質的に技術的に表に出る必要ってあるんですか）
的な質問を投げかけられて、自分なりの答えを返したのでまとめる。（答えるのもおこがましい感じはしましたが）
あとは、最近よく会社でエンジニアの方を採用するときに、積極的に発信する機会って増やすべきかな、そうだとしたらどうやって発信するのがいいんだろうと考えていたのもある。
準備やらプライベート開発の時間はどうやって作るんですか？
これはインプットとアウトプットの２つで分けて時間の取り方を考えると、
インプット
気が向いた時にやってることの範囲でいうと、
- 電車の中でドキュメント読む
- 帰って歩きながらドキュメント読む
- ジムでトレーニングしてるときに腹筋背筋してる時にドキュメント読む
とか。
あとは業務に関連性の高いことをやるようにすれば、インプットを効率よく行えるのは自明で、例えば今いる会社はAWSのインフラ周りの構築フローを自動化しているのですが、似たような構成をTerraformでやるとどうなるのか、的なことを勉強してます。
あと、僕は自分を追い込むためにインプットのやり方をこうしているのではないです。自分のやっていることが好奇心による没頭的な行為なのか、気合いによる曖昧な目的意識による行為なのか区別して、好奇心が湧くテーマだけ開発するようにします。スパルタっぽいやり方は完全に向いてないです。
アウトプット
これは毎日githubにコミットする習慣があるので、時間があるときはコード書くようにしてます。（毎日良い感じのコードかけるわけじゃない。つらい。）
目下の悩みは、terraformの勉強がはかどるのはいいけど、Goを書く時間が減ってることです…
まとめると、インプットの時間に区切りを設けてないので、それなりにいつもアウトプットの時間が取れています、ということです。
あと、トークの準備でいうと、スライドの準備が4時間くらいで、発表の練習は脳内でするくらいで正直あんまり時間とってない…
技術的に表に出るためにあと一歩欲しいけど、足りないところをどう埋めるべきですか？
これに関しては、一個の、中規模以上のものを自分一人で作ってみるのがいいです。小規模のライブラリとかはLTとかならいいんですが、通常トークだときついですよね。
僕も小さくgem作っていたりした時期がありましたが、結局実践ノウハウを話す現場のパイオニアのトークほど有意義にはできません。そういうとき自分の作ったものへの意義が見出せなくてコーディングモチベが下がるので、負の連鎖を生みます。
それを回避するために、とりあえず中規模以上のAPIを書くことにしました。たとえば、僕はクローラーAPIを書いたり、今は動画配信サーバーを書こうとしています。サービス一個作ってみるともっといい感じにノウハウが得られると思います。
さらに、それらを継続的に開発するのが結構肝かなとおもっていて、普通に作りきるだけだと、いまいちのノウハウで完結してしまって、実はこれもまた小さいライブラリを作るのと同じ粒度のノウハウしか出てこないな、と個人的には感じています。リファクタリングした結果、人に見せる段階に至ったかなと思えるには、継続的な開発期間って必要になりますし。
「この機能つけたいな」「最近だとこういう標準パッケージが出たから入れてみよう」とかすると、徐々に発表内容として成立するものが出てくる気がしてます。
なんで登壇するんですか？（本質的に技術的に表に出る必要ってあるんですか）
個人としての側面
発表することのデメリットがないからするっていうのが一番大きくて、個人的なメリットでいうと、
- 困った時に質問できる相手ができる
- 発表できるレベルまではコード書かなきゃいけないという目標ができる
- コミュニティに貢献できる
とかでしょうか。
本音
上に書いたのは建前で、
- 懇親会で自分から話しかけなくても済む
- 他者から観測可能な価値をアピールできる
- 自分のやってることに明確な評価が欲しい。褒めて！
- スライドの方が視覚的に納得しやすいので、実はブログとかより拡散されやすいのでよい
が本音です。
懇親会で自分から話しかけなくても済む
というのは結構個人的には大事です。懇親会でベテランの方がわいわい話してる中に入ってくの勇気要りませんか！？メリットを実感したいので懇親会ではぜひみなさん話しかけてください。頼む。
あとコミュニティに貢献するとか、僕が言うのはおこがましいと思っていて、そういうのはもうちょっと歳をとったら言いたいな、と思っています。
組織的な側面
積極エンジニア採用中で、組織的にエンジニアが外に出て発表すべき、みたいなのもあると思うのですが、これは最適解がないなと思います。
自社開催で勉強会やってるところは、「景気いいな」と思う一方で、その企業に興味なかったり、別の勉強会で発表してた有名なエンジニアがいる、とかじゃない限り、企業によってはあまり行かないのかなと思います。そういう意味で有名なエンジニアを抱えてる企業が自社開催イベントをやると、「おっあの人出るのかな」「あの人以外にもすごい人がいるのかな」というワクワク感があって、そこは強みですよね。逆に外の勉強会である程度発表してないのに、自社開催をいきなりやるのは、その勉強会自体のプレゼンスが高まるまで根気良く待つか、なかなかうまくいかないか、になるだろうなと思います。
あと、事業的に安定してないのにバンバン勉強会行ったりブログ書いたりするの本当よくないよねという話を何人かとしていて、まずユーザーにちゃんと価値を届けられるクオリティにするのと、お金稼ぐの大事ですよね。
とはいえ、組織としてエンジニアを採用したくて、事業もいい感じに拡大してきたというフェーズの場合、勉強会とかでその会社の人が登壇してないと、「技術的にどういうことやってるのか」「魅力的な人がいるのか」というのが他者から観測できないので、ちゃんと言語別の大きな勉強会とかで発表する必要が出てくるなと思います。そして各分野でプレゼンスを持った技術者が何人か出てきたら自社開催の勉強会をやる、というのが相性いい気がしますね、というのをぼんやりお昼ご飯を食べながら話していました。
まとめるとデメリットがないし、企業のフェーズによっては採用に効いてくる、ということなんですが、「なんで発表する必要があるの？」とか聞かれると、個人的な側面の本音の部分を元に返答しそうになるのをこらえつつ、一度冷静になった後、「いや別に発表する必要なんかないし、個人の承認欲求だの、人と仲良くしたいだのがモチベーションなので、それに興味がないならやらなくていいんじゃないの」というのが答えかなと思いたって、いつも返答しています。
