こんにちは！
インフラ部署にあるチームのマネージャーとして仕事をしている奥村です。
今回の記事では、チームで行っている取り組みを3ヶ月間続けてみて、続けてみた結果「楽しい」といえるものになってきたのでまとめてみました。というものです。
2018年11月頃に
という記事を書かせて頂いて、新しく楽しく効果的 な取り組みをしているということを伝えたつもりです。
伝わっていない方は今回の記事で伝わればいいなぁと思います。
今回話すこと
10月頃からチームで行っている2つの取り組みについて紹介させて頂きます。
紹介するにあたって、取り組みの名前を「チームで使っている名前」で紹介させて頂くとともに、名前の由来も紹介いたします。
また、今回紹介する2つの取り組みは、「技術力向上・知識向上」に主眼を置いた取り組みとなります。
取り組みの名前は
- BFQ（Break First Question）
- モブPoC
です。
チーム構成
- 私
- ベテラン
- 新卒2年目
の3人です。
取り組みについて
BFQ
BFQとは、「Break First Question」の略です。 
一言で説明すると、「一日の最初(First)にアイスブレイク(break)を兼ねて行われる問題の出し合い」です。（朝ごはんのようなものという意も込めています。）
ここでいう問題には、IT基礎的な問題や、クラウドサービスの知識問題、ミドルウェアに関する知識問題などが含まれます。
流れ
BFQの流れは以下の通りです。
- 事前に、それぞれのメンバーが問題をストックしておく
- 日々の学びなど
- 朝会の後に、立った状態でそのまま行います。
- 一人が出題者として問題を出し、他のメンバーがそれに答える
- 正解発表&解説
- 問題の資料作成
- 問題、解答、解説の構成
あらかじめ、それぞれのメンバーが問題をストックしておき、日ごとに出題者をローテーションします。
良いところ
取り組んでいて感じているのですが、全体的に良い事が多いです。
朝会のアイスブレイクの延長線という点でも結構効果があると思いますが、それ以外の特筆したい部分を説明します。
事前に、それぞれのメンバーが問題をストックしておく
まず、「事前に、それぞれのメンバーが問題をストックしておく」 ですが、日々の業務などで得た知識をアウトプットの形まで意識して準備できている点です。
かつ、知識を習得するときには自ら問題を作ることは効率が良いとされています。
それを同時に行える問題のストックはすごく良いです。
問題の資料の作成
そして、「問題の資料の作成」 です。
問題資料の作成は、基本的に「回答できなかった人」が作成するようにしています。
問題に回答できた人は、すでに知識として身についていると言えます。逆に、答えれなった人は、初めて知ったことだったり、まだ知識として身についていないことです。
解説をされ自身のインプットとし、それをすぐにアウトプットするという流れができています。
さらに、解説された以上の事を改めて自分で調べて資料を作成することで、より深い知識を付けれると思います。
誤った理解になっていないか、出題者がレビューすることも大切です。
やってみて
10月の中旬から現在まで営業日は毎日行えており、現在では64問作成されました。
作成された資料のイメージはこんな感じです。
例題として
- CAP定理を説明してください
- RASISってなんですか？
- FWにはステートレスとステートフルの2タイプがあります。それぞれ説明してください。また、それぞれ製品名や機能名をあげてみてください。(何個でもok)
- S3にファイルを保存する場合、単一のファイルサイズの制限はあるか？
- MySQLのレプリケーションの仕組みを図に書いて答えてください
などが過去に出題さました。ぜひ上記問題だけでも回答を考えてみてください。
モブPoC
続いて、モブPoCについて説明します。
そもそもPoCとは
概念実証（がいねんじっしょう、英: Proof of concept、ポック、ピーオーシー）は、新たな概念やアイデアの実現可能性を示すために、簡単かつ不完全な実現化（または概要）を行うこと。あるいは原理のデモンストレーションによって、ある概念や理論の実用化が可能であることを示すこと。
とWikipediaに載っていましたが、私のチームでは「技術検証」と読み取り、実践しています。
こちらは単純で、モブプロ、モブレビューなどのモブ活動を技術検証で行っているという事です。
新しい技術や、使ったことのないマネージドサービス、アップデートされたマネージドサービスなどを対象とし、検証を行っています。
モブプロなどのきっちりした枠組みは設けずに、複数人で一つの画面をみて、情報をまとめていくという活動になります。
週に1回2時間で実施しています。
流れ
- 技術検証の対象を決めておく
- 当日までにそれぞれのメンバーがざっと概要だけ確認しておく
- 一人がPCの画面をディスプレイに表示する
- 全員でどうやって進めていくか考える。
- 対象のドキュメントを読み進めていくことが多いです。
良いところ
私が感じている良いところを挙げます。
- PoCにより、実現手段の手札が増える
- 相談や提案時に検証した記録があると役立ちます。
- モブでやることにより、チーム内での対象への認識がそろう
- 検証時点で発生した問題に複数人で取り掛かれるので解決が早い
ざっとこのような良いところがあります。
モブでやることにより、チーム内での対象への認識がそろう 個人的にはこの点が大きいかと思います。
技術検証した結果を資料として残すのも良いですが、認識が揃うという点ではモブで実施するのは効果的です。
現在よく検証対象として扱うのは、「使った事がないクラウドのマネージドサービス」です。(AWS, GCP等)
バージョンアップなどで追加された機能をこういう場で検証できると、一気にチームの知識が増えて、より良いと思います。
まとめ
今回挙げた2つの取り組み以外にも
- SRE本読書感想・議論会
- 全員でポモドーロデイ
など様々な取り組みを行っています。
このような取り組みは、私含めたチームメンバーの誰かが思いつき、とりあえずやってみて、改善点があれば改善してまた取り組むという流れで実施しています。
枠にはまらず「こうすれば良さそう」という取り組みを実施できることが一番の取り組みなのかもしれません。
面白そうだと思ったら是非実践してみてください！
最後までご覧いただきありがとうございました。
