👩🏫 要約
"学び向上し続けるエンジニア組織" を作るための足掛かりとして
Matcher エンジニアチームに1日10分の『本日の学びシェアタイム』を提案・導入してから 1年 が経ちました。
結果、
・学びの蓄積によって、日々向上している感覚を得られる
・誰かの学びが自分の学びにもなる
・日々の業務の中から「何か学びを得よう」とする意識が生まれる
・学びや技術が属人化されず、組織に形式知として蓄積されていく
などの良い効果が得られました。
エンジニアチーム内でコミュニケーションが生まれるきっかけにもなり、
チーム感の醸成にも寄与するためフルリモートが基本のエンジニアチームにもおすすめです！
🏃♂️ 何をやっているか
弊社 Matcher株式会社 のエンジニアチームでは
1年 ほど前から『本日の学びシェアタイム』を実施しています。
読んで字の如く、
「今日の業務の中で新しく学んだこと・気づきなどがあればお互いに共有しよう！」
という時間のことです。
業務の中で何か新しく学んだことや気づきがあれば
それをエンジニアチームみんなで共有しているスプレッドシートに記載しておき、
終業前の 10分間 を使ってお互いにその日の学びを共有し合う、という取り組みをほぼ毎日しています。
Matcher では「今日の学びやろう」「学びタイムいこう」が合言葉になり
ぞろぞろみんなで集まって一日の学びを共有し合う、みたいな感じになっています。
(ということで、以下 "学びタイム" と呼ぶことにします)
↑ 実際に使っているスプレッドシートはこんな感じです。
ほんとうに雑多にいろいろ書いてあります。
(スプレッドシートはなぜか "怒涛の学びタイム" という名前になっています🌀)
🗺 やろうと思った背景
僕は自分が所属する組織を "他の人に誇れる強い組織" にしたいという思いがあります。
自分なりの強い組織の像が "学び向上し続ける組織" であるため、
Matcher のエンジニアチームを『学び向上し続けるエンジニア組織』にするためにどうしたらよいかを考えている中で
手始めに「学びタイムを導入しよう！」と思い至りました。
『個人目線』『組織目線』の大きく 2つ に分けて
学びタイム提案当時 (1年前) 考えていたことを雑に書いておきます。
-
個人目線
- 元々『スプレッドシートへの学びの蓄積』をひとりでやっていた
- 記憶力に優れた方ではないため、記憶の外部化をするため
- 一人でやっている中で「同じことをひとりでやるよりもチームの取り組みとして導入した方がよくね？」と思った
- 自分の学びがチームメンバーの学びになるし、チームメンバーの学びが自分の学びになるから
- 何より今は自分の技術力向上が自分個人にとっても組織にとっても最重要ミッションだから、周りのメンバーの学びを自分のものにできるこの取り組みはやるべき 🚀
-
組織目線
- 大前提、『学び向上し続ける組織』を作りたい
- 特にエンジニアは労働集約ではなく知識集約だから学び続けることをやめてはならない
- そのために、『学び向上しつづけるための仕組み・文化』を組織に根付かせたい
- "学び向上し続けること" を構成員各々の意識・努力のみに帰結してしまうのはコントロールできない要素が多く、不安定
- だから、構成員が所属する組織の側にそれを可能にする仕組みや文化があることが不可欠
- その一歩目として、日々の業務の中で生まれる学びをその場限りのものにせず蓄積していく仕組みを組織に備えたい
- この仕組みが運用され組織に根付くことで、『学び向上しつづける組織』に近づくのではないか
- エンジニアが 3人 とまだ規模が小さい今のうちから組織に良い習慣を作り、それが文化になればその後入ってくれる人たちにとってはそれが当たり前となり、組織のスタンダードが上がる
- となれば、今からできることやるに越したことはない 🚀
💡 実際にやってみてどうだったか
結論「やってよかった！やり続けたい！」という話なのですが
なにがどう良かったかの自分なりの解釈について、
『個人目線』『組織目線』の 2つ に分けて書いていきます。
- 個人目線で良かったこと
個人目線で良かったことについては
・学びを共有する側
・学びを共有される側
で得られるものが違うと感じているので分けて書きます。
『学びを共有する側』 が得られるもの
① 日々積み重ね向上している感を得ることができる
自分ができるようになったこと、学んだことが可視化され日々蓄積されていくためです。
毎日何か新しい学びや気づきがあればスプレッドシートに1行追加していき
後から見返すと過去の自分が学んできた分だけ行数が増えている、
というのは非常にわかりやすく、モチベーションにもなります。
また、自分の学びを他者に伝える過程で学びがより深化します。
言語化する中で何が理解できていて、反対に何が理解できていないのかが明らかになるためです。
--
② 自分ひとりのときでは得られなかった視点の学びを得ることができる
伝えた相手から、自分が気づかなかった学びポイントや指摘を得ることができるためです。
「今日 JavaScript の実装で forEach を初めて使いました！便利でした！」
「あれ、そのケースだったら forEach より map の方がいいんじゃね？そのまま戻り値使えるし」
「今日 JavaScript でスプレッド構文を初めて使いました！便利でした！」
「いいね！実は同じようなのが Ruby にもあって、スプラット演算子っていうんだけど...」
学びタイムをやっていると結構こういうことがあります。
これはひとりでスプレッドシートに学びを蓄積していた時と比較して
明らかな利点だと感じています。
『学びを共有される側』 が得られるもの
① 誰かの学びが自分の学びにもなる
こちらはシンプルです。
チームメンバーの学び共有を受ける中で、それを自分の学びにもできます。
また、学びの内容それ自体だけではなく
その人の『学びの作り方』に注目するとさらに有意義です。
「このコードをその切り口で読むとそんな学びを得られるのか」
「その疑問にブチ当たったときにそうやって考えてるのか」
「そもそもどんな風に考えているとそこに疑問を持つことができるんだろう？」
など、よりメタな学びや気づきを得ることができます。
--
② その人自身のことを知ることができる
こちらは技術的な内容ではなく、
学びを共有してくれているその人自身について理解を深めることができるよね、ということです。
学び共有を通じて
・その人がどんなことをしているのか分かる
・その人の技術レベルが推察できる (どんなサポートが必要そうか判断する材料になる)
・その人の興味・関心が分かる
・その人の技術的な成長を見て取れる
など、様々な利点があると感じています。
エンジニアは業務の性質上、一人でもくもくと作業をすることが少なくないため
毎日学びを共有しつつチーム内でコミュニケーションを取る機会になっているのは良い点だと感じています。
- 組織目線で良かったこと
① 業務中のひとつひとつから何かを気づき学びとろうという意識にさせる
不思議なもので、学びタイムがあると
「何か言える学び用意したいな！」という気持ちになります。
(少なくとも自分はなりました)
これによって、日々の業務で生じた学びや気づきの種に対して
敏感になり見逃しにくくなります。
人間は系が及ぼす影響から良くも悪くも自由になれない生き物なので
系を目的に応じた最適な形にすることを諦めなければ、
人間の思考や行動をある程度ハックできると個人的には考えています。
学びタイムの導入・実施を通じて、上記のことを改めて感じました。
--
② 学びや技術が属人化されず、組織に形式知として蓄積されていく
エンジニアチームみんなで共通のシートに学びを蓄積していくため、
誰でもあとからシートを見返すことができます。
実際に、業務にあたっていて
「あ、これ学びタイムで言ってたやつだ... 何だっけ... 思い出せない...！？」
というときに
学びシートを開いてシート内検索をして対象の学びを発見、ことなきを得る
ということがこれまで何度もありました。
個人で生じた学びを個人の枠内に閉じず、
学びタイムという形で共有しているからこそ実現できる動きに間違いないため
前述のようなことがあったときには学びタイムの意義を再認識できて嬉しい気持ちになります。
✏️ 【重要】 学びタイム実施のコツ
最後に、学びタイム実施のコツを記して終わりにします。
コツは『どんなに小さな学びや気づきであっても、シートに記入し共有する』こと、
そしてそれを奨励することです。
--
measure の発音は「ミーシャー」ではなく「メジャー」
これは実際に Matcher の学びシートの貴重な 1行 を占めている、僕が生み出した学びです。
学びに貴賤上下はありませんが、Matcher の学びシートの中で
最も小粒な学びであることに間違いありません。
measure という単語が名前に入った関数の処理について議論しているときに
僕の発音がおかしいことを後輩から指摘され、晴れて学びの仲間入りとなりました 🌀
--
こんな小粒の学びですが、こいつには立派な役割があります。
それは学びシートへの記入ハードルを極限まで下げることです。
事実、Matcher のエンジニアチームでは
「ミーシャーも立派な学び。どんなに小さな学びや気づきでも書こう！」
という言葉が半分イジリ、半分本気で使われています。
↑ これがあるかないかで、シートへの記入ハードルは全然違ってくると考えています。
--
特に、エンジニアを始めたての新人さん視点。
おそらく新人さんにとっての学びは基礎的な事柄が多く、
先輩エンジニアにとっては既知の内容であることがほとんどでしょう。
そして、そんなことは新人さん自身も痛いほどわかっています。
それで「さあ、君の学びをシートに書いて共有してごらん！」と声高らかに言われても
「こんな小さな基礎的なこと書いたって意味ないじゃん...」となってしまうのは想像に難くないはず。
そんなときにミーシャー (概念) があれば
「ミーシャーでもイケるなら、自分も学び書いてよさそう...！」
と少しでも思えるのではないでしょうか？
まとめると
「どんなに小さな学びや気づきでもいいから、書いて共有しよう！」
「それがいつか誰かにとってのミーシャーとなって、勇気を与えるかもしれない！」
というお話でした。
--
僕もようやくエンジニア歴が 丸2年 になろうとしており、
以前よりはだんだんとわかることも増えてきましたが正直全然まだまだです。
学びタイムを皮切りに、"学び向上し続ける組織" を自らの手で作り、
その中に身を置くことによって自分個人も向上させていきたい所存です。
それでは、日々日々学んでいきましょう！
最後まで読んでいただきありがとうございました！
(もしみなさんのエンジニアチームでやっている良い取り組みがあったらご教授ください...！🙏)