CIは命綱 - 開発プロセスで意識・工夫していること
ストックマーク Co-VPoE の岩瀬です。本記事はストックマーク アドベントカレンダー 2022の初日記事です。
ストックマークの開発チームは高速にかつ堅実に価値を生み出しています。その内部で何を意識しているのか、何を工夫しているのか、本記事でその一端をお届けします。効果的な開発プロセスを追求するエンジニアや、テックリード、エンジニアリングマネージャに少しでも参考になることを狙っています。（なお、概要＋一部の公開ですので、全体像やより突っ込んだ詳細については、本記事最下部にあるカジュアル面談までお願いします！）
本記事で紹介するトピックは以下の6つです。
- スキーマ駆動によるコミュニケーションの最適化
- Over Fetching を生み出さないAPI設計
- 価値のベースラインを保つリグレッションテスト
- 継続的なライブラリバージョンのメンテナンス
- CIは命綱
- 「推測するな、計測せよ」によるユーザー体験の向上
それでは早速いってみましょう！
スキーマ駆動による開発効率化
ストックマークのエンジニアは、フロントエンドであればバックエンドであれ、gRPCのスキーマを触れるようになっていきます。これによってメンバー間のコミュニケーションコストを最小化しており、円滑に開発が進められるようになっています。
もう少し具体的に内部を紹介すると、PRDを作ったメンバー※や、PRDのメイン検討・実装を担うことになったメンバーがprotoファイルを先に作って、Pull Requestを出すようにしています。
※ ストックマークでは、エンジニアであってもPRDを書くことがあります。[記事1][記事2]
Over Fetching を生み出さないAPI設計
ストックマークのプロダクトは大量の情報を扱うものが多いため、API設計を雑にしてしまうと、Over Fetchingが発生する可能性があります。Over Fetchingすると、必要以上のデータをやりとりすることがあるため、速度の低下を招くためユーザ体験が悪化してしまいます。
そこで、内部のAPI設計として、画面ごとに最適化して必要十分なAPIとなるようにしています。この場合、画面ごとに一部重複してしまう可能性がありますが、実装として共通部分を共通のmessageとして括りだして使うなど、保守性を高めています。
価値のベースラインを保つリグレッションテスト
プロダクト開発というのは、常に新しい価値を生み出し続けるものではありません。新しい価値を生み出しながらも、狩野モデルで挙げられる当たり前品質・一元的品質をキープする必要があります。
ストックマークのプロダクトにおいても、常に品質を保ち続けたい機能がいくつかあります。たとえば、検索精度や検索キーワードの自動補完がその機能に該当します。検索機能を例にとると、ストックマークのプロダクトのユースケースでは、検索が利用される機会が多くあります。そのため、検索精度が悪化してしまうと、ユーザー体験が著しく悪化してしまうのです。
そこで、内部のアルゴリズムに手を加えた場合であっても、体験が悪化していないことを担保するために、リグレッションテストを継続的に実施しています。自動化している部分も多くありますが、人間の価値判断が必要な部分については、人の目も活用しています。
本セクションの例として取り上げているような「良い検索精度、ユーザーに高い価値をもたらす検索精度ってなんだろう？」というテーマは、人の目を活用する一例です。もちろん、再現率と適合率を考慮したF値を見るような手法や、ランク指標を測るMRR（Mean Reciprocal Rank）などもありますが、現時点ではいちばん顧客アウトカムに寄与するものとしてマニュアル対応をしています。
継続的なライブラリバージョンのメンテナンス
皆様は過去に、開発・運用しているプロダクトで利用しているライブラリのバージョンがかなり古くなってしまった、という経験はありませんか？バージョンの差分が開けば開くほど、バージョンの最新化は困難になりがちです。
ストックマークではライブラリバージョンが古くならないよう、開発プロセスに組み込んで対応しています。具体的には、開発の週次ミーティングの中でdependbotによる通知をレビューしています。
CIは命綱
開発を続けていると、特定の環境要因（たとえばCircle CI）でCIが意図通りに動作しないことがあります。たとえば、CircleCI の Executor 環境とローカル環境の違いやバイナリのコンパイルオプションの違いなどが要因となって、Python のsetuptools がインストールされずにテストが落ちるといった現象などです。
このような場合の対応策としては、その部分はカットしてしまったり、別のワークアラウンドを試したり、と様々な案があります。ストックマークでは、レアな事象が起きたとしても、過去に様々な事象を踏み抜いてきたエンジニアが在籍しており、CIが正常に動き続けるようにメンテナンスをしています。
実際に内部のエンジニアの発言から「CIは命綱。動いていなくても、少しならいいかもしれないけど、命綱がない状態で開発をしていたらぼくは怖い。」という力強い発言もありました。
「推測するな、計測せよ」によるユーザー体験の向上
ストックマークの開発チームは、プロダクトの内部でかかっている処理・IO時間を、Datadogを利用して可視化しています。可視化されたデータから、特にユーザー体験につながる部分を集中して改善しています。言い換えれば、場当たり的に予測して改善を繰り返すのではなく、データドリブンで開発プロセスを進めているということです。
わかりやすい仮の例を使うとすれば、バックエンドで1秒かかる処理を70%高速化するよりも、10秒かかるようなネットワークIOを10%高速化（IOの量を減らしたり、回数を減らしたり）したほうがユーザー体験につながるのです。
格言である「推測するな、計測せよ」を地で行く開発プロセスを進めています。
まとめ
本記事では、ストックマークの開発プロセスで意識していることや、工夫していることの一部を紹介しました。他にも、テスト時におけるモック注入や、環境ごとに適した依存性注入を実現するためのDI (Dependency Injection) 利用など、たくさんご紹介したい内容があります。
本記事では紹介しきれない詳細や他の課題について、詳しく知りたい場合はぜひお話しましょう！
また、本記事はストックマーク アドベントカレンダー 2022の初日記事でした。本日含め明日からも25日間、ストックマークの記事が続きますので、ぜひお楽しみに！
