hey でソフトウェアエンジニアをやっている @_morihirok です。
私たちが開発・運用しているネットショップ開設サービス STORES に、このたび新しい決済手段が追加されました。
規模と影響範囲が大きい開発でしたが、3人という少人数の開発チームでスケジュール通り無事故でリリースでき、すでに多くのユーザーさまに使っていただいている決済手段となっております。
私たちのチームがどのようなことを意識することでこれらの成果を上げることができたか、ご紹介させていただきます。
私たちのチームについて
私たちはネットショップ開設サービス STORES とオフライン店舗向けPOSレジアプリ STORES レジ の機能開発を行っているチームです。
昨年秋頃に「新たな決済手段を追加する」という意思決定が行われ、その開発を私たちのチームで行うことになりました。
規模が大きくリリース時期の指定があるなど難易度が高い開発に思えましたが、私たちが普段から取り組んでいることを継続できれば問題なくプロジェクトを完了できると考え開発を進めていきました。
私たちが取り組んでいること
チーム全員でひとつの課題に向き合う
私たちのチームでは開発プロセスにスクラムを採用しています。 スクラムでは一定の期間をスプリントと呼び、スプリントの最初に取り組むタスクの見積りをします。
この見積りをチームでとても大切にしており、ただ見積もるだけではなく「チーム全員がそれぞれのタスクに対する修正（Pull Request）を出せるまで理解が深まっている」状態を目指しています。そして、スプリントのタスクはすべて誰でも取り組める状態にしています。
以前は見積りの際に「このタスクはこの人が実装する」というのが（暗黙のうちに）決まっていたのですが、どうしても実装者が見積りを率先してしまい他のメンバーの理解が深まらないままスプリントに突入してしまっていました。結果、Pull Requestが出たタイミングでレビュアが「そもそもなんでこの変更が入るんだっけ？」となりコードレビューに時間がかかり、時には前提が覆り、大きな手戻りが発生したこともありました。
チーム全員でタスクの理解度を高めるのは確かに高コストではありますが、「このスプリント中にどのようなPull Requestが来るのか」ということが想像できるようになり、結果としてコードレビューが早くなり開発速度は向上します。
さらに、チーム全員が課題に対して同じ理解度を持つことによっていろんな観点から課題解決の方法を出せるようになります。チームのメンバーひとりひとりは違う背景を持ってチームに来ているので、既存機能の知識や過去の失敗などいろんな知見を持っています。みんなの知見をひとつの課題を通じて共有しあうことで、より良い課題解決の方法を考えられるようになります。
規模の見積りとベロシティトラッキング
私たちのチームでは見積りにあたって アジャイルな見積りと計画作り を参考にしています。
この本に従い見積りには時間を使うのではなく、相対的な規模を使うことによってどのスプリントであっても概ね見積りの粒度を合わせています。時間の見積りだとメンバーの技術力・知識量によって見積りの結果が変わりますが、相対的な規模であればチームの状況に左右されず見積り粒度をある程度揃えることができます。
見積った規模をポイントとしてタスクに割り振り、毎スプリントごとに消化できたタスクのポイント総量をベロシティとしてトラッキングしています。この値を利用し将来を予測することでどのような規模の開発であってもある程度正確なリリース見積りができるようになります。
詳細なやり方についてはぜひ本を参考にしていただけたらと思いますが、ある程度正確なリリース見積りができるようになることでハードワークを防ぐことができ、社内外とのコミュニケーションが円滑になります。
プロトタイピング
見積りで課題の理解度を上げた結果「これ実際にコード書いてみないと判断できないね」となることはよくあります。このとき私たちのチームではモブプログラミング・プロトタイピングといったプラクティスを積極的に行っています。
モブプロでコードを書きながら、あるいはプロトタイピングによって作られたある程度動くコードを見ながら議論するとチーム全体で課題の理解度が上がり、多くの暗黙知を共有することが可能となります。（もちろん必要な情報については Pull Request の Description やコードコメントなどでなるべく残せるように努力します）
プロトタイピングで重要だと思っていることは「プロトタイピングしたコードをそのまま採用しない」ということです。 あくまでプロトタイピングは課題への理解度を上げる行為だと思っていて、この時に書いたコードを元に取り組むべきタスクに落とし込んだら、プロトタイピングしたコードは思い切って捨てています。
あわせて、私たちのチームではプロトタイプを開発したメンバーがそのまま本実装に入らないように意識しています。プロトタイピングを行ったメンバーはどうしても課題の理解度がグッと上がるので、あえて違うメンバーが本実装に取り組むことで課題の理解がひとりに集まることを避けています。
トランクベースの開発
私たちのチームでは LeanとDevOpsの科学を参考にさまざまなプラクティスを開発を取り込んでおり、その中でも一番効果を感じたのがトランクベースの開発です。
トランクベースの開発ではフィーチャーブランチやトピックブランチを用意せず、書いたコードをどんどん本番環境にリリースしていきます。 このとき本番環境に影響を与える差分についてはフィーチャートグルを用意し、開発環境では動作するが本番環境では動作しない状態でリリースします。
これによって他の開発チームの変更によるコンフリクトに頭を悩ます必要もなくなり、ビッグバンリリースするストレスから解放されます。 自然とひとつひとつのPull Requestの粒度は小さくなり、レビュー速度もあがり開発速度の向上にも寄与します。
試してみる前は正直効果があるのかピンと来ていなかったところもあったのですが、自分たちでも驚くほど開発体験が良くなり、今ではチームにとって欠かせないプラクティスになっています。
取り組んだことの成果
今回私たちは決済手段の追加という影響範囲が大きく、開発期間も長く、さらにリリース時期の指定があるという難易度の高いプロジェクトに取り組みましたが、結果として期日通りに無事故でリリースを完了させることができました。
チーム全員でひとつの課題と向き合った結果、いろんな観点から問題がないか精査し合えたことで事前に多くのエッジケースを考慮でき、それらに余裕を持って対応することができたのが無事故の要因として大きかったと感じています。また、トランクベースの開発を行うことでビッグバンリリースを避けられたことも無事故の一因と思っています。
また、プロトタイピングを元になされた規模の見積りとベロシティトラッキングを続けた結果、比較的長期にわたる開発プロジェクトであったにも関わらず精度高く見積もれました。おかげで期限がある開発であっても残業などのハードワークは発生せず、健康なチーム状態のままリリースまで辿り着くことができました。
開発体験としてもPull Requestがすぐにレビューされどんどん本番環境にデプロイされていくのはとても気持ちが良く、満足いくスピードで開発ができていたと感じています。質とスピードは相反関係に無いということを強く実感するプロジェクトでした。
これからの私たちのチーム
今回のプロジェクトを経て、私たちは私たち自身で良いチームだと思えるようになりました。 しかし、これは「これからも私たちは良いチームであり続ける」ということではありません。常に私たち自身を客観的に捉え、より良いチームであるための改善を繰り返して初めて今の状態を維持できると思っています。
私たちが素早く質の高いコードを書き、高い価値を届けられるチームであり続けることは、プロダクトを提供する会社にとって大事な強みとなりますし、何より私たちのプロダクトを使ってくださるユーザーのみなさまにより喜んでいただくことにつながります。
これからも私たちはさまざまな挑戦をしてより良い開発チームであり続けられるよう努力していきます。
ということで、より良い開発チームであり続けるためにさまざまな挑戦をしてみたいソフトウェアエンジニアの方はぜひ私たちのチームにお越しください！
