2014年1月26日日曜日

「LEAN UX」を読みました。


「デザイナーの仕事は仕様を書くことではなく、価値ある製品とサービスをつくることなのです。」

本の中のこの言葉。
当たり前なんですが、本質に立ち戻り、今までのやり方見直すことが重要なんですね。


LEAN UXの3つの基盤

「Lean UXには、基盤となる3つの概念があります。」
  • デザイン思考
  • アジャイルソフトウェア開発
  • リーン・スタートアップ


原則

「Lean UXの体験を、学びの旅のようなものととらえましょう。あなたとチームを正しい方向に導くために、これらの原則を活用してください。」

価値、原則とくるところは、完全にアジャイルにインスパイアされてますね。
  1. 部門/領域横断的なチーム
  2. 小規模、専任、同一場所
  3. 進捗=結果(アウトプット)ではなく、成果(アウトカム)
  4. 課題焦点型のチーム
  5. 無駄を取り除く
  6. バッチサイズは小さく
  7. 継続的な発見
  8. GOOB-新たなユーザ中心思考
  9. 共通理解
  10. アンチパターン-ロックスター、エバンジェリスト、忍者
  11. 仕事の外面化
  12. 分析よりも形にする
  13. 成長よりも学習
  14. 失敗を許容する
  15. 中間成果物中心の仕事の進め方からの脱却

テンプレート

「開始点は、要件ではなく、前提になります。次に仮説をつくり、それを評価します。そして、望ましい成果が実現できているかどうかを、実験を通じて評価します。」

以下のテンプレートが紹介されています。
新しい独自のものというより、3つの基盤で使われているものを整理した感じです。
特にリーン・スタートアップの影響が強いようです。
  • 課題ステートメント・テンプレート
  • ビジネス前提ワークシート
  • 仮説ステートメント
  • ペルソナのフォーマット


コラボレーティブ・デザイン

「長い目で見れば、コラボレーションはヒーローズベースのデザインよりも、良い結果をもたらします。」

プロセスの部分は、デザインに限らず使えそうなので、様々なところで応用できそうです。
勉強会で素振りするといいかもしれないなぁ。


プロセス

  1. 課題の定義と制約の明確化
  2. 個別のアイディアの創出(多様性)
  3. プレゼンテーションと批評
  4. イテレーションと洗練(形成)
  5. チーム全体でのアイディアの創出(集約)

スタイルガイド

良いスタイルガイドの特徴
  1. アクセスしやすい
  2. 継続的に改善されている
  3. 実用的である

MVPと実験


「MVPをつくる最も効果的な方法の1つは、体験のプロトタイプをつくることです。」

MVPとは、Minimum Viable Productの略で、実用最小限の製品のことです。
プロトタイプは以下の基準で、どのレベルの忠実度にするのかを決めます。


プロトタイプ作成の基準


  • プロトタイプとインタラクションをするのは誰か。
  • 何を学習したいか。
  • 作成の期間はどれくらいあるか。

プロトタイプ作成のツールも紹介されています。
その中では、Balsamiqというのは、よさそうだと思いました。
あと、本には紹介されていませんが、個人的にはCacooがおすすめです。


フィードバックとリサーチ


「このプロセスでは、「軽量」「継続的」「コラボレーティブ」などのリサーチ技術を使います。」

実は、ここが一番難しいと思います。
コラボレーティブかつ継続的なリサーチは結構大変そうです。


コラボレーティブ・ディスカバリ

「コラボレーティブ・ディスカバリは、チーム全体がオフィスの外に出て(文字通り、あるいは比喩的に)、顧客に直接会い、そこから学習するというリサーチ手法です。」


継続的ディスカバリ

「定期的なペースで顧客を関与させることは、Lean UXにおける重要なベストプラクティスの1つです。」


Lean UXとアジャイルの統合

「Lean UXをアジャイルで機能させるためには、チーム全体がすべての活動(スタンドアップ、レトロスペクティブ、IPM、ブレインストーミング)に参加しなければなりません。」

Lean UXでは、対面コミュニケーションの重要性を非常に強調しているように思います。
私は、対面コミュニケーションの不足よりも、対面コミュニケーションの質に課題があるように感じています。


組織的な移行

「これらの手法をここで実践するにはどうすれば良いですか?」

はい。アジャイル開発でもよくだされるQAですね。
答えは、「あなたが考えなさい。」ってやつです。
わかってますよー。

2014年1月23日木曜日

teian-labで発表しました

徹夜で作った提案書では負け。 RFP受領前に勝敗決まる。 



日経システムズのこの記事がはじまりでした。
徹夜続きでようやく提案書を書き上げた後にこのタイトルは私にとって衝撃的でした。
そこから、teian-labやAPMP Proposal Guideで勉強をし、実際の提案活動に活かしてみた経験をお話しました。

Executive Summary


提案概要は、普通につくっていると思いますが、RFP前にドラフトをつくってしまう!
私にとってはかなり驚きでした。
でも、実際にやってみると、本当に役に立ちます。
Executive Summaryをつくるためには、お客様と色々話をしなければなりません。
このプロセスが提案書作成の鍵をにぎると言っても過言ではないと思います。

参考
exective-summary

Schedule


計画を練るのは重要です。
私はAgile開発が好きなので、Agile開発のプラクティスを活用しました。
この部分はきっとプロジェクトごとにいろいろな工夫の仕方があると思います。

参考
daily-team-management
proposal-management-plan

Kickoff Meeting


キックオフミーティングは儀式ではありません。
提案には、知識体系があり、スキルがあり、正しくマネジメントすれば、徹夜なんてしなくても、いい提案書が書けるということを、根拠を持って伝えることが重要です。

参考
kickoff-meetings

Storyboad & Mockup


ストーリーボードは映画の絵コンテのようなもので、モックアップは骨子みたいなものです。
この2つは、提案書作成のキモです。
でも、うまくやるのはなかなか大変です。

参考
storyboad

FAB


Featureは機能や特徴で、要は、提案するソリューションです。
Advantageは自社のソリューションの強み、利点です。
Benefitはお客様にとっての価値、利益です。
Benefitをはじめに書き、その後に、AdvantageとFeatureを書くようにします。
これを口酸っぱく言い続けると、自然と顧客起点の提案書になってきます。

提案で勝つために


結局これが一番重要です。
RFPが出た時点で動き出したら、もう負けてるかもしれませんよ。

参考

資料

プレゼン資料のフォントについてご質問を受けましたが、あんずもじというフリーのフォントです。


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