STORES Product Blog

こだわりを持ったお商売を支える「STORES」のテクノロジー部門のメンバーによるブログです。

プルリク数を増やすために考えたこと、やったこと、思ったこと。

開発速度を上げよう

こんにちは、STORES 決済 Androidエンジニアのみっちゃんです。

2025年上期、STORES テクノロジー部門では、目標の一つに「開発速度向上」を掲げていました。

この方針を踏まえ、個人としてどのような目標を立てるか考えた際、自分のプルリクエスト(以下、PR)数が少ないことを以前から課題に感じていたこともあり、「PR数の増加」を個人目標として設定することにしました。

具体的には、100件のPR提出を目指すという数値目標を立てました。

ちなみに私の去年下期(2024/07/01~2024/12/31)のPR数は49個です。

これを読んでいる人の中には「え?あなた本当に毎日働いていますか??」と思われた方もいらっしゃるかもしれませんが、本当に毎日働いていました。個人の感覚としては、自分なりに一生懸命日々の仕事に向き合っているつもりでした。

今年の上期に100PR出すということは、今までの倍近くのPRを出す必要があります。

私は絶望しました。

不可能だと思いました。 だって毎日自分なりに一生懸命働いてこれなのにそこから50個以上多くPRを出すなんて全く想像できないと思ったのでした。(お恥ずかしい)

しかしやるしかないので、まずはできることから始めてみることにしました。

うーん。これって本当にやりたいことじゃないね。

プロジェクトに関わる開発を進めるかたわら、fix typoしてみたり、detektのうるさいwarningをコツコツ直したり、特に重要ではないところのunit testを書いたり、ライブラリのアップデートをしたり…今の自分が片手間でできるようなことをして、PRを出してみました。

そうしているとPR数は増えましたが、特に重要ではない変更のレビュー依頼をたくさん飛ばすことによってチーム全体に余分な負荷をかける結果となってしまいました。深く反省しました。

どうやったら意味のあるPRをたくさん出せるようになるのかな。と考えました。

意味のあるPRをたくさん出すために考えたこと

そして、プロジェクトに関係のあるタスクの一つ一つを速くこなせばいいという結論に辿り着きました。

同じ時間でもタスクを完了するまでのリードタイムが短ければ短いほど、より多くのタスクをこなすことができます。
つまり、めっちゃ速く仕事すればいいのだ〜!と阿呆丸出しの形相で思いつきました。(お恥ずかしい)

まあ最初からそれを考えろよという話ではあるのですが、当時の自分にとっては今のプロジェクトのタスクはどれをとってもそんなに簡単に終わるものではなかったので、プロジェクトのタスクを速く終わらすというのは実現可能性が低い選択肢だと思い込んでいました。

で、問題はどうやったら速く終わらせられるんだろう?というところです。

しかし、そんなことをじっくり考えている時間すらもったいないので多少生活を犠牲にしてでもとりあえず長時間働くことでより多くのタスクをこなそうとする習慣が始まりました。自分不器用なもんで。

数週間して仕事のボトルネックが自分なりに見えてくるようになりました。

開発業務は大きく分けて次の2つのステップがあると思います。

1. タスクに関する情報収集

  • どんな仕様?
  • デザインはある?
  • 表示したいデータはどこから取ってこれる?
  • デザイン通りのUIを構成するのに必要な知識は揃っている?
  • 異常系についてもUIや仕様は固まってる?

2. 実装する

  • 1でかき集めた情報をもとにあとは手を動かすだけ

そして一番時間がかかるのは1の情報収集の部分だと思いました。 情報収集の部分で疑問点が一切ない状態まで持っていければ2の作業は速く、そして見積もりやすくなります

逆にタスクに時間がかかってしまうパターンで多いのは、1と2のステップを行ったり来たりする場合です。 1で疑問点や確認不足を残したまま2の実装に入り、実装の最中で「あれ異常系のデザインがない」となり、デザインチームに確認している間にタスクが止まったり、デザインが決まった後で「そもそもこのデータ取って来れなくない?」ということに気づき、またコミュニケーションを取り直す…などの現象がおきます。

では情報収集部分をできるだけ正確に速くするために実際にやってみた工夫を紹介します。

情報収集を速くするためにやったこと

すぐにできること

自分が立てたissueにデフォルトで自分をアサインするようにしました。

これは別に自分ができそうなタスクを自分で作ってそれに自分をアサインするとかいう自作自演ではないです。

例えばプロジェクトとfigmaを見比べて、この画面の実装がないな、と思ったらissueを立てて、その時に自分をアサインしておく、みたいな感じで、あくまでプロジェクトを前に進めるのに必要なissueを立ててます。

STORES 決済 Androidチームでは、issueを立てる時、issueの概要やゴール、デザインがあればそのキャプチャも載せるようにしています。つまり、issueを立てる過程でそのタスクに関する情報収集をある程度やることになります。そうすると、自分で立てたissueを自分にアサインしておくことで、ちょっとでも情報収集部分の時間を省くことができました。そしてそのタスクをできるだけ速く着手するようにしました。

もちろん、自分がアサインされていなくてもまず優先順位の高いものから進めました。優先順位の高いタスクを気合いで早く終わらせて、特に優先度が高いものが現状ないなという状態になったら、自分がアサインされている理解度が高いissueに取り組む、みたいな感じにしました。

時間をかけてできるようになること

もう一つは、同じことやっていても、経験でさらに精度が上がるなあということです。

自分は新卒の頃から、タスクを完了するまでに必要なことを全てチェックボックスと共に言語化するようにしています。

ここで新卒の頃のタスク分解の粒度を見てみましょう。 これは画像設定機能を削除するissueでした。

ブランチを切るところからタスクにしてるのがすごく可愛いなと思いました()

「依存がなくなっているか調べて消す」とか「テスト落ちるかも」みたいに一見視野広そうに見えますがこれは全部先輩の助言を素直に書いてるだけです。自力で辿り着いてないです。

一方、最近のタスク分解の粒度を見てみます。

割と細かく分解しています。ここまで細かいと考慮漏れも防げますし、あとどれくらいでタスクが終わりそうかの見積もりも容易です。

これはタスクに対する解像度が高くなったのもありますが、自分に対する解像度も高くなったのだと思います。

例えば今までの経験で、「もっと始めの段階でデザイン確認していれば!」とか「異常系のパターン考え忘れてた!」とか「実装したけど、これどうやって動作確認したらいいんだ??」とかたくさんミスをしてきたので、これまで積み上げてきたたくさんのミスを繰り返さないための工夫がタスク分解に表れています。

同じ取り組みをやっていますが、経験によって精度が高くなったと思います。

チームでやったこと

計画第二部をやるようになりました。

今のプロジェクトではスクラム開発をしていて、一週間でスプリントを回しています。一週間の初め、月曜日に全体で計画をした後、今度はAndroidチームだけで集まって、計画第二部をやります。

計画第一部(全体での計画)では何をやるのかを決め、計画第二部では、どうやるのかをチームで議論します。

大体1時間くらいで、全員でそれぞれのメンバーのissueをみて、デザインがすでにあるか確認したり、仕様について疑問点をなくしたり、先輩から実装する場合の懸念点について教えてもらったりします。

その過程で、思ってたより難易度の高いタスクだぞ!と分かった場合はストーリーポイントを変更し、各人のタスクを優先度や稼働日も考慮しながら調整します。

また、計画第二部以外にも毎日夕会をしているので、いつでも気軽に質問・相談できるタイミングはあります。

その他効果があったこと

こまめにPRを出す

「こまめに」と言っても、意味のあるまとまりごとにPRを出すことを意識しています。

以前の自分の開発スタイルを振り返ると、一つのPRで多くのことを詰め込みすぎていたと感じます。 たとえば画面の実装に関して、実装前のリファクタリング、正常系の実装、異常系の実装、バグ修正などをすべて1つのPRでまとめて行おうとしてしまい、結果的に同じ作業ブランチで数日〜1週間も作業し続けてしまう、ということがよくありました。

現在は、意味のある単位でタスクを分け、それぞれの区切りでPRを出すようにしています。 これによって自分自身も達成感を感じやすくなり、チームメンバーからも進捗が把握しやすく、変更差分が小さくなることでレビューの負担も軽減されました。

結果

2025/01/01から現在までで、私のPRは115個マージされています。

無事100を超えることができました。

スプリントごとに見るとこんな感じです。 出張が多かったりMTGが多い週はPR数が下がったりもしていますが、ある程度コンスタントに貢献できていると感じます。

思ったこと

正直自分の情報収集スキルはまだまだだ未熟であるというところは非常に強く感じています。 情けないですがどうしても苦手な部分なのだと思います。 引き続き自分に向いているやり方を日々の仕事の中で模索するしかありません。精進します。

一方で、自分が不可能だと思ったことをとりあえず何とかして何とかできたことは良かったと思います。

この記事を読んでいるみなさんも、こいつこんなこともできないのか、こんなことで悩んでいるのかと思うかもしれませんし、私も今思えば普通にできるやんと思ったりもしますが、できるようになるまでは、「できないこと」って「できる」イメージが全く持てない、ブラックホールみたいに真っ暗で不安で先が見えない課題なのですよね。元気に生きていきましょう。