常に新しい情報をキャッチアップし続け、スキルの継続的なアップデートを求められるのがITエンジニアという仕事ですよね。そのため、社内勉強会を実施する会社も少なくないと思います。その一方、「開催したいけどハードルが高い」「過去開催したが、実施負荷が高い」とお悩みの方もいらっしゃるかもしれません。
昨年12月に、所属する課でハッカソン形式の社内勉強会を開催し、発起人として企画・運営を担当しました。本記事では、その時の経験をもとに企画・運営者視点で「社内勉強会の進め方とポイント」をまとめました。
前半では、勉強会を実施する際の基本的な流れを整理しました。後半では、12月に企画・主催したハッカソン勉強会を具体例としてご紹介します。これから社内勉強会を開催してみようというITエンジニアの皆さんのお役に立ちましたら幸いです。
後編では、前編でご紹介しました社内勉強会の進め方をポイント整理に沿う形で解説していきます。
それでは、始めます。
実施概要
【STEP1】企画
・目的＋実施に伴う効果（終了後のイメージ）
ハッカソン勉強会を実施した背景には、若手ITエンジニアの開発力や対応力を一層高めたいという私たち発起人側の思いがありました。
参加メンバーを若手に絞ることで、前編でご紹介した社内勉強会のメリットのうち、「技術向上」「知識共有」「モチベーション向上」を目的に設定しました。
0から1の開発を経験することで、企画、デザイン、開発、インフラ、リリースなど、Webサービスを提供するための知識を網羅的に学べます。また、現場での開発では、上司やマネージャーによってプロジェクトの進め方が固定化されたり、プロダクト依存で試したい技術に取組めないケースは多いと思います。
ですから、マネージャーを含めず若手だけで実施することで、普段の業務の中で各々が感じている「この技術を利用してみたい」「この進め方を試してみたい」といった声を取り入れました。
今回のハッカソン勉強会では、流行っている技術や手法の有用性を確認・検討したいという思いもあったので、マネージメント部分も含めて全て自分たちで決めていきました。技術選定に加え、進捗管理まで自分たちだけでできたのは大きかったと思います。
・参加対象
私たちが所属しているアプリケーション開発課のメンバー9名で実施しました。普段はフロントエンドをメインとしているメンバーで実施したため、インフラ、バックエンド領域の知識や経験が少なく、技術のキャッチアップが必要でした（バックエンドとインフラ構築には苦戦しました）。
※その点、Ｊストリームでは幅広い職種のITエンジニアがいるので、バックエンドやインフラ領域のITエンジニアに協力を仰いだり、知恵を借りたりできました。協力してくれた皆さん、ありがとうございました。
・制作物
今回は「360度評価ツール」を作りました(図1、2)。実際に何を作るかを考えるミーティングで「身の回りの問題を解決するサービスを作ろう」という声が挙がったのがきっかけでした。議論を深めていき、会社の評価制度のあり方をもっと改善できるのではないかという観点から「360度評価ツール」に決まりました。
360度評価とは、社員の評価を上司や人事だけで行うだけではなく、周りのメンバー、部下、上司が評価し合うことです。360度評価を行うことで、企業は全従業員の性質や執務態度を客観的かつ公正な視点から把握できます。他社が作った既存のツールを使うのではなく、自ら360度評価ツールを作ることで、会社のルールに合わせカスタマイズができ、素早く対応ができるようになります。
・場所
バーチャルオフィスを使い、完全オンラインで実施しました。その時の様子をキャプチャ掲載します（図3）。
・実施期間
2022年9月～12月
2022年9月：企画立案〜インセプションデッキ作成
2022年9月〜10月初旬：要件定義、スケジュール決め、タスク分解
2022年10月中旬〜11月下旬：フロント、バックと担当すすメンバーに分けて環境構築や技術調査、学習
2022年12月初旬：実装当日までの下準備（DockerやAWS環境の用意、SwaggerによるAPI設計、Figmaでのデザイン作成など）
2022年12月下旬：丸1日実装期間とり、フロントエンド、バックエンドに分かれてペアプロにて開発
丸1日業務時間を利用して開発しましたが、今回は業務時間内に実施することで上長のOKもとれました。
・実施に関するコスト
外部コストは大きく分ければ、学習用の教材費用とサーバ費用です。学習費用は、各メンバーがすでに持っている技術書籍、公式のリファレンスの読み込みをメインにしたため、学習動画と書籍の購入金額を合算しても数万円程度でした。サーバはAWSを利用したので、最大で月額10万円弱で、計数十万のサーバ利用料が発生しました。
内部コストについては、上記「実施期間」で具体的な動きを例にあげました。自社での工数想定の参考にしてください。
【STEP2】社内承認
業務時間を社内勉強会に使えるかは、正直、会社により判断がわかれます。Ｊストリームでは、ふたつ返事で承認されました。これは、ありがたかったです。上司に相談したところ「社内勉強会ぜひやろうよ！」と、とても前向きに言ってくれた上に、「何か必要なツールがあれば、なんでも相談して」とも言ってくれました（なんと、AWSのアカウント発行準備も自ら買って出てくれました！ 大変助かりました）。上司のOKが出ると心強いものです。
【STEP 3＋4】広報＋事前準備
課内での開催でしたので、最初の告知は課会で行いました。期間中は毎週定例ミーティングを行い進捗について確認しました。定例のミーティングとは別で学んだことを共有する場も適宜設けました。企画趣旨、概要、インセプションデッキやプロダクトバックログ、要件定義書、技術選定、勉強会、実際に動作するアプリケーションの開発までをゼロから一貫して行っています。
また、ハッカソン形式で社内勉強会を実施するには、サービスを作るために各分野の土台となる知識が最低限必要です。実施日までに、参加者メンバー全員が必ず何かしらのアウトプットを提出することを遵守しました。
タスクとして技術選定や調査などが割り振られた場合であっても、自分なりに調べて、結果をドキュメントにまとめて、参加メンバー全員に共有または発表するまでを1セットにしました。参加者全員が、何かしらの形で必ずチームに貢献する形を作り出すことで、参加者間の認識を合わせると共に、参加感を高めることを狙いました。
また、工程ごとの承認者を全員とすることで、全員の認識、目線があった状態で次に進み、誰かを置いて先に進まないような工夫も取り入れました。これにより、参加感を高め、徐々に盛り上がる手応えを感じました。
【STEP 5】実施
制作物概要はご説明しましたので、ここでは、技術面について、もう少し詳しく解説します。
・技術的なポイント
今回はあくまで勉強会で技術的な制約なかったため、話題になっていたり、流行っている技術や手法、参加メンバーが使ってみたい技術などをできる限り使ってみることを意識しました。ただ、そのなかでも候補を洗い出し、各技術がどういうメリット・デメリットがあるのかを吟味して選びました。
例えば、Go言語であれば、シンプルかつ静的型付け言語なので、TypeScriptで慣れているフロントエンドエンジニアにも、とっつきやすいということで採用しました。
・技術スタックやツール
技術スタックとしては以下の通りです。
バックエンド：Go言語、Gin
フロントエンド：TypeScript、React18、MUI
インフラバックエンド：AWS ECS、Fargate
インフラフロントエンド：AWS Amplify、Vite
CI/CD：GitHub Action、AWS Pipeline
IaC：Cloud Formation
メール配信：AWS SES
デザインツール：Figma
ミドルウェア：MySQL、Redis
開発環境：Docker
開発手法は、アジャイル開発をベースにプロダクトバックログの作成を実施、コーディングする際はペアプログラミングで実施しました。
・開発フロー
開発フローは、APIのスキーマを定義し、定義をもとにバックエンドやフロントエンドで分かれて開発を進めるスキーマ駆動開発を採用しました。
手順は以下です。
1. バックエンド側が必要なAPIの洗い出しとインターフェース（OpenAPIの定義）の叩きを作成
2. フロントエンド側は作成したインターフェースをレビュー
3. レビューが通れば、マージし、モックの生成
4. フロントエンド側はSwaggerおよびモックもとに実装、バックエンド側はSwaggerをもとに実装
モックの作成は、stoplight/prismを利用し、OpenAPIの定義より作成しました。そうすることで、モックの作成工数を削減しました。
・実施に際しての役割分担
バックログのチケットベースでタスクを分解し、役割はそのチケットを元にそれぞれが興味があるもの、やりたいタスクを挙手制で決めました。
・主なタスク
– 画面仕様作成
– API設計
– CSS学習
– RESTful APIの学習
– React学習
– Go学習
– デプロイ環境準備
– Swagger学習
– DB管理ツール調査
– DB設計学習
– 認証認可設計
– インフラ設計
– Figma学習
報告書を掲載するよりも、生の声をお届けする方が参考になるかなと思いますので、項目ごとに記載します。
・実施前の反応
最初に、課内でのハッカソン勉強会の趣旨などを説明したタイミングでは、参加対象となる課のメンバーはシーンとしていて、実は「自分だけ盛り上がっているのかも」と少し不安でした（笑）。ただ、実際の作業になるとみんな一生懸命取り組み、よいものを作ろうと楽しんでくれました。
・実施後の反応（一部抜粋）
実施後のアンケートでは以下の意見が挙がりました。
・1からものを設計して作るのは、新鮮で良かった
・普段一緒にやらないメンバーと開発ができたのが良かった
・普段触らない技術を触ることできたので、視野が広がった
・自分の実プロジェクトでも使えそうな技術があったので今後検討してみたい
・ちょっとしたTipsみたいなものを学べたため、自身のプロジェクトでも取り入れたい
・企画・運営者としての感想
今回の社内勉強会でも最初にインセプションデッキを作り、みんなが向かう方向性（ゴール）を確認するところから始めました。その甲斐あって無事遂行することができたと思っています。
はじめての取組みで不安はあったものの、まず社内勉強会が途中で消滅することなく、アプリケーションとして実際に動くものを最後まで作れたことで大きな達成感を感じることができました。その過程でWebサービスの仕組みであったり、チーム開発の大変さ、新しい技術の有能さであったり、学んだことはたくさんありました。
加えて、企画段階では考えていませんでしたが、普段関わることのないメンバーと関わりが持てたことも良かったと思っています。同じ課であってもチームが異なれば、普段どんな仕事の進め方をしていて、どんな趣味嗜好があるのかなどを知らないメンバーもいました。社内勉強会を通して「この人はこういうことが得意なんだな」とか「この人の話し方良いな」など、メンバーの知らなかった一面などを知る機会が持てたことは思わぬ副産物でした。
結果、本業務においても「この分野は〇〇さんが詳しかったから聞いてみよう」と、これまではチーム内だけで完結していたようなことも、チームを超えて知見の共有を図りやすくなり、チーム間の交流が活性化しました。
上長からもいい取り組みだと評価してもらえたのも嬉しい成果でした。また、その後、今回の社内勉強会で取入れたペアプロを実業務にも取入れようと動いています。
運営上配慮した点
・配慮した点
【STEP 4】事前準備での記述した通り、特定の人だけが決め、進めるのではなく、全員で考え、意見を出し、必要なものを揃え、創り上げていくフローにしたことです。
・運営上大変だったこと、難しかったこと
業務の兼ね合いで、なかなか時間が取れないことや、思ったように進捗しないことはありました。普段業務で担当している領域ではなく、技術的に各メンバーが経験したことがないタスクが多かったことが要因だと考えています。
また、本業務との調整も大変でした。開催までには、技術の調査や勉強、サービスの企画、要件定義と多くの準備が必要ですが、メンバーはそれぞれが本業務を持っているため、リソース調整は難航しました。
社内勉強会よりも本業務の方が優先のため、本業務のリリース前や不具合が発生した場合にはどうしてもそちらにリソースを割かなければいけないメンバーも出てきます。また、各々違うチームで働いているので、忙しいタイミングがバラバラということもありました。
ここについては、タスクを割り振った後も進捗次第では他メンバーでサポートすることで、なんとか解決ができました。これは、Ｊストリームで、普段の業務においても、声をあげれば助け合える環境が整っていたことが反映された結果だと思います。
・つまずいたポイント
各メンバーの受け持ったタスクによっては難易度や量の大小が発生し、特定のメンバーにタスクが集中してしまうことがありました。全員が何らかのタスクを持っているとはいえ、挙手制でタスクを自分から拾いに行く形を採ったことで、やりたいことが多いメンバーは、複数のタスクを同時に抱える事態も発生しました。
今回はリーダーのような役割を置いていませんでしたが、各メンバーのタスクを管理するPMのような役割は配置するべきだったかなと感じています。
まとめ：今後の抱負、計画、その他チャレンジしたいこと
技術・学びが好き！でないと難しいと感じました。同じ志を持った人を見つけて実施するとやりやすいと思います。その点では、私は、課内に同じ志を持つ仲間がいてくれてとても幸運でした。
また、前例や知見がないからと途中で諦めないことも大事です。若手だからこそ、失敗上等の覚悟でやってみて、次に活かすことが大切だと思います。スキルが足りないからとか、前例がないからとか、そういう文化だからとかやらない理由はいくらでも挙げられますが、それらは後から付いてくるもので、作っていくものだと個人的には思っています。
今後は新しいサービス開発などをやりたいと思っています。そのためにも新しい技術などを継続して学んでいきたいです。
社内勉強会については、もっと気軽に誰でも開催OKな雰囲気を作っていきたいと思っています。現時点では、勉強会を開催するとなると、「自分はまだまだ技術に浅いし、マサカリが飛んでくるんじゃないか」とか、「発表するほどの資料を準備する時間がない」など、開催するまでのハードルの高さを感じています。技術的なことでなくても良いので、発表して、リスペクトして、気軽に参加者で議論する、そんな雰囲気が作れたらと思っています。
※記載内容は、執筆当時のものです。その後、状況が変化していることがあります。
