投稿者: 水簾洞

7日間完成英検®2級 予想問題ドリル	Day 1 リスニング
	Day 3 リスニング
	Day 5 リスニング
	Day 6 リスニング
	Day 7 面接（スピーキング）
7日間完成英検®準2級 予想問題ドリル	Day 1 リスニング
	Day 3 リスニング
	Day 5 リスニング
	Day 6 リスニング

中百舌鳥　駐車場地図

第三駐車場への行程

英語検定　2024年度	英検4級	第二回	全部
	英検２級	第一回	全部
	英検２級	第二回	第一部
			第二部
英語検定　2022年度	英検２級	第一回	リスニング
		第二回	リスニング
		第三回	リスニング

英語検定　2022年度	英検３級	第1回.mp3
		第2回.mp3
		第3回.mp3
	英検４級	第一回
		第二回
		第三回
	英検５級	第1回.mp3
		第2回.mp3
		第3回.mp3

	キンメづくし丼	ホテル あけのほし
	しらす丼	安芸しらす食堂
	鰹たたき	田中鮮魚店
	清水さばぶっかけ丼	足摺黒潮市場

　

２０１９年７月に確認
　　河内長野市教育メディアセンターＨＰ　⇒　新着情報　⇒　新年度のプログラム紹介　より

　　下記の教材を取捨選択しながら教育現場で使用する（掲載順は無関係）

	スクラッチ		ゲーム作成 製品紹介	ビジュアルプログラミング 　　※論理構造を組み立てる
	ビスケット		ゲーム作成 製品紹介	ビジュアルプログラミング 　　※直観的に絵を動かす
	アウア オブ コード		紹介ＨＰ	プログラミングをゲーム感覚で学べるサイトです 下記の様なゲームが数種類用意されています
		コードモンキー	ゲーム例 製品紹介	小学6年～ CoffeeScriptプログラミング言語
		マインクラフト	ゲーム例 製品紹介	小学2年生～ コードブロック方式
		アングリー バード	ゲーム例	初心者向け ドラッグ＆ドロップ式

　　（１）パッケージ導入に現場部門が反発または現場の追加開発の要望を抑え切れなくなる
　　　　特定のパッケージソフトをユーザーに推薦したＩＴベンダー側の責任を問われるケースが多い
　　　　　　プロジェクトマネジメント義務違反と認定されるケース
　　　　　　　　ベンダーの技術者にパッケージの機能や業務の知識が不足していた
　　　　　　　　適切な要件定義の支援や情報提供ができなかった

　　　　ユーザー企業が協力義務違反を問われるけーす
　　　　　　「パッケージに合わせて業務を変える」ことを前提にパッケージ導入を決定したのに、
　　　　　　　　業務を変えることへの現場の反発を抑えられなかったケース

　　　　失敗の原因
　　　　　　旭川医大・ＮＴＴ東裁判　開発失敗（ユーザー企業側の「協力義務」に違反）
　　　　　　　　現場部門の要望を過剰に聞き入れての仕様が膨らみ過ぎ
　　　　　　トクヤマ・ＴＩＳ裁判　ＥＲＰ導入失敗（現場部門が新システム導入への協力を拒否）
　　　　　　　　原場部門の要望を聞かなければ導入直前に不満が爆発する

　　　　原因と対策
　　　　　　パッケージの選定や要件定義の際に現場部門のキーパーソンがほとんど関与していなかった
　　　　　　　　パッケージを選定した後に現場部門の要望を聞くという順序で進めると
　　　　　　　　　　後々のトラブルにつながりやすい
　　　　　　現場部門を交え、１～２年をかけて個々のパッケージソフトの特性を理解したうえでの選定が
　　　　　　　　コストや時間はかかるものの、後々のトラブルを未然に防ぎやすくなる

　　（２）理由のない検収の拒否
　　　　ＩＴベンダーがシステムを納品しようとした際、
　　　　　　ユーザー企業側が検収や受領、受け入れテストへの協力を拒否するケース

　　　　実際にプログラム品質が劣悪だったとしても、
　　　　　　それをユーザー企業が定量的・客観的に実証しない限り、
　　　　　　ユーザー側は裁判の場では正当性を主張できない

　　　　失敗の原因
　　　　　　旭川医大・ＮＴＴ東裁判
　　　　　　　　契約解除までに「システムはほぼ完成していた」と判断し、
　　　　　　　　「システムは未完成」と主張して受領を拒否した旭川医大に賠償を命じている
　　　　　　読売新聞・アクセンチュア裁判
　　　　　　　　読売新聞はバグが収束せず、システムの半分を廃棄すると決定
　　　　　　　　アクセンチュアはパッケージにはバグはなく、手計算にバグがある

　　　　原因と対策
　　　　　　バグの数、重要度、バグの収束度合いがどの程度なら
　　　　　　　　プロジェクトの中止もやむなしとみなせるか、
　　　　　　　　契約書に検収の条件となる基準の記載を求める

　　（３）データ移行やマスタデータ作成
　　　　データ移行についての検討は後回しにされがち
　　　　　　データの抽出からクレンジングまで想定外の工数が発生しやすい

　　　　データの移行について「ＩＴベンダーが全部やってくれる」と思いがち
　　　　　　ベンダーの交代を伴うプロジェクトでは、
　　　　　　　　旧ベンダーに作業を依頼せざるを得ない場合があり
　　　　　　　　旧ベンダーと契約関係にあったユーザー企業の責任はより重くなる
　　　　　　マスターデータを移行・整備する場合には、
　　　　　　　　業務をよく知る現場部門の協力が不可欠であり、これを怠れば協力義務違反となる

　　　　失敗の原因
　　　　　　旭川医大・ＮＴＴ東裁判
　　　　　　　　旭川医大の現場部門がマスタデータの作成に協力的でなかった点について
　　　　　　　　　　協力義務違反を認定している

　　　　過去に作成したサイトです、更新作業はｓｔｏｐしています
　　　　　　古い内容ですが記念に保管しています
　　　　　　時期（時間に余裕ができたら）をみて、削除していきます

	オープン（ソース・データ）活用		公共データのオープン化に伴い有効活用を図りました 市民が関心のある市民税の使い道を視覚化しました
	ＰＣクラブ「千代田」 活動報告		パソコンクラブ「千代田」の活動報告です 短い１０ヶ月余りの報告です
	ＰＣクラブ「千代田」 学習記録		パソコンクラブ「千代田」の学習記録です 短い４ヶ月余りの記録です
	「あかしあ台」自治会		自治会活動を支援するコミュニケーションサイトを目指しています ＳＮＳとWordPressを使っています
	「まちづくり」協議会		楠小学校区つながろ会のホームページを作成しました 地域コミュニケーションのベースになればと思っています
	いきいき情報誌		いきいきと活躍する高齢者を紹介します 高齢者を取り巻く状況を整理します
	防災ポータル		防災のためのサイトを立ち上げます 公開されている情報を元に構築します
	時の証人		ビッグバンから１３８億年、時が刻まれてきました 数々の出来事に関するよもやま話です
	デジタル技術		デジタル技術の発祥から現在までの栄枯盛衰 数々の出来事に関するよもやま話です

１０年前に考えていたことは現在どうなっているのか？
　　（１）キャリアパス
　　　　年功序列・終身雇用の衰退
　　　　　　所属する企業の価値なのか個人の価値なのかが問われる時代になる
　　　　独立した際の不安材料
　　　　　　・安定して継続的な受注
　　　　　　・確定申告、請求書発行等の作業
　　　　　　・病気やケガが心配
　　　　　　・クレジットカード、ローンの審査
　　　　　　・研修や自己啓発に時間と自己資金が必要

　　　　独立した際の不安解消
　　　　　　契約金額が収入になる喜びを実感する
　　　　　　支援組織（技術者協同組合）に入る
　　　　　　　　上記の不安は全て解消される

　　（２）Ｊａｖａ技術
　　　　Ｃｏｂｏｌ技術者は不要でＪａｖａ技術者が重宝されている
　　　　　　実際、契約単価では殆ど差が無いくらいになってきた
　　　　　　使える言語の種類ではなく、担う工程が上流か下流かに依って契約単価が決まっている

　　　　下流工程の需要はオフショアに流れて、益々下落するであろう
　　　　　　上流工程を狙って自己啓発に努める

　　（３）コンサルテーション、プロジェクトマネージャー
　　　　人気はコンサルタントやプロジェクトマネージャーに限られている
　　　　　　上流工程を狙うのは分かるが、徐々に職種の幅が広がってきている

　　　　新たなキャリアパスの広がり（上記以外）
　　　　　　・アーキテクト
　　　　　　・組み込みエンジニア
　　　　　　・エヂュケーション（人材教育、トレーニング）

　　（４）開発プロセス
　　　　脚光を浴びているのは、反復型開発やアジャイル型開発である
　　　　　　メインフレ－ム系のウィーターフォール型開発は衰退した
　　　　開発知識も同じく衰退している
　　　　　　・要件を慎重に詰める（機能要件、性能要件、運用要件）
　　　　　　・プロセス構築、仕様書作成
　　　　　　・中間成果物作成
　　　　　　・改造、移行
　　　　　　・マルチベンダー

　　　　技術を引き継ぐ
　　　　　　業務の目的を理路整然と理解して、システムを設計する技術
　　　　　　２００７年以降の大きな課題である

１０年前に考えていたことは現在どうなっているのか？
　　（１）業務要件とシステム要件
　　　　業務要件さへ明確に決まればシステム開発は上手くいくか
　　　　　　機能とプログラムが明瞭に結びついていることは少ない
　　　　　　機能だけでなく、セキュリティー、ＤＢ等への理解

　　　　業務要件をヒアリグしながら、
　　　　　　システム要件と機能要件も同時に検討する
　　　　　　　　・業務要件を聞きながらシステムアーキテクチャーをイメージする
　　　　　　　　・システム要件を逆提案する
　　　　　　　　・上記を繰り返すことでシステム要件と機能要件を固めていく

　　（２）大型サーバー
　　　　大型（タワー型）サーバーからブレードサーバーへ変化してきた
　　　　　　・コストパフォーマンスが高い
　　　　　　・処理性能が高い
　　　　　　・要素技術の開発が進み可用性や運用性が高くなった

　　　　Ｗｅｂサーバーだけでなく
　　　　　　アプリケーションサーバーやデータベースサーバーに使用される

　　（３）オブジェクト指向
　　　　広く普及してきた、が分散オブジェクト技術に限界が出始めた
　　　　　　細かい処理を何度も実行しメッセージを何度も交換する
　　　　　　多数のオブジェクト間での整合性を確認するのに手間が掛かる

　　　　ＳＯＡ（Service Oriented Architectur）の登場
　　　　　　オブジェクト単位ではなくサービス単位のソフトを非同期に連携させる
　　　　　　　　連携するサービスの開発手法はオブジェクト指向でも手続き指向でも構わない
　　　　　　アーキテクチャーとしてＳＯＡが主流となる

　　（４）キャパシティー計画
　　　　オープン時代になり、機器装置の価格の値下がりに合わせて
　　　　　　ソフト構成やハード構成を検証・計画することに無頓着になってきた

　　　　単純に設備の増強を図るのではなく
　　　　　　要件定義の段階から処理性能を作りこんでいく
　　　　　　あらかじめボトルネックを調査・把握し、適宜手を打っていく

　　（５）テスト、納期、品質
　　　　短納期の案件を沢山抱えていると、品質より納期を優先する
　　　　　　時間とコストの掛かるテストを省く傾向にある

　　　　テストの効率化を図る
　　　　　　開発プロセスから独立させ、各々の開発局面と並行させてテスト計画を作成する
　　　　　　テスト自体の品質を安定させるために、ケース作成やテスト項目抽出の教育訓練を行う

　　（６）プロジェクトマネージメント
　　　　小規模・短納期プロジェクトが多くなると
　　　　　　一気呵成にプロジェクトの回復・修復を行う

　　　　小規模だからこそプロジェクト管理をしっかり行う
　　　　　　採取的にユーザの信頼を得るにはこれが一番肝心

　　（７）プロジェクトマネージャー
　　　　メンバーの進捗やモチベーションを管理することが多い
　　　　　　人の管理が主体になっている

　　　　成果物をマネージメントする
　　　　　　成果物を中心にして、問題点や進捗を管理する
　　　　　　ＷＢＳの作成も成果物を定義することから始める
　　　　　　　　成果物を定義してこそ、後工程の作業計画が考えられる

１０年前に考えていたことは現在どうなっているのか？
　　（１）国際競争力
　　　　パッケージソフトの大部分は欧米製
　　　　　　・９０年代のオープン化時代に自前の開発を怠った
　　　　工学的アプローチの遅れ
　　　　　　・国内だけでの開発競争
　　　　　　・バブル崩壊と同時にベテランが居なくなる
　　　　　　・ユーザ企業のコスト削減で技術者不足に陥る
　　　　競争力が強いと思われる要素
　　　　　　・品質や機能が優れた情報システムが構築できる
　　　　　　・組み込み技術

　　（２）下請け構造
　　　　６０年代・・・メーカー主体で一貫して開発～保守を行う
　　　　７０年代・・・独立系ソフト会社の登場、メーカーからの開発を受注するのがメイン
　　　　８０年代・・・金融系、官公庁を中心にした大型開発が主体となる
　　　　９０年代・・・開発規模の縮小、オープン化、パッケージ化が押し寄せる

　　　　多階層下請け構造は小さくなり、専門特化したベンダーが相互に連携する様になる

　　（３）顧客志向
　　　　顧客の要求を全て聞く「セネラリスト型」は行き詰る
　　　　　　求められる技術やビジネスが複雑化している

　　　　少数の「コディネート型、と「付加価値と営業力重視型」とになる
　　　　　　高度なプロジェクトマネージメントを行うコーディネート型
　　　　　　専門的な領域で付加価値を提供し、直接受注できる営業力重視の型

　　（４）人月見積もり
　　　　８０年代までは開発コード行数での金額換算であったが
　　　　　　作業の多様化や開発言語の特性により人月での金額換算になって行った
　　　　人月では、システムの規模と価値が見えない、生産性向上が図られない等々

　　　　成果物を作成するための技術要素を細分化する
　　　　　　技術要素ごとに単価設定し、これを人月で積み上げて成果物作成費用とする
　　　　　　システム開発金額はこれら成果物の集合体として金額合算する

　　（５）最適商品
　　　　８０年代まではメーカー主体の「垂直統合型」であった
　　　　　　プロセッサー、ＯＳ、ミドルウェア、ネットワークと全てメーカーが担う
　　　　９０年代になると新しいベンダー製品を組み合わせる「水平分業型」に移る
　　　　　　高集積回路、パソコン、ＤＢの領域に新しいベンダーが登場した
　　　　２１世紀になると複雑化した分業体制に無理が出始めた
　　　　　　広範囲な領域を担当する人材の確保が追いつかない
　　　　　　トラブル修復に手間が掛かり過ぎる
　　　　　　ＡＰＬ連携が複雑になり過ぎる

　　　　再度「垂直統合型」を志向する
　　　　　　各ベンダー製品を自社の統合モデルに組み込んでいく
　　　　　　　　組み合わせを絞り込み、過度な複雑さを解消する
　　　　　　　　技術的な絞込みも行い、機能面や可用性を向上させる
　　　　　　　　自社技術で開発するモノと技術提携を受け製品開発するモノとになる

　　（６）ソフトウェアの価格
　　　　ソフトの価格が同じなら、シェアが高い方を選ぶ、ことが多かった
　　　　　　個別に構築してきた情報システムを全体で統合する動きが出てき始めた

　　　　統合基盤プラットホームの上にシステムは構築される
　　　　　　・人へのサービスの統合機能・・・ビジネスワークフローの定義等
　　　　　　・プロセスの統合機能・・・・・・EnterpriseApplicationIntegration等
　　　　　　・アプリケーションの統合機能・・Webアプリとサーバーの連携等
　　　　　　・情報の統合機能・・・・・・・・データウェアハウスやＢＩ等
　　　　価格やシェアに寄って左右されるのではなく
　　　　　　ベンダー提供のビジョンやアーキテクチャーを評価しなければならなくなる

　　（７）コンサルテーション
　　　　コンサルタント批判が出始めた
　　　　　　・契約料金が膨大な額になる
　　　　　　・成果物がプレゼン資料的であり、開発の役に立たない

　　　　多様化、高度化したＩＴを駆使し経営課題を解決するには
　　　　　　明確な方向性を指し示すことの出来るコンサルタントの存在が必要

　　（８）システム部門のスリム化
　　　　システム部門の子会社化が盛んになりつつある
　　　　　　組織内での人材育成が出来なくなり、システムの空洞化が始まる
　　　　　　経営戦略と結びついたシステムの企画立案が出来なくなる
　　　　　　ベンダー提案の是非を評価できなくなる

　　　　スリム化は是だとしても、過度なスリム化はすべきではない

　　（９）オフショア
　　　　コストの安い中国へのオフショア開発は盛んになりつつある
　　　　　　中国ではＩＴ教育の質も高い人材が確保できる
　　　　　　逆に日本での技術者の教育が疎かになり十分な成果に結びつかない

　　　　質の高いオフショアを求めるなら、日本の技術者にも教育をしっかり施す
　　　　　　オフショアビジネスとして成り立つ様に努力する

１０年前に考えていたことは現在どうなっているのか？
　　（１）ＩＴベンダーの問題
　　　　・工学的アプローチなしでもやってこれた
　　　　・技術進歩が激しく教育が追いつかない

　　　　ＳＷエンジニアリングやPjtマネージメント等の競争力強化を怠る
　　　　優秀な人材育成を怠り、キャリアパスの整備を疎かにする
　　　　基礎技術の開発や研究を疎かにする

　　（２）ユーザー側の問題
　　　　・情報シスウテム部門が弱体化する
　　　　・開発や運用をＩＴベンダーに丸投げする
　　　　・不透明な政府調達

　　　　ＩＴベンダーの善し悪しの判断力が低下する
　　　　ＩＴベンダーの甘えを誘い込む

　　（３）大学等の教育機関の問題
　　　　・サイエンスに片寄り、実践的な教育が少ない
　　　　・産学の交流が乏しく、実践的な教育ができる教育者が少ない
　　　　・革新的・実践的な研究が少ない

　　　　ＩＴエンジニア全体の質が低下する
　　　　大学発で世界に通用する製品が少ない

　　（４）政府の問題
　　　　・政策が省庁によってバラバラ

　　　　統一したＩＴ政策が出てこない

以下の項目について注意する
　　（１）分析の目的を決める
　　　　・データを並べて触っていれば何らかの意味合いが生まれてくる
　　　　・なんとなく思いついた型の分析を始めてみる
　　　　・目的がはっきりしないまま数字をこねくり回す
　　　　・言いたいこと、検証したい仮説がない

　　　　「何のために」がはっきりしないものは分析として意味を持たない
　　　　　　データを処理しているうちに何か生まれてくるかのような錯覚
　　　　　　　　何が目的関数なのか
　　　　　　　　何に決着をつけるために分析しているのか
　　　　　　　　何を言えばいいのか
　　　　　　闇雲に分析するのは無駄である

　　（２）分析の軸を適切に決める
　　　　・入手し易さや扱い慣れているという理由だけで分析軸を選ぶ
　　　　・判断に必要なコントロール（対照条件）が取られていない
　　　　・軸の取り方にダブリや漏れがある
　　　　・軸の中の刻みがおかしく、意味合いを正しく導き出せない

　　　　分析とは比べること
　　　　　　フェアに比較できるもの同士を比べ、違いや関係を見出す
　　　　　　言葉に信頼を与え、論理を成り立たせ、問いに答えを出す
　　　　比較のための条件側の軸、あるいは評価側の軸が「分析の軸」
　　　　　　ダブリや漏れがあったり、目的に沿ってなければ無駄になる

　　（３）データの検証を行う
　　　　・分析対象が決め打ちされている
　　　　　　母集団に抜けや漏れが生じている
　　　　・そもそもデータが汚れていたり、歪んでいたりする
　　　　　　サンプリングやデータ取得に由来する問題

　　　　取り扱うデータが汚ければ分析することが無駄になる

　　（４）異質なものを比較する
　　　　・本来比較できないものを比較している
　　　　・本来足し合わせることができない値を足している

　　　　定義の異なる数字を混同するために起こる
　　　　　　間違った比較が分析に混じると、全ての結果が無駄になる

　　　　・導き出された数字からは言えないことを言っている
　　　　・素直にデータを解釈していない
　　　　・異常値を拡大解釈している
　　　　・決着がついていないのに決着がついたと勘違いする

　　　　気持ち、思い込み、仮説等に引っ張られて
　　　　　　どちらにも解釈できると考え、自分の言いたいことを言う

以下のようなステップを踏んでカリキュラムを進める
　　（１）ビジネスプラン作成のポイント
　　　　売れる仕組みを創り出すためにアイデアを落とし込む
　　　　　　・コンセプト作成のポイント
　　　　　　・ターゲットを明確にイメージする
　　　　　　・商品、サービスの作り方
　　　　　　・売れるためのメッセージ作り
　　　　　　・自らのプランに落とし込む

　　（２）損益予測からプランを具体化する
　　　　続けて行くためのリアルな計画を作る
　　　　　　・損益計画を立てるための基礎
　　　　　　・必要な資金を洗い出そう
　　　　　　・資金繰りの基礎
　　　　　　・数字の見方を身に付ける

　　（３）ビジネスプランを見つめなおす
　　　　客観的な見方を入れて思い込みを解消する
　　　　　　・意見交換してプランをブラッシュアップ
　　　　　　・課題抽出

　　（４）事業のプレゼンテーション
　　　　ビジネスプランを伝える
　　　　　　・成果やプラスαについて発表する
　　　　　　・今後に向けた具体的なポイント説明

案件獲得計画（CApturePlan）のための行動計画
　　（１）外部分析
　　　　顧客の悩みを突き止め、競合の状況を掴む
　　　　　　事前に情報を可能な限り集めて分析する
　　　　　　仮説を立て、実際い顧客を訪問して仮説を検証する
　　　　　　
　　　　・案件の把握
　　　　　　プロジェクト名、目的、背景、ビジョン、ミッション、ゴール、ニーズ、スケジュ－ル、予算
　　　　・顧客の把握
　　　　　　組織図、最優先度、評価基準、購買プロセス、購買履歴や傾向、フィードバック
　　　　・競合の把握
　　　　　　ＳＷＡＴ分析、各アプローチ
　　　　　　ＫＳＦ（コスト、品質、実績、機能）を想定し、競合と比較し各要素を強化する

　　（２）内部設計
　　　　自社の強みを突き止める
　　　　　　下記の点を列挙し、優位性を導き出し、競合他社が提供できないモノを突き止める

　　　　・提供可能なソリューション
　　　　・コスト分析
　　　　・過去の事例
　　　　・リスク分析

　　（３）戦略策定と計画
　　　　導き出した優位性を顧客に理解してもらう様な活動計画を立案する
　　　　　　顧客の要求と自社の提供能力、競合他社の能力を洗い出して比較検討する

　　　　・戦略
　　　　・活動計画
　　　　・顧客の訪問
　　　　・ソリューション検討
　　　　・ミーティング
　　　　・提案書作成
　

以下の点について注意して対応する
　　（１）何の事を記述しているか分からない
　　　　文章に筋道を付けて分かり易くし、何のために記述しているかを理解してもらう

　　　　「問いかけ」を行う
　　　　　　どういった解を提示するか「問いかけ」で指し示す
　　　　　　「問いかける」ことで文章を読んでみようと思う動機付けになる
　　　　　　　　余り断定的にならずに、「問いかけ」程度が丁度良いと思われる

　　　　　　図解は視認性が高く情報量が多いので併用すると効果が高くなる

　　　　　　タイトルや見出しに使用する
　　　　　　　　文章の書き出し、メールの件名、サブタイトル、「はじめに」の位置に置く等々

　　　　記述の例
　　　　　　議事録・・・「何を決めるためか」、「何が決まったか」
　　　　　　告知文・・・「見る人への影響」
　　　　　　依頼文・・・「何故依頼するのか」
　　　　　　調査報告・・「何を検証しようとしたか」、「調査結果での示唆は」
　　　　　　活動報告・・「成果は何か」、「うまくいっている」、「問題はないのか」

　　（２）事柄の関係や関連が分からない
　　　　文章の構造を分かり易くし、何を記述しているかを理解し易くさせる

　　　　「目次」や「見出し」を作る
　　　　　　項目に分けて、「大項目」を用意する
　　　　　　項目が多ければ、階層構造にする
　　　　　　　　階層は３～５までとする
　　　　　　使用目的別や機能別とかで切り分ける
　　　　　　読み手のレベルによって切り分ける

　　　　　　図解は視認性が高く情報量が多いので併用すると効果が高くなる

　　　　　　見出しには伝えたい内容を的確に表現する
　　　　　　　　長すぎずに単語の重複は避ける
　　　　　　　　「問い」を繰り返し入れても良い
　　　　　　　　括弧や記号は余り入れない
　　　　　　　　カタカナより漢字を使う
　　　　　　　　　　無理に変換せず、同じ意味合いの漢字に変換する

以下の項目について注意する
　　（１）準備を丁寧に行う
　　　　・上手にやろうと意識しない
　　　　・資料の出来上がりを気にせず簡単に済ませるようにする
　　　　・装飾やアニメーションに拘らず標準テンプレートをそのまま使う
　　　　・箇条書きは１行で済ませる
　　　　・句読点は省略する
　　　　・体言止めにして完結にまとめる
　　　　・３色（黒、青、赤）ですませる
　　　　・スライド１枚当たりの文字数を少なくする
　　　　・少ない文字数のスライドをそのまま読むだけにする
　　　　・章ごとに全体での位置づけを分からせる
　　　　・目立つ場所に、メリットや効果を記述する（メッセージライン）

　　（２）自信を持って臨む
　　　　・語尾を意識したプレゼンを行う
　　　　　　質問に回答するパターンにする
　　　　　　一番伝えたい事項は最後に話す
　　　　・実数を使ったプレゼンを行う
　　　　　　具体的にイメージしてもらう
　　　　・繰り返しを使ったプレゼンを行う
　　　　　　強くイメージを残してもらう
　　　　・メッセージラインを必ず読み上げる
　　　　・指示棒を上手く使う

　　（３）納得させて終了する
　　　　・プレゼンの筋道を考える
　　　　　　全体を一度俯瞰し上で、筋道を練り直す
　　　　　　マトリックスで考える（縦がストーリー、横がプレゼン内容）
　　　　・必要ならデモを行う
　　　　　　相手に分かりやすくする（既作成のモノに頼らない）
　　　　・相手を想定して事前に練習しておく
　　　　　　想定問答等を練習しておく

　

ＫＳＲＤシステム全体を制御するためにｉｎｉファイルを用意する

カラム　０１　ウエルカムページ内でＷＰを使用する
　　　　　　　　　　”空白”・・・ＷＰを使用しない
　　　　　　　　　　”１”・・・・・・ＷＰを使用する

ポイントは
　　・相手側の立場や理解度に合わせた内容にする
　　　　専門用語や表現には注釈を入れておく
　　　　書面になって回覧されることも考慮に入れておく
　　・簡潔な短い文章で記述する

以下の手順で進める
　　（１）プロポーザル場面の設定
　　　　提案の対象者を選定し、日時と場所を決める
　　　　　　・提案範囲の決定
　　　　　　　　課題解決策の提案
　　　　　　　　　　受け入れにくい提案の場合にはこれだけに止める
　　　　　　　　実行計画の提案
　　　　　　　　　　比較的提案を受け入れ易い相手のの場合には同時に提案する
　　　　　　・提案対象者の設定
　　　　　　　　企画内容の実行を決済できる代表者を設定する
　　　　　　　　　　事前に決まっている場合にはよく確認する
　　　　　　　　　　段階に分かれて順々に提案する場合もある
　　　　　　・日時・場所の決定
　　　　　　　　互いに調整して決める

　　（２）プロポーザル資料の作成
　　　　企画した内容を提案書にまとめ、事例やデモツールを用意する
　　　　　　・提案骨子の作成
　　　　　　　　章立てと各章の要点を整理する
　　　　　　　　　　システム化の背景・目的
　　　　　　　　　　　　何のために何をシステム化するのかを整理する
　　　　　　　　　　　　材料は「ユーザーニーズ」、この把握が重要
　　　　　　　　　　解決すべき問題・課題
　　　　　　　　　　　　目的を実現するために解決すべき問題・課題をまとめる
　　　　　　　　　　　　材料は「原稿業務の問題点」、「洗い出された課題」
　　　　　　　　　　課題解決のポイント
　　　　　　　　　　　　問題解決のための業務やシステムの変更点や注意点を表す
　　　　　　　　　　　　材料は「改善ポイント」、「リスクと対策」
　　　　　　　　　　課題の解決策
　　　　　　　　　　　　解決策となる業務やシステムの内容と期待効果を表す
　　　　　　　　　　　　材料は「解決策」、「期待効果」、そのものを利用する
　　　　　　　　　　解決策の実行計画
　　　　　　　　　　　　解決策をどうやって実行に移していくかを表現する
　　　　　　　　　　　　材料は「作業項目、推進体制、スケジュール、コスト」

　　　　　　・提案書の作成
　　　　　　　　骨子を元に企画内容を提案書にマトメていく
　　　　　　　　　　システム化の背景・目的
　　　　　　　　　　　　図式化して表現する、数値項目も散りばめる
　　　　　　　　　　解決すべき問題・課題
　　　　　　　　　　　　図式化して表現する、数値項目も散りばめる
　　　　　　　　　　課題解決のポイント
　　　　　　　　　　　　影響を及ぼす業務やシステムへの注意点を簡潔に表現する
　　　　　　　　　　課題の解決策
　　　　　　　　　　　　現状の問題点と解決策とを対比させて表現する
　　　　　　・事例やツールの準備
　　　　　　　　必要に応じて準備する

　　（３）提案の実施
　　　　　　・提案の実施
　　　　　　　　特に理解を示して欲しい点を決めておく
　　　　　　　　　　事例や状況説明を組み込み、理解したことを確認していく
　　　　　　　　読み上げる内容と読み飛ばす内容を区別する
　　　　　　　　　　全て読み上げる必要は無い
　　　　　　　　個別に分割して質疑応答を行う
　　　　　　　　　　飽きさせない効果が有るが、間延びする可能性もある
　　　　　　　　相手の反応を確認する
　　　　　　　　　　どの点が合意されたか、合意されなかったかを確認する
　　　　　　・提案後のフォロー
　　　　　　　　合意されなかった点を確認・分析しフォローする
　　　　　　　　　　内容が駄目なのか、プレゼンの仕方が駄目なのかを切り分ける

業務フローが分かりにくい原因と対策

　　（１）人の作業なのかシステム処理なのか分かりにくい
　　　　担当者（組織やグループ等）と時間軸とのマトリックスで表す
　　　　　　どの担当者（組織やグループ等）がどのタイミングで業務を行うのかを表現する
　　　　　　業務の前後関係や必要な情報を整理して表現する

　　　　対策
　　　　　　・明確に線で区切って、レーンとする
　　　　　　　　人とシステム、自社と他社、部門と部門等々を区分けする
　　　　　　　　アイコン（人、ＰＣ機器、書類等）を用意して分かり易くする
　　　　　　・責任分担表を作成しレーンを整理する
　　　　　　　　業務プロセス単位に関係する組織や担当者を洗い出してマトリックス表にする
　　　　　　　　　　Ｒ（Responsibile：実務担当者）
　　　　　　　　　　Ａ（Accountable：責任者、管理者）
　　　　　　　　　　Ｃ（Consult：相談対応）
　　　　　　　　　　Ｉ（Inform：情報提供）
　　　　　　　　同じ役割や責任を持つ部分を一つにまとめていく

　　（２）プロセスの粒度がバラバラ
　　　　人とシステムとの関係を見直して粒度を揃える

　　　　対策
　　　　　　・具体的に細分化し過ぎないようにする
　　　　　　　　画面遷移を意識しない、意識すると細かくなり過ぎる
　　　　　　　　一箇所を細かくすると、引きずられて全体が細かくなってくる
　　　　　　・システム処理は簡単に記述する
　　　　　　　　他の業務との接点は主要な情報の入出力で表す
　　　　　　　　極力、細かなシステムの入出力に惑わされない様にする
　　　　　　・複雑な場合はＵＭＬを使用する
　　　　　　　　ユースケースシナリオとして別にまとめる
　　　　　　・粒度は無理に揃えない
　　　　　　　　細かすぎたら粗い方に修正する
　　　　　　　　粗すぎたら無理に細かくはせず、再調査するなりの時間を掛けて揃える
　　　　　　・サンプルを作成する
　　　　　　　　業務フローでの概要レベルと詳細レベルの記述見本を用意する
　　　　　　　　用意する際には概要と詳細の切り分け基準が分かる様にする
　　　　　　　　レビューを繰り返し、全体の粒度を揃える

　　（３）分岐するとフロー図が複雑になる
　　　　様々な条件に依って分岐が発生する
　　　　複雑になると各々でのレビューが自然と疎かになる

　　　　対策
　　　　　　・分岐する条件を調べ上げる
　　　　　　　　分岐条件と後続作業を全部調べ上げてパターン化する
　　　　　　　　業務フローを記述するより前にパターン化しておく
　　　　　　　　パターンを精査し漏れを無くし、重複を取り除く

　　（４）注釈を入れると余計に分かりにくい
　　　　補足説明や注意事項を業務フロー図の中に盛り込んでしまう
　　　　注釈等を書き込むと複雑すぎて見辛い

　　　　対策
　　　　　　・記号や番号でリンクを取り、別紙と紐付ける
　　　　　　　　記号や番号に絞っても、余り使いすぎて複雑にしない
　　　　　　　　噴出しを使って文言をフロー図から切り離す
　　　　　　・注釈を入れるレベルを決めておく
　　　　　　　　前提条件・・・他システムとの繋がり
　　　　　　　　運用ルール・・・業務遂行上の条件と対処方法
　　　　　　　　タイミングや例外処理・・・実施する条件や例外とする判断基準

マイナンバー制度について
　　（１）スケジュール
　　　　・２０１５年秋・・・・・・市町村が通知カードで番号を知らせる
　　　　・２０１６年１月・・・・・個人番号の運用開始
　　　　　　社会保障、納税、防災等から実施予定
　　　　・２０１７年１月・・・・・自治体での情報連携の開始
　　　　・２０１９年・・・・・・・官民連携・民間利用の可能性あり

　　（２）管理の主体
　　　　・所得・・・・・・国税庁、地方自治体
　　　　・年金・・・・・・日本年金機構

　　　　個人に関する情報を集中管理はしないが
　　　　　　行政機関は個人番号を相互に紹介できる
　　　　個人番号は国民が行政手続きに使用する
　　　　　　基礎年金番号、被保険者番号の代わりに使用する
　　　　政府が構築する情報連携システムで相互に照会する
　　　　　　税務署、年金事務所、市町村の３者かんで連携する

　　（３）期待効果
　　　　・社会保障の給付手続き簡略化
　　　　　　源泉徴収票、納税証明書の発行が不要になる
　　　　　　各行政機関の窓口に行かなくても、１箇所での手続きで済ませることができる
　　　　・行政機関の業務効率化
　　　　　　名寄せが確実に行われる
　　　　　　　　氏名、住所での名寄せは、外字の使用もあり非常に困難
　　　　　　　　税金逃れのための記述ミスの繰り返しを防止できる

　　　　システム開発費用が２７００億円、システム運用費用が３００億円/年
　　　　　　個人番号の適用範囲を拡大させなければ、費用対効果は期待できない
　　　　　　行政機関での情報連携による効果は３０００億円が見込まれている
　　　　　　　　年々、適用業務拡大を図らなければ効果は見込めない

　　　　マイナンバーを使わなくても業務効率をアップさせている例
　　　　　　・福岡県粕屋町
　　　　　　・福岡県北九州市

　　（４）関係するシステム
　　　　関係する諸システム
　　　　　　・内閣官房・総務省
　　　　　　　　情報提供ネットワークシステム、マイポータル、委員会用監査システム
　　　　　　・地方公共団体情報システム機構（総務省）
　　　　　　　　個人番号生成システム／公的認証サービス用システム
　　　　　　・国税庁
　　　　　　　　法人番号生成システム、国税システム（改修）
　　　　　　・日本年金機構（厚生労働省）
　　　　　　　　年金システム（改修）
　　　　　　・厚生労働省
　　　　　　　　雇用保険システム（改修）、労災保険システム（改修）
　　　　　　・地方自治体
　　　　　　　　社会保険システム（改修）、住基/地方税システム（改修）

　　　　処理の流れ
　　　　　　・地方公共団体情報システム機構
　　　　　　　　個人番号生成システムで採番し、住民基本台帳に個人番号を付与する
　　　　　　・地方公共団体
　　　　　　　　通知カードを送付する、個人番号カードを発行する

　　　　　　・日本年金機構、ハローワーク、市町村
　　　　　　　　情報提供ネットワークシステムを使って相互に情報連携を行う
　　　　　　　　直接個人番号は送信しない、「符号」を用意してこれを送受信する
　　　　　　・特定個人情報保護委員会
　　　　　　　　委員会用監査システムを使って情報連携や職員の違法行為を監視する
　　　　　　・住民
　　　　　　　　マイポータルを使って個人番号の提供元と提供先を確認する

　　（５）個人情報の漏洩対策
　　　　「符号」を用いた個人情報の保護
　　　　　　・地方公共団体情報システム機構が事前に
　　　　　　　　各行政機関と情報提供ネットワークに「符号」を提供する
　　　　　　　　同一人物に対して各行政機関用にバラバラの「符号」が提供される

　　　　　　・各行政機関は個人番号とヒモ付いた「符号」を
　　　　　　　　情報提供ネットワークシステムに送信する

　　　　　　・情報提供ネットワークシステムは元の「符号」を
　　　　　　　　相手先用の「符号」に変換し相手先に電文を送信する
　　　　　　　　各「符号」を相手先に合わせて都度変換する
　　　　　　　　　　※変換表にして保持している訳ではない

　　　　　　・相手先から情報が各行政機関に送信されてくる

　　　　　　この間のやり取りにおいて個人番号は一切使われない
　　　　　　　　個人番号と個人情報がセットになって送受信されることはない

　　（６）懸念事項
　　　　・串刺し検索ができない
　　　　　　必ず相手先を指定しての情報連連携のため
　　　　　　　　個人番号だけで情報照会（転居先不明者の検索）の様な使い方が出来ない
　　　　・市町村での対応費用が多額になる
　　　　　　新たな業務プロセスの構築
　　　　　　　　福祉システムは給付の種類が多く、プロセス変更が多岐にわたる
　　　　　　システムの改修
　　　　　　　　住基システムは個人番号対応の改修が多い
　　　　　　住民データの整理
　　　　　　　　地方税システムは宛名データの整備が大変
　　　　　　　　各担当課で整備している宛名データを１個に統合する必要がある
　　　　　　　　　　※主に住民課、国保年金課、税務課が保有している宛名データが対象
　

　　ネット通販でのポイント

　　　　（１）「儲かる仕組み」を作ってから広告を打つ
　　　　　　以下の様な仕組みを先に作り上げる
　　　　　　　　・レスポンス
　　　　　　　　　　広告で多くの”見込み客”を集める
　　　　　　　　・引き上げ
　　　　　　　　　　”見込み客”を”既存客”に引き上げる
　　　　　　　　・リピート
　　　　　　　　　　”既存客”を”固定客”にする

　　　　（２）”純広（特定の媒体に掲載する広告）”を活用する
　　　　　　極端に狭いところからのリーチ
　　　　　　　　アフリエイト・・・個人サイトや小さな会社からのリーチ
　　　　　　　　リスティング・・・特定のキーワードを検索したときに広告が出る
　　　　　　広告主が主体的に大規模な広告が打てる
　　　　　　　　バナー広告・テキスト広告・メール広告　等

　　　　（３）広告は無視されるものと割り切る
　　　　　　ネットユーザは何らかの情報を得るためにネットに繋げている
　　　　　　　　元々広告を見ようとは思っていないのである
　　　　　　無視されることを前提に、案を練って広告を打つ

　　　　（４）”情報”を盛り込んだ広告を打つ
　　　　　　視覚的に訴えるバナーではなく、情報を含むバナーにする
　　　　　　　　・動きのある広告より、落ち着いた広告を好む
　　　　　　　　・バナーは動きを無くし、キャッチコピーをメインにする
　　　　　　　　・無視される前に、内容が目の中に飛び込んでくるように仕向ける

　　　　（５）広告商品別にＬＰ（LandingPage）を必ず作成する
　　　　　　広告バナーから決して本サイトにＬｉｎｋさせてはいけない
　　　　　　　　広告を見ての跳び先が本サイト（ＨＰのトップページ）では興味が無くなる
　　　　　　　　ＬＰは訴求力のある商品情報と他のページに絶対Ｌｉｎｋさせない

　　　　（６）ＬＰからはショッピングカートには行かせない
　　　　　　ＬＰで商品個別のページにたどり着いたので
　　　　　　　　そのまま申し込みフォームを使って”商品購入”までリードする
　　　　　　　　選択された商品名を先ず表示し、１画面で全入力を完成させる

　　　　（７）アップセルは確認ページで行う
　　　　　　ＬＰの中で同時にアップセルの広告を出したくなる
　　　　　　　　アップセルの広告は、確認ページに出す
　　　　　　　　　　全ての購入手続きが終わって区切りの付いた時を狙う
　　　　　　　　確認画面上で”通常購入”ボタンと”アップセル”ボタンを並べておく
　　　　　　　　　　なるべく”アップセル”を押す様に仕向ける

　　　　（８）申し込み完了ページを用意する
　　　　　　全てが完了して終了（サイトから離れる）する際に
　　　　　　　　”申し込み完了”ページを用意しておいて、ＳＮＳでの友達への紹介を促す

ＭＳ社の【Ｅｘｃｅｌ】と旧Ｌｏｔｕｓ社の【１－２－３】
　　歴史的なソフトウェアのシェアー争いはどのように展開されたのか

　　１９９３年
　　　　ＭＳ－ＤＯＳ配下ではＬｏｔｕｓ社製【１－２－３】の独壇場であった
　　　　ＭＳ－ＤＯＳ配下でＭＳ社製【ＭｕｌｔｉＰｌａｎ】が動いていただけ
　　　　　　【Ｅｘｃｅｌ】はＭＡＣ配下で動いていただけ
　　　　他社製で【ＶｉｓｉＣａｌｃ】が動いていた
　　　　Ｗｉｎｄｏｗｓ３．１が発売される

　　１９９４年
　　　　ＭＳ社がＷｉｎｄｏｗｓ版の【Ｅｘｃｅｌ５．０】を発売する
　　　　両社の販売合戦が始まる

　　１９９５年
　　　　Ｗｉｎｄｏｓ９５が発売される頃には決着がついていた

　　ＭＳ社が取った販売戦略
　　　　・商品力（Ｐｒｏｄｕｃｔ）
　　　　　　利用者の評価では差が無かった
　　　　・課価（Ｐｒｉｃｅ）
　　　　　　ＭＳ社は乗り換えキャンペーンを積極的に行う
　　　　　　　　約６万円の【１－２－３】に対して約２万円の【Ｅｘｃｅｌ】を売り出した
　　　　　　　　半年後【１－２－３】も約２万円までに下げたが【Ｅｘｃｅｌ】はさらに値下げする
　　　　　　価格競争に持ち込んでも勝算があった
　　　　　　　　ソフトウェアは開発費が回収できれば、後はコピー販売で利益が出る
　　　　　　　　ソフトウェアは他に乗り換える可能性が低い
　　　　・販促（Ｐｒｏｍｏｔｉｏｎ）
　　　　　　ＭＳ社はWindows一本に絞った広告宣伝を行う
　　　　　　Ｌｏｔｕｓ社はＤＯＳ版にも広告宣伝を行わざるを得なかった
　　　　・販路（Ｐｌａｃｅ）
　　　　　　小売店中心の販売には差が無かった

　　商品が優れていたわけではなく、価格戦略と販促戦略に優れていたと言える

ピンチを乗り切るには
　　（１）聞き手の顔が険しくなった
　　　　　　・冒頭でプレゼンの内容を聞き手に確認する
　　　　　　　　こちらから質問して、要望や興味範囲を聞き出しておく
　　　　　　・途中であっても区切りを入れる
　　　　　　　　「ここまではよろしいですか？」「もっと聴きたいことはありませんか？」
　　　　　　　　軌道修正を図っていく
　　　　　　・同行するアシスタントに頼んでおく
　　　　　　　　気付いた時点で、口を挟んでもらう

　　（２）他人の作成した資料を使うことになった
　　　　　　・置かれている状況を把握する
　　　　　　　　プレゼンの目的を理解し検証する
　　　　　　　　　　聞き手の立場、人数、期待されている内容等々
　　　　　　　　　　話してはいけないこと、強調すべきこと等々
　　　　　　　　　　理解した内容を必ず誰かに検証して貰う
　　　　　　・資料に目を通し、全体の流れを掴む
　　　　　　　　印刷して注意事項を書き込む
　　　　　　　　資料の順番は配布資料との整合性を取った上で並べ替えても良い
　　　　　　・気持ちを整理する
　　　　　　　　雰囲気が伝わるので、代わりだとの態度をとらない

　　（３）機器が故障した
　　　　　　・機器に頼らず、資料だけでプレゼンを続ける
　　　　　　　　動揺した態度を見せずに、腹をくくってプレゼンを続ける
　　　　　　　　発生した出来事は正直に聞き手に説明する

　　（４）受け持ち時間が変わった
　　　　　　・ポイントとなるスライドを絞り込む
　　　　　　　　冒頭、聞き手に持ち時間が変わったことを告げてポイントを絞らせる
　　　　　　　　長くなっても、短くなっても、やることは同じ

　　（５）キーマンが中座した
　　　　　　・一旦、話を切り替える
　　　　　　　　残った人とＱ＆Ａを行って時間を潰す
　　　　　　　　着席されたら、「先ほどの続きから再開します」と告げて再スタートする

聞き手を意識して話に引き込むポイント

　　（１）きちんとした服装と態度
　　　　プレゼンターの服装によって、聞き手は尊重されているかどうかを見極める
　　　　態度で重要なのは、最初と最後にスクリーンを消し、前に踏み出して挨拶する

　　（２）体を聞き手に向けて立つ
　　　　指示棒を必ず使い、スクリーンに近い方の手で持つ
　　　　スクリーンに向かって話さない
　　　　２人～３人なら座ってもＯＫ、なるべく立って視線を集めてプレゼンする

　　（３）聞き手の目を見て話す
　　　　聞き手に不安感を持たせないように、目を合わせて話す
　　　　聞き手の中の、目線を合わせてくる人、表情がにこやかな人、うなずく人かに焦点を絞る
　　　　最後列から最前列に向けて順次目を合わせていく

　　（４）適時、聞き手に問いかける
　　　　問いかけを挟み込むことで、聞き手も集中するし、質問する切っ掛けを与えることになる
　　　　一呼吸置くだけで、聞き手の反応で理解の度合いが分かる
　　　　事前に問いかけのタイミングと内容を資料に書き込んでおく
　　　　３つ程度に決めておく
　　　　　　・前提知識の確認・・・ご存知でしょうか？
　　　　　　・現状の確認・・・どのようにしていますか？
　　　　　　・理解度の確認・・・ここまでよろしいでしょうか

　　（５）質問には復唱してから回答する
　　　　即答せず、全員に聞こえるように復唱してから回答する
　　　　発言し易い雰囲気を作り出す

論点のまとまりと話し方・言葉遣い・進行の仕方等の分かり易さがポイント

　　（１）全体像から始める
　　　　最初に全体操から始めて、真ん中で個別事項、最後に全体操を話して締めくくる
　　　　個別事項の話でも、同じく全体像・個別事項・全体像の話し方をする

　　（２）参照の指示は具体的にする
　　　　具体的な事例
　　　　　　・ページ番号を必ず振っておく
　　　　　　・指示代名詞は使わない
　　　　　　・スライドの切替の前に、簡単に内容を話しておく

　　（３）大きな声で話す
　　　　大きな声とジェスチャーを使って表現する
　　　　数を数えるときには、大きく指を使って表現する

　　（４）時々話すテンポを変える
　　　　声の調子を変えるだけでなく、一呼吸入れて話すテンポを変えて集中力を引き出す

　　（５）専門語には解説を付ける
　　　　勝手判断はせず、簡潔な説明で丁寧さを強調する

資料作成の４ステップ

　　（１）キーメッセージの設定
　　　　聞き手に理解・納得してもらいたい点を決める
　　　　　　プレゼン終了時点で、聞き手はどんな気持ちになればよいかを考える

　　　　３つのタイプで考える
　　　　　　・政策メッセージ
　　　　　　　　「～すべきである」、「～する必要がある」と行動を働きかける
　　　　　　・評価メッセージ
　　　　　　　　ある事項に対して評価や見解を述べる、行動は期待せず主張を述べるだけ
　　　　　　・事実メッセージ
　　　　　　　　単なる事実を述べる

　　（２）論理を組み立てる
　　　　理解・納得するための客観的な根拠で論理を組み立てる
　　　　　　論理は階層的に構築・展開する・・・キーメッセージを頂点としたツリー構造を考える
　　　　　　漏れや重複を防ぐ・・・最下層のメッセージを１枚のプレゼン資料にする

　　　　　　・政策メッセージ
　　　　　　　　必然性を強調する（デメリットの排除や課題の解決）
　　　　　　　　効用を強調する（メリットに繋げる）
　　　　　　　　実現可能性を強調する（現実的なコスト、スケジュール、方法）
　　　　　　・評価メッセージ
　　　　　　　　聞き手の視点で評価の基準を用意する・・・全ての情報を考慮し推測する必要がある
　　　　　　・事実メッセージ
　　　　　　　　事実を漏れなく示せばよい

　　（３）ストーリーを構築する
　　　　特に強調すべき点を洗い出し、話の流れを組み立てる
　　　　　　全ての根拠をストーリーに盛り込まない
　　　　　　　　聞き手にとって価値の高い根拠とインパクトの強い根拠に絞る
　　　　　　根拠を示す順序に工夫を施す
　　　　　　　　最初の１分～２分で聞き手の興味を喚起する

　　（４）資料を作成する
　　　　ストーリーに従って、メッセージや根拠を文章や図表で表す
　　　　　　重要な情報を目立たせる（余計なメッセージは入れない、３項目程度に絞る）
　　　　　　分かり易く表現する（レイアウトや言葉使いに注意する、目次を必ず用意する）
　

２００４年４月に
　　・旧あさひ銀行システムのアウトソーシング先をＮＴＴデータと決める
　　　　りそな銀行、埼玉りそな銀行は共にＩＢＭのメインフレームだった
　　　　　　複数のアウトソーシング先を確保してコストを比較した
　　・旧大和銀行システムへの片寄せ計画から旧あさひ銀行への片寄せにした
　　　　総合費用を１００億円安くできると試算した

２００３年３月には
　　旧大和銀行と旧あさひ銀行のシステムを接続し
　　　　旧あさひ銀行のシステムをりそな銀行と埼玉りそな銀行に論地分割させた実績がある
　　　　その後、旧あさひ銀行のシステムを旧大和銀行のシステムに片寄せする計画であった

		大和銀行	あさひ銀行
９８年	４月	ＩＢＭにアウトソーシングを開始する 　１０年契約で合計５００億円のコスト削減を目指す
	－		東海銀行との統合を発表する
００年	３月		三和銀行との３行統合を発表する
	夏		３行統合はご破算になる
０１年	８月	近畿大阪銀行、奈良銀行との経営統合を発表する 　システムは大和銀行に１本化する 　銀行名はりそな銀行と決まる
	９月		りそな銀行への経営統合を発表する
０２年	３月	りそな信託銀行が分離して営業を開始する 　２００９年に再統合される	あさひ信託銀行はりそな信託銀行に統合される
０３年	３月	りそな銀行のシステム統合が完了する 　りそな銀行・埼玉りそな銀行が営業を開始する 　りそな勘定系の１本化が始まる	りそな銀行に統合される
	５月	預金保険機構より公的資金を投入する 　システムの１本化は白紙に戻る
	７月～９月	コスト削減が至上命令となる 　ハードの統合、保守契約の見直し、あさひ銀行へのアウトソーシングが検討される
	１０月	ＮＴＴデータへのアウトソーシングが決まる
	１１月	システム１本化の検討が再開する
	１２月		あさひ銀行へのシステム１本化が決まる
０４年	１月		あさひ銀行のシステムをＮＴＴデータにアウトソーシングする 　７年間で２千億円の契約
	２月	Ｄ＆Ｉシステムの株式をＩＢＭに譲渡する	あさひ銀行ソフトウェアの株式をＮＴＴデータに譲渡する
	３月	大和銀総合システムの株式をアイネスに譲渡する
	４月		ＮＴＴデータへのアウトソーシングが始まる

経緯として
　　・コスト削減
　　　　アウトソーシングはグロスでの金額しか分からない
　　　　ＩＢＭへのアウトソーシングが高額である

　　・提案内容がヒットしなかった
　　　　ＩＢＭの提案は「新システム」への切替であった
　　　　　　古いシステムの統合ではなくて新システムを提案した
　　　　　　短期間にＶ字回復を目指す経営陣にヒットしなかった

　　・マルチベンダー
　　　　ＮＴＴデータはマルチベンダーを束ねられると提案した

　　・片寄せ方法
　　　　拡張性について、旧あさひ銀行システムはハブ・システムを採用していた
　　　　　　周辺システムに繋がり易い構造であった
　　　　統合コストについて、切替コストに１００億円の差が出た
　　　　　　　　端末・ＡＴＭの台数は旧あさひ銀行は旧大和銀行の１．８倍であった
　　　　　　　　接続端末・ＡＴＭの台数が多いシステムを残すのが安く済むと判断した
　　　　

（１）四コマ漫画（所要時間:10～15分程度、人数:20～100人、準備:四コマ漫画）

事務局が多数の四コママンガを用意し、一コマずつ切り離して袋などに入れておく。参加者が無作為に一コマずつ引き、自分の片割れのコマを持っている人を探してストーリを完結させるゲーム。多人数から4人ごとなどのグループ編成を楽しくやるときに効果的。

（２）ワン・ワード（所要時間:15分程度、人数:10～20人、準備:不要）

ファシリテーターが、テーマを参加者に告げる（例:ファシリテーション）。各自それについて一つの単語を連想する。参加者が順番にその単語を紹介し、次々と前の人の単語を使ってつながりのあるコントを即興で作っていく。

効果:他人の話をよく聴くことの重要性に気づく。即興力を養う。即興の面白さで場をほぐす。他人の発言を受容する。

（３）動作の足し算（所要時間:15分程度、人数:10～20人、準備:不要）

参加者全員がお互いが見えるように立つ。一番目に指名された人がある動作をする。全員でそれをまねる。二番目の人は、その動作に次の動作を加える。全員でそれをまねる。三番目以降も、覚えている範囲で、それまでの動作をまね、新しい動作を加える。

効果:からだの緊張をほぐし、リラックスした気分をつくる。他人を受け入れる環境をつくる。

（４）言葉の足し算（所要時間:15分程度、人数:10～20人、準備:不要）

ファシリテーターが、適当なテーマを参加者に告げる（例:ファシリテーション）。第一番目の参加者は、同じ言葉を繰り返した後、自分の言葉を加える。二番目の人は、前二つの言葉を繰り返した後で、自分の言葉を加える。三番目以降も、それまでの言葉を覚えている限り繰り返した上で、自分の言葉を加える。

効果:他人の話をよく聴くことの重要性に気づく。即興力を養う。即興の面白さで場をほぐす。他人の発言を受容する。

（５）ジャンケンミリオネアー（所要時間:5～15分程度、人数:100人以上でも可、準備:不要）

参加者に100円ずつ出してもらう。パートナーを見つけ、自己紹介した上でジャンケンする。勝った方が、その百円をもらって、次のパートナーを探す。これを繰り返して、最後に残った二人がみんなの前でジャンケンし、雌雄を決する。大変盛り上がります。知らない人の多い大パーティー向き。この後に立食パーティーなどがあると、ジャンケンした人たちが話しやすい。

数十人から200人規模でやれる。

（６）地図を作ろう（所要時間:5～15分程度、人数:10～50人、準備:不要）

出身地を代表する形で全員がフロアーに地図を描くように立つゲーム。北海道出身者が右上のコーナーに立てば、本州の人は部屋の中央部にといった具合。リーダーはどこにどう地図を描くという指示はださない。参加者のコミュニケーションのもとに地図ができるようにする。時間を計ると適度な緊張感が生まれて楽しい。同じ出身地の人が見つかり盛り上がる。

（７）グループキャラを探せ（所要時間:20～30分程度、人数:10～50人、準備:不要）

血液型、生まれた順（長男女、次男女、末っ子、一人っ子）、生まれた季節（春夏秋冬）、出身地、などでグループを作る。各グループに話し合ってもらって特徴を書き出してもらう。

（８）チームブレーンストーミング（所要時間:20～30分程度、人数:10～50人、準備:紙と筆記用具）

記録係を各チーム一人ずつ決め、ファシリテーターの出した質問に答えるアイディアを記録してもらう。質問例:丸いもの、休日で思いつくこと、赤いもの、スピード違反の言い訳、遅刻の言い訳、などなど、面白い質問を工夫すると盛り上がる。

（９）キャッチ（所要時間:5分程度、人数:10～20人、準備:不要）

円をつくり、左手の人差し指を左側の人の胸の前に差し出す。差し出された指をいつでもつかめるよう、右手を開いて構える。リーダーの「キャッチ！」の合図（フェイントあり）とともに、左指はつかまれないように下に逃げ、右手は隣の人の指をつかめるように閉じる。このゲームを、右と左を交代したり、メンバーが自由に号令をかけたりして繰り返す。

（１０）体でアンケート（所要時間:10分程度、人数:何人でも、準備:不要）

会場の中で、例えば窓側を100%YES、通路側を0%にして、ファシリテーターの質問に対する解答を、立位置で表現する。

質問例:

• ワークショップは得意か？
• 理想のファシリテーターにどれくらい近づいているか？
• 今日のワークショップをどれくらい楽しみにしているか？

（１１）手のひら催眠術（所要時間:15分程度、人数:何人でも、準備:不要）

ペアになって、相手の手の平の動きに顔（体）を追従させていく。体をほぐすと同時に、人をコントロールする（される）ことを体感する。

（１）めかくしマスゲーム（所要時間:30分、人数:10～20人、準備:不要）

参加者に手を取り合って円陣をつくってもらう。円陣ができたら目をつぶってもらう。ファシリテーターは、「絶対に目をあけないように、全員で正方形を作ってください」と指示する。声は出してよい。できたと思ったら、「できた！」と声をだしてもらう。それではどうぞ！できあがりまでの時間を測り、何分何秒でできたかを提示。正三角形、二等辺三角形、長方形、と形を変えてやってみる。グループ対抗で時間を競ってゲーム感覚でやるのもおもしろい。終了後、言葉によるコミュニケーションの大切さ、適切な言葉を使用することの大切さ、リーダーシップ・フォロアーシップなどを振り返る。

効果

グループワークにおけるリーダーシップ・フォロアーシップ・自主的参加・コミュニケーションなどを体感する。

（２）砂漠生き残り大作戦（所要時間:40分、人数:1グループ6～8名、大人数の場合、グループに分けて実施、準備:ゲーム説明書、15アイテム順位付け表、発表用模造紙、マジック）

1グループ6～8名に分かれ、以下のことが書かれた、ゲーム説明書を配布。

「8月中旬午前10時、あなたの乗っていた飛行機が米国南西部の砂漠に墜落。パイロットは即死。墜落地点は予定飛行ゾーンから約90km離れている模様。また、約100km離れたところに、鉱山のキャンプがあり、作業員がいるらしい。砂漠は今、摂氏40度、正午になれば気温はさらに上昇すると思われる。あたりには砂しか見えない。あなたは、半袖のカジュアルな服装で、奇跡的なことに怪我はなかった。ポケットにはハンカチと、米ドル札が$85、コインにボールペンがある。他の生存者と共に、機体残骸から次の15のものを集めた。皆が無事生き延びるために必要と思われる順に、この15のものをランク付けせよ。」

『コンパス、パラシュート、懐中電灯、人数分のサングラス、45口径銃、本「砂漠の動物たち」、ジャックナイフ、一人当たり一杯の水、食卓用塩、ガーゼと包帯、化粧鏡、ウォッカ2本、ビニールのレインコート、航空地図』

まず始めに、自分で、15アイテムごとの優先順位付けを行う。次に、チーム内で、優先順位付けを行う。最後に、自分で決めた優先順位と、チームで決めた優先順位の得点付けを行い、得点差から、自分ひとりで結論を出した場合と、チームで結論を出した場合の違いを確認する。

効果

得点差が小さい方が、チームのシナジー効果を発揮出来たと言える。この得点差で、チームの良さを引き出すことが出来たかどうかを知ることが出来る。

※他にバリエーション多数あり「月で迷ったゲーム」「サバイバルゲーム」「栄養学教室」・・・

（３）メルヘン大会（所要時間:40分程度、人数6名1グループ、準備:メモ用紙、お伽噺・昔話の資料、発表用模造紙、マジック）

このゲームは、参加者が良く知っているお伽噺や昔話の内容を聞き、絵を見た人が、まず一人に伝え、次々に6人にそれを伝えます。そして6人目の人が伝わった情報（内容と絵）をどのように再現するかを見て、コミュニケーションが、どのように歪曲され、脱落していくかなどを知り、職場等におけるコミュニケーションは、どうあるべきかを考えるものです。同時に、命令や報告の際の確認の大切さを考えさせることも出来る。

（４）目隠し道案内（所要時間:20分程度、人数:10～50人、準備:探索ルートの確保、目隠し）

ペアになってもらう。その一人に目隠しをつけてもらう。相棒が、目隠しをつけた人と手をつなぎ、決められたルートを案内しながら歩く。森の中など頭上や足元に障害物のあるルートがあると理想的。

パートナーを信頼し、コミュニケーションすることの重要性を感じてもらう。

（５）ペーパータワー（所要時間:20分、人数:10～20人、準備:A4サイズの紙）

数人のグループに分け、与えられたA4の紙だけで、できるだけ高いタワーを作ることを競わせる。紙は各グループに30-40枚程度配布する。

タワー作りに入る前に、作戦タイムを10～15分与える。作戦タイムには一枚以上の紙に触れてはいけないと指示する。作成時間は30秒から1分。

楽しく、グループの成果を称えた上で、グループディスカッションのやりかたと、作戦のたてかたをふりかえる。

効果

グループワークにおけるリーダーシップ・フォロアーシップ・自主的参加・コミュニケーションなどを体感する。

（６）スノー・フレーク（所要時間:5分程度、人数:10～20人、準備:A4程度の大きさの紙×人数）

メンバーに紙を配り、各自で二つ折りにする。その紙の一部を切って、また二つ折りにする。この作業を3～4回繰り返したところで、紙を開き、できあがった紙を見比べる。同じ指示で紙を折り・切っても、できた形は人により異なる。多様性を学ぶことにつながる。

（７）ラインナップ（所要時間:10分程度、人数:20～50人、準備:なし）

参加者を複数のグループに分る。スタートの合図とともに、参加者が名前の五十音順になるよう一列に並び替え、その時間を競い合う。次に同じように誕生月日順に並び替え、時間を競い合う。勝った（負けた）要因を振り返る過程で、皆が協力しあうことの大切さや、リーダー、フォロワーの役回りを学んでいく。

（８）流れ星（所要時間:15分程度、人数:10～100人、準備:紙と筆記用具）

参加者に紙と筆記用具を配り、ファシリテーターの言葉（例:流れ星、竜巻）を絵にしてもらう。質問は受け付けない。

効果

一方通行のコミュニケーションによって生まれる、受け手の多様性を感じる

（９）キャッチボール（所要時間:20分程度、人数:10～50人、準備:なし）

全員で輪になり、相手にアイコンタクトを送ってから仮想のボールを投げて受け取ってもらう。ボールの数をだんだん増やしていくと面白い。非言語コミュケーションや双方向のコミュケーションを学ぶ。

（１）靴が取り持つ縁（所要時間:人数×5分程度、人数:10～50人、準備:不要）

参加者が入室するときに、片側の靴を脱いでいってもらう。片方の靴だけの山ができる。全員集まったところで、自分とは違う靴をその山の中から拾ってくる。全員が靴を拾ったところで、その持ち主を、足元を見ながら探す。見つけられた人は、拾ってもらったお礼に、名前と自分に関するユニークなことを3つ教えて靴を返してもらう。全員靴を取り戻したところで、靴を返した人のユニークな3つの話を全員に紹介する。

（２）ウソ、ホント？（所要時間:20～30分程度、人数:5～50人、準備:A4の紙）

4～6人のグループに分かれる。A4ぐらいの紙を配り、各人、自分について4つの事実を箇条書きしてもらう。ただし、そのうちの一つはウソ。各自そのリストを読み上げ、残りの人は、ウソと思うことをメモする。全員が自分のリストを読み上げた後、最初の人から順番に何がウソかをみんなで話し合い、答えを言う。

短時間で楽しく相手を知ることがでる。共通項も見つかるかも。見かけと真実の違いにも気づくかもしれません。

（３）話題づくり（所要時間:人数×5分程度、人数:5～10人、準備:カード）

• 全員にA5程度の紙を配り、会のテーマに関する問い掛けを、一枚に一件、記入してもらう。見えないように折って帽子などに集める。人数と時間に応じて、一人一問から数問まで調整することも可。
• 無作為にその紙を引き、問題を読み上げ、自分なりの回答していく。他の人の回答に自分なりのコメントや回答を言い合ってもよい。
• 必要に応じて回答時間を制限する。

質問の例:

1. ファシリテーションに関する会:ファシリテーションをどう使いたい？
2. 読書会:もっとも印象に残っている本は何
3. PTA:これは問題だと思ったことは何？

（４）この人だあれ？（所要時間:30分程度、人数:10～20人、準備:ユニークな経験を集めリストにする）

事前に（会のはじめに）全員に簡単な自分のユニークな経験を一行程度で書いてもらう(複数書いてもらうことも可)。他人に見られないように事務局が回収し、誰が書いたものかはわからないように、それをリストにして全員に配る。このリストをもとに、一人につき、3回質問できるというルールで、15分程度時間を与え、何人の人を特定できるかを競う。人数が多い場合（30人以上）、数人ずつのグループに分けて、グループ間で何人当てられるかを競ってもいい。質問の仕方などをグループ内で協議するというプロセスが入ってきて新しい効果が期待できる。

「ユニークな経験」例:

• 合気道の有段者でハリウッドスターのスティーブン・シガールと一緒に練習した。
• お風呂で本を読んでいて、風呂桶に本を落としたことがある。
• 1年間に50冊以上本を読む。
• 般若心経を諳んじている

（５）名前の足し算　（所要時間:15分程度、人数:5～100人、準備:不要）知る

5～15人程度のグループに分ける。人の名前を覚えるこつをファシリテーターが簡単に紹介する（顔の特徴と名前の特徴をとらえ、連想して覚えるなど）。グループが一重の輪を作って内側を向く。最初に指名された人は、手をあげて「私は○○です」と名前を紹介する。その左の人は「私はAさんの隣の××です」という。それ以降の人は、前の人の名前をいって、自分を紹介することを繰り返す。あだなでやっても可。

（６）私の親友だったら（所要時間:人数×10分程度、人数:5～10人、準備:質問カード）

ペアを組んでもらって、それぞれに3～5問程度の質問を渡し、10～15分程度時間を与えて、相互にインタビューしてもらう。ペアは知らないどうしになるようにする。ひとり余る場合は3人の組を一つ作る。全体に対して、インタビューの結果わかったことを報告してもらう。

（７）私ってこんな人（所要時間:5分×人数、人数:5～20人、準備:質問、紙と筆記用具）知る

白紙もしくはフリップチャートを配り、ファシリテータ-は次の事項を次々読み上げる。読み上げた後、約2分でそれぞれの考えていることを記入していく。

読み上げる内容

1. 私が今、ワクワクしていること
2. 私が今、気になっていること
3. 今日これまでにいらいらしたり、腹立たしかったこと
4. 私について職場の仲間が知らないこと
5. 私が大切にしている価値観のうちの一つ
6. 私のことを自分のひ孫はこう語るだろう
7. 私がこれまで成し遂げたことの中で特に誇りに思うこと（ひとつ）
8. 私が仕事の中で、一番楽しんでいる事
9. もし経済的な心配がなかったらやりたいこと
10. 私が尊敬する人の性格、人柄、資質（ひとつ）

カードを読み上げる、もしくはフリップチャートを見せながら自己紹介を行う。

効果

顔をあわせるだけ、もしくは日常会話だけではなかなか知りえない、お互いの価値観・人間性を手っ取り早く共有する。

（８）人間ビンゴ（所要時間:10～15分程度、人数:20～100人、準備:ビンゴ型質問表、賞品）

ビンゴのフォーマットに一連の質問が記された用紙を用意する。参加者は、その質問に「はい」と答えられる人を探し、そのマスにサインしてもらう。これでビンゴゲームを行う。

質問の例

申年の人、北海道出身、ハンディ20以下のゴルファー、10カ国以上行った、

（９）署名運動（所要時間:20～30分程度、人数:10～200人、準備:質問シート、賞品）

全員に10～20程度の質問を書いたシートを渡す。その質問に合う人を探してサインを集める。

早く集められた人2～3人に賞を出す。

質問の例

• コンタクトレンズをしている
• 茶色の靴下をしている
• 映画シカゴを見た
• ヨーロッパに行ったことがある
• 上海に行ったことがある
• 楽器を演奏できる
• 外国語を話せる
• 変わった趣味を持っている

等など

（１０）フォーチュンクッキー（所要時間:人数×5分程度、人数:5～10人、準備:フォーチュンクッキー）

フォーチュンクッキーを配る。順番にあけて、そこに書いてあることに絡めて自己紹介する。

（１１）靴工場（所要時間:15分程度、人数:10～20人、準備:不要）

参加者は円陣を組む。全員靴を脱ぎ、円陣の真ん中に積み上げる。リーダーは、左右異なる他人の靴を1足履くように指示する。その後、正しい靴の持ち主を探し、自己紹介して肩を貸しながら靴を履きかえる。

（１２）自分探し（所要時間:15分程度、人数:10～50人、準備:のりつきカードとペン）

全員にのりのついたカードを配り、「こんにちは、私は○○です。」と書いてもらう。カードを回収し、袋などに入れる。それを無作為に引いてもらって胸に貼る。全員立ち上がって、自分の名札をつけた人を探して自己紹介する。

多人数で、二人ずつのペアを作るときに有効。名前だけでなく、何か自分に関するユニークなことを一言添えてもらうと話が弾む。

（１３）好きなもの（所要時間:20～30分程度、人数:5～50人、準備:A5カード）

4～6人のグループに分かれる。カードを一人一枚ずつ配り、好きな色、食べ物、行きたい国、この後やりたいことを箇条書きしてもらう。お互いに見せないようにする。カードを回収し、シャッフルして無作為に配る。配られたカードを順番に声を上げて読み、誰のものかを皆が書き留める。全部のカードを紹介し終えた後、正解を告げ、誰がもっとも当てることができたかを競う。

（１４）他己紹介（所要時間:人数×10分程度、人数:5～10人、準備:不要）

知らない人とペアを組んでもらう。5分間時間を与えてインタビューしてもらう。その後、全員のその人を紹介する。

（１５）隣人の証言（所要時間:20分程度、人数:10～20人、準備:不要）

円を作り、両側の方に自己紹介。同じ人と両隣にならないように、複数回、円を作っていく。5回、「円作り＆自己紹介」が終わったところで、ファシリテーターの指示で、1回目からの円を再現していくのだが、両サイドの相手は誰か、記憶を辿る過程で、連帯感も醸造されていく。

（１６）ネーム・トス（所要時間:10分程度、人数:10～20人、準備:不要）

円をつくり、各自が呼ばれたいニックネームをつける。それを順番に紹介していき、全員のニックネームを全員が覚える。皆で順番に一人ひとりのニックネームを大きな声で呼ぶ。

（１７）こんな経験ある？（所要時間:5分程度、人数:10～20人、準備:不要）

円になって立ち、ひとりが体験（例「今朝コーヒーを飲んだ人！」「沖縄に行ったことがある人！）を告げる。これにあてはまる参加者が円から出て、円の別の位置に入る。

（１８）マイブーム（所要時間:20分程度、人数:10～20人、準備:不要）

自分のマイブームを3つ挙げてもらい、ポストイットに書き出し、グループ内で紹介しあう。その3つの中から各々「ベスト・マイブーム」を決めてもらい、グループ外のメンバーと紹介し合う。最後にベスト・マイブームの内容で参加者全員を50音順にラインナップ。3つの新しいグループに編成し直す。

（１９）握手で自己紹介（所要時間:人数により5～15分、人数:何人でも、準備:不要）

一人ひとりニックネームを名札に書く。輪になって最初の人が隣の人の前に行き、交互にニックネームを呼び合ってから握手する。最初の人は一つずれて同じ作業を繰り返し、次の人が最初の人と同じ作業を行う。この作業を繰り返し、輪をまわりながら全員に対して2回ずつ挨拶を行っていく。

　　顧客獲得の手法を整理する
　　　　・時間軸として
　　　　　　存在を認知してもらう　⇒　継続的に交流を図り関係を強化する
　　　　・接触の方法として
　　　　　　プッシュ型・・・積極的に情報を発信し、顧客の興味などの情報を吸い上げる
　　　　　　プル型・・・・・顧客が収集する情報を提供し、顧客からのアクセスに適切に対応する

		認知度アップが目的	関係強化が目的
	プッシュ型	・オートコール 　　自動音声電話で潜在顧客に販促 ・ファックスＤＭ 　　顧客リストにファックスを一斉送信	・テレマーケティング 　　電話を掛けて興味を聞き出す ・メールマーケティング 　　顧客属性やアクセス傾向を基に 　　情報を分析し販促メールを送信
	プル型	・検索サイト活用 　　検索サイト上で自社のアピール ・アフィリエイト・プログラム 　　ネット上の代理店から誘導	・コールセンター 　　問い合わせに迅速に対応し 　　信頼度を上げる

　　認知度アップ＋プッシュ型
　　　　電子メールに加えて電話とファックスの活用
　　　　　　オートコール・・・音声をコンピュータから自動配信
　　　　　　ファックスＤＭ・・専用業者から顧客リスト先にファックス配信

　　認知度アップ＋プル型
　　　　検索エンジン対策を施す
　　　　　　ＳＥＯサービスを利用する
　　　　　　検索広告サービスを利用する
　　　　　　アドワーズ広告（Ｇｏｏｇｌｅ）を利用する

　　　　課金の仕組み（タイプ）を理解する
　　　　　　広告が表示されると課金するタイプ
　　　　　　クリックされると課金するタイプ
　　　　　　商品を購入したら課金するタイプ

　　　　表示される順位を理解する
　　　　　　クリック単価の高い順に表示するタイプ
　　　　　　クリック単価とクリック率とでスコアを算出し、スコア順に表示するﾀｲﾌﾟ
　　　　　　検索サイトの評価基準に沿って表示されるタイプ

　　　　検索キーワードを絞り込む
　　　　　　有料広告サイトに申し込み、無料サービスを利用する
　　　　　　　　管理レポート（検索キーワード順位等）を有効活用する

　　関係強化＋プッシュ型
　　　　既存顧客へのアプローチ
　　　　　　電子メールを利用する
　　　　　　　　個別に顧客対応できないと、無意味となる
　　　　　　　　閲覧履歴ログの解析などと組み合わせる

　　　　実店舗によるアプローチ
　　　　　　ネット客には電子メールで新規キャンペーンを仕掛ける
　　　　　　店舗客には購入履歴を分析して継続購入を促す

　　　　コールセンター作り（要望等を聞き出すセンター）
　　　　　　テレマーケティングを実施する
　　　　　　　　自動音声システムの利用
　　　　　　顧客情報を収集し個別対応を行う

　　関係強化＋プル型
　　　　コールセンター作り（クレームやメールでの問い合わせに対応する）
　　　　　　顧客の要望に応え、顧客満足度を高める
　　　　　　　　顧客情報のデータベース化
　　　　　　　　対面コミュニケーション（ネットを介して）

プレゼン資料の作成
　　（１）資料の構成
　　　　　　・表紙やアジェンダを作成する
　　　　　　　　いきなり本題から始めない
　　　　　　　　表紙にはタイトル、日付、作成者名
　　　　　　・各ページに番号とタイトルを付与する
　　　　　　　　軌道修正を図っていく
　　　　　　・最終ページにマトメを入れる
　　　　　　　　結論や強調点を再確認する

　　（２）資料の内容
　　　　　　・１ページの項目数は７＋－２にする
　　　　　　　　説明内容を文章にはしない（説明が資料を読んでいるだけと受け取られる）
　　　　　　・箇条書きや図表を使う
　　　　　　　　説明内容に集中させるに必要
　　　　　　・フォントに気を付ける
　　　　　　　　タイトルは３６ポイント以上
　　　　　　　　本文は２８ポイント以上
　　　　　　　　フォントはゴジックを基本とする
　　　　　　　　改行位置に注意する
　　　　　　・アニメは多用しない
　　　　　　　　操作に気を取られることになるので気を付ける
　　　　　　・色のコントラストに気を配る
　　　　　　　　事前にスクリーンに映写してみて確認する

プレゼン資料の見せ方
　　（１）最初に
　　　　　　・紙の資料とスクリーンとの関係を説明する
　　　　　　　　異なる点はどこかを説明しておく

　　（２）途中で
　　　　　　・説明内容とスクリーンとを合致させる
　　　　　　　　異なると気が散るので気を付ける
　　　　　　・説明の流れに気を付ける
　　　　　　　　ページ替えのタイミングは見ている人の注意を引き付けながら行う
　　　　　　　　手元に資料をまとめて縮小印刷しておく
　　　　　　・小技を使う
　　　　　　　　画面を消す・・・スクリーンから一旦話題が外れる場合に使用する
　　　　　　　　　　【Ｂ】を押すと画面が黒くなる、【Ｗ】だと白くなる
　　　　　　　　特定ページにジャンプする・・・矢印キーやマウス右クリックでも移動できるが
　　　　　　　　　　【飛びたいページ番号】＋Enterキー押下
　　　　　　　　非表示ページを表示する・・・用意しておいた非表示のページを表示したい
　　　　　　　　　　一つ手前のページで【Ｈ】を押す、次の非表示ページが表示される
　　　　　　・ポインターを上手に使う
　　　　　　　　レーザポインターはなるべく使わない
　　　　　　　　むやみに弄らない
　　　　　　　　スクリ－ンを叩いたり擦ったりしない
　　　　　　　　聴衆に背を向けない
　　　　　　　　人を指名する際に使用しない
　　　　　　・白板には黙って書く
　　　　　　　　大きく見やすく書く
　　　　　　　　書き終わってから聴衆に向かって話し始める
　　　　　　　　消す際には確認してから消し始める（できるだけ一部分を消す）
　　　　　　・実物は回覧しない
　　　　　　　　手元に回覧物が来ると、説明を聞くことより回覧物に気を取られてしまう

　　顧客の変化を取り込む４つの営業戦略

　　・先手必勝戦略
　　　　今後の市場の変化を予測し、先手を打って新しい領域での戦いに移行する
　　　　　　圧倒的なシエアを取る戦略

　　　　　　業態や商品の魅力で戦おうとする他社に先駆けて
　　　　　　　　価格競争を仕掛け、圧倒的市場を獲得する戦略

　　　　　　価格訴求の限界が直ぐに表れ、苦しいい状況に追い込まれるケースもある

　　・独自市場創造戦略
　　　　市場や競合の動きを見て、自社の強みを発揮できる独自領域を生み出し、
　　　　　　特化してオンリーワンになる戦略

　　　　　　通常の市場の流れに逆行死ながら独自の市場を創造する

　　・領域最適化戦略
　　　　自分の戦っている領域はどこに位置しているかを改めて一つ一つ整理し、
　　　　　　そこでの成功条件を徹底させる戦略

　　　　　　領域ごとの違いを鮮明に意識し、具体的な動き方まで変える必要が有る

　　・新規事業・商材の事業展開戦略
　　　　新規事業の生成・発展から完結に至るストーリーを組み、
　　　　　　展開ステップを組むことで成功に導く戦略

　　　　変化の時代に合った事業展開ストーリー
　　　　　　パトナーシップ対応
　　　　　　　　新規事業の仮説作り、一緒に事業を進めるパートナー探し
　　　　　　エンジニア対応
　　　　　　　　成果を上げ成功事例を作り、専門ノウハウ（エンジニア）を蓄積する
　　　　　　ハイスピード対応
　　　　　　　　成功事例を横展開して市場にへ一気に浸透させ、シエアを獲得する
　　　　　　コストダウン対応
　　　　　　　　価格競争（コストダウン）を仕掛けて競合他社を蹴落とす

提案書作成の７原則
　　・計画の実施策や問題の解決策を先方に代わってまとめる

　　・自分の言いたい事ではなく、先方の知りたいことに徹する

　　・先方の要望、要件、問題に対する提案のコンセプトを明記する

　　・計画の実施策、問題解決策の特徴、効果を適切な絵や図形、表にする

　　・計画の実施策、問題解決策の費用対効果、そのサポート体制を明記する

　　・先方の要望、問題に対してその都度何回でも作成する

　　・先方の中で提案書が独り歩きできるように作成する