Sgt2014_GxP

[2E-2]

エンタープライズでタッチダウン
を決めるための戦略と実践
グロースエクスパートナーズ株式会社
鈴木雄介 / 和智右桂 / 関満徳

Copyright© Growth xPartners, Inc. All rights reserved.

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


1

紹介
• グロースエクスパートナーズ株式会社は、
– 100人規模で受託請負開発を中心にしている
– エンタープライズ案件をプライムでやっている
» SI部隊とデザイン部隊
» コンサル~IT企画~構築~保守運用まで

– 顧客の業界は医療、百貨店、情報提供サービス、住
宅設備、製造などの大手企業
» 売上上位5社の平均社歴は100年越え

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

2

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


3

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


4

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

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

タッチダウン


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

トライ
5

「エンタープライズでタッチダウン
トライを決めるための戦略と実践」
と題して我々の経験をお話しします
http://www.flickr.com/photos/chalofotos/3808402596/

6

アジェンダ
•
•
•
•

エンタープライズ系とは
トライへの道のり
事例紹介
まとめ


7



8

• 概況
– ますますITサービスに対する重要性は高まり、ビジ
ネスとITの関連性は強い
– ビジネス環境の変化は激しく、それに追随していか
ないといけない

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


9

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

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

10

ただし、エンタープライズは”色々ある”
http://www.flickr.com/photos/jimmyflickr/3475179987/

11

• 色々
– 既存ビジネス
» 既存顧客、既存資産、既存業務、既存ブランド、既存…

– 既存システムとの連携
» 会計、分析、各種業務系…

– 関連部署との調整
» 経営、経理、シス企画、開発、運用、業務、運営、営業、
導入、保守、サポート、ロジ、設備、製造、購買…

– 全社ルール
» 内部統制、情報保護、各種法令、各種慣習…

12

• エンタープライズは、めんどい
– 色々あるので、みんな意見が違う
– 色々あるので、新しいことをやりたがらない
– 色々あるので、やりたいことができないことがある
– 色々あるので、変えられないことがある
– 色々あるので、…

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


13

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

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

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

14

• 顧客を通じて、社会とつながる
– 自分のやっていることが社会の役に立つという実感
– 社会が必要とする企業に必要とされていれば、自分
たちの仕事はなくならない

• めんどくささは必要なもの
– 慣性の法則がなければ企業は立ち行かない
– でも、優れた企業は変わり続けることで存続してき
たし、これからも変わり続ける意志がある


15

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

• 我々の経験からお話しします
– まだ、体系化はできていません


16

トライまでの道のり


17

では、色々あるなか、どうやって
トライを決めるのか？
http://www.flickr.com/photos/tony4pics/7294009662/

18

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

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

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

19

• 「作って、見せて、調整していく」は基本
• ただし、
– 既存システム連携や既存業務があるため、最低限見
せられるまでにやるべきことが多い
– その後の調整時間も長くなりがち
– 最後の最後になって大きな問題が発生しがち

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


20

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

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

21


フェーズ企画

アーキ


初期構築

調整

移行

運用
22

プロジェクト計画＝円陣
我々は何をするのか？

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

23

• 企画＝円陣
– 「我々は何をするのか？」を決める
» いわゆるスコープ定義
» ユーザーにどんな価値をもたらすのか、という抽象的なレ
ベルでよい

– 顧客との関係づくり（3つの立場）
» 教えてもらう：顧客は当たり前すぎて気づけないので、気
になることは聞いてみて教えてもらう
» 教える：システム的にはこう考える、こうすべきを教える
» 一緒に考える：業務とシステムをどうバランスさせるか、
話し合う

24

アーキテクチャ設計＝キックオフ
すべてを、ここで決める

25

• アーキテクチャ設計＝キックオフ
– 基本的な戦略を決定する
» 「何を作るか」と「どう作るか」をつなげる

– アーキテクチャ設計
» まず確定要素と不確定要素を振り分ける
» 不確定的な要素に対して
▸ 不確定さの影響範囲を限定的にする
▸ どうやって確定するかを決める（プロトなど）
▸ 決定をなるべく遅らせ、選択肢を幅広くする

» 決めてしまったら、後戻りはできない
▸ 事後的には調整しかできず、それはマネジメントの仕事


26

初期構築＝ラン
迷わず行けよ

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

27

• 初期構築＝ラン
– 60~70点を目指す
» 利害関係者が触れるためには、全利害関係者のための一通
りが必要。ここで作り過ぎないことが大事
» ここで60点を取れていないと以降ではリカバリできない

– プロセスはウォーターフォールに近い
» 基本設計~ITまで
» ゴール/リソースを確定していればウォーターフォールは効
率が良い
▸ 無理にアジャイルにすると全体整合性がとれなくなる危険性あり


28

調整＝イテレーション

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

29

• 調整＝イテレーション
– 利害関係者に見せて、フィードバックをもらう
» 例：オペレーションしてもらう
» 例：他システム連携をしてみる

– プロセスはアジャイルに近い
» フィードバックを課題管理にいれる
» タイムボックス型のリリース

– 初期構築から調整への切替がけっこう大変
» テストあたりからの流れでグダグダにならないように！

30

移行＝押し込み
気合と諦め

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

31

• 移行＝押し込み
– 最後のドロドロしたあたり
» 課題の取捨選択
▸ トリアージ的判断で愚痴は切り捨てる

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

– 顧客と同じ方向を向いて、その日を迎える
» 最悪、「運用で何とかします」と言ってもらえるか


32


フェーズ企画

アーキ


初期構築

調整

移行

運用
33

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


34

• 常に真摯に顧客と向き合っているか？
– 成功するために、あらゆる手段を講じているか？手
段が目的化していないか？
– 銀の弾丸はない（1つの方法論だけは完遂できない）

• 何よりも信頼を積み上げることが一番の効率化
– 方法論による効率化よりも大事なこと
– いま何が起きていて、何をすべきかを顧客と真摯に
話し合う


35

事例紹介


36

事例紹介
• 事例1：（株）アドバンスト・メディア様
– VoXTサービス

• 事例2：情報提供サービス業某社
– オンラインサービス


37

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

38

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

実践事例


39

実践事例の概要（1/1）
• エンタープライズでの新規事業
– 企画検討から1年以内でサービスインを実現
2013/11/20
サービスイン！
2012年

2013年

12月

1月

企画検討

2014年

2月

3月

4月

要件検討

5月

稟議

6月

仮説
検証

7月

8月

プロト
タイプ

9月

プロト
検証

10月

構築

11月

12月

1月

保守運用

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

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

40

サービスイン翌日
実践事例のサービス紹介（1/5）
『2013年11月21日(木)付け日経産業新聞』
トップ一面に掲載されました！


41


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


42



43



44

Word等のエディタを起動しながら
ショートカットキーによる
再生・一時停止等の操作が可能

文字変換結果を表示


45

実践事例（1/8）
■企画検討における3つのステップ
1. [発散] ターゲットにしたい業種・顧客の書き出し
2. [発散] 1.が実現したい未来の書き出し
我々の
使命は
何か？

»

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

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

我々の
顧客は
誰か？

5つの質問に答えることで着手すべき未来を選定
この時点で経営陣と協議し、方針を仮決め

2012年

1月

我々の
成果は
何か？
我々の
計画は
何か？

2013年

12月

顧客の
価値は
何か？

企画検討

2014年

2月

3月

4月

要件検討


5月

稟議

6月

仮説
検証

7月

8月

プロト
タイプ

9月

プロト
検証

10月

構築

11月

12月

1月

保守運用

46

■要件検討における3つのステップ
1. 対象課題をシナリオの区切りで分割
2. 課題構造と解決手段の双方向の論理整合を検証
»

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

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

プロダクトキャンバスを活用して検討
ビジネスモデルにおける課題とリスクも記録

2012年

2013年

12月

1月

企画検討

2014年

2月

3月

4月

要件検討


5月

稟議

6月

仮説
検証

7月

8月

プロト
タイプ

9月

プロト
検証

10月

構築

11月

12月

1月

保守運用

47

[解説]プロダクトダイアグラム
 プロダクトにおける「課題構造」と「解決手段」
「課題構造」の妥当性
なぜ顧客は購入するのか？
購入意思の発生条件、頻度はもとより、
根本的な課題・動機・原因。

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

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

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

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

競合から乗り換えるメリットは何か？

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

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

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

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

競合を捨ててまで採用する動機。[金額][時間]
[知識][スキル][熱意]等の観点も利用可。

購入する顧客

プロダクトの価値

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

キャッチコピーに惹かれる顧客の状況は？

競合にはなかった「独自の価値」は何か？

購入検討者の心に
我々の提案は
本当に響くのか？

課題について自分事である人々の状況。

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

購入検討者が心を惹かれる理由。
マーケットの中で生き残れる理由。

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

双方向の論理整合を検証

48

[解説]プロダクトキャンバス
 プロダクトのビジネスモデル
顧客が欲しいと思った動機
顧客は何らかの仕事／行
為をする必要があり、プ
ロダクトを使って、自分
の代わりにそれを行わせ
ようとしている。

・その仕事／行為は何か
・解決したい課題は何か
競合
課題に対する代替手段。
まったく新しい課題を解
決しようとしているので
ない限り、課題にはすで
にソリューションが存在。
ただし競合があるとは限
らず、課題があっても
困っていないのであれば、
「何もしない」も実用的
な代替品。

価値の提供手段

プロダクトの持つ価値

購入に至った根本的な [顧客視点]
課題・動機・原因に
→競合を捨ててまで採用
対して、プロダクトが
する動機となる価値。
提供し、解決した項目。
[プロダクト視点]
→プロダクトの存在価値。
社会貢献に値する価値。

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

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


顧客に紹介する際の一言
顧客に対してすばやく
伝えたり広めたりする
際に使用する、アピール
の際の一言。
キャッチコピーを包含。

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

顧客へのチャネル
[インバウンドチャネル]
→顧客にこちらを見つけて
貰うための手段

購入する顧客
購入してくれる顧客
の特徴を絞り込む。

コアなファン
特に影響力を持つ顧
客の特徴を絞り込む。

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

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

49

[解説]ビジネスモデルの課題リスク
 プロダクトのビジネスモデルにおける課題とリスク
社内業務が抱える課題

プロダクトが抱える課題

社内業務における課
題。

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

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

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


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

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

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

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

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

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

50

■稟議
– 役員層による稟議決裁
»
»
»
»

予算確保
方針転換
条件追加
役員層からの要望

2012年

2013年

12月

1月

企画検討

2014年

2月

3月

4月

要件検討


5月

稟議

6月

仮説
検証

7月

8月

プロト
タイプ

9月

プロト
検証

10月

構築

11月

12月

1月

保守運用

51

■仮説検証におけるプロダクトビジョンの策定
– 開発前にお客様の視点をスタート地点とした検証
»
»
»

プレスリリースの内容は、既存プロダクトの問題点と
それを新しいプロダクトがどう解決するかを記載
プレスリリースがユーザー層に響かなければ、
そのプロダクトは作らない
見当違いなプロダクトを作るリスクを一番最初の段階で
低コストに回避

2012年

2013年

12月

1月

企画検討

2014年

2月

3月

4月

要件検討


5月

稟議

6月

仮説
検証

7月

8月

プロト
タイプ

9月

プロト
検証

10月

構築

11月

12月

1月

保守運用

52

[解説]プロダクトビジョンの策定
 プレスリリースに記載する項目
No.

項目

記載内容

1

見出し

顧客が商品を理解できるタイトル

2

副題

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

3

概要

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

4

課題

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

5

解決

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

6

コメント

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

7

使い方

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

8

ユーザーからの声

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

9

締め

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

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

項目

記載内容

1

プレスリリース

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

2

Q&A

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

3

ユースケース

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

4

マニュアル

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


53

■プロトタイプにおける4つのステップ
1.
2.
3.
4.
»

ペーパープロトタイピングでおおまかな動線の確認
PowerPointプロトタイプで画面レイアウトの確認
画面のみ実装したプロトタイプでの確認
ビジネス面の仮説を検証するのに最低限必要な要素
のみ実装したプロトタイプでの確認
プロダクトのデザインや技術的な検証とは大きく異なる

2012年

2013年

12月

1月

企画検討

2014年

2月

3月

4月

要件検討


5月

稟議

6月

仮説
検証

7月

8月

プロト
タイプ

9月

プロト
検証

10月

構築

11月

12月

1月

保守運用

54

■プロト検証でのコアのMVP達成度の確認
– 代替手段のヘビーユーザーによるプロト検証
»
»

ビジネス面の仮説を検証するのに最低限必要な要素が
満たされているか確認
市場で生き残れるプロダクトとなっているか確認

2012年

2013年

12月

1月

企画検討

2014年

2月

3月

4月

要件検討


5月

稟議

6月

仮説
検証

7月

8月

プロト
タイプ

9月

プロト
検証

10月

構築

11月

12月

1月

保守運用

55

■構築を効率よく、かつ最短で行うために
– アーキテクチャ設計およびデータベース設計を工夫
1.
2.
3.
4.

クラウド(Azure)の採用、特性を素直に活用した設計
設計のシンプル化、疎結合重視、キューの利用
オンラインメンテナンス対応、自動更新対応(ClickOnce)
ビジネスモデルの変更はマスタデータの変更で極力吸収
例）料金プランの変更、プランの追加、etc
5. サーバーサイドとクライアントを同一言語(C#)で実装
2012年

2013年

12月

1月

企画検討

2014年

2月

3月

4月

要件検討


5月

稟議

6月

仮説
検証

7月

8月

プロト
タイプ

9月

プロト
検証

10月

構築

11月

12月

1月

保守運用

56

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


57

■保守運用フェーズでの対応
– ビジネス面の仮説を検証するのに最低限必要な要素
には含まれなかった機能の追加
1. 問い合わせ対応用の機能
2. 不具合追跡調査用の機能
3. サービス管理者向け機能

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

2013年

12月

1月

企画検討

2014年

2月

3月

4月

要件検討


5月

稟議

6月

仮説
検証

7月

8月

プロト
タイプ

9月

プロト
検証

10月

構築

11月

12月

1月

保守運用

58

実践事例 - まとめ
• スクラムやリーンなどのテクニックは適材適所
で上手く扱えばエンタープライズにも応用可
– 企画検討における3つのステップ
– 要件検討における3つのステップ
– 仮説検証におけるプロダクトビジョンの策定
» プレスリリース作成、検証

– プロトタイプにおける4つのステップ
– プロト検証でのコアのMVP達成度の確認
– 構築を効率よく、かつ最短で行うためにアーキテク
チャ設計やデータ設計の工夫が必要

59

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

60

実践事例の概要
• 特定業務向けの情報を提供する企業
– オフラインが中心だが、今後はオンラインを推進す
るためにオンラインサービスを再構築
– 数十種類/数億件のデータをオンラインで検索して情
報提供する
– 29か月で約350人月
» いろいろな事件がありました…


61

実践事例の概要
要員
45.0
40.0
35.0
30.0
25.0
要員

20.0
15.0

10.0
5.0
0.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

初期構築


追加構築

調整

移
行

運用

62

実践事例：企画
• 企画
– 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

Sgt2014_GxP

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (18)

Similar a Sgt2014_GxP

Similar a Sgt2014_GxP (20)

Más de グロースエクスパートナーズ株式会社/Growth xPartners Incorporated.

Más de グロースエクスパートナーズ株式会社/Growth xPartners Incorporated. (20)

Último

Último (12)

Sgt2014_GxP