はじめに

こんにちは。計測プラットフォーム開発本部バックエンドチームの佐次田です。普段はZOZOMATやZOZOGLASSなどの計測技術に関わるシステムの開発、運用に携わっています。去年の夏に、ZOZOFITというサービスを北米向けにローンチしました。

本記事では、ZOZOFITのローンチまでに遭遇した意思決定における課題と、ADRというドキュメンテーション手法を用いた解決までの取り組みについて紹介します。

目次

• はじめに
• 目次
• 計測プラットフォーム開発本部 バックエンドチームとは
• ZOZOFITとは
• 開発中に直面した課題
• • 過去の背景が分からず決断しにくい
  • 意思決定の結論が追いにくい
  • 意思決定の認識合わせに時間がかかる
• ADRの導入
• • ADRとは
  • 展開
  • ADRのフォーマット
  • 使用ツール
  • チームへの展開
  • ADRの一例
  • 振り返り
  • 課題はどう解決されたのか
  • メリット
  • デメリット
• 最後に

計測プラットフォーム開発本部 バックエンドチームとは

計測プラットフォームバックエンドチームは、ZOZOGLASS/ZOZOMAT/ZOZOSUITによって採集される計測データにまつわるバックエンド開発を担うチームです。アプリやブラウザに対するクライアントAPIや、ZOZOTOWN内部のマイクロサービスのAPIにおいて、徹底的に低レイテンシにこだわりを持つことと、高可用性を保つことを目指しています。

ZOZOFITとは

ZOZOFITは2022年に発表した体型管理を目的としたフィットネスアプリです。ZOZOSUITの計測技術を利用したサービスであり、2023年3月時点では、体型計測および身体3Dモデルのデータ・体脂肪率の表示機能を提供しています。

開発中に直面した課題

ZOZOFITの開発を進めるにあたり先んじてアーキテクチャを選定する必要がありました。選定基準として、過去に運用実績があるZOZOSUITやZOZOMATなどの知見は重要なものでした。実際に私たちのチームではスピードと品質を担保するために過去実績があるアーキテクチャを採用することに決め改善する必要があるものは新しいチャレンジを行うことに決めました。その後、開発を進めるにあたり以下の課題に直面しました。

過去の背景が分からず決断しにくい

私たちのチームはメンバーの半数が新しく参画したメンバーであり、過去の決定はまばらに文書化されている状態でした。メンバー内でも過去の意思決定を把握できているメンバーが偏っている状態であり、新規メンバーは決定の背後にある動機を理解できていない状態でした。新規事業においてはスピード感も重要となるため、ローンチまでに過去の決定をキャッチアップするための同期的なコミュニケーションも取りにくい状態でした。そのため、新規メンバーは新しい意思決定に踏み込みにくい状態となっていました。

意思決定の結論が追いにくい

ZOZOFITにおける意思決定はアジャイルに何度も行われ、意思決定の機会は数多くありました。しかし、過去の決定はSlackでの会話やGitHubでのコミュニケーションなどに点在しており、最終的な結論を理解するためには多くの議論を遡って見ていく必要がありました。議論が追いきれなかった場合は再度同じ提案をする必要があり、何度も同じテーマについて会話する状況となっていました。

意思決定の認識合わせに時間がかかる

私たちのチームはフルリモートでの業務を主としており、海外チームと共に開発を進めています。そのため非同期でのコミュニケーションを重要視しており、SlackやGitHub等のツールを使って積極的に会話をしています。

ZOZOFITにおける海外チームとの協業についてはブログ記事が公開されていますので、気になる方はこちらの記事をご参照ください。

より良い決定のためには、背後にある動機や判断材料が重要となります。しかし、背景などの情報が伝わっていない状態で会話を進めていたため、情報を集めるために各チームと都度コミュニケーションが発生していました。また、非同期でのコミュニケーションはレスポンスがすぐに返ってくるとは限らないため、別作業とコミュニケーションでのスイッチングコストも課題となっていました。

ADRの導入

私たちは上記の課題を解決するためにADRという手法を導入することにしました。

ADRとは

ADRとはArchitecture Decision Recordの略称であり重要なアーキテクチャの意志決定を、背景、結果と共に記録したドキュメントです。

Micheal Nygard氏は「DOCUMENTING ARCHITECTURE DECISIONS」においてADRの思想について言及しており、意思決定の理由と背景を追跡することは難しいため記録しておくべきだと述べています。

One of the hardest things to track during the life of a project is the motivation behind certain decisions. A new person coming on to a project may be perplexed, baffled, delighted, or infuriated by some past decision. Without understanding the rationale or consequences, this person has only two choices:

Blindly accept the decision.
Blindly change it.

プロジェクトの中で最も追跡が困難なことの1つは、ある決定の背後にある動機である。
プロジェクトに新しく参加した人は、過去の決定に戸惑い、困惑し、喜び、あるいは激怒するかもしれません。
このような場合、その理由や結果を理解できないまま、以下のどちらかを選択することになります。

決定を盲目的に受け入れる
やみくもに変更する

実際に私たちのチームにおいても決定の背景や動機を読み取れない問題が起きており、導入することで課題解決に繋がると考えました。

しかし、ADRは決定のドキュメントを記録していく手法であり、Agile Manifestoにおいては包括的なドキュメントより動くソフトウェアを重視すると記載されています。その問題については、以下のように述べています。

Agile methods are not opposed to documentation, only to valueless documentation. Documents that assist the team itself can have value, but only if they are kept up to date. Large documents are never kept up to date. Small, modular documents have at least a chance at being updated.

アジャイルな手法は文書化に反対しているわけではなく、価値のない文書に反対しているだけである。 チーム自身を支援する文書は価値を持つことができますが、それは最新の状態に保たれている場合に限られます。 大きなドキュメントは決して最新の状態に保たれません。小さく、モジュール化された文書であれば、少なくとも更新される可能性があります。

ドキュメントを小さい単位で記録していくことで、より扱いやすく色々な人にとって価値のあるものとなります。ADRは仕様書のように最新の状態に更新し続ける必要はなく意思決定のログとして扱えるため、後追いで見た時に読み手が解釈しやすく、価値があるドキュメントとなります。

上記を踏まえて、以下の項目を意識してADRの導入を行うこととしました。

1. 意思決定の背景・動機が残っている状態となること
2. ドキュメントは小さな粒度で残していくこと
3. ADRは仕様書ではなく、決定のログとして残していくこと

展開

ADRのフォーマットは展開のしやすさを考慮してシンプルなものを採用することにしました。テンプレートは数多く公開されていますが、私たちのチームでは下記のテンプレートを参考にすることにしました。

https://github.com/joelparkerhenderson/architecture-decision-record/blob/main/templates/decision-record-template-by-michael-nygard/index.md

ADRのフォーマット

実際の運用では上記テンプレートの一部解釈を変更して運用しています。使用しているテンプレートは以下となります。

続きはこちら