0時に寝て5時過ぎに起きた。

事例紹介⌗

いまやっているお仕事の事例紹介の承諾をいただいたので掲載した。感謝。この事例紹介は私の自己満足なところも大きい。世の中に対して自社が貢献しているということを再確認するための手順の1つと捉えている。もちろん複合的に宣伝にもなるので自社にとってメリットもあるが、それ以上に自分に向けて書いているという思いがある。それはこれまで私にとっての、意義のない開発をし経験から、そういうお仕事はしないようにしようという戒めでもある。これまで組織の論理が自分の想いや方向性とズレてしまったときに退職してきたが、業務委託だと契約を終了できるので転職するよりは補正しやすいという側面もある。

ふりかえり⌗

スクラムのふりかえりで pull request のルール適用による成果について共有した。ルール適用前まで pull request のレビューに正社員のレビューを必須としていた。開発チームは協力会社主体であり、正社員は1人しかいなかった。そのため、レビュー負荷がその正社員に集中し、その人が多忙だと pull request のレビューが2-3日停滞するというのが常だった。そこで協力会社の approve でもマージできるような条件を設定したり、そもそも approve を必要としない pull request の条件を追加したり、pull request を作らずに main に直接コミットしてよい内容なども作った。ルール適用の前後で1ヶ月間のチームの平均値を比較した。

その結果、findy teams の pull request の作成からクローズにかかる時間が30%に短縮された。3倍近くクローズが早くなった。私個人の「1プルリクあたりの平均マージ・クローズ時間」においても 14.7h → 4.1h に短縮された。平均で1日待たないと approve をもらえなかったのがその日中にもらえるようになったと言える。ふりかえりで成果を共有したところ、わりと成果の大きさに驚かれたのに私が驚いた。経験が浅いチームの当たり前には価値基準や手順などに乖離があるんだろうなと思えた。私にとっては当たり前のことをやって、当たり前の成果が出て、当然こうなるって話しでしかないのだが、開発を数字でしか把握できない人たちにとっては斬新にみえるのかもしれない。