sgt2014_gxp

Copyright© Growth xPartners, Inc. All rights reserved.

エンタープライズでタッチダウンを決めるための戦略と実践

グロースエクスパートナーズ株式会社

鈴木雄介 / 和智右桂 / 関満徳

[2E-2]


提供

• この講演はグロースエクスパートナーズ（株）の提供でお送りします

1


紹介

• グロースエクスパートナーズ株式会社は、

–100人規模で受託請負開発を中心にしている

–エンタープライズ案件をプライムでやっている

» SI部隊とデザイン部隊

» コンサル~IT企画~構築~保守運用まで

–顧客の業界は医療、百貨店、情報提供サービス、住宅設備、製造などの大手企業

» 売上上位5社の平均社歴は100年越え

–社名の由来は「顧客と共に成長するパートナーになる」

2


紹介

• http://www.gxp.co.jp/

3

http://www.gxp.co.jp/


紹介

• http://www.facebook.com/gxpinc

4

http://www.facebook.com/gxpinc


お詫び

• タッチダウンじゃなくて、トライでした。

5

http://www.flickr.com/photos/hjelle/2074511619/ http://www.flickr.com/photos/tony4pics/7294009662/

タッチダウントライ

http://www.flickr.com/photos/hjelle/2074511619/

http://www.flickr.com/photos/tony4pics/7294009662/

Copyright© Growth xPartners, Inc. All rights reserved. 6

「エンタープライズでタッチダウントライを決めるための戦略と実践」と題して我々の経験をお話しします

http://www.flickr.com/photos/chalofotos/3808402596/

http://www.flickr.com/photos/chalofotos/3808402596/


アジェンダ

• エンタープライズ系とは

• トライへの道のり

• 事例紹介

• まとめ

7


エンタープライズ系とは

8



• 概況

–ますますITサービスに対する重要性は高まり、ビジネスとITの関連性は強い

–ビジネス環境の変化は激しく、それに追随していかないといけない

–顧客は、自分たちのニーズをかなえるようなシステム開発手法を求めており、旧来のウォーターフォール型からアジャイル型へ強い興味を持っている

9


「顧客にコミットした開発をしたい」その思いはエンタープライズかWebかで大きな違いはない

10 http://www.flickr.com/photos/23065375@N05/2235525962/

http://www.flickr.com/photos/23065375@N05/2235525962/


ただし、エンタープライズは”色々ある”

http://www.flickr.com/photos/jimmyflickr/3475179987/

http://www.flickr.com/photos/jimmyflickr/3475179987/



• 色々

–既存ビジネス

» 既存顧客、既存資産、既存業務、既存ブランド、既存…

–既存システムとの連携

» 会計、分析、各種業務系…

–関連部署との調整

» 経営、経理、シス企画、開発、運用、業務、運営、営業、導入、保守、サポート、ロジ、設備、製造、購買…

–全社ルール

» 内部統制、情報保護、各種法令、各種慣習…

12



• エンタープライズは、めんどい

–色々あるので、みんな意見が違う

–色々あるので、新しいことをやりたがらない

–色々あるので、やりたいことができないことがある

–色々あるので、変えられないことがある

–色々あるので、…

• でも、めんどいだけではない

13


社会が100年間必要としてきた企業が必要とするITを作る

顧客を通じて、社会とつながる

http://www.flickr.com/photos/acetonic/5165735565/

http://www.flickr.com/photos/acetonic/5165735565/



• 顧客を通じて、社会とつながる

–自分のやっていることが社会の役に立つという実感

–社会が必要とする企業に必要とされていれば、自分たちの仕事はなくならない

• めんどくささは必要なもの

–慣性の法則がなければ企業は立ち行かない

–でも、優れた企業は変わり続けることで存続してきたし、これからも変わり続ける意志がある

15



• そんなエンタープライズ系における開発手法とは何がいいのか？

• 我々の経験からお話しします

–まだ、体系化はできていません

16


トライまでの道のり

17


では、色々あるなか、どうやってトライを決めるのか？




華麗なるランからのダイビングトライ！

http://www.flickr.com/photos/pierre-selim/8707069713/

なんてことは、まずない。






• 「作って、見せて、調整していく」は基本

• ただし、

–既存システム連携や既存業務があるため、最低限見せられるまでにやるべきことが多い

–その後の調整時間も長くなりがち

–最後の最後になって大きな問題が発生しがち

• では、どうやって「作って、見せて、調整していく」のか？

20


ラグビーに様々な戦略があるように、開発にも様々な戦略が必要

http://www.flickr.com/photos/nelomijangos/5994812481/

http://www.flickr.com/photos/nelomijangos/5994812481/



22

企画調整移行運用アーキ初期構築フェーズ


プロジェクト計画＝円陣

我々は何をするのか？

http://www.flickr.com/photos/koreboy/2398368256/

http://www.flickr.com/photos/koreboy/2398368256/



• 企画＝円陣

–「我々は何をするのか？」を決める

» いわゆるスコープ定義

» ユーザーにどんな価値をもたらすのか、という抽象的なレベルでよい

–顧客との関係づくり（3つの立場）

» 教えてもらう：顧客は当たり前すぎて気づけないので、気になることは聞いてみて教えてもらう

» 教える：システム的にはこう考える、こうすべきを教える

» 一緒に考える：業務とシステムをどうバランスさせるか、話し合う

24


アーキテクチャ設計＝キックオフ

すべてを、ここで決める





• アーキテクチャ設計＝キックオフ

–基本的な戦略を決定する

» 「何を作るか」と「どう作るか」をつなげる

–アーキテクチャ設計

» まず確定要素と不確定要素を振り分ける

» 不確定的な要素に対して

▸ 不確定さの影響範囲を限定的にする

▸ どうやって確定するかを決める（プロトなど）

▸ 決定をなるべく遅らせ、選択肢を幅広くする

» 決めてしまったら、後戻りはできない

▸ 事後的には調整しかできず、それはマネジメントの仕事

26


初期構築＝ラン

迷わず行けよ

http://www.flickr.com/photos/chasephotography/3947836440/

http://www.flickr.com/photos/chasephotography/3947836440/



• 初期構築＝ラン

–60~70点を目指す

» 利害関係者が触れるためには、全利害関係者のための一通りが必要。ここで作り過ぎないことが大事

» ここで60点を取れていないと以降ではリカバリできない

–プロセスはウォーターフォールに近い

» 基本設計~ITまで

» ゴール/リソースを確定していればウォーターフォールは効率が良い

▸ 無理にアジャイルにすると全体整合性がとれなくなる危険性あり

28


調整＝イテレーション

関係者を巻き込む http://www.flickr.com/photos/tunnelarmr/3611455939/

http://www.flickr.com/photos/tunnelarmr/3611455939/



• 調整＝イテレーション

–利害関係者に見せて、フィードバックをもらう

» 例：オペレーションしてもらう

» 例：他システム連携をしてみる

–プロセスはアジャイルに近い

» フィードバックを課題管理にいれる

» タイムボックス型のリリース

–初期構築から調整への切替がけっこう大変

» テストあたりからの流れでグダグダにならないように！

30


移行＝押し込み

気合と諦め

http://www.flickr.com/photos/simonw92/8220635050/

http://www.flickr.com/photos/simonw92/8220635050/



• 移行＝押し込み

–最後のドロドロしたあたり

» 課題の取捨選択

▸ トリアージ的判断で愚痴は切り捨てる

» 気合は重要

▸ 自分事にしてリリースを迎える気持ちがあるかどうか

–顧客と同じ方向を向いて、その日を迎える

» 最悪、「運用で何とかします」と言ってもらえるか

32



33

企画調整移行運用アーキ初期構築フェーズ


一番大事なことは、常に顧客と真摯に向き合えているかどうか





• 常に真摯に顧客と向き合っているか？

–成功するために、あらゆる手段を講じているか？手段が目的化していないか？

–銀の弾丸はない（1つの方法論だけは完遂できない）

• 何よりも信頼を積み上げることが一番の効率化

–方法論による効率化よりも大事なこと

–いま何が起きていて、何をすべきかを顧客と真摯に話し合う

35


事例紹介

36


事例紹介

• 事例1：（株）アドバンスト・メディア様

–VoXTサービス

• 事例2：情報提供サービス業某社

–オンラインサービス

37


事例紹介1 （株）アドバンスト・メディア様

38


エンタープライズでの新規事業にて、これまで紹介してきた戦略を軸にスクラムやリーン、UI/UXなどのテクニックを駆使した実践事例を、ご紹介します

実践事例

39


実践事例の概要（1/1）

• エンタープライズでの新規事業

–企画検討から1年以内でサービスインを実現

–稟議が通ってから3ヶ月以内に代替手段のヘビーユーザーよるプロト検証を実現

40

2012年 2013年 2014年

12月 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月 1月

企画検討要件検討稟議仮説検証

プロト検証

構築保守運用プロトタイプ

2013/9上旬代替手段のヘビーユーザーによるプロト検証実施！

2013/11/20 サービスイン！

プロト検証


実践事例のサービス紹介（1/5）

41 http://www.flickr.com/photos/10549583@N03/1601233059/

サービスイン翌日『2013年11月21日(木)付け日経産業新聞』トップ一面に掲載されました！





42

https://voxt.jp/ へ今すぐアクセス！



43



44



45

Word等のエディタを起動しながらショートカットキーによる

再生・一時停止等の操作が可能

文字変換結果を表示


実践事例（1/8）

■企画検討における3つのステップ

1. [発散] ターゲットにしたい業種・顧客の書き出し

2. [発散] 1.が実現したい未来の書き出し

» 必要に応じて二次元マップ等を使用して分類

3. [収束] 2.について着手対象の絞り込み

» 5つの質問に答えることで着手すべき未来を選定

» この時点で経営陣と協議し、方針を仮決め

46

2012年 2013年 2014年

12月 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月 1月


保守運用プロトタイプ

我々の使命は何か？

我々の顧客は誰か？

顧客の価値は何か？

我々の成果は何か？

我々の計画は何か？

プロト検証

構築



■要件検討における3つのステップ

1. 対象課題をシナリオの区切りで分割

2. 課題構造と解決手段の双方向の論理整合を検証

» プロダクトダイアグラムを活用した課題の深掘

3. プロダクトのビジネスモデルを検討

» プロダクトキャンバスを活用して検討

» ビジネスモデルにおける課題とリスクも記録

47

2012年 2013年 2014年

12月 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月 1月


保守運用プロトタイプ

プロト検証

構築


[解説]プロダクトダイアグラム

48

プロダクトにおける「課題構造」と「解決手段」

なぜ顧客は購入するのか？購入意思の発生条件、頻度はもとより、根本的な課題・動機・原因。

購入における最終意志決定者は誰か？買わなければいけない緊急性があるのか？本当に買う必要があるのか？を判断する人。

競合は何か？買わなかった場合の代替手段。

競合を使い続けている理由は何か？ [競合]から[別の手段]へ乗り換えない理由、環境、背景、その他要因。

競合から乗り換えるメリットは何か？競合を捨ててまで採用する動機。[金額][時間] [知識][スキル][熱意]等の観点も利用可。

キャッチコピーは何か？課題について自分事である人々が目にした時に、視線が止まる、興味を持つ一言。

キャッチコピーに惹かれる顧客の状況は？課題について自分事である人々の状況。

顧客に会うにはいつどこへ行けばいいか？課題について自分事である人々を見つける条件。

プロダクトが提供する解決手段は何か？購入の決め手となった解決手段。購入に至った根本的な課題・動機・原因に対してプロダクトが提供し、解決した項目。

「治療薬」か「痛み止め」か？「治療薬」：課題を根本的に解決「痛み止め」：課題を和らげる顧客の期待値と解決策の一致を検証。

顧客にお願いする事項は何か？ ①購入・利用開始に必要なコスト ②競合からデータや運用を移行するコスト ③競合を捨てるコスト ④使い続けるのに必要なコスト競合からの乗り換えを躊躇する原因。

競合にはなかった「独自の価値」は何か？購入検討者が心を惹かれる理由。マーケットの中で生き残れる理由。

売るために行った戦略は何か？競合に対する優位性、差別化要因。

購入検討者の心に我々の提案は

本当に響くのか？

4つのコストを負担してでも、競合から乗り換える必要が本当にあるのか？

「課題構造」の妥当性「解決手段」の妥当性

プロダクトの価値購入する顧客

他の選択肢

顧客が抱えていたニーズは実在したか？プロダクトを購入する

と解決するのか？

購入

双方向の論理整合を検証


[解説]プロダクトキャンバス

49

プロダクトのビジネスモデル顧客が欲しいと思った動機顧客は何らかの仕事／行為をする必要があり、プロダクトを使って、自分の代わりにそれを行わせようとしている。・その仕事／行為は何か・解決したい課題は何か競合課題に対する代替手段。まったく新しい課題を解決しようとしているのでない限り、課題にはすでにソリューションが存在。ただし競合があるとは限らず、課題があっても困っていないのであれば、「何もしない」も実用的な代替品。

価値の提供手段購入に至った根本的な課題・動機・原因に対して、プロダクトが提供し、解決した項目。

プロダクトの持つ価値 [顧客視点] →競合を捨ててまで採用する動機となる価値。 [プロダクト視点] →プロダクトの存在価値。社会貢献に値する価値。顧客に紹介する際の一言顧客に対してすばやく伝えたり広めたりする際に使用する、アピールの際の一言。キャッチコピーを包含。

競合に対する優位性競合に負けないための戦略や、差別化要因。購入検討者が心を惹かれる理由。マーケットの中で生き残れる理由。

購入する顧客購入してくれる顧客の特徴を絞り込む。コアなファン特に影響力を持つ顧客の特徴を絞り込む。

ビジネスの成功基準ビジネスがどれだけうまくいっているかを示す数値。進捗の計測や顧客ライフサイクルの転換点を見つけるのに使用。 [顧客獲得][初回体験時の満足度][定着、反復利用][収益][紹介] 等の観点も利用可。

顧客へのチャネル [インバウンドチャネル] →顧客にこちらを見つけて貰うための手段 [アウトバウンドチャネル] →プッシュ型のメッセージを使ってこちらから顧客に接触する手段

コスト時間、お金、労力、人員、固定費、変動費、etc。

収益価格体系、課金体系、etc。


[解説]ビジネスモデルの課題リスク

50

社内業務が抱える課題社内業務における課題。

プロダクトが抱える課題プロダクトの機能や品質における課題。

営業活動が抱える課題営業活動プロセスを取り巻く様々な要因における課題。

顧客が抱える課題顧客の背景、役割、環境における課題。

市場が抱える課題市場を動かす様々な要因における課題。 <市場における圧力> 市場セグメント、需要と供給、市場の論点、スイッチングコスト＜産業における圧力＞サプライヤーと他のバリューチェーンの企業、新規参入、競合（既存企業）、代替品・代替サービス、ステークホルダー

社内業務が抱えるリスク社内業務におけるリスク。

プロダクトが抱えるリスクプロダクトの機能や品質におけるリスク。

営業活動が抱えるリスク営業活動プロセスを取り巻く様々な要因におけるリスク。

顧客が抱えるリスク顧客の背景、役割、環境におけるリスク。

市場が抱えるリスク市場を動かす様々な要因におけるリスク。＜重要なトレンド＞規制、技術、社会的、文化的、社会経済＜マクロ経済の圧力＞グローバル市場の状況、資本市場、経済インフラ、原料や他のリソース

プロダクトのビジネスモデルにおける課題とリスク



■稟議

–役員層による稟議決裁

» 予算確保

» 方針転換

» 条件追加

» 役員層からの要望

51

2012年 2013年 2014年

12月 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月 1月


保守運用プロト検証

構築プロトタイプ



■仮説検証におけるプロダクトビジョンの策定

–開発前にお客様の視点をスタート地点とした検証

» プレスリリースの内容は、既存プロダクトの問題点とそれを新しいプロダクトがどう解決するかを記載

» プレスリリースがユーザー層に響かなければ、そのプロダクトは作らない

» 見当違いなプロダクトを作るリスクを一番最初の段階で低コストに回避

52

2012年 2013年 2014年

12月 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月 1月





[解説]プロダクトビジョンの策定

53

プレスリリースに記載する項目 No. 項目記載内容

1 見出し顧客が商品を理解できるタイトル

2 副題ターゲット層と、彼らのメリットを1行で

3 概要商品の特徴と利点をまとめるこの段落で全てを理解できるように

4 課題このプロダクトが解決する課題を説明

5 解決プロダクトがどのように課題を解決するかを説明

6 コメント自分による紹介コメント（社長のコメント的なもの）

7 使い方どれくらい使い方が簡単かを説明

8 ユーザーからの声仮想ユーザーからのコメント

9 締め最後にしめ、次にユーザーがどうすればいいかを示す

No. 項目記載内容

1 プレスリリースそのプロダクトの存在意義と魅力を説明できるプレスリリースを作成ユーザーに響かなければ、プロジェクトは終了

2 Q&A プレスリリースを元にQ&Aを作成プレスを読んだ人が疑問に思うことを想定し、プロダクトの魅力を理解できるようにする

3 ユースケースこのプロダクトのユーザーが、いつ、どのように使うのかのシナリオをまとめるここでリアリティが無ければ作成しなおす必要に応じてモックアップやエピソード、デモビデオなどを作成

4 マニュアルこのプロダクトは何か？どのように使うか？注意することは？といった「お客様が知るべきこと」をまとめた簡単なユーザーマニュアルを作成

プレスリリースを補完する目的で同時に作成する場合の成果物



■プロトタイプにおける4つのステップ

1. ペーパープロトタイピングでおおまかな動線の確認

2. PowerPointプロトタイプで画面レイアウトの確認

3. 画面のみ実装したプロトタイプでの確認

4. ビジネス面の仮説を検証するのに最低限必要な要素のみ実装したプロトタイプでの確認

» プロダクトのデザインや技術的な検証とは大きく異なる

54

2012年 2013年 2014年

12月 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月 1月






■プロト検証でのコアのMVP達成度の確認

–代替手段のヘビーユーザーによるプロト検証

» ビジネス面の仮説を検証するのに最低限必要な要素が満たされているか確認

» 市場で生き残れるプロダクトとなっているか確認

55

2012年 2013年 2014年

12月 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月 1月






■構築を効率よく、かつ最短で行うために

–アーキテクチャ設計およびデータベース設計を工夫

1. クラウド(Azure)の採用、特性を素直に活用した設計

2. 設計のシンプル化、疎結合重視、キューの利用

3. オンラインメンテナンス対応、自動更新対応(ClickOnce)

4. ビジネスモデルの変更はマスタデータの変更で極力吸収例）料金プランの変更、プランの追加、etc

5. サーバーサイドとクライアントを同一言語(C#)で実装

56

2012年 2013年 2014年

12月 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月 1月





[解説]開発ライフサイクル

57



■保守運用フェーズでの対応

–ビジネス面の仮説を検証するのに最低限必要な要素には含まれなかった機能の追加

1. 問い合わせ対応用の機能

2. 不具合追跡調査用の機能

3. サービス管理者向け機能

–利用者数増加、利用シーン拡大のための施策検討

58

2012年 2013年 2014年

12月 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月 1月





実践事例 - まとめ

• スクラムやリーンなどのテクニックは適材適所で上手く扱えばエンタープライズにも応用可

–企画検討における3つのステップ

–要件検討における3つのステップ

–仮説検証におけるプロダクトビジョンの策定

» プレスリリース作成、検証

–プロトタイプにおける4つのステップ

–プロト検証でのコアのMVP達成度の確認

–構築を効率よく、かつ最短で行うためにアーキテクチャ設計やデータ設計の工夫が必要

59


事例紹介2 情報提供サービス業A社

60


実践事例の概要

• 特定業務向けの情報を提供する企業

–オフラインが中心だが、今後はオンラインを推進するためにオンラインサービスを再構築

–数十種類/数億件のデータをオンラインで検索して情報提供する

–29か月で約350人月

» いろいろな事件がありました…

61


実践事例の概要

62

0.0

5.0

10.0

15.0

20.0

25.0

30.0

35.0

40.0

45.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

要員

要員

企画

調整移行

運用アーキ初期構築追加構築


実践事例：企画

• 企画

–RFPに対して提案を行い、案件を獲得

» 業務フローの理解による基本的な機能配置

» システムアーキテクチャの基本方針

63


実践事例：アーキテクチャ設計

• アーキテクチャ設計 –業務ドメイン設計とシステムアーキテクチャ

» 検索：検索エンジン（データ更新と整合性）

» 出力：帳票作成/メール送信（キュー）

» 決済：マスタ共有化/請求連携/横断ドメイン

» 連携：DB/ファイル/Webサービス/…

» Etc...

–「コンウェイの法則」重要 » リソース調達とコミュニケーション

▸ オフショアを見越したスケールアウトと集約

» スケジュール/品質/リスクも同じ

» ※いわゆるPMだけではプロジェクト計画が作れない

64


実践事例：初期構築

• 初期構築/追加構築

–初期構築で50点に至らず

» あると思っていた他システムがなかった…

» 他システム連携ブリッジの開発が必要に

–追加構築で65点に

» 対象範囲の拡大

» 「とりあえず動く」ようになるまで一苦労

–この段階で大きなキズを残さないことが重要

» 初期のアーキテクチャがどうだったかが問われる

65


実践事例：調整

• 調整 –すべて課題管理ツール（JIRA）による管理を行い、

顧客と課題リストを共有

–毎週の定例会で優先順位を判定して状況を報告 » お客様社内テストとの兼ね合いでスピード感重視。

» バタバタと毎日のようにリリースする段階から、徐々にペースを落として、最終的には週次リリースに。

–頻繁なリリースを支えるためのCI基盤整備

–縮小したコアチームによる運営 » チーム作りとプロセス作り

» 「動きながらまとめて行く」

66


実践事例：移行

• 移行

–運用に向けた最終調整段階

–期間が定められた中での厳格なトリアージが必要

» 求められるスピード感と品質が上がる

» 現実解と「とはいえやらなければいけないもの」とのせめぎ合い

67


実践事例：運用

• 運用

–運用フェーズになって分かったことも色々

» 日々改修

» サービスインしてしまっているので緊急性は高いが、拙速による事故は起こせないというトレードオフ

–真面目に仕事をしている数千人の人たちのインフラを担うという責任感

» 「指さし確認」重要

68


実践事例 - まとめ

• 総括

–作るフェーズから使うフェーズへ

» 大きく作るところはウォーターフォール

▸ 「コンウェイの法則」重要

» 調整～移行はアジャイル

▸ チケット駆動必須

» 機能面での整備だけでなく運用の考慮は常に必要【反省】

–計画していないことは常に現れる

» その「ゆらぎ」を吸収できるアーキテクチャと体制、プロセスが重要

» その「ゆらぎ」を吸収できる範囲に収める計画づくり

69


まとめ

70


まとめ

• エンタープライズ系

–顧客とコミットしたい、という思いは共通

–ただし”色々とある”のでめんどくさい

–でも「顧客を通じて社会とつながる」という魅力

• 開発の進め方

–「作って、見せて、調整する」は基本

–でも、1つの方法論では完結できない

–あらゆる知恵を使って乗り越える

71


まとめ

• 戦略と実践

–大前提：「正解はない」

–現場ごとに異なるミッションと制約を理解し、その中で最適な手段を作り出してく

» 必ず戦略を立てて、実践する

» 戦略立案のために理論（他人の経験）を学ぶことは重要だが、現場状況が優先される

» とはいえ、最後まで分からないことはあり、それは覚悟で乗り切るしかない（顧客と向き合えているか）

72


さいごに

• グロースエクスパートナーズ株式会社にご興味をもたれたら、以下にアクセスしてください。

–http://www.gxp.co.jp/

–https://www.facebook.com/gxpinc

–採用： http://www.gxp.co.jp/recruit/index.html

73



https://www.facebook.com/gxpinc

https://www.facebook.com/gxpinc

http://www.gxp.co.jp/recruit/index.html

http://www.gxp.co.jp/recruit/index.html

sgt2014_gxp

Business