IT系の勉強会でそこそこ上手く話せる３つのトピック

いわゆる勉強会というやつをやってみた。IT勉強会カレンダーに掲載するほどオープンなものではない。SlideShareにアップロードしている人が多少いたくらいか。

内容はエンジニアリング系で、JavaによるWebアプリの開発とその周辺分野が中心だった。各自がスライドを用意して順番に話し、聞き手が質問や意見を投げかける、といった形で進行する。

何人もの発表を聞き、実際に自分自身で話してみて、「この手の勉強会でそこそこのクオリティを担保するためのポイント」が少し見えてきたのでメモする。


＊発表テーマ

重要なのは結局、話す内容に尽きる。スライドが見やすいとか、話し方が丁寧だとか、そういったプラス点は瑣末なもののように感じた。あるいは、内容の良さと伝え方の良さは連動しているのかもしれない。いずれにせよ、発表テーマが重要であることに異論はないと思う。

それなりに魅力的だった発表トピックは、主に「問題解決型」「手法紹介型」「原理解説型」の３つに分かれる。また、聞き手に対する影響として「既知/共感」「未知/刺激」の２種類があるように思う。これらは私の主観的な分類と命名で、他意はない。


＊問題解決型

話者が実際に直面した問題とその解決策を共有する。まず「こういうことがしたい」から始まって、「とりあえずこうやってみた」が、「こういうエラーが起きた」。調べてみると「実はこうなっていたからだ」と分かった。その後、「じゃあこうすればいい」と解決策に辿り着く。

既に同じ問題と出会ったことのある人は、課題提起に共感し、解決策を聞いて「そういうことだったのか！」と感心する。少し時間を掛けて調べたり試行錯誤すれば同じことは学べたはずだ。しかし、スケジュールや優先順位の関係もあり、必ずしも学習に注力できるわけではない。だからこそ、「少しだけ頑張って１つ調べました」を複数人が持ち寄ることで、勉強会が成り立つのだと思った。

一方、その問題とまだ出会っていない人は、将来同じような問題と出会ったときのための方向性を学ぶことができる。とは言え、実感していないと理解できないことも多い。そうした聞き手にとっての意義はむしろ、いざとなったときに「誰に聞けばいいのか」「どのスライドを見返せばいいのか」というリファレンスを蓄積できることだと思う。

なお、問題を複数列挙することもある。「ついついやってしまうミス」「ツールを初めて使ってみたけど分からないことだらけだったよ」といった内容だ。この場合は主なものを３点ほどにまとめて、失敗例（アンチパターン）と成功例を順に示すと分かりやすい。


＊手法紹介型

話者が新しいツールや方法を紹介する。まず「こういうことがしたい」から始まって、「でもどうしたらいいか分からない」or「すぐに思いつくやり方だと手間が掛かる」といった聞き手の状況に理解を示した上で、「こういうのがあるんですよ」と紹介する。そして「こうやって使います」と手順やサンプルコード、デモを示す。

「こういうことがしたい」と思いつつ、無知や手間が原因で行動できなかった人は、発表を歓迎するだろう。また、そのツールや手法について、言葉だけ聞いたことがあるとか、検索して調べてみたけどいまいち理解できないとか、書籍を購入したものの読んでいないとか、そういった人は、実践的でシンプルな手順・サンプルコードをすぐに活用するはずだ。

一方、手段を知らないが故に「こういうことをしよう」という発想さえ持たない人もいる。彼らは新しい手段を知ることによって、次の機会に「こういうことをしよう」と思いつくことができるようになる。「あのツールを使えば簡単にできるかもしれない」という見積もりがあるので、実行を恐れない。シンプルなデモを１つ見るだけで、素人は勇気づけられ、挑戦できるようになるのだと思う。


＊原理解説型

自分たちが普段使っている技術の裏側はどうなっているのか、といった原理を解説する。「あまり知らなくてもこうすれば問題ないからOKだよね」と現状を共有した上で、「でもこういうとき迷いませんか？」と投げかける。そして「じゃあ全体像を理解して安心しましょうよ」と提案する。

ツールの仕組み・全体像を知らないまま利用している人は、潜在的な不安を抱えている。かといって、時間を掛けてドキュメントに目を通すほどの必要性は感じていない。そういう人は多い。当然ながら、「短時間でドキュメントの要約を理解したい」というニーズを抱えている。10人が1つずつツールを担当して要約すると、1の努力で10の知見を共有することができる。

そもそもツールを利用したことがない聴き手の場合、その発表を聴くことで全体像をざっくりと知ることができる。結果、効率的な自主学習に繋げることができるかもしれない。少なくとも、知らないから手を出しにくい、という状況から前進するはずだ。聞いた上でやっぱいいやとなったり、実際に使っていないから聞いても分からないかもだけど。

ちなみに、注意点としては単調でつまらない発表になりがちだということ。文献やドキュメントの要約を話すことになると思うが、そういった引用元は「脳をフル回転して主観的に読むこと」を想定している場合が多い。同じ内容を同じように話すだけでは、発表の場において、受動的な聴き手にとって苦痛な時間となる。

したがって、話したいことが10あったら1に抑えるべきだと思う。なるべくビジュアル化して、なるべくシンプルに、要点だけを紹介する。「つまりどういうこと？」「だから何が言いたいの？」と思わせないように練習・改善を繰り返すのが良いかもしれない。苦労の割に受けが良いとは限らないのでコスパは悪い。ただ、説明力は格段にレベルアップすると思う。


＊最後に

スライドについて補足する。①共有・DL可能な状態にすることと、②参考サイトや推奨書籍を掲載しておくと、聴き手にとって嬉しい。①はサンプルコードを読み直すときに助かる。②はより体系的な・より深みのある学習へと繋げることができる。

時間制限のあるプレゼンテーションでは、聞きたことの10％も覚えられず、言いたいことの10％も伝わらないので、見返せるスライドだとか、分量のある本にバトンタッチするのが望ましい。

なお、偉そうなことを書いてはいるが、自分は全然上手く話せなかった。結構悔しい思いをしたので、同じ過ちを犯さないように振り返ってみた所存である。要は、反省文でした。

おしまい。

顧客分析ツールで創作の登場人物にリアリティを持たせる

文章を書き慣れるために、とにかく記事を更新していきます。



【この記事の要約】

＊前提：人間の行動・心理を分析するためのマーケティング手法があります。
＊主張：それを小説執筆などの創作活動に応用してみてはいかがでしょうか。
＊結果：あなたの作品のキャラクターは、より現実的な存在になります。

＊具体例① ジャーニーマップ：「カフェに入ってから注文する」といった１つのアクションについて、一連の行動を時系列でマッピングします。

＊具体例② 共感マップ：1人の人間について「言動/態度」（アウトプット）、「見聞」（インプット）、「思考/感情」（内面）、「Pain/Gain」（欲望）で要素分解します。



【本題】

１：人間を理解するためのマーケティング手法がある。

企業のマーケティング活動について、脚本術や物語作法を応用しようとする流れが一部に存在します。コミュニケーション面では「いかに分かりやすく話を伝えるか」「相手に寄り添えるか」「相手を引き込めるか」が要求されるからです。

また、それだけではなく様々な顧客分析手法が登場しています。ユーザーについて理解しなければ、使ってもらえる製品やサービスを開発することはできないからです。上辺だけのアンケート結果では参考にならない場面も多々あります。だからこそ、いかに顧客の深層心理まで読み解くかが重要だったりするのです。

HUNTER×HUNTER風に言うと「何を思い、何に怒り、何を好み、何を求めるか、どこを旅し、誰と出会い、どんな経験をするのか。それら全てが」１人の人間としての顧客を「形づくるのです」。そういった顧客のインサイトと向き合うために、色々なツール・手法が開発されています。

そこで、今度は反対に「小説や漫画などの創作活動を行う人が、マーケティングツールを逆輸入したら面白いんじゃないか」ということを思い立ちました。



２：具体例「ジャーニーマップ」

顧客の一連の行動を時間軸でマッピングする手法です。例えばスターバックスでは、お店に入ってからお店を出るまでに、顧客がどのような行動をするのかを分析しています。その上で、より快適な空間を提供するための改善努力を行っているのです。

参考：User Experience Journey Map - ユーザーエクスペリエンス・ジャーニーマップ
参考：エクスペリエンスジャーニーマップ／カスタマージャーニーマップ

同様に、登場人物が２人でカフェに入る場面を想像してください。どちらがドアを開けるでしょうか、どのように開けるでしょうか、開けた人と開けてもらった人のどちらが先に店内の異変に気付くでしょうか。

２人がどんな人なのか、どんな関係なのかによって答えは変わります。もちろんそれだけではなく、なぜカフェに入ったのか、荷物はあるのか、季節や気温や天気はどうなのか、どんなカフェなのか、多くのチェーン店と同じようにドアは透明なのか、普段から来客は多いのか、初めて入る店なのか、などなど。

そういった事情が違うと「カフェに入る」というアクションを行う際にも、時系列での行動は変わってきます。

初めて入る店であれば、カフェの前に駐輪している自転車の数に圧倒されてしまい「空席はないかもしれない」という半ば諦めた気持ちで、硝子ドアの向こうを覗き込むでしょう。ドアを実際に開けるのはその後です。

しかし、普段から来店していれば、その自転車が隣のビルの進学塾に通う学生たちのものだと知っているので、安心しきった気持ちで躊躇いなくドアを開けるでしょう。

１つのアクションを終えるまでに、どんな行動を取っているか、取り得るか。本来取りたかった行動を期待通りに取ることができるのか、できないのか。その際にどんな感情が生まれるか。

本人が意識しているかどうかさえ明確ではないレベルで、その人間の行動を分析できているでしょうか。想像だけで文書化するのは難しいものがあるので、時系列での行動や感情といったものを図にしてしまいましょう。



３：共感マップ。

ある人間について「見たもの/聞いたこと」（外部からインプットされた情報）、「発言/行動/態度」（外部にアウトプットした情報）、「思考/感情」（外部とのやり取りによって影響を与え合う内面）、「Pain/Gain」（結果として得るマイナスとプラス：背景となる苦痛や欲望）を要素分解します。

参考：ファンが共感する６つのポイントがわかる「共感マップ」の簡単な利用法
参考：『図解ビジネスモデル・ジェネレーション ワークブック』無料サンプルの該当頁

例えば、カフェに入った先輩♂と後輩♀。先輩は財布を取り出そうとしますが、肝心の財布は鞄の奥に入り込んでしまったようでスマートに取り出せません。何とか支払いを終えた後、後輩がスムーズに財布を取り出すのを見て、先輩はもやもやします。

背景には、異性の後輩に良く見られたいという下心（Gain）があります。しかし、財布を取り出すことに時間を掛けてしまいました（行動）。

たとえ実際には相手が気にしていなくても、店員や後輩やレジに並ぶ他の客が自分を待っているという事実。公共の場で他人に迷惑を与えることが恥だという社会通念（思考）。相手に恥を見せてしまったという実感。その結果、生じる焦り（感情）。

さらに、後輩がスムーズに財布を取り出した（見聞）ことで、それができなかった自分との格差を感じ、ショックを受けます（Pain）。後輩のことをまだ良く知らないのであれば、彼女はしっかりしている人間なのだろうか、なさけない失望されたのではないか、と絶望しています。

ところが、実は財布を取り出す時間は大差なかったのです。彼女側視点で物語を描くと、先輩が会計を行っている待ち時間で、財布を取り出しただけだったのです。しっかりものではありません。自分が財布を取り出すことに意識を取られて、先輩の焦り具合にさえ気付いていません。

しかし、先輩はどうでしょうか。下心（Gain）を満たすという目的の達成から遠ざかり、ショック（Pain）を受けています。このギャップを解消するためには、何らかの手を打たなくてはいけません。次にアウトプットされる言動は、この深層心理の影響を受けているはずです。たとえ本人が意識していなくても。あるいは意識した上で、不自然にならないように平静を保とうとするかもしれません。

その結果、焦りで声のボリュームが少し上がってしまうとしましょう。すると、後輩は「公共の場で大きな音を出している自分たち」の存在が周りに迷惑を与えているように感じるかもしれません。そんなことが何度か続くと、遊びに誘っても「今日はちょっと……」と断られるようになるかもしれません。

あー、そういうことだったのか。



４：作品のリアリティは登場人物のリアリティ。

いかに時代考証を重ねた歴史大作であっても、いかに分厚い設定資料で塗り固めたファンタジーであっても、登場人物の言動や思想にリアリティがなければ、作品としての魅力は損なわれてしまうように思います（その不自然さが読み手に対して独特の魅力や安心感を与える場合は別ですが）。

特に「作者にとって都合の良い展開に誘導するために、無理矢理キャラクターを動かすこと」で不自然さが生まれます。言うはずのないことを言い、取るはずのない行動を取る。物語がキャラクターを動かす状態です。

そうではなく、キャラクターが自発的に行動し、結果として物語が動く。作者の意思を超えて、登場人物が自分の意思で自分の人生を生きる。作者はただ必死に追いかけて物語の結末を見届ける。これが１つの理想と言えるのではないでしょうか。



おわり。

やはり私のブログの書き方は間違っている。

--- 背景 ---

３ヶ月ぶりにエントリーを書いたところ、明らかに読みにくい記事が出来上がってしまった。そこで、知人にお願いして、問題点と改善点を指摘してもらった。備忘録としてメモしておく。


--- 結論 ---

＊ターゲットと目的を明確にする。
＊情報の粒度を統一させる。
＊スマホでも見やすいUIにする。


--- 本題 ---

【問題点①】開いた瞬間にターゲットと目的が分からない。

記事自体が「企画を考えるときはターゲットを明確にしようね」的な内容を含んでいるにも関わらず、自分がその原則を遵守していなかった。

本来の意図としては「自分が企画を考える際のチェック項目をざっくりとまとめておこう」くらいの気持ちだった。だとしたら、「◯◯についてはきちんと考えていますか？」といった確認リストっぽい見せ方をした方が分かりやすい。


【問題点②】 情報の粒度が一貫していない。

用語の解説、具体例、実際に行うべき作業、ざっくりとした方向性。こういった異なる粒度の情報が、同じインデントで括られている。構成に一貫性がない。

事前に考えていなくても、短い文章であれば、書きながら情報構成を調整できる。同じような感覚で無策に情報を書き出してしまった。再発防止策としては、なるべく早い段階で情報設計を行うことだと思う。

※とはいえ書き出す前に設計するのもなかなか難しい。実際に書き始めてみて「用語解説」や「具体例」が必要だということが分かったら、その段階でストップ。無理に書き進めないで、これらの情報を他の情報と区別できるように書き直す。


 【問題点③】スマホだと読みにくい。

箇条書きの見せ方として、共通の情報のまとまりは、同じ幅だけインデントを下げた。結果、スマートフォンから閲覧すると、レイアウトが崩壊してしまっていた。

自分がPCで記述・閲覧することしか想定していなかったことが根本原因。UIとしては、問題外のミスだったと思う。以後、スマートフォンなど複数デバイスの画面サイズを想定したい。読み手に対して失礼すぎるなぁと反省。

※見出しレベル（いわゆるh1, h2, h3, h4, h5, h6）をどう見せるかという各論に絞ると、色や太さといったCSS装飾で区別できるようにするのが一般的な方法。あるいは、インデントを下げたいのなら、頭だけでなく文のブロック全体を下げると読みやすい。


おわり。


--- 結論（再掲） ---

＊ターゲットと目的を明確にする。
＊情報の粒度を統一させる。
＊スマホでも見やすいUIにする。


--- 補足 ---

そういえば、文章を書く仕事をしている友人に『良い文章を書くために心掛けること。』を聞いたことがあった。まず書いてみて、色々と改善を積み重ねるしかないのかもしれない。

新規サービス開発について学んだこと（１）企画

社畜生活の中で実践とインプットを繰り返しているので、ざっくりまとめます。Webサービス系の事業開発をどう進めていくか、そのために何が必要なのかという内容。全てが必須ではないし、ケースバイケースですが、思考の補助として参考になれば幸いです。

ただ、私自身がきちんとした知識・経験を有しているとは言い難いので、あくまでも現状で示すことができるMAXです。痛くて恥ずかしいミスをしているかもしれません。学習に合わせて加筆・修正を重ねるつもりです。

不十分な点があればご指摘いただけると幸いです。内容に限らず、文章が分かりにくいといったことでも結構です。Twitter（@yuzutas0）、Facebook、LINE、コメント欄、ブコメ、メール、直接会ったときなど、どんなツール・タイミングでも歓迎です。

アウトライン

1. 企画　←いまここ
2. 環境構築
3. モック
4. 開発
5. 運用
6. グロース＋その他

1. 企画（何をやるか）

1-1. 注目ポイント①：十分な市場があるか？

　　＊各種メディアやインタビュー記事で、市場動向は把握できる。
　　　　＊年末年始に日経新聞や東洋経済が出している雑誌の特集は分かりやすい。
　　　　＊スタートアップ企業のピッチや、流行サービスのネット記事も参考になる。
　　　　＊その他、カンファレンス/研究報告書/アナリストのコメントなど。

　　＊『ハイ・コンセプト』は、21世紀のマーケットチャンスを大まかに分類している。
　　　　＊物に溢れた時代：機能だけでなく、体験/意義/ストーリー性/人間関係に価値。
　　　　　　＊一方、まだ物不足の地域や人々もいる。そこでBOPといった観点が登場。
　　　　＊機械が人の仕事を奪う：共感や遊び心は人間にしかできない。
　　　　　　＊一方、ツールが定着しないケースも多い。機械を作るのもチャンス。
　　　　＊専門知識のコモディティ化：全体最適を判断できることが求められる。
　　　　　　＊例：優秀な医師は、知識量ではなく、患者の生活全体を踏まえた治療。
　　　　　　＊例：昔はその病気を治せるだけで価値だった。
　　　　　　＊一方：希少疾患の治療薬など、コモディティ化されていない知識は価値。

　　＊最終的には単なる計算。
　　　　＊市場シェアと顧客単価から参考となる利益を概算する。
　　　　　　＊大企業での新規事業立ち上げでは重視されている気がする。
　　　　　　＊ベンチャーでは後述のペルソナ/課題ベースが優遇される風潮かも。


1-2. 注目ポイント②：ターゲットと問題は明確か？

　　＊誰にソリューションを届けるのか。
　　　　＊具体的な人をイメージできるようにペルソナを特定する。
　　　　　　＊迷ったときはペルソナを踏まえて判断する。
　　　　　　＊例：２つのデザインのうち、この人はどっちを好むか？と問いかける。
　　　　＊具体的な手法は文献参照。
　　　　　　＊『UXデザイン入門』
　　　　　　　　＊調査：エスノグラフィー/インタビュー/観察/日記調査。
　　　　　　　　＊モデリング：行動変数/データマッピング/セグメント分け/文書化。
　　　　　　＊『スタートアップ・マニュアル』
　　　　　　　　＊デモグラフィック/サイコグラフィックを明示して文書化。
　　　　　　　　＊その人はどんな1日を送っているのか？
　　　　＊自分自身や身近な人の方が成功確率が高い。
　　　　　　＊ターゲットの特徴や背景を正確に把握できる。
　　　　　　＊調査や仮説検証を行いやすい。知らない人に頼むのはハードルが高い。
　　　　　　＊実際のソリューションを提供する際に、最初の利用者となってくれる。
　　
　　＊その人はどんな問題を抱えているのか。
　　　　＊問題に遭遇してから対処するまでのストーリーを把握する。
　　　　　　＊本気で対処していない問題は、そもそも解決する価値がない。
　　　　　　　　＊「あったらいいな」ではなく「なければ困る」を狙う。
　　　　　　　　＊「こんなサービスあったら面白そう」だと、結局使われない。 
　　　　　　＊参考：上記『スタートアップ・マニュアル』の課題認識度指標。
　　　　　　　　＊課題がある＜課題を自覚＜解決策を模索＜自前の解決策を既に保有。
　　　　＊具体的な手法は文献参照。
　　　　　　＊参考：上記『UXデザイン入門』や『スタートアップ・マニュアル』
　　　　　　＊参考：『Running Lean』の構造化インタビュー技法。
　　　　＊普段の生活の中で「誰がどんな問題を抱えているか」をメモすると良いかも。
　　　　　　＊例：新婚の友人と会話。
　　　　　　＊発見：夫婦の起床時間が違うとアラーム利用に抵抗感＝問題。

　　＊注意：ストーリーに別の人間が登場する場合。
　　　　＊実際にソリューションを利用するときには人間関係が鍵になる。
　　　　　　＊例：業務ツール：導入を決める人/予算を決める人/実際に使う人は別。
　　　　　　＊例：動画の共同編集：発案者/面倒臭がり/PCに疎い人で使い方が違う。
　　　　　　＊例：子供の受験教材：意思決定は母親/予算は父親/利用者は子供。
　　　　＊全関係者のペルソナを定める。
　　　　　　＊参考：上記『UXデザイン入門』
　　　　　　＊3種類のペルソナ：主役/脇役/黒衣。
　　　　＊人間関係図（組織図・顧客相関図）を書く。
　　　　　　＊参考：上記『スタートアップ・マニュアル』
　　　　　　＊営業ロードマップ
　　　　　　　　＊どの順番にどんな営業をすれば、サービスを使ってもらえるか。
　　　　　　＊ 顧客アーキタイプ
　　　　　　　　＊意思決定者/予算管理者/リコメンダ/インフルエンサ/エンドユーザ
　　　　　　＊顧客タイプ
　　　　　　　　＊初期評価者/エバンジェリスト/拡大期顧客/メインストリーム
　　　　　　　　＊これらに加えてアーリーアダプター。
　　　　　　　　　　＊不完全でもソリューションに価値を感じる顧客のこと。　　　　　　　　　　＊初期評価者（新技術に触れたいだけの人）より献身的。
　　　　　　　　　　＊エバンジェリスト（製品を広めてくれる人）より消極的。
　　　　　　　　　　＊参考：『リーン・スタートアップ』
　　　　＊影響関係を図示する。
　　　　　　＊参考：『ビジネスモデル・ジェネレーション ワークブック』
　　　　　　＊共感マップ
　　　　　　　　＊各ペルソナごとに作成。
　　　　　　　　＊インプット：外部から見たもの/聞いたもの。
　　　　　　　　＊アウトプット：外部に対する言動/態度。
　　　　　　　　＊影響結果：思考/感情⇒不（Pain）と欲（Gain）の発生・解消。
　　　　　　　　＊各ペルソナ間で、情報のやり取りと影響結果を図示。

　　＊その問題はどのように発生しているのか。
　　　　＊問題構造を分析する。
　　　　　　＊いわゆる科学的な思考体系があると良いかも。
　　　　　　　　＊学生時代の専門分野を初めとして、論文を読むと良いかも。
　　　　　　　　＊特定の問題の構造解説がなされている。
　　　　　　　　＊先行研究の要約として、解決アプローチが列挙されている。
　　　　　　　　＊私の場合はミクロ経済学を応用すると分析しやすいです。
　　　　　　＊色々なサービスを知る。
　　　　　　　　＊「誰の、どんな問題を、どう解決しているのか」に注目する。
　　　　　　＊普段から思考するクセをつける。
　　　　　　　　＊困ったことが起きたら最適解と再発防止策を模索する。
　　　　　　　　＊その過程で問題を分析する。
　　　　＊問題構造のどこをどう変えれば解決するか当たりをつける。
　　　　　　＊解決策に落とし込むには思考の飛躍が欲しいかも。
　　　　　　＊原則：新しいアイデアは、既存のアイデアの結合によって生まれる。
　　　　　　　　＊手法としては、いわゆるブレーンストーミングやKJ法。
　　　　　　　　＊さまざまなアイデアの引き出しを蓄えておいてそこから引き出す。


1-3. 注目ポイント③：競合はどうなっているか？

　　＊競合や既存の解決策が見つからない場合。
　　　　＊競合の捉え方が間違っているケース：誰の何が課題かを元にきちんと探す。
　　　　＊そもそも解決する価値がないケース：企画は却下。
　　　　＊解決したくても上手く解決できていないケース：理由を分析する。

　　＊既存の解決策・活動を置き換えるよう意識する。
　　　　＊ターゲットが時間やお金を費やすに値するサービスを作りたい。
　　　　　　＊「あったらいいな」ではなく「なければ困る」を狙う。
　　　　　　＊なければ困るのだから、ターゲットは何らかの対処法を既に持っている。
　　　　　　＊しかし、その対処法は完全ではないかもしれない。
　　　　　　＊だから、そこを置き換えるサービスを提供する。
　　　　＊最終的にはユーザーが時間を費やしたりお金を払うことになる。
　　　　　　＊そのお金や時間をどこから捻出してもらうのか。何を捨ててもらうのか。
　　　　　　＊前の解決策から新しい解決策に引っ越しをしてもらうのがスマート。

　　＊どのように既存の解決策を置き換えるか。
　　　　＊使いにくさ（Pain）を解決するか、良い点（Gain）をさらに伸ばす。
　　　　　　＊参考：『Value Proposition Canvasとは何か』
　　　　　　　　＊例：語学力を付けたいという課題。解決策は英会話学校。
　　　　　　　　＊Pain：英会話学校に通うのは大変。授業日時が固定で、生活に支障。
　　　　　　　　＊Replace：融通の効く時間設定ができれば良い⇒Skype英会話。
　　　　＊既存サービスに対して勝てそうな要素を探す。
　　　　　　＊参考：『ビジネスモデル・ジェネレーション』Business Model Canvas。
　　　　　　＊既存のソリューションがどのようなビジネスモデルなのか要素分解する。
　　　　　　＊9つの要素：顧客/関係/チャネル/解決/問題/パートナー/資源/収入/支出。
　　　　　　　　＊例：英会話学校。
　　　　　　　　＊Cost, Partner：日本国内だと外国人講師を雇うための人件費が高い。　　　　　　　　＊Replace：フィリピンなら人件費を抑えられる⇒Skype英会話。
　　　　　　＊1つでも要素を変えること＝イノベーション。
　　　　　　　　＊参考『イノベーションのジレンマ』
　　　　　　　　　　＊持続的イノベーション：業務最適化やツール導入による支出削減。
　　　　　　　　　　＊破壊的イノベーション：Skype英会話という解決モデル。

　　＊置き換えではなく模倣という手も……。
　　　　＊全く同じサービスを別の国や地域で行う（＝クローン市場）。
　　　　　　＊Business Model Canvasの要素「顧客」を変える。
　　　　　　＊顧客の違い＝文化や背景の違いに伴って、他の要素も調整する。
　　　　＊レッドオーシャン市場で戦う。
　　　　　　＊顧客フォローや丁寧な説明など、ちょっとした点で差別化する。
　　　　　　＊１人１人に対して最適化されたサービスを提供する。
　　　　＊自分の成功体験をベースにしてサービス化する。
　　　　　　＊例：友人に地元の美味しい料理屋を紹介した⇒地元民による紹介サイト。
　　　　　　＊例：文書管理のために自動化スクリプトを作る⇒業務ツールとして販売。
　　　　＊注意：他の地域も/他の人も、その問題を解決したいと思っているか。


1-4. 競合の補足：問題解決型、文化創出型、習慣型。

　　＊既存の活動（job）を置き換えるのが問題解決型サービス。
　　　　＊より良い解決方法があるなら、人間はそちらを利用する。
　　　　＊例：「速い馬が欲しい」＝「速く移動したい」⇒ 自動車の発明・普及。

　　＊映画やTV番組、ニコニコ動画といったサービスは文化創出型と言える。
　　　　＊問題/解決の対応や置き換えが見えにくい。
　　　　＊歴史的な文脈のもとで置き換えが起きている。
　　　　　　＊舞台での演劇（日時・場所が限定されてしまう）
　　　　　　＊映画館での映画鑑賞（日時・場所をクリア／周りが騒がしい）
　　　　　　＊自宅でのDVD鑑賞（プライベートを確保／人と共有したい）
　　　　　　＊ニコニコ動画（コンテンツを軸とした独自の盛り上がり）
　　　　＊文化や芸術、スポーツやエンターテイメントには歴史の流れがある。
　　　　　　＊興味のある分野を概観する書籍を読むと勉強になるかも。
　　　　　　＊メディア論や文化史といった人文科学で分析されている。
　　　　　　＊その分野の専門家/マニアは課題意識と改善アイデアを持っている。
 
　　＊ゲームやSNSのように、ついつい使ってしまう習慣型サービスもある。
　　　　＊見えにくいが、問題解決の構造は存在する。
　　　　　　＊例：Twitterではリアルの寂しさをオンライン交流で紛らわせる。
　　　　　　＊参考：『ツイッター創業物語』
　　　　＊問題解決の価値ではなく、習慣化の構造による成功が大きい。
　　　　　　＊参考：『Hooked』（未読・読んだら追記）
　　　　＊時間の観点では置き換えが起きている。
　　　　　　＊あるサイトやアプリをついつい開いてしまう。時間を費やしている。
　　　　　　＊時間を費やす対象が置き換わる。
　　　　　　　　＊例：mixiを開かなくなる代わりにFacebookを見る時間が増えた。
　　　　　　＊競合分析をもとにGain/Painを読み解けば、理屈は説明できる。
　　　　　　　　＊mixiで余計な機能がユーザー体験を害した…とか。
　　　　　　　　＊競合ベース、各論によるところが大きい。


1-5. 市場、ペルソナ/問題、競合分析の順番について

　　＊大企業は、市場を見てから小さく落とし込む傾向がある。
　　　　＊既存事業との親和性に価値を置くことがある。
　　　　＊始める前から「市場が小さそう」という理由で棄却することがある。
　　　　　　＊企画を通すために準備できることは全て準備する。
　　　　　　＊社内政治や準備のために非効率な時間を費やしてしまう懸念。

　　＊スタートアップとしては、ターゲット・問題から始めるのが望ましい。
　　　　＊まず問題の重要性について検証⇒解決策がきちんと機能するかを検証する。
　　　　＊検証の過程でどんどんビジネスプランは変わっていく。
　　　　＊最終的なプランについて、将来的に市場を獲得できるか検討する。
　　　　　　＊プラン自体が変わるので、最初から市場を見てもあまり意味がない。
　　　　　　＊何らかのリソース・強みを持っているなら市場ベースでもいいかも。
　　　　＊検証を終えた後で「市場が小さいから却下」という結論に至る悲劇。

　　＊競合分析は順序に関係なく重要。
　　　　＊他サービス：市場を理解するための足掛かりになる。
　　　　＊既存の解決策：問題を理解するための足掛かりになる。
　　　　＊文化創出型：歴史の流れから次のヒットを予測する。
　　　　＊習慣型：いま時間を費やしているものを置き換える。


1-6. アイデアを見える化する

　　＊取り組もうとしている事業をリーンキャンバスに記述する。
　　　　＊9つの要素：顧客/問題/解決策/チャネル/独自価値/計測指標/優位性/支出/収入
　　　　　　＊複数アイデアがあるときは複数を書く。
　　　　　　＊複数のユーザーで成り立つマルチサイドサービスの場合は全員分を書く。
　　　　　　＊なるべくシンプルに書く。複雑だと顧客や仲間にさえ理解されない。 
　　　　＊キャンバスは更新・修正されていく。
　　　　　　＊n周目の1枚目：事業モデルをまとめる。
　　　　　　＊n周目の2枚目：根拠となる要素の仮説を詰める。
　　　　　　＊n周目の3枚目：仮説を検証して結果を反映させる。
　　　　　　＊n+1周目の1枚目：新たな情報を元に練り直した事業モデル。
　　　　　　＊n+1周目の……。
　　　　＊参考：上記『Running Lean』

　　＊早い段階で検証できるものは検証しておく。
　　　　＊上記インタビュー等で顧客/課題の検証はできている状態だと望ましい。
　　　　＊解決策の方向性を検証するためにWebを利用すると早い。
　　　　　　＊例：ブログにアイデアを書いてみる。興味を持ってくれる人はいるか。
　　　　　　＊例：AdsenseやFacebook広告を出稿する。クリックする人はいるか。
　　　　　　＊例：ランディングページを公開する。メールを登録する人はいるか。
　　　　＊参考：上記『リーンスタートアップ』の仮説検証サイクル。
　　　　　　＊何を検証するか（仮説）＝キャンバスの要素。
　　　　　　＊どうやって検証するか（構築）＝サービス開発もここに入る。
　　　　　　＊結果はどうだったか（計測）
　　　　＊プロトタイプがないと検証できない要素が残る。
　　　　　　＊「MVP：検証のために必要な最小機能の製品」を開発する。
　　　　＊まずは全ての仮説検証を終えることを目指す。
　　　　　　＊その過程で実際のサービスをどんどん改善していく。
　　　　　　＊その過程で実際のユーザーや売上を獲得していく。
　　　　　　＊実際に使われるか、収益を得られるか、実践の中で検証する。


⇒「2. 環境構築」に続く。