Upgrade to Pro — share decks privately, control downloads, hide ads and more …

ユーザー課題を解決しプロダクトを成功に導く方法とCREの役割 / july-tech-festa-2021-7-18

missasan
July 18, 2021

ユーザー課題を解決しプロダクトを成功に導く方法とCREの役割 / july-tech-festa-2021-7-18

ユーザー課題を解決しプロダクトを成功に導く方法とCREの役割
July Tech Festa 2021

missasan

July 18, 2021
Tweet

More Decks by missasan

Other Decks in Technology

Transcript

  1. 2021.7.18 July Tech Festa 2021 #jtf2021 #jtf2021_a id:missasan / @mur_ms_

    ユーザー課題を解決しプロダクトを 成功に導く方法とCREの役割 1
  2. missasan(みっささん) 三浦 美沙 (ミウラ ミサ) 所属:株式会社はてな Mackerelチーム CRE はてなid: id:missasan

    Twitter: @mur_ms_ 略歴 • 某SIer企業でインフラエンジニア(SE) • 某MSP企業でテクニカルセールス • 2018年3月〜 現職 自己紹介 2
  3. Mackerel とは? • サーバー監視サービス • 国産 SaaS • 直感的なUI/UX •

    簡単に導入できる • 監視という専門領域を民 主化 • コアユーザーはインフラ エンジニア・SRE 4
  4. • Customer Reliability Engineer • 日本語に直訳すると「顧客信頼性エンジニア」 • 2016年にGoogleが提唱した • はてな

    では、2017年に Mackerel チームで発足 プロダクトを導入・活用するユーザーの課題解決をミッションとするエンジニア CRE とは? 5 CREのミッション 顧客に寄り添い、顧客が抱える真の課題にフォーカスし、 その課題を技術を軸として顧客と共に解決を図る
  5. カスタマージャーニーと課題の例 8 導入 活用 拡大 約3ヶ月 約1年 Mackerelによる監視・運用の設 計・導入 Mackerelを中心にした障害対応

    の実施 本格的な運用開始 Mackerelの応用機能の活用 DevOps・SREプラクティスの導 入 Mackerelを用いた監視・運用ノウ ハウを複数事業・部署に展開 新しいアーキテクチャへの導入 素早い導入 最適な設計の模索 チームでの知見共有 障害対応時間の短縮 運用コストの削減(自動化) システム改善への適切なフィー ドバック 大規模な導入による管理の煩雑 化 スピード感とガバナンスのバラ ンス 課題 CRE は フェーズ・課題にあった支援を提供 フェーズ
  6. 課題の解決方法 • 基本的にはユーザーの自走を目指す 9 方法 特性 テクニカルサポート 素早い解決。自走のためのアシスト。 セミナー・ハンズオン 全体像や体系立った概念を伝えられる。知識の下地づくり。

    ヘルプドキュメント・ブログ すでに蓄積されたノウハウをユーザーが触れやすい状態にする。 プリセールス ユーザーが課題にぶつかる前に下準備する。 プロダクトのアップデート (フィードバック) ユーザーが自走できるための根本解決。 課題に対して適切な打ち手を選択し、心地よいタイミングと速度で提供する
  7. ユーザーについての理解を深める 課題を正しく理解するためには、背景について深く理解する必要がある • ユーザーインタビューから知る ◦ 対象のシステムについて知る ◦ 運用組織について知る ◦ 組織文化について知る

    • データから知る ◦ 機能の利用状況について知る ◦ 全体から見たそのユーザーの特性を知る 11 ユーザーの理解を深める=課題の輪郭を明確にする
  8. • 課題の優先度を見極める • 支援が必要なもの、自走を促すものを見極める • チェックポイントの例 ◦ 一般的な事例か、個別事例か ◦ プロダクトビジョンとマッチするか

    ◦ ワークアラウンドはあるか ◦ ...etc 課題の”目利き”の重要性 12 実装方法を提案する 開発チームに フィードバックする ワークアラウンドを提案 する プロダクトで解決できる No Yes No プロダクトを改善すれば 解決できる 頭の中で分岐を思 い描いている Yes
  9. 課題や背景のフィードバック 必ずしも機能要望と合致していなくても エンジニアが最適解を提案できる 開発チームには課題(≠機能要望)をフィードバックする 課題や背景 機能要望 開発チーム プロダクト機能 ユーザー 課題や背景

    機能要望 開発チーム プロダクト機能 ユーザー フィードバック フィードバック 機能要望のフィードバック 課題に対する改善策が限定的にな る恐れがある
  10. • 課題・課題の背景 ◦ ユーザーが解決したい課題は何か。 ◦ なぜ解決したいのか。解決されることによるユーザーのアウトカムは何か。 • ユーザー ◦ 誰の声か。

    ◦ そのユーザーは、チームが認識しているどのペルソナに当てはまるのか。 • 解決のアイディア ◦ ユーザーから実際に上がった具体的な機能要望。 ◦ ユーザー・プロダクト双方を理解したCREが考える解決策の一例。 ◦ (注意:ここでのアイディアが採用されるとは限らない。でも気にしない) • ビジネス的な背景 ◦ ビジネス的な狙い ◦ ユーザーとの関係性 フィードバックテンプレート
  11. おまけ:自分の経験からの教訓 18 • とはいえ事前にユーザーと仕様を合意する必要がある場合もある ◦ 課題解決に繋がる最小限の仕様を合意する ◦ なるべく自由度をもたせて開発チームが提案できる余地を残す • 背景を正しく共有するため開発チームとコミュニケーションする

    ◦ コミュニケーションのために開発チームのリソースを奪うことを恐れない ◦ リソース配分も含め開発チームに任せる • ◯◯社用コードを生み出さないよう心がける ◦ 開発コストが低く見えたとしても安易に選択しない ◦ 機能を限定せず公開機能としてリリースできる道を開発チームと探る