Software engineering from east direction

六本木一丁目で働くソフトウェアエンジニアのブログ

外部イベント登壇しがち属性が考える登壇の使い方

TL;DR

  • 外部イベントを楽しむ・学びのきっかけにするための登壇の使い方
  • イベント運営の方々いつもほんとうにありがとうありがとう...

はじめに

社の飲み会などでカンファレンスに行ったり登壇したりすることの意味みたいなことがうっすら話題になり、各エンジニアの力量・フェーズによって"使い方"が変わるよなぁと思ったので考えをまとめてみます。

カンファレンスなどの外部イベントへ関わり始めたのは大学生のころからでした。大多数が職業エンジニアという属性の場に一人でいっていて、職業エンジニアになり数年経過した今でもいろいろなイベントに顔を出させていただいています。

そういった経過の中で、感じた登壇するとこういうことが良かったなとおもうことを書いてみようと思います。

目次

  • 外部イベントでの"交流を楽しくする"使い方
  • 外部イベント登壇をマイルストーンに置く"学びのペースメーカー"としての使い方
  • 思考の練度を上げる"きっかけ"としての使い方
  • 伝え方の練度を上げる"きっかけ"としての使い方

外部イベントでの"交流を楽しくする"使い方

カンファレンスなど初めて行く場で、その場で懇親会が始まったりすると、根本的に人見知りな私は話しかけるのに躊躇してしまいます。学生の頃は、「大学生なんです!」っていうと優しいおじさんたちが輪にいれてくれるといったことはあるのですが、職業エンジニアになるのと会話のフックが難しかったりしてさらに困難を極めます。

しかし、何かしらで登壇しておくと自分のセッションの聴講者の方々が大変ありがたいことに話しかけてくださったりします。
例えば、今年の6月29日に開催されたPHPカンファレンス福岡2019では、ユニットテストの現場の問題を原則に立ち返って考えるという内容の話をしたのですが、その後のAsk the Speakerや懇親会で、同じような課題感を持ってらっしゃる方々が集まってきていただいて、人見知りな私でも交流を楽しむことができました。

また、そういった交流の中で新しい気付きや課題を見つけることもあります。 例えば、Go Un ConferenceというイベントでGo API Validation error handlingという「みなさんどうしてますか?」という問いかけがほしい旨の内容を話すと、twitter上でそれに関する意見を貰えることができたりしました。

これは、聴講者として参加していただけでは得られなかった交流の仕方だなと思い感動を覚えました。

学びのペースメーカーとしての使い方

これについては、2018年のPHPカンファレンス2018でも次のようなLTをさせていただいていました。

俗に言う"発表駆動開発"というものでしょうか(本当に俗にいうかはわからないけどよく聞くので)。実際にこの効果はあって、普段業務では使ってないけど今後使っていきたい領域をカバーしたいというときに有用だと思います。
例えば、昨年のPHP勉強会でTerraformでAWSのインフラ構成構築を自動化する(入門)という発表をしました。この時の状況として、アプリケーションエンジニアなのでメインでTerraformを触るわけではないが、理解する必要があるし、少しずつクラウドやインフラ領域に対して自分の専門領域を広げていきたいと思っていました。そのために、雰囲気で見ている .tf ファイルを理解すべく発表をマイルストーンにおいてががっと勉強したという経緯があります。
このように、外部イベントで「その話ができるレベルにはなりたい」というマイルストーンをおいて、そこまで自分の能力を強制的に引き上げるというプロセスを私はよくやっていました。それの継続の末にいろいろな範囲をカバーできるようになってきた自分がいたりするので、負荷が高いやり方ですが眼の前の業務範囲に縛られないという状況を作りたい方にはおすすめな使い方だと思います。

逆に言うと、「その範囲は仕事の中で手が届くし、今やってないなら自分で仕事にしてしまえ!」くらいの能力・立場・心の力を持っているとこの使い方はあまり刺さらないメリットなのかもしれないと最近は思っています。

思考の練度を上げる"きっかけ"としての使い方

ソフトウェアエンジニアの"技術力"という言葉がどう定義でどう分類できるかというのは難しいですが、一つの要素として、実現するソフトウェアシステムに込められた 思考の深さ があるのではと思っています。
一つのクラスを作るなり機能を作るなりしても、その人が普段どれだけソフトウェア開発についての思考を巡らせていて、設計ノウハウ・知力をそこに込められているかは、結果的にメンテナンス性やパフォーマンス性といった別の指標で現れてくるのではと考えています。そういった意味で、さらに深いレベルで思考する、思考の練度を上げていくことは個人の能力に直結していくと思っています。

例えば、僕はユニットテストという一つのテーマでPHP系カンファレンスで何度か話しているのですが、それは毎回の発表時点ではまだ思考の練度が足りず話せなかったことをやろうとしています。カンファレンスを通して自分のソフトウェア開発に対する思考の練度を高めようとしています。

そういった形で自身のソフトウェア開発の造詣を深めるために登壇というきっかけを作るという事ができると思っています。

伝え方の練度を上げる"きっかけ"としての使い方

同僚のエンジニアのコードに対してレビューするといった機会や、同僚に対して何かしら働きかけを行いたいと思った際に、様々な伝え方があると思います。「俺のコードを読んでついてこい」というような職人タイプの引っ張り方もあれば、一から言葉とコード例で伝えていくという引っ張り方もあります。
職業エンジニアとしてそのソフトウェア・あるいはサービスに貢献する方法として、一個人としてのスキルの提供を通して貢献していくてもありますが、より再現性・レバレッジを利かせるのであれば自分以外も含めてチーム全体でどう成果物を出せるかというのは、大なり小なり重要な貢献の仕方です。 後者を考えると、「どう伝えるか」という点においていろいろな難しさがありますよね。普段から考えていないと「なんとなくこうしてる」といった見えない慣習的なことがあります。あるいは、自分のスタイルを人に伝達しようとした際に、そのメリット・デメリットを把握できているか、その人の状態で無理のないやり方に落とし込めるかという点が求められます。

そのような伝え方の練度をあげるために、一つ登壇して"アウトプットを残す"ということが有効かなと考えています。
たとえば、PHPカンファレンス仙台2019 にて、テストが辛いを解決するテスト駆動開発のアプローチという発表をしました。
これは、「このコードにテストを書くのがつらいんだがどうすればいいだろう」というコードの悩みを何度か現場で聞き、それに対して説明していたことをちゃんと筋道立てた形で資料にしたいとおもったことがきっかけでプロポーザルを出したものです。
このように、実際に現場で「あの人にどう伝えればいいだろう」というテーマをもとに発表内容を構成していくと、自分自身が実は意識していなかったことが言語化され、伝える際の参考資料も登壇を通して手に入れることができます。
多かれ少なかれ、誰かに対して働きかけを行ったり、自身の知っていること・身につけていることを伝搬する機会はあると思うので、そのようなことを考えることが多い方にはこういう使い方がおすすめなのではと思っています。

最後に

使い方という形で登壇に対して自分が思っている「使い方」を書いてみました。こういう雑な記事がかけるのも、普段カンファレンスやイベントを有志で運営していただいている方々のおかげです。この場を借りて皆様に深く感謝の意を申し上げます。
この記事では、「エンジニアとしての市場価値」などの観点は入れていません。実際、個人のコミュニティにおける注目度が上がることによって、所属している企業に興味を持ってもらうフックになるという意味での価値は一つあると思います。個人的には その価値に溺れてしまうと名実の実が著しく乖離してしまう状況になってしまう危惧があり、今回はあえて省略させていただきました。
アウトプットの一つとして登壇というものをどう使えそうかということをつらつらと書きましたが、登壇だけが全てではまったくなく、業務やOSSのコントリビュート・ブログ等様々なものを、それぞれ個人が使い分けていけばいいと思います。
一つの考え方として参考になれば幸いです