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

Gitの導入はなぜ失敗したか、どうすれば成功したか

YAPC::Kansai 2017のLTに応募してたんだけど不採択になったのでブログ記事にする。落ちるだけあって、大した内容ではないです ;-)

あとこの話はフィクションです。一応ね。

経緯

去年一年くらい、地方の中小企業的な某社(以後B社とする)に雇われて働いていた。PHPで、既存システムのリファクタリングとか、機能追加とかをやった。なおすべてリモートワーク。

B社はIT関係ではなく、自社システムのために社内にプログラマが多少いる、みたいな環境。半分内製、半分外注みたいな感じ。

B社のソフトウェア開発体制は、 ジョエル・テスト で0点取りそうな感じでまあ微妙。

VCS使ってないし、デプロイは自動じゃないし、バグ管理もスケジュール管理もできてないし、仕様書もない。

でも現状がいいとは思ってないみたいで、打ち合わせのときにも改善点ないか聞かれて、どうにかしようという意識はあるようだった。

ので、なにより自分のためにGitその他いろいろ提案したのだが……。

ツールは導入されました。しかしワークフローは改善されませんでした、みたいなことになった。

B社の開発ワークフローでつらかったのが、

  1. ソースコードのマスタが本番サーバにあるファイル。
  2. 作業がコンフリクトしないように、作業前に作業箇所を報告。
  3. 毎回本番サーバからダウンロードして、変更があれば手もとにマージ。手もとでは当然Git使ってるので。
  4. デプロイ前にもう一回ダウンロードしてきて、マージするなり。
  5. デプロイはFTPで手動。なお日付つきバックアップをしてからアップする。

みたいなあたり。

Gitを導入して、Gitリポジトリがマスタになれば、ほとんどの問題は解決するはずだった。

が、じっさいにはいろいろ問題が出て、なに一つ解決しなかった。

  • リポジトリの単位がおかしくて、一つのシステムが複数に分割されたりしていた。
  • ブランチが使われなかった。
  • コミットの粒度もおかしかった。

とかまあどうしようもない感じで、Gitリポジトリがマスタになれば、自動デプロイもすぐだなー、とか甘く考えてたのがぜんぶ駄目になった。

最初はこう思った

とにかく、もっとちゃんと使ってくれよ、わからないなら自分で学ぶか、せめて俺に聞けよ、と。

けどまあ、開発体制の改善が俺の仕事ではなかったし、リモートワークなんでコミュニケーションも取りづらいし、けっきょく行動しないままに仕事は終了。

終わってから今更ながら反省すると

落ち着いて考えると、目に見えるモチベーションなしに勉強なんてしないよね普通。そして、日付つきバックアップ作っていたような環境でいきなりGit使っても、便利さ感じるまで遠過ぎるよね、と。

じゃあ目に見える便利さがあればよかったんじゃないかな、便利さ駆動でなら学んだんじゃないかな、という結論に。

で、どうすれば便利だったか。いろいろ考えてみたけど、リモートで密なコミュニケーション取れるわけでもなく、立場的にあれこれ強制するわけにも行かず、みたいな前提だと、ワークフローを与えるみたいなのは却下。

じっさい、Gitやほかにもツール類はいくつか導入されたが、ワークフローの変更が必要な提案はどれも通らなかったし。

  • ツールの形で、
  • 一目瞭然な便利さがあって、
  • その便利さを継続して受けるためにGitをきっちり使う必要がある。

みたいなのが欲しい。

最終的には、Git + Jenkins + lftp使った自動デプロイスクリプトあたりで、とにかくワンタッチでデプロイできる形にした仕組みを丸ごと提案。

とかすればよかったんじゃないかなあと。

次機会があったら今回の反省を踏まえて、もっとうまくやりたいですね。