はじめに
最近!?入社しました（40分未満の運動は何も意味がないと考える）体育会系プログラマのymd2です！
これまではSIerやSESのようなお客様を支援する形での業態が主だったので、初めて自社サービスでワクワクしております！
さて、転職前後でたくさんの変化がありましたが、その中でも個人的に一番予想外だったのは、私のプルリクエストのマージ教がrebase主義派からmerge主義派に変わったこと。
- 「developの差分、トピックブランチにmergeで取り込めばいいじゃん。え？rebaseしたい？何で意味わからない？」って言われるアレです。
- トピックブランチをカジュアルにrebaseしちゃってmerge派のレビュアーに「レビュー中に最新の差分取るのめんどい、mergeしてよ」文句言われるアレです。
- 「Git logがきれいになるっていうけど、それ意味あるの？」って言われるアレです。
結構厳格なrebase主義派であったはずの私が、なんの苦労もなくすんなりとmerge主義派に「こんにちは」できたのには何かあるはず！！！ ってことで、ここでは体育会系らしく精神論の観点から考えてみます！
何が変わったのか？？
なぜrebaseをしなくなったのか、、、思い返すと1日のうちにプルリクに関する作業にかける時間がシンプルに短くなったことが大きい気がします。
これはインゲージが忙しいというわけではなくて、単純に
- Sier/SES
- 価値を生み出すには成果物（主にコード）を作ること。成果物がゴール。
- 自社サービス
- コードは価値を生み出すための手段。
といった何が価値（お金）を生み出す行為の差で、時間をかける比率が違うということ。
これらの差が純粋に個人に対するインセンティブに影響するので、仕事の行動様式がガラリと変わりました。
思えば、これまでSier/SESのお仕事は「守りの姿勢」が求められるものだったなと。
転職前: 「いのちだいじに」「じゅもんつかうな」
転職前はコードを書くのがお仕事なので、めちゃくちゃ乱暴に言ってしまうと「生み出したコードがお金を生むかは二の次」。 どちらかといえば「守りの姿勢」が大事になります。
- 守りの姿勢の特徴
- 拙速より巧遅
- リスクを裂けるため過去の成功を踏襲し、新しいことを極力避ける
- 自分の変更が他人に影響を与えないよう注意する
- バグの可能性を最小限にする（可能な限りリソースを投入する）
この観点からみると、rebase運用が理にかなっているなと。
- コミット履歴が整然としており、自分の責任範囲が明確。
- 統合ブランチへのマージ後にバグが発生しても、問題の切り分けが容易。
もう少し踏み込んで考えると、個人単位で成果を守る姿勢が仕事全体を支配していた気がします。
転職後: 「ガンガンいこうぜ」
一方、一般的に自社サービスの開発では「攻めの姿勢」が求められます。
- 攻めの姿勢の特徴
- スピードと柔軟性を重視
- 書いたコードが直接ビジネス価値を生む意識を持つ
- 個人ではなくチーム全体の成果を最大化
この環境ではmergeの運用が大きな効果を発揮します。
- 履歴を改変しないため、チーム内での混乱が少ない
- 大規模変更やリファクタリングを段階的に進めやすい
- 不具合発生時にhotfixを積んで最速で動くようにする、という力学が働きやすい
またインゲージでは、「統合ブランチへのマージ済みコードはチーム全体で責任を持つ」という意識があり、過去のコードであまりイケてない状況であってもその時点での最適解だったと受け入れ、必要なら恐れずに改修する。この柔軟性が、開発全体の強力な推進力にもつながっているように感じます。
まとめ
rebaseからmergeの選択には背景にある前提条件（例えば開発体制やリリース頻度など）もあるので、一概にmergeが正解などとは言えませんが
- rebaseからmergeのどちらを選択したのか？
- その理由は？
という問いからその会社／チームの働き方が見えてくるかも知れません！？
私の場合はrebaseからmergeに変わったのは、シンプルに仕事の性質が「守り」から「攻め」に変わったからでした。 自社サービスの会社ですと別種の苦労も多いのは事実ですが、仕事に対する達成感はケタ違いです。 仕事終わりのビールが美味い！！って働き方はいいものですねー！
