15分のアウトプットタイム実践したらすごく効果があった報告
この記事はQiitaに上がったこの記事を自社で実践した結果の中間報告です。
最終的なゴールに据えているのは、施策としてこの15分のアウトプットタイムをするのではなく
組織の文化として当たり前に自分以外の人が実践するような文化まで持っていくことです。
2週間この施策をしてみたので
- 実際にやってみてどうだったか
- 実践にあたってのコツ
この辺を報告していきます。
15分アウトプットタイムとは
詳細は記事を読んでいただくのが一番ですが簡単に紹介を。
15分アウトプットタイムとは
- 15分間で行うアウトプットの時間
- アウトプットする担当者は課題の本や設計についてまとめる
- インプットの負荷が高くならないよう本なら30Pほどを目安にする
- 新卒とベテランを混ぜて行う
こんな感じのショートタイム勉強会です。
弊社では課題図書として
- Effective Scala
- リーダブルコード
この2つととある設計パターンに関するものでおこないました。
設計のときの学びが深かったのでまた別のnoteでまとめます。
弊社での実践の仕方
毎日適当に15分時間を確保しています。
担当は順番で持ち回りにしていています。
まずは言い出しっぺの僕からスタートしてアウトプットの仕方とかをなんとなく見せます。
基本的には
- 今回の学び
- 書いてある内容の要約
- どうやって業務に活かすか
この辺を抑えながら自分の言葉で喋ることを意識していきます。
足りない部分や補足は先輩や聞いている側がします。
タイマーで15分を測りながらおこない15分で強制終了としています。
これによって話す内容を精査し臨むことができるようにしています。
実際にやった事例の紹介
Effective Scalaをやった時の事例を紹介します。
担当者は2~3章分を読んで発表をします。
Effective Scala1~3章では書式やパターンマッチそもそもEffective Scalaがかかれているのかについて触れられています。
ちょうど実施した期間ではScalaでかかれたサーバーの改修を進めるにあたって練習用のissueをこなしているタイミングでした。
新卒と内定者インターンの感想としては
- 他人の知識を取り入れて自分の勉強や理解がすすんだ。
- 自分が発表するにあたって自分が担当したissueやコードをみなおした
- Pull Requestについていたコメントの意味や意図がよくわかった。
- 具体的にかかれている実装を想像できたので改修のイメージがつきやすくなった
といった感想をもらいました。
また実際、内定者インターンのアウトプットの精度が高くなり主体的にissueをたてたり
実装の提案をしてくれるなどの成長が短期間で現れたのはいい傾向だとおもいます。
また、先輩と僕も
- もう一度強制的に昔のインプットを反芻したことで認識が改まった。
- 具体例を実際のコードの中からさがしたことによってリファクタリングがすすんだ
- 後輩の成長がきっかけとなりインプットの熱とアウトプットへの意識がたかまった
などいい結果をえられました。
まとめ
中間報告としては
- 15分アウトプットタイムは年次に関わらずいい効果があるぞ
- インプットの負荷バランスをとるのが意外と難しい(調子にのってやりすぎてしまう)
- 時間を固定してとるほうがいい
- 文化になるまでにどう繰り返していくかが課題
こんなところでしょうか。
最終目標を施策ではなく文化としてアウトプットタイムをつくれるようにすることとしているので
施策→文化までもっていくために必要なことを実装していかないといけ無いです。
文化として昇華したいのはなぜかというと、弊社が裁量労働を採用しているので
施策として実施しているとワーキングタイムのずれから施策が頓挫しかねないからです。
この辺はまずは固定の時間を設定していくのがいいんではないかというのが今の答えです。
短期的にも効果はあるので新卒が一定のレベルになるまでやるとかでもいいかなと思います！
インプットの負荷をうまくバランシングしないと調子にのって過負荷になり
続けるのが辛くなってしまいます。
ファシリテーター役の先輩方がきっちりと決めてあげましょう。個人的な感想としてはわざわざ過負荷にしなくても
それなりにきちっとした結果がでます。ゆるいくらいでもいいでしょう。
フィードバックの時は詰めすぎず、褒めすぎずを心がけています。
良いフィードバックの仕方については今後の課題として残してあります。
皆さんもレッツ短時間アウトプットタイム！！！
いいなと思ったら応援しよう！
