この記事はBASE Advent Calendar 2021の20日目の記事です。
はじめに
こんにちは。Owners Experience Backend Group の杉浦です。主にサーバーサイドのアプリケーションの実装をしています。
エンジニアにとって、外部企業から提供されるAPIやCDN（Content Delivery Network）といった『外部サービス』をどう扱うかは悩ましい問題です。
特にシステムの設計段階において「外部サービスをどうやって内部システムに組み込むのか？」という方針は、その後のアプリケーションの生産性に大きく影響します。
仮に、密結合に設計してしまうと「外部サービス」という不確実性に影響されやすくなるため、好ましい状況とはいえません。どのように疎結合を実現するのか？という設計が、外部サービスから不確実性をハンドリングする生命線になります。
そこで、この記事では、2021年11月にリリースを行なった「Akamai Image Video Manager の導入プロジェクト」を例に、外部サービスの不確実性を最小化する「設計戦略」の実践方法を提示します。
本稿は３章立てになっています。
- 第１章：外部サービスの不確実性という問題
- 第２章：設計戦略のプランニング
- 第３章：設計戦略を実行するチームマネジメント
第１章では、外部サービスの不確実性について考察しています。内部サービスがミクロな不確実性への対処が主軸になるのに対して、外部サービスの不確実性がよりマクロな範囲、特に外部企業の経営方針の影響を受けやすいという点に言及しました。
第２章では、不確実性を最小化するための設計戦略を提示します。疎結合な設計はもちろん、外部企業の経営状況を読み解くために財務状況（PL/BS）を踏まえる必要性を提示しました。
第３章では、Akamai Image Video Manager の導入プロジェクトを例に、設計戦略を遂行するためのチームマネジメントについて言及しています。外部サービスの導入・移行プロジェクトには技術的な知識が不可欠なことから、エンジニアである筆者がチームを取りまとめた実践例をとなります。
第１章：外部サービスの不確実性という問題
良い設計をするための１つの重要な論点として「不確実性の最小化」があります。
ここで重要なのが、内部のシステムに対する「不確実性」と、外部のシステムに対する「不確実性」は、それぞれ「似て非なる存在」ということです。
内部システムにおける不確実性は、社内のエンジニアでなんとか対応できる範囲が多いと言えます。あくまで、社内における不確実性に対峙するため、その対処も社内で完結しやすいためです。
一方、外部システムは「存在そのものが不確実性に満ちている」といえます。期待したレスポンスが返却されるか？というミクロな不確実性に加えて、それとは別次元のマクロな不確実性を伴います。
例えば、外部システムが「3年後にもサービスを継続している」という保証はどこにもありません。加えて「値上げをしない」という確証も（契約に入れない限りは）どこにもないのです。
つまり、外部システムの不確実性は、干渉できない範囲に及ぶため、これらの不確実性を考慮した設計を考えることは容易ではないといえます。
第２章：設計戦略のプランニング
なぜ戦略なのか？
外部サービスの不確実性に対処するためには、単なるアプリケーションの設計はもちろんですが、その大前提となる「設計戦略」が鍵を握ります。
あえて「戦略」という仰々しい単語を使う理由は、その影響力の時間軸が長いからです。戦略を間違えると、リリース直後は問題が発生しなかったとしても、数年後に苦労します。出発点である戦略を間違えた場合、改修コストへの投資が必要になりますが、こうなると当然、ROIも低下するため、経営的にも好ましくありません。
つまり、方向性を間違えることは将来にわたってビジネスに好ましくない影響を与えることを意味するため、設計の上位概念である「設計戦略」が必要になるということです。
取り替え可能性を考慮して設計する
「外部サービスの取り替え可能性」を考慮した設計こそが、不確実性の最小化にあたって有効な方針となります。
取り替えが可能であれば、別の代替サービスへの移行や、代替機能の開発（内製化）が容易になります。そして、仮に、外部サービスで「値上げ」や「サービス停止」といった不確実な事態が発生した場合に、影響を最小限に抑える最後の砦になります。
ただし、この設計方針は、競合製品が存在する「コモディティーな市場」でしか取り得ない選択肢になります。
逆に、代替が存在しない「独占的なサービス」を利用する場合は、価格決定権は外部サービスの側にあります。さらに、代替サービスの登場は考えにくいため、取り替え可能な状態にする必然性に乏しいといえます。
この意味で、外部サービスの利用を前提とした設計戦略を考える上では、外部サービスのビジネス上の競争環境や、経営状況の見極めが必要になります。
このうち、外部サービスの経営状況は、財務の分析によって明らかにできます。米国企業であれば10K（Security Report）、日本企業であれば有価証券報告書が、そのサービスの置かれた競争環境を示す材料になります。
今回のプロジェクトではAkamai（証券コード：NASDAQ: AKAM）が提供するサービス「Akamai Image Video Manager」の利用を前提としたため、Akamaiが公表した2021年の10Kについて、ざっくりと目を通しました。
https://www.ir.akamai.com/sec-filings
責務を１つのリポジトリに集約する
今回の「Akamai Image Video Manager の導入プロジェクト」では、画像配信基盤を「取り替え可能な状態」にするという設計戦略を採用しました。
具体的な実現方法は、外部サービスを利用した画像配信に関する責務を、１箇所のリポジトリに集約するということです。
従来のBASEにおいては、複数のリポジトリに画像配信の外部サービスのコードが点在しており、責務分離の観点であまり好ましい状態ではありませんでした。
そこで、画像配信に関する実装上の責務を１つのリポジトリに集約することによって、疎結合の実現を目論みました。
第３章：設計戦略を実行するチームマネジメント
エンジニア駆動のチームマネジメント
筆者の普段のBASEでの仕事は、コードを読み書きすることなので、プロジェクト関連のマネジメントには関与しません。
ですが、今回の「Akamai Image Video Manager の導入プロジェクト」においては、プロジェクトチームを取りまとめました。
その理由は、このプロジェクトを回すためには、エンジニアリングの専門的な知識が必要だったからです。
一般的なBASEの社内プロジェクトであれば、プロダクトマネージャの元に、複数のエンジニアが参画して、１つの機能開発に携わることが多いといえます。
ですが、このプロジェクトにおいては、画像ファイルの基本的な知識に加えて、キャッシュやCDN、BASEのリポジトリ構成を理解する必要がありました。そこで、普段はコードを書いている筆者が、チームを取りまとめることになったのです。
なお、このプロジェクトでは、筆者は実装を行なっていません（ただしプルリクのレビューは行なっています）。
これは社内事情が影響しており、当初は取りまとめと実装を両立して行う予定だったものの、急遽実装が必要になった別のプロジェクトに追加アサインされたため、時間の都合上、Akamaiの移行プロジェクトは「取りまとめ役」に徹することになったからです。※
※急ぎの実装とは「Facebookドメイン認証」というプロジェクトで、これに関してもテックブログを書いています。→「ROI（投資利益率）を意識したエンジニアリング」
答えのない意思決定に対峙する
チームの取りまとめにあたって、実装の担当箇所の振り分けと、局所的な意思決定の２つを行いました。
１つ目の実装担当箇所の振り分けとは、（１）改修範囲の調査と見積もりを行い、（２）チームの各メンバーに実装箇所を割りあて、（３）リリースに至る手順を交通整理する、ということです。
２つ目の局所的な意思決定とは、リリースにあたって実装以外で決めなければならないことについて、社内の担当者と調整したうえで決定することです。今回は「ショップに対するコミュニケーション」と「APIの互換性」という２点で、意思決定を行う必要がありました。
「ショップに対するコミュニケーション」とは、BASEの顧客であるショップへの通知のことを意味します。画像配信基盤の移行にあたって、画像表示の仕様が微妙に変化することが避けられなかったため、利用者の方にその内容を事前にお伝えすることが必要でした。
この際に、どのような方法（メールなのか？管理画面なのか？）でお伝えするのかを判断する必要があり、プロダクトマネージャの方の大きな助けを借りつつ方針を決めています。
「APIの互換性」とは、BASEが外部に公開しているAPI（BASE-API）への影響を加味することです。
Akamaiへの移行によって、BASEが提供するAPIの構造には変化はないものの、画像関連の「パス」が変更されるため「潜在的に影響あるかもしれない」という懸念がありました。
従来の画像パスとの互換性を残すか？それとも残さないか？というのは非常に難しい問題で、BASE社内の各方面の責任者の方と相談しつつ、方針の決定に至りました。
これらの経過を経て、2021年11月ごろまでに「Akamai Image Video Manager の導入プロジェクト」は無事に終了しました。
協力していただいた社内の皆様、チームの方々に大感謝しております。
終わりに
筆者の個人的な見解として、インターネット業界では、2020年代を通じて外部システムが提供する機能のボリュームは増え続け、業界全体でAPIなどを通じた外部サービスとの連携が１つの主戦場になると見ています。
近い将来、エンジニアは「外部サービスの不確実性をいかに最小化するか」という問題に、より一層、真剣に対峙する必要が出てくるでしょう。
その際に、このテックブログの内容が少しでも参考になれば幸いです。
最後にいつもの宣伝です。BASEでは各職種で採用を強化しておりますので、お気軽にお声がけください！
