毎日温泉に入りたい♨︎

見た物や買った物、投資についてを書いてますヽ(* ॑꒳ ॑* )ノダァーッ!!

GitLabを導入して見えてきたのは組織の問題だった

こんにちは、こんばんは、おはようございます (。-ω-)ノ ダァーッ!!

現職ではGitLabを利用しています(させられている)がその中で組織の問題点が見えてきたけど似たような記事を調べても全然出てこないので徒然なるままに内容をまとめていこうかと、、、

前書き

  • 導入されたのは私が入社する少し前のこと
  • その段階、既存社員はGit自体を利用したことがない
  • この導入タイミングで他所から来た人は概ね利用していた
  • GitLabにしたのはコスト面の理由のみでまともな検討されなかった
  • 導入にあたっては別組織管轄

問題

  • ゲート式*1のMerge Requestになった、仕様すら把握していないのに目けんで品質の担保をするのはかなり難しい
  • 恐らくやりたいことはこの段階でのテストなのだろうが手を動かしたく無いのでやってないあるいはやれない感じ
  • 組織的に長ではない人間がふんずりかえる御山の大将ができてしまった
  • Gitでsvn運用を開始
  • 謎のブランチ運用、テストも受け入れ式なのでブランチ名はテスト内容を記載しているが、付いている日付はリリース日という矛盾、リリースブランチにdevelopという名前が付いてたりもする
    {見えてきた問題 マウント取りたい人間がいる,git運用を知らない,学ぶ気の無さ}

導入前に考えておく

  • 体験的にイミフ運用をやり始めてしまうと、後から変える事を嫌がる人が多くなる傾向が見られた、*2そのため事前に解放を考えておいたほうが良い、今回の場合半ば強制なので入れる側の責任感にも強く依存した
  • 運用はGit-flowを使うことで改善される、後から来た人も俺俺運用を学ぶ必要が無い、分からないからと言って変な運用を考えるくらいなら最初にオーソドックスな運用を学ぶ
    Git-flow ~Gitのブランチモデルを知る~ | バージョン管理システム入門(初心者向け)
  • チームになっていないなら大人しくチーム開発はしない、この辺は精神的な信頼関係が思っているよりとても大切
    チーム開発実践入門──共同作業を円滑に行うツール・メソッド:書籍案内|技術評論社 チーム開発の成功に大切なこと - Timers Tech Blog
  • ゲート式のやり方は至るまでの経路が複雑であればあるほど最後で違った時の修正が大きい可能性がある、そもそもゴールでスタートに戻される可能性が高いなんてリスクが高いしスピードが出ない
  • 適当にgit関連の書籍を読んでみるのも良いけど、個人的にはGitHabなど無料で利用できるリポジトリを作成して無理やりにでも触らせる必要があると感じた、特に失敗した時の使い方rebaseとかはいざ発生してから調べるより体験しておいたほうが精神的に楽(´д`*)だし、最初に遊び感覚で試すと後で眉間にしわを寄せるような事態になりにくい

まとめ

GitLabというツールではなく、利用する事で自組織の問題点が浮き出てきたのは意外だった
特筆するなら全体的な学習意識の低さ、既存の業務フローのあり方、mother fucker野郎の邪魔さなど人的障害が多分に散見された
結局のところウチの組織のチーム形成が壊滅的に出来てないという問題なのだが(笑)
自分も過去の職場で新規ツールやフレームワークを導入して失敗した経験があるが、重要なのはやる前に「それが必要か?なぜ必要なんだっけ?」を問うて答えになることだと思う
コストの問題はあるものの自組織の特製を見直し理解してそれにあったものや運用ルールを事前に大真面目に検討したほうが良いなと

*1:受入れ方式

*2:自分が生み出した運用こそが正しい的なプライドなのかな…