【はてな×ZOZO】プルリクエスト分割が開発生産性向上のカギ？〜エンジニアチーム全体で改善を推進〜
2023年3月17日、ファインディ株式会社が主催するイベント「【はてな×ZOZO】プルリクエスト分割が開発生産性向上のカギ？〜エンジニアチーム全体で改善を推進〜」がオンラインにて開催されました。
ファインディでは、エンジニア組織支援クラウド「Findy Team+(チームプラス)」をリリースし、エンジニア組織づくりや生産性の可視化を通じたパフォーマンスの最大化支援に取り組んでいます。
昨今、開発生産性を定量化する指標として、GoogleのDevOps Research and Assessment（DORA）チームが提唱した“Four Keys”指標がトレンドになりつつあり、開発生産性の維持や向上をミッションに掲げ、取り組みを進める組織が増えています。
一方で、現時点では開発生産性の可視化に留まってしまうことも多く、生産性向上につなげるための施策が見いだせないケースや、施策に取り組んだものの効果創出まで到達しきれないケースなども多く聞かれます。
そこで、今回のイベントでは、株式会社はてなにてWebアプリケーションエンジニアを務める五十嵐さんと、株式会社ZOZOにてフロントエンド部ディレクター、兼WEAR Androidブロック長を務める御立田さんをお招きし、開発生産性の可視化から向上への先進的な事例として、取り組みにおける課題やアプローチ、チーム状況の変遷について、パネルディスカッション形式でお話いただきました。
■登壇者プロフィール
株式会社はてな Webアプリケーションエンジニア 五十嵐 雄さん 2019年4月に株式会社はてなに新卒入社。はてなブックマークチームでスクラムマスター、テックリードを務めた後、現在は同チームでメンバーのメンタリング等を含めたエンジニアリングマネジメントで開発を牽引。テクノロジー、デリバリー、ピープルなど複数領域に関心を持ち、幅広い手段でチームを改善することを志向している。
株式会社ZOZO フロントエンド部ディレクター、兼WEAR Androidブロック長 御立田 悠さん 2012年株式会社ZOZO（旧株式会社スタートトゥデイ）に新卒入社。ZOZOTOWN開発チームで企画案件を担当。翌年よりWEAR事業立ち上げに従事。2017年よりAndroidエンジニアとしてフリーランスを経て、2021年株式会社ZOZOに再入社。現在はブランドソリューション開発本部フロントエンド部ディレクターとして「WEAR」「FAANS」のフロントエンド領域でマネジメントを行う。
※本イベントのアーカイブ配信（無料）はこちら
目次
登壇者の自己紹介と、両社の開発チームにおけるミッション
──まず最初に、お二方の自己紹介からお願いします。
五十嵐：株式会社はてなでWebアプリケーションエンジニアをしている、五十嵐と申します。2019年からはてなでエンジニアをしていて、はてなブックマークチームで、スクラムマスターやテックリードなどを務めていました。現在はチームメンバーのメンタリングなども含めた、いわゆるエンジニアリングマネージャーのような立場で開発を牽引しています。
テクノロジーだけではなく、デリバリーやピープルマネジメントなど、プロダクト開発を形づくるさまざまな領域に関心を持っていて、幅広い手段でプロダクト全体を前に進めようという気持ちでやっております。本日はよろしくお願いします。
御立田：株式会社ZOZOの御立田と申します。フロントエンド部のディレクター兼WEAR Androidブロック長をしています。
経歴としては、2012年に旧スタートトゥデイ（現在のZOZO）に新卒入社して、最初はZOZOTOWN開発チームで企画案件などを担当していました。翌年、WEARというファッションコーディネートアプリのサービスを立ち上げるタイミングで異動し、最初はバックエンド、途中からAndroidエンジニアをしていました。2017年に一度会社を退職して、フリーランスになったのですが、全国在宅勤務という制度が導入された2021年に再入社しています。
現在はブランドソリューション開発本部という、WEARやショップスタッフの販売サポートツールFAANSなどのBtoB事業を扱う本部のフロントエンド部で、ディレクター（部長職）という立場でいろいろなマネジメントをしています。よろしくお願いします。
──本日はパネルディスカッションのアジェンダとして、大きく4つのテーマを用意しております。本日はよろしくお願いいたします。
──それではさっそく、両社の開発チームの体制やミッションからお伺いできればと思います。
御立田：開発チームとしては、すごくシンプルに「生産性を3倍にしよう」という目標を打ち立てました。この目標に向けて、具体的にどう進めていくのかを落とし込むにあたって、やはりデプロイ頻度が多い組織というのはハイパフォーマンスであると考えました。
チームには、アプリやWeb、バックエンドなどさまざまなエンジニアがいるなかで、全体を通して使えそうな指標として、まずは「プルリクエストのマージ数」と、「プルリクエストの平均マージ時間を24時間以内にする」というミッションを掲げて進めました。
五十嵐：はてなブックマークというサービスでは、中期的にアクティブユーザーを増やしていくことを目標としています。そこに向けて、4年前くらいに大きなシステムリプレースがあり、素早く変更を加えられるようになりました。
その次の段階として、プロセスや思想的な部分をしっかりアジャイルの方に向けていき、小さくインパクトが出るようにモノを作っていこうという形で、現在プロダクト開発を進めています。
開発生産性について、取り組みを始めたときの状況は？
──続いて、開発生産性の可視化や向上に関して、取り組みを始めたときの状況について、それぞれお伺いしたいと思います。
五十嵐：開発生産性に関しては、わりと長くやってきていて、アジャイルにやろうとか、スクラムをやろうというときにも、生産性はずっとチームで意識してきていました。デュアルトラックアジャイルのような仮説検証を試行するときも、やはりフロー効率のところではリードタイムをより短く、デプロイ頻度を増やす、という意識はあったかなと思いますね。
チームでも、そういったことをボトムアップでやっていく意識があった上で、CTOから、「会社としてもデプロイ頻度を上げて、デリバリー能力を高めていこう」という話がありました。そこで、可視化ツールとして「Findy Team+」を導入した結果、さらに生産性がよく見えるようになった、という形で開発生産性への向き合い方が進んでいきました。
──CTOの方からデプロイ頻度など、開発生産性に関するお話が出たときに、現場の方々の反応はいかがでしたか？
五十嵐：はてなは形態の違う事業をいろいろやっていることもあり、各事業でマインドが違っていたりします。私が所属するはてなブックマークチームは、アジャイルにやっていくというマインドがより強いチームだったため、やるのは当然という印象でした。
一方で、そこまで興味を持っていないというか、事業としてはまだ重要ではないと受け取られる場合もあるなど、チームによって受け取り方は様々だった印象ですね。
──御立田さんからも、取り組みを始めたときの状況についてお願いします。
御立田：取り組みを始める前に、そもそも弊社では「Findy Team+」の前身にあたる「Findy Teams」を導入していました。ただ、当時自分はそういったことにアプローチする立場ではなかったため、権限的にも見ることはできず、そういうものがあるということだけ聞いていました。
その後、自分が関わるようになったタイミングで、「Findy Team+」の数値を眺めだしたのが最初のきっかけですね。最初は数値を眺めていても、その数字の良し悪しがわかりませんでしたが、一般的に目指すべき数値と比較してみると、全然ダメだということがわかってきました。そこから、「なぜこの数値になっているのか？」「課題を追わなければ！」という状況になりました。
──レビューやデプロイの遅さなど、明確な課題を感じて見始めたわけではなく、まず数値を見てみるところから始まったのでしょうか？
御立田：課題感がまったくなかったわけではなく、チームメンバーも肌感としては遅いなと感じていた部分もありました。ただ、チーム内で完結していて比較対象がなかったため、なんとなく「もうちょっと早かったらいいな」くらいにしか思えていない状況でしたね。
プルリクを小さく分割することが、さまざまなメリットを生む
──続いて、取り組みを進められていくなかで直面した課題や、それに対してどうアプローチされたかについてお聞きしていきたいと思います。
御立田：まずは、課題に気づけていないことが課題だったので、数値を見て遅いことがわかったタイミングで、何が課題になっているのか、改善できるポイントがないかについて、チーム全体で意識づけるところからスタートしました。
生産性を上げるためには、プルリクを分割していくといった動きになると思うのですが、経験上なにか一つやれば大きく変わるような施策はなく、チーム毎の細かな取り組みの積み重ねで、だんだん改善していくものだと考えています。
そのため、一つ課題を解決したら、また新たな課題が見えてきて、それを一つひとつ解決していくというアプローチでやっていきました。そのため、壁が大きくて大変だったという印象はなく、取り組めることを徐々にやってきたという感じですね。
──プルリクを小さくしていくにあたって、考え方が浸透していないと「小さく作っても数が増えるだけでは？」という話になってしまう場合もあると思います。そのあたりはいかがでしたか？
御立田：私のチームでは特に反発する声はなかったです。しかし、会社全体で見ると、やはりそういう意見も出てきていました。それに関して、プルリクを小さくすることのメリットは、もちろん早くなることにありますが、修正の舵が切りやすくなるところが大きいと考えています。
例えば、1つの大きなプルリクと、中身が同じ5つに分かれているプルリクがあったときに、細かく分かれているプルリクであれば、1プルリク当たりのコード量が少ないため、レビューする側も楽ですし、レビューされた側も指摘に対してのレスポンスが早くなります。また、万が一思っていた方向性と異なる実装をしてしまった場合にも、その段階で舵を修正することができるんですね。
それを飛ばして、大きなプルリクから一気に最終的なものとして出されてしまうと、修正にすごく時間がかかってしまいます。そのため、これがプルリクを小さくする一番のメリットだと自分は感じていますね。このことを説明をすると、納得してくれるメンバーが多いです。
五十嵐：プルリクを小さくすることは、他にもたくさんメリットがあると思っています。そもそも、プルリクを小さくするには、全体が見えたうえで、自分の作業を分解できている必要があると思います。そのため、チームでも本人でも、まずは計画するという段階が入ってくることも、すごくいいなと思っています。
また、小さくした状態でマージしていいと言われるには、結構テクニックがいると思っています。全部書いてしまうと、テストがなくても一気通貫で動いているからOKと言えてしまいますが、小さくしてビジネスロジックだけ書いたときに、それをアプルーブするには、テストで動作が確認できていないと通せないため、品質の向上にもつながると感じますね。
【ZOZO】Jiraのサブタスク機能を活用し、チケットを分割
──ここからは両社の取り組みを、「Findy Team+」のデータから振り返っていきたいと思います。まず御立田さんのチームでは、サイクルタイム全体の時間が、取り組みの前後で約340時間から約85時間まで短縮されています。リードタイム改善のために、どのような取り組みをされましたか？
御立田：サイクルタイムの4つの指標の中で、一番左にある「コミットからオープンまでの平均時間」と、それ以降では少し毛色が違うと考えています。「コミットからオープンまでの平均時間」は、もちろん仕組みで解決する部分もありますが、それ以上にエンジニアの力量が問われる部分でもあるので、そこは他に比べて時間がかかる傾向があるのかなと思います。
取り組んできた内容については、細かいことがたくさんあるので、詳細についてはぜひテックブログ（※）をご覧ください。そのなかでも特に大きかったのは、うちのチームでは案件管理にJiraを使っているのですが、Jiraの中で案件のチケットを分割していったところですね。
見積もりの時点では、開発者がコードレベルで、あるクラス、またはビジネスロジックだけ切り出すというのは、少し見通しづらい部分があります。そこで、Jiraのサブタスクという機能を使うと、実際にチケットを開始した後に、そのチケットを親にして、サブタスクをぶら下げることができるんですよ。
それを使って、例えばユースケースを切り出すとか、エンジニアが見ないとわからないようなレベルでサブタスクを切っていって、親のチケットにサブタスクを入れていくようにしていきました。この運用を始めてから、エンジニアがコミットするところの意識も変わっていきましたね。
適当なコミットをしてしまうとサブタスクも上手く分けられないので、先ほど五十嵐さんが言っていたように、全体を見通さないとできない部分があるんです。その恩恵もあり、徐々にメンバーの意識も高まっていったことが、一番大きかったと思います。
※ZOZO TECH BLOG：運用改善によるチームパフォーマンス向上のための取り組み（2022年9月30日）
【はてな】自分の開発よりレビューが優先という“鉄の掟”
──続いて、五十嵐さんのチームです。上の図は、折れ線グラフが稼働人数、棒グラフが稼働人数当たりのプルリク作成数で、1人当たりのアウトプット量は約2倍に増えています。下の図は、折れ線グラフがレビューのリードタイムで約1/3に、棒グラフがチーム全体のプルリク作成数で約4倍になっています。データをご覧になっていかがでしょうか？
五十嵐：一番すごいのは、下のグラフにあるレビューのリードタイムの下がり方だと思います。移動平均を取っているので、これでも穏やかになっています。
もともと「Findy Team+」を導入し始めた段階では、自分たちは結構ちゃんとやれているつもりでした。プルリクは24時間以内にマージされると良いということは、みんな知っていましたし、それができているつもりだったんですが、実際の数値を見てみると思ったより時間がかかっていたという状況でした。
チームではこれまでの経緯もあって、botを使って非同期なレビューアサインをしていましたが、この数値についてチームで話したところ、「フロー効率を求めているのだから、レビューがきたらその場でやれば良い！」という話が出てきました。そこで、その日からGitHubのアサイン機能でレビューを当てることにしました。
それから、チームのルール集に“鉄の掟”として、「レビューは自分の開発より優先」と書いて、みんなで合意を取ったんです。そのため、このグラフも本当はおそらく移動平均の真ん中ぐらいに崖があると思います。そこでレビューのリードタイムが大きく下がった感じがしますね。
──「レビューは自分の開発よりも優先」というルールを伝えたときに、メンバーの方から反発などはありませんでしたか？
五十嵐：こちらから伝えたというよりは、振り返りでチームから出てきた内容だったので、特に苦労はありませんでした。だいぶうまい話だなとは思いますが（笑）。
御立田：すごいですね。その“鉄の掟”が破られることはないんですか？
五十嵐：緩やかに破られることはありますよ（笑）。あくまで気持ちとしては、みんなレビューが優先だとしている感じですね。
御立田：そうしたいという気持ちはありつつも、実際に自分の開発よりレビューを優先するのはなかなか難しいことなので、本当にすごいなと思います。
改善を進めるなかで、開発者体験が向上していくことを実感
──続いて、チームメンバーの意識や行動の変化についてお伺いしたいと思います。特に、開発生産性を可視化することに対して、現場の方からネガティブな反応が上がるケースもあるようなのですが、いかがでしたか？
御立田：最初に、「Findy Team+」を使って可視化できるようになるという話をしたときには、「監視されるのか」「その数値を見て注意されるのか」というように、一部ではありますがネガティブな方向に捉えられてしまうこともありました。
実際は全然そういうものではなく、何が無駄になっているのかを見つけるためのツールに過ぎないと、アプローチしていきました。改善を進めるなかで、体験そのものが変わっていったので、毎週メンバーに数値を見せて「良くなったよね」と確認したりはしていません。
レビューを出すときに、レビュアーにとってやりやすい環境を作っていくことで、自分自身が楽になっていくことが、みんなすごく実感できていたと思います。その結果、「もっとこうしたら楽になるんじゃないか」と、課題を前向きに捉えてくれるような変化があったと感じます。
──五十嵐さんはいかがでしたか？
五十嵐：私のチームでは、先ほどお話ししたように、取り組み前からのメンバーの貢献もあって、もともと生産性に対する意識がすごくありました。そのため、一般的に起こりそうなハレーションは、全然なかったですね。
可視化したことで何か大きく変わったことはなく、シンプルに道具を1つ手に入れた感じです。エンジニアは可視化が大好きなので、グラフを見て楽しんで、さらに改善に取り組むということはあったと思います。
──どの指標を追っていくべきかということを、気にされる方もいるかと思います。今追っている指標については、どのように考えられていますか？
五十嵐：基本的に生産性を考えたときに、まずはアウトプットに着目することになると思います。今は既に決定版としてFour Keysがあるので、そこが中心になってくると思います。
そのサブ指標のようなものとして、レビューのリードタイムやプルリク数などがあるイメージです。それらがすごくアプローチしやすいところなので、そこから取り組んでいくと上の指標も良くなっていくだろう、という形で取り組んでいます。
一方で、最近直面しているのは「アウトプットを改善しただけで事業が良くなったら誰も苦労しない」みたいなところですね。実はアウトプットを減らしてでも、しっかりと作るものについて話す時間を取った方が、より成果が上がるんじゃないかとか、生産性に関する視座が一段上がったことで、また少しチームの動きが変わってきた感じがありますね。
最後は、来場者からの質問に答えるQ＆Aタイムへ
──ここからはQ＆Aとして、参加者の方からの質問にも回答いただければと思います。まずは、「今チームの人数は何人くらいですか？」との質問です。
五十嵐：プランナー、デザイナー、アプリ、Webなど全職種を含めると、15人程度です。その中で、Webエンジニアは現在5人ですね。レビューなどに関するお話は、その5人のグループでの話です。
御立田：例としてお話していたのはAndroidチームの内容で、そのチームは6名ほどです。事業部としては他のブロックもあって、全体でいうと20数名です。
──プルリクの分割について、「具体的にこうやって分割している、という例をお伺いしたいです」とのことですが、いかがでしょうか？
御立田：そのプルリク自体をマージして大丈夫な状態か、そのプルリクを1つ入れた状態でリリースできるか、というのがまず一つの基準かなと思います。ただ、それだと分割できる粒度に限界があるので、さらに分割するために、Jiraのサブタスクを利用しているという形ですね。
──続いて、「小さくリリースすることができない壁にぶつかったとき、それをどう乗り越えましたか？」という質問です。
五十嵐：小さくリリースできない場合、いろんなレイヤーで壁があると思っています。一つは、一番上のビジネスのところですね。一切ユーザーに見せずに、半年規模のものを出したいという要望が降ってくるとか、そういったやり方もあると思いますが、もし小さく出したい、アジャイルにやりたいと思っているのに、そういう話が降りてくるとしたら、それは組織の課題かなと思います。
それをクリアしても、次は開発の方にも壁があって、小さく出すためのテクニックを知らない場合があると思います。例えば、HTMLを生成するところまでやって、最後にそれをdisplay noneで隠すとか、簡単なことでもそういう発想がないと全部作り切らなければ出せないと考えてしまうのかなと思います。そういうちょっとしたテクニックを授けるだけでも、進んだりすると思いますね。
──「増えたプルリクを素早く回せる仕組み、特にCI面での工夫ポイント」が知りたいとのことですが、こちらはいかがでしょうか？
御立田：CIに限って言うと、そこまでないかなと思っています。すごく細かいことですが、例えばGitHubでプルリクの一覧を出したときに、そこでどのプルリクがアプルーブをもらっているのか、パッと見てわかるようにするなどですね。
チームによって、アプルーブが何件ついたらOKというルールがあると思うんですけど、私のチームでは自動でアサインされて、2名アプルーブがついたらマージしてOKというルールにしています。2名からLGTMが来たタイミングでCIを回して、LGTMのラベルを付けて、一覧でパッと見てどれがOKな状態なのかわかるようにするなど、本当にそういう細かいところをいろいろやっていますね。
あとは、Androidチームで言うと、アプリ開発で定期的なリリースになっているので、マイルストーンで「このプルリクはどこのバージョンに向けて入れるもの」と一覧で見れるようにしていたりもします。そういった形で、都度考えることなく、見た瞬間に情報が入ってくる状態を目指すために、細かな取り組みをしています。
──続いて、「開発の現場から課題を吸い上げるために工夫しているポイント」については、いかがでしょうか？
御立田：今やっていて、これからも続けていきたいと考えているのは、週に1回の実装相談とKPTの2つです。これはプルリクと同じで、細かくやって細かく軌道修正していくためのものです。
実装相談は、例えばアーキテクチャはどうしたら良いかなど、全体に関わる設計の相談ですね。そういったものを各自がGitHub Discussionsに質問をあげて、それについてチームメンバーで議論する時間をとって回答を出すようにしています。
それをやることで、コード全体に関わるところの意思決定が素早くできます。人によって書き方が違ったり、どう書けばいいか迷ったりすることが減っていくので、そこがすごくいいなと感じています。
──最後に、「プルリク分割が生産性向上に有効なことを示す定量的、または客観的なメトリクス」について。プルリク数だけを追うとハックできてしまうという話ともつながるかと思いますが、いかがでしょうか？
五十嵐：そこはあまり見ていません。はてなでは組織の目標にもしていなかったので、別にハックする理由もありませんでした。わざわざ分ける必要もないくらい小さくしたら、本人も面倒だし見る方もつらいので、誰もやらないでしょうという認識でした。
KPI全般に言われることですけど、もし数値を目標にするのであれば、ハックできてしまうところには気を使うべきですね。目標に使うなら十分に研究された指標にすべきで、例えばFour Keysでは、ちゃんと対になる要素も置かれています。それに加えてSREの文脈でSLI、SLOも見ていくとか、そういう話になるのかなと思います。
──それではお時間となりましたので、イベントは以上とさせていただきます。五十嵐さん、御立田さん、ありがとうございました！
※本イベントのアーカイブ配信（無料）はこちら
