はじめに
この記事は、Supershipグループ Advent Calendar 2022 8日目の記事になります。
自己紹介
Ad Generationというプロダクトで、
iOS/Androidアプリ向けのSDKを開発している、 @napo と申します。
普段は .xcframeworkと.aarを開発して過ごしています。
なんの記事?
業務で、「モバイルアプリ向けのライブラリを開発する」という、あまり馴染みの少ないポジションについて、
日々、どんなことをやっていて、どんな気付きがあるか、を楽しくまとめることを目的としています。
要点
- SDK開発はたのしい
- BtoB/BtoCのどちらも並行している
- 安定性とレガシー脱却のガチンコ
- プロダクトも自分も強くなる、「お問い合わせ」対応
- 目指すのは「見やすい、わかりやすい、使いやすい」
くわしく
SDK開発はたのしい
さっそく、抽象的な表現で恐縮ですが、総じて、「楽しい」です。
感じやすいやりがいとしては、「自分の設計/実装したコードがAPIとなり、多くのアプリに利用していただける」ところです。
色々なアプリで実行されるコードなので責任は重く、何らかの問題があると、SDKが起因してクラッシュや機会損失などが発生しうるため、
そのようなご迷惑をおかけすることがないよう、品質のことを意識する比重も大きく、その分、やりがいも大きいです。
私の従事しているプロダクトのSDKは、
広告によってマネタイズをおこないたいアプリに導入いただくことで、多様な広告を複数のレイアウトで表示することがコア機能となります。
そのため、「導入アプリの収益向上=広告主の利益向上=プロダクトのグロース=自己成長」というように、
導入アプリさまのことを考えてアクションを起こし続けることが、最終的に自分の成長にもシンクロしやすい点があり、個人的に好きなところです。
BtoB/BtoCのどちらも並行している
広告に関するSDKの場合、導入アプリさまが、法人の場合と個人の場合がありえます。
また、導入アプリの用途の違いにより、B向けであったり、C向けである場合がありえます。
さらに、裏側では、他企業さまのシステムとの接続や連携などの業務もあり、その都度、仕様の調整や設計などが発生いたします。
そのため、常に「誰のための、何のためのミッションであるか」を意識して取り組むことができます。
「アプリ開発とは違ったサイクルで、意識の向き先を横断して経験を積める」ことがありがたい点です。
安定性とレガシー脱却のガチンコ
前述でも触れたとおり、導入いただいた多くのアプリで実行されうるものなので、安定性に対する姿勢に違いがあります。
導入アプリに対して、悪い影響(クラッシュ、多すぎる制約、パフォーマンス低下)などが無いよう、慎重さが求められます。
しかし、社内/社外問わず、市場からの要望は日々あるため、機能追加や改修が止むことはありません。
また、SDK開発の技術的な面においても、Google/Appleなどのプラットフォーマーからのアップデートがあり、レガシー化しやすい側面もあります。
そのため、アプリ開発でも同様のことが当てはまりますが、
品質
x機能アップデート
xレガシー返済
のバランスを見極めてリリースに望んでいます。
プロダクトも自分も強くなる、「お問い合わせ」対応
導入アプリさまから日々お寄せいただく、お問い合わせには多くの学びがあります。
「意図した表示にならない」というような利用方法に関する点や、
「なぜこうなるのかわからない」というAPI設計に関するご指摘、
「エラーになっている/なっていないが、これはどういった意味か?」という事象に対する不明点など、
いずれも、ヒアリングをさせていただいて、調査をおこなって原因究明し、解消/実現したいことがクリアできるようご案内をすることがゴールとなります。
SDKという立ち位置の場合、提供しているAPIをどのように実行いただいているかコードを拝見させていただくことは難しく、
事象を手元で再現できたり、デバッグログを確認できたりすることも難しいケースが想定されやすいため、
導入アプリさまのご負担が大きくならない範囲で、状況に対する簡潔なヒアリングをさせていただくことが1歩目となります。
お問い合わせでは、テキストベースのやり取りがメインのため、
- 前提となる事象への解釈に相違がないようにする
- 文章の最初から最後までの見通しが立ちやすくする
- 最小限のヒアリング数にする
- ヒアリング事項には、意図している背景を併記する
- お客様の状況にあわせて、正常に動作するサンプルプロジェクト/スクリーンショット/動画 など、視覚的または明瞭にお伝えできる情報を極力追加する
- お客様の立場での言葉を選択し、結果を誘導しうるような表現にしない(前提知識や背景を推し量って回答に極力影響しない言葉の選択をする)
- どこに問題点があるか、あらゆる可能性を排除せず、包括的な視野で解釈と調査に努める
など、意識をして日々向上させるべき観点が凝縮されています。
導入アプリさまにとって、お問い合わせのアクションをしてくださるのは、コストがかかることかと存じます。
だからこそ、1つ1つのお問い合わせを迅速かつ正確に真剣に向き合いたいと考えています。
目指すのは「見やすい、わかりやすい、使いやすい」
SDK開発に限らずですが、
- 達成したい機能が備わっていること
- 安心して実行できること
- 挙動が予測しやすいAPIであること
- ドキュメントが充実していること
- サンプルコードが充実していること
- FAQが充実していること
などを意識して、
「ご利用が継続しやすい環境作りを、利用者さまとのタッチポイントに対して包括的に施策を講じる」
ということを目指して、日々改善に取り組んでいます。
これから
前述にて、 「品質
x機能アップデート
xレガシー返済
のバランス」 という点に触れましたが、
- 品質 : テストコードの充実化/状態や挙動に不整合がおきにくい設計
- 機能アップデート : 着手から市場リリースまでのリードタイムを短縮し、付随する手動作業の自動/省力化をおこなう
- レガシー返済 : Java→Kotlin / Objective-C→Swiftの言語コンバートや、時流と共に陳腐化/複雑化してしまった既存設計のリファクタリング
に取り組み、利用者さまにとって、よりメリットになるリリースをおこなっていきたいと考えています!!
さいごに
明日は、新規事業にも精力的に活動されていて、僕が尊敬している、 @masayannuu さんの記事です!お楽しみに!
PR
Supershipではプロダクト開発やサービス開発に関わる人を絶賛募集しております。
ご興味がある方は以下リンクよりご確認ください。
Supership株式会社 採用サイト
ぜひ、よろしくお願いします!!!