はじめに
バージョン管理システムのGitは、今や多くの開発現場で当たり前に使われている技術です。 しかし、Gitが導入され、メンバー全員が使えるにもかかわらず、なぜか誰も使おうとしないという不思議な現場も存在します。
この記事では、国内屈指の大手企業のプロジェクトで実際に起きた、Gitを意地でも使わない現場の実話を紹介します。
本記事は、個人や企業を誹謗中傷することを目的としたものではなく、以下を目的としています。
- 企業からは都合の良い情報しか発信されないことが多いため、求職者が一方的な情報に惑わされないようバランスを取る
- 仕事の中で起こりうる想定外な出来事や、理不尽な出来事をあらかじめ知り、対処や心構えの一助としていただく
- 業界に対して不満はあるが、立場上声を上げにくい現場の方々に代わって、内情を吐露することでガス抜きの場とする
実体験をもとに、なかなか表に出てこない業界の実情をお伝えし、学生やエンジニア、マネージャーの皆様の今後のキャリア選択に役立てていただければ幸いです。
Gitを意地でも使わないプロジェクト
これは、国内屈指の大手企業が発注するシステム開発プロジェクトでの出来事。
このプロジェクトでは、Gitがすでに導入されており、メンバーも一通りコマンドを扱える状態だった。 つまり技術的な障害は何もない。それでも、なぜかチームの誰もGitを積極的に使おうとしなかった。
あるとき、新しく参画したエンジニアCが、レビューの進め方について尋ねた。
紙でのソースコードレビュー
- エンジニアC 🙂 「プルリクエストって、どうやって出せばいいですか？」
- ベテランエンジニアD 😐 「プルリクエスト？ うちはそういうのやってないよ。」
聞けば、このプロジェクトのコードレビューは、WinMergeで差分を取り、その画面をExcelに貼り付けて印刷し、紙で行うのが慣例だという。
- エンジニアC 😳 「え、印刷して紙でレビューするんですか……？」
- ベテランエンジニアD 😑 「その方が見やすいでしょ!!」
半信半疑のまま、エンジニアCは初めて紙でのレビューを受けることになった。 WinMergeの差分画面をExcelに貼り付けて印刷したものをベテランエンジニアDに提出し、確認を待つ。
数分後、ベテランエンジニアDが眉間にしわを寄せながら紙を持ってやってきた。
- ベテランエンジニアD 😠 「ちょっと、これ変更したところの色が分かりづらいよ」
- エンジニアC 😕 「え、色、ですか……？」
- ベテランエンジニアD 😡 「見づらいだろ！ 」
- エンジニアC 😥 （Gitがあるのに、なぜ紙の色使いで怒られているんだろう……）
結局、エンジニアCはその場で色設定を変更し、WinMergeの差分をあらためて印刷し直すことになった。
ブランチ一本化戦略
さらに話を聞くと、開発は複数人が並行して進めているにもかかわらず、ブランチはほとんど使われていないという。
- エンジニアC 🤔 「複数の機能が開発同時進行してるから、ブランチ切った方がいいんじゃないですか？」
- ベテランエンジニアD 😠 「ブランチが複数あると煩雑になるから、うちは一本化でいくことにしてるんだ。」
一本化とは、つまり全員がひとつのブランチに直接手を加えるという運用のことだった。
- エンジニアC 😨 （それ、実際の開発が並列で進んでいるんだから、ソース管理するの放棄して、現実逃避しているだけでは…）
案の定、コンフリクトは発生したが、他のメンバーが加えた改修を、上書きしてしまってもベテランエンジニアDは悪びれる様子はなかった。
誰もpushしないチーム
さらに厄介なことに、ベテランエンジニアD含む他のメンバーは、ローカル環境だけで作業を進め、リモートへpushする習慣がなかった。つまり、誰が何を変更したのか、Git上で共有される仕組みが存在しない。
- エンジニアC 😰 「みんなの変更、Gitに反映されてないですけど、大丈夫なんですか？」
- ベテランエンジニアD 😠 「今忙しい、そのうちやるよ。」
悪びれる様子もなく答えるベテランエンジニアD。
- エンジニアC 😨 （資産管理できていないのに、……誰も気にしてない）
見て見ぬふりをすることもできたが、リリースが差し迫っていたこともあり、エンジニアCはやむを得ず自分の判断で対応することにした。 サーバ上にデプロイ済みのファイル一式があることに気付いたエンジニアCは、そのファイルのタイムスタンプを一つひとつ見比べ、どのファイルが最近更新されたのかを自力で判別していった。
- エンジニアC 😖 （このファイル、更新日時が新しいから、たぶんこれが最新版……）
判別した差分をローカルの作業コピーに反映し、内容を確認したうえで、エンジニアCは自分の名前でGitにpushした。 それでもベテランエンジニアDや他の若手メンバーは、相変わらず無関心なままだった。
結果として、複数人が実際には開発に関わっているにもかかわらず、Gitのコミット履歴に残るのは、たまたまその役割を引き受けたエンジニアCだけという状態になっていた。
- エンジニアC 😵 （このプロジェクトのGit、個人開発みたいなコミットログだな……）
解説
このプロジェクトの最大の問題は、Gitという技術的な障害が一切ないにもかかわらず、運用そのものが技術を活かせない形になっていたことです。 プルリクエストによるレビューを紙とExcelの印刷に置き換え、ブランチ運用を「煩雑だから」という理由で放棄し、pushの習慣すらないという状態は、Gitを導入した意味そのものを失わせてしまっています。
特に深刻なのは、サーバ上のタイムスタンプを目視で確認し、差分を人力で判別してpushするという運用です。 これはGitが本来自動化するはずの作業を、わざわざ非効率かつミスの起きやすい手作業に置き換えてしまっている状態であり、しかも複数人の開発成果が一人の名前でコミットされることで、誰が何を作ったのかという記録すら失われています。
メンバーのリテラシーや協調性が異常に低い現場もあり、こういった現場では一部のメンバーに作業が集中することになります。
おわりに
世の中には、このように技術が導入されていても、それを活かす気がない、あるいは変化を恐れて古い運用を続けてしまう企業やプロジェクトが実際に存在します。
これまでは人手不足の中、多少非効率な現場であっても「仕方なく」発注し続け、そこで働き続けるという選択が取られがちでした。 しかし、AIの台頭によって、こうしたいい加減な運用を続ける取引先やプロジェクトと関わり続けることは、今後キャリア上のリスクになっていく可能性があります。
もし今あなたが、このような非効率な運用を「当たり前」として受け入れている環境にいるなら、発注先を見直す、転職する、あるいはフリーランスとして独立するなど、環境を変える選択肢を検討してみる価値があるはずです。