Scrumで売上があがるのか - Scrum Gathering Tokyo 2014

Scrumで売上があがるのか

株式会社シャノン　技術統括役員　堀　譲治

14年1月17日金曜日

自己紹介

14年1月17日金曜日

•シャノンで技術部部門と製品のマネジメント（Product Owner)

•前職はOracleの開発部門でアプリケーションサーバのエンジニアリング担当

• 2005年に入社し現行サービスを翌年リリース。８年目。

14年1月17日金曜日

今回公募した理由

Product Owner（営業、マーケティン

グ、経営）

Agileコミュニティ（開発）

非常に情報が少ない。寂しい。

14年1月17日金曜日

•シャノンについて• Scrumを導入した理由• Scrumの４つのビジネス的メリット• Product Ownerとしての７つの失敗• Scrumで売上はあがるのか

本日のお話

14年1月17日金曜日

シャノンについて

14年1月17日金曜日

14年1月17日金曜日

• 大手企業・外資中心に年間利用200社、イベント利用200社• 月額＋導入費のB2Bサービス• 累計12万キャンペーン、月間5000キャンペーン• マーケティング管理市場で3年連続TOPシェア（ITR）

8

他、多数

14年1月17日金曜日

毎年140％成長2010 2011 2012 2013 2014

売上

14年1月17日金曜日

Scrumを導入した理由

14年1月17日金曜日

あれは2008年末サービスをローンチ

して2年

14年1月17日金曜日

当時の課題

•開発はデスマーチ•マイナーは速いのに、メジャーリリースできない

•事業サイドと疎遠14年1月17日金曜日

当時の疑問

•日本は製造業だけなぜ強いのだろう？

•エンジニアの力量は変わらないのになぜアメリカは強いのだろう？

14年1月17日金曜日

R&Dの比率

• Salesforce.comで14%、Oracleで13%程度

•日系企業は半分を超えるところもある•シャノンでも２００９年で４０％程度

14年1月17日金曜日

Scrumへシフト•売上に対する開発コストを徐々に減らし、営業・マーケティングをウェイトを大きくあげていくことを決めた

•そのためにも少ない開発リソースで効率的かつ営業・マーケティングと連動した形で開発する手法を編み出したかった

14年1月17日金曜日

シャノンにとっての

Scrumの４つのビジネス的メリット

14年1月17日金曜日

1.売上が早くつくれる

14年1月17日金曜日

通常の開発サイクル売上

時間

開発機能A

開発機能B

開発機能C

リリース

売上

リリースしてから売上が計上14年1月17日金曜日

Scrum型サイクル売上

時間

開発機能A

開発機能B

開発機能C

リリース1

売上リリース2 リリース3

売上を早くつくれる14年1月17日金曜日

2.顧客接点の増加

14年1月17日金曜日

頻繁なリリースのメリット

•大量の機能リリースは認知できない•イテレーションが増える、つまりリリース回数を増やすと顧客接点が増加

•営業の既存顧客往訪機会•マーケティングでのキャンペーン展開

14年1月17日金曜日

３.人員コストの平準化

14年1月17日金曜日

年に１度のリリースだと...

•まず、QA（テスト）がその時期だけ大量に人員確保が必要に

•サポート・マーケもリリースピークにあわせた人員確保要

•ビックバンリリースは品質も不安定に。。

ピーク時にあわせた採用が不要14年1月17日金曜日

４.失敗リスクの最小化

14年1月17日金曜日

一度プロジェクトが始まると。。

•始めるまでは詳細に検討してても、始まると誰も止められない。。

•イテレーションのタイミングで意思決定を挟むことが比較的容易

•失敗PJを止めて新規PJ開始することでROIを最大化できる

失敗したら「やめる」ことでROI最大化14年1月17日金曜日

ゴールはいつも開発の成功ではなく事業

の成功

14年1月17日金曜日

プロダクトオーナー

開発

役員

営業・マーケティング・顧客

開発の失敗は事業の失敗に直結することは多くはない

14年1月17日金曜日

プロダクトオーナー

開発

役員

営業・マーケティング・顧客

事業の失敗は開発以外の部分で決まる

14年1月17日金曜日

Product Ownerとしての７つの失敗

14年1月17日金曜日

１.顧客課題にフォーカスしてない

14年1月17日金曜日

• 「機能」の要望を顧客・営業から聞いてしまう。本当は「課題」を把握しなければならない

• この質問に答えられるか？• 誰のための• どんな課題を• 今いくらでどうやって解決しているのを• 自分たちはどうやって解決するのかもっとも難しいのは「課題が何か」を知ること

14年1月17日金曜日

２.一部顧客をみてマーケットをみてな

い

14年1月17日金曜日

•「声の大きい」「お金を払っている」顧客の要望を優先してしまう

•マーケット全体のニーズ把握、将来のニーズに気を配ってない

常にマーケット全体からみる

14年1月17日金曜日

３.優先度の決め方に責任感がない

14年1月17日金曜日

•昔、事業系部署の全マネージャから投票で優先度を決めたことがありました

•誰もその意思決定に責任をもてなかった。。

•売上数字を持つ責任者が優先度決定に深くかかわるべき

•シャノンではスポンサーを定義プロダクトバックログは事業責任者のコミット必須

14年1月17日金曜日

４.収益シナリオを把握してない

14年1月17日金曜日

• どうやって売っているかを把握してますか？• マーケ戦略、営業戦略の把握• マーケ：マーケティングのイベント、キャンペーン、各種手法、リードソースの種類、想定見込み客数

• 営業：重要顧客、業種、顧客数、商談単価、リードタイム、受注率

• リピート率・解約率戦術のレベルまで数値把握し、その上で優先度調整

14年1月17日金曜日

５.顧客の導入障壁を理解してない

14年1月17日金曜日

•機能を使い始めた後のことばかりに集中して、使い始めの障壁に気を配らなかかった（設定変更、既存機能とのコンフリクト、システム移行、価格、導入サービス etc）

•製品企画に必ずいれる

「使い始める」シナリオを明らかに

14年1月17日金曜日

６.開発は管理してるのに企画を管理して

ない

14年1月17日金曜日

• 開発にはスケジュールのことをいろいろ言う割に製品・事業企画のスケジュールが管理できていない

• すぐオーバーコミット状態に• プロダクトマーケ：販促資料、社内説明会、WEB変更、価格決定、展示会、キャンペーン、ベータ顧客、プレス etc＝＞シャノンでは５６のプロセスを定義

• Product Requirements Documentをテンプレート化（２０-３０枚程度のPPT：目的、スコープ、マーケット、アーキテクチャ、ストーリ、制限事項、非機能要件等）

事業の企画も管理プロセスが必要

14年1月17日金曜日

７.技術的負債を無視している

14年1月17日金曜日

• 収益に直結しないシナリオを軽視しがちだが、確実に痛い目にあう

• 大きなプロジェクトの10-20%程度まではリファクタリング工数とする

• 小さいプロジェクトではやらない（デグレリスク）• リファクタリング単体のプロジェクトはやらない• パフォーマンス向上などをセットにすると負債を返済しやすい

ビジネスメリットを理解した上で負債を返済

14年1月17日金曜日

まとめ

14年1月17日金曜日

Scrumで売上はあがるのか？

14年1月17日金曜日

プロダクトオーナー

開発

役員

営業・マーケティング

ここ大事

14年1月17日金曜日

やったからあがるわけではありませんが収益部門が開発部門の「舵取り」をしやすくなるフレームワークだと思い

ます

14年1月17日金曜日

ご清聴ありがとうございました

14年1月17日金曜日