2023 / 12 / 5

改善施策のプランニングが鍵 - 大規模バッチ処理のテストフレームワーク刷新プロジェクト

プロジェクトの背景

最初に、Anewsのバッチ処理とそのテストフレームワークについて説明します。

Anewsとバッチ処理

ストックマークはAI 情報収集プラットフォームAnewsを運営しています。 Anewsでは、ニュース、論文、特許といった様々な情報を国内外約35,000メディアから収集し、AIによる最適な情報配信を提供しています。

Anewsで配信されるコンテンツ（フィード）には様々な種類があります。例えば、ユーザーの興味や嗜好に合わせたパーソナルフィードや、ユーザーが設定したキーワードにマッチするテーマフィードなどがあります。これらのフィードは日々のバッチ処理によって生成されています。

上図はAnewsのバッチ処理を定義しているAWS Step Functionsのワークフローです。 Anewsで日々の情報配信が行われるためには、このバッチ処理が安定稼働する必要があります。バッチ処理の安定稼働を確保するためには、テストが不可欠です。

バッチ処理のテストフレームワーク

バッチ処理のコードはPythonで書かれており、そのテストフレームワークとしてはmambaが使用されていました。

mambaを使用していた理由は開発者の学習コストが抑えられるためです。 AnewsのウェブアプリケーションのバックエンドではRubyが使用されており、そのテストフレームワークとしてはRSpecが使用されています。 mambaはRSpecと同様の記法でテストを書くことができ、mambaを使用していました。

ですが、mambaは2020年11月を最後に更新が止まっており、長期的に使用するには不安がありました。このため、バッチ処理のテストフレームワークを刷新することが改善施策として挙げられていました。

改善施策のプランニング

次に、ストックマークにおける改善施策のプランニングについて説明します。

ここでの「改善施策」は、数週間程度時間がかかったり、複数チームの連携が必要になったりする、比較的工数がかかる改善施策を指します。

このような改善施策は、重要度が高いにもかかわらず、なかなか優先度を上げることが難しく、後回しにされることがよくあります。

そこで、ストックマークでは、重要な改善施策に関しては、組織の目標として計画に取り込み、実行する機会を確保しています。

具体的には、以下のような手順で改善施策をプランニングします：

各チームは次期に取り組む改善施策の候補をリストアップし、優先順位を付ける。
他チームとの連携が必要な施策については、各チームのリーダーが協議し、優先順位を調整する。
チーム内で各施策の担当者を決定し、担当者は次期の個人目標にその改善施策を組み込む。

このようにすることで、次期に取り組む改善施策の実行の機会が確保されます。また、担当者の個人目標と結びついているため、改善施策を進めるインセンティブになります。

改善施策をどのように進め、いつ実施するかは、担当者の裁量に委ねられます。また、改善施策を行うことについて組織で合意形成できているため、工数については担当者が必要なだけ確保できます（たとえば、今回のテストフレームワークの刷新プロジェクトは1ヶ月程度工数を確保して進行しました）。

一方で、改善施策とは別にプロダクトの機能開発も同時進行で進める必要があります。このため、以下のように、チーム内で誰がどのタイミングで機能開発と改善施策に取り組むかを調整しながら進行します。

このように、機能開発を進めながらも改善施策に取り組む機会を確保しています。

今回のテストフレーム刷新プロジェクトについても同様にプランニングしました。また、私が志願して担当させていただくことになりました。

テストフレームワークの選定：pytest-bdd

新しいテストフレームワークを導入するにあたり、まずはテストフレームワークの選定を行いました。調査対象とするPythonのテストフレームワークとして、以下のものを検討しました：

テストフレームワークの選定基準としては、社内事情を考慮し、以下のポイントを優先的に検討しました：

現在もメンテナンスが継続されていること
BDD（ビヘイビア駆動開発）テストフレームワークであること
使いやすさ

1については、旧テストフレームワーク（mamba）の課題が、メンテナンスされていないことだったため、採用しました。

2については、Anewsのバッチ処理の各ジョブにはビジネス上の要求から様々な仕様を満たすことが求められます。 BDDテストフレームワークでは、システムに求める仕様を自然言語で記述しながらテストを書くことができます。このため、何をテストしているかが分かりやすく、求められる仕様を全て満たしているか確認しやすいというメリットがあります。

また、旧テストフレームワークのmambaもBDDテストフレームワークであり、BDDテストフレームワークであればmambaで書かれたテストを書き直しやすい（テストを移行しやすい）というメリットもあります。よって、2も選定基準に入れました。

3については、多少主観的な要素も入りますが、テストが書きやすい点も重視しました。この点については、各テストフレームワークで実際にテストコードを作成し、感触を確認しました。

これらの基準に基づき、最終的に選定したのはpytest-bddです。

behaveも上記の基準を満たしたのですが、pytest-bddはpytestのプラグインであるため、pytestの機能やプラグインを使える（特にテストの並列実行にも対応している）などを考慮し、pytest-bddに決めました。

新テストフレームワークの導入と運用

pytest-bdd関連のライブラリの導入とテスト環境の整備は、特に問題なく進められました。

さらに、テストの作成方針に関するガイドラインを整備しました。具体的には、新テストフレームワークを使用してテストを書く際に、担当者ごとにテストの記述方法にばらつきが生じる可能性があります。このばらつきを抑制するために、ガイドラインを導入しました。

ガイドラインの例としては以下が挙げられます：

pytest-bddを使ったテストの書き方（test file、feature fileの作成例）
test fileの各ステップの関数の命名規則
feature fileに複数のシナリオがある場合の、test fileの各ステップの関数の記載順序（シナリオごとにgiven、when、thenステップをまとめる等）

ガイドラインを整備することで上手くいった点と今後の課題は以下の通りです。

上手くいった点

ガイドラインで明示した内容については、Pull Requestレビュー時に指摘が不要になった
新たな開発メンバーに対してもガイドラインの所在を知らせるだけで情報共有できるため、教える手間が軽減された

課題

当初のガイドライン作成時に想定していなかったケースが発生した

課題の「想定していなかったケース」の一例を紹介すると、pytestとpytest-bddの使い分けが挙げられます。

例えば、utilやhelper関数のテストなどもpytest-bddを使用するとテストが冗長になり、書きづらいケースもあります。このため、これらのケースでは通常のpytestを利用することを許容しています。ですが、pytestとpytest-bddの使い分けの基準についてはまだ十分に定まっておらず、今後も検討が必要です。

旧テストフレームワークのテストコードの移行作業

2023年12月現在、旧テストフレームワーク（mamba）で記述されたテストコードが残っており、これらのテストコードをpytest-bddで書き直す作業を進めています。

定期的に関係者で集まり、テストコードの移行の進捗を確認するミーティングを行っています。移行の進捗状況はスプレッドシートで管理しており、進捗を可視化しています。

基本的には以下の方針で新テストフレームワークでテストを作成しています。

新機能に関するテスト（つまり、今後追加するテスト）はpytest-bddを使用して記述する
既存機能に関するテスト（mambaで記述されたテスト）については、関連する製品コードを変更するタイミングでpytest-bddで書き直す

ですが、バッチ処理の既存機能の製品コードを変更する機会がそれほど頻繁でないため、既存機能のテストコードの移行が予想よりも進みませんでした。

このため、現在は上記のアプローチに加え、各関係者に対して既存機能のテストファイルを割り当て、次回の進捗確認ミーティングまでにそれらをpytest-bddで書き直すようにしています。

このようなトライアンドエラーを通じて、テストコードの移行作業を進めています。

プロジェクトを通して学んだこと

今回のプロジェクトを通じて、個人的に以下の3つのことを学びました。

1. 改善施策のプランニングが鍵を握る

改善施策を事前にプランニングし、組織内でそれに対する合意を形成できたことが大きな成功要因でした。このプランニングのおかげで、工数を確保してプロジェクトに取り組む土台が整いました。

2. プロジェクトを完遂することで自信がつく

チームメンバーとの協力を得ながらも、プロジェクトを完遂することができました。作業には一ヶ月以上かかりましたが、この経験から今後も同程度のタスクなら達成できるという自信を持てるようになりました。

3. メンバーとのコミュニケーションが強化される

大規模な改善施策では、担当者単独では意思決定が難しく、チームメンバーとの協力が不可欠です。コミュニケーションを重ねることで、チームメンバーに意見を求めることへの抵抗が減り、今後のプロジェクトにおいてもプラスになると感じました。

まとめ

今回は改善施策としてテストフレームワークの刷新プロジェクトを紹介しました。

ストックマークには担当者が裁量を持って施策を進められ、それが評価される風潮があります。

ストックマークに少しでも興味を持っていただけた方はカジュアル面談をお申し込みいただけると嬉しいです。気になった方はぜひ採用ページをご覧ください！