Shimpei Wakida のブログ

日々の学びをゆるりと。FinTechなスタートアップでRailsエンジニア・エンジニアリングマネージャー・スクラムマスターなどをやっています。

『スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス』読んだ

私の働く会社ではプロダクト2つ持っており、それぞれでチームが独立しています。

数ヶ月ほど前、私のチームでは私がスクラムマスターとなり、本格的なスクラム開発の導入を推進することになりました。 当時、会社にはほとんどスクラム経験者がいませんでしたが、ちょうどその頃、元トヨタスクラム開発の経験者がもう一つのチームにジョインしました。その方と連携しながら知識をインプットし、なんとか本格的にスクラムを導入して約1ヶ月が経過。

スクラムの体系的なインプットは『スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (WEB+DB PRESS plus) 』をチームの教科書とし、週一の輪読会を行いながら全員で理解を深めました。

スクラムに関する知識が網羅的にインプットできるのはもちろん、他社の導入事例が紹介されていたのが印象的でした。

事例として紹介されていたのは、GMOペパボmixiDeNAという有名テック企業たち。今ではテック企業としての確固たるポジションを確立している彼らも、スクラム導入においてはちゃんと失敗していたことを知れました。

スクラム素人の自分たちだって失敗して当然だ」と、ある意味開き直ることができました。

失敗事例を見ると、その失敗の根底にある課題は

  • スクラム導入の目的をチームメンバーが理解していない
  • スクラムに関する知識をインプットしないままスタートしている

あたりに集約されそうだと思いました。

スクラム導入初期は、必ず困難にぶち当たります。うまくいってる実感を感じられない瞬間もあるはずです。そもそもスクラムは、課題をあぶり出すフレームワークでもあるので、当然です。そんな時に、スクラム導入の目的・スクラム導入によって得られるメリットを正しく理解できていないチームであれば、「やっぱりうまくいかないからスクラムやめよう」という思考になってしまいます。

事例では、上記のような理由で一度失敗したあと、チームメンバーでスクラム勉強会を実施し、スクラムマスターだけでなくメンバー全員がスクラムに関する解像度を高める活動をすることで、状況の改善を図っていました。

「成功はアート、失敗はサイエンス(成功に再現性はないが、失敗には再現性がある)」などと言いますが、同じ失敗を繰り返さないよう私のチームではスクラムに関する知識のインプットをしっかり行ってから実際の開発をスタートさせました。

おかげさまで、スクラム開始から2ヶ月ほど経過しましたが、全員がスクラムの価値や原則をある理解できているので、課題を前向きに捉え、改善を繰り返しながら少しずつ良い形になってきています。

スクラムをやって実際に感じているメリットについても、別記事でまとめようと思います。

MySQLでバックアップ・リストア

概要

たまにローカルのMySQLをPC上からMySQLごと削除したい場面がある。ただ、データは残しておきたいときもあるので、バックアップ・リストア方法を調べた。

基本的には mysqldumpでバックアップ・リストアする - とほほのWWW入門 を参考にさせていただいてます! www.tohoho-web.com

バックアップ

とりあえず以下のコマンドを叩けば、最低限安全にバックアップは取れる。

mysqldump -h localhost -u root -p パスワード --databases データベース名 \
  --single-transaction > dump.sql

冒頭紹介した記事では、--flush-logs--master-data=2のオプションを付けていたが、アプリ側の設定によっては以下のエラーが起こる(起こった)

mysqldump: Error: Binlogging on server not active

対応方法は、2つ。

1つ目は、my.cnfに以下の設定を追加し、再起動。

[mysqld]

log_bin = /var/lib/mysql/mysql-bin.log

参考 blog.siwa32.com

もう一つは、--flush-logs--master-data=2のオプションを使わないこと。

リストア

mysql -h localhost -u root -p パスワード < dump.sql

MySQL5.6→5.7のアップデートで「Library not loaded: libmysqlclient.18.dylib (LoadError)」に対応した

概要

RailsアプリのローカルDBで使用しているMySQLバージョンを5.6から5.7に上げる時ハマったので備忘録。

バージョン

手順

MySQLのバージョンを上げる

brew uninstall mysql@5.6
brew install mysql@5.7
mysql.server restart

などを行った後、

bin/rails db

でDB接続を試みると、

(中略)
dlopen(/Users/{ユーザー名}/.rbenv/versions/2.7.5/lib/ruby/gems/2.7.0/gems/mysql2-0.5.3/lib/mysql2/mysql2.bundle, 0x0009): Library not loaded: /usr/local/opt/mysql@5.6/lib/libmysqlclient.18.dylib (LoadError)
  Referenced from: /Users/{ユーザー名}/.rbenv/versions/2.7.5/lib/ruby/gems/2.7.0/gems/mysql2-0.5.3/lib/mysql2/mysql2.bundle
  Reason: tried: '/usr/local/opt/mysql@5.6/lib/libmysqlclient.18.dylib' (no such file), '/usr/local/lib/libmysqlclient.18.dylib' (no such file), '/usr/lib/libmysqlclient.18.dylib' (no such file) - /Users/{ユーザー名}/.rbenv/versions/2.7.5/lib/ruby/gems/2.7.0/gems/mysql2-0.5.3/lib/mysql2/mysql2.bundle

のエラー発生。

Reason: tried: '/usr/local/opt/mysql@5.6/lib/libmysqlclient.18.dylib' (no such file) と言われても、もうMySQL5.6はアンインストールしてるんですが?という感じ。

ファイルも、当然存在しない。

$ ls /usr/local/opt/mysql@5.6/lib/libmysqlclient.18.dylib

ls: /usr/local/opt/mysql@5.6/lib/libmysqlclient.18.dylib: No such file or directory

MySQLの場所を確認

brew info mysql@5.7

すると、以下のようなものが出力される。

==> mysql@5.7: stable 5.7.39 (bottled) [keg-only]
Open source relational database management system
https://dev.mysql.com/doc/refman/5.7/en/
/usr/local/Cellar/mysql@5.7/5.7.39 (320 files, 233.6MB)
  Poured from bottle on 2022-10-27 at 23:41:25
From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/mysql@5.7.rb
License: GPL-2.0-only
==> Dependencies
(中略)

mysql@5.7はどこにいるかというと、ここ/usr/local/Cellar/mysql@5.7/5.7.39

シンボリックリンク貼る

sudo ln -s /usr/local/Cellar/mysql@5.7/5.7.39/lib/libmysqlclient.dylib /usr/local/lib/libmysqlclient.18.dylib

これで解決した。

『SCRUMMASTER THE BOOK 優れたスクラムマスターになるための極意――メタスキル、学習、心理、リーダーシップ』読んだ

私の働く会社ではプロダクト2つ持っており、それぞれでチームが独立しています。

数ヶ月ほど前、私のチームでは私がスクラムマスターとなり、本格的なスクラム開発の導入を推進することになりました。 当時、会社にはほとんどスクラム経験者がいませんでしたが、ちょうどその頃、元トヨタでスクラム開発の経験者がもう一つのチームにジョインしました。その方と連携しながら知識をインプットし、なんとか本格的にスクラムを導入して約1ヶ月が経過。

スクラムの体系的なインプットは『スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (WEB+DB PRESS plus) 』をチームの教科書とし、輪読会を行いながら全員で行いました。

おかげで、スタートして1ヶ月経ちますが、全員がスクラムの価値や原則をある理解できているので、課題を前向きに捉え、改善を繰り返しながら少しずつ良い形になってきています。

うまく回り始めたスクラムチームですが、よりよいチームにすべく、私自身スクラムマスターというロールについての理解をさらに深めたいと思い、『SCRUMMASTER THE BOOK 優れたスクラムマスターになるための極意――メタスキル、学習、心理、リーダーシップ』を読みました。

結論、めちゃくちゃスクラムマスターというロールについての解像度が高まってよかったです。同時に、スクラムマスターの責任範囲が明確にわかったことで、それ以外のPO・開発者のロールについても理解が深まりました。

本書によると、スクラムマスターの役割を超ざっくりまとめると以下です。

  • チームの自己組織化の促進
  • コーチでありファシリテーター
  • デリバリーの責任は負わない

最大の目的は、「チームの自己組織化」です。これを達成するためにスクラムマスターは存在します。極論、完全に自己組織化したチームにおいてはスクラムマスターは不要といえます。

まあ現実的にはそんなチームは滅多にないでしょうから、タックマンの集団形成モデルの各ステージによって立ち振る舞いを変えながら、自己組織化を支援していくことになるでしょう。

タックマンの集団形成モデルとスクラムについては、こちらの @ryuzee さんのブログがとても分かりやすいです。 www.ryuzee.com

余談ですがこのブログ、「スクラムで困ったらとりあえず見に行け!!!何かしらのヒントが得られるはずだ!!!」と声を大にして言いたいくらい、スクラム開発に関する有益情報で溢れかえっています。超おすすめです。書籍に書かれている抽象的な内容と、現場で実践する具体とのちょうど間を埋める、「そうそう、これが知りたかったんだ!」という粒度の内容となっています。

あとは、スクラムマスターは基本的に「コーチング」に徹するサーバントリーダーなので、いわゆる問いかけスキルが問われますね。これは私自身も業務の中で実践しようとしてますが、とてつもなく難しいです。どこかで専門的にコーチングを学んでみたいとも思いました。

スクラムマスターにはもちろん、それ以外のスクラム開発に関わるPO・開発者にとっても面白い本だと思います。

付録(読書メモ)

  • スクラムマスターの役割
    • 自己組織化の促進
    • コーチでありファシリテーター
    • デリバリーの責任は負わない
  • スクラムマスターがマネージャーと兼務の場合(今これ
    • デメ
      • 命令的で、コーチングではなくメンタリングに頼りがち
    • メリ
      • 移行期には対応がすばやい
  • 結果
    • スクラムマスターの役割が軽く扱われる
    • マネージャーが意思決定・問題解決・調整を行うため、自己組織化・自己肯定感・当事者意識が弱くなる
    • → 移行期が終わったらスクラムマスターは他のメンバーに渡すべきだな
  • スクラムマスターの目的
    • リーダーシップ(サーバント)
      • スクラムを理解しているだけではだめ。リーダーシップが必要。
    • 1つのスクラムチームだけでなく、組織全体に目を配り、みんながよりうまく働けるようにすること
    • アジャイル移行期には、ガイド役となる
  • 仕事の仕方
    • 障害物の除去
      • 他のどんな管理職とも違う
        • 責任・活動・オーナーシップをチームに委譲
          • そうすることで、自己組織化が進む
    • ファリシテーション
      • ファシる際には、議論の内容や解決策には絶対に干渉しないのがルール
        • (マジか。死ぬほど意見出してる)
    • コーチング
      • 習得は大変だが、できるととても強力な武器となる
  • スクラムマスターの3つのステージ
    • 自チーム
    • チームとチーム外
    • 組織全体
  • タックマンの集団発達モデル(ここでも出てきた
    • フォーミング(形成期)
      • 会話もあまりない、スクラムの原則も浸透していない
        • このフェーズでは、ティーチング、説明すること、経験を共有すること、に時間を割く
    • ストーミング(混乱期)
      • スクラムは、チームの限界をこえるコミットメント・コミュニケーションを要する
        • チーム内で議論が激しくなり、冷静さを失うこともある
      • お互い一緒に働くことができそうなワーキングアグリーメントを作る
      • SMとしては、「ファシリテーション」が重要
        • 円滑なコミュニケーションを促す
    • ノーミング(統一期)
      • ストレスから解放され、一息つける
      • うまくいってる実感を得られる
      • 落とし穴
        • うまくいって、快適がゆえに「これ以上改善することはない」という思考に陥りやすいので、さらなる改善を促す
        • SMとしては、「コーチング」によって、チームの自己組織化を目指す
    • パフォーミング(機能期)
      • チームが自信にあふれ、常に良い方法を探している
      • SMとしては、観察し、以前の状態に戻らないように気を配る
    • メンバーが抜けたりすると、また以前のフェーズに戻ってしまう
    • → スクラムを始めるまえに同期作業をかなりやっていたことで、混乱期〜統一期 くらいの状態でスクラムをスタートできていたのはでかい。
  • 守破離
    • 習得するまでに数年かかることもある
      • まずは、1人の先生のやり方を徹底的に身につける
      • 複数の先生の意見を取り入れてみる
      • 独自のやり方に進化させていく
  • ファシリテーション
    • スクラムマスターのコアプラクティス
    • ファシリテーションとは、議論の枠組みと流れを定義すること
      • 議論の内容ではない 
    • すぐれたファシリテータは、準備はするが場の熱量を見て柔軟に対応できる
    • 実践
      • 会議の前に
        • 目的を明らかにする
        • SMART(具体的・測定可能・達成可能・合意済み・現実的・時間制限あり)
      • 会議中
        • 開始数分が極めて重要
        • 目的・期待される成果物・議題を常に共有する
          • 各自にとってこの会議がどういう意味があるものなのかを考えてもらう
  • コーチング
    • 最も重要なスキルの一つ
      • パワフルクエスチョン
        • 何を達成し、変え、獲得したいですか?
        • 今、あなたにとってなにが重要ですか?
        • 完璧なスタンドアップミーティングとはどのようなものですか?
        • 何がうまくいっていますか?
        • これまでどのような進展がありましたか?
        • 目標を達成するために何を変える必要がありますか?
        • それについてなにができますか?
        • 違うやり方で何ができますか?
        • やめるために何をする必要がありますか?
        • 他には何がありますか?
        • 次はなんですか?
        • 根本解決
        • フィッシュボーン
        • 5W1H
        • なぜなぜ5回

『「60分」図解トレーニング ロジカル・ファシリテーション』読んだ

自分のロールであるエンジニアリングマネージャー・スクラムマスターという仕事柄、普段の業務でMTGファシリテーションを行うことが多いです。

一日平均で数回はファシリテーションをやっているにも関わらず、ちゃんとファシリテーションを学んだことないなと思い、関連本を読んでみようと思いました。

そんな中、社内でおすすめの本としてこちら紹介いただいたので、早速読んでみました。

一言でいうと、『ロジカル』とタイトルにあるように、「論理思考をベースに会議の設計や、会議中の進行をしていきましょう」という内容の本でした。

逆をいうと、まずは自分が論理思考をある程度理解して使える状態になっていないと、ファシリテーターを務めるのは難しいよ、ということかな、と解釈しました。

「まずはMTGの目的や目標(ゴール)設定をしましょう」という、どこでも見聞きするような内容から、実際の議論の中で「論点がずれていないか?」「この発言の根拠は確かか?」「両者の意見が食い違っているが、そもそも二人の頭にある前提は揃っているか?」など、多岐に渡る要素を1つ1つ状況に応じてクリアにしていき、参加者全員の認識を合わせながらMTGのゴールへ向かわせよう、という実践的な内容まで幅広く網羅されていました。

本書にあった上記ファシリテーションの役割を果たす上で、必要になる能力は個人的に2種類あると思っていて、1つは「状況把握する能力」、もうひとつは「軌道修正する能力」です。

前者はまさしく「ロジカルさ」が求められる部分で、ゴールに向かって議論が正しく進んでいないときの原因を正確に突き止めるために、ロジカルシンキングが必要になりますね。

後者においては、ロジカルシンキングによって察知したズレを実際に修正していくところで、「どういった問いかけをするか?」がとても重要だと感じています。具体的には、「言葉遣い」ですね。

「それってあなたの感想ですよね?」より、「なるほど、〇〇さんはそう思われたのですね。ちなみに、そう思うに至った根拠はありますか?」と聞くほうが、言われた側も気持ちよく返答できますよね。

これは極端な例だとしても、実際のビジネスの現場におけるMTGでは、「もうちょっと聞き方ってものがあるでしょ。。」と思うような場面に出くわすことが少なくないと思います。

本書では、実際に明日から使えそうな問いかけの例文が多々紹介されていました。「ロジカル・ファシリテーション」というタイトルではありますが、ロジカルさはもちろん、問いかけの力という超アナログなスキルも非常に大事だなーと思わされた本でした。

おわり。

社内向けPodcastを50本発信して、変わったこととこれから

こんにちは。スタートアップでエンジニアリングマネージャーをやっている脇田(@kiwatchi1991)です。

入社して1ヶ月ほど経った頃、同僚と酒を飲んでいたときに、「Podcastやろうよ!!!」と盛り上がり、ノリで始めた社内向けのPodcastが、先日ついに50回を迎えました!!!。

基本的に営業日は毎日配信。我ながらよくやった。

発信活動はどんな類のものでも継続が本当に大変です。「音声でのアウトプットを(ほぼ)毎日やってみた」という話はあまり聞かないので、実際やってみて感じたあれこれをまとめてみます。

前提

毎日どんだけしゃべってる?

あまり気合い入れすぎても続かないよね、ということで、1回あたりの収録時間が3〜4分くらいになるようなボリュームにしています。

何しゃべってる?

直近の仕事上でのトピックがメインにはなりますが、読んだ本のアウトプットや、時には自分なりの仕事術的なTipsを生意気(?)にも発信しております。

ただ、50回もやっているとTipsなんて早々にネタ切れしてしまっているので、最近は、直近の仕事の振り返りがメインです。

どこでみんなに知らせている?

弊社は1日の終わりに日報をSlackに投稿する文化があり、日報にその日のPodcastのリンクを貼り付けています。

実際どう?大変?

大変か大変じゃないか、で言ったら、当然だけど大変です笑 でも、大変さを上回るメリットがあると思うから続けられています。

変わったこと

一番は、「自分という人間をより知ってもらえた」ことですね。

今夏のコロナ再流行以来、元々週2ほど出社していたのが現在はフルリモートに近い働き方となっており、コミュニケーションを取る機会はオフライン時と比べるとどうしても減っています。弊社は、社員10数名ほどの小さな会社ですが、全員と毎日仕事上で絡みがあるわけではないので、少しずつお互いの人間性を把握するコストは高まっています。

そんな中、毎日日報代わりにPodcastを発信しているので、「自分が今何を課題に感じていて、何に興味を持っているのか」を、分かってくれている人が増えた気がします。

具体的なところでいうと、僕はアジャイル開発をするうえでは「リソース効率よりもフロー効率重視」と常々発信しています。PodcastやSlackの自分用timesチャンネルも合わせると、「フロー効率」というワードは入社してこの5ヶ月で余裕で100回以上は発言していると思うので、「フロー効率おじさん」としての社内認知は十分に取れた気がします笑

i2key.hateblo.jp

これから

よかったこととして挙げた「自分という人間をより知ってもらえた」と近いものではあるのですが、「(マネージャーとしてメンバーに)自分の考えを伝える」ツールとしても有効活用していけたらと思います(今も既に、そのつもりでやっていたりします)。

先日、ナレッジワーク社の代表・麻野耕司さん@asanokoji が、ご自身が執筆された(スタートアップにおける経営者の振る舞いと見られ方|麻野耕司|note)の中で、スタートアップの経営者のやるべきこととして

● 経営者が取り組むべきこと

実現したい未来、事業の戦略、組織で大切にしたいこと、人材に対して思っていること、あらゆることを丁寧に発信する必要があります。

と仰っていました。

記事では、経営者目線で経営者の取り組むべきこととして紹介されていましたが、一つのチームに目線を向けると、チームのリーダーには同じような姿勢が求められるだろうと、僕は考えています。

同記事の中では、ミドルマネージャーの役割として

ドルマネジャーの役割は経営と現場の意思疎通を適切に促す結節点である

とありました。経営者の考えを、自分の言葉に翻訳してチームメンバーに伝える、それがマネージャーである自分の仕事であると僕は解釈しています。

そのための手段として、Podcastは非常に有用なツールです。

音声は、テキストに比べて熱量や人間味が伝わりやすいコミュニケーションツールです。 音声メディアのVoicyさんでは、「声の社内報」という、社内発信向けのサービスをやっています。「経営レイヤー→メンバー」だけでなく、「メンバーの声を全社に届ける」という使われ方もされていて、「テキストで伝わりきらない会社のカルチャーや空気感が声にのって伝わる」と好評なようです。

note.com

また音声は、テキストに比べて、「発信にかかるコストが少ない」という、発信者にとっての大きなメリットもあります。 テキストであれば、最低限日本語としての体裁を整えないと読むに堪えないものとなりますが、音声であれば多少日本語の文法的に雑でも全然気になりません。

「テキストに比べて発信コストが低く、かつ熱量が伝えられる」、そんなPodcast。もうやらない理由はないですね、、、?!

おわりに

50回続けてみて、大変ではありますがそれ以上のメリットを感じているので、個人的には今後も続けていきたいと思っています。 自分の考えを伝えられるだけでなく、同時に他の人の考えを知ることができるツールでもあるので、他の社内メンバーにも是非やってもらえたら嬉しいと思っています!(みんな見てますか!?)

コミットメッセージに自動でブランチ名を追加した時に詰まったポイント

後々のコミットの検索性を考慮し、コミットメッセージの頭にブランチ名を書くのが好みです。 ただ、手動でブランチ名を毎回入力するのは大変面倒なので、自動でできるようにしちゃいます。

その過程で詰まったポイントがあったので、備忘録として記事にします。

詰まったところ

結論からいうと、「リベースした際、既にコミット済みのコミットメッセージの頭にブランチ名が追加されてしまうのを回避する」のに少し苦労しました。

最終的なコード

先に、最終形態のコードをお見せします。

.git/hooks/prepare-commit-msg

#!/usr/bin/env bash

# コミットメッセージを変数に格納
COMMIT_EDITMSG=$1 

# コミットメッセージの頭に追加する"[ブランチ名]"の文字列を変数に格納
BRANCH_NAME=$(git branch | grep '*' | sed 's/* //')  
INSERTED_BRANCH_NAME=["$BRANCH_NAME"] 

# コミットメッセージの頭に INSERTED_BRANCH_NAME を追加
addBranchName() {
  DESCRIPTION=$(git config branch."$BRANCH_NAME".description)
  echo "$INSERTED_BRANCH_NAME: $(cat $COMMIT_EDITMSG)" > $COMMIT_EDITMSG
  if [ -n "$DESCRIPTION" ] 
  then
     echo "" >> $COMMIT_EDITMSG
     echo $DESCRIPTION >> $COMMIT_EDITMSG
  fi 
}

# マージコミットであるか判定
MERGE_MESSAGE_LINES=$(cat $COMMIT_EDITMSG|grep -i 'merge'|wc -l)
# リベースのコミットであるか判定
REBASE_MESSAGE_LINES=$(cat $COMMIT_EDITMSG|grep -i "rebasing"|wc -l)

# リベースではない&マージコミットではない場合、コミットメッセージの頭にブランチ名を追加する
if [ $REBASE_MESSAGE_LINES -eq 0 ] && [ $MERGE_MESSAGE_LINES -eq 0 ] ; then
  addBranchName
fi

ちなみに、「コミットメッセージにブランチ名を追加する」だけなら、ググると記事も出てくるのでその通りに割と簡単にやればできます。

参考にしたサイト:Gitのブランチ名をコミットメッセージに追加する方法は?

この記事にあるコードをベースに、リベース時に回避する設定を追加した形になります。(シェルスクリプトはほとんど書いたことなく苦手なので、設定を追加するにもまず現状のスクリプトを読み解くのにも非常に苦労しました。。)

ポイント

「リベースのコミットであるかどうか」をどうやって判定するのか?が肝です。通常のコミット・マージコミットと、リベースコミットの違いをみてみます。

コミットの違い

  • 通常のコミット(ブランチ名を追加したい)
  • マージコミット(ブランチ名追加したくない)
  • リベースコミット(ブランチ名追加したくない)

まず、通常のコミットはこんな感じの形式になっています。

 (ここにコミットメッセージを書く)
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# On branch {ブランチ名}
# Changes to be committed:
#       modified:   {ファイル名}
#

次に、マージコミットを見てみます。

Merge branch 'hoge' into fuga
# Please enter a commit message to explain why this merge is necessary,
# especially if it merges an updated upstream into a topic branch.
#
# Lines starting with '#' will be ignored, and an empty message aborts
# the commit.

最後に、リベースコミット( git rebase -i で、r (コミットメッセージの変更)をしたとき)

 (ここにコミットメッセージを書く)
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# Date:      Fri Aug 12 01:15:05 2022 +0900
#
# interactive rebase in progress; onto hoge
# Last commands done (2 commands done):
#    pick hoge
#    reword fuga
# No commands remaining.
# You are currently editing a commit while rebasing branch 'hoge' on 'fuga'.
#
# Changes to be committed:
#       modified:   hogehoge
#

それぞれのコミットで、コメントアウトされている箇所に書いてある内容が違うことが分かるかと思います。この違いを見て、マージコミット・リベースコミットを判定しています。

マージコミットの場合は、mergeの文字列、リベースの場合は、rebasingの文字列が含まれているかどうかを見ます。

# マージコミットであるか判定
MERGE_MESSAGE_LINES=$(cat $COMMIT_EDITMSG|grep -i 'merge'|wc -l)
# リベースのコミットであるか判定
REBASE_MESSAGE_LINES=$(cat $COMMIT_EDITMSG|grep -i "rebasing"|wc -l)

wc -l で、最終的に merge もしくはrebasingの文字列を含むブロックがあるか、ある場合はその行数を取得しています。行数が0なら、マージ(リベース)コミットではないということで、コミットメッセージにブランチ名を追加します。

# リベースではない&マージコミットではない場合、コミットメッセージの頭にブランチ名を追加する
if [ $REBASE_MESSAGE_LINES -eq 0 ] && [ $MERGE_MESSAGE_LINES -eq 0 ] ; then
  addBranchName
fi

ちなみに、マージコミットの判定は参考にした記事にあったコードに書いてあったので、この処理の中身(シェルスクリプト・コミットの仕様)を読み解きながら、リベースコミットの判定を追加する形で進めました。

おわりに

以上です。誰かのお役に立てば幸いです。