読書レポート #6 『BCGの特訓 成長し続ける人材を生む徒弟制』
本の選定理由
読書レポートを過去5回にわたって書いてきたが、いわゆる"●●の会社のやり方"という本を読んでないことに気づいた。
このことから、"超大手企業のやり方"の本を読んでみたいと思うようになった。そんな中で本屋を巡ったところ、今回読むことになった「BCGの特訓 成長し続ける人材を生む徒弟制」を発見した。
BCGというのは「Boston Consulting Group」の略である。BCGは1963年にアメリカのボストンで創業された経営戦略コンサルティング会社である。現在の経営戦略コンサルティング業界において"BIG3"と呼ばれる会社の一角である(あと2つはマッキンゼーとベイン)。
BCGの顧客の多くが大手企業である。そんな彼らの経営の方向性を決める重要なプロセスを担う彼らはまさしく"超大手企業"といってよいだろう。
こうした経緯からこの本に興味を持ち、今回読んでレポートを書くに至った。
この本の概要
BCGの「多様な人材を超高速で戦力化する技術」
現在の世の中の流れはより流動的になり、経営の複雑性が増している。
この結果、世の中に素早く対応できる人材は希少性を増している。
いわゆる頭数としての人はいても、"今の世で使える人材"は貴重になっている。
人がいないなら育てるという発想ももちろんあるわけだが、経営資源のない会社の場合は「すでにいる社内人材でやった方が速い」という結論に達してしまうため、育成まで手が回らないのである。
多くの人が想像するとおり、クライアントはBCGに非常に高い成果を要求する。このため、BCGは高い成果を出す人材をクライアントに充て続ける必要がある。成果を出せなければ自身と会社が回らなくなる上にクライアントへの損害も出てしまう。にもかかわらずBCGはクライアントの期待に応え続けてきた。すなわち、BCGは高い成果を出す人材を輩出し続けられていることがいえる。優秀な人が入社していることはもちろんだが、人を育てることに長けた環境であることも伺える。こうしたこともあり、BCGはクライアントから"自社メンバーの育成"を依頼されるという。
コンサルタントのスキルのひとつとして"ハウツー"のスキルがある。分析ツールの使い方・ロジカルシンキングの方法・プレゼンスキル・交渉方法…といったものが挙げられる。こうしたスキルはコンサルタントの必須スキルであるが、よいコンサルタントの必要条件なだけで十分条件ではない。
この"十分条件"の内容については後の章で解説する。
1 スキルを集めるだけでは成長しない
筆者いわく「スキルマニア」は要注意だという。
スキルマニアというのは、資格取得に代表されるスキル習得を目的とした行動を行う人のことである。彼らは会社の行き帰りや休日といった自由時間にセミナーに行っていたり資格の勉強をしている。一見仕事ができそうに見えるが、成果に対する貢献度は低いことが多いという。
スキルマニアには2種類あるとされる。ひとつは「コレクション型」、もうひとつは「突き詰め型」である。コレクション型はコンサルタントに必要そうな能力を資格取得という形で獲得することを望んでいる。先述したハウツーのスキルを証明する資格（MS-Officeマスター、簿記2級、応用情報技術者…etc）はその恰好の対象である。 突き詰め型は特定のスキルを極めることで代えがたい存在となり、周りから重宝されることを望んでいる。
チェックボックス・メンタリティ
スキルマニアの心理の根幹として「チェックボックス・メンタリティ」がある。チェックボックス・メンタリティというのは、自身に足りないものをリスト化してそれを埋めることで安定を得ようとする心理のことである。仕事で失敗した場合、何が足りなかったか原因を考える。スキルマニアはこの原因をわかりやすいスキルに帰結させ、スキルを付けることで失敗しないようにしているのである。しかしながら、特定のスキルだけで成功できるビジネスなんてほとんどないのである。ビジネスにおける物事の因果関係は非常に複雑で「Aが足りないからBが必要」といった単純化はできないのである。
優等生ほど陥りがちなスキルマニアの罠
筆者いわく、こうしたスキルマニアの罠に陥ってしまうのは"優等生"が多いという。ここでの優等生は学校のテストで優秀な成績を取れる人を指す。学校のテストでは点を取れない原因がわかりやすく、対策方法も明確である。
具体的には、「英語の点数が低かったのはリスニング能力が低かったから。だからリスニング能力を高めよう」といったものである。こうした受験勉強的な考えかたをビジネスの現場に取り入れると「仕事の成果が出ないのは自身のスキル不足が原因、だからスキルを高めよう」と帰着するのも無理はない。
スキルは集めるより使い方
スキルは集めるより使い方が大事である。具体的な例えでいえば、野球のピッチャーである。ピッチャーのスキルは球速の速さ・コントロール・球種の豊富さ…といったものが挙げられる。これらすべてを兼ね備えていれば最強のピッチャーかといえば、そうではない。最強のピッチャーは「相手打者からアウトをもぎとる投球ができる」ことである。
調子、得意・不得意な球種、足の速さといった相手打者の情報や、出塁者の有無・ボールカウントといった場の状況を考えて最適な投球をすることでアウトを取ることが容易になるのである。相手が170kmの速球が打てるのに速球で勝負していたり、内角高めの玉も処理できるのにインコースで攻めていたりしてはアウトを取りにくいことは自明であるように、スキルを持った上で使いどころを考えて使うのが大事なのだ。
2 優秀なコンサルタントに共通する3つのマインドセット
"自己の成長"を目的としていない
筆者によれば、「成長」を目的にすると成長しないという。
これは非常に逆説的であるが、確かにその通りである。理由は、「クライアントの役に立ちたい」という本来の目的に必要なものが成長であるからで、成長はあくまで手段だからである。
自己の成長を目的にしている場合、クライアントの役に立つまで努力せず自分が成長する段階までで留めてしまう傾向があるという。人は非常に社会的な動物であるため、他人のため（他人からの評価含め）に頑張ることはできても自分のためだけに努力をし続けることは大変に難しい。自己成長は自分だけのことだから、どこかで甘えてしまうのだ。
「クライアントの役に立ちたい」という目的を持ち、どうしたらよいか考えて行動することでコンサルタントとしての成長がもたらされるのである。
成功するまでチャレンジする
資格試験の場合、過去問題集を解くことで問題のパターンが見えてくるため「近道」があるといえる。しかし、ビジネスの場合はそうもいかない。ビジネスの前提条件は日々変化するし、不確定要素がたんまりある状態で走りださないといけない。近年の若い人の中に"失敗したくない"と願い自分のできることだけやりたいと言う人がいる。それでは"できること"さえ見つからないし、運よく見つかっても時代の変化で"できること"の価値がなくなることさえある。ビジネスで成果を出すには「成功するまでチャレンジする」ことが不可欠である。
"できない"という事実を受け入れられる
BCGに入社する人は成功体験を持っていることがほとんどで、自信を持った人が多い。しかし、そうした人たちが陥りやすい罠がある。それが他責思考である。
一般の人の中にはコンサルタントといえば「自信満々で理路整然と自説を主張する人」というイメージを持っている人は多いかもしれない。しかし、成果を出すコンサルタントはすべからく自己否定ができる素直で謙虚な人なのだと筆者は述べている。
3 "伸び悩み"を突破する
「頑張っているのに伸び悩む」ということは往々にしてある。これが趣味の世界なら頑張っているだけで良いが、ビジネスではそうはいかない。筆者は経験的に、伸び悩むパターンを3つ述べている。
手段が目的化してないか？
前述のスキルマニアの傾向と共通しているが、クライアントの役に立つ提案をするという目的で勉強しているにも関わらず、勉強自体が楽しくなり勉強が目的になってしまうと伸び悩みが起きる。
あなたの能力は「プロとして通用するレベルで得意」か？
筆者は「自分は●●が得意」と言う人に特に多いと述べている。
得意というのは自分が持つ能力要素の中で"相対的に得意"なのか、プロとして仕事で通用する水準に達している意味の"絶対的に得意"なのかで全く意味が異なる。本当に得意と言っていいのは後者だけである。
「井の中の蛙」状態になっている人にとって、他人からのアドバイスは"うざい"と思うことさえある。このような状態では伸び悩むのも必然である。
"相手のビジネスをよりよくする"ためのスキル駆使になっているか？
人によっては本当に「プロとして通用するレベルで得意」なスキルを持っている人がいる。しかしそのスキルを使った作業の際、"相手のビジネスをよりよいものにする"という本質からずれた方向の作業になっていないだろうか？もし作業屋の一段上のステージに行きたいのであれば、"相手のビジネスをよりよくする"ための知見やメッセージを込めた作業をしないといけないだろう。
4 ビジネスマンとしての成長に不可欠な要素
筆者は、成長を次のように定義している。
「目指す姿」と「現状」のギャップを埋めること
ここから、目指す姿→"正しい目標設定"と現状→"正しい自己認識"が必要であることがわかる。この二要素のどちらかが欠けても成長はもたらされない。また、誤った目標設定と自己認識にはいくつかのパターンがあるという。
筆者は、それぞれのパターンを3つずつ下記のように記している。
目標設定編
・具体性のないスローガンを掲げる
・「憧れのあの人」みたいになりたい
・眼前の「できないことの改善」にフォーカスしすぎている
自己認識編
・結論が自責論より他責論に立脚している
・ユートピアばかり探して今の場所で活躍しようとしていない
・無意識の思考のクセを把握していない
無意識の思考のクセの項目を読んで個人的に気になった「SE・プログラマー出身者の思考パターン」の概要をここに記す。
プログラマー出身者は一言でいえば「完璧主義」である。
システムの改修の際はたとえ数行の改修であったとしてもシステム全体の影響調査を行い、あらゆるバグを未然に防ぐためのテストを実施する。
こうした業務を行ってきた関係で、細部に至るまでの整合性担保を行う傾向が強い。
彼らの強みはITに対する知見と緻密さである反面、これが裏目に出やすいところがある。それが「新規事業の立ち上げ」である。新規事業は仮説ベースでコトが進み、見切り発車でスタートする。細部を詰めるのは走りながらで、軌道修正を何度も繰り返すのが新規事業である。起こりうる失敗をすべて想定し、緻密な計画を元に行動する彼らにとっては非常にストレスフルであることは容易に想像できる。
5 成長を加速させる鉄則
正しい目標設定と自己認識を持ち、クライアントに役立つための努力を続けていれば成長は可能である。しかし、"どのくらい速く"成長するかが重要になってきている。変化の速い現代では10年後が今と同じである保証は全くない。3年、下手をすれば1年後に結果を出すことが求められるようになってきている。BCGのメンバーでも成長の速度にばらつきはあるが、一番影響を及ぼしているのは与えられた時間を有効活用できることであると筆者は述べている。
成長スピードを上げるためのアプローチは2つある。ひとつは「量を増やす」ことである。これは睡眠や食事の時間を削って努力するということではなく「学びのスイッチが入っている時間を増やす」ということである。もうひとつは「質を高める」ことである。質と量の両方の要素を高めることで、成長スピードが加速する。これについて詳しく解説する。
量的アプローチ：スイッチオンの時間を増やす
スイッチオンの状況を理解するうえで、スイッチオフの状況を考えるのは効果的である。筆者によれば、以下のようなものが挙げられるという。
「こんな会議に意味はない」と、参加こそすれ深く話を聞いていない
与えられた作業に対し、よく考えず手順書などに則って作業している
自分の仕事の全体の作業における意味合いを理解していない
これらに共通することとして「コンテキストを把握していない」である。言い換えれば、作業や指示の意味合いや求める成果物を考えずに作業しているのである。何も考えていない成果物を提出してはならない。コンテキストを把握したコンテンツを提出するのである。
成長スピードの高い人は、指示や作業工程・全体共有メールなどの情報に対し「●●という方法もあるけどあえて◆◆という方法を採用しているのはなぜ？」「会議で言っていた●●の伝え方が××だったのはなぜ？」などの疑問を持ち、上長に質問するのである。これはすなわち「学びのアンテナが高い」のである。学びのアンテナが高い人はすべからくコンテキストを把握し、かつコンテキストとの相違点を質問しているのである。
質的アプローチ：目を肥やす
"目を肥やす"ことの最も手っ取り早い方法は、成功しているヒト・モノを多く知覚することである。良いピッチャーになりたいのであれば、MLBやNPBで活躍しているピッチャーの投球を多く見たうえで自身の投球を見て差分を確認するだろう。良いピッチャーには何らかの共通点があるはずであり、それを知覚するにはまさに"テープが擦り切れるまで動画を見る"ことが必要である。
※小池所感
これは非常に納得できる。私は同世代の誰よりも走高跳の動画を見ていた自負がある。Youtubeに投稿されていた走高跳選手の動画を毎日のように見ていた。自宅のPCではもちろん、動画をPSPの記憶媒体に入れて持ち歩き、見たいときにいつでも見られるようにしていた（当時はスマートフォンがなかったための処置）。この結果、平均以下の身長しかない私が高校ランク1位（2010年）の跳躍ができる技術を身に付けた背景にあると実感している。
行動を因数分解する
ひとつの行動・作業には無数の要素が含まれている。例えば社内報の作成という作業を因数分解すると、社内調整・外注・進捗管理・チームマネジメント・企画書作成・承認取得…といった要素が出てくる。こうした要素は他の作業をする上で求められる要素であり、このエッセンスを自分の血肉として獲得することができるのである。目の前の作業を因数分解した要素の観点で意識して行うことで、他の作業に応用可能な学びにすることができる。
行動をリバースエンジニアリングする
リバースエンジニアリングとは、既存の製品を分析・測定することで製造方法や素材を明らかにしていく手法のことである。この分析対象を自身の行動にしていくことで、自身の成長につなげていくのである。
デフォルメした例として、今日の昼食にカレーライスを食べた理由について考える。カレーライスを食べた理由について「なんとなく」と答えられるが、「なんとなく」の背景について考察することがリバースエンジニアリングといえる。クライアント先からの帰りにカレー屋の前を通りかかった際に良い匂いに刺激されたこと、朝見ていたYoutubeで配信者がカレーを食べていたこと、昼休みの終わりまで30分で食べられるものを選びたかったことなどが考えられる。
リバースエンジニアリングの考え方は「うまくいった理由」の分析より「うまくいかなかった理由」の分析にこそ強いし、学びにつながる。
例としては下記のようになる。
・システムリリースの進捗に遅れが発生した原因
→結合テスト中に予期せぬバグが発生したこと
・バグ発生の原因
→手直しが間に合わず単体テストに漏れがあったこと
・手直しが間に合わなかった原因
→1回目のコードレビューで機能不十分な点が判明したこと
・機能が不十分だった原因
→実装仕様の認識が曖昧にしたまま実装を進めたこと
・実装仕様の認識が曖昧だった原因
→「●●は曖昧だが以前やったシステムでは◆◆だったからこれと同じように実装しよう」と考えたこと
というように「ある要件について曖昧な認識のまま、上長に確認を取ることなく推測で実装を進めてしまう」という自身の問題の根本に近づくことができる。
「成長が加速しないタイプ」の特徴
育てられ下手
正しい意識を持ち、正しい方向性の目標を立て、目の前の仕事のコンテキストを理解して行動している人がいるとする。彼を見ている上長や周囲は「この人に成功してもらいたい」という気持ちを抱き、アドバイスをしてくれるだろう。しかし、作業に対して正しい行動をしていたとしても"成長させてほしい"と自身の成長を他人頼みにする姿勢では成長しない。成長するためには「必要なものは自分で取りにいく」という能動的な姿勢が大事である。
任され下手
成長を加速させるためには自身に仕事を任せてもらい、試行錯誤しながら成果を出す必要がある。しかし、任された仕事を「自分で全部やらないといけない」と長い時間抱え込んでしまう人には仕事を任せにくいのである。それは、長い時間かけたうえに進捗がないということは単純な損失だからである。こうしたことを回避するには、やり方を調べたり一定時間考えたあと「ここまで考えましたが、いかがでしょうか？」と上長に質問するようにすると良い。
任され下手な人の特徴として「わからないことを早めに詰められない」が挙げられる。例えば「明日の会議で使う資料を作っておいて」と上長から指示があったとする。任され下手な人の場合「何を作れば良いのだろう」と考えこむだけに終始し、成果物を作れないか的外れな成果物を作ってしまうのである。こういう場合は「会議のアジェンダは何ですか？」「前回の会議ではどんなことが話されましたか？」「参加者は誰でどんな人達でしょうか？」などを質問すべきだ。
任され上手な人は「雑な依頼を投げられても上長の求める成果物を予想して出せるスーパーマン」ではない。「雑な依頼だったら上長に確認を求め、不明点をなくしてから無駄なく成果物を作れる人」こそ任され上手な人である。
成長をPDCAで「自動化」する
この章では「育てられる側」ではなく「育てる側」について語っている。
BCGではクライアント企業のリーダー層の育成を依頼される。このときクライアント企業のリーダーのほとんどは部下に対する愚痴や批判を口に出すという。これに対して筆者は「部下が育たないのはリーダーの育て方が下手である」という。
答えを言うのは最悪の指導である
育成における最初のステップは、正しい自己認識と正しい目標設定だ。
しかし、成長をうながすためには"彼ら自身で正しい自己認識と目標設定"がなされないといけない。悪いパターンは、彼らの認識や彼らの目標についてリーダー側が口を出してしまうことである。彼らの認識をリーダーが断定的に言った場合、多くの人は信じないし反発するだろう。仮に信じている反応をしたとしても、部下は上長に対して受け身な反応を取るのが最適と判断した上の行動かもしれない。答えを与えてしまうのは、部下の成長をもたらさないのである。
指導上、客観的事実を伝えるのは大事である。しかし、それは部下に考えさせる材料としてであり、それに基づく結論まで言ってしまうのは最悪といって差し支えない。「●●という点についてキミはどう思う？」など、答えを言うことなく部下の無意識的な思考を解説するような質問をするのが良い。
業務を分解することで部下に依頼する仕事の難易度を調整する
リーダーは部下の成長を促すために、適切な難易度の業務を部下に任せる必要がある。このためには、業務の難易度と部下の実力の両方を把握することが求められる。感覚で業務の難易度を測ることは非常に難しい。特に、仕事ができていたタイプのリーダーは難易度を見誤る可能性が高い。当人にとっては簡単でも、部下にとっては難しいことが往々にしてある。
そこで、業務の難易度を把握する際に「分解」する発想を持つことをオススメする。分解する要素は次の通りである。
論点：問いに対する答え
仮説：検証すべき仮説の提唱
タスク：明確になった仮説の検証結果
作業：検証の1ステップとしての作業
上記を例示すると、下記のようになる。
論点
→A社の●●事業について、中国市場での収益が悪化している。
これがなぜだか調査してくれない？
仮説
→A社の●●事業について、中国市場での収益が悪化している。
商品をを小売店に運ぶための物流コストがネックになっている
可能性があると思われるから、調査してほしい。
タスク
→A社の●●事業について、中国市場での収益が悪化している。
商品をを小売店に運ぶための物流コストがネックになっている
可能性があると思われる。
主力商品の◆◆について、工場から小売店への配送コストが
ここ3年でどう変化したかレポートにまとめてくれる？
作業
→A社の●●事業について、中国市場での収益が悪化している。
商品をを小売店に運ぶための物流コストがネックになっている
可能性があると思われる。
主力商品の◆◆について、工場から小売店への配送コストが
ここ3年でどう変化したかレポートにまとめてくれる？
レポートは配送業者ごとのコストを表にまとめたうえで、
縦軸をコスト・横軸を年次とした折れ線グラフとしてまとめてほしい。
この本を読んで学んだこと
この本を読んで、下記の三点は特に印象に残った。
無意識の思考のクセ
任され下手
業務難易度の見極め
私はプログラマーになる前から「完璧主義」な傾向が強く、「成功する道筋が見えていることでないとやりたくない」と思うクセがあると思った。今後ありうる話として、新しいシステムの新規開発が挙げられる。こうした開発では「成功する道筋」というものは全く存在しないし、軌道修正は何度もするだろう。特に新規開発では、何度も挑戦してはフィードバックを受けて修正するものだと意識して今後のエンジニア人生を歩んでいきたい。
「任され下手」の項目を読んだとき、過去の自分を見ているかのような記述ばかりであった。最近こそ不明点を洗い出して早めに聞くことを心掛けているが、新人のころに抱え込みすぎて上司から呆れられたことは今も覚えている。この本にも記載はあったが、不明点を速めに洗い出すことは今後も続けていきたい。
論点・仮説・タスク・作業の四段階で業務の難易度を分ける発想はとてもわかりやすく、今の自分の業務にも応用できると思う。「上長はどの結論を求めているか？」ということを意識してアウトプットを出していきたい。
この記事が気に入ったらサポートをしてみませんか？