株式会社リゾーム システム企画・開発部 第4グループの平松です。
読書会の第5回目のレポートです。 第4回目のレポートは、こちらになります。
読書会の題材
前回に引き続き 入門 監視 ―モダンなモニタリングのためのデザインパターン を題材としています。
5回目レポート
今回は、5章「ビジネスを監視する」で、参加者は5名でした。
それぞれの感想・意見交換
ビジネスKPI
- KPIはメトリクスって言われたら確かに。
- これらのメトリクスはサービスを作るときに取得できるように設計しておかないと、次の打ち手を考えるときのデータがない。
- 月次での推移とか作ってみたら良さそう。解約数とか、アクティブユーザー数とか。
- 結局、お客様が儲かるシステムを作らないと、現在進行系で困るし先も続かない。
- お金について語れると強い。
- 「お客様は喜んでいるか」これを開発側が意識する機会が不足している。
- ビジネスKPIを確認できるダッシュボードがあれば開発以外の人がよく見てくれる場所になるかも。
- ビジネスKPIになるうる指標は営業と開発の橋渡しになりそう
ネットプロモータースコア
- ツールやアプリを使用している時やアンケートで出てくる問いにはこのような意味があったのか。
- この手のコストが関与しないアンケートが、どの程度信頼できるデータなのか疑問に思っている。
- アプリを使っていて「評価してね」って出るのはこれの関係か。
- NewRelicだとApdexスコア？
- 開発としてもどこに満足しているかなど知っておきたい
顧客生涯価値(LTV)
- これはSC業界でやっていそうな視点
顧客獲得単価(CAC)
- SC BASE*1だと、お客様の環境へ導入するまでに、一定の期間やコストがかかっている話は度々聞く。
- それは現在の運用を補うための機能追加や修正コストであったり、関わる人数が多く施設全体への周知コストがかかるであったり、導入時の機器設置や初期設定であったり。
- これらを集計・グラフ化する術というのはあるのか。数字としては出ていそう。
- 契約が増えればいいというわけではない
- 採算が取れるかという意味でも大事だと思う
ランレート
- 貯金残高を月々の支出で割って一喜一憂するあれの会社版だろうか。
- 円安の影響なども考えると実際の計算はより複雑そう。
アクティブユーザ数
- ユーザ数に加えて、いつ使われているか、どの機能を使っているかなど詳細がわかれば開発や改善の優先度を決めやすい
2つの事例
- 事例から想像できるだけでも、いろんなメトリクスが取れる。
- もしページ毎のアクセス数や操作の流れを集計・分析していれば、客観的な数字から改善点を求めることができて良いのでは。
- ある操作をメニュー経由で頻繁に繰り返しているなら、ショートカットを設置するだけで便利になる可能性があるなど。
- 気づきを得るための監視。
- 正常よりエラーをよく見たり、エラーとユーザー利用の相関性を見ることが大事
- BOND GATE*3だと、ショップのログイン回数や各機能のアクセス数とかのメトリクスを取るのが良さそう。
- Google Analyticsでいろいろわかる
ビジネスKPIを技術指標に結び付ける
- レイテンシをつけておくのは良さそう。
- 失敗率やレイテンシに関するメトリクスも重要、なるほど。
- ここで言われている失敗率は何を含んでいるのか
- ユーザー側の設定ミスなども含めるのか等
自分のアプリケーションにそんなメトリクスはないという時は
- ないなら作れってことだよな...
- 出すように変更しましょう
会社のビジネスKPIを見つける
- ビジネスKPIを定義して、社員がいつでも確認できるようにしてみたい
- スプリントレビューで責任者とリーダーが隔週で3時間割いてくれるので、各々の情報や知見の共有もできている。
- 専門外の人と話をするというのは大事だと感じた
- どうしても枝葉の方ばかり気にして議論してしまうことがある
- 広い視点を得るためには専門外の人と話すのが良い
- 大事な見落としにも気づくはず
まとめ
ビジネスの観点から監視を行うという内容で各々ツールやアプリを使っていて経験したこと、また担当しているサービスに絡めた話などで議論しました。
この章では事業責任者からの質問に答えるための方法を学ぶというものでしたがこれらの知識を得ることで開発側から経営層や営業へのアプローチも可能になってくるのではないかと思いました。
開発者という立場からビジネスについて考える機会があまりなかっただけに今回の読書会は会社のビジネス面に対して開発側ができることについて深掘りすることができたのではないかと思います。
次回は「6章 フロントエンド監視」です。
