第13回 JPSPS in 大阪_失敗しないSharePointプロジェクト案件

Japan SharePoint Group in 大阪

SharePointプロジェクト / 案件

アドバンスド・ソリューション株式会社

深見哲 (ふかみあきら)[email protected]

失敗しない

- Opportunity Development -

2014年2月22日

Copyright © 2014 Advanced Solution Co.,Ltd All Rights Reserved.


自己紹介

• 深見哲（ふかみあきら）

• アドバンスド・ソリューション株式会社雑用係

• PG → SE → PM → IT-Cons → Pre-Sales → Sales → 今ココ

• 概略：

– ソフトハウスを転々とし、フリーランスで気楽に仕事していたところ、

縁あってマイクロソフトに入社。が、また転職し、某A社にてBDを担当。

– もっと楽しく仕事をしたく、SharePoint業界を中心に食っていけそうだ

と算段できたため、会社を立ち上げて今に至る。

– 単純なSharePoint歴は長く、SharePoint Portal Server 2001

のベータ版（Tahoe）検証プロジェクトからの付き合い。

2



会社紹介

•アドバンスド・ソリューション株式会社

• 2012年9月始動

• 従業員 7名 (2014年2月22日時点)

• 絶賛社員募集中

• 主力事業

– SharePoint の新規導入、移行支援

– SharePoint を活用したコミュニケーション基盤の構築

– SharePoint 上での業務アプリ開発

© アドバンスド・ソリューション株式会社3



既に良書がある

• SharePoint成功の道標

4

主催者登壇者

http://www.amazon.co.jp/SharePoint%E6%88%90%E5%8A%9F%E3%81%AE%E9%81%93%E6%A8%99%E2%80%95SharePoint%E3%82%B3%E3%83%B3%E3%82%B5%E3%83%AB%E3%82%BF%E3%83%B3%E3%83%88%E7%A7%98%E4%BC%9D-%E5%AE%9F%E8%A3%85%E3%81%8B%E3%82%89%E6%B4%BB%E7%94%A8%E3%81%AE%E3%83%8E%E3%82%A6%E3%83%8F%E3%82%A6-%E3%82%B8%E3%83%A7%E3%83%AB%E3%83%80%E3%83%B3%E3%83%96%E3%83%83%E3%82%AF%E3%82%B9-%E4%B8%8A%E6%9C%88-%E7%A5%A5%E8%A3%95/dp/4915933369/ref=pd_sxp_f_i


もう一度表紙に戻ってみて

SharePointプロジェクト / 案件

失敗しない

- Opportunity Development -

Analyze Design Build Test DeployOpportunityDevelopment

Proposal Contract



アジェンダ

• 失敗の原因は？

• どうしたらいいのか？

• まとめ

• 最後に

6


失敗の原因は？



よくある SharePoint案件の「注意したい特徴」

• 半パッケージだからこそのままならなさ– PoC やスモールスタートやらいないと、なにが標準なのやら・・・

• 間違ったモデルを採用しがち– いまだに一気通貫完全ウォーターフォールの WBSをたまに見ます・・・

• 他のスクラッチ開発プロジェクト等より「燃え率」が高い– 注意ポイントが多いのと、経験者の少なさでしょうか・・・

• 情報系として導入した場合、サービスインがスタート– 言葉のまんまです

8

皆(特にベンダー)が知ってる、「注意したい特徴」に大きな違いは無いはず・・・



よく聞く SharePointの評価は？

• ユーザーさんからは、

– エンドユーザーに使われない

– そもそも使い方がわからない

– 使われてるけどごみ箱状態

– やりたいことが出来ない

9

とっても低い評価なのはなぜ？悪いのはユーザー？ベンダー？どっちもどっちかなぁ・・・でも・・・

そもそも、「まともな提案」してたらこうはならなかったんじゃないの？



参考）「まともな提案」って？

• 少なくとも下記

– 作業内容、役割分担が明確になっている

– ユーザー側作業の定義と役割が定義されていること

– 後続フェーズのポイント検討が作業内容に含まれている

– ユーザー側の体制にエンドユーザーが含まれている

– 範囲外事項が定義されている

各定義が矛盾なく、双方(提案する側/される側)にメリットがある形となるのが望ましい

10



なぜ提案しない (できない)のか？

• スキル不足

– 残念ですが、まれにこういったベンダーもいます

• 責任感の無さ

– これまた残念ですが、自身の提案に責任を持っていないベンダーもいます

• 立場の違い

– 個人的には不本意ながら、会社/組織として提案できないこともある

11

しかし、提案するのであれば、「立場の違い」が重要な意味を持ってきます



立場の違い

• ジャッジする際の優先順位

12

ユーザーベンダー

機能の実装 (要件) ◎ ×

予定通りのサービスイン (期間) ◎ △

赤字じゃないこと (お金) ○ ◎

優先することが違うのは当たり前

「失敗」の定義も違う

ギャップを埋めないことには、必ず失敗するこれが失敗の最大原因



参考）視点による優先順位の違い

• 「構築」のみなのか、「運用」も含めるのか– 「その後の運用」も含めるのであれば、「構築」自体のマージンを下げたり、

場合よっては赤字でも提案することがある

– この場合、ベンダーの優先順位は「期間」が最優先となる

13

ベンダー

機能の実装 (要件) △

予定通りのサービスイン (期間) ◎

赤字じゃないこと (お金) ○• Win-Win？– ユーザー側からすると初期投資が小さくなり、ベンダー側からすると運用を見込

むことで黒字を確保できることになるため、Win-Winに見えますが・・・

– ユーザー側の要件が実装されなかったり（早く運用フェーズを始めたいので）、よく分からない次フェーズなるものが組まれたりする

– ベンダー側メンバーとしては、辛い案件になりがち（期間優先、要件もそれなりに）で、主要なメンバーが離職したり、運用メンバーの扱いが酷かったりする

– ユーザー側としては、提案のスコープを合わせることはもちろんのこと、提案の意図も汲み取って、その上で自社にとって価値があるのか判断すべきです


どうしたらいいのか？



本気で「プロジェクト」のことを考えましょう

• メンバーを揃える

– ユーザー側：プロジェクトオーナー、PM

– ベンダー側：PM、ソリューションスペシャリスト、営業

• 何を議論するのか

– 目的を明確にする

– 「成功」の定義を合意する

• いつ行うのか

– 提案前

15

Plan Analyze Design Build Test DeployOpportunityDevelopment

Proposal Contract

ココ！



メンバーを揃える

• 責任を持って発言できるメンバー

– ユーザー側：

16

メンバー期待すること

プロジェクトオーナー • プロジェクトの目的• 成功だと判断するポイント

PM • プロジェクト要件の取りまとめ• 体制

メンバー期待すること

PM • 進め方について• リソース計画

ソリューションスペシャリスト • システム化について• アーキの提示

営業 • 交渉材料の提示

– ベンダー側：



何を議論するのか

• 「目的」を明確にする

– プロジェクトオーナーより説明を行うこと

– 説明が出来ないのであればプロジェクトを始めない方がいい

– 「目的」が間違ってないか注意する

– ハードウェアのリプレースによって～

– 三極認証基盤統合に合わせて情報基盤の導入を～

• 「成功」の定義を合意する

– 「要件」で「全て重要」というのはあり得ない

– 最優先事項を決める

– 無駄な要件を除く

– 条件面の交渉を行う

– 営業のもつ条件を引き出す

17



いつ行うのか？

• 遅くとも提案前には

– CRM上、「Opportunity Assessment」や、「Opportunity Development」と表現されることが多く、単に提案するかどうかの判断を行うフェーズではなく、「プロジェクト成功に向けた定義」を行うフェーズと捉えること。

• 色々分かること・・・SharePoint 案件ならでは

– 「SharePoint 以外のソリューションの方がいい」となったり

– システム化の範囲に比べて社内の影響範囲が広いことが分かったり

– ユーザー側プロジェクトチームが足りないということが分かったり

18


Proposal Contract

ココ！



「話し合い」の結果・・・（ギャップが埋まっても、埋まらなくても）

• ユーザーから見た「ダメなベンダー」がよく分かります

– 例えば・・・

– ミーティングにベンダーの営業しか出てこない

– まったく交渉する気が無い

– SharePoint 以外のソリューションを検討していない

– ベンダーをチェックするいい機会です

• ベンダーとしての利点は？

– もちろん、「ダメな案件」がよく分かります

– 例えば・・・

– プロジェクトの目的が明確になっていない

– 要件の優先順位を決められない

– ユーザー側の体制が組まれてない

– 提案したら負けパターンです

19



「話し合い」の結果・・・（次のフェーズは）

• そして RFP/提案書作成へ・・・

– 各フェーズの注意ポイントに気をつけて

– もちろん RFP/提案書作成におけるポイントもあります

– 今日は「Opportunity Development」なので、また機会があれば

なにはともあれ、納得いくまで話し合える関係作りを目指しましょう

20


Proposal Contract

ココ！


まとめ



まとめ

1. 立場の違いによるギャップを埋める努力をする

2. 話し合いをする

3. 目的を明確にする

4. 「成功」の定義を合意する

SharePoint プロジェクトならさらに・・・

1. ToBe モデルから始める

2. スモールスタートを心がける

3. エンドユーザーに SharePointと触れ合ってもらう

「失敗」しないためには、「成功」するためには

22



最後に

• まだまだソリューション提案の観点から「SharePoint」のポテンシャルは深く広いものだと思っています。（発掘しきれてないと思っています）

• 伝え方や表現の差がこんなにも大きく影響する製品は他にもなかなかありません。

• 本日は少し表現や話し方について、乱暴な箇所があったかと思います。もし気分を害された方がいらっしゃいましたら申し訳ございませんでした。

• 休憩時間や懇親会、メールでもコメントをいただけましたら幸いです。

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

アドバンスド・ソリューション株式会社

深見哲 (ふかみあきら)[email protected]

第13回 JPSPS in 大阪_失敗しないSharePointプロジェクト案件

Technology

Transcript of 第13回 JPSPS in 大阪_失敗しないSharePointプロジェクト案件

第13回 JPSPS in 大阪_失敗しないSharePointプロジェクト 案件

Technology

Transcript of 第13回 JPSPS in 大阪_失敗しないSharePointプロジェクト 案件

第13回 JPSPS in 大阪_失敗しないSharePointプロジェクト案件

Transcript of 第13回 JPSPS in 大阪_失敗しないSharePointプロジェクト案件