淡々と続けてきたMigration Trackも、とうとう最終日になってしまいました。こんにちは、ソーシャルゲーム事業部ゲーム技研の谷脇です。
この記事はTech KAYAC Advent Calendar 2019 Migration Trackの25日目の記事です。24日目はWEB+DB Press Vol.114 に「マネージドサービスによる既存サーバの再構築」を寄稿しましたでした。
当技術ブログおよび、表の方のAdvent Calendarではは技術ブログなのに、人の行動原理について解説してみたり、カレーのきれいな食べ方の研究が載ったりと、普段我々が仕事で「技術」と呼ぶ範囲には含まれない話題も盛り上がりました。ただ僕はこういったネタも好きで、僕が主催する社内の勉強会であれば、仕事の技術、次に時代が来ると感じる話題、生活の知恵など、エモよりテクであると喋る人が言い張れるものならなんでもござれ、というスタンスでやっています。
そんな社内勉強会を、継続的に続けていくために、サロンにmigrationした話です。サロンっていうのは、オンラインサロンとかのサロンです。
社内勉強会の意義と継続性に関する課題
この記事で語る、社内勉強会の定義をしておきます。
- 参加者が社内の方のみで構成される
- 発表者も社内のみ
- 社外の方を読んで話を聞く特別回もあるが、性質が違ってくる
- 社内の案件について話したり聞くことが出来る
- プロダクトのコードを実際に見せたり、動いているサーバを見せながら話したりも
- 受託案件などは社内でもなかなか話すのが難しいものもありますが...
- 月1〜週1程度の頻度で開催される
と言ったところです。
そして、何故社内勉強会をやりたいのか、という欲求に対して2つの視点があります。それは聞く側と話す側の視点です。
- 聞く側: 知らない知見を実体験として吸える
- 話す側: 得られた知見が実際に正しいのか客観的な視点で見てもらえる
聞く側の話はよくされますが、話す側の欲求をどう満たすか、という視点も勉強会を成立させるのに必要な要素です。人に話を聞いてもらって嬉しい、という感情的なメリットもありますが、フィードバックをもらえる事自体にも価値を感じる人も多いです。
さて、これらの事柄から社内勉強会をやることに対しての、メリット・デメリットが導き出されます。
社内勉強会ならではのメリット: 話の一般化がある程度不要
知見を吸うだけなら社外の勉強会に行くのでもいいのでは、という声もあります。なので私なりに社内でやるメリットを言うなら、社内だから話せることがあるを挙げます。
社外の勉強会やカンファレンスで話す時には、話す内容を一般化する過程を経なければなりません。内容の一般化とは、以下に示すような事情がわかっている同僚ではなくても、話したいことが伝わるようにするために内容を付け足したり、落としたりする行為です。
得られた知見を一般化すると、他の種類の仕事や、他の会社の人も知見を活かせるようになります。
具体的にどうやって話を一般化するかというと、
- 話す事柄の詳細な定義
- この記事のようにしつこく定義しないと、人によって認識がブレます
- 前提条件の開示
- 歴史的経緯など、その技術の選択を何故したのか材料になるための前提知識
- 話したい課題の本質以外の情報の排除
- 具体的な案件や別カテゴリの話題などを盛り込むと話がブレます
- 似た種類の行為として、バグレポートを上げる際のバグが再現可能な最小のコードの提示が挙げられます
- 社内の機密情報の除外
- ビジネス上の機密情報を公開の場で言うのは様々なリスクがあります
- 実際に動いているコードを提示するなども、この項目によって除外されます
- なんらかの議論の答え
- 一般化する大きな理由として、聞く人にとってためになる話ができるかがあります
- 「困ってるんですよ〜」で終わる発表は聴衆もどう受け取っていいかわからなくなります。私個人としてはあってもいいとは思いますが、大体の人は発表している人なりの答えが聞きたいのではないのでしょうか
などが挙げられます。
ただ、ここで挙げた項目からわかるように、大変に骨が折れる作業ですし、頭を使います。また、一般化しすぎてあまりにも抽象化されてしまうと、課題と解決方法が捉えづらくなってしまう弊害もあります。今、書いていることがまさにそんな感じだなと思っております。
しかし、もし社内で事例発表をするケースだったらどうでしょうか？
具体的な案件のこともある程度話せますし、コードも例示することが出来ます。また、歴史的背景や社内の技術選択の指針のようなものも、聞いている人にはあらかじめ伝わっている事が多いため、前提の話は飛ばして話したい部分に重点を置いて話すことも出来ます。
また、社内勉強会であれば「困ってるんですよ〜」で終わってもいいと私は思っています。その場にいる人は具体的な手法に踏み込んで、解決方法を提案することが出来ます。そこから実際に手を付けてもいいでしょう。
社内勉強会でのデメリット: ずっと続けられるかどうか
社外の勉強会でも、勉強会を何度も継続的に開催できるかは悩んでいる事柄です。ただ、社内でクローズドな会だと人の入れ替わりがより起こりにくく、関わる人も入れ替わらないことから、運営をやる人が偏ります。
偏ると何が起こるかと言うと、運営をやっている人が忙しくなったり、飽きると終わります。
会社でやる勉強会は、会社が後押しする、ある意味強制的なイベントとしてやるというお墨付きがあると、継続性が緩和されることもあるのですが、カヤックは多様性と自主性を重んじていて、フラットな組織であることが是とする文化なので、強制参加の会をやるのはあまり馴染みがありません。
私も、2018年末頃に社内勉強会があまり開催されなくなっているのを見て、よーしやったるぞと引き取ってみたのですが、話題によって来る人が入れ替わったり、人数の差が激しかったり、話してくれる人を捕まえるのが難しかったりと、課題を感じて「ほんまにこれ続けられるんかな？」となって行き詰まっていました。
というわけで社内勉強会はやめてサロンをやることにしました
社内サロン
この話を相談した時に、「サロンをやればいいのでは」と弊社の人事部長に言われたときは「サロンって貴族がやるやつ？」って思いました。ですが、よく考えてみると、今抱えている課題を解決するのにぴったりな勉強会の形態だと考えるようになりました。
私が勉強会をやる際に大事にしたかったのは、以下の2つです。
- 定期的に開催される技術の話であれば話せる場・時間があること
- 聞きに来る人は社内の人であれば制限しないこと
これさえ守られれば、従来の「30分から1時間程度で、社内の人にスライドめくりながら話してもらう形態」にこだわらなくても良いなと感じたのでした。
そこで、世間のサロンの形態を調べると、
- クローズドな場で
- 1人ないし少数のコアメンバーの人が何かを話す
- コアメンバーが出した話題に関して議論する
と解釈したので、社内勉強会向きにアレンジしてみます。
- 社内というクローズドな場だが、社内には開けているようにする
- オンライン中継と録画と資料公開を常にする
- 何人かの社内で技術的に強いと言われている人を集めて、持ち回りで話す
- 話す人集めがしんどいのを解消するための施策
- 強い人は技術の話題に対して話しなれているはずなのと、話を聞く人を集めやすい
- 毎週1回30分
- 定番の番組にすると、聞きに来ることが習慣化されるのではという仮説
これでスタートしてみました。
半年やってみた感想
これは僕がはじめから意図してなかったのですが、「コアメンバーが聞きに来た人に対してお悩み相談する会」の形態をしたところ結構ウケたのでそれが続きました。
サロンで挙がった話題としては、
- 3Dのゲームで必要な技術を挙げて、どこを会社で伸ばすかという話 by 平山さん
- 社内のワークフロー整備してみたけれど、皆さんはどうですかという問いかけ by 私
- フロントエンドエンジニアが使う技術をコロコロ変えるのはなんでか by のびー
- IPアドレス認証やめたいけどどうすればやめられるのか by 組長
- ↑の話に関連して実は認証プロキシを作ってるよ by れもんさん
- チームを強くするためにいろいろ実験してるよ by 原さん
などなど、この場でしか聞けないたくさんの話が聞けました。
ただ、課題感もあって、一番は「技術的に強い人は引っ張りだこで忙しい」問題があります。なので、いつも聞きに来ている人にそろそろなにか話してみない？ と打診してみたり、話した人が次に話す人を決める方式にしてみるなど、いろいろ実験しています。
継続はある程度できたとして、次の目標は「安定的に聞きに来る人を増やす」ことだと考えています。話す人の様子を見ていると、聞きに来る人がいるかどうかが不安だったり、話が聞きに来た人に刺さるかどうかが不安というのを感じます。なので、理想の状態を「どんな話題でも興味津々に話を聞く人がたくさんいる」と定義して、サロンを改善していきたいと考えています。
ちょっとエモな感じになりましたが、Tech KAYAC Advent Calendar 2019 Migration Trackは以上です。良いお年を〜。
