はじめに
こんにちは！ 10Xで始まったプロダクトブログで初めて筆を取りました、ソフトウェアエンジニアの 山口 (@yamarkz) です。
最寄りのスーパーはライフで、必ずはちみつヨーグルトを買ってます。(おいしいのでオススメ 😋)
自身の初回ということで何を書くか迷いましたが、もうすぐ10Xに加わって1年ということもあり、入社時に驚いたことの1つである 10Xのコードレビュー文化 について紹介しようと思います。
10Xのプロダクトチームがどんなスタイルで開発を進めているのか、その一端を知ってもらえたら嬉しいです。
- はじめに
- 1. もともとコードレビューする文化がなかった
- 2. 1年半で4パートナーのリリース、高まる複雑性
- 3. コードレビューの導入を始める
- 4. 導入後の変化
- 5. 今後の展望
- さいごに
- おしらせ
1. もともとコードレビューする文化がなかった
いきなり否定から入ってしまうのですが、自分が入社した2020年9月の頃は、プロダクトチーム内でコードをレビューする文化がありませんでした。( !! )
正確には全くないというわけではなく、クリティカルな部分の実装や実装者がレビューを希望した場合にのみ実施されており、それ以外は行わず各々がPR (Pull Request) をマージし、リリースしていました。
最初この状況を見た時は戸惑いがあり、「すごいな...」と声を漏らして驚いたことを覚えています。自分は10X以前ではコードレビューをゆるくも厳しくも必ず行う世界を見てきたので、初見のギャップが大きかったのかもしれません。
希望して実施されるレビューは大方針が間違っていないかや、クリティカルな箇所のロジックが仕様に沿っているかを確認する程度で、よくある細かな表現に対する指摘などはなく、実装は個々人に大きく委ねられていました。
それでも特段開発に支障が出ることもなく、ほど良い品質で素早く機能をリリースするサイクルが回っていたので、レビューの必要性自体あまり感じない状況だったなと、今振り返ると思います。
これには大前提として、当時からシニアなメンバーが揃っていたのとリリース初期で複雑性が低かったという背景もありました。
2. 1年半で4パートナーのリリース、高まる複雑性
Stailerがリリースされてからおおよそ1年半で4パートナーのプロダクトをリリースしてきました。 これが早いか遅いかは主観による所ですが、個人的には極めて早いスピードで進んできたと思っています。
このスピードを実現できたのは、開発言語をDartに統一するという技術戦略や、Stailerをプラットフォームとして事業展開する(≒ 抽象化でレバレッジをかける)といったプロダクト戦略によるところが大きいのはもちろん、先の文化も少なからず寄与しています。
コードレビューを強制しなくても良い感じに開発が進む文化は、自律した個々人の集合によって実現されていました。この文化は見方を変えれば、「開発におけるメンバー間の依存関係が疎である」とも言えます。
疎というのは、メンバー間での情報共有が少なくとも自律的に物事が進められる組織状態のことで。これは仮に10人のメンバーがいた場合、並列して10個の開発が進んだりします。各メンバーは常に業務時間の8割以上を開発に投下でき、非常に生産性の高い状態です。
開発スピードはチームとしての頑張りもありますが、それ以上に戦略と文化によってもたらされる部分が大きいのではないかと思っています。
これまで開発を順調に進めてきましたが、それでもやはり規模が大きくなるにつれてプロダクトの複雑性が高まることは避けられません。
複雑性に対処するために仕様の理解や調整に時間を要することも徐々に増えてきました。
Stailerはマルチテナントで運営されており、共通の実装で複数サービスの展開を行なっています。コードで見れば、6~7割程度は抽象実装でカバーできていますが、残りの3割近くは断片実装が必要になります。
この断片実装周りの仕様が分岐点になり、「Aパートナーには機能提供するが、Bパートナーにはしない」「Aパートナーでは制約付きで提供し、Bパートナーは制約がないが若干表現を変えて提供する」といった複雑な状況が生まれていました。
これらは後々統一した抽象実装に昇華させたりもしますが、直近の断片実装は避けられない状況で、ある程度の複雑性を許容して進めていかなければいけません。
そういった中で開発を進めていくと、仕様の考慮漏れであったり、変更による想定外の副作用などが生まれてしまい、実装者だけで実装の安全性や完全性をカバーすることの限界が見えてきました。
今後支障をきたし始めることがわかってきたタイミングで、コードレビュー必須化の話題が挙がり、導入の検討が始まります。
3. コードレビューの導入を始める
前段の状況が生まれ始めたことをきっかけに、コードレビューの必須化検討が始まりました。
導入の段取りはCTOのishkawaさんがコードレビュー運用方針のタタキ台をつくって、そこにメンバーのフィードバックを当てて実運用に乗せていく流れです。
運用を始める背景、最低限守りたいライン、運用手順などがドキュメントに起こされました。
これは外に公開しても問題ないという確認を得られたので、10Xのコードレビュー運用ガイドの一部を紹介します。
このコードレビューの方針に沿った形でPRを作った場合、実装方針とその表現の確認に重きが置かれます。具体例として、直近自分が作ったPRは以下の様な表現をしています。
課題を解決するHowの候補として取れる選択肢は何があるのか。その中で何を選択したのか。その結果、どういった表現になるのか。表現に対して考慮の不足や副作用の懸念がないか。という一連の方針、実装の大上段をレビューしてもらいます。
WhyやWhatはissueに記載してある場合や、口頭で合意を取っているケースがほとんどなので、PRにはHowのみを記載します。
[余談] これまで運用をしてきた中で「こりゃ便利だな〜」と感じている仕組みとして、Slackにレビュー依頼のメンションを飛ばす仕組みがあります。
この仕組みがあると画像のようにSlackにメンションで通知が来るので、レビューを忘れることことがなくなり便利です。すぐに設定しましょう。
👉 公式ドキュメントに設定方法が紹介されています。
4. 導入後の変化
というわけで、10Xでもコードレビューが必須になりました。🚓 👮♀️ 🚨
ルールを変えるということは、結果として何かしらの変化が起きます。 起きた変化を得られたものと失ったもので整理すると次のようになりました。
<得られたもの>
- 仕様の考慮漏れや変更による副作用でのバグが減った。
- メンバー間で仕様の共有知を醸成できる様になった。
- 仕様変更の認識と理解を得る機会になった。
- 中期を意識したより良い実装表現を見つける機会になった。
<失ったもの>
- リリースまでの短期的な速度が低下した。
- レビューで個人の稼働時間を消費するようになった。
- レビューによる認知負荷が個人にかかるようになった。
導入タイミングとしてはベストで、投資対効果が十分に見合う仕組みになったと感じています。
後から気づいたことで、レビューの機会が「仕様変更の認識と理解を得る機会になること」は新しい発見でした。
急速に複雑化していくStailerの場合、仕様変更に後追いで気づくよりも、レビューの機会を通じて変更が入ることを頭の片隅に入れておけるのはキャッチアップの機会にもなり、良い体験です。
5. 今後の展望
運用によって良い効果が得られている一方で、まだまだ改善の余地があります。 具体的には、レビューの基準をより精密にすることや、実装以前の段階での設計レビューを設けるなどです。より良い形を模索しながら、10Xらしい開発文化を作っていきたいです。
ちょうど先週開催されたProductチームが話すオープンオフィスでは今後のStailerの方針が社外向けにも話されました。
Stailerはこれからの1年~3年でプラットフォームとしての拡大基盤の整備、および信頼性と安全性の向上に力を注いでいきます。
コードレビューの導入は、これから達成していくことの最初の一歩目とも言える出来事だったと思いました。
さいごに
10Xのコードレビュー文化について、これまでの過去を振り返りながら、現在の状況、そして今後やりたいことまでを紹介してきました。
コードレビューを強制しない状況から、徐々に実施する流れに進んできていますが、そこには明確な背景や合理的な理由があってやり方を変えてきたというのが、今回の記事で紹介したかったポイントです。弊社の例がコードレビューの導入や改善を検討している方の参考になれたら嬉しいです。
自身の1本目だったので下手なことは書けないなと思い、気合を入れて書いてしまいましたw 今後はゆるい記事も交えながら、10Xのナレッジを公開していけたらと思っています。😄
おしらせ
10XはFlutter/Server Dartという邪道のような技術を選択しながら、店舗のデジタル化という小売の王道になるであろう事業の立ち上げにトライしています。🔥
難しい問題がたくさんありますが、自律した仲間と背中を合わせて10xな価値をつくるのはとても楽しいですよ！
定期的に開催しているオープンオフィスでは、普段の開発の裏話なども聞けるので、興味あればぜひご参加ください。
