エンジニアチームでは毎週火曜日、午前の1時間くらいで全員でエンジニアMTGを開催している。議題は主に普段の業務の中で感じた問題点の改善で、GoogleのSpreadsheetをエンジニアの誰もが書き込めるようにして随時ストックするようにしている。
もともとは技術的に深堀りした内容をエンジニアどうしで共有しよう、というちょっとした勉強会目的で集まるようになったのが始まりだった。それが今となっては情報共有の他に、お互いにコードレビューをしたり、モブプログラミングなどのエンジニアまわりで流行しているプログラミング方法のお試し導入や、仕事で使っているドキュメントの改善など、エンジニアチームをより良くしていくための様々な活動を行う場となっている。その中でも特に有意義だと考えている取り組みを紹介したい。
それぞれが愛用しているツールを共有する
ベイジでは基本的に一案件に対してエンジニアは一人ということが多いので、実は普通に仕事をしているだけでは隣のエンジニアがどういう風に仕事をしているか、よくわからない。この状態を私はかなりもったいないと思っている。せっかく同じような仕事をしているのなら、それぞれが効率化のために工夫している技を共有したほうがチームにとっては有益ではないだろうか。
そこで、各エンジニアがどのような工夫をしているか知るために、それぞれが使っている便利ツールの情報共有を行っている。特に多いのはエンジニア全員が使っているエディター「VS Code」の拡張機能や、Chromeのアドオンの紹介だ。同じ職種とはいえ、それぞれが新しい拡張機能を導入するので意外と知らない便利な機能を発見する機会になっている。
このツール共有は定期的に行う他に、新人エンジニアが入社したタイミングでも行っている。普段からエンジニア間で共有しておくことで、新人の方にもスムーズにおすすめの環境を伝えることができている。
ドキュメントを見直す
コーディングに関係するガイドラインやチェックシートなどのドキュメントの見直しは過去の議題を整理してみても最も議題に上った回数が多かった。これまでに見直したことがあるドキュメントは以下の通りだ。
- コーディングガイドライン
- ブラウザチェックシート
- 要件定義書
- クライアントに納品する運用マニュアル
フロントエンドの環境は目まぐるしく変わっていくので、コーディングガイドラインやブラウザチェックシートは内容が古くなりすぎないよう、更新していく必要があり、最低でも1年に1度は見直しを行っている。
「見直し」というものの、エンジニアMTGの場で全員で内容を議論するのは効率が悪いので、作業分担した後、仕事の一環としてそれぞれで見直しを行い、その上でみんなで議論すべきことだけに絞って話し合うようにしている。
また、要件定義書や運用マニュアルについては、実際に使っていて「こうしたらもっと分かりやすくなるのでは」「こう作ればもっと早く完成する」といったアイデアを持ち寄ってフォーマットの更新を行ったりもしている。
気になることを試す場として活用する
普段の情報収集の中で、気になった技術だったりコーディングの手法をエンジニアMTGの中で試験的に導入してみるということも多くある。
その一つにモブプログラミングというものがある。例えばカルーセルの実装というテーマがあるとすると、ドライバーという役割の人が実際にPCを操作してコードを入力するが、ドライバーは指示を受けてただ入力するだけで、具体的にどう実装するのかはその他の人がその場で議論して、ドライバーに指示をする。
一人で実装する場合の脳内会議とその指示を受けて入力する手を、それぞれ役割分担して人が実際に再現する、というのがイメージとして近いのではないだろうか。このモブプログラミングを行うことで、普段は見えない他人の実装時の考え方や、知らない実装方法を知ることができる。
加えて、ドライバーには「こう書いてほしい」とかなり細かく指示を出すことになるので、考え方だけでなく各人のコードの細かい書き方を見ることができるというのも興味深い。
このモブプログラミングに関しては実際に試してみて、エンジニア全員から「おもしろい！」と好感触だったほか、新人エンジニアがドライバーとなれば良い学習になるのではないかという考えから現場でも導入するようになった。
最後に
このようにエンジニアMTGを単なる情報共有の場として捉えるのではなく、エンジニアチームの課題を考えたり、チームの全員が業務の中で思っていることを話し合うことで、働き方の改善につながっている。また、最後にエンジニアMTGを行うにあたって私が気をつけていることを書いておきたい。
- 活発に議論するために小さめのテーブルを囲む
- よいアイデアを生むためにも不要な緊張感は出さない
- 議題がないときはMTGを無理に開催しないで、仕事する
細かいことかもしれないが、こういった小さな運営方法の工夫も、より効果的な解決策を生むための活発な議論を起こしたり、MTGを定期的に継続して運営しくために必要なことだと思う。せっかくエンジニアで集まって話し合う文化が定着したので、有意義に活用していきたい。
