SIerとウェブ系のバージョン管理の違い
SIerとウェブ系企業ではバージョン管理に対する考え方も違っています。
ヤバいの出てきた pic.twitter.com/nZLs7BfE2w
— Ryutaro YOSHIBA (@ryuzee) March 20, 2021
SIerでのバージョン管理は「ちょっと進んでいるチーム」だとSubversionを使っています（※2020年の話です）
変化に寛容で、チーム内に痛みを伴った「導入・布教する努力」ができる人がいる場合に限り、Gitを使っているチームもあります。
ただし、私が知る限りでは人数が1000人以上いる本部の中で1つか2つといった感じです。
失礼な言い方をすると、多くのSIerの社員にとってGitは難しすぎるし、新たに勉強してまでGitをわざわざ使おうとする人はいません。
30歳以上のSIer社員の「技術アレルギー」は相当なもので、できるだけ「知らない技術」は避けようとする傾向が強いのです。
「じゃあSourceTreeでも使って簡単に使えるようにしたらいいじゃん！」と思われるかもしれませんが、SIerで配布される貧弱なWindows PCではSourceTreeの稼働が安定せず、謎のメモリリークのような問題が発生したりもします（実体験）
そういうわけで、SIerでのバージョン管理は誰にでもできる、最も簡単な方法を取ります。
ファイルサーバで日付管理
です。
吉羽さんのツイートのようなバージョン管理が至るところでなされています。
「手順書_20210321_レビュー前.xlsx」
「計画書_20210210_最新.ppt」
みたいなファイルが共用ファイルサーバに並んでいます。
毎週の定例では「報告書_20210115.xlsx」のような報告書で、日付を変えて編集していきます。
このようなファイル名に日付をつけてのバージョン管理がExcel、PowerPoint、Word、zipファイルなどあらゆるものに適用されているのです。
ちなみに「日付バージョン管理」の亜流として「末尾Ver管理」というものがあります。
SIerで、上司から「プロジェクト計画書を読んでおいて」と言われて、プロジェクト計画書を探したら
「プロジェクト計画書_ver0.9」
という資料があり、では「ver1.0」があるのかなと探しても見つからず、なぜか
「プロジェクト計画書_ver1.1」が見つかって、それを読んでいたら「最新はver1.3だ」と言われたことがあります。
末尾「_verX.X」で同じ資料を更新しているだけでなく、verX.Xが別々のフォルダに置かれていて、探し出すこともできない状態だったのです。
ソースコードのバージョン管理
SIerではソースコードのバージョン管理にも基本、Gitは使いません。
Gitを使っているのは全体の1%未満で、10%がSubversion、50%が謎の自前のバージョン管理システム、40%がCVSみたいな何かです。
「CVSみたいな何か」というのは、何かよくわからないのですが、編集したソースコードを謎の担当者みたいな人にメールして、CVSみたいなシステムに「登録してもらう」みたいな業務がありました。
誰かがどこかに登録していて、新しいソースコードを手元に落としたいときは、担当者にお願いして「最新版」をメールで送ってもらう、みたいなやり取りをした記憶があります。
SIerではGitHubへのアクセスが禁じられることもあるので、Gitのホスティングサービスを使う場合はGitLabかアトラシアン社のBitBucketを使うことが多いです。
といっても、当然ながらGitLabやBitBucketをバージョン管理に使っている部署は全体の1%未満で、ホスティングサービス云々まで話が及んでいないのが実情です。
まともなチームでSubversionを使っている程度でしょう。
ただし、Subversionの環境も会社で提供されているわけではないので、ガチガチに固められた社内のネットワーク環境の中に自前でVMを立ててSubversion用のサーバーを構築しなければなりません。
各チームごとに、やる気のある担当者が頑張って「バージョン管理用のサーバ」を作って、上司を説得して布教活動をして、周りのメンバーを必死にサポートして、やっとバージョン管理ができるのです。
「やる気のある担当者」と書きましたが、バージョン管理用のサーバを自前で立てるような“泥仕事”をやる人は「暇な人」をみなされるし、
手を動かすと「本来の（管理）業務をサボっている」と思われてしまうので、わざわざ余計な仕事を増やしてまで現状の業務を変えようとする人はほとんどいません。
そのような「手を動かすこと」に後ろ向きな社内文化もあるため、SIerのバージョン管理はおそらくは今後5年は「ファイル+日付」が主流となると思われます。
ウェブ系のバージョン管理
もはや書く必要はありませんね。
Gitでバージョン管理しています。
GitHubに変更内容をpushして、Pull Requestを送ります。
Pull Requestが通ったらmainブランチ（masterブランチ）にマージされます。
pushされたタイミングでテストが走り、問題があればテストで検出します。
検出された問題はSlackで通知され、issueを立てて解消していきます。
いわゆるソフトウェア開発の標準的なやり方です。
なぜSIerでは便利なバージョン管理システムを使わないのか
過去のしがらみがあるからです。
SIerでは30年前に作ったシステムを保守しているチームも数多くあります。
そのようなチームでは、30年前からずっと同じような「管理フロー」だったり、「バージョン管理手順」が使われています。
一部ではバージョン管理を専門とするチームがあるほどです。
このような「現状の業務」を変えるのは大変な痛みを伴います。
業務が細分化されていて、部署もまたがっているため、現状の業務を誰がどうやって、どのように担当しているのかがわからないくらい混沌としているケースも多いのです。
混沌としている業務を変更して、何か問題が起こったら大変です。
何か問題がある可能性がある場合は、たくさんの人を説得しなければなりません。
「問題はないのか？」
「何のためにGitを使うのか」
「今までのやり方で何が悪いのか」
などを部署をまたいでたくさんの偉い人に説明し、説得して回ります。
その後に待っているのは「現場の社員の嫌な顔」です。
今まで慣れ親しんだやり方を変えたい人は多くありません。
「新しい技術を試してみよう」という志向の人はSIerからいなくなってしまうので、残っているのは「現状維持」を好む人です。
できれば現状を変えたくない人にメリットを説明し、使い方を説明し、詳細な手順書を作り、質問に答えまくって、ようやくバージョン管理を導入できるのです。
SIerにGitを使える人がいないわけではありません。
みんながGitアレルギーを持っているわけでもありません。
変えよう、変えたい、なんとかしたいと思っている人はSIerの中に割と潜んでいます。
ですが、変えていくには多大なる労力を要しますし、普段の業務も忙しすぎて時間がありません。
