敢えて公式感と敷居を高めた社内テックカンファレンスを開催する理由|100人超のエンジニア組織の組織学習事例

イントロダクション

こんにちはエンジニアリングマネージャーの普川泰如(@taipuka0)です。普段、プロジェクトの完了やシステムのリリース時、スプリント終了など、様々な機会で振り返りを行っていると思います。今回我々はその振り返りを敢えて社内テックカンファレンスとして、敷居高く行ったところ、良い振り返りが続出し、多くの学びや発見が生まれ、更には社内の交流も活発になるとても良いイベントにする事ができました。この記事ではその具体的な内容と実践ノウハウをお伝えしていきます。

開催に至る経緯

人材育成における「70:20:10の法則」

まず社内テックカンファレンスの開催に至った経緯を説明したいと思います。モノタロウではエンジニアの人数が年々増えていて、現在は社内で120人を超える程度で特に最近その増加ペースが上がっています。我々は会社やビジネスの成長を支えるためにエンジニア組織を拡大させていますが、それと同時に組織をよりよくするためにはエンジニア一人一人が自律的に成長することも重要だと考えています。

人材育成について、マイケル・ロンバルドとロバート・アイチンガーが書籍『Career Architect Development Planner』で記した「70:20:10の法則」が有名です。この法則によると人材育成に寄与する割合はそれぞれ、70%は仕事などの経験、20%は他者とのやり取り、10%は本や研修などが関係があるとされています。つまり育成については研修制度や教育プログラムを充実の効果は少なく、業務上の経験からいかに学びを抽出し活用できるかが大事だと考えられます

それに対して組織ができることは2つあります。

  • 一人一人にとって良い経験を行える機会を提供する事
  • またその経験からうまく学んでもらう事

前者はタスクやジョブアサインの話でそこにもいくつかのポイントはありますが、今回は後者の経験からいかに学びを得るかについて行った活動を紹介していきます。

振り返りから学ぶとはどういうことか

振り返りの手法はいくつかあると思います。有名な「KPT」や「YWT」です。我々のチームでは「熱気球 (Hot-air Balloon)」を使ったりします。どの方法を用いても本質的に行っていることは同じで「経験を一般化、抽象化して、その事象の構造を取り出すこと」に他なりません。その構造を他に転用することで、再現性が生まれます。プロジェクトの失敗の構造を理解することで、より確実な再発防止が行えます。ある状況で選んだ技術選定の判断基準の軸を他で使うことで、質の高い意思決定を再現できるのです

敢えて敷居を高くした発表の場を提供

 「振り返り」は以前から、業務やプロジェクト終了後チーム毎に行われていました。ただその実施は各チームに委ねていました。 そのため振り返りのやり方は様々で、振り返りからの学びの共有もチーム内に限定され他のチームまで共有されません。次の案件の期限がある場合は、その案件が優先となってしまい十分に振り返りを行えないことがあるなどが課題としてありました。

これらの課題を解決する方法を考えた結果、敢えて敷居を高くした社内の公式な発表場を設けることで振り返りの質が上がるのではと考えました。カンファレンス登壇、LT発表など敷居の高いアウトプットの機会に向けて自身の準備に気合が入るという経験は誰しもがあると思います。これを社内で用意してしまうのです。社内であれば発表に対するフィードバックも得やすく多角的な気づきも期待できます。こうして社内テックカンファレンスという案が生まれました。

リモートワークでの情報共有やコミュニケーションに関する危機意識

 もう一つの背景は組織内の情報共有に対する問題意識がありました。コロナ禍をきっかけにリモートワークへとワークスタイルが切り替わりました。幸い生産性が落ちる様子はなく仕事が継続出来ていますが、一方で組織内でのコミュニケーションが少なくなっています。チーム外のメンバー同士のやり取りや、雑談が少なくなったり、新しく入社した人が人間関係作りに苦労しているという問題が起きていました。そのためリモートワークで少なくなった他のチームの取り組みの情報の共有を補うという意味でも社内テックカンファレンスが有効だと考えました。

準備段階で行なったこと

コンセプトは「学びの最大化と組織学習」に定め、この社内テックカンファレンスのイベントの名前を「ManabiCon」と名付けました。その後、どんな背景で何を狙いとして行うかを共有するため企画書を作成しました。企画書の「なぜやるか」の部分を抜粋してみます。

  • 業務の振り返りと言語化
    • 自らのやったことを業務を振り返り、一般化/抽象化することで学びを促し、成長する機会を作る
    • 現場で出てきた技術的な内容を体系的に掘り下げることで深く理解を進める
  • アウトプット機会の提供
    • 部門公式のアウトプット場を作ることで、一定以上のクオリティのアウトプットを作る機会を提供できる。
    • その中で自分達の学びを言語化力、アウトプットする力を引き上げる
    • 他者からのフィードバックを得ることができ、気づきに繋がる。
    • 社内で練習しておくことで社外でのカンファレンスの登壇のハードルを下げる。
  • 組織内の情報共有
    • 情報の共有:リモートワーク環境下での情報共有、誰が何をやっているのかを知る。
    • 知識の共有:他者の学びから学ぶ。組織の知への転換
    • 熱量の共有:他者からの刺激を受け、自らの視野の拡張や気づきを得る。

社内テックカンファレンス盛り上げるためにやった7つの工夫

いざ実施する上でイベントをよくするための工夫を色々行いました。良かったものを紹介していきます。

1.原則全員参加で公式感の醸成

 組織の公式行事として行うことをアナウンスし部門全体の参加を呼びかけました。前述の通りオフィシャルなイベントであること、また多くの人が見てくれる「場」を提供することで、振り返りや学びが多く生まれる事が狙いです。また発表も全チーム実施とし、当日もどうしても必要な業務がない限り全員参加を原則としました。

2.低ハードル、低負担

 全チームでの発表をお願いしたのですが、業務もある中での準備は大変です。準備の負担を減らすことを考えました。具体的には準備、発表を個人よりチームの複数人でやっていただくことを推奨しました。誰か一人に負担となるのを避けるのが狙いでしたが、結果としてチーム全体でより深い学びを共有することができました。また過度な資料の作り込みの必要もないのでプレゼン形式でなくドキュメント形式もOKとしました。

3.発表用フレームワークの提供

発表内容の構成のフレームワークを共有しその流れに過去の業務を当てはめられるようにしました。発表内容は、担当マネージャーやテックリードなどから構成チェックと題材の技術的な部分の内容をフィードバックしてもらうようにしました。

4.聴き手の本気度をあげる複数トラック制

今回は敢えて複数トラック制にこだわりました。セッションが複数あると必然的に聴衆側は選ぶという行為が発生します。「選んだ」ということは興味のあるセッションですし、「選んだ」ことで聴く側の真剣度が上がります。もちろんZoom発表なので全て録画をすることで、選ばなかったセッションを観たいという希望にも対応しました。またどのセッションに何を持ってくるのかも慎重に決める必要がありました。

5.👏 と顔出しによる虚無感の回避

発表者が気持ちよく発表できる状態を作ることがそのセッションを成功するのに重要と考え、発表の開始前と、終わったあと、必ず拍手をしてもらうよううお願いしました。Zoom上なのでアイコンによる👏の表示や画面越しの拍手ですがやはり雰囲気は良くなります。また発表中、聴衆者側の人もにも可能であればカメラONにしてもらうようにお願いをしました。聴講者が全員Zoomカメラオフだと反応が見えず、話しづらくなるのを避けるためです。

6.副音声としてのSlack活用

Slackのイベント用チャネルに発表セッション毎のスレッドを用意して、聴き手に質問や感想を書いてもらうように誘導しました。普通のカンファレンスでもTwitterなどで行われていますが、社内でやる場合は気心もしれているメンバー同士なので、より活発に盛り上がることがわかりました。また質問によってはより詳しいドキュメントなどもすぐに共有されていきます。発表中についた質問に同じチームの人が回答するのはもちろんのこと、並行して議論が始まり、そこからも思わぬ気づきが出るなどです。

7.全セッションに司会付き

 発表者以外にセッション毎に司会進行役として発表チームのマネージャーをつけました。発表者を発表に集中してもらいたいのが狙いです。もう一つ、発表後のQAやディスカッションの場での掘り下げを行いたかったのもあります。あらかじめ発表内容をチェックしているメンバーがその場を回すことで、発表に入れられなかったポイントや別の視点での気づきを入れたりなど単純に一方的に発表するだけではない「場」にできました。

当日の様子

イベント当日の様子です。ManabiConの開会宣言で改めて学びはなぜ必要なのかを説明しました

リモートで行なっていることもあり、発表者が気持ちよく行えるようにお願いしました

各発表の雰囲気

SEOチームのチームビルディングについて

ZOOMとは別にSlackを通じて非同期でコミュニケーションを取ることできるようにした。聴講者から質問や自身での振り返りが多く書き込まれた。

終わった後はみんなで喝采を伝えるコミュニケーションを取り、発表者にお疲れ様と伝えられる仕組みを用意しました

当日の発表タイトル

今回の発表タイトルを並べておきます。 今後各セッションの内容は当ブログで順次公開していく予定です。是非お楽しみに。

TrackA TrackB
Manabi Con 趣旨説明 学びについて
Web 安定化PJT

トラブル多発にどのように対応したか?

社外コンサルとの協業で得た学び
度重なる再リリースから得た学び 機械学習基盤開発で学んだこと
課題解決へのアプローチ手法 新フロントエンドの技術選定をした話
特集ページスマホ化 [GCP]リソース/IAM自動チェックの仕組みの移行における技術選定と取り組み
社内バッチのマイグレーションからの学び 俯瞰的・相対的な学びから得た 技術の選択と学習 - ワークフローエンジンを通した学び -
リリース後の効果計測が大変だった話 言語シャッフルペアプロ始めました。
認定スクラムマスターが語るチームビルディングとは -SEOチームでの事例- アーキテクチャーチームの取り組み

結果と振り返り

アンケート結果

アンケートでは「業務に活かせますか」の問いに5段階評価で4ないし5と答えた方の合計が96.2%。皆さま何かしらの学びを持って帰れた様子です。

自由回答の感想もいくつかご紹介します

  • 各チームの取組みを聞ける機会はいままでなかったので、よい機会だったと思います。
  • 在宅勤務になってから他の方が何をしているか見えづらくなっており、それが見えたのが非常に良かった。
  • 自分で発表するにあたって言語化する過程で新たな発見が出てくるということもあり良かったです。
  • 知らない技術・システムの話を聞けたのは有意義でした。また、質疑応答を行ううちに「他のチームでも同じ課題を持っている/この取り組みに需要がある」と共通認識が形成されたのも良い点だと感じました。
  • お祭り感がでて楽しむこともできましたし、多くの学びを聞くことができてよかったです。

実施してみてわかったこと

こうして大盛況のうちに終えることができました。コロナ禍のリモートワーク下で日々の業務が単調になっていたこともイベントとして盛り上がった理由だと思います。それと同時にメンバーの皆さんの学びや知ることへの強い興味を今回改めて感じました。当初業務の振り返りと言語化、アウトプット機会の提供、組織内の情報共有という目的は十分に達成されたと思います。

 特に学びを共有した結果、いくつかのチームで同様の課題感が持っていることがわかり、早速連携が進んだり、当日の発表後のQAだけでなく、Slackでの会話も有効で、発表者以外の人から、同じ問題意識や別の視点がもたらされ、学びをより深いものに出来たことがよかったです。

社内ならではの良さの発見

今回社内限定のテックカンファレンスにすることで良い点が発見できました。まず参加者全体に、システムやサービスの知識が共有されている状態なので、会社、業務、システムの紹介などにあまり時間を割くことなく、発表時間の大半を主題に使って進むことができました。また、外部登壇ではないので、社外秘、NG情報などの制約がほぼなく全ての情報をあますことなく発表が可能でした。関係者しかいないので、特に取り繕う必要もなく、失敗も問題も極めてオープンに話せたので結果かなりディープなところまで議論がなされていきました。

今後について、学びの仕組み化

 今後は年2,3回程度の頻度で定期的に実施していく想定です。定期的に組織内全体で振り返りを行う機会を提供することで、学ぶことを仕組化に落とし込めると考えています。また今回はエンジニアだけのイベントとしましたが、デザイナーやデータサイエンティスト、マーケターなど他の職種の人も巻き込んで開催をする予定です。今回のカンファレンスでは同じ様な問題意識に色々な視点が入ることで色々な気づきが生まれました。多くの職種のメンバーが参加することでより多角的な視点からの振り返りが行われると思うので、今からワクワクしております!次回実施したらまた報告をしたいと思います。

 そしてエンジニアの成長にコミットし色々な組織施策を一緒に行って頂けるエンジニアリングマネージャーを募集しています。こちらからのご応募お待ちしております!

hrmos.co

弊社アーキテクトのインタビュー記事もどうぞ

note.com