こんにちは、エンジニアの@tanakoです。
PLAIDでは、CX（顧客体験）プラットフォーム<a href="https://karte.io/">KARTE</a>の機能を iOS / Androidのネイティブアプリから活用できる <a href="https://karte.io/product/app/">KARTE for App</a> のSDK（以降 SDK）をAppチームで開発しています。
さて、Appチームは去る4/7にSDKをOSS化し、ソースコードをGithub上で公開しました 🎉
<ul>
<li><a href="https://github.com/plaidev/karte-ios-sdk">iOSリポジトリ</a></li>
<li><a href="https://github.com/plaidev/karte-android-sdk">Androidリポジトリ</a></li>
</ul>
またOSS化に伴い、SDKをv2（以降 v2）にメジャーアップデートしました。今回は、SDKをOSS化して解決したかった課題や、v2メジャーアップデートの概要、チームとしての取り組みをいくつか紹介します。(この記事は社内勉強会で@wasnotが発表した内容を基に、@tanakoが加筆修正したものです。)
<h2>KARTE for App SDKについて</h2>
前提知識となるSDKについて簡単に説明します。SDKは、イベント送信APIやJavaScriptモジュールを読み込むコンポーネントを内包しており、管理画面で記述されたHTML/CSS/JavaScriptをSDKが管理するWebView（iOSではWKWebView）に読み込むことでアプリ内メッセージを表示できます。
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/24b3914e-72e7-4c6a-a7fe-03abb2acea98/----------0030-12-22-16.27.18-1.png" alt="">
<h2>OSS化の背景</h2>
KARTE SDKは他の一般的な計測SDKと異なり、活用の仕方によっては積極的にアプリのUIに介入できます。また、OSS化以前のv1 SDK（以降v1）はほぼクローズドソースで提供されていたため、自社アプリへの影響を心配する、次のフィードバックがいくつかのクライアントからありました。
<ul>
<li>コードの品質を直接確認できないため導入に不安がある</li>
<li>SDKアップデート時の差分をコードレベルで把握できず影響が読めない</li>
</ul>
これらの不安に対して我々がSDKの品質に問題ないと言ったところで、それを明確に証明する材料はなく説得力も持ちません。
このようなクライアントに安心して利用してもらうためにも、ソースコードの公開が必要と判断しました。
<h2>OSS化によって提供できる価値</h2>
OSS化するにあたり、利用者に提供できる価値を次のように明文化しました。
安心感の向上
<ul>
<li>SDKの品質に問題がないか確認できる安心感</li>
<li>内部挙動を正確に把握できる安心感</li>
</ul>
信頼性の向上
<ul>
<li>第三者が開発に参加することによる信頼性の向上</li>
<li>多数の開発者の目に触れる（問題のあるコードは速やかに報告され修正されやすい）</li>
</ul>
透明性の向上
<ul>
<li>開発プロセスの見える化</li>
<li>コードの変更経緯が追える</li>
</ul>
これらの価値提供でクライアントの不安は払拭できる一方で、単純にOSS化するだけでは、次に挙げる価値を直接提供することはできません。
OSS化だけでは提供できない価値
<ul>
<li>機能性</li>
<li>拡張性</li>
<li>保守性</li>
</ul>
<h2>OSS化にあたり事前に決めたこと</h2>
えいやでソースコードを公開できれば楽ですが、当然OSS化後も開発は続きます。効果的、効率的にOSSを運用するにあたり次の点を決める必要がありました。それぞれどのような観点で決定したかを紹介します。
<ul>
<li>ライセンスの選定</li>
<li>開発・リリースフローの検討</li>
<li>バージョニングポリシーの変更</li>
</ul>
<h3>ライセンスの選定</h3>
OSSとしてソースコードを公開するにあたり、コードのライセンスについて検討・選定しました。MIT、Apache 2.0、BSDや独自ライセンスなどが候補に挙がりましたが、社内有識者やリーガルチームと相談・議論し、条項の読み合わせを行なった上で、 次の理由で<a href="http://www.apache.org/licenses/LICENSE-2.0">Apache 2.0 License</a>を採用しました。
<ul>
<li><a href="https://opensource.org/">OSI</a>の承認ライセンス</li>
<li>利用率の高さ（非コピーレフトだとMITの次点）</li>
<li>特許紛争に関する特記事項の存在</li>
</ul>
特に特許紛争に関する特記事項が記載されていることはクライアントに安心して利用して頂く上で重要なポイントです。
ライセンスの検討にあたっては、「<a href="https://www.amazon.co.jp/OSS%E3%83%A9%E3%82%A4%E3%82%BB%E3%83%B3%E3%82%B9%E3%81%AE%E6%95%99%E7%A7%91%E6%9B%B8-%E4%B8%8A%E7%94%B0-%E7%90%86/dp/4297100355">OSSライセンスの教科書</a>」を参考にしました。「OSSマトリョーシカ問題（OSS内で利用するOSSが競合するライセンスを持っている状態）」という言葉を知り、事前にSDKが依存するOSSについて精査できたのもこの本のおかげです。
<figure><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/3f5ef028-d97b-4d82-ac79-be19ea1ba4cd/----------2020-04-23-20.04.44.png" /><figcaption>上田 理 (2018)．　OSSライセンスの教科書，図9.2 OSSマトリョーシカ（OSSの中にOSSが入っている）</figcaption></figure>
<h3>開発・リリースフローの検討</h3>
開発中の新機能や特定クライアントのissue等の開示は難しいため、当面はそれらの開発プロセスはPrivateにすることにしています。適切に公開範囲をコントロールするため、開発・リリースフローを次のリポジトリ・CI構成で行うことにしました。
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/27bdb86e-1762-44f1-8243-e5927af06ea7/----------2020-05-08-18.45.29.png" alt="">
Publicリポジトリではソースコードの公開だけでなく、issueやPRの公開・受付も行います。また、OSS化することを優先したため、当初PRの受付はバグ修正に限定しています。機能追加のPRは受け入れ体制が整い次第少しづつ受け付ける方針としています。体制が整った段階で<a href="https://github.com/plaidev/karte-ios-sdk/blob/master/CONTRIBUTING.md">CONTRIBUTING.md</a>を更新する予定です。
<h3>バージョニングポリシーの変更</h3>
v1では次の運用でバージョンアップを行っていましたが、この運用ではIFに破壊的な変更があるかどうか利用者側から影響範囲が分かりません。
<ul>
<li>微修正はpatchバージョン</li>
<li>機能追加などはminorバージョン</li>
<li>iOS/Android SDKのバージョンは揃える</li>
</ul>
OSS化するv2からは、バージョンアップがアプリケーションに与える影響を把握できるように、セマンティック バージョニング 2.0.0（以降 SemVer）に従うことにしました。これにより、バージョンアップが後方互換性を保った変更なのか、破壊的な変更なのか利用者からわかりやすくなります。
また、SemVerでメジャーバージョンの更新条件は自明となりますが、<a href="https://semver.org/lang/ja/#spec-item-7">マイナーレベルのバージョニング</a>の解釈に曖昧な点が残っていました。
<blockquote>
マイナーバージョン Y （x.Y.z | x &gt; 0）は...プライベートコード内での新しい機能の追加や改善を取り込んだ場合は、上げてもよいです（MAY）。その際にパッチレベルの変更も含めてもよいです（MAY）。
</blockquote>
これについては、<a href="https://ja.reactjs.org/docs/faq-versioning.html#minors-versus-patches">Reactのバージョニングポリシー</a>などを参考にチームで議論し次のように決定しています。
緊急性の高い不具合 
即修正してリリースしなければならない問題については、patchバージョンを上げてリリースする。この場合は master ブランチから hotfix ブランチを切ってリリースする流れとなる。
緊急性の低い不具合（考慮漏れ・仕様バグなど） 
minorバージョンを上げてリリースする。2通常のリリースフローでリリースする流れとなる。
バージョニングポリシーを明確化することで、迷いが減り迅速なリリースが期待できます。
<h2>v2 SDK（メジャーアップデート）で実施したこと</h2>
v1 SDKは、モノリシックなモジュールに多くの機能が詰め込まれており技術的負債が溜まっていました。また、利用者にとっての機能拡張性も十分に提供できているとは言えない状態でした。そのため、OSS化を良い機会と捉え、公開インターフェース及び内部実装の再設計を行い、保守性、拡張性などを高め長期的なSDKの品質維持が容易になるようにv1 SDKに対して非互換なアップデート（v2へのメジャーアップデート）を行う判断をしました。
<h3>モジュール化</h3>
v1では複数の機能が一つのモノリシックなモジュール内に詰め込まれていましたが、v2では各機能単位にモジュールを分割しました。
<figure><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/f2c4b3d6-3f24-464a-b598-409c1ff5f353/----------2020-04-23-15.14.22.png" /><figcaption>モノリシックなv1、機能毎にモジュール分割したv2</figcaption></figure>
モジュール化には次のメリット・デメリットがあると考えましたが、デメリットを加味しても利用者が要件に応じた必要最低限のモジュールを選択できること、SDKの機能追加や拡張がしやすい状態に保つことは非常に重要だと考えました。
モジュール化のメリット
<ul>
<li>要件に必要な機能だけをリンクして利用可能</li>
<li>可読性の向上</li>
<li>バグやデグレの影響範囲分離・回避</li>
<li>機能追加が容易（サードパーティによるモジュール追加も可能）</li>
</ul>
モジュール化のデメリット
<ul>
<li>一部モジュール間連携用のAPI公開が必要</li>
<li>クライアントがどのモジュールをimportするか判断が必要</li>
<li>全モジュール利用時のバイナリサイズは拡大する傾向</li>
<li>リリース等の作業が煩雑化</li>
</ul>
連携の方法について
モジュール分割により、モジュールが完全に独立して動くようになったわけではありません。各機能のモジュールはCoreモジュールに依存しており、Coreとその他のモジュールを連携させるための作業が必要になります。
この連携作業において、ツールによっては明示的な連携コードの実装が必要です。v2では、より簡単にSDKを導入できるようにモジュールがリンクされていれば自動的に連携するようになります。具体的にはCoreモジュールに各モジュールをlistenerとして登録し、各イベントを受け取る方式となります。尚、モジュールの自動登録には、各プラットフォームごとの機能を使用しています。
iOSでのモジュール連携内部実装
iOSではクラスがランタイムに追加された時に呼ばれるメソッド(<a href="https://developer.apple.com/documentation/objectivec/nsobject/1418815-load">load</a>)があり、各モジュールのクラスがロードされたタイミングで、Coreモジュールにクラスを登録できます。リンクされたクラスは基本的に全てロードされます。
<pre><code class="language-obj-c">@implementation KRTInAppMessagingLoader

+ (void)load
{
 [KRTInAppMessaging _krt_load];
}

@end

</code></pre>
<a href="https://github.com/plaidev/karte-ios-sdk/blob/6bd7e70836b94deb2823d22b7868b917b38d8f1b/KarteInAppMessaging/InAppMessagingLoader.m#L24-L31">Objective-CのloadからSwiftのload用関数を呼び出す</a>
<pre><code class="language-Swift">@objc(KRTInAppMessaging)
public class InAppMessaging: NSObject {
 ...
 @objc
 public class func _krt_load() {
 KarteApp.register(library: self)
 }
 ...
 }
</code></pre>
<a href="https://github.com/plaidev/karte-ios-sdk/blob/6bd7e70836b94deb2823d22b7868b917b38d8f1b/KarteInAppMessaging/InAppMessaging.swift#L48-L53">Swift側でのモジュールの登録</a>
Android (JVM)でのモジュール連携内部実装
JVMは基本的に初期状態ではリンクされたクラスはロードされず、呼び出し時に初めてロードされるため、iOSと同じアプローチは使えません（lazy load）。
JVMのClassLoaderにはリンクしたjar内の決められたファイルを参照する仕組みがあり、そちらを利用することで動的にリンクされたモジュールのロード・登録が可能です。
<pre><code class="language-kotlin">val libraries = ServiceLoader.load(Library::class.java)
libraries.forEach { library -&gt;
 register(library)
 library.configure(self)
}
</code></pre>
<a href="https://github.com/plaidev/karte-android-sdk/blob/0e74ddf40b17d253e658ea69b337a5ee1f74f937/core/src/main/java/io/karte/android/KarteApp.kt#L238-L243">ServiceLoaderを使用したモジュールの登録</a>
<h3>開発言語の変更</h3>
iOS / Android共に、メインの実装言語を各プラットフォームのよりモダンな言語に変更しました。iOSは Objective-C から Swiftへ、Androidは JavaからKotlinに変更しています。
言語変更のメリットを次のように考えています。
<ul>
<li>可読性の向上</li>
<li>言語の安全性向上</li>
<li>メンテナンス性の向上</li>
<li>言語背景が（ある程度）似ているため、今までよりもプラットフォーム間の共通点が多い</li>
</ul>
一方デメリットは次の通りです。
<ul>
<li>自由度の低下（安全性とトレードオフ）</li>
<li>バイナリサイズの膨張や呼び出しコスト増大</li>
<li>レガシーな開発環境のアプリでは、余計なものが増えてしまう</li>
</ul>
デメリットはレガシーな開発環境に限定されており、近年では完全にレガシーな環境のアプリは少ないと判断しました。
また、PLAIDではチームやプラットフォームの垣根なくコードを書くことが多いため、言語仕様が（ある程度）近いことによるメリットは大きいと感じています。
<h3>リファレンス自動生成</h3>
v1では、Developer Portal（Karteを利用する開発者向けのドキュメント置き場）のAPIリファレンスを、手動でメンテナンスしていました。
この方式は更新漏れでコードとドキュメントに乖離が生じやすい上に、バージョン毎の対応関係もわからずメンテナンスコストが高い状態でした。
v2からは、ドキュメンテーションコメントをソースコード内に記載し、リファレンスを自動生成することで、コードとドキュメントの乖離が起きにくくしました。iOSは<a href="https://github.com/realm/jazzy">realm/jazzy</a>、Androidは<a href="https://github.com/Kotlin/dokka">Kotlin/dokka</a>でドキュメントを生成しています。
また、バージョン毎にリファレンスが生成されるようになり、対応関係がより明確になりました。リファレンスは<a href="https://github.com/plaidev/karte-sdk-docs">GitHubのリポジトリ</a>にPushして、<a href="https://plaidev.github.io/karte-sdk-docs/ios/latest/KarteCore/">iOS</a> / <a href="https://plaidev.github.io/karte-sdk-docs/android/core/latest/">Android</a>ともにGithub Pagesを利用して公開しています。
v2では、ここで紹介した他にも、<a href="https://developers.karte.io/docs/support-policy-ios-sdk-v2">サポートポリシー</a>の刷新や新機能追加などを多く盛り込みました。興味があるかたは、ぜひ<a href="https://developers.karte.io/docs/release-notes-ios-sdk-v2">リリースノート</a>をご覧ください
<h2>OSS化とv2リリースを同時進行したことによる効果</h2>
v2へのメジャーアップデートとOSS化を同時にリリースしたことで、結果として「OSS化だけでは提供できない価値」である「機能性」「拡張性」「保守性」を付与できました。
これにより「SDK利用者の開発体験」全体を向上させることができインパクトのあるリリースになったのではないかと考えています。
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/24a49205-2570-45b6-97ae-57a40d569e89/----------2020-04-23-23.38.32.png" alt="">
<h2>おわりに</h2>
簡単にSDKをOSS化した背景、v2アップデートの概要、チームで取り組んだことを紹介しました。
まだまだ、OSS運用のノウハウは溜まっておらず、英語のみでのメンテナンスや、他開発者とのコラボレーション方法の整備に関してもスタート地点であり、その他にも多くの課題が残っています。
引き続き、透明性が高く開発者が安心して使えるSDKを提供するために改善を続けていきたいと思います。

OSSのライセンス、バージョニング、リリースフローの検討と背景、v2メジャーアップデート

KARTE for App SDKのOSS化によるDeveloper Experience向上への取り組み

BigQueryのリソース配分最適化のため、プロジェクトへのコミットメントの割り当てパターンや、スロット消費の多いクエリの見つけ方などについて調査した結果をまとめてみました

6,000スロットを使うBigQueryのリソース配分最適化への挑戦