00:06
4月12日水曜日ですね。
時刻は朝9時9分になりました。
はい、今日はなんか、東京は風がすごく強くてですね。
まあでも天気は良くなりそうだし、
まあ暑くなる日があるかなと思います。
はい、おはようございます。
ユメミのkkeethことくわはわらです。
ではでは、本日の朝活を始めていきたいと思います。
本日はですけども、
今日はちょっと日本語の記事ですね。
ちょっと日本語の記事で読みたいって、面白そうだなと思った記事があったので、
読んでいくんですけど、
入社3ヶ月でプルリク作成数5倍！！さくさくプルリクをマージするメリット
っていうところですね。
をダラダラといつも通り読んでいこうかなと思っております。
まあおそらくファインディーチームプラスを使った記事だと予想はするんですけど、
まあそこの話を読んでいこうかなと思ってます。
はい、レノアさんですね。
おはようございます。ご参加いただきありがとうございます。
じゃあ今からちょっとダラダラと読んでいこうかなと思っております。
では行きましょう。
タイトルになりますね。
こんにちは。ファインディーでソフトエンジニアをしているハムです。
ファインディーの仲の方でした。
9月に開発効率が高いエンジニアを真似することから始める
エンジニア組織の改善サイクルというオンラインイベントで登壇をしました。
この記事ではイベントでお話ししたことのうち、
個人の開発パフォーマンスがどのように変化したのかに
フォーカスをして書いていきたいと思います。
この記事で話すことですけど、
入社3ヶ月でプルリクの作成数が5倍になった理由、
プルリクを分割してサクサクマージするメリット、
そしてプルリクをサクサクマージできる開発組織とはどうなるでしょうか?
というところでお話しですね。
3本構成になっているという話でした。
ではドヤは本題に入っていきたいと思います。
スーさんがご参加いただきありがとうございます。
今からダラダラ読んでいきます。
じゃあまず一つ目ですね。
入社3ヶ月でプルリク作成数が5倍になりましたよというお話からです。
ファインディーの仲の方でファインディーチームプラスを
カプチャーとかばんばん貼ってあるんですけど、
5月と8月ですね。
ゲーム制度は2022年の5月1日から5月31日と
2022年の8月1日か8月31日の2つのグラフが今貼られていて、
それぞれプルリクの作成数の比較をされていました。
こちらのグラフは入社月5月と3ヶ月後8月の
この筆者の方のプルリク作成数を比較したものですけど、
パッと見ただけでもプルリクの作成数が本当にめちゃめちゃ増してるんですよね。
前回5月の頃のものでいくと平均、
結局1日1個ぐらいが結構限界だったっぽいんですけども、
8月になると1日多い時はもう7個ぐらいプルリク作ってますね。
だいたい平均すると4ぐらいは作れてるよってところです。
もう全然変わりましたね。
実際に月間プルリクの作成数は5月で14件しかなかったんですけど、
8月で85件です。
ということで3ヶ月で5倍以上になりましたよってことです。
03:00
なので1日1件作れてない日もあったってことですね、5月は。
なんですけど、8月で85件というところで、
20日働くとしても1日4件ですねやっぱりっていうところですごい爆発的に増えましたね。
プルリクの数が増えるとじゃあ何が嬉しいのかってところなんですけども、
誤解なきように先にコメントしておくと、
プルリクの作成の数が5倍になった、
イコール生産性が5倍になったというわけではありませんというところは先に補足しておきます。
生産性を5倍にするにはプルリクの大きさを変えずに数を5倍にすることが必要になります。
そりゃそうだよね。
けど今回は1つのプルリクでやっていたことを分割することでプルリクの数が5倍になったという話ですね。
単純に今までのデカい1つのドーンといったプルリクで全部自走していたものを
5分割に分けて小さく小さく作成、マージ、作成、マージというところに分けたという話ですね。
これを分けたらどういうメリットがあるかという話が次に続くんですけど、
こちらがAPI予進機作成するときのプルリクを図にしたようなものでして、
1つのプルリクを例えば5個に分けたとします。
5個に分けた最後の5つ目のプルリクがマージされたときに初めてそのAPIが叩けるようになるというような感じですね。
前者はそのAPIが使えるまで1つの実装のプルリクでパッと作っているみたいな図があるんですけど。
後者を5分割したんですけど、例えばまず5分割の1つ目は入力値を変換する処理を実装してマージしました。
2つ目はレスポンスで使うデータ生成処理というところだけを実装してマージしました。
3つ目はその生成したデータをレスポンス用に成形する処理ですね。
そこだけを生成してマージ。
4つ目はそのAPIの認証を実装した。
で、マージ。
最後はAPIのルーティングを実装して叩けるようにしたというところでマージを繰り返したという5個をやりましたというところですね。
で、で、で。
ぶっちゃけこの図を見ると1発のプルリクで作ろうか、5個に分けようか、結局どっちも同じです。
最終的な過程もそうですし、作る流れもそうですし、マージする流れは結局一緒なんですけど、
そのマージをするごとにレビューするから、むしろレビューの数は5倍に増えます。
そりゃそうだよね。
1つのプルリクで1回レビューすればよかったのに、その1つのプルリクを5分割に分けたことによってレビューの回数が5個に増えます。
なのでレビュー数5倍じゃんっていう声はもちろん聞こえてくるでしょうし、おっしゃる通りだと思います。
APIが使えるようになるまでのそのトータルの時間ですね。
ぶっちゃけ言うとあんまり意味はないと言ってます。
ただですね、実際にプルリクを分割して開発してみるとですね、
その1つ1つのプルリクへのマージの時間が早くなったというところを言ってます。
つまりトータル的に言うと1つのプルリクで実装してマージするまでよりも、
それを5分割にした方がトータル時間が短くなったというふうにこの秘書の方はおっしゃられています。
じゃあなぜそのトータル時間が短縮できるのかってとこなんですけど、
いくつか要因はありますが1つ目です。
実装者の認知負荷が減るっていうところがまず1つ大きいと言ってます。
プルリクをマージするまでの間、実装者はそのプルリクのすべての変更に責任を持つ必要があります。
プルリクの変更業数ですね。
プルリクがマージされるまでは実装者のコードであり、
変更内容を把握したり、バグを修正したり、レビュー指摘を修正したり、ベースブランチの変更を取り込んだり、
06:04
プルリクを正しい状態にする責任は実装者が持っています。
そりゃそうだよね。マージ前なんで。
プルリクの変更業数っていうのがレビューで承認されて、
ベースブランチにマージしたらみんなのコードにやっとなります。
みんなのコードはチームメンバー全員でメンテナンスするコードになります。
もし一つのプルリクで全てを実装していた場合は、
当然変更業数とか変更業そのものが膨大になります。
変更の業が多ければ大きいほど、実装者の認知負荷というのはもちろん上がりますし、
プルリクを正しい状態に保つための作業というのは結構煩雑になり、時間がかかるようになります。
一方でプルリクを細かく小さくすることで、
実装者が責任を持つ変更業というのは減らすことができて、
プルリクを正しい状態に保つことにかける時間というのも短くなります。
というのがまず一つ目の要因です。
続いて二つ目ですけども、二つ目はやっぱりレビュー速度がアップというところですね。
皆さんここが多分そうだろうなというふうに予想はつきますけど、
レビューする方ならわかると思いますが、
プルリクの変更業数が増えるとレビューにかかる時間は指数関数的に増加します。
多分、あれですよね。線形的に増えていくわけではないと思います。
僕も感覚はありますけど、感覚値でいくと指数関数的に増えるなと思いますね。
1000行変更したプルリク1つよりは200行変更したプルリク5つの方が、
やっぱり後者の方がレビュー時間が短くなるとは、僕もそう思いますね。
やっぱりそのレビューのサイクルが早く回るというところですからね。
またレビュー速度と直接関係はないですけど、
変更業数が多いとレビューにかかる認知負荷も上がるため、
レビュー精度も下がっていくという負荷的な懸念が発生すると。
レビュー精度が下がることでバグをレビューで検出できない確率も高まって、
バグ対応なので間接的に時間を消費してしまうことにつながります。
結果的には後で失う時間が増えていくということですよね。
ちなみに私が所属している開発チームの過去3ヶ月の1プルリクあたりの変更業数を確認したところ、
約200行でした。これすごいですね。
3ヶ月でプルリク変更業数、平均とったら200行ぐらいに収まってるんですね。
これはすごいと思いますよ。
もちろんそのバックエンドフロントエンドとか、
どこのソースコードによるかもしれないし、
開発の内容によるきりだと思いますけど、
でも3ヶ月で変更を取って200行に収まっているというのはなかなか素晴らしいと思います。
この結果、やっぱりプルリクはサクサクレビューできるし、
サクサクレビューされているということだそうですね。
また私の8月のレビュー数は175件でした。
これ、この人ちゃんとレビューもしつつ開発もしていて、
それだけの実績を作ったと。
1日あたり約7件レビューしていることになります。
それでも私は8月前日の通り85件プルリクも作成しています。
1ヶ月で85件プルリクを作って、つまり1日平均4件プルリクが作っているし、
1日平均7件のプルリクのレビューもしているというので、
これはサイクル的にはすごいですね。
レビューで圧迫されて開発工数が落ちていないということの詳細にもなります。
作っているプロダクトの規模感にもよるという話は全然あると思うんですけど、
それでもこれだけの件数をプルリクを作っているということは、
09:00
結構機能は多かったりとか規模感は大きいんじゃないかなと思ったりするので、
いやーこれすごいですね。
平均4件のプルリクと平均7件のレビューを1ヶ月続けたということですよね。
いやーこれは参考になりますね。
続いての話です。
今のはレビューの負荷が下がる、レビュー速度がアップするというのが2つ目の要因でした。
3つ目は手戻りが減るというところですね。
基本的には1つのプルリクでやろうとしている変更が全て終わった後にレビューしてもらうともちろん終わります。
レビューで全体に影響する指摘があった場合、
変更行数が大ければ大きいほど手戻りがもちろん増えてしまいますが、
変更行数が少ない場合は全体に影響する指摘があっても影響は少なく済みます。
プルリクを小さくすることで変更行数が少ない状態でレビューしてもらえるので、
常に手戻りが少ない状態で実装を進めることもできます。
これは本当にその通りだった感じですね。
ラスト、コンフリクトが減るというところです。
プルリクの変更行数が増えるともちろん生存期間も長くなってしまいます。
マージまでの時間が長くなるので。
変更行数が多く生存期間が長くなると
ベースブランチからの返りがどんどん大きくなり
コンフリクトが発生する可能性も高まります。
これはチームのベロシティとか
開発の速度、頻度ですね。
マージの頻度がどれくらいかによって
ベースブランチからの返りの大きさというのは変わりますけど、
この会社さんは結構頻度が高そうには見えるので、
確かにベースブランチの返りがどんどん大きくなる可能性は高まりますよね。
コンフリクトの修正は変更行数が多いほど辛い作業になる。
コンフリクト解消に使う時間もどんどん長くなります。
一方、変更行数を少なくして生存期間を短くすることで
コンフリクトする可能性をほぼゼロにすることができます。
コンフリクトない世界はとても快適です。
そうなんだよね。
コンフリクトって本当にただただコストを使うだけに過ぎないので
できればゼロにしたいですよね。
はい、というところでした。
続いて、別で行われたコンフリクトを
コンフリクト解消に使う時間もどんどん長くなります。
一方、変更行数を少なくして生存期間を短くすることで
続いて、別で行われた変更を取り込む手間も省けますよ。
メリットばかりだな。
チーム開発をしている場合、複数の開発がもちろん並行していると思います。
その中には、ライブラリのバージョンアップや
全体に関わるリファクタリングが行われることもたまにあります。
一つのプロジェクトで作業を続けている場合、
別で行われた全体的な変更を
作業中のプロジェクトに自分で反映する必要もあります。
一方、細かくベースブランチにマージしておくことで
マージ済みの変更というのは
別で行われる全体的な変更の対象となるので
自分でやる必要はもちろんなくなりますよね。
はいはい、本当その通りだなって感じですね。
メリットラストですけど、
本番障害時の原因特定がやっぱり早い。
開発していると本番障害を起こしてしまうこともたまにはあります。
発生した場合、リリースしたプロジェクトの変更要素が多いと
障害箇所を見つけるのにやっぱり時間がかかってしまいます。
これはプロダクトのソースコードの量にもよる気はしますけど
だいたいコミットを追うことがよくある話なので
確かに変更要素が多いと大変だって感じがしますね。
変更要素が多い場合は
1回のリリースで複数の不具合を埋め込んでしまう可能性も高くなります。
12:00
少しずつマージしてリリースしている場合は
1回のリリースでの変更要素が少ないので
複数の障害を同時に埋め込む可能性というのは低くなり
障害のゲイン特定にかかる時間も短くなります。
はい、これはあれですね。
冒頭にいくつかあったメリットの一つにありましたけど
そもそものレビュアの認知負荷も下がるので
なるべくチェックするときのレビューの精度が下がらないというのも
セットにくっついてくるなと思いましたね。
今のがプルリクトータル時間がなぜ短縮できるのかというところの分析というか
この辺じゃないのというお話でした。
では続いてプルリクをサクサクマージできる開発組織とはというところですね。
ここまではプルリクを分割して細かくマージしていくことのメリットを紹介していましたが
ここではそれを実現するための開発組織について語っていきたいと思います。
1つ目には自動テストやリントなどのCIを充実させましょう。
プルリクを細かくマージするにはやはり自動テストやリントなどのCIを充実させることは必須になってきます。
リントなど静的なコード解析がない場合コードレビューで機械的に判別できる指摘が増えて
レビュー時間が延びてしまいます。
自動テストがないと少しの変更でも既存影響の有無がわからないため
マージするために手動でテストをしていく必要がある。
サクサクマージするがもちろん困難になります。
これはもうほぼ現代のモダンな開発環境ではマストですよね。
続いて開発フローが簡素化もしくは自動化されている
さっきのちょっとひもづく気はしますけど
プルリクの数を増やす場合同じ開発フローのままでも
気合で数を増やすことは一応できます。
ただ今まで月1回のサイクルで回していた開発フローを
週1回にしたり週1回で回していた開発フローを1日1回にするなど
大幅に短縮すると今までは手動でも気にならなかった作業でも
やっぱり実施回数が増えることで高負荷になることはあります。
まずは回数が増えることで負荷が高くなる作業を自動化するなどして
一つずつ潰していき、少しずつフロー全体を高速にしていきましょう。
続いてチーム全員で同じ意識を持つというところですね。
プルリクを細かくマージしていくには
同じペースでレビューしてくれるレビュアの存在も欠かせません。
これも本当そうですよね。
作ったけど皆さん開発してるから
皆さん全然レビューしてくれないってなったら結果的には遅いですからね。
そのためチームで一人だけプルリクを細かくしようとしても
他の方も同じように考えていないとレビューが遅くなり
最終的にはレビューのペースに合わせたプルリクサイズになってしまいます。
レビューが1日1回だったらプルリクも1日1回になってしまいますよねってことです。
それはそうだよね。
基本的には遅い方に収束していくことが多いので
実施する場合はチームで意識を合わせるようにしましょう。
これは組織論の話なんですけど
どんな組織もマイナスというか末端なところにやっぱり引っ張られるんですよね。
なのでなるべく組織っていうのは基準とか目標が高いところに合わせて
そこにみんなが合わせていくようにしないと
基本的に組織は我解していくっていうのは
よくある話なので
これは同じことがここでも生かされるなってところですね。
なので遅い方に収束してしまうので遅いところに合わせる。
ではなくてちゃんとレビューを早く回すとか
プルリクの数を増やすとかっていうところに
皆さんで意識を合わせましょうってところですね。
プロジェクト最初の時とかそういう方針に変えますよって時に
みんなでちゃんと合意を取っていくっていうのは
15:01
すごく大事なことだと思いますので
ここは時間をしっかりとったほうがいいなと思いました。
続いて途中のコードがベースブランチに回されることを許容するですね。
一つの機能開発でもプルリクを細かくマージしていくために
まだ本番では使われないコードや中途半端なコードとか
QAなどのテストが不十分なコードっていうのが
ベースブランチにマージされることになります。
中途半端といってもユーザーに提供できる状態になっていない
っていうだけであって
ちゃんとテストとかリントっていうのはクリアしている前提です。
開発現場によってはこのような中途半端なコードが
ベースブランチに入ることを許可しないところも多いと思っています。
ただ既存には影響されないように実装されているのであれば
ベースブランチにマージしても問題はないはずです。
前述したメリットももちろん享受できるので
既存に影響がない場合はガンガンマージしていく文化っていうのが
広がるといいなっていうふうに思っていますというところでした。
ではラスト、最後にですけど最後まで読んでいただきありがとうございますと
ファインティーでは開発者体験の最大化に積極的に取り組んでいますというところで
興味ある人はDMくださいとかカジュアル面談とかやってますので
お聞かせくださいっていうのと
それを可視化するためのツールとして
ファインディーチームプラスというものがあります。
いわゆるフォーキーズっていうところを実現するための可視化ツールというところで
そういうサービスも運営してますので
よければ見てみてくださいっていうことでした。
はい、ちょっと短かったですけどいかがだったでしょうか。
単純にこの一朝のプロジェクトの作成の数っていうのを5倍にしてみたけど
単純に5倍にしただけでコストかかったのかっていうよりむしろ時間を短く
つまり開発のリードタイムが短くなったっていう風に言ってますね、トータルでは。
これはとても良い文化でありますし
皆さんでそういうサイクルを早めるっていう意識が高まったのがすごく良い話だと思っているので
これはぜひぜひ取り入れたいし
自分たちでも何か試してみたい感じがありますね。
ただ一方で今の開発メンバーたちのプロジェクトを作るバリューだったりとか
そのスキルレベルだったりとか
高数の割当とかいろんなものがあるので
チームの今の現状を加味した上で決めていくのはいいと思うんですけど
でも先にやるのはまず最初なんですかね。
エイヤーでプルリクの作成の数を一日何個にするっていう
結構エイヤーで決めていくのは一つはありかもしれないですね。
ちょっとドラスティックで
なんでっていうとご説明席にも問われるかもしれないですけど
っていうのでやっていくといいと思います。
プルリクの作成の数は例えば一日3件みんなマストにしましょうとか
プルリク一日の業務終わるときには
GitHubのリポジトリのプルリクがノータッチのまま終わるんじゃなくて
必ずレビューだけはしている
一回が見たよっていうところまでしてから業務終わるっていうようなルールに
チームのルールにすると必然的にプルリクの小ささとか
サイズを分割していく形になっていくと思いますので
結果この記者の方と同じような環境に近づけるんじゃないかな
というふうにちょっと読んで思いました。
良し悪しはありますし、はまらないケースももちろんあると思います。
そしてスペック高いエンジニアたちのチームであれば
別にプルリク一つ良くないっていうのもそれは全然アリだと思います。
それでしっかりベロシティ上がってるんであればいいとは思ってますので
一応参考としてこれをやってみるんじゃないかなとも言いました。
はい、というところで今日の朝活はここで短いですけどね
以上にしていきたいと思います。
本日はですね、レノアさんと、ちょっと何て読むか分からないんですけど
18:00
ひろどうさんですかね。
ご参加いただきありがとうございます。
また明日もなんかのんびりと記事見つけてゆっくり読んでいこうかなと思ってますので
興味あれば参加してみてください。
すいません、オンラインで見えてないんですけどおそらくスーさんですね。
ご参加いただきありがとうございます。
今日水曜日ですね、中日ですけど1日頑張っていけたらなと思います。
じゃあ終了します。お疲れ様でした。
