No profit grows where is no pleasure ta'en.: 10月 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/

登録: 投稿 (Atom)