-
Notifications
You must be signed in to change notification settings - Fork 14
参考記事キュレーション【Biz系】
AIエンジニアは、技術的な内容も広く深く扱います。特に、コードの書き方や環境構築などで悩み、多くの時間を消費しがちです。
自分で数分・数十分、問題解決に努めてみて、打つ手がなくなったり何をやっているかわからなくなったときは、すぐにPM・メンバーに相談しましょう!
(DMでPMに聞くよりは、プロジェクトチームのチャンネルで報告することが望ましいです。他のプロジェクトメンバーも同じ問題に直面した時の助けになります)
A-2. 相談したら必ず結果を報告(重要度:高、難易度:低) [1]
何かしら相談したら、PMやメンバーが一緒に解決方法を考えてくれたり、すぐに詳細な回答をくれたりするかと思います。
その場合、悩み事がどうなったか、結果報告をするようにしましょう。 相談に乗ってくれた方は自分の作業時間を削って相談に乗ってくれています。結果報告と感謝を伝えることで、プロジェクト内のコミュニケーションが流動的になります。
(👍などのスタンプで終わらせるよりは、併せてスレッドにて「解決しました!ありがとうございました!」のように文章で感謝を伝える方が望ましいです)
クライアントの抱える問題解決などは解が無数にあり、プロジェクトメンバーは皆違う考え・ソリューションがあるはずです。
社内ミーティングなどのシチュエーションで、「〜さんはどう思いますか?」と言われた場合に、「ケースバイケースだからなんとも言えないです」や、「(本当は違う意見があるけど議論したくないから)〜さんと同じ考えです。」のような回答をするのは最悪です!
問題解決に限らず、ミーティング中やSlackで自分の考えは表に出して、積極的に議論しましょう!スタンスをとって自分の意見を表明することで、介在価値を生み出すことができ、結果的にプロジェクトでバリューを生み出すことに繋がります。
クライアントの抱える問題は複雑で、何をすればいいか、またそもそも何から解決すればいいかわからないまま相談されるケースがほとんどです。
AIコンサルではこのような問題の解決を引き受けるわけです。何が最善の解決策かは誰もわからないため、プロジェクトチームを組成して知恵を出し合い、解決に尽力します。
この「答えがない」ことを意識して業務に臨みましょう。以下の関連書籍はこのページでもこの先何度か引用していますが、興味のある方は購入して一読することをお勧めします。
AIコンサルでは、パワポスライドを作る機会は頻繁にあります。週1で進捗報告スライドを作るプロジェクトも少なくありません。
このようなクライアントに見せるスライドを作る際には、以下のようなことを意識して欲しいです。
-
論点を明確にし、その上でメッセージを言語化する
- 「何が言いたいんだっけ?」を整理する。
- その後、空のページを複数作り、そのページで言いたいことをテキストボックスなどでメモする。※
-
メッセージを支えるファクトを必要最低限注入する
- 検証内容・検証結果のサマリなどを1で書いたメモの下に付け加える
-
スライドのイメージを考える
- どのスライドフォーマットを使うか・どういう図を作るか・どういう文章構成にするかなどを考える。
- どうしたらメッセージが伝わるかを意識する。
-
スライド作成!
- ひたすらスライドを作る。
(※1、2、3ではパワポは開かず、NotionやWordでやり切るのもおすすめです。ここをパワポでやりきろうとすると途中でスライド作成に取り掛かったりしてしまって、「スライドで言いたいこと」がブレる恐れがあります。「スライド内容の整理(=NotionやWordでやるタスク)」と「スライド作成(=パワポでやるタスク)」を分けることで、結果的に良いスライドが早く完成したりします。)
A-6. 「クライアントの為に」の前に、「上司の為に」(重要度:中、難易度:中)[1]
プロジェクトではクライアントを第一に考えて日々のアウトプットを洗練させていきたいですが、入って間もないメンバーだと難しいこともあるかと思います。
PMと学生メンバーでは視座が違うため、プロジェクトに付加価値を付けづらくなりがちです。また、クライアント目線、プロジェクトで価値を出しているのは一番コミュニケーションをとっていて、チームを率いているPMです。
そのため、「自分でもできる仕事をPMから奪って、PMにはいかに彼らにしかできない部分(思考・インサイト)にフォーカスしてもらうか」という考えが大事になります。クライアントへ付加価値を付ける前に、まずは上司へ付加価値を付けることを始めましょう。
前述のように、プロジェクトは1つの「答え」が存在せず、無数にソリューションがあります。その際に「存在しない答え」に近づいていくためには、比較をするしかありません。絶対的な答えがないため、想定的に答えに近づくしかないのです。
何らかのアクションを起こす時は、2つ以上用意して、比較しましょう。比較して選ぶことで、「なぜそれを選ぶのか」を言語化できますし、より洗練されていきます。
問題の解決策や機械学習モデルなどはもちろん、提案スライドのフォーマットなどから「比較→選択」というプロセスを行うことで、経験則のようなものも身につき、あなたのアウトプットがどんどん洗練されていきます。
普段の生活から意識することも非常に有効です。比較する場面は、至る所にあるはずです。
(ex:試験勉強をしたい。大学の図書館で勉強するか、カフェで勉強するか、自宅で勉強するか。それぞれの効率性、周りの環境、時間の柔軟性、天気などの面から比較すると、今日は自宅で勉強するのが良さそうか、など)
B-1. 出席するからには何かしら発言する(重要度:高、難易度:高)[1]
クライアントとのミーティングに出席するからには、頑張って何かしら発言することを心がけましょう。クライアントからしたら、あなたは一人前のAIエンジニアであり、高い期待をされています。また、ミーティングの時間も報酬金が発生しています。
言うことが思いつかなかったら、「(zoomミーティング時に誰よりも早く)お世話になっております、よろしくお願いいたします」と発言するなど、些細なことから心がけていきましょう!
B-2. 議事録を積極的に取る(重要度:高、難易度:中) [1]
「発言しましょう」とは言ったものの、最初からプロジェクトを前進させる、中身のある発言をするのは難しいかと思います。
ミーティング時は、特に自分が発言していない時に、積極的に議事録をとるようにしましょう。AIコンサルでは、Notionを使って議事録をとることが多くなるかと思います。
議事録をとる目的としては、以下のようなものが挙げられます。
-
(プロジェクトメンバーのアウトプットに対する)先方からのフィードバックを記録する
- 発言の記録の例:「ooさん)いいですね!」「xxさん)ここの精度をもう少し上げてほしい」など
-
先方の温度感を記録する
- 温度感の記録の例:「ooさんが技術的内容まで興味がある様子」「xxさんが怪訝な顔をしていた」など
-
欠席者が後から見返してキャッチアップする
- 休んだ人が後からどんな会議内容だったか把握できるものにする
- 前述の、先方の温度感なども欠席者が把握できるとベスト
-
ミーティング中の自分の思考整理
- どんな流れでミーティングが進んでいるのか、弊社側のコンテンツに漏れはないか、整理できる
議事録をかける人は、プロジェクト内でも重宝されます。他のメンバーの議事録取りを奪う勢いで、積極的に書きましょう!
ミーティング中は、ファシリテータ(司会者)への協力を心がけましょう。
- zoomでは画面をonにする
- (クライアントミーティングで)zoom上の自分の名前の最後に「_{会社名}」をつける
- 適宜、相槌を打つ・頷く
- etc…
ミーティングの雰囲気を良いものにしたり、本質的なことのみを会議で話すためにも、まずはこのような些細なことから始めましょう!
B-4. 質問回答ではまず論点に答える(重要度:高、難易度:中) [1]
クライアントから今週の進捗に関しての質問をもらったら、要点を押さえた、非エンジニアでも理解できる回答をする必要があります。
質問回答が苦手な方は多いと思います。特に、自分のアウトプットに自信がない場合や相手の質問を理解できなかった場合などは、背景ややったことをつらつら述べる脈絡のない話し方になり、結果的にクライアントの質問の回答になっていない、というケースも多いです。
クライアントミーティングに限らず、Yes/Noで答えられる質問にはまず「回答」して、必要に応じて後から背景だったり意図を装飾しましょう。
「(Yes/No質問)ですか?」→「(回答)です。(補足)」
また、言いたいことが2つ以上ある場合は、「構造」が主役の話し方が有効です。
質問:「趣味は何ですか?」
NG:「〜と〜と〜です。〜は…で、〜は…です。〜は、…です。」
OK:「大きく3つあって、
1つ目は〜で、…です。
2つ目は〜で、…です。
3つ目は〜で、…です。」
社内のミーティングなどから構造化した話し方を意識すると、外部ミーティングなどでも自然と話し方が整うようになります。
B-5. 平常時よりテンションを少し上げる(重要度:中、難易度:中) [1]
経験の浅いエンジニアの場合、付加価値を出すのに苦戦することもあるかと思います。そのような場合に「僕なんて」といじけるのではなく、「未熟さ」を「チャーム」でカバーする技術を持っておきましょう。
最も威力を発揮しやすいものは、「平常時よりもテンションを上げる」ことです。クライアントミーティングや社内ミーティングでは、つまらなそうな顔=絶対悪です。クライアントやメンバーのテンションが下がったら、プロジェクトの雰囲気も悪化していきます。明るくいきましょう!
テンションを上げる際、私は発言の語尾に「っ」と「!」をつけることを心がけています。
- ex:「承知しました」→「承知しましたっ!」
気持ち1つで変わる部分でもあるので、まずは社内ミーティングから使っていきましょう!
聞いたことのある方の方が多いかと思いますが、報告・連絡・相談のことです。
チーム間でのコミュニケーションおよび、クライアントとのコミュニケーションの核になります。これを怠ると、プロジェクトの炎上や、メンバーからの信頼の失墜につながってしまいます。
ただ単に「報告と連絡と相談をすればいい」というわけではなく、その方法も奥深いものがあります。日々の生活から意識しだしたり、本ページで紹介しているビジネス本などで学び、ホウレンソウを身につけていきましょう!
C-2. ホウレンソウによって期待できる価値 [1]
ホウレンソウを適切に行うことで、以下のようなことが期待できます。
-
仕事の手戻りを減らす
-
クライアントはアウトプットのイメージがあるが、言語化されていないことがほとんどです。また、そのイメージは時間とともに変化することも多々あります。
→依頼される側・依頼する側が双方細かくホウレンソウを行うことで、認識を合わせることができます
-
-
先輩や上司からの信頼を得る
-
ホウレンソウができないと、上司からの信頼が失墜してしまいます。
- 信頼=期待と安心
-
以下の2人のメンバーがいたとします。
- Aさん:「アウトプットは普通だがホウレンソウができる人」
- Bさん:「アウトプットは質が高いことがあるがホウレンソウがなく当日までアウトプットがわからない人」
→PMからすると、Aさんの方が一緒に働く上で安心できますし、成長を期待します。
-
目安として、PMなどの上司から「あの件どうなりました」と聞かれたらゲームオーバー、という意識をするといいかと思います。
- 「あれどうなりました?」→「期待していたタイミングより遅いんだけど、大丈夫ですか?」
- その仕事を120%のクオリティでやっていたとしても、ポイントになりません。
-
-
重大なトラブルを防止する
- トラブル=期限に対して手段がなくなることです。
- 大概のものは早く対処できればトラブルにならないので、小さいトラブルでも話に出すことがとても大切です
- あなたがホウレンソウを怠ったことでトラブルが対処不可能なほどにまで大きくなったら、プロジェクトの炎上・信頼の失墜に直結してしまいます。
理想のホンレンソウのタイミング・内容はプロジェクトによるかとは思いますが、一般的に以下のようなものが良いとされるかと思います。
-
タイミング:
-
細かいほどいいです。細かく報告・連絡・相談がきて、鬱陶しいと思う上司はほぼいません。「しつこい!もういい!」と言われるレベルまで行う意識が大切です。
- 1タスク終わったら
- 10分悩んだら
など
-
-
内容:
- 空雨傘(=事実→解釈→行動がストーリーで示されているもの)が表現されると良いです。
- ただ「わかりません!」と聞いたら、コミュニケーション工数を余計に増やしてしまいます。
- 自分が何を・なぜやったか・その結果がどうだったか、を伝えましょう。
- 「xxxを疑ってyyyをやったんですが,zzzでした」
- 自分が何を・なぜやったか・その結果がどうだったか、を伝えましょう。
A-1. 新規事業を生み出すステップ[3]
新規事業を生み出すためには、「1. 気付く・思いつく」→「2. 練り上げる」→「3. 踏み出す」という3ステップが必要になります。また、各ステップで異なる”調査”が必要になります。
-
気付く・思いつく
アイディアが全ての領域です。「それ面白い?」「やる価値ある?」という問いに常に向き合う必要があります。ここでは、”刺激物”としての調査が必要になります。(次セクションの”浴びる”調査に該当)
-
練り上げる
ファクトが全ての領域です。Why?How?So What?という問いに常に向き合います。ここでは、”仮説検証”のための調査が必要になります。(次セクションの”磨く”調査に該当)
-
踏み出す
調査しただけではどうにもなりません。価値やお金を生み出すために、アクションをする必要があります。ここでも調査が必要になります(=”やる”ための調査、次セクションの”口説く”調査に該当)
A-2. 新規事業における”調査”の使い分け[3]
前述の通り、調査にも様々あり、フェーズによって使い分ける必要があります。
そもそもの仮説がない場合
→ ”浴びる”ための調査
仮説はあるが、検証に使えるプロダクトがない場合
→ ”磨く”ための調査
そもそも必要な仮説検証の粒度がわからない場合
→ ”口説く”ための調査
B-1. 浴びるべき情報とはどんなものか[3]
普段私たちは、共通言語としてのメディアに触れがちです(例えば、キー局の番組、ゴールデン帯の番組、バズっている漫画・アニメなど)。
これらの「みんな知っていて当たり前」のメディアで終わらず、「マイナーなドメインでの当たり前・トレンド」を追いましょう!例えば、深夜番組やAbemaTVや昭和のマイナーなテーマの漫画などを見るなどは有効です。
B-2. 知識ベースを一気に高めよう(重要度:高、難易度:中)[3]
もし自分・自社とは遠い領域に乗り出そうとする場合、以下のような方法で知識ベースを高めることが有効です。
-
書籍を10冊ほど買って2日で読む
業界の原理・構造・トレンドに関する情報を網羅的に得るには、書籍が優れています。目次を熟読→中身を拾い読み→中身を熟読、のような流れで読むとおすすめです。
-
業界専門誌を1年分取り寄せて読む
「まさに今の情報」であれば、業界専門誌もかなりおすすめです。何が最先端なのか、最近のテーマ・関心ごとは何なのか、を知るのに優れています。1年分買って順に読むことで、トレンドを予測する力も自然とついていくはずです。
-
Webで専門メディア記事を読む
今すぐ情報を得たいといった場合は、Webの記事もやはりおすすです。ただ、内容の信憑性などは注視する必要があるため、数十記事ほど広く浅く読んで、自分の中のイメージを固めましょう。
そのほかにも、やはり現代ではSNSを調査に活かさない手はありません。意見・事実を言葉で理解するにはTwitter、視覚で理解するにはYoutubeなどが有効です。また、エキスパートのナレッジを知るには、QuoraやYahoo知恵袋などの活用も有効です。
B-3. 調べた後も考え続けよう(重要度:高、難易度:中)[3]
調べたらそこで終わらず、仮説を作っていくこと、磨いていくことを目指して、「タテ・ヨコ・ナナメ」に思考を展開していきましょう。
-
タテ:
- 上:構造や仕組みを考える
- Why?So What?の思考
- 下:要素や具体を考える
- Who?Where?How?などの思考
- 上:構造や仕組みを考える
-
ヨコ:
- 類似のものを考える
- What Else?の思考
- 類似のものを考える
-
ナナメ:
- 別の次元・切り口を考える
- What if?の思考
- 別の次元・切り口を考える
C-1. その領域のエキスパートに壁打ちしよう(重要度:高、難易度:中)[3]
巨人の肩に乗ることで、健闘の速度と深度を上げましょう。その際、漠然と話を聞くのではなく、仮説のベースにある事実の成否判定・Not Yetの背景理解を行いましょう。
-
意見は聞かない:
-
「〜について、どう思いますか?」
-
「〜の未来について、どう考えていますか?」
などは、聞かない!
-
-
事実を聞く:
- 数字で聞く→金額、割合、人数
- 行動で聞く→Aということが起きているとして、その前後で何が起きるのか
- 仮定で聞く→「もし〜だったとして、どう行動・判断しますか?」など
C-2. その領域の素人にインタビューしよう(重要度:高、難易度:中)[3]
新規事業やサービスに関して磨けてきたら、”そもそも”を問うてくれる、Non-エキスパートと話をしましょう。様々な観点から自分の考えを見つめ直して、観点をフラットに保つことが大事です
C-3. 頭で考える前に足で考える(重要度:中、難易度:高)[3]
磨くこと=思考すること・分析することです。違う領域の文化を内部化するために、現場に行ってその空気を吸うことは大事です。
例:
- 外食向けのSaaSを作りたい→毎日外食して店内観察
- 10代向けの動画SNSを作りたい→親戚・街中の10代のSNS利用を観察
AI系のプロジェクトの場合はそこまで行動することは難しいかもしれませんが、関連領域のフリーで落ちているデータを入手→眺めたり分析してインサイトを得る、その領域の権威のブログを読み漁る、などは有効かもしれません。
D-1. 口説き基準の理解・設定を行おう(重要度:高、難易度:高)[3]
調査の目的は、「製品・サービスをつくらせてもらうことを承認してもらう・邪魔しないでもらう」ことです。
-
これ絶対成功するの?と聞いてくる上司がいたら:
- 心の声
- 「できないでしょ」「失敗した時の責任転嫁でしょ」
- 質問の変換+ガンジーマインド
- 「調べ切ったか?考え切ったのか?」という質問に変換→その体で回答する
- 「あなたと一緒に成し遂げるのです」と口説く
- 心の声
-
現場では難しそうな事業立案を求められたら:
- 心の声
- 「簡単に言わないでくれよ」
- 試算マインド→シミュレーションマインド
- 「達成できるかどうか」を解くのではなく、「達成するためにいじれるレバーは何で、その水準はどの程度か」を考える
- 売上・コストの因数分解→各因数の仮定+ファクトチェック→モデリングを行う
- 心の声
D-2. アウトプットを先に握ろう(重要度:高、難易度:中)[3]
調査をして、終わってからどうまとめるかを考えるようでは手遅れです。「どんなレポート・上申書が作れれば上司・組織が動くのか」を前提に、調査で”埋める”ように逆引きで動きましょう。
D-3. 浴びる・磨くを繰り返そう(重要度:高、難易度:中)[3]
口説くことができなかったら、再び浴びるための調査・磨くための調査に戻りましょう。
自分・チームが何をやろうとしているのか、やるべきなのかを意識して、調査をまとめる時には「So What?(だから?何が言えるの?)」を常に意識して、調査のサイクルを回していきましょう。
A-1. 示唆とは [2]
示唆とは、ファクトから言える事柄のことです。皆様には、ファクトから示唆を抽出するスキルをぜひ身につけていただきたいです。
AIコンサルの業務では、「ファクト」は「AI技術を用いた検証の結果」であることが多いかと思います。ここでPMやクライアントに報告する際、ファクトのまま報告するのはやめましょう。ファクトだけを提供されても、「だから何?」という反応になります(PMであれば一緒に示唆の抽出に乗ってくれるかもしれませんが)。
示唆を使いこなすことができれば、「答え」のない問題解決のプロジェクトでも有利に戦うことができるでしょう。
A-2. 示唆ができるようになるためのTips [2]
示唆を身につけるために、以下の2つを行うことがおすすめです
-
「何が言えるっけ?」を口癖にする
- グラフや文章など、ファクトを見た時、「何が言えるっけ?」と頭の中で唱えると、示唆につながりやすくなります。
- ex)
-
ファクト:女の子が髪を切った。
→何が言えそう?
-
示唆:失恋した・運動をはじめた・etc…
-
- ex)
これを習慣付けると、示唆を抽出する意識が定着するはずです。
- グラフや文章など、ファクトを見た時、「何が言えるっけ?」と頭の中で唱えると、示唆につながりやすくなります。
-
「にもかかわらず」を使いこなす
- 示唆には必ず対比が存在します。言い換えると、対比が存在しない示唆は、ただの感想になってしまいます。
- 対比を考える上では、以下の構文がおすすめです。
- 「xxxにもかかわらず、oooということは+++に違いない」
- xxx=常識・知識・ファクト
- ooo=ファクト
- +++=示唆
- ex)
- 「Aさんとか他の人らは2年で昇進するのが基本にもかかわらず、Bさんは1年3ヶ月で昇進したということは、Bさんは優秀であるに違いない」
- 常識・知識・ファクト=Aさんや他は2年で昇進
- ファクト=Bさんは1年3ヶ月で昇進
- 示唆=Bさんは優秀であるに違いない
- 「Aさんとか他の人らは2年で昇進するのが基本にもかかわらず、Bさんは1年3ヶ月で昇進したということは、Bさんは優秀であるに違いない」
- 「xxxにもかかわらず、oooということは+++に違いない」
このような思考をすることで、示唆の抽出過程が言語化されます。
ビジネス系の本を買ったことがある人などは、「論点思考」「仮説思考」などという言葉を聞いたことがあるかもしれません。これらは主にコンサルタントがよく使う思考法です。AI系のプロジェクトはかなりコンサル色が強く、これらの思考法がマッチしています。
論点とは、解決する必要のある課題(issue)や、そもそもプロジェクトを行う目的であり、「〜か?」のような問いの形をとります。論点は「答えるべき問い」とも言い換えることができ、答えがでない・答えるべきでないものは論点とは言えません。
論点は業務のはじめに設計するものであり、論点がないまま手を動かしても期待されたアウトプットはうまく出せません。
良い論点は、以下のような特徴を持っています。特に、最初の2つは重要です。
-
必ず答えを出すことができる
- 前述の通り、論点とは「答えるべき問い」であり、必ず答えの出る必要があります。
-
2つ以上作って比較できる
- 複数の論点を比較・選択することで、よりアウトプットを作り出すことができます
-
MECEになっている
- 論点は、「漏れがなく、ダブりがない」と、全体像を捉えやすくなります。
- ただし、MECEにすることが目的ではないため、意識しすぎて時間を浪費する必要はありません。
-
構造化されている
- 以下のように構造化された論点ツリーができると、メンバー間で認識を合わせやすかったり、論点の比較がしやすくなります。
論点を設計する際は、以下のことを心がけましょう。
-
常に問う姿勢を持ち続ける(難易度:低、重要度:高)
- 論点設計で困った場合は、「そもそも何を決めたいんだっけ?」「そもそもこの作業って何のためだっけ?」など、「そもそも」というキーワードを用いて客観視することが有効です。
-
プロジェクトメンバーと議論をする(難易度:中、重要度:高)
- プロジェクトの大半は複数人で回すものであり、違う考え・論点の種を持っている仲間がいます。論点を提起して議論することで、論点の共有・アップデートができ、最終的により良いアウトプットに繋がります。
-
論点ツリーのフォーマットを用意して、論点を埋めていく(難易度:中、重要度:中)
- 論点ツリーを用いることで、構造を意識しながら論点を設計することができます。
- また、具体化されていて、一貫性を保った論点を作りやすいです。
- 論点ツリーができたら、ぜひプロジェクトメンバーに共有してみて、意見を聞いてみましょう。
- 論点ツリーを用いることで、構造を意識しながら論点を設計することができます。
仮説とは、論点に対する仮の答えです。仮説を設計する際は、「〜となっている」や「〜である」など、「言い切ってしまう」ことが重要です。
仮説はその時点で考える「確からしい答え」であり、必ずしも正しいとは限りません。仮説は検証と再設計を繰り返して進化するものです。「なぜ?」「本当?」と常に考える姿勢が重要になります。
仮説を立てることで初めて、具体的な検証などのアクションに繋がります。仮説がないと、検証内容の明確化を行うとができません。逆に言えば、仮説は検証しなければただの絵空事です。検証して正しさを確かめることで、仮説を立てた意味が生まれます。
「良い仮説」とは、以下のような特徴を持っていることが多いです。
-
具体的で現場感がある
- 関係者であれば誰もが思いつくようなものは、仮説としては不十分です。現場の
-
アクションにつながる
- 関係者があなたの設計した仮説を見たら、「ああ、この人は次はこれをやるんだな」と想像できるような仮説が理想です。仮説を設計しても、「それで、どうするの?」と言われてしまったらその仮説は修正が必要です。
-
検証できる
- 仮説は必ず検証する必要があります。一見素晴らしい仮説を設計しても、検証ができなければ意味はありません。
常に上記の3条件を確認して、プロジェクトメンバーと議論もできると、仮説が進化していき、経験により洗練されていきます。
仮説設計で詰まったら、以下のことを意識してみましょう。
-
今とは反対側の視点から見てみる(難易度:中、重要度:中)
- 自分が依頼される側であれば依頼する側の視点を、消費者であれば生産側の視点を意識することで、現在の仮説の問題点が浮かび、相手を納得させられる仮説を立てやすくなります。
-
両極端に振って考える(難易度:低、重要度:中)
- 両極端に振ったり、逆を考えたりすることで、自分のスタンスが生まれやすくなります。
- ex)
- 高単価x少量販売 / 低単価x大量販売
- 完全に自動化できるもの / 全くできないもの
- ex)
- 両極端に振ったり、逆を考えたりすることで、自分のスタンスが生まれやすくなります。
-
ゼロベースで考える(難易度:低、重要度:中)
- 両極端に振るTipsと近いですが、「そもそもChatGPTがなかったら?」「理想だけで言うと何?」のように、ゼロの状態から検討し直すことも有効です。
-
[1][コンサルが「最初の3年間」で学ぶコト 知らないと一生後悔する99のスキルと5の挑戦
- コンサルが3年間で身につける思考・作法について、読みやすい「VS」形式で解説されている。松尾研の共同研究プロジェクトにもすぐ応用できる内容となっている。
-
- 問題解決の思考について解説されている。「答えのないゲーム」である共同研究プロジェクトにおいて、どのようなプロセスで良い示唆・仮説を導き出すか、本を通して学べる。
-
[3][新規事業を加速させるリサーチ術〜説得力を生み出すための情報収集方法とは〜
- 新規事業開発におけるリサーチ術について、BCGの戦略コンサルやスタートアップの執行役員を経て活躍する田中志さんが作成されたスライド