はじめに
社内向けに Git の勉強会を開催しました。
アンケートの結果も良好で、全体として満足のいく勉強会になりました。
本記事では、企画中に考えていたこと、資料の作成方法、開催後に見えた改善点などを振り返ります。
勉強会企画までの流れと全体構成の決定
弊社のバージョン管理は、既存プロダクトでは SVN、新規プロダクトでは Git を使用する運用となっています。
Git の知識が十分に浸透しているとは言えず、「なんとなく使っている」人が多い状態でした。
一方で、今後 CI/CD や AI 活用の観点から GitHub を使いたい、という声も一部で上がり始めています。
このままでは Git 経験値の差がさらに広がってしまうと感じました。
- Git を組織全体に浸透させ、使える人を増やしたい
- Git の基本から、GitHub を使うと何ができるのかまでを一通り体験できる場を作りたい
と考え、勉強会を企画することにしました。
まずは GPT にざっくり相談してみます。
なるほど、「1日目で基礎と個人運用、2日目でチーム運用、3日目で応用」という流れは良さそうです。
2日目は、チーム開発風に何かを作る演習が面白そうです。
社内でGitbucket使っていますが、Gitbucketの機能を活用してるチームをあんまり見ないのでそこを中心にできると業務に活かしやすいかもしれません。
PRやIssueを全員が体験できるような演習にして、最終的に成果物を作るところまでいければ達成感ありそうな感じがします。
3日目は、GitHubでCI/CDを実際に体験できるのがいい気がします。
ビルド・デプロイできる題材を使い、CI/CDの便利さを実感してもらえたら理想です。
自動テストもまだ馴染みが薄いので、触れられたら面白そうです。
さらに、普段使っているバックログ管理ツールやチャットツールとの連携の需要もありそうなので、ここで取り入れたいなと思います。
🟧 一番の悩みは1日目
1日目の内容決めは悩みました。
参加者の中には、
- 業務である程度 Git を使っている人
- 使ったことがない人
が混在します。
「コミットできました！プッシュできました！」だけだと、既に使っている人からすると面白みがなく、途中で離脱されそうです。
かといって基礎を飛ばすと、使っていない人を置いていくことになります。
Git に触ったことがない人にも分かるよう、基本は省略したくない。
そのうえで、何かアクセントになる面白さを入れられないかと考えました。
そこで再び GPT に相談します。
実務で起こりえるトラブルシューティング的な内容は食いつきがいいかもしれないと思いました。
「これ困ったことある！」と思ってもらえる要素を入れるのは良さそうです。
この方向性をベースに、1日目の詳細なシナリオを考え始めました。
Day1 の構成を考える
構成は大きく以下のイメージです。
- はじめ
- 本編（演習を通して基本操作を学ぶ）
- トラブルシューティング（実務で起こりがちなケースを一問一答形式で）
- おわり
🟧 はじめについて
導入部分は、長くしすぎないことを意識しました。飽きてしまうので。
検討したが入れなかった内容
🔸 Gitってなんで必要？バージョン管理がどうして必要か
すでにバージョン管理システムを使っている人が多く、疑問に思わないだろうと判断しました。
🔸 SVN vs Git
自分が SVN を使った経験がなく、聞きかじりで語るのは良くない話題な気がしたのでやめました。
🔸 Git の歴史 Linux カーネル開発で生まれた話
へ～ってなるとは思いますが、実務の課題解決には直結しないので割愛しました。
🔸 SourceTree は内部で独自の Git を持っている話
ややこしくなりそうだったため諦めました。
Day2以降で素の Git を扱う際に説明することにします。
結果、残した内容
- 勉強会開催の経緯
- Git とは何か
- Git / GitHub / Sourcetree などの違い
Git の説明は最低限に留め、演習を通して体感してもらう方針にしました。
Git と GitHub の違いはつまずきやすいポイントなので、念入りに説明しました。
🟧 本編について
演習を中心に進める構成にしたいと考えました。
一般的な Git 勉強の流れを知るために、『サルでもわかる Git 入門』を読みました。
分かりやすい本だったので、演習の大枠はこちらの本を参考にさせていただいています。
特に「Git はセーブポイントを作るツール」という言い回しが気に入り、使わせてもらいました。
こちらの本では SourceTree を使った演習が行われています。
弊社でも SourceTree 利用者が多いため、演習は SourceTree のみで完結させることにしました。
参加者の多くが普段 GUI で Git を操作していることから、今回はコマンド操作は扱わないことにします。
Gitをしっかり学ぶならコマンドの理解は必要不可欠ですが、弊社の状況で考えるとかえってノイズになると判断しました。
演習の題材はファイルをメモ帳で編集してもらうシンプルなものです。
Git 操作に集中してもらうため、演習で使うファイルはテキストファイルとし、プログラムは扱わないことにしました。
「セーブポイント」のイメージに合わせ、RPG の装備欄っぽいテキストにして、少しはテンションが上がるようにしました。
【武器】勇者の剣
【頭】ニットの帽子
【体】あったかいコート
【足】あったかいブーツ
他の演習の題材案として、後述のReveal.jsを使ったhtmlのスライド作成も考えましたが、html、cssの研修になりそうだったのでやめました。
ダサいスライドをかっこよくしよう！みたいなのも楽しいかなと思っていました。
そんなことを考えながら、取り扱いたい内容を洗い出していましたが、表面的な操作が中心で人によっては物足りなく感じそうです。
そこで、Git の仕組みに少し踏み込むような要素も追加します。
🟧 追加した要素
🔸 ブランチの正体
枝や分岐というイメージが強いですが、実体は「コミットを指すポインタ」であること。
これを知ると、移動・追加・削除の心理的ハードルが下がる気がしたので追加しました。
実際「ブランチはコミットのまとまり」ととらえていた人が多かったみたいなので、入れてよかったです。
🔸 リモートリポジトリをローカルに作る
業務では、あらかじめ作成されたリポジトリをクローンして使い始めることが多く、リポジトリを自分で作成する機会はあまりありません。
そのため「リモートリポジトリは特別なもの」と捉えられがちです。
実はローカルリポジトリの作成と同じコマンドで作れるし、自分の端末内にも作れる、というのは新鮮味がありそうだと思いました。
🔸 リモートブランチとリモートリポジトリ上のブランチの違い
リモートブランチ（追跡ブランチ）はローカルリポジトリのブランチだということ。
ローカルとリモートのつなぎ目がどうなっているのか理解すると、Git の怖さが和らぐ気がしたので追加しました。
逆に入れなかった内容もあります。
🟧 入れなかった要素
🔸 リセットの3つのモード
入れたかったんですが、リセットの説明を勉強会の序盤で入れていたので、あまり情報が多いとノイズになるかと思い外しました。
リセット自体も本来は「ブランチの位置を変える」ものですが、説明では実務でよく使われる操作の「戻す」にフォーカスしています。
🔸 ファストフォワードマージ
入れたかったのですが時間がありませんでした、Day2のブランチ・マージ戦略の話の時に入れようと思います。
演習中はファストフォワードマージが発生しないような履歴にしていました。
🔸 .gitフォルダの中でデータがどのように保持されているか
私の理解が浅く、うまく説明できる自信がなかったのと、演習でコマンドをいっぱい触ってもらうことになりそうなので今回は割愛することにしました。
補足資料には入れようと思います。
リポジトリはコミットの分スナップショットを保存してるはずなのに、なぜ.gitはそこまで肥大化しないの？とか、
ヘッドって何？デタッチってどういう状況なの？とか、
内部構造が分かるとそういうことか～！となるものが結構あります。
株式会社MIXIが公開しているGit研修資料があり、こちらの内部構造編で丁寧に解説されています。
🔸 リベース、スカッシュ、スタッシュ
入れたかったですが時間がありませんでした。
補足資料、Day2の内容に組み込もうと思います。
🔸 ワークツリーを複数作る、サブモジュール
ややこしいので今やるべきではないと判断しました。
複数ワークツリーはバイブコーディングするとき便利という話があるのでDay3で入れるかもしれません。
私も普段つかってないので理解を深めたいです。
🟧 トラブルシューティングについて
周囲の人や自分の経験から、「実務でこうなると困るよね」という内容を集め、一問一答的な形式でテンポよく進める構成にしました。
そんな感じで章ごとに盛り込みたい内容を洗い出していきます。
資料作成
内容が固まってきたので、スライドの作成方法について考え始めました。
何らかのAIを使えるツールであることは確定で、figmaとかcanvaとかfeloとかがいいのかなと思っていました。
いろいろとスライド生成AIを調べているときにReveal.jsに出会います。
Reveal.jsは、HTMLでスライドが作れるJavaScriptのライブラリです。
最小で始める場合、環境構築不要でHTMLファイル一つあればスライドが作れます。
試しに...
- メモ帳を開く
- 下のコードをコピぺ
- 名前を付けて保存する、ファイル名は
スライド.html、エンコードはUTF-8とする - 作成したhtmlファイルをブラウザで開くとスライドになっている
<!doctype html>
<html lang="ja">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<title>Reveal.js Minimal</title>
<!-- Reveal.js -->
<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/reveal.js@5/dist/reveal.css"/>
</head>
<body>
<!-- ここにスライド -->
<div class="reveal">
<div class="slides">
<section>
<p>Hello! Reveal.js!</p>
</section>
<section>
<p>最小構成の</p>
<p>スライド</p>
</section>
</div>
</div>
<!-- Reveal.js -->
<script src="https://cdn.jsdelivr.net/npm/reveal.js@5/dist/reveal.js"></script>
<script>
Reveal.initialize({
hash: true,
});
</script>
</body>
</html>
プラグインを使うとスピーカーノートや数式の表示など便利な機能も追加できます。
GUIでスライド作るよりもコードで作ったほうが精神的に楽だったのと、
普段使いしているAIツールでスライド作成に特化したものがなく、htmlを書かせるほうが普段のツールを活用しやすいという理由から、スライドはReveal.jsで作ることにします。
早速セットアップをします。
Reveal.js本体のコードもカスタマイズしたかったのでフルセットアップの手順で環境を作ります。
day1、day2、day3全資料を共通で管理したかったのでそれ用にslidesディレクトリを作成します。
.
├─node_modules
├─css ┓
├─dist ┃ Reveal.jsのコアファイル
├─js ┃
├─plugin ┛
└─slides スライドはこのフォルダ以下に格納
├─assets
├─common
│ ├─custom.css 共通で使うクラスなど
│ ├─reveal-init.js プラグインの読み込み・Reveal.js初期化など
│ └─components 各スライドでよく使う部品をカスタム要素に
│ section-title.js
│ slide-title.js
│ tsuduku-mark.js
│ video-link.js
├─day1 1日目で使うフォルダ
│ ├─index.html
│ ├─assets
│ │ ├─files
│ │ ├─images
│ │ └─videos
│ └─handouts
├─day2
└─day3
スライドに読み込ませる共通のjsとcssを作って各スライドhtmlの記載を簡略化しました。
カスタムテーマの作成までやりたかったですが優先度は低かったので、今回は用意されているテーマを使用しました。
使いやすくするようにReveal.jsの中身を一部いじります。
以下の改修を行いました。
- 左下にコピーライトを表示
ページの表示と同じ扱いでスライド外に表示し、印刷時も表示されるようにする - すべてのimg、videoが遅延ロードになるようにする
data-src属性にパスを書こうとしたとき補完が出ずに不便だったため - 印刷時に非表示にするクラスを追加
- スピーカーノートのプラグインでaside.noteがノート扱いになるが、noteクラスなしでもノートになるように
下書きをもとにスライドを作成します。
Reveal.jsはsectionタグの入れ子でスライドのグループ分けができるのでそれで章を表現していきます。
各章は、最初に扉スライド、最後には章のまとめを入れるルールとし、モジュール分けされたような構成を目指しました
スライドの組み立て中には以下のことを意識しました。
- 演習の指示は常に同じデザインのカードにまとめ、参加者の操作が必要な部分をわかりやすくした
- 色を無駄に増やさない
強調にはメインカラーを使い、メインカラー以外の色を使う場合は意味を持たせる - 1スライド1メッセージを意識し余白を埋めようとしない
各章の内容は下書きの通りに進めていましたが、言い回しや伝え方、デザインが思いつかないときは、feloやgeminiにスライドを作らせて参考にしました。
スライド作成AIをあまり使ったことがなく、今までで一番使いこみましたが、雑な下書きからでも言い回しを整えて、いい感じのスタイルを用意してくれるので、構成を決めるのにお世話になりました。
今回は全編を一気に作らせるような使い方はしませんでしたが、スライドの枚数が多かったり、他のスライドと共通化したいルールが多かったりしても、対応できたりするんでしょうか？
どこまでできるか今度試してみたいと思います。
スライドはVScodeで書いていました。
普段コード生成で使っているAIツール（copilotやamazon qなど）をそのまま使えるのでやっぱり便利でした。
資料内で使う図は主にdrawioを使って作成しました。
拡張機能を使ってVScode内で編集ができます。
.drawio.pngで画像として表示しながら、drawioで編集もできるのも便利です。
ただ、.drawio.pngにしたときの画像が荒かったので拡大率の調整をしたり、タグ毎・レイヤー毎・ページ毎のエクスポートができなかったりとちょっと不便なこともありました。
AIに.drawioファイルを触らせることもできるらしいのでそれを習得できればもっと捗りそうです。
そんなこんなで資料を作りました。
開催後の振り返り
継続する点
- Reveal.js は今後も使用していきたい
- 演習の頻度、難易度はちょうど良かった
- 利用ツールを SourceTree のみに絞ったことで、画面共有がしやすく進行もスムーズだった
- Zoom のリアクション利用の活用
多くの方が積極的に参加してくれた
改善点
- 各演習スライドに動画を添付したかったが、時間が足りず実現できなかった。
勉強会中に SourceTree が重くなり、待ち時間が発生する場面があったため、こうしたケースに備えて事前に動画を用意しておけばよかった。 - トラブルシューティング部分の説明が不十分で、進行がぐだついてしまった。
こちらも資料作成が間に合わなかったことが原因。 - 「途中参加 OK」と告知していたが、途中参加者への配慮が足りなかった。
途中から演習に参加するのが難しい構成だったにもかかわらず、「気軽に参加してほしい」という思いだけで安易に告知してしまった。
告知した以上は、途中参加者向けの準備や、当日のアナウンスをもっと行うべきだった。 - やりたいこと・入れたいことを詰め込みすぎた結果、準備に時間がかかってしまった。もっと上手に AI を使いたかった。
- 多くの参加者がリアクションで参加してくれた一方で、誰がリアクションしてくれているのかを把握しきれなくなってしまった。
Zoom のリアクションは録画に残らないのようで、後から録画を見返した際に当時の反応や状況が分かりにくくなってしまった。- Mentimeterなどの、発表中に参加者と交流するためのツールがあることを後から知った。
これらを活用して参加者とのリアルタイムなやり取りを増やしつつ、終了後も残る形にできると良さそう。
- Mentimeterなどの、発表中に参加者と交流するためのツールがあることを後から知った。
- スクリーンが自分から見えにくく、演習の進行が大変だった。
マイクの位置もよくなかったので、スクリーンを見ながら話している時の声が小さくなってしまった。 - フィラーが多かった。
Git勉強会の資料作成用リポジトリなのに、人に見せられる状態になっていない。
おわりに
想定以上の人数に参加していただき、アンケート結果も満足のいくものとなりました。
一方で、自分の勉強不足・準備不足な部分も多く浮き彫りになりました。
今回得られたノウハウを活かしつつ、次回以降の開催につなげていきたいと考えています。
反省点・改善点に加え、アンケートでいただいた意見も参考にしながら、次回はより良い勉強会にできるよう取り組んでいきます。