お久しぶりになってしまいました。イノウエです。

もっとコンスタントにブログを書きたかったのですが、アウトプットが遅くなってしまいました。
言い訳っぽくなってしまうのですが、本ブログのタイトルに記載した通り GitHub を会社で提案する機会がもらえたので、そちらに注力していたのです。

熱量のあるうちにこちらの話を今日は記録します。

GitHub ってすごいよね

GitHub ってとっても便利ですよね。
何を当たり前のことを、と言われてしまうと思いますが…。
今年 7月に GitHub に出会って以来、少しずつ色んな機能を開拓していっているのですが、あまりの便利さに感動する日々です。

そしてふと思いました。
こんなに便利なのになぜ弊社では使ってないんだろう？
GitHub 使ったら業務効率向上するし、何より仕事の仕方が変わるよなぁ、と。

誤解を防ぐために申し上げますが、決して今の会社のやり方を否定するつもりは一切ありません。
歴史の長い会社なので長年にわたって培ってきたものが沢山あり、それ自体は素晴らしいと思っております。
ただGitHub を取り入れたらもっと仕事環境がよくなるのでは、と思った次第です。

GitHub の導入を提案

上司とお話する機会があり、仕事環境の課題についての話題になったときに
『今だ！』
と突然体内の全細胞が大騒ぎ。ﾜｱﾜｱ

チャンスが来たと思って
「GitHub という便利なものがあるのですが、それなら改善できるかもしれません…」
とお話してみました。

ありがたいことにその話に耳を傾けて下さり、GitHub の導入の提案をする機会をいただきました。
嬉しい！！

現状の課題を洗い出し、改善策をまとめた提案資料を作成しました。

Speaker Deck に提案資料を載せているので、宜しければご覧ください ☟☟
バージョン管理システムによる開発環境の課題改善検討案
（勤務先の情報を一切含まないように一部修正しております）

GitHub で何がどう変わる？

資料にもまとめたのですが、GitHub でどう課題を改善できるかについて、こちらにもつらつらと書いてみます。

バージョン管理ができる

現状

ソースコードはバージョン毎にファイルサーバ上に保存

project1  
　├ project1_ver1.0.0  
　├ project1_ver1.0.1  
　└ project1_ver1.0.2

といった感じですね。

課題

ファイルサーバで書き換えできる権限のある人は容易に変更・削除が可能
更に変更・削除してしまった場合の復旧が困難な場合も十分考えられます
複数人で作業することが多いので、他の人の変更に気づかずにうっかり上書きしてしまったりも…
上書きしてしまったことにすら気づけなかった場合はもう言葉がありませんよね…怖い話…！

命名ルールの一貫性が損なわれると変更の把握が困難
一貫した命名則に基づいて名称が付けられているときは問題ないですが、例えば以下のように
```
project1  
　├ project1_ver1.0.1_最新  
　├ project1_ver1.0.1  
　├ project1_ver1.0.1_1  
　└ project1_ver1.0.1_2  
```
となっていたら何が何だか分からないですよね。
これは少し大袈裟かもしれません（もはやバージョンが機能していない）が、複数人で編集する以上、後から履歴の把握が難しい変更をしてしまうこともあります。

改善案

GitHub の Release 機能と Tag 機能で容易にバージョン変更できないように
Tag でバージョンなどの名称を付けることができ、Release 機能で Tag を付けたソース等を公開できます。
リリースノートでコメントも追加できるので、前回のバージョンからの変更点などが記載できる点もとても便利だと思います。
GitHub の画面上では Release や Tag の変更はできないので、うっかり削除の心配も少ないです。

監査ログで操作履歴を追跡
オーナー権限のある方のみ、Organization メンバーの操作履歴を閲覧することができるようです。
変なことするとバレちゃいますね。

ソースコード結合作業の改善

現状

マージツールで比較をかけて手作業でソースの結合

対象ソースコードを複製して開発者に渡す
開発者が対象ソースコードを変更
開発者が変更後のソースコードを一式をファイルサーバの指定フォルダに配置
マージ担当者が変更内容をマージツールで確認しながらマージ
マージ担当者がマージ結果を検証
マージ担当者がマージされたソースコード一式をファイルサーバの指定フォルダに配置

課題

作業に時間がかかり、ミスが生じやすい
もうこれに尽きますね。現状の手順書くのもちょっと疲れちゃいました。
作業が増えるとその分ミスも発生しやすくなるので、できるだけ簡単に済ませたいところですよね。
何しろ時間を割くべき作業ではないと思っているので、こういった事務的な作業はどんどん減らしたいです。

マージ作業が複雑、分担が困難
総じてマージ担当者の負担が大きいですよね。
ソースコードを編集する人数が増えれば、その人数分マージをかけなければならないので、規模の大きなプロジェクトだと大変なことになりそうです。
全員がバラバラのバージョンからの修正をしていたら…と考えたら胃が痛くなってきました。

改善案

GitHub の Pull requests 機能により、視認性の高いレビューと安全なマージが可能
レビューとマージが流れで行えるって凄くないですか…。
GitHub と出会ってから個人的に一番驚いた機能かもしれません。（まだまだ機能は開拓中ですが）
ファイル同士比較をかけながらレビューして、問題がなければ自動でマージしてくれるなんて、私はなんて素晴らしい時代に生まれたのでしょうか。

経過をプロジェクトメンバー間で共有できるため、分担や再修正が効率的に
改善案の1点目に挙げた Pull requests の状況が全て記録されており、いつでも確認可能なので、誰がどのような作業をしているのかが把握しやすくなります。
手動マージの時のような、マージ担当者1人への負担が大きいといったことはなくなるでしょう。

バグやタスクが管理しやすくなる

現状

ソースコードやドキュメント、タスクやバグの一覧をそれぞれ独立して管理
ソースコードやドキュメントはそれぞれ指定のファイルサーバに、追加のタスクやバグは Excel 上に一覧でまとめており、こちらも同じくファイルサーバに置いて管理しています。

課題

タスクやバグの資料からソースコードやドキュメントの変更が辿れない
ファイルサーバでそれぞれ管理しているとこれは当たり前だと思いますが、Excel の一覧表からはソースコードやドキュメントをどのように修正したのか辿ることは難しいです。
タスクが複雑になってくると、修正したのかしていないのか把握しきれない事案が発生し、本当に修正済みになっているか2、3度チェックし直したりなど、手間と時間がかかる羽目に。

改善案

GitHub の Issue 機能や Milestone 機能により、タスク・バグ管理や進捗把握の効率化
Issue にタスク等を書き出し、Milestone を各 Issue に設定することで、効率的にタスク管理が行えます。
Issue のほかに Pull request にも Milestone を設定できます。 Milestoneではタスクの進捗率がバーで表示されるのですが、こちらは一目で進捗状況が分かりやすくて便利です。
また commit と Issue を紐づけられるので、タスクからソースコードの確認が容易になります。

まとめ

今回は、とある会社への GitHub の導入の提案について記録いたしました。
きっと同じような環境の会社は一定数存在すると思うので、そういった方に向けて何か参考になるものがあれば幸いです。

実際に導入に踏み込んでくれるかは会社の判断なので分かりませんが、少しでも今の環境が変わるきっかけになればと願っております。

これからもどんどん不要な作業を減らして、時間をかけるべきところにかけられる職場環境にしたい！です！

がんばるぞう🐘

こちらのブログは初心者エンジニアが勉強の記録やアウトプットの一環として執筆しております。
内容に誤りがある可能性が多大にありますのでご了承ください。

ほっそりイノウエの
マッチョエンジニアへの道

GitHub の導入を会社に提案してみた話