Nstockでもデータを見たくなってきた
Nstockでは、株式報酬SaaSを提供しています。（以下SaaS）
複数のお客様へのご提供が開始され、実際にSaaS上でもストックオプションの登録や権利者（ストックオプションの付与が完了した人のこと、社員や従業員など）の登録が行われています。
職種を問わずSaaS全体の状況を簡単に可視化するために、いわゆるBIツールを導入したくなりました。
👀 株式報酬SaaSのデータの特徴
株式報酬SaaSで取り扱う情報は、主に従業員情報とストックオプション情報です。誰にどんな(いくつの)ストックオプションがいつから付与されているかのデータを所有しています。直接的にお金や残高を持つわけではないですが、「誰がどれだけの株（相当）を所有しているか」という特性上、センシティブな情報と考えられます。
他方で、公開株の取引とは違って、ストックオプションは大量の取引はありません。まだSaaSでは行使機能を提供できていませんが、将来的に提供したとしても一日に大量のトランザクションが発生する。といったことは少ないと考えています。
選定にあたって
「初期的なBIとして小さくスタートする」という方針のもとに、最初に観点の洗い出しを行いました。以下が最初に作成したドキュメントの一部です。
SaaSのBIに必要な特性を定義し、反対に「今回は見送った特性」も明記することで決定フローを残しました。（ADRの考え方に近い）
💡決定ポイント① データウェアハウスをつくるのか
SaaSではAmazon Auroraを利用しています。
新たにデータウェアハウスを構築するか、リードレプリカを用意して直接BIツールを接続するかを考えました。
現時点ではAurora以外のデータソースをほぼ使っておらず、CRMツールやAnalyticsツールとの接続も不要であり、SaaSのデータがビジュアライズできれば十分と判断し、 「データウェアハウスは構築せずに、BI環境から直に接続する」 ことを選択しました。
💡決定ポイント② 現時点でのNstockのBIに求められる必要特性を定めた
「ミニマムにスタートしつつも、守るべきところは守る。」の大方針のもと、 「セキュリティ・権限管理、コスト、保守性」 の３つを重視し、それ以外の項目に関しては備考にとどめました。
必要特性に従って検討をすすめたのがコチラ。（画像は一部）
結果的に「Amazon QuickSight」にした
最終的に「Amazon QuickSight」をSaaSのBIツールとして選定し、30日トライアルでの試用を開始しました。結果的に正式に採用、2024/08時点でも利用中で概ね満足しています。（🍎コチラに関しては別記事作成予定）
⭐さいごに
BIツールはプロダクトとデータの特徴を分析したうえで、耐用年数がある前提で選ぶべし
今回のBIツールの選定で意識したことは２つです。
- データとプロダクトの特徴から、分析環境が備えるべき必要特性を洗い出す
- 選んだ理由（必要特性）と考えなかったポイント（見送った特性）をドキュメントに残す
結果的には大規模なデータウェアハウスを構築したり、モダンなETLを作成したりということはなく、フルマネージドBIに直接つなぐという、シンプルな形で落ち着きました。
特にスタートアップのように「何年後にどんな状態である」という予測が難しくても、必要特性を定義することで、ある種の耐用年数を考えられることができると感じました。
📕参考リンク
必要特性というキーワードは「アーキテクチャ特性」を参考にしました
風音屋さんのブログや資料にも大変参考させていただきました
Discussion