CIは命綱 - 開発プロセスで意識・工夫していること

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

CIは命綱 - 開発プロセスで意識・工夫していること

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト