エンジニア以外がGITで業務効率をアップさせる方法

とある団体からセミナーの依頼を受けました。 連絡があったのはかつてからの知り合いで、昔から仲良くしていた友人だったので、 中身をあまり聞かずに、「イイヨ」とだけ返答しておいたんですが、 よくよく聞いてみると「GITのセミナーをしてほしい」との事でした。 エンジニア育成か何かなのか？と考えたが、その団体の活動は、ビジネスコミュニティ系の団体らしいので、それは考えにくい。 どうやら、「様々な職種で、GITを高知いて業務効率化を行うセミナーをしてもらいたい」とのことでした。 オーマイガ！かなりのムチャブリに後ほど気がついたんですが、もはや時すでにお寿司。 まあ、セミナー講師は楽しい仕事なので、やっぱやめとは言わずに、楽しんで受け入れる事にしようと考えた。

GIT講習過去事例

実は昨年、とある某（日本一）有名な国立大学の特定部門の職員さんのホームページを改修したんですが、 そのホームページが、ローテク手法で、フレームワークも何も使わず、1ページずつHTMLファイルで構築されているサイトだったので、 ミスも多いし、抜け漏れも多く、管理し切れないという悩みを職員さんたちみんなが感じていて、 ページのデザインを改修する事も重要だけど、重要な大学のホームページをちゃんと管理したいという事で、1年間のプロジェクトで ホームページ改修プロジェクトを発足しました。 やった内容としては、ホームページをまるっと別のフレームワークに載せ替えてリプレイスして、ソースコードをGIT管理して、 GITによる運用方式を1年間かけて講義したというプロジェクトになりました。 今現在は、ほぼ問題なく運用できていて、職員の皆さんがGITを使って各種のデータ更新をやってくれていて、「非常に便利になりました」とのコメントもいただき、 プロジェクトが大成功だったおいう経験があります。 これを、いろいろな職種で活用できるようにセミナーを組み立てればいいのかと考えたんですね。

GITを使った業務効率って何？

いろいろな職種というのが少しひっかかりますが、 GITと聞くと、やっぱりエンジニア（プログラマー）が使うツールというのが大半の人の認識でしょう。 だって、GITというバージョン管理ツールは、プログラミングのバージョン管理ソフトとして作られたモノですからね。 それも踏まえて、業務効率できる方法を考えてみました。

エンジニア／開発職

ブランチ戦略の導入： Git FlowやTrunk Based Developmentを導入し、開発の流れを明確に コードレビューの効率化： Pull Requestとテンプレートでレビュー基準を標準化 CI/CD連携： Gitのpushをトリガーにして、自動テスト＆デプロイ

デザイナー

バージョン管理としてのGit LFS活用： 大きな画像やPSDファイルもバージョン管理 共同作業の透明化： デザインファイルの変更履歴をチームで共有 プロトタイプの変更履歴管理： Figma → PNG出力 → Gitでバージョン管理

ライター・編集者

Markdown＋Gitで記事管理： ドキュメントの履歴・差分を簡単に比較 複数人での編集作業に対応： Pull Requestで編集内容をレビュー リリースごとにタグ付け： 記事のバージョン（例：第1稿、第2稿）を明確化

マーケティング職

キャンペーンページの履歴管理： HTML/LPファイルの更新をGitで管理 ABテストのパターン管理： ブランチごとに異なるページを作成・テスト レポートの変更管理： 分析結果の資料（MarkdownやCSV）をGitで共有

カスタマーサポート／営業

FAQやナレッジベースの管理： Markdown形式でGitに保存、履歴付きで編集 テンプレート管理： 営業資料やメールテンプレートのバージョン管理 問い合わせ対応フローの見える化： ワークフローや対応ログをGitで管理

マネジメント・PM

議事録やドキュメントをGit管理： 履歴と責任者が明確になる タスク定義やスケジュールのバージョン管理： 進行管理ファイルも履歴付きで記録 レポート・分析資料のレビュー体制構築： Pull Requestで部下のアウトプットを確認

共通の工夫

コミットメッセージの命名規則統一： 変更内容がすぐ把握できる GitHub/GitLabのIssue機能活用： タスクやバグ管理に統合的に使う Wiki機能をドキュメント共有に活用： ナレッジの中心をGitに一本化

Git学習に適している方法

Gitは、なんといってもGithubとセットで考えるのが一番いいでしょう。 Git自体はコマンドラインで使うことをおすすめしたいのですが、GUiツールを使っても問題はありません。 この辺は自分の環境や使いやすで考えればいいのですが、エンジニアだけはコマンドラインで使うことを強くオススメしたいですね。 ちなみに、GUIとCUIの違いは、細かな機能までの作業ができるかどうかと、バージョンアップの即時対応の為ですね。 そして、肝心のGitを学習したければ、一番いいいのが、複数人でいつのプロジェクト（リポジトリ）を更新し合うのがよく、 コンフリクトしてもいいように公開型にしないのもいいですが、「ブログをGITで書く」という方法は悪くない活用法とも言えます。 GithubのGit Pagesという機能を使えば、お手軽な公開方のWebページが手軽に作れますからね。 無料でかなりのことができてしまうというのもメリットの一つです。 あと、それ以前に苦労すると思われるのが、Gitに関するあらゆる関連単語を覚えていく必要があり、これはリファレンスやチュートリアルなどを通じて覚えていくしかありません。 あと、GITで誰もが苦労して覚える点としては、ブランチのHEAD状態の認識です。 未ステージ状態のソースをaddして、コミットして、pushして、ようやくmainブランチにマージするという工程で、今自分がどの状態なのかをstatusで確認するというこの工程に慣れるまでは、 本当にしんどい心情になると思います。 でも、ネットで色々と解説ページやブログがあるので、お金をかけなくても勉強ができると思いますし、メンターなどを使って教えてもらうというのも悪くないでしょう。

あとがき

知らない言葉（単語）をずっと聴き続けていると、人は眠くなります。 セミナーにおいてのこの状態は、無限ラリホーですよね。 この事態だけは避けないといけないので、おそらくセミナー冒頭で、セミナーで登場する単語集を定義しなければいけません。 でもたんなる辞書的に伝えるのではなく、理解する方法で、興味を無くさないようにしなければいけないので、用語集のペライチ書類を作っておいて配布するのも悪くないかと考えています。 でも、とにかく、このブログを書いてセミナーの内容の骨子が作れたような気がします。 叩き台として書いてみた今日のブログでしたが、GITを知らないし、エンジニアではないけど、業務活用に使ってみたいと考えた人がいたら、ぜひコメントしてもらうか、ご意見ご感想をいただきたいと思います。 なんなら、セミナーにご招待しますよ。