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

時間がないとき

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

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

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

ネタ：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/

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/

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

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

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


目的は３つ。

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

作ったものは、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コマンドにしてしまった。。。

PROPOSAL MANAGEMENT PLAN

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

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

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

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

---

提案計画(PROPOSAL MANAGEMENT PLAN)

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

提案管理計画の例

コンテンツ

1. 提案プロジェクト概要
2. お客様情報
3. 競合分析
4. 提案戦略
5. 役割と責任
6. 提案作業

添付

1. 提案スケジュール
2. 提案アウトライン
3. 執筆者情報
4. 提案戦略
5. エグゼクティブサマリーのドラフト
6. 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/

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

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/

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/

BID DECISIONS

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

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

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

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

---

 商談方針決定¹ (BID DECISIONS)

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

追跡判断

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

入札判断

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

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

入札検証

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

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

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

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

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

提案を改善すると、大抵、勝率は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は直訳すると入札決定だけど、入札の前にその商談を追跡するところが一番重要だと思うので、商談方針決定と訳してみました。