コンサルじゃないけど『コンサル一年目が学ぶこと』を読んだ
Amazon Readingで読めるビジネス書で、評価の高かった本を読んでみました。コンサルに関わらず、どの業界でも使える仕事の基礎みたいな内容です。
著者
外資コンサルで働く大石哲之氏が執筆されています。自身の経験に加え、実際にコンサルタントとして働いた経験を持つ方々からの取材と議論によって内容を推敲されているようです。
本書の他にもロジカルシンキング系の本を執筆されています。調べてみるとブロックチェーン関連の著書や取材記事も見つかったので、ITやFintech分野に精通しているのかもしれません。ですが本書ではITに関わらず、広く一般に通じるような内容が取り上げられています。
概要
大きく４つの技能を章に分けて紹介し、その実例や細かいtipsを説明する形で記述されています。ざっくりまとめた内容は以下です。
話す技術
- 結論から、端的に話す。YES/NOで答えられるものはまず答え、その後に理由を述べて問題の所在を明らかにする。
- ファクト（数字と論理）で語る。論理と数字は共通の言語であり、どんな人間にも通じるローコンテキストな基準である。
- 相手に理解してもらえるように話す。相手は無知識であることを前提とし、適宜反応を見ながら最も伝わりやすい（相手に合わせた）方法/形式で伝える。
- 相手の期待値を把握する。意思疎通しながら期待値を推し量り、無理な要求は退けながらも、常に期待値を超えた成果物を出す。
思考術
- 手順を考えてから着手する。作業全体の道筋を考えてから関係者に合意を取り、手順に基づいて細部の作業を進める。
- ロジックツリーを使用して対象を分析する。論点を分解した後に数値による分析を行い、重み付けをして次に取るアクションを決める。
- 提案するときは事実・解釈(仮説)・行動を区別して説明する。
- 仮説→検証→フィードバックのサイクルで仮説の確からしさを証明し、意思決定に繋げる。そのために、常に考えながら情報に触れる（単に情報量を増やすという策を取らない）。
デスクワーク技術
- 議事録は決定事項、確認事項、次に持ち越すこと、次までにやることを明確にする。
- 説明資料作成時は、根拠となる事実＋解釈が１セットとなるようにする。特にパワポは1スライド1メッセージを守る。
- PCやツールの操作速度を上げる。ショーカットなどで作業速度を上げることで、思考に費やせる時間を増やす。
- 重要な部分を見極め、残りを捨てる。情報収集や検討などは、重要だと思われた箇所について深く実施する。
- 課題管理をする。直面している課題を共有し、役割と期限を決めてプロジェクトを進める。
プロフェッショナル・ビジネスマインド
- 相手（顧客や会社）に価値を提供する。相手にとって価値があると思わなければ自己満足である。
- 自分には金銭的コストがかかっていることを自覚する。会議で発言しない、休憩時間を余分に取る等の行為はプロとして不適切である。
- 拙速は巧遅に勝る。完璧なものを時間を掛けて提出せず、大まかな成果物を早く出し、改善するサイクルを回す。
- （頑張りや評価ではなく）仕事の成果に対してコミットする。顧客を起点とし、約束を果たすことを最優先として行動する。
- 「こうなりたい」と思える人物を見つけ、徹底的に真似る。
- リーダーの指針に積極的に賛同し、周りに行動を促すフォロワーシップを発揮する。
- 他とは違う役割を果たしながらチームに貢献する。チームワークとは分業であり、自分の今の能力でチームに貢献できる方法を考える。
要点
要点と感じた部分について書きます。
期待値をコントロールしつつ、超えていく
自分が真っ先に「あ、これはできてないな。。」と感じた部分です。なんやかんやでコンサルは社会的に信頼度の高い業種であり、評価と高給を得ている理由とされる部分ではないかと思います。無理な要求はきっぱり断りながらも、相手の期待値をコントロールし、成果としてはそれを超えるように働く。そのためには、
- 仕事の目的
- 成果のイメージ
- クオリティ
- 優先順位（緊急度）
を確認することが良いと述べられています。（これは指示を出す側も意識しておくべき）
相手が明確なイメージを持っていない場合は、2章で述べられている仮説・検証で成果物のすり合わせをすることになります。
仮説ドリブンで動く
第二章は参考になる部分が多かったのですが、全体としては「仮説」がより重要であるように感じました。仕事の手順を考えるのも、解釈から行動を提案するのも、すべて仮説がなければ始まりません。（人は大なり小なり先のことを予測しながら生きていると思うので）
この「仮説を立てる」という行為、学生時代では研究で当たり前にやってきたのに、仕事となると「とりあえず動く」みたいな行動をとりがちな気がします。おそらく納期などの外部要因がそうさせるのだと思いますが、結果的にどちらが早く仕事が終わるのかは明らかでしょう。
20:80の法則を意識する
物事は20%の本質部分を抑えれば、80%の効果を出せるという法則です。元は経済学の用語ですが、「重要な部分以外は切り捨てる」という思考はこれを元にしています。あらゆる業務（特にソフトウェア開発）についてこれが有効かは不明ですが、少なくとも対人折衝的な業務においての資料作成、情報収集には当てはまりそうです。
自分の得意分野で価値を提供する
「チームワークとは分業である」という主張にハッとさせられました。ソフトウェア開発において、誰かがいなくても代えが効くようにプロセス設計されていることが多いですが、「全く同じ役割を担う者は二人もいらない」と本書で述べられています。そのチーム内で、どのように価値を出すかを自分の得意分野と相談しながら考えることが大切だそうです。場合によって、それは「高い設計能力」かもしれないし、「誰からも好かれる人当たりの良さ」かもしれません。大事なことは、価値を出せるなら手段は何でもよいということです。
実践
今日から実践したいことを書きます。
考察しながら情報に触れる
仮説ドリブンや20:80の法則を実践するためには、「すぐに仮説を立てる」ことや「重要な部分を素早く見つけ出す」ことが求められます。そのためには日頃から多くの情報に触れ、そこから意味のある考察をし続けることが重要だと思いました。
とりあえず身近な例として、
- Twitterで見つけたニュースの見出しに対して、背景や原因を考えてから記事を開く
- 広告やCMなど、そのデザインやメッセージに至った背景を考える
みたいなことから始めます。
まとめ
典型的なザ・ビジネス書みたいな内容でしたが、やはり仕事の進め方的な部分でコンサルの方から学ぶことは多いと感じました。本書で取材元とされた方々の経歴を見ても、やはり一般的に優秀であることは疑いようのない事実です。（あくまで一般的に見てですが）
コンサルの言うことを鵜呑みにして無茶な主張をする上司の気持ちも少しはわかｒ…いややっぱわかんねえな…いつかわかるようになるのかな…
