読者です 読者をやめる 読者になる 読者になる

わざわざ残す必要もないことを整理とか気にせずに吐き出していく。そんな空間。

社内にてsvn=git移行担当に任命されました。

胃が痛い。

社内にてsvn=git移行担当として任命されることになりました。今の現場は8月中旬から(だっけ?)になりますので、入ってきて二ヶ月ちょっとの若造にsvn=git移行を一任するクレイジーな会社です。ほんとに胃が痛い。

事の発端

うちでは社内にsmbがありまして、みんながそのsmb上で作業をしております。みんながsmb上で作業するので、まぁあれですね。言わずもがな的な障害が色々と起こっておったわけです。

うちでは複数の製品をリリースしておりまして、各製品で継続的にリリースが発生する、という状況です。その複数の製品での共有ソースというのがありまして、それなんかはもう管理がほんとに大変で。各製品毎にCOじゃないんですね。開発中もソースを共有しているのです。

もうデスクを挟んで「今○○の画面でdumpしてるの誰?」とか、「○○で画面真っ白だけど、誰か触った?」みたいな。まぁ(何故か)色々と尖ったミドルを採用してたり、なのでローカルに環境つくりにくい、と言う理由もあるのですが、本当に困った状況でした。

とりあえず「共有ソースの部分を製品ごとに持とう」という改善案が出たのですが、そこから何故かあれよあれよと話が進展して、「gitどうなんよ」って話が上がったわけです。

んでそこから何故かこの私が社内GIT講習会を開くことに。勉強会でもLTくらいなもんなのに業務で1時間喋るとは思わんかった。あぁ胃が痛い。

GITとSVNの違い

 社内講習会でGIT説明なんて言っても、技術者から非技術者まで揃っててどうやろうかと悩んだ。とりあえず初回講習会は「GITで何が変わるか」に充填を置いて説明。「GITの使い方」とはハッキリ分けましょうという方針で。

  • gitとsvnの違い
  • gitから生まれる新しい運用フロー(gitflow,githubflow)
  • ツールを変えるだけでは大したメリットはない。学習コストとトントン
  • ツールからメリットを得るには運用フローの根本的改善が必須。

という感じで「運用まで変えないと意味ないですよ」的な感じの慎重論で締めようとしたわけです。現状運用面ではファイルベースのリリース管理を行っていたので、ファイルベース、コミットベース、ブランチベースそれぞれのリリース管理方式のメリット/デメリットを比較参照しながら…

が、予想に反して管理者陣から好評を頂き、「で、GITHUB ENTERPRISEっていくら?」みたいな話に発展する始末。技術者陣の沈黙がやや気になる中、この流れは多分止まらない。あぁ胃が痛い。

SVN=GITへの移行は怖い

 社内運用のフロー改善なんて、ろくでもない仕事です。みんなからの嫌われ者。タスクとしてのやりがいはあるわけですが、状況はあまり芳しくない。20代だし、現場入ってまだ2ヵ月だし。こういう業務ってコミュニケーション力が最重視されるわけじゃないですか。なかなかハードル高いのです。

 とはいえ、社内でまともにgitを使えるのはうちしかいないわけで、というかうちもまだ黄色いgitのポケットリファレンスは必携の状態なのですが、まぁこういう状況になるべくしてなった、というかなんというか。

 社内運用改善で成功をおさめるためには、社内の不満とどう戦うか。丸め込むかヒアリングして解消するかの二択。入社2ヵ月の自分には、丸め込む程の権力も無いので(というかそういうの好きじゃない)、ヒアリング一択なわけですが、不満をばんばん吐露してもらえるほどの人間関係はまだ築けてねぇですよ。「現行の改善案で不満が生じていないか」みたいな悪魔の証明と闘いながら業務に当たらなければならないわけです。

 PHPの現場である以上「勉強したくない人間」にやさしい職場づくり、ってのが個人的なポリシーで。馬鹿となんとかは使いようなのがPHPのメリットなのですよ。例のアレみたいな選民思想むき出しで、自分たちだけ「楽しい」言語なんて嫌いなのです。「教育」なんてのを押し付けてくるアレも嫌いです。

 とはいえGITの採用が始まった以上、だれでも使えるGITフローってのを構築していかないと行けない。表面化しない不満と戦いながら運用フローを考える。いじめとか起きなきゃいいけど。あぁ胃が痛い。

PS. やりがいあるので不満は全くないですが、胃薬がほしいなぁというエントリーです。