【勉強会メモ】Sansanの開発の現場
- 日時：2018-07-20（金）19:30 - 21:30
- 場所：楽天 大阪支社
名刺管理サービスSansanの開発現場について、PM、デザイナー、開発チームそれぞれの立場から開発を前進させている話を聞いてきました。 @mmmmao0530 さんには以前からアジャイル系の勉強会でお会いしたことがあったのと、個人的に同じtoBのサービスを展開するクラウドサービスの企業ということで以前からウォッチさせてもらっていたこともあり、興味を持って話を聞きに行ってきました。
個人的にはインセプションデッキやトレードオフスライダーの扱いどころについて今ひとつイメージできていなかったところが、ひとつのヒントを得られたことが大きな収穫でした。あとは新規ビジネスの話については理論を知るよりもやはり現場の話を聞くのが一番参考になると改めて感じました。
ビジネス仮説を検証する - Sansanの新規事業開発 -
プロダクトマネージャー 加藤 淳さん
- 新規ビジネスは不確実性が高い
- 不確実なものとどう向き合っていくか
アイデアはうまくいったけどビジネスとして成り立たないこともある
不確実なものと向き合うマインド
- 不確実なものはなにか探索し、実験と学習によって意思決定（リーン）
- 全てのアイデアを仮設と捉え、仮設がただしいか検証
なぜ仮設の検証が必要？⇒リスクを抑えるため
仮説検証とリスクの関係
- 正しくないものを作ると時間が経過するとリスクが上がる
- 顧客開発モデルは構築⇒計測⇒学習を繰り返す
- 学んだ結果、リスクが抑えられる
- 新規事業開発はこれを繰り返す
Sansanの新規事業開発
独自の価値
- 名刺から調査対象を抽出し、BtoB企業の〜（※製品に関する詳細はオフレコ推奨により自粛）
- 仮説のスタートは自社の課題から
Sansanの課題
- 自社ブランディング対策に力を入れているが、効果が不明
- 他の会社も困ってそう⇒ビジネスの予感！
仮説検証の流れ
- 課題の検証
- ソリューションの検証
↑ここまで 課題とソリューションのフィット
- 製品の検証（訂正）
- 製品の検証（定量）
↑製品と市場のフィット
後の工程になるほどお金がかかる
1. 課題の検証
解決に値する課題か？
- 課題を持っている人はいますか
- どのような課題？
- どうやって解決する？
他社も困ってそう⇒検証する
- インタビューしにいく
- 課題をもった人たちとのコミュニティ形成を始める
なんか悩んでそうな人に会いに行く
- 動かずに考えるのはだめ
- 課題を持った顧客とのコミュニティ形成を目指す
2. ソリューション検証
必要なソリューションはなにか？
- 課題を解決できそうか？
- すぐに欲しがる人はいるか？それは誰か？
- 価格モデルは適切そうか？
⇒MVPを決める
どうやって検証するか
- 独自の価値に共感してくれる最初の顧客を見つける
- インタビューではなく買ってもらう
- できるだけリアルなものを見せる
アーリーアダプターがこんなものがほしいと言ってくれる ⇒ これがMVPになる！
リアルな内容
こんな製品があるので買ってください、月額ｘｘ円です
- 価値のあるフィードバック
- リアルじゃないと得られない
- アーリーアダプターはコアな部分に投資してくれる
- 少しぐらい変わっても気にしない
検証で変わるものと変わらないもの
- 独自の価値⇒ほとんど変わらない
- 開発を進めてOK
- 価値のインターフェース⇒変わりまくる
- 開発しても無駄になる可能性がある
3. 製品の検証（定性）
- 必要とされるものをつくれたか
- つくった製品が適切か
定性情報をどう判断するか
- 1の売上になる1つの機能に集中する
- 情報を集めすぎない
プロダクトバックログの上位であるMVPの開発に集中する
- 価値を検証できれば作り込まなくて良い
確からしい情報が得られたらすばやく判断
4. 製品の検証（定量）
- 必要とされるモノをつくれたか
- 大規模に検証し、拡大へのパターンを見つける
⇒残念ながら今回はここまで（開発中）
Sansanデザインクオリティ向上への取り組み
デザイナー 佃 望さん
SansanのUIデザイン
- デザイン＝設計
- ユーザーの目的
BtoBサービスのユーザー
- 導入する人と使う人の立場が違う
- 嫌でも使わざるを得ないゆえに真摯なフィードバックを頂く
Sansanのデザイナーとしてできること
Sansanの世界観とユーザーをつなぎ混乱を排除する
プロダクトの実現したい世界
- 社内人脈をフル活用
- 出会うべき人と最短距離で出会える世界
デザイナーは各開発チームに所属
開発チームの日々
- PM：まずなにやるんだっけ
- デザイナー：なんでやるんだっけ
- 開発：どれくらいでできるんだっけ？
デザインチームの取り組み
デザインチームの課題
- 増え続ける機能・画面
- 忙しい
- デザイナーの増員
ビジュアル・体験の統一感をいかに高い水準で保つか
- 目指すはさらなるSansan体験価値の向上
チーム内のコミュニケーション強化
- GKPT（Good,Keep,Problem,Try）で業務と日々の振り返り
- ワークショップやストレングスファインダー
- 相互理解を深める
受け方・診断方法 | ストレングスファインダー®とは | ストレングスファインダーで強みを活かす 株式会社ハート･ラボ･ジャパン
デザインレビュー
- 週１回MTG
- 案件共有＆レビュー実施
- Slack上でも気軽にレビューし合う
- 制作の途中段階でも見せる
ツールのちからで業務の効率アップ
- InVisionでプロトタイプドリブンな設計
- sketchのコンポーネントを使い倒す
普段の業務では得られない新しいアイデアにふれるための＋αの取り組み
- ICE
- Sansanのクリエーターが集い創作する
まとめ
- Sansanのデザイナーとしてできること
- Sansanの世界観とユーザーをつなぎ混乱を排除する
- デザインクオリティ向上へ大切にしていること
- 綿密なコミュニケション。レビューツールを活用して制作・検証・改善のサイクルを早く回すこと
新メンバーが多いチームにおけるプロジェクトマネジメントのコツ（苦労話）
チーフエンジニアリングマネージャー 大西 真央さん
大阪拠点の立ち上げ
- 新メンバーを採用しながら新たなチームづくりプロジェクト推進
- 拠点立ち上げ
- 2017年1月 東京メンバーとリモートで仕事しながら採用活動
- 採用：2名⇒8名
どんどん新しい人が入ってきて育成環境が整わない状況だと 採用基準を下げないことが重要
- 立ち上げと育成の両輪は難しい
- 人数が増えたら育成込みで採用しても良いかもしれない
プロジェクト
時期4名のときのプロジェクト
- IDプロビジョニングの機能実装
- WebAPIを作って自動連携
チームのスペック
トレードオフ・スライダー
- 納期＞品質＞＞コスト＞＞スコープ
プロジェクトマネジメントのコツ（苦労話）
参考：アジャイルな見積りと計画づくり
アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~
- 作者: Mike Cohn,マイクコーン,安井力,角谷信太郎
- 出版社/メーカー: 毎日コミュニケーションズ
- 発売日: 2009/01/29
- メディア: 単行本（ソフトカバー）
- 購入: 74人 クリック: 764回
- この商品を含むブログ (226件) を見る
日々得られた全ての情報から計画を考え続けること
うまくいかなかったポイント
大前提として全員の認識合わせを初期にやる - インセプションデッキ - プランニングポーカー - ドラッカーエクセサイズ
その1：バーンダウンせず - 想定内 - 新メンバーの立ち上がり時期 - ドメイン知識の習得時期 - ボトルネック - 設計に時間がかかる - IDプロビジョニングの技術知識の理解 - 新メンバーの立ち上がり遅れ - ドメイン知識習得に時間がかかる
新メンバーの立ち上り遅れにフォーカス
その2：死守できなかったポイント
- ベロシティ推移が4スプリント目で理想線に比べて現実のパフォーマンスが出なかった
やったこと
- レードオフ・スライダーを再検討
- 主体性、成長の観点を追加
それでも納期優先
納期＞品質＞成長＞主体性＞コスト＞スコープ
チーム全員でリリース最優先の認識合わせ後、今後の進め方を検討
変更1：マネジメントスタイルの変更
- 学習モード⇒サバイバルモード
参考：エラスティックリーダーシップ
- 作者: Roy Osherove,島田浩二
- 出版社/メーカー: オライリージャパン
- 発売日: 2017/05/13
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (2件) を見る
変更2：プルリクレビュー＆ペアプロ専任者を用意
- 日々チェックして数字を見たうえで専任をおいたほうが早いと判断
変更3：タスクに対して作業時間の見積りを実施
- 見積り通りいかなかったら個別にメンバーと一緒に考えた
- チーム全員でサバイバルモードと決めたので見積り通りのタスク実行を徹底
⇒リリースできました
まとめ
