こんにちは。ソフトウェアエンジニアのたかにぃです。
みなさんは所属しているコミュニティなどで、交流会や勉強会を開催したことや参加したことはありますか？
日々の業務に追われる中で、自身やチームの強化であったり、技術の深化の時間を如何に確保するかは重要なテーマかと思います。
勉強会などはそういった試みの1つだと思いますが、私が所属しているプロジェクトでも似たような試みとして「バックエンド相談会」というものを定期開催しています。
今回はその内容について紹介させていただければと思います。
「バックエンド相談会」ってどんなものか？
バックエンドエンジニアリングの内容を中心に「今困っていること」「相談したいこと」「プロジェクトに取り入れたい技術」「面白い記事」といったことをざっくばらんに相談・共有しあう会になります。
開催に至った経緯
きっかけとしては、プロジェクトメンバーからの「勉強会的なものを開催してみたい」という要望が発端になります。
そのまま「勉強会」を開催しても良かったのですが、同時にプロジェクトが持つ課題も解決していきたいと考えました。
所属するプロジェクトの課題としては以下のようなものがあります。
- 参画して日の浅いエンジニアが多く、コード品質にばらつきが生まれレビューコストが増加していた
- 各メンバーが持つ知見を活かしきれていなかった
- 良いコードを書こうという意識に温度差があった（ように感じていた）
- 目先のタスクに忙殺されて、新しい技術や試みを取り入れる機会が減っていた
そこで、勉強会の開催を提案してくれたメンバーに上記の課題感を伝え、目的であったり、プロジェクトとして達成したい姿をすり合わせた上で、具体的な運営方針に落とし込んでもらいました。
ある程度まとまったところで、プロダクトオーナーに正式に工数を確保したい旨を伝えて了承をいただき開催の運びとなった、という感じです。
なぜ「勉強会」じゃなくて「相談会」にしたのか？
主な理由としては、肩肘張らずにラフに参加できる場にしたかったからです。
私のプロジェクトの状況として、経験の浅いエンジニアが多いということもあり、「勉強会」と銘打ってしまうと、参加にあたって各自が必死で技術情報を一から仕入れ、それを紹介するだけの場になってしまうのではないか？ということを危惧しました。
そうはならないかもしれませんし、それはそれで大事なことなのですが、そのために本来の業務が疎かになってしまっては本末転倒ですし、参加のハードルも上がってしまうと思います。
また会を開催する目的として、新しい技術のキャッチアップも当然ありますが、日々の業務で詰まったポイントなどをメンバーの知見を持ち寄って解決し、それを通じてチーム全体の開発力の底上げに繋げたいという狙いもありました。
そうなってくると「勉強会」ではなく「相談会」の方が相応しいよね、ということで相談会と銘打っております。
なんでバックエンドに限定したのか？
実はここに深い意図があるわけではないのですが、スコープを程よく絞りたかったのと、議論の活性化を狙ってのものになります。
フロントもバックエンドも（それ以外も）となると話すテーマや内容が幅広く、議論が拡散してしまい結論まで時間がかかってしまうかもしれない、と考えました。
ある程度スコープを絞った方が議論される内容を参加者が想像しやすく、より深く活発な検討が行われやすいかと思います。
また、相談会の形として、一方的に誰かの考えを皆に伝えるのではなく、各自の考えをアウトプットし合う場にしたいとも考えていました。
参加人数が増えすぎるとそれが難しくなってしまうことから、スコープに伴い参加人数的にも程よい規模に納めたかったという狙いがあります。
どんな感じで進めてるか？
開催周期：２週に１回
開催時間：基本１時間。状況によって短縮、延長あり
参加者：主にバックエンド側の比重多めで開発を担当するエンジニア（だけどそうじゃない人も参加可）
議題についてはスプレッドシートで管理しています。参加者が事前に話したいことや相談したいことを概要レベルで記載しておき、相談会の中でそれらを取り上げて行く形で進めています。
実際に相談会の中で話し合った内容も同じスプレッドシートに蓄積していくので、参加できなかった人も後からどういった内容が話されたかを共有できるようになっています。
ファシリテーターは輪番制としています。進め方は基本的に自由ですが、主な流れとしては冒頭に前回やった内容についてさらっと触れた後に、気になる議題をピックアップしていくようなスタイルが多いです。
成果と課題
まずは得られた成果から紹介します。
実装方針の共通認識
今まではメンバーの熟練度によってまちまちだった部分も多かったのですが、相談会で設計方針について議論をする中で、どういった観点があり、なぜこういった設計/実装になっているか？といった思想的な部分について意見を出し合うことで共通の理解が深まりました。
併せて、既存実装の問題点なども洗い出され、今後の改善タスクとして計画に載せるといった動きも進めることができています。
運用改善
会で出た意見が採用され、運用改善に繋がっています。
一例となりますが、私の所属するプロジェクトでは、メンバー同士でレビューを行っています。
レビューされるだけでなく、他メンバーのコードを読む機会にもなり、レビュー者視点での経験も積むことができるため、よい取り組みだと思っているのですが、その際にレビューの知見が当人同士で閉じてしまい、何度も同じ指摘をしたことがある。といった悩みを持っているメンバーが意外に多いということがわかりました。
こちらを解決するためにレビュー指摘自体を知見として蓄積していき、開発スプリントごとに振り返るといった試みを試験的に開始しています。
メンバーの相互理解
（特に若手メンバーの）実装において陥りがちなミスやハマりポイントなどをメンバー間で共有することができました。
また相談会を通じてそれぞれがどういった部分を気にしているか？などがわかってきたため普段の業務においても相談しやすい空気が醸成されてきていると感じます。
次に課題です。
開催頻度
どんなに忙しい時でも開催を！と言いたいところなのですが、繁忙期はどうしても議題の集まりが悪かったり、参加が難しいメンバーがいたりと、難しい部分があります。
本来の業務に影響がでない形での無理のない運営体制については今後も課題になると考えています。
発言頻度
人数を少なめにしたことで発言自体は活発になっていますが、やはり経験が長めのメンバーの発言が多くなってしまう傾向があります。
それ自体が問題というわけではないですが、自分の考えや実装における思想をアウトプットする場は重要だと考えているため、こちらもうまく調整を図って行きたいと思います。
まとめ
最後まで読んでいただきありがとうございます！
今回は私のプロジェクトで定期開催されているバックエンド相談会について紹介させていただきました。
勉強会や相談会など色々と形態はあるかと思いますが、それぞれの組織やチームのフェーズや状況によって最適な形は異なると思います。
より良いやり方を模索し、自身とチームや組織の開発力向上に繋げていきたいものですね。
本文章がそういった活動の参考になれば幸いです。
＼\『真のユーザーファーストでマーケットを創造する』仲間を募集中です!! /／
