No profit grows where is no pleasure ta'en.: 2013

2013年10月14日月曜日

REVIEWS

受託開発だろうとなんだろうと、技術が中心だ。

でも、技術が中心にならないことが多くって、だからSIはオワコンとか言われてしまうんだと思う。
受託開発で技術を真ん中に持ってくるには、はじめのはじめから変えないとダメだ。
だから、提案についてちょっぴり勉強をはじめてみました。
APMPのテキストを読んだ感想など書いてみます。

レビュー（REVIEWS）

レビューには、準備、実施、反映の3つのフェーズがある。

適切なときに、適切なことをレビューすることが重要だ。

レビューでは、次の２つを達成しなくてはならない。

包括的：全ての要素をカバーする。
生産的：ポジティブで協力的なトーンを維持する。あいまいだったり、ネガティブなコメントはやめ、生産的な提言にする。

組織のプロセスとして、マイルストーンとレビューポイントを定義しよう

ここの図は重要！なので、テキストみてね。

キャプチャーフェーズ

パシューデシジョン->青チーム->黒帽子チーム->はじめのビッドデシジョン

提案計画フェーズ

ビッドデシジョン決定->ピンクチーム

提案準備

ピンクチーム->赤チーム->ゴールドチーム->提案書提出

提出後

ふりかえり

キャプチャープランをレビューして、戦略を検証するための青チームを運営しよう

青チームのチェックリスト

戦略は抜かりなく、完全なものか検証する
お客様のニーズと要求に対して戦をのテストする
戦略は競合に対して明確な優位点を持つことを検証する

競合の戦略とソリューションをレビューし、戦略をアップデートするための黒帽子チームを運営しよう

黒帽子チームのチェックリスト

ゲームをどのようにつくるか？
競合の戦略は何か？
技術、価格、リスク、実績でどのくらい競合に勝っているか
競合の強みと弱みは何か
お客様を誘導できている課題は何か
お客様はどの企業や担当を好んでいるか
どうやって現行から奪うのか
どうやって現行を残すのか
どうやって競合を打ち負かすのか
どうやって競合のプロモーションやキャンペーンを弱めるのか

戦略どおりに書かれているかを検証し、コンプライアンスを検証するためのピンクチームを運営しよう

ピンクチームはストーリーボードとモックアップをレビューする。

ピンクチームのチェックリスト

事前にレビュアーに必要な情報を提供しよう
レビュアーのテーブルには、動き回れるスペースを用意し、大きなホワイトボードを用意しよう
各メンバーの責任を定義して、レビューチームを構成しよう
目次順に各章を並べて、提案の流れとあっているか確認しよう
レビュアーに簡単な説明をし、質問に答え、役割をはっきりさせよう
全てのコメントと改善案をドキュメントに残そう
レビューの成果に対する提案チームの感想を聞こう

カスタマーフォーカス、完全性、戦略とソリューションの明確な記述を検証するための赤チームを運営しよう

赤チームのレビューは提案書作成の2/3時点に実施するのがよい。

赤チームのコメント反映は、誰か1人がした方がよい。

この段階で、各担当は疲れていて、冷静に書き直すのは難しい上に、高い技術も必要だからだ。

赤チームのチェックリスト

徹底的に計画しよう
単一のリーダーを任命しよう
赤チームメンバーを早期に選定し、キックオフミーティングに参加させ、何名かはピンクチームと兼任させよう
赤チームのためにドキュメントを用意し、レビューの3日前までには配布しよう
お客様の評価構造、ガイドライン、オペレーションなどに沿った形で赤チームを構成しよう
提案書に基づき、構造化された評価計画を使って、赤チームを運営しよう
定性的な評価と定量的なスコアリングの両方を使おう
提案チームに対して、結論を示すことを要求しよう
説明責任をはたそう

提案のメリットとリスクが受け入れてもらえるものか確認するためのゴールドチームを運営しよう

課題と要求の理解を評価しよう
技術的なソリューションのロバストネス（頑健性）を批判的に評価しよう
価格戦略に従っているか検証しよう
実行可能性を保障しよう
差別化要素のメリハリをテストしよう

プロセス、戦略、メンバーの改善状況がどのくらいかを決定するためのふりかえりを運営しよう

ふりかえりチェックリスト

戦略はどのくらい正しかった？
どのくらい正確で有用な業務知識を持っていた？コストはお客様の予算に合っていた？
早期から上位のマネジメント層のサポートを得ていた？
プロポーザルマネジメントプロセスはどのくらい効率的だった？
チームメンバーはどのくらい協力して仕事をできた？
提案は一貫していた？提案依頼書に従っていた？
リーズナブルなコストと時間で提案書を作成できた？
どのくらい提案書は勝利に貢献できた？

各レビューで一貫性のあるプロセスに従おう

どのレビューも準備、実施、反映のプロセスに従う。

ポジティブで生産的なトーンを維持するようにする。

よりよくするのであって、悪い点を指摘するのではない。

コアグループが責任をもって、改善案を反映するかどうかを決定する。

そして、レビューの反映結果はドキュメントに残す。

レビューの分担、範囲を明確にし、レビュアーの負荷を平準化しよう

効率的なレビューのためには、1人のレビュアーが1日に40ページが目安となる。

官公庁の提案は大体90%が新規作成だから、これくらいが理想だ。

再利用ができるものであれば、80ページくらいできるだろう。

必須事項とオプションに分け、各章に2人のレビュアーをつけよう。

そして、重要なところからレビューしよう。

一貫性と適合性をレビューしよう

コストとスケジュールの一貫性や、スケジュールの一貫性をレビューしよう。

？？？いまいちよくわからない・・・

うるさいレビュアーには全体をざっとみてもらうようにアサインしよう

水平レビューと垂直レビューをうまく使おう。

各チームのタスクに応じて適切なレビュアーを選択しよう

赤チームのレビューは提案書作成の2/3時点に実施するのがよい。

赤チームのコメント反映は、誰か1人がした方がよい。

この２つは重要だなあ。

ネタ：APMP Proposal Guide: the Foundation Accreditation Study Guide

https://apmp.site-ym.com/store/view_product.asp?id=1018152

参考：kumi shiki blog

http://kumishiki.wordpress.com/

日次ミーティング（Daily Team Management）

日次のチームマネジメントは、間違った方向に進むことを最小限にする。
３つのキーツールがある。

提案計画
朝会
ストーリーボード

提案計画を用意しなさい

ソリューションを最初に定義しなさい

全員の役割を明確にしなさい

朝会をしなさい

タスクを小さくしなさい

ストーリーボードを使ってレビューしなさい

毎日１つの観点でレビューしなさい

なんだ、ほとんど開発と同じじゃないか！
提案書作成は開発と同じってことを意識していながら、できていなかったということがわかった。

開発と同じと思えば、得意分野じゃないか。

ネタ：APMP Proposal Guide: the Foundation Accreditation Study Guide

https://apmp.site-ym.com/store/view_product.asp?id=1018152

参考：kumi shiki blog

http://kumishiki.wordpress.com/

GRAPHICS

受託開発だろうとなんだろうと、技術が中心だ。
でも、技術が中心にならないことが多くって、だからSIはオワコンとか言われてしまうんだと思う。
受託開発で技術を真ん中に持ってくるには、はじめのはじめから変えないとダメだ。
だから、提案についてちょっぴり勉強をはじめてみました。

APMPのテキストを読んだ感想など書いてみます。

グラフィクス（GRAPHICS）

管理職の評価者は、目立った図とキャプション、見出し、ハイライトされた文とエグゼクティブサマリーしか読まないことがある。
調査によると、文章よりも図の方が２倍記憶に残る。
図と文書の両方だと文章のみの６倍記憶に残る。
近年は、高品質の図が求められる。
効率化のためには、うまく再利用する必要がある。

理解を示し、戦略を強調し、差別化要素を目立たせるように図をつくる
機能ではなく、お客様の便益を図にする。
差別化要素を目立たせるには、横並びの図が有効だ。

現行/提案
複雑/シンプル
旧/新
棒グラフ、円グラフ

文章を書く前に図を考えておく

図をはじめに書くことで、文書を書く時間を1/3にすることができる。
図画あれば、文章は少なく簡潔にできる。

メッセージをサポートする図を選ぶ

チャートは関係や項目間の流れを示す
線グラフは相互関係、棒グラフはトレンド、円グラフは比較を示す
写真はそれが現実にあることを示す
イラストは特徴を示し、写真にありがちな不要な詳細を排除する
マップや絵は関係をしめす
表は数字を強調する。数字の値が重要な場合は表、比較やトレンドが重要な場合はグラフがよい

全ての評価者が理解できるまで図を修正する

エグゼクティブサマリーは技術を知らない人にもわかりやすく。
章の中では、段々と技術的詳細度を高めるとよい。
技術的要素の強い章では、十分に正確な技術要素を記述する。

シンプルで落ち着いた、読みやすい図にし、１つの図には１つのキーアイディアのみ示す

キーポイントは１つ。
複数ある場合は、図を分ける。
１０秒ルールを忘れずに。
１０秒でポイント伝わらなければ、アウト。
図は、前面、中面、背面の３つにわけてメリハリをつける。
目立たせたいものを前面にもってくる。

図の前に文章で図を説明する

図と同じ言葉ではダメ。
違う表現を使う。

文章の中に図を入れる

図をみるために、別のページを探さなければならないのはダメ。

図の向き

紙を回転させなければ図がみれないのはダメ。

折り込みの図は最小限に

折り込みの図は、スケジュールとか、最小限に。

図の中の文章は最小限に。文章はアクションキャプションに

図の中の文章はスペルチェックとかできないし。

章ごとに番号付けする

「章-番号」がいい。
「章-節-番号」だと細かすぎる。

全ての図にアクションキャプションをつける

文章を書く前に図を考えるってのができないんだなぁ。。。

ネタ：APMP Proposal Guide: the Foundation Accreditation Study Guide

https://apmp.site-ym.com/store/view_product.asp?id=1018152

参考：kumi shiki blog

http://kumishiki.wordpress.com/

2013年10月3日木曜日

ORGANIZATION

受託開発だろうとなんだろうと、技術が中心だ。

でも、技術が中心にならないことが多くって、だからSIはオワコンとか言われてしまうんだと思う。

受託開発で技術を真ん中に持ってくるには、はじめのはじめから変えないとダメだ。

だから、提案についてちょっぴり勉強をはじめてみました。
APMPのテキストを読んだ感想など書いてみます。

構成(ORGANIZATION)

構成はビジネス文書の鍵となる。提案書も同じだ。
よい構成であれば書きやすい。ライティングスキルに自信がなければなおさらだ。
ひどい構成の提案書は救いようがない。

提案書を読む人は、主に次の2つを要求する。

すぐにみつけられる。
すぐに理解できる。

全てを読んでくれる評価者はほとんどいない。
小説のように、はじめから順に終わりまで読んではくれない。
評価項目ごとに、回答をを探し、評価するという手順を繰り返す。

よい構成の提案書は次の特徴を持つ。

構成を示し、そのとおりになっている。
キーポイントを明確にし、評価者がわかりやすい。
カスタマーフォーカスで、何が重要か、評価者の立場で考えられている。
評価者が構成を理解し、必要な情報をすぐに見つけられ、その内容を理解できるように、複数の表現を用いている

提案依頼書で示された構成に従いなさい

このガイドに違反してもいいから、とにかく、提案依頼書で示された構成に従いなさい。
指定がなければ、内容、サイズ、構成について聞きましょう。
そのときは、オープンクエスチョンよりクローズドクエスチョンを使いなさい。
ここを確認しておくと、それをしていない競合より優位になります。

秩序立てて考え、早く、効率的に欠けるように一貫したプロセスに従いなさい

POWeRステップを使うとよい。

Planning:計画

目的を決める
対象者を分析する
メッセージを分析する
最適な媒体を選ぶ
コンテンツをつくる

Organizing:構成

お客様に指定されたとおりにする
サマリーの後に詳細
4-Boxアプローチを使う
強調すべき点を決める

Writing:執筆

ドラフト
強調テクニックを使う

Examining:検証

精錬させる
外部レビュー(同僚、マネージャー、お客様)

Revising/Rehearsing:遂行

メッセージをはっきりと
メッセージを簡潔に
メッセージを正確に

※eだけ小文字なのは、大文字:執筆者、小文字:その他の意味

3.評価しやすいように構成しなさい

評価者は次の表現に目がいく。

見出し
図
アクションキャプション
色
余白
大きな字、太字、色付きの字
はじめの段落
箇条書き
吹き出し
ヘッダー、フッダー

これらをうまく組み合わせることが重要だ。
提案書を全て読まなければならない構成だと、大抵負ける。

4.全てのレベルでまとめなさい

ページ、パラグラフ、センテンスのはじめが最も重要だ。
そして、それぞれの最後が次に重要だ。
時間がなければ、オープニングサマリーとクロージングサマリーに注力しなさい。
サマリーと導入を誤解してはいけない。
サマリーは簡潔に重要な点を示したもの。
導入は内容のプレビューだ。
この2つを混ぜてはいけない。
サマリーをはっきり書き、その後に導入を書くとよい。
サマリーの書き方はexecutive summaryと同様だ。

5.似たアイディアはまとめなさい

次のような場合、うまくまとめなければならない。

同じような要求項目がばらけている
異なる要求に同じソリューションが必要
複数の執筆者が気付かずに同じようなことを書いてしまう
同じ原稿から複数の執筆者が書く

ストーリーボードを使ってうまく整理しましょう。
クロスレファレンスをさけるためには、次のようにするとよい。

1.2.3にも記載していますが、再掲します。
概要をここに示します。詳細は1.2.3をご参照ください。

6.セットアップは短くしなさい

本文の前にセットアップが必要なことがある。

あなたの言葉でニーズを書きなさい。提案依頼書のコピーはダメ(理解していないと思われる)。
value proposition(価値提案)かベネフィットから書きなさい。使い古された決まり文句はダメ(提案の機会を与えていただき・・・とか)。
1文か1フレーズにしましょう。

7.最も重要な点をはじめに書きなさい

大事な順に書かれているか常に意識しなさい。

8.評価者が期待に合わせて、文体やスタイルを章ごとに調整しなさい

エグゼクティブが読むところは図を用いてわかりやすく書いたり、
技術者が読むところは、技術的な内容を詳細に書いたりして、
調整しましょう。
ただし、技術書ではないので、わかりやすいサマリーをはじめに書くのは
一貫して重要だ。

9.ドラフトを前にメッセージを構成するのに役立つテンプレートを使いなさい

4-Boxテンプレートなどをうまく使いましょう。

提案のポイントってところに、「○○を示します。」って書いてある提案書がよくある。
まさに、サマリーと導入を誤解してる。

ネタ：APMP Proposal Guide: the Foundation Accreditation Study Guide

https://apmp.site-ym.com/store/view_product.asp?id=1018152

参考：kumi shiki blog

http://kumishiki.wordpress.com/

2013年9月6日金曜日

ACTION CAPTIONS

受託開発だろうとなんだろうと、技術が中心だ。

でも、技術が中心にならないことが多くって、だからSIはオワコンとか言われてしまうんだと思う。

受託開発で技術を真ん中に持ってくるには、はじめのはじめから変えないとダメだ。

だから、提案についてちょっぴり勉強をはじめてみました。
APMPのテキストを読んだ感想など書いてみます。

訴える表題(ACTION CAPTIONS)

10秒ルールというのがある。読み手は、10秒でポイントが理解できなければ、ページをめくってしまう。訴える表題は、伝統的なやり方とは異なるけれど、徐々に受け入れられつつある。

全ての図に訴える表題を使う

図は評価者の目を引き寄せ、訴える表題が評価者の目をつなぎとめる。
表題は１フレーズや１文にすべきという考え方もあるが、短い表題では重要な情報を書ききれないので、本文から情報を探さなければならない。
２～４文は、受け入れてもらえる長さだし、評価者に十分な情報を伝えられる。
訴える表題で表現したポイントは、本文で繰り返す必要はない。強調のためにあえて繰り返す場合は、別の表現にするとよい。

訴える表題は図表番号、タイトル、表題の３つ

図表番号は章ごとに採番するとよい。
章の部分を細かくして3.4.5.1-1.のようにすると読みにくいので、章ごとがいい。

ビジネスでは、図、表、グラフなどを区別して採番するが、区別が難しい。
全て「図」で統一してしまうのが読み手も書き手も楽だ。

訴える表題には、お客様の利益と機能が含まれていて、機能がお客様の利益につながっていなければならない。

図で描いた機能をお客様の利益に結びつける

もし、お客様の利益に結びつけるのが難しい場合、次の２つの対処方法がある。

お客様の利益につながらないなら、その図は削除しなさい。
お客様の求めている利益が何なのか分からないなら、絶対負けるので提案自体やめなさい。

できるだけお客様の利益は定量的にする

できるだけ定量的な方がよい。

訴える表題は図の下に書く

多くの人は上から下、左から右に読む。

評価者はまず図に目がいくので、訴える表題はその下にするとよい。

より精錬されたデザインではその限りではないが、提案書はシンプルに図の下で統一するとよい。

本文では番号で参照する

本文ではすべての図を番号で参照する。

タイトル、表題、本文は別のスタイルで書く

番号とタイトルは太字にするとよい。

図表に長い説明ってやったことないし、見たことない。
今度試してみよう！

ネタ：APMP Proposal Guide: the Foundation Accreditation Study Guide

https://apmp.site-ym.com/store/view_product.asp?id=1018152

参考：kumi shiki blog

http://kumishiki.wordpress.com/

2013年8月13日火曜日

STRATEGY

受託開発だろうとなんだろうと、技術が中心だ。

でも、技術が中心にならないことが多くって、だからSIはオワコンとか言われてしまうんだと思う。

受託開発で技術を真ん中に持ってくるには、はじめのはじめから変えないとダメだ。

だから、提案についてちょっぴり勉強をはじめてみました。
APMPのテキストを読んだ感想など書いてみます。

戦略(STRATEGY)

戦略はゴールを達成するための計画や方法だ。しばしば、戦略と戦術が混同されるが、戦術は戦略を実行するためのアクションのことだ。

今のポジションを分析する

標準的なツールを複数使って、自社の今のポジションを分析しよう。

ホットボタンを探す

お客様に最も響くホットボタンをみつけだす。

課題：お客様の心配事のこと。

動機：利益を増やす、売上を増やす、コストを削減する、安全性を高める、リスクを減らす、品質を高める　などのお客様が達成したいこと。

ホットボタン：課題と動機のセットで、お客様の言葉で表現し、2から5つくらいにしぼる。

セールス目標を立てる

追跡することが決定されたら次の条件を満たすセールス目標をたてる。

具体的：どんな製品やサービスを誰が買うか
測定可能：いくらで
時間：いつ
結果：可能な限り定量的な結果

経営層、ユーザー、システム担当を特定し、彼らの課題をリストアップする

経営層は費用対効果に注目する。そして、経営層が最終的な決断をする。

ユーザーは自分たちの仕事の効率化に注目する。

システム担当は、製品やサービスの機能に注目する。

統合ソリューションワークシートを使ってソリューションを決定する

No.	課題	要件	ソリューション	ギャップ	競合のソリューション	差別化要素	戦略	アクション
1

競合比較表をつくる

課題	重み	自社	競合A	競合B
課題1
課題2
課題3
合計	100

※重みの合計は必ず100にする。

ベストソリューションを選ぶ

各お客様に、ベストソリューション、アプローチ、価値提案をする。

価値提案とはソリューションの価値のことだ。

価値提案は、次の要素を含む。

定量的ビジネス改善
タイミング
ソリューション
投資額
ペイバック
結果測定と証跡

戦略記述のドラフトをつくる

何をどのように実現するかを定義する。

戦略は次の４つの方法で実現される。

強みを強調する
弱みを緩和する
競合の弱みを強調する
競合の強みの重要度を下げる

戦略記述ワークシート

我々は、我々の強みである[　　　　　]を強調する。[　　　　　]によって。
我々は、我々の弱みである[　　　　　]を緩和する。[　　　　　]によって。
我々は、競合の弱みである[　　　　　]を強調する。[　　　　　]によって。
我々は、競合の強みである[　　　　　]の重要度を下げる。[　　　　　]によって。

アプローチの検証と競合の代筆のトレードオフを使う

？？？
※よく意味がわからない。
※競合を落とすことを言ってるみたいだけど、何がトレードオフ？

アクションプランをつくる

戦略を発展させることと実行のバランスをとる。

アクションはお客様が自社のソリューションを選択するために行う。

この章はおもしろくないなぁ。

ネタ：APMP Proposal Guide: the Foundation Accreditation Study Guide

https://apmp.site-ym.com/store/view_product.asp?id=1018152

参考：kumi shiki blog

http://kumishiki.wordpress.com/

2013年7月18日木曜日

STORYBOAD

受託開発だろうとなんだろうと、技術が中心だ。

でも、技術が中心にならないことが多くって、だからSIはオワコンとか言われてしまうんだと思う。

受託開発で技術を真ん中に持ってくるには、はじめのはじめから変えないとダメだ。

だから、提案についてちょっぴり勉強をはじめてみました。
APMPのテキストを読んだ感想など書いてみます。

ストーリーボード(STORYBOAD)

ストーリーボードは映画の絵コンテみたいなもので、提案書作成の効率化が目的だ。ストーリーボードは文章と図で提案のアウトラインをつくる。

小さなストーリーボード

タスクの理解

この章で書くべきこと

要求の分析

要求との対応（きちんと答えているか）

提案内容

主な課題
アプローチ（技術/管理）
特徴と効果
主張の補足、根拠

戦略

差別化要素
テーマ

図表

図表タイトル
アクションキャプション

一般的なストーリーボード（提案開発ワークシート）

「タスクの理解」と「要求の分析」は、キックオフミーティングの前に、コアメンバーがを整理しておき、メンバーに提供するとよい。

ストーリーボードを完全に仕上げてからメンバーに提供する方法はうまくいかない。

他人のつくったストーリーボードは無視しがちだからだ。

書く前にコンセプトをはっきりさせて手戻りをなくし、勝てる提案書にする。

そのためにうまくストーリーボードを使おう。

関連する提案情報
関連するRFPの項目
要求との対応チェックリスト

RFPの項目
RFPへの対応

アウトライン（RFPの要求ベース）

見出し番号
見出しタイトル

関連する提案戦略
主な課題
要求と課題へのアプローチ
ソリューションの特徴と効果
差別化要素
リスク
経験・実績
メッセージ
テーマ
図表
アクションキャプション

ストーリーボードを管理ツールに

手戻りを防止するために、全てのストーリーボードを頻繁にレビューするべきだ。
スピードアップのために、以下の手順のワークショップ形式でやるという方法もある。

タスクについて説明し、明確な品質標準を決める。
短い時間でタスクを完成させるように依頼する。
どんな質問にも回答し、共有する。
グループでレビューし、協働を促進させ、情報共有と改善を促進する。
十分な内容になるまで繰り返す。
次の章に入る。

提案開発ワークシートはBDUP(Big Design Up Front)だと思う。
アジャイル好きとしては、以下の順にインクリメンタルかつイテレーティブにやるといいと思う。

小さなストーリーボード
提案ポイント
見出し（アウトライン）
トピックセンテンス
重要な図表
文章

最初にワークショップ形式でやるのはいいかも。
今度やってみよう。

ネタ：APMP Proposal Guide: the Foundation Accreditation Study Guide

https://apmp.site-ym.com/store/view_product.asp?id=1018152

参考：kumi shiki blog

http://kumishiki.wordpress.com/

2013年6月30日日曜日

EXECTIVE SUMMARY

受託開発だろうとなんだろうと、技術が中心だ。

でも、技術が中心にならないことが多くって、だからSIはオワコンとか言われてしまうんだと思う。

受託開発で技術を真ん中に持ってくるには、はじめのはじめから変えないとダメだ。

だから、提案についてちょっぴり勉強をはじめてみました。
APMPのテキストを読んだ感想など書いてみます。

エグゼクティブサマリー(EXECTIVE SUMMARY)

エグゼクティブサマリーはソリューション、得られる利益、競合に対する優位性が読み手にはっきりと伝わらなくちゃいけない。

よいエグゼクティブサマリーの基準

お客様のビジネスビジョンに沿っている
お客様のどのステークホルダーがどのようなニーズを持っているか明示している
ソリューションがお客様のニーズを直接解決している
主張の根拠を明示している
競合に対する優位性を根拠をとともに明示している
難しい技術用語は使わず、簡潔かつ包括的である
提案書の構成を示すなどにより全体の内容をリードする

内部での使い方

戦略を推敲するために使う
管理職の承認を得るために使う
関係者に戦略を説明するために使う
提案書作成の方向性を示すために使う
提案書のモデルとして使う

求められなくてもエグゼクティブサマリーはつくる

エグゼクティブサマリーの提出が求められていようといまいと、問答無用でエグゼクティブサマリーをつくるべきだ。

マネジメントサマリーとかマネジメントオーバービューとかお客様が呼んでいるなら、その名前で呼ぶこと(いつでもどこでもお客様の言葉で語ること)。
サマリーと導入は区別すること。サマリーは要点で、導入は全体構成だ。
エグゼクティブサマリーが求められてないときは、別添にするか、初めの章につけるか、各章の頭につけるかするといい。ただ、ページ制限があるときには気をつけないといけない。

首尾一貫お客様起点で

お客様のビジョンを明記する
ビジョンと提案を直結させる
ホットボタンを重要な順か提案依頼書の記載順に明記する
誰に対するホットボタンなのかを明記する
初めに記載した順にホットボタンの内容を記載する
自社がどういいとかではなく、お客様がどうよくなるかを書く
自社について書く前に、お客様について書く
機能の前にお客様にとっての価値について書く

既存の営業プロセスや戦略をベースに作成する

獲得計画、提案計画をベースにするとよい。
統合ソリューションワークシート、競合比較表、戦略記述ワークシートを基にエグゼクティブサマリーソリューションワークシートを作成する。

統合ソリューションワークシート

No.	課題	要件	ソリューション	ギャップ	競合のソリューション	差別化要素	戦略	アクション
1

競合比較表

課題	重み	自社	競合A	競合B
課題1
課題2
課題3
合計	100

※重みの合計は必ず100にする。

戦略記述ワークシート

我々は、我々の強みである[　　　　　]を強調する。[　　　　　]によって。
我々は、我々の弱みである[　　　　　]を緩和する。[　　　　　]によって。
我々は、競合の弱みである[　　　　　]を強調する。[　　　　　]によって。
我々は、競合の強みである[　　　　　]の重要度を下げる。[　　　　　]によって。

エグゼクティブサマリーソリューションワークシート

	#1	#2	#3	#4
ホットボタン
ソリューション
代替案
差別化要素
根拠（実績）
根拠（機能・性能）

はっきりと説得力のある構成にする

エグゼクティブサマリーソリューションワークシートができたら、4Boxテンプレートに落としこむ。

Box1：サマリー

お客様の戦略テーマ、お客様のビジョン
（目的、目標、提案ソリューションへの伏線などを含めてもよい）

Box2：導入

ホットボタン（主要なものをいくつか）
（ニーズ、キーポイント、課題、目標などを考慮する）

Box3：本文

ホットボタンごとに次を記載。
提案ソリューション、ソリューションがもたらすお客様の利益、根拠、図表

Box4：レビュー

まとめと今後の方向性

4Boxテンプレートを基にドラフトを作成する

次の作業をすることで、4Boxテンプレートからエグゼクティブサマリーのドラフトを作成する。

図表を推敲する

図表にメッセージを伝える表題（アクションキャプション）をつける

評価者を図表に注目させる文章を書く

ソリューションについて記述する

実績と機能・性能に関する根拠を記述する

ルール上問題なければ、コストについてまとめる

提案の構成を記述する

ベストプラクティスに基づきチェックする

ベストプラクティス

キックオフミーティングの前にエグゼクティブサマリーのドラフトを完成させる
管理者がドラフトをレビューし、ソリューションを詳細化する
可能であればお客様にレビューをしてもらう
提案書の5～10%で、お客様の管理者が読みやすい程度の量にまとめる
図表中心にまとめる
プレゼンのベースに使う
首尾一貫お客様起点でまとめる

ガイドラインに従う

ガイドライン

20ページ以下の小さな提案書以外は、独立したドキュメントとしてエグゼクティブサマリーを作成する
技術者向けではなく、上位層向けに作成する
簡潔かつ包括的にする
図表を含める
読み手が提案関連の情報を持っていることを前提にしない
お客様起点で構成を決める
提供する事項とそれがどのようにお客様の利益となるのかを明示する
主な差別化要素とお客様の課題をはっきりと関連づける

時間がないとき

時間がないときは以下の簡易プロセスに従う。

お客様のホットボタンを定義する（2～5）。Box1
主要な要件、ソリューション、差別化要素を少なくとも1つのホットボタンに対応づける。Box3
お客様のビジョン、ニーズとソリューションを対応づける。Box1
価格、ソリューション、提案の優位性をまとめ、今後の方向性を示す。Box4
チームでレビューし、推敲する。特に複数人で作成しているときは注意が必要。
可能な限り推敲する。

エグゼクティブサマリー、奥深い。
大抵、提案書作ってから最後に提案書から抜粋して作ってる。。。
ここだ！一番足りないの。

ネタ：APMP Proposal Guide: the Foundation Accreditation Study Guide

https://apmp.site-ym.com/store/view_product.asp?id=1018152

参考：kumi shiki blog

http://kumishiki.wordpress.com/

2013年6月18日火曜日

DISCRIMINATORS

受託開発だろうとなんだろうと、技術が中心だ。

でも、技術が中心にならないことが多くって、だからSIはオワコンとか言われてしまうんだと思う。

受託開発で技術を真ん中に持ってくるには、はじめのはじめから変えないとダメだ。

だから、提案についてちょっぴり勉強をはじめてみました。
APMPのテキストを読んだ感想など書いてみます。

差別化(DISCRIMINATORS)

差別化はユニークセールスポイント（USPs）といわれる。
違いがあればいいってものじゃなくて、商談獲得に重要なものでなければならない。
差別化要素がない場合、価格が唯一の差別化となり得る。

しかし、多くの場合、勝者と敗者の違いはそれ程大きくはない。

敵を知り己を知れば差別化危うからず

大抵は、競合の提案内容なんてわからない。
そのうえ、要求は曖昧だ。

　　　我々は、経験豊富なネットワーク技術者を要求する。

ってな具合に。
競合の提案がわからない以上、国内平均や第3者の調査結果などの標準を利用するか、自社提案以外のアプローチの劣っている点を明確化することだ。

正と負の両方の差別化を明確にし、可能な限りよく見せる

正と負の差別化を明確化した例:

弊社は、○○に使用される唯一の☓☓を製造しています。
最近、☓☓の欠陥で大きな事故がありました。
弊社のお客様は、弊社と協力し、原因を特定するためにNNN百万ドルを費やしました。

よくみせた例：

弊社は、○○に使用される唯一の☓☓製造業者です。
さらに、最近、弊社のお客様と共同でNNN百万ドルを費やして設計を改善しています。
弊社以外の製造業者を選択する場合、弊社が過去に様々なお客様と共に実施してきた投資と同規模の投資が必要となる可能性があります。

差別化要素が今でも差別化できているか継続的に確認する

ニーズは変化する。
同じお客様だからといって、一度うまくいった戦略がまたうまくいくとは限らない。

継続して差別化要素をより明確にする

「明確だけど一般的」という表現がある。

明確だけど一般的

プログラム管理者はプログラムチームと共にいつもリスクログをレビューし、必要な緩和策を追求する。

明確

佐藤一郎はプログラム管理者である。彼はリスクログを毎週金曜日にレビューし、次の月曜日の営業終了時間までに、プログラムWebサイトに改善事項を公開する。

人、経験、性能、業務の理解に焦点を絞り、差別化要素を強調する

提案依頼書がでる前に、お客様との間にラポールを構築しよう。
家をリフォームするときに、どんな人が自分の家に入って作業をするのか気になるのを考えれば、それが重要なことがわかるはず。
決定的な差別化要因はお客様の業務、ビジョン、直近のニーズの理解であることがしばしばある。
どうやって、お客様の戦略ビジョンを実現するかを最もよく示すことが商談獲得につながる。
提案書全体で、お客様の業務を理解していることを示すことで差別化しよう。

下線部分、当たり前と言えば当たり前。
知っていたと言えば知っていた。
でも、できてないなぁ。。。

ネタ：APMP Proposal Guide: the Foundation Accreditation Study Guide

https://apmp.site-ym.com/store/view_product.asp?id=1018152

参考：kumi shiki blog

http://kumishiki.wordpress.com/

2013年6月15日土曜日

JUnitとCucumberとSeleniumとGithubとJenkinsとSonarとHerokuと（LS研デモ用）

会社の研究会にLS研究会というのがあって、「アジャイル開発における開発・保守の品質保証」の研究チームのTA（テクニカルアドバイザー）をやらせてもらっている。

TAなんて言えるほど、自分には知見がないのだけれど、少しでもお役に立てればと思って、JUnitとCucumberとGithubとJenkinsとSonarとHerokuをからめたデモを用意してみた。
（https://github.com/itagakishintaro/fizzbuzz-web）

目的は３つ。

経験者が少ないので、アジャイル界隈でホットな技術について実際に触れていただきたい。
ドキュメントをテーマにするのであれば、Cucumber、JUnitはドキュメントの代替になり得るので、どんなものかを知っておいていただきたい。
アジャイルを体験したいという気持ちから試行する方向で話しが進んでいるが、きちんと仮説を立てた上でやらないと研究成果が得られないので注意してほしい。

作ったものは、Fizzbuzz問題を答えるWebアプリ。
View(JSP)、Controller(Servlet)、Model(POJO)各１クラスの最小スペック。

以下の順でやってみた。

1.JUnit

テスト名を日本語にするなどの工夫をして、
どこまで仕様書や設計書の代替になるかを議論してほしい。

参考

書籍「JUnit実践入門」（良書。オススメ。）

2.Cucumberで受入テスト

個人的には、お客様がCucumberの書式で仕様を書いてくれるとは思えないので、どうかと思うけど、アジャイルにおけるドキュメントという観点からは外せないと思う。

※仕様書や設計書の代替という意味ではCucumberに軍配が上がるけど、個人的には、Groovy+Spockの方が好き。

参考

書籍「JUnit実践入門」（良書。オススメ。）

3．Githubに登録

試行をするときの参考にしてもらいたい。
あと、作ったものをみてもらうために。
eclipse+EGitでやってます。
慣れないうちは、eclipse+EGitで最低限のことだけでいいと思う。

ハマリポイント

SSH関連の鍵の設定。
分散型に慣れてないと、ローカルのGitとGithubの関係がわからなくなる。
gitを知らないくせに、色々試したくなってしまう。
github for windowsのUIが素敵なので、eclipse+EGitとどっちにするか迷ってしまう。

参考

webで色々。

4.Jenkinsでビルド

「Jenkins実践入門」を参考にした。
試行をするときの参考にしてもらいたい。

ハマリポイント

Githubとの連携（SSH関連）。

参考

webで色々。何となくできちゃった感じ。次もハマりそう。。。

5.JenkinsからSonarに連携

「Jenkins実践入門」を参考にした。
試行をするときの参考にしてもらいたい。

ハマリポイント

プラグインと設定の書き方（動いてるけど、今もちゃんと理解できてない。）。
pomの書き方（動いてるけど、無駄な記述とかあると思う。）

参考

http://docs.codehaus.org/display/SONAR/Analyzing+with+SonarQube+Runner http://docs.codehaus.org/display/SONAR/Code+Coverage+by+Unit+Tests+for+Java+Project

6.JenkinsからHerokuにデプロイ（が、うまくいってない。）

~~以下のエラーがでてHerokuでTomcatがうまく動かない。。。~~
~~おそらく、lounchのmain.javaのwebappDirLocationがおかしいんだろうけど、よくわからない。~~

java.lang.IllegalArgumentException: Document base /app/src/main/webapp does not exist or is not a readable directory

ハマリポイント

JDKがデフォ6なので7に直さなきゃない（system.propertiesが必要）。
Dynosが動いてくれない（Procfileが必要）。
Tomcatが動かない（Main.javaが必要、pom.xmlに記述が必要）。

参考

https://devcenter.heroku.com/articles/add-java-version-to-an-existing-maven-app

https://devcenter.heroku.com/articles/procfile

https://devcenter.heroku.com/articles/create-a-java-web-application-using-embedded-tomcat

~~Herokuはもう少しがんばってみようかな。~~
~~あと、Seleniumを入れたいなぁ。~~
~~そういえば、SeleniumってCucumberと組み合わせできるのかな。~~
~~やっぱり、受入テストが画面操作じゃなきゃって気がするし。~~
~~よし、やってみよ。~~

→2013/6/17
Slenium+Cucumberをやってみた。
できるけど、cucumberでは@Before, @Afterがきかないみたいでちょっと無理矢理感が。。。
正しいやり方ってあるのかな？
→2013/6/17
cucumber.annotationとHookを使えばいいのか。
→2013/6/20
Herokuへのアップもできた。
ただ、Jenkinsから実行するときgit publisherでうまくいかないのでwindowsコマンドにしてしまった。。。

2013年6月13日木曜日

PROPOSAL MANAGEMENT PLAN

受託開発だろうとなんだろうと、技術が中心だ。

でも、技術が中心にならないことが多くって、だからSIはオワコンとか言われてしまうんだと思う。

受託開発で技術を真ん中に持ってくるには、はじめのはじめから変えないとダメだ。

だから、提案についてちょっぴり勉強をはじめてみました。
APMPのテキストを読んだ感想など書いてみます。

提案計画(PROPOSAL MANAGEMENT PLAN)

提案計画は役割、責任、タスク、締め切りを示す。
提案計画ができないうちに、打合せをしてもムダ。アカウントプランを流用して、かしこく提案計画を立てよう。

提案管理計画の例

コンテンツ

提案プロジェクト概要

お客様情報

競合分析

提案戦略

役割と責任

提案作業

添付

提案スケジュール

提案アウトライン

執筆者情報

提案戦略

エグゼクティブサマリーのドラフト

WBS/WBS辞書

目次例

1.0 提案プロジェクト概要

一般情報
プロジェクトの焦点
スコープと成果物

2.0 お客様情報

お客様組織の情報
選定プロセス
ニーズ、課題、ホットボタン（購入の決め手となる部分）

3.0 競合分析

競合比較表

4.0 提案戦略

提案戦略：我々は[　　　　　]を強調する。[　　　　　]によって。
価格戦略
関連実績と過去の実績
提案テーマ：価値、差別化要素

5.0 役割と責任

名前、所属、役割、責任、連絡先

6.0 提案作業

施設
サポート
手順

A 提案スケジュール

B 提案アウトライン

提案No.、章タイトル、RFP No.、担当、ページ数
ストーリボード完成日時
第1回レビュー日時
最終レビュー日時
モックアップレビュー日時
ピンクチーム日時
図完成日時
ドラフト完成日時
赤チーム日時

※ピンクチーム、赤チームって何？デッドライン的なこと？

C 執筆者情報

ストーリボード形式
参考Webサイト
参考資料
提案書テンプレート

D エグゼクティブサマリーのドラフト

強調点、テーマ、ヴィジョン、ホットボタン
ホットボタン１~n：強調点、ソリューション、価値、根拠、図
コスト：強調点、概要図、概要と次のステップ

E WBS/WBS辞書

WBS
WBS辞書

ここまでできれば、確かに完璧だよなぁ。。。
難しいのは提案戦略とエグゼクティブサマリー。
大抵は、提案書書きながらみんなで考えて、最後にエグゼクティブサマリーを作ってしまう。
ダメだとわかってはいるけど、やっぱり難しい。。。

ネタ：APMP Proposal Guide: the Foundation Accreditation Study Guide

https://apmp.site-ym.com/store/view_product.asp?id=1018152

参考：kumi shiki blog

http://kumishiki.wordpress.com/

2013年6月11日火曜日

オブジェクト指向らしいってなんだろう？

DevLoveの「オブジェクト指向でコードが書けるようになろう。」に参加してきた。

会員情報として、次の情報があって、氏名は20文字以内とかメアドやパスワードにもルールがある場合、いくつのクラスをどんな名前で作りますか？

氏名
メールアドレス
パスワード

的な課題を議論した。

答えはないけど、オブジェクト指向らしいってこんなことだよねっていう結論が以下の感じ。

会員クラス１つでつくっちゃうんじゃなくて、氏名クラス、メールアドレスクラス、パスワードクラスを作って、それらのクラスでルールをチェックする。

単一責務にする（高凝集）
データとロジックは同じ場所におく

そうだ、そうだ。

そうした方が変更に強く、簡潔で、オブジェクト指向らしい。

ん！？

オブジェクト指向らしい？

オブジェクトってなんだっけ？

英辞郎（http://www.alc.co.jp/）で調べたら

　　　〔視覚や触覚で感知できる〕物、物体

が1番目にでてくる。

そうだよね。

「視覚や触覚で感知できる」だよね。

名前オブジェクト？

メールアドレスオブジェクト？

パスワードオブジェクト？

変じゃない？視覚や触覚で感知できないよね。

オブジェクトじゃなくてインスタンスならすっきりするかな。

でも、じゃあ、これらをどう区別するか？

会員クラスの内部クラスとして、名前クラス、メールアドレスクラス、パスワードクラスを定義すればどうだろう？

名前もメールアドレスもパスワードも業務固有の型を持っているからクラスにするけど、あくまで属性として扱う。

考え過ぎかなぁ。。。

KICKOFF MEETINGS

受託開発だろうとなんだろうと、技術が中心だ。

でも、技術が中心にならないことが多くって、だからSIはオワコンとか言われてしまうんだと思う。

受託開発で技術を真ん中に持ってくるには、はじめのはじめから変えないとダメだ。

だから、提案についてちょっぴり勉強をはじめてみました。
APMPのテキストを読んだ感想など書いてみます。

キックオフ(KICKOFF MEETINGS)

キックオフは次の目的で実施する。

みんなに活動を開始してもらう
商談に関する質問に答える
提案書作成の役割分担をする
直近の作業を調整する
一致団結したチームを形成する

提案依頼書を入手したら、すぐにでもキックオフをしたいと思うだろうけど、我慢しよう。
拙速なキックオフは、進捗の錯覚、手戻りを招き、ダメな提案につながる。

キックオフの準備

キックオフの前に、準備期間の15%をコアチーム計画に当てよう。
準備期間は、提案書のドラフトを手に入れられるか、獲得計画とコアチーム計画が承認されるか、提案管理計画が完成しているかにかかっている。

キックオフメンバー

キックオフのメンバーは、「集まれる人が必要」なんじゃなくて、「必要な人を集める」んだ。

完全で簡潔なアジェンダ

10～30人なら2～3時間以内でキックオフをしよう。
課題解決の場ではないので、課題がでたら別の打合せを設定して本題に進もう。

キックオフの準備

必要なもの

提案プロジェクト概要（商談情報など）
お客様情報（ニーズ、課題、ホットボタン、評価プロセス、自社とのつきあい）
提案戦略（全体戦略、差別化ポイント、キーメッセージ）
提案作業（フォーマット、再利用素材、レビュー方法）
提案アウトライン（章立て、ページ分配、担当者、締め切り）
執筆パッケージ（提案開発ワークシート、ストーリーボード、割当、ページ数制限、ガイドライン、チェックリスト）
RFP（提案依頼書）

望ましいもの

競合分析（競合情報、統合ソリューションワークシート、競合比較表）
役割と責任（メンバー、作業場所、連絡先、役割、経験、コスト、作業可能時間）
エグゼクティブサマリーのドラフト（ニーズ、ソリューション、戦略）
WBS/WBS辞書（提案活動のWBS）

ガイドライン

手戻りを防止するためにガイドラインを用意しよう。

提案開発ワークシート、ストーリーボード、コアチーム計画ってなんだろう？
次に読んでみよう。
キックオフは大体自分のやろうとしていること（できてないけど）とほぼ一致してるなぁ。

ネタ：APMP Proposal Guide: the Foundation Accreditation Study Guide

https://apmp.site-ym.com/store/view_product.asp?id=1018152

参考：kumi shiki blog

http://kumishiki.wordpress.com/

2013年6月9日日曜日

CAPTURE PLANNING

受託開発だろうとなんだろうと、技術が中心だ。

でも、技術が中心にならないことが多くって、だからSIはオワコンとか言われてしまうんだと思う。

受託開発で技術を真ん中に持ってくるには、はじめのはじめから変えないとダメだ。

だから、提案についてちょっぴり勉強をはじめてみました。
APMPのテキストを読んだ感想など書いてみます。

獲得計画(CAPTURE PLANNING)

獲得計画は、競合に勝てる見込みを立てることだ。文書化されていて、行動指向じゃないとダメ。
大体、提案依頼がでる前に40%〜80%位、意中の会社が決まってる。
獲得計画を立てて、提案依頼がでる前に意中の会社にならないと。

獲得計画の作成手順

ビジネス戦略
-(30％再利用)->アカウントプラン
-(40％再利用)->獲得計画
-(60％再利用)->提案計画
の順に、前のドキュメントを再利用して作成する。

獲得計画の内容

外部分析、内部分析、戦略、実行と監視という獲得計画の一般的な構造で作成する。
たとえ、時間がなくても、統合ソリューションワークシートと競合比較表をつくるべきだ。

体制

手が空いている人材でチームをつくると大抵負ける。適切な人材を任命しないとダメ。空き時間に作業させるのもダメ。ちゃんと見通しを立てて、必要な体制を立てないから負けるんだよ。

我が組織は、すでに40%～80%位意中の会社が決まっている提案依頼書公示後から動き始めることもしばしば。
ビジネス戦略は正直チープだし、アカウントプランもいつ作ったんだよ状態。
提案メンバーもそのとき手が空いているメンバーでやりくりしてる状態。
それより何より、獲得計画も提案計画も存在しない！
どうしたものか。。。

ネタ：APMP Proposal Guide: the Foundation Accreditation Study Guide

https://apmp.site-ym.com/store/view_product.asp?id=1018152

参考：kumi shiki blog
http://kumishiki.wordpress.com/

2013年6月8日土曜日

BID DECISIONS

受託開発だろうとなんだろうと、技術が中心だ。

でも、技術が中心にならないことが多くって、だからSIはオワコンとか言われてしまうんだと思う。

受託開発で技術を真ん中に持ってくるには、はじめのはじめから変えないとダメだ。

だから、提案についてちょっぴり勉強をはじめてみました。
APMPのテキストを読んだ感想など書いてみます。

商談方針決定¹ (BID DECISIONS)

商談方針決定は、勝率の低い商談を避け、勝てる商談に集中するための意思決定で、次の３つからなる。

追跡判断

追跡する価値はある？その商談に対する実行能力はある？
あるなら、獲得計画（Capture Plan）の準備を始めよう。

入札判断

勝ち目はある？提案のためのリソースはある？

入札するなら、提案計画（Proposal Plan）の準備を始めよう。

入札検証

最新の提案依頼書を手に入れよう。

入札できない要件はない？提案計画はずれてない？

入札検証したら、キックオフ・ミーティングだ。

こんな商談方針決定はイヤだ！

営業の数字目標に合わせてどの商談を扱うか決まっちゃう。
取捨選択って何？全部いっちゃえ！
提案依頼書を受け取ってから活動がはじまる。
入札検証って何？入札しないとかありえないし。

提案を改善すると、大抵、勝率は15～20%上がり、商談方針決定を改善すると勝率は２倍～３倍になるとのこと。
私の所属では、商談方針検討会なるものがありますが、あまり機能していません。
入札直前にやることも多く、その場合、当然追跡判断というものが存在し得ません。

ちなみに、「こんな商談方針決定はイヤだ！」がほぼ満点。。。

提案活動のコストの20%が追跡から入札判断までに使われるのが適切らしい。
社内の予算がどういう割合で使われているか。
見える化するところから始めないといけないなぁ。

ネタ：APMP Proposal Guide: the Foundation Accreditation Study Guide

https://apmp.site-ym.com/store/view_product.asp?id=1018152

参考：kumi shiki blog
http://kumishiki.wordpress.com/

1: BID DECISIONは直訳すると入札決定だけど、入札の前にその商談を追跡するところが一番重要だと思うので、商談方針決定と訳してみました。

登録: 投稿 (Atom)