朝の10分を「学び」に。チーム開発の「慣習」「考え方」を育てる勉強会の立ち上げと運用

✨ 本記事はbitA Tech Blog Advent Calendar 21日目の記事です。

はじめに

私の所属するフロントエンドチームでは、2025年10月から
チーム開発における「慣習」や「考え方」 を身につけることを目的とした
トレーニング型の勉強会を開始しました。
年末に至る現在まで継続しており、運用も軌道に乗ってきています。
本記事では、勉強会立ち上げまでの試行錯誤の過程や、実際に得られた知見についてまとめます。

この記事を読んでほしい人

• 実務経験が浅く、チーム開発にまだ馴染めていないメンバーと一緒に仕事をしているエンジニア
• 特定の技術ではなく、エンジニアとして共通する「土台となる知識」「考え方」をどう伝えるべきかで悩んでいる人
• 勉強会を立ち上げたものの、継続できずに挫折した経験がある人

立ち上げに至るまで

当時のチームでは、メンバー間でスキルセットやチーム開発の経験値にばらつきがあり、慢性的に開発スピードやコード品質に差が出ている状態でした。
技術的な内容そのものは、日々のコードレビューである程度カバーできており、メンバーの学習意欲も高かったため、時間をかければ解消できると考えていました。

一方で、ベースとなる考え方や慣習、いわゆる「お作法」の定着には苦労していました。

• 単調なコミットメッセージが連続し、見ただけではコミットの内容を推測できない
• プルリクエストに記載してほしい前提条件や確認観点、確認方法の記載漏れ
• 開発における各種原則やアンチパターンへの理解不足

例えばNext.jsのようなフレームワークは、公式チュートリアルなどを通して体系的に学ぶことができます。
こうした技術スタックの使い方は、本人の学習意欲次第である程度カバー可能な領域だと考えています。

一方で、考え方や慣習といった内容は、現場での経験を通して少しずつ身につけていく性質のものが多く、体系的に学ぶ機会を作りづらいという課題があります。
私たちのチームでも、コードだけの問題にとどまらない内容について説明することに難しさを感じていました。

直面していた課題

特に次のような課題が顕在化していました。

• エンジニアとしての「慣習」や「考え方」が十分に身についていない
  • チーム開発における前提知識として定着していない
    • コミットの切り方やコミットメッセージに含めるべき情報
    • プルリクエスト作成時に記載してほしい内容
    • 基本的なアンチパターン など
• レビューする側も、明確に言語化できるほど自信を持てていないケースがある

チームのエンジニア全員が、将来別の現場に移ったとしても自走できる状態になることを目標としていましたが、これらの課題は曖昧なまま後回しにされていました。
トレーニングに時間を割きたいという意識はありつつも、日々の業務に押されて着手できていなかったのが実情です。

トレーニングの方法検討と、直面した壁

いくら本人たちが意欲的に学習していたとしても、この状態が続くことは開発効率の低下に直結します。
そのため、チーム内で体系的なトレーニングを実施する必要があると考えました。

検討した方法

案件が比較的落ち着いているタイミングで、いくつかの方法を検討しました。

方法	説明	想定したメリット
ナレッジドキュメントの提供	開発ナレッジや注意点をドキュメントとしてまとめ、完成次第読んでもらう	- 任意のタイミングで提供できる - 網羅的に情報を整理できる - スケジュール調整が不要
週1回、1時間勉強会実施	チーム全員でまとまった学習時間を確保する	- 集中して学習でき、抜け漏れが少ない - 比較的深い内容まで扱える
ペアプログラミング(ペアプロ)の実施	ドライバー（コーディング担当）」と「ナビゲーター（指示・レビュー担当）」を1対1で割り振り、 その場でのレビュー・フィードバックを行う。	- その場でコードの問題点や理解不足な点を指摘でき、直接フィードバックをもらえる - 実践的な学習になりやすい

まずは、一般的に採用されているこれらの方法で解決できないかを検討しました。

直面した課題

結論から言うと、いずれの方法も運用面で課題があり、継続的な実施は難しいと判断しました。

方法	直面した課題
ナレッジドキュメント提供	- メンバーごとの理解度を正確に把握することが難しい - 網羅的な内容のドキュメントを説明なしに渡しても、実践のタイミングが想像しづらい
勉強会実施	- 業務が忙しいタイミングで真っ先にスキップされやすい - 全員の予定調整が難しい - 間隔が空くので内容を忘れる。 - 1つの分野を深く扱えるが、学習したい範囲に及ばない。 - 欠席した場合、内容をフォローしづらい
ペアプログラミング	- 業務が忙しいタイミングで真っ先にスキップされやすい - 欠席者が出ると実施できない - 精神的負担が大きい - 教える側のスキルに依存しやすく、属人化しやすい - 準備負担が高い

特にドキュメント案については、

「難しい業務をしていないのだから、時間があるはずだ」

という、無意識のバイアスに陥っていたことに気づきました。
実際には、各メンバーもそれぞれの業務を抱えており、決して余裕があるわけではありません。

このような状況で、単に「読んでおいてください」とドキュメントを渡すだけでは、受動的なインプットに終わってしまいます。
受動的な学習だけで完結させることには限界があると痛感しました。

---

朝会の10分を有効活用する

これらの反省を踏まえ、チームに求められる勉強会の条件を整理しました。

• 「慣習」や「考え方」といった幅広いテーマを扱えること
• 新たなスケジュール調整が不要であること
• 属人化しにくいこと
• 学んだ内容を実務で実践しやすいこと

一般的な勉強会は 特定の技術を深堀りする には適していますが、私たちのチームではこれらの条件を満たすのは難しい状態でした。

そこで採用したのが、

「朝会の後半5〜10分をトレーニングに充てる」

という方法です。

メリット

• 既に全員が参加している枠を使うため、再調整が不要
• 短時間のため、準備・参加ともに負担が少ない
• 学んだ内容を、その日の業務ですぐに意識・実践しやすい

私たちのチームでは、毎朝30分の朝会を設けていますが、実際には15分程度で終わることがほとんどでした。
この余白時間を活用する形です。
スキップ・欠席による遅れが生じても、リカバリに負担はかかりにくいです。

デメリット

• 実施頻度が高いため、準備負担が発生する
• 深い議論や詳細な説明には向かない

毎日実施する分準備に負担はかかります。
ただし、一度資料を作成すれば繰り返し利用できるため、将来的な育成資産になると考えました。
初期コストは高いものの、長期的な視点で割り切ることにしました。

実際の運用

テーマを洗い出し、Notionで管理しています。
体系的な座学というよりも、現場経験を通じて理解が深まる内容を中心にテーマを選定しています。
必要に応じて、技術的な基礎知識についても扱っています。

実際のトレーニングテーマ管理ページの一部

初期構想

当初は資料を NoLang で動画化し、全員で視聴・共有する形式を検討しました。
動画化による再利用性の高さに魅力を感じていましたが、毎日開催するには準備負担が大幅に高まることから、断念することとなりました。
現在は、持ち寄り資料をもとに口頭で説明する形式に落ち着いています。

初期構想における動画化イメージ

求める水準

1回あたりの勉強会は長くても15分程度のため、深い議論や完全な理解を求めてはいません。
説明した内容を短時間で完全に身につけるということも、現実的ではないことは承知の上です。

この勉強会では 「本人の引き出しを増やすこと」 を目的にしています。
必要な場面で 「そういえば、あの話があったな」 と思い出せるきっかけを作ることを重視しています。

ベースそのものが無い状態から、
「何か注意するポイントがあったから、気にかけてみよう」と意識が変わるだけでも、十分に価値があると考えています。

運用の手応えと今後の改善

開始から約2ヶ月で、次のような変化が見えてきました。

• 議論の活性化

  • チーム全体で、テーマについて意見を交わす機会が増えた
  • 経験者の考え方が共有され、チーム内で可視化された

• 知識のアップデート

  • 曖昧な理解のまま使っていた概念を整理できた
  • 経験者にとっても、意識できていなかった点を整理するなど新たな気づきがあった

• 業務の質の向上

  • コミットやプルリクエストの内容が整理され、レビューしやすくなった
    • 例:「レビュー対応」「修正」のような単調なコミットが並ぶことが激減
  • レビューにかかる時間が体感的に短縮された
    • 定量的な数値で結果を比較できることが望ましいですが、2ヶ月間のためまだ集計しきれていません。メンバーからの声として捉えてください。

特に、経験の浅いメンバーだけでなく、チーム全体の成長意欲が高まった点は想定外の成果でした。

もちろん、チームメンバー全員が非常に協力的だったことが一因なのは言うまでもありません。

今後に向けて

現在は、「どこまで到達すれば自走できると言えるのか」というゴール設定に課題を感じています。

• 到達レベルの具体的な定義、ペルソナ
• 定着度合いを定量的に測るための指標
• ソフトスキル寄りのテーマにおける目標・到達レベルの設定

これらを明確にし、より再現性の高い仕組みへと改善を進めている段階です。

おわりに

技術はキャッチアップしやすい一方で、
チーム開発における「慣習」や「考え方」は、意識しなければ共有されにくいものです。

本記事で紹介した取り組みが、
そうした目に見えにくい土台を育てるための一例として、
チーム教育やオンボーディングを考えるきっかけになれば幸いです。