2014年1月18日土曜日

「第1回 日本Seleniumユーザーコミュニティ勉強会」に参加してきました。


「第1回 日本Seleniumユーザーコミュニティ勉強会」に参加してきました。


コミュニティ開催のごあいさつ【伊藤望さん】

日本Seleniumユーザーコミュニティは、Seleniumに関する分からないこと・困ったことについてユーザー同士で助け合うグループ。
https://groups.google.com/forum/#!forum/seleniumjp

早速、私も登録しました。
登録したけどメールが届かない人メールの設定を見直してくださいとのことなので、1日1通まとめメールが届くようにしました。

今回の申し込みアンケートでは、Seleniumは、やっぱりWebDriverを使っている人が一番多くて、次がSelenium IDE。言語はJavaが圧倒的に多い。


招待セッション(通訳あり)【Jason Hugginsさん】

Seleniumの生みの親であるJason Hugginsさんのお話。


Selenium

2004年、Seleniumが生まれた。
その頃、Ajaxなどが生まれ、テストがしにくく、それを解決するためにSeleniumを作った。
Seleniumはロボットのようなものだ。

Selenium Job Trends(Seleniumを使える人に対する求人)でみると、2007年くらいから人気になり、2012年くらいからはQTPを上回っている。
QTPはMercuryが作っていて、Mercuryは水銀という意味。Selenは水銀の毒性をとる物質。そうなってるね(^^)


Appium

今、mobileが本当に大きくなっている。mobileのテストを無視できない。
mobile向けのseleniumの位置づけのappiumをつくった。
クロスプラットフォーム(iphoneとandroidの両方に対応)で、ネイティブアプリとハイブリッドアプリに対応している。
githubでソースを公開している。twitterは@AppiumDev。


Appium Philosophy

Rule 1
Test the same app you submit to the marketplace

Rule 2
Write your tests in any language, using any framework

Rule 3
Use a standard automation specification and API

Rule 4
Build a large and thriving open-source community effort


AppiumはSelenium WebDriverを使っている。
Selenium WebDriverはW3C working draftになっている。
コードを書かないでいいように、ブラウザベンダーに対応させたい。


Appium Architecture

iOS


Android

クロスプラットフォーム対応しているので、1つのテストでiOSもAndroidもテストできる。


ここでAppiumとHealthcare.govのdemoがありました。


Sample code




Selenium 3はWebとmobileのテストの両方に対応しようとしている。
アメリカの電話では数字とアルファベットが対応していて、4723はipadとなる(^^)


SeleniumはRobotだ

ということで、本当にロボットをつくったよ。
tapsterbot.com
@Tapsterbot
Legoと互換性があるよ(^^)




将来的にはSeleniumから操作できるようにしたい。

ここでtapsterbotのdemoがありました。


Sauce Labs?

宣伝じゃないよ(^^)
シミュレーターなどをクラウドで提供している。
どんなプラットフォーム、ブラウザにも対応。


Q&A

Q1:Selenium WebDriver, Client Server, Browserの3 つで動いている。Browserの進化にClientがどう追いつく仕組みになっている?
A1:Selenium3では、Browserについてはコミッターが責任を持たずに、Browser側に対応してもらう。非難がSeleniumにこないで、Googleにいくようにね(^^)

Q2:いつSelenium3がでる?
A2:Webページのタスクがすべて終われば。責任者も書いてるよ(^^) RCはなくなるので、WebDriverに移行するいいタイミング。

Q3:Selenium3って?(質問を聞きのがした・・・
A3:ゴールはコードを書かないこと。Browserが全て対応するのには時間がかかるけど。

Q4:Appiumはmobileのブラウザのテストはできる?
A4:対応している。

Q5:WebDriver vapクラス???はどうなる???(質問がよくわからなかった・・・
A5:私は答えられない。ごめんね。WebDriver1はすべてJavaScript。WebDriver2からはOSのネイティブイベントを使ってる。

Q6:Selenium3の新機能を教えて。mobile対応の他には?Selenium2との互換性は?
A6:Selenium2と互換性がある。Platformname, Platformversionが入れられる。mobile独自のAPIへの対応。デスクトップ関連は新機能はほとんどない。mobile対応が主な新機能。

Q7:Gebの動作がIEだと遅かったり、たくさん操作すると異常終了する。Selenium3になると性能や安定性は向上する?
A7:テストが遅いなら、多くのマシンを使うのがいいよ(^^)Seleniumの外の問題も多い。httpプロトコルを使う部分に問題が多い。GoogleがSpeedyというプロトコルを提出している。Selenium3では対応できないけどね(^^)

Q8:Appium Loadmap資料もらえる?
A8:いいよ。

Q9:Selenium IDEやBuilderの話をお願い。違いとか。
A9:比較するとそれだけで1講演できる。IDEは笠谷 真也さんがつくった。キャプチャー&リプレイの機能も将来的にサポートしていく。IDEもBuilderもFirefoxに依存している。でも、BuilderはFirefox依存を最低限にしている。Firefox以外への対応はBuilderが優れている。IDEの方がコミュニティは大きいけど、Builderの方が可能性がある。でも、Builderはたくさん改善の余地がある。Builderはundoがないなど、ユーザビリティに問題がある。

Q10:日本語を入力し、キーボードをタップするまでやるのが大変。キーボードを使わずに入力する方法はある?
A10:あるよ。デモの見栄えがいいからキーボードをタップさせてるだけ。直接テキストを入れられます。

Q11:Seleniumの正確な発音は?
A11:WikipediaでSelenのページに「ソフトウェアの話はこっち」ってリンクがある。eの発音が正しい。でも、イギリス英語みたいになっちゃう(^^) Alminiumをアメリカで違う発音するのと同じ。

Q12:テストは分析、設計、実行がある。Seleniumは実行?分析、設計までやって自動化では?
A12:Seleniumは実行。ロボットだ。実行だけでも要望がたくさんあるので、対象範囲を絞っている。実行の外は対象外。例えば、レポーティングとか。レポーティング機能のある製品もあるけどね。

Q13:WebDriverでテストしている。Jenkinsと連携するときに気を付けることは?
A13:JenkinsなどのCIサーバーとの連携が課題になる。JUnit、TestNGからXMLでテスト結果をXMLで取得できる。ブラウザのテストをするときに気を付けてほしいのは、エラー時にスクリーンショットをとること。スクリーンショットをgifアニメーションでとれる。Jenkinsを使うときもスクリーンショットなどを意識するとよい。

Q14:mobileのネイティブアプリのテストをしている。簡単にできる方法は?
A14:Appium InspectorはIDEやBuilderに似ている。まだiOSにしか対応していない。


ノンプログラマのためのSelenium DDTはじめの一歩【浦山 さつきさん】

Selenium IDEを使ったテストのデモ。
Excelからテストスクリプトをはきだし、Selenium IDEで読み込んでテストするツールをつくった。
簡単でしょ。
データ駆動テストにしてます。



Enterprise開発でのSelenium活用事例【大田尾 一作さん】

画面項目を自動で取得-->Excel-->データ駆動テスト。
ScreenShotを1行でとれるようにUtilを作成。
などなど
-->社内ライブラリ化
  • name属性がない、id属性が動的に変動・・・こんなのは、見送り。
  • 1回の実施では30%~2倍のコスト。継続的な使用で効果が得られる。
  • エンプラでも使い始めている
  • いきなり全部だと非効率。一部からはじめるとよい。


Jenkins×Selenium 最初の一歩【玉川 紘子さん】

Seleniumのテストは1回では元がとれない。
-->チームの意識が高くないと、すぐにテストが陳腐化してしまう。
-->Jenkinsで自動化。
JenkinsのSeleniumプラグインがたくさんある。
簡単で便利なものをご紹介。


Seleniumhq plugin

browser, startURLなどを設定すると、Jenkinsが実行してくれる。
結果も画面でみれる。


seleniumhtmlreport plugin

TestSuiteが多い場合は、これでレポートがみれる。
mavenなどでxUnit形式で出力すれば、Jenkinsでレポートがみれる。


Selenium plugin

Selenium Gridで並列実行するときにSelenium Hubを簡単に設定できる。


JenkinsでSeleniumのテストをするときに気を付けること

  • テスト環境は専用に
  • データの初期化の仕組みをつくる
  • ジョブは機能のカテゴリごとに小分けにするとよい(失敗したときに修正のモチベーションのため)
  • スクリーンショットをとる(Selenium Advent Calendar 2014でブログ書いたよ)


Selenese Runnerができるまで(仮)【岩室 元典さん】(@vmi_jp)

SeleniumでCIするときに困ったことありませんか?
  • Selenium RCが動かない
  • テストがこけたときに何がおきたかわからない
  • WebDriverはメンテコストが高い
こんな人にSelenese Runner。
  • WebDriverベースなので、クロスブラウザ対応
  • ログとの突合せに必要な情報の出力
  • コマンド毎、失敗時のスクリーンショット
  • JUnit形式で結果出力
などなど

ここでデモ(クロスブラウザ、実行中にハイライト・充実したログ・スクリーンショットなどなど


Seleniumと相性がいいテンプレートエンジンMixer@nabedge

Seleniumあるある
idかclassをつけておいてくれればややこしいxpathをつかわなくていいのに。。。

Mixer2はHTML, CSSでテンプレートを書いて、可変部分はJavaで書く。
なので、id, class属性が自然につけられるのでSeleniumでやりやすくなる。

ここでデモ(Mixer2の開発の書き方でテストもできる)

Mixer2はXHTMLパーサー、ジェネレーター、Object/XHTMLマッパー。


懇親会

普段は、こうゆうことしないんだけど、隣にいた女子が「写真とってもらいましょーよー」といったので、その流れで。
ナイスだ、後藤さん!



2014年01月18日
第1回 日本Seleniumユーザーコミュニティ勉強会
東京都渋谷区道玄坂1-12-1
http://kokucheese.com/event/index/117476/

2013年10月14日月曜日

REVIEWS

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

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

レビュー(REVIEWS)

レビューには、準備、実施、反映の3つのフェーズがある。
適切なときに、適切なことをレビューすることが重要だ。
レビューでは、次の2つを達成しなくてはならない。

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

組織のプロセスとして、マイルストーンとレビューポイントを定義しよう
ここの図は重要!なので、テキストみてね。

キャプチャーフェーズ

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

提案計画フェーズ

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

提案準備

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

提出後

ふりかえり


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

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

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

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


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

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

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

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

赤チームのレビューは提案書作成の2/3時点に実施するのがよい
赤チームのコメント反映は、誰か1人がした方がよい。
この段階で、各担当は疲れていて、冷静に書き直すのは難しい上に、高い技術も必要だからだ。

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

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

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

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

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

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

どのレビューも準備、実施、反映のプロセスに従う。
ポジティブで生産的なトーンを維持するようにする。
よりよくするのであって、悪い点を指摘するのではない。
コアグループが責任をもって、改善案を反映するかどうかを決定する。
そして、レビューの反映結果はドキュメントに残す。

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

効率的なレビューのためには、1人のレビュアーが1日に40ページが目安となる
官公庁の提案は大体90%が新規作成だから、これくらいが理想だ。
再利用ができるものであれば、80ページくらいできるだろう。
必須事項とオプションに分け、各章に2人のレビュアーをつけよう。
そして、重要なところからレビューしよう。

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

コストとスケジュールの一貫性や、スケジュールの一貫性をレビューしよう。
???いまいちよくわからない・・・

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

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

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



赤チームのレビューは提案書作成の2/3時点に実施するのがよい
赤チームのコメント反映は、誰か1人がした方がよい。

この2つは重要だなあ。


ネタ: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

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

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

日次ミーティング(Daily Team Management)

日次のチームマネジメントは、間違った方向に進むことを最小限にする。
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/

GRAPHICS

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

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

グラフィクス(GRAPHICS)

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

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

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


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

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

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

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


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

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

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

キーポイントは1つ。
複数ある場合は、図を分ける。
10秒ルールを忘れずに。
10秒でポイント伝わらなければ、アウト。
図は、前面、中面、背面の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.セットアップは短くしなさい

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


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

2013年9月6日金曜日

ACTION CAPTIONS


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

訴える表題(ACTION CAPTIONS)

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

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

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

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

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

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

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


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

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

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


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

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

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

多くの人は上から下、左から右に読む。
評価者はまず図に目がいくので、訴える表題はその下にするとよい。
より精錬されたデザインではその限りではないが、提案書はシンプルに図の下で統一するとよい。

本文では番号で参照する

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


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

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



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




ネタ:APMP Proposal Guide: the Foundation Accreditation Study Guide
https://apmp.site-ym.com/store/view_product.asp?id=1018152


参考:kumi shiki blog

2013年8月13日火曜日

STRATEGY


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

戦略(STRATEGY)

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

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

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

ホットボタンを探す

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

  • 課題:お客様の心配事のこと。
  • 動機:利益を増やす、売上を増やす、コストを削減する、安全性を高める、リスクを減らす、品質を高める などのお客様が達成したいこと。
  • ホットボタン:課題と動機のセットで、お客様の言葉で表現し、2から5つくらいにしぼる。


セールス目標を立てる 

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

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


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

経営層は費用対効果に注目する。そして、経営層が最終的な決断をする。
ユーザーは自分たちの仕事の効率化に注目する。
システム担当は、製品やサービスの機能に注目する。


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


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


競合比較表をつくる

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

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

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

各お客様に、ベストソリューション、アプローチ、価値提案をする。
価値提案とはソリューションの価値のことだ。
価値提案は、次の要素を含む。
  • 定量的ビジネス改善
  • タイミング
  • ソリューション
  • 投資額
  • ペイバック
  • 結果測定と証跡


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

何をどのように実現するかを定義する。
戦略は次の4つの方法で実現される。
  • 強みを強調する
  • 弱みを緩和する
  • 競合の弱みを強調する
  • 競合の強みの重要度を下げる

戦略記述ワークシート

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

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

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

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

戦略を発展させることと実行のバランスをとる。
アクションはお客様が自社のソリューションを選択するために行う。




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

ネタ:APMP Proposal Guide: the Foundation Accreditation Study Guide
https://apmp.site-ym.com/store/view_product.asp?id=1018152


参考:kumi shiki blog