コンサル一年目が学ぶこと
https://scrapbox.io/files/62a2c5acdb3ebd002336bddc.png
第1章 コンサル流話す技術
結論から話す
結論から端的に話すことで短い時間で相手に必要なことを伝える
PREPという型.Point:結論 → Reason:理由づけ → Example:具体例 → Point:結論の繰り返しで締める.
会議は結論から逆算して運営する
どのような結論を出したいのか
どのような段取りをするのが良いか
端的に話す
まずYes or Noで答える.その後に理由を付け加える.
Yes, Noで答えながら順番に深掘りしていくと,問題のありかがわかってきて生産的な話になることが多い
「分析グラフができていない件は何が問題なんだ?」
「グラフ化しようとしてもデータ自体に問題があって集計できないです.これを今直しています.」
「時間はどれぐらいかかるのか?」
「一週間ぐらいかかるかもしれません」
「一週間では困るので,別の人もヘルプさせるから,二日で仕上げられるか.」
無理のある相談が来たときはできる理由を伝える.
「はいできます.が,一人では無理なので手伝ってくれる人が一人必要です.」
数字というファクトで語る
他では得られない独自に集めた数字はとても有効.
世界共通言語は英語ではなく,論理と数字.論理があれば議論できる.
ローコンテキストなルールや基準だけを掲げて,論理と数字だけでコミュニケーションをする
日本では多様性の議論をする際に女性や外国人の活用のことばかりが論じられている.過去の価値観,もしくは新しい価値観に統一しようという考えが起こる.多様化が進んだ今は働き方も価値観も全く異なる人が同じ価値観に合わせるのは不可能だという前提に立った方が良いのではないか.
相手に理解してもらえるように話す
まず論理の組み立てを相手は何も知らないという前提で考える.自分の家族など,そのテーマが全わからない人に説明してみる.
相手の期待値を把握する
相手の期待を常に超えることがビジネスにおいて重要らしい.これは求められていないことに時間を費やしていらないおまけをつけることではない.
相手が何をどのレベルまで期待しているかを見極め,絶対に外さない.そして相手の期待値のちょっと上を常に達成していく.
期待値を満たせないものは安請け合いしない.時には相手の期待値を下げる.
上司の期待を超える
報連相の基本は,その前提として上司からの指示の内容を明確に把握すること.報連相の本当の目的は上司と部下が目的と内容について共通の理解を得ること.単なる情報共有のための報連相はあまり意味がないとこの本の著者は言う.
部下が上司から仕事を受ける時に確認すべきポイントは次の4つ
1. その仕事の背景や目的
2. 具体的な仕事の成果やイメージ
3. クオリティ
4. 優先順位・緊急度
多くの指示は曖昧.相手の指示の行間を自分で補ってみてそれを相手に確認してみる.
例:
「A社の新サービスにだけれども,まずはざっくり調べておいて.」
「ざっくりというのは,わたしなりに,①主なターゲット,②サービスの特徴と競合と差別化要因,③価格帯系,④提供体制その四つくらいあと思っていますが,それぞれ資料一枚,合計5枚ぐらいでまとめればいいでしょうか」(このとき枚数などを数字などで具体的に確認しておくことが重要)
項目数などを尋ねて求めているクオリティを把握する
曖昧であればお互いに明確にし,共通認識を持つ.
第1章を読んでみて
とりあえずアーキテクチャ図のタスクは相手の完成予想図のイメージをこちらで把握できていない.まずこちらでこのようなタイプでよろしいでしょうか?という提案をしてから具体的な完成イメージを共有してもらおう
文量
レイアウト
第2章 コンサル流思考術
作業を始める前に手順を考える
どのように考えたら答えが出るのかその道筋をまず考える.最終の成果物を見せて相手に納得してもらう前に手順の段階で合意をもらう.そのあと作業に入る
例:生徒を募集するためのマーケティングという提案書.
マーケティング活動の目的とゴールを確認して合意する
出願する生徒をエリアと偏差値に分け,どこの生徒がどこからやってきていて結果がどうなのかを分析する
合格者にも同様の分析をする.出身エリアと合格者入学率を分析し競合大学と比較.
全国の動向,競合の動向,貴学の動向の三つから入学者の減少原因を突き止める.その上で報告会を実施して今後の方針を検討.
今後ターゲットとすべきエリアや高校を決める.
以上を二ヶ月半で行う.費用は◯◯◯
ロジックツリーを使いこなす
一生使える基礎のテクニックらしい.
ロジックツリーが書けると議論の中の話が構造化出てきて,それぞれの話が全体の中でどのような位置付けなのかが頭の中で視覚化される.
取捨選択に役立つらしい.
意思決定のスピードが上がる.重要度の判断ができるから.
https://scrapbox.io/files/62b02c7a0260c7001d804863.png
痩せるにはという論点を分解して6つの論点に分解する.
あとはそれぞれの論点について数字の分析をして重み付けする
イシューからはじめよっていう本が良さげ
普段からいろんなことを分解してロジックツリーにする癖をつけるといいらしい.
ただし論理が正しくない場合にフィードバックがないと上達はないらしい・
雲雨傘提案の基本
事実,解釈,アクションを区別する.
事実だけではレポートではない.解釈がないグラフをいくら作ってもだから何なのかという解釈がないと問題を解くのには何も役立たない.
根拠がないのにアクションに持っていこうとするのもだめ.解釈に対するアクションは一つではない.その選択肢を選んだ根拠もセットで伝える.
事実,解釈,推奨アクションの三つの見出しをつける
仮説思考
はじめに仮説ありき
あらかじめ仮説を立てておくことで調べるべきポイントを絞り込めていれば効率的なリサーチができる.
リサーチはいつも仮説とセット.
リサーチは仮説に対しての検証を提示するもの.
仮説を持つということこは現時点での結論をあらかじめ用意しておくということ.つまり仮説を立てまくる->現実が起こる->仮説に沿って対応する
旅行の例:3日間の休みがあったらいくらでどこに行くか予算はいくらかをリストアップ->3日間の休みが実際にきた->リストから選択して即実行
常に自分の意見を持って情報にあたる
情報量を闇雲に増やしても無駄,重要なのは考えて自分の意見を持つこと.(痛いほどわかるなあ...今までいろんなすげー人のアカウントをフォローしてたけど地に足つけて自分の意見持つことが最も大事だと今は思ってる.)
情報に当たる時にまず考える.
「こだま新幹線の乗客が5年で7割増加」,なぜこだまなのか,乗客が増えた理由は何だろうか.経済の低迷で安い乗車賃のこだまの需要が増えたのか.などの意見を持ってから記事をクリック
本質を得よう
議事録
発言を列挙するんじゃなくて,決まったことを書く
決まらなかったことを書く
明確に簡潔に
議事録は発言録ではなく決定事項をかいて後日のための証拠に残すためのもの
最終成果物から逆算して作業プランを作る
スライドならタイトルと各項目の名称を書く
イベントならプログラムから書き始める
自分の制作は完成が見えないボトムアップ方式だから完成することがなかったなあ...今後はちゃんと完成予想から逆算していこう
最終成果物をまず作成するメリット
アウトプットのイメージが明確になる
必要な作業を洗い出すことができる
ワークプランができる
作業を切り出して複数人に依頼することができる
読書法について
基本的には
読書の目的を絞る,明確にする
目次を見て必要な章だけ読む
なるべく多くの文献を広く浅く当たる(?)
漫然と満遍なく読むではなく,読む目的を明確にして本を読む
今度から何が知りたいか考えてからよも.
目的の達成が重要.目的によって本の読み方は変わってくる.
この本で達成したい目的は簡潔で生産的な文章や議論をするためのメソッドが知りたい.
いつも闇雲にランダムにやっていくタイプなので目標が達成できないこと多々ある.計画を立てて着実に目標を達成できるコツを知りたい.
その他自分が社会人として欠けている常識を補いたい
まあ全部読むことになる
早く仕事を終わらせる
速度を上げるのではなく余計なことをやらない.
「20対80の法則」,組織全体のパフォーマンスの80%はトップ20%の人の働きによるとか何とか.つまり本当に重要な部分は20%.
何が大事なのか何がインパクトがあるこの七日を早めに見極めてそこだけに集中して議論する
ノーフォーカス(総花的)なのに細部にこだわるのは時間切れになって成果物が0になる.
心当たりしかない.以前の制作はどこにフォーカスを置くか決めていなかったがためにどれも中途半端になってしまっていた.映像,インターフェース,振動触覚フィードバック.そして細部にもこだわりたいと思っていた.重要なのはどれだよって話っすよね.
やらないことを決めるべき
スピードと質の両立
とにかく早く終わらせて仮説検証のサイクルを早く回す
初期のアプローチのまま完璧を目指そうとする.->方向が大きく間違っていれば時間を大幅にロスしてしまう.
失敗を開示せずに抱え込むとチームに迷惑をかけるリスクが一気に高まる.
60%まで終わらす->結果を即座に報告して方向転換,これを繰り返した方が効率が良い
システム設計演習の反省
まず小規模なプロトタイプを作るべきだった.
全体の理想が出来上がるまでやろうとしてしまったため最後までデバイスの選定ミスなど方向性を選ぶことができていなかった.
方向性のミスを一人で抱え込んで改良案を実験したがうまくいかず,チーム全体の遅れが出てしまった.
フォロワーシップ
リーダーの提案を理解し,リーダーの期待を考えて動く
主体性のないYESマンとは違う.