概要
モバイルアプリケーションのログ設計を考えるにあたり、何か良い本がないかを探したところ、入門 監視が良さそうだったので長期休みを使って一読しました。
どの章も面白かったのですが、その中でもビジネスの視点からアプリケーションを監視するということにフォーカスした章があり、エンジニアとして考えたことのなかった視点から解説していたため、興味深かった箇所をメモとして残しておきます。
詳細
KPI
KPIはビジネスが良い状態であるために会社が重要だと認識している計画の状態を測るための指標です。
一般的に、経営者の視点の関心は以下のようなものです。
- 顧客はアプリケーションあるいはサービスを使えているか
- 儲かっているか
- 成長しているか、縮小しているか、停滞しているか
- どのくらい利益が出ているか。収益性は改善しているか、悪化しているか、停滞しているか
- 顧客は喜んでいるか
つまり、現在会社は儲かっているか、将来に向けて儲かるような状態を作れているか、またはその両方を満たしているかを測りたいということになります。
上記のような関心を持った経営者の質問に事業責任者が答える時、以下のような指標を出して説明を行うことが多いとしています。
- 月次計上収益
- 顧客からの月毎の経常収益
- 顧客あたりの収益
- 課金顧客の数
- ネットプロモータスコア(ユーザーあるいは顧客満足度の指標のこと。よくある「このアプリを友人に薦めますか？」という10段階のアンケートはこれを測るためのもの)
- 顧客生涯価値(Life Time Valueとも。1人もしくは1社が生涯にわたって企業にもたらす利益。顧客当たりの収益との違いは顧客当たりの収益は年単位、こちらの単位は生涯に渡って計算されること)
- 顧客あたりのコスト
- 顧客獲得単価
- 顧客の解約数
- アクティブユーザー数
- バーンレート(会社全体でどれくらいのお金を使っているか)
- ランレート(現在の支出を続けた場合に資金がなくなるまでの期間)
- TAM(ある特定のマーケットがどのくらいの大きさなのかの指標)
- 粗利(販売したもののコストを除いた利益を表す指標)
など。
補足となりますが、この記事で列挙している項目に対してより深く解説をしているこちらの記事を読むと、より理解が深まります。
YelpとRedditの事例
Yelp
Yelpはローカルビジネスと人々を繋げるオンラインプラットフォームで、以下のような特徴があります。
- ローカルビジネスを探している人(レビューを書くユーザー)とビジネスページを管理するビジネスオーナー(レビューに返事をするかもしれないユーザー)が存在している
- ビジネスオーナーはビジネスページを「無料」で取得でき、Yelpはビジネスオーナから広告費用を徴収することでサービスをマネタイズしている
これらの記述だけでもビジネスKPIを作ることができます。
- 検索実行
- レビュー投稿
- ユーザーのサインアップ
- ビジネスページの取得
- アクティブユーザー
- アクティブビジネス
- 広告購入
- レビューに対する返事
これらを計測することで直感的にビジネスの状況を把握することができます。
つまり、儲かっているか、将来に向けて儲かるような状態を作れているか、またはその両方を満たしているかを把握することができる、ということです。
RedditはSNSで、Redditには以下のような特徴があります。
- ユーザーはアカウントを作らなくてもRedditを閲覧可能である
- スレッドを投稿したり、コメントを付けたり、投票したり、プライベートメッセージを送信するにはアカウントが必要
- 広告、有料アカウントにグレードを設けるなどの手段でマネタイズを行っている
こちらもYelpと同様に、主要機能に対してのビジネスKPIを作ることができます。
- 現在サイトに滞在しているユーザー
- ユーザーのログイン
- コメント投稿
- スレッド作成
- 投票
- プライベートメッセージの送信
- 有料アカウントの課金者数
- 広告購入
主要機能に関連するビジネスKPIを計測することで直感的にビジネスの状況を把握することができます。
これらのビジネスKPIは、実は技術指標に結びつけることが可能です。
例えば、ユーザーのログインというビジネスKPIを、ユーザーのログインの失敗、ログインのレイテンシというような技術指標と結びつけます。
技術的な指標に結びつけることで、ビジネスKPIのみを設定するときよりも細かいレベルで「アプリケーションが動作しているかどうか」という質問に答えられるようになることがメリットです。
会社のビジネスKPIを見つける
全てのビジネスは異なるので一般化するのには無理があります。
ただ、何を計測するかを判断するときに間違いない方法があります。
それは「人と話す」ことです。
どういった人と話せばよいかというと、まず第一にプロダクトマネージャーです。プロダクトマネージャーの仕事は顧客が何を必要としているかを理解し、それを実現するためにエンジニアリングチームと協力することです。
多くのプロジェクトマネージャーは何が問題なのかを高いレベルで把握していることが大きな理由です。
その次にソフトウェアエンジニアリングチームのマネージャー、シニアソフトウェアエンジニアと話せば何が問題で、どのように問題点を理解できているはずです。
そういった「人と話す」状況で著者がよく使う質問は、
- 私が会社に入りたてだとして、アプリケーションが動いていることをどうやって知ったら良いでしょうか？何をチェックしていますか？どう動いていたらよいのでしょうか？
- アプリケーションのKPIは何ですか？ なぜそのKPIを使っているのですか？ そのKPIはどんなことを教えてくれますか？
というものとされています。
感想
冒頭でも述べている通り、普段あまりビジネスの視点からアプリケーションを深く考察することがないため、勉強になりました。
アプリケーションログを設計する時にこれを取っておくとビジネス的な視点から分析するときに役に立つよね、という考えを事前に持つことができたのはこの章のおかげだと思います。
ただ、関わっているアプリケーションが社内向けのアプリであり、直接的な儲けを出さない場合、計測はどのように修正すれば良いのか？という疑問が少し残る部分もありました。
それも、既存の業務の置き換えの場合ならまだしも、完全新規の社内向けアプリとなると経営陣の欲しい情報は十分に取れるのでしょうか。
どこかにそんな事例を紹介した記事があれば読みたいです。情報お待ちしています。