「コンサルティング会社 完全サバイバルマニュアル」を 2,023 年 09 月 09 日に読んだ。
目次
メモ
p30
私が会社を去る直前の日々においては、かれこれ2年間スーツを着ることはなかった。
あまりにも普段着ないので、1着を残し、すべてリサイクルショップで売り払ってしまったほどだ。
クライアント先を訪問する場合でも、ジャケットと襟のついたシャツさえ着用していれば、よっぽど明るい色でもない限り、
失礼にあたることもないだろう(私はかつてデニムシャツを着ていって怒られたことがあるから、賢明な読者諸氏におかれては避けることをおすすめする)。
p31
ヤマウチや西崎をはじめとする先輩たちは、とにかく「速度にこだわる」コンサルタントであった。
まず物理的なタイピング、PCの操作が異常なほどに速かった。
オフィスの中でマウスを使っているのは私だけであり、先輩たちはPCに向かう際、マウスを一切使わなかった。
当時、会社では海外拠点での研修が頻繁に開催されていたのだが、日本オフィスのメンバーがマウスを使わずに、
さまざまなショートカットを駆使してExcelを操作しているのを見て "wizard... (まるで魔術師だ)" と感嘆の声が上がるほどだった。
私がExcelをマウスを使って操作しているのを見たヤマウチは、マウスを取り上げ、「次マウスを使っている所を見たら、手を切り落とす」と言い放った。
最初は操作に戸惑ったものの、1週間もすればマウスがないことに体が自然と慣れていった。
p32
速度を身につけるためには、まずこの「迷子の状態で漫然と作業をしている時間」を徹底的に排除する必要がある。
その第一歩として、1日8時間の作業ロットを2時間単位に分割したい。
例えば朝、何か上司から指示された場合、日を跨いで結果を見せるようでは遅い。
朝一で指示があれば、遅くとも午後一に、一度何かしらの作業進捗を上司に見せられるコミュニケーションが必要だ。
なぜなら、作業の〈手戻りリスク〉を最小化するためだ。
その日1日をかけてゆっくりと作業した内容が、上司の意向と全く異なるものであったことが翌日明らかになった場合、もはやリカバリーすることができなくなってしまう。
入社1年目の私は、作業を1日かけて行い、翌朝に報告するようにしていたが、「え、1日かけてこれ?」
「ごめん。全然指示した内容と違うが......」と差し戻されることが頻繁に発生していた。
1日かけた作業が生産高に結びつかないことは5営業日のうちの20%が既に無駄になってしまったことを意味する。
その時点で残りの4営業日でリカバリーが必要となり、本来避けるべき残業が発生してしまう。
このような惨事を回避するために、まずは2時間集中し、
その中で何かしらのアウトプットが出せるかどうかを自分で考え、そこまでの成果をぶつけよう。
作業を進める中で20分以上手が止まる場合は2時間を待たずして、
即上司に対してエスカレーション(上席への報告する)ことを心がけたい、20分考えて手が止まるような場合は、作業のやり方がイメージできていないことを意味する。
作業の手順を具体的に指示するのは上司の仕事の一環でもあるので、その場合遠慮なく相談しよう。
結果としてその方が仕事は早く終わり、かつ残業代が節約されれば、プロジェクトのファイナンスも改善しクライアントの予算を無駄にすることもなくなる。
これは立派なクライアントと会社への貢献なのだ。
p36
「"速い"はそれ自体が重要な価値だ」とヤマウチに叩き込まれた。
かつてのコンサルタントは上司からよく「自分の時間あたりの単価がいくらかわかってる?」という強烈な圧をかけられながら作業をしていた。
現在はパワハラ的言動について業界の自浄作用が働いており、このようなフィードバックをされることはあまりないが、コンサルタント自身は事実として知っておく必要がある。
一般的に、総合コンサルティング企業のアナリスト/アソシエイト一人の月額単価は 150 万円 ~ 250 万円であり、
1日あたりで換算すれば約10万円。8時間の営業時間で割れば時間あたり1万2500円相当の単価になる。
もし資料を4時間かけて作成すればその資料は6万円相当の価値がクライアントにとって存在しないと、割に合わない。
プロジェクトごとで、安くても数千万、規模の大きなものだと億単位のお金が動く。
正確な見積りと期待値調整で速さを”演出”する p39
年中スピードを出しすぎて、体を壊してしまっては元も子もない。
「加速状態を持続可能な状態で維持する」という絶妙なコントロールが求められるのがコンサルタントの辛いところだが、そこで覚えておきたいのが"期待値調整"テクニックだ。
例えば同じ仕事を同じだけの時間で完了することができるA君とB君がいるとする。
A君は本来翌日の17時までに完了すれば良い仕事を引き受けた際、本日中に終わらせます!と力強く宣言し、結果として翌日の17時に提出することになった。
一方B君は、明日の18時までいただければ終わらせることができるかもしれません、と控えめに宣言した上で、結果として翌日の17時に提出したとする。
この時、二人は同じ仕事を同じ時間に終わらせているにもかかわらず、周囲にいる人間からはA君は自分で定めた締切りを守れなかったルーズな人、
そしてB君はしっかりと締切りに合わせて仕事ができる人という評価になる。
A君とB君の明暗を分けたのは、B君の自分の作業に対する見積りの正確さと期待値調整の巧みさだ。
A君はそこを見誤ったため、必要のない「遅延」を自ら招いている。
私も過去、クライアントが3日後に出てくれば嬉しい、といった仕事を「今日中に提出します!」などと期限を切ってしまい、結果として終わらないことが多々あった。
その都度先輩たちから「もっと保守的な期限を言っておけばいいだろ!3日後って言っておいて、2日後に出せば十分喜ぶじゃん!」と怒られたものだ。
はじめのうちは一つの作業を開始する時に、時間を予測した上で、ストップウォッチで計測するのが良い。
おそらく予測時間をオーバーするだろうが、との手順や予定外の要素がネックになったかを振り返ることが大切だ。
私はアナリスト時代によく議事録を作る仕事を頼まれていた。
議事録は通常、1時間の会議であれば1時間で作成することが理想だが、実際に書いてみるとなかなかそうはいかない。
出席者全員の名前をメモし損ねていて関係者に確認を取らなければならなかったり、出席者の発言の背景を確認したりと、思った以上に時間がかかるものだ。
また、作業途中で同僚に声をかけられたり緊急のメールに返信をしたり等、"差し込み"が入ると集中力が途切れてしまう。
現実的にこうした中断は頻繁に発生するし、そのような想定外の出来事への対応を含めた上で、どの程度の時間があれば一つの仕事を終わらせることができるのか、感覚を研ぎ澄ますことが大切だ。
予定外の手順を一つずつ予測時間に組み込んでいくことで作業見積りの精度は向上し、上司やクライアントからの「なぜそんなに時間がかかるのか?」という質問に対しても、明確に切り返せるようになる。
正しい作業見積りを立てられず、いつまでに仕事が終わるのか明確にできない社会人は、いつまで経っても仕事を任せてもらうことはできないだろう。
p48
一貫性のない色使いやフォントの揺れが少しでもあれば、漏れなく赤入れの対象となった。
100ページ近くある紙の資料をパラパラとめくりながら「これだけなんでフォントが違うの?」「このオブジェクトだけなんか左にずれてるね。なんで?」「この数字、たぶん変だよ。データちょっと確認して」と、数ページおきにコメントを入れていくのである。
ヤマウチの細部へのこだわりは日常生活にまで染み込んでいた。
終業後、二人で居酒屋で飲酒をする際も、〔炒め物、煮物、揚げ物、季節のおすすめ〕と横並びに記載されたメニューに対して、
「こういう表記の仕方を見た時に違和感を持つようになってほしい。この場合、全部語尾を"物"で揃えてほしい」と話していた。
p51
そんな私にある日、同じプロジェクトを担当していた赤城という大先輩が言った。
「僕たちの会社はクライアントに控えめに言ってもかなり高い報酬をお支払いいただいている、いわば高級商材だ。
値段で他社と比較されてしまえば勝ち目はない。僕たちは値段の勝負の土俵に乗った瞬間に負けてしまう。
僕たちはピカソの絵にならないといけない。ピカソの絵を買う人は値段を見て買ったりしない。ピカソの絵だから買うんだよね」と品質の重要性を諭してくれた。
例えば、コンサルティング会社の書いた資料に誤字があったとする。
あるいは会議をはじめる時に、資料の投影でモタモタしたりする。
これではせっかくの記念日に1年がかりで予約したレストランで、椅子に汚れがあったり、店員のマナーが悪かったりするのと同様にクライアントの期待を裏切ることになってしまう。
ただ空腹を満たすためだけに入ったチェーンの牛丼屋で店員の態度が悪かった、というレベルの話では済まないのだ。
悪い評判はすぐに拡散されていく。
コンサルティング業務における小さな品質問題は、会社全体のブランドに影響を及ぼす重大な瑕疵になり得るものだ。
この品質に対する意識は、単に資料の体裁のみに関わる話ではない。
「我々はコンサルタントである」という強いブランド意識を社員一人ひとりが持つことが、あらゆる仕事の場面で細部まで感覚を研ぎ澄まし、プラスαの創意工夫が生まれる土壌ともなるのだ。
p59
もっと言うと、宿題は終わらせるだけではあまり意味がない。
それは期待に応えたことにはなるが、期待以上の働きではないからだ。
コンサルタントとして絶えず意識しておきたいことは、"常に少しだけ期待値を上回る"ということだ。
宿題を終わらせた上で、さらに一つ、オーダーした側が喜ぶことを追加で添えておくと、やっぱり一味違うな・・・・と思わせることができる。
例えば国内の競合会社の動向を調べる宿題をもらったとする。
その場合は競合の動向を調べた上で、参考に2つほど国外の先進事例についても添えてみる。
あるいは上司が毎週行っているデータの集計作業かわりにやる宿題が与えられたら、その集計作業を次週から自動でできるように仕組み化してみる。
かつてコンサルティング会社には新入社員の椅子を背後から蹴飛ばし「バリュー(付加価値出てる?」と聞いてまわる妖怪のようなシニアマネジャーが存在した。
現代社会においては流石にこのような妖怪は絶滅危惧種だが、付加価値のない仕事をすることはコンサルタントとしての存在価値を問われることとなってしまう。
ショートカットはつべこべ言わずに覚える p71
Excelを使用する時にマウスの利用をやめよう。
多い日であれば1日中Excelとの格闘が生じるコンサルタントにとって、ショートカットを覚えているのとそうでないのとでは1日の中でも数時間の作業スピードの差になり得る。
例えば何かしらのシートに入力されている情報を選択してみよう。
たったこれだけの1作業であっても、キーボードとマウスだと5秒程度要してしまうだろう。
100の手順をマウスを使って行えば、500秒が必要になる。
一方、ショートカットは1つの作業についておよそ1秒で済む。
塵も積もれば、削減できる時間は山となっていく。
p113
コンサルティング業界の雄、ボストンコンサルティンググループ出身の内田和成の著書「仮説思考」はすべてのコンサルタントの教科書となるため、必ず読んでおきたい一冊だ。
この本を読まずしてコンサルタント業務を行うことは、ルールを知らずに野球をしている状態に等しい。
p121
そんな状況下でコンサルタントが、「何が課題ですか? どこが問題なんですか?」といった言葉を口にしたらどうだろうか。
クライアントからしたら、「それを知りたくてお前らを雇っているんだろうが」と舌打ちのひとつもしたくなるだろう。
クライアントに課題を直接的な言葉で聞くことは「これから勉強させていただきます」「ご迷惑をおかけすると思いますが」といった言葉と同様、自分たちの存在意義を否定するに等しい。
クライアントに何か聞くにしても、「こう思っているんですけど、実際のところいかがですか?」という仮説思考を徹底しよう。
仮説としての見立ては、本質的な論点を見つけるための議論のたたき台ともなる。
仮説をもとにクライアントとの対話を深め、正しい論点を設定する―これができるのがコンサルタントだ。
クライアントと会話をする際、すでに自分がどこまでの情報を持っているのかを最初に伝え、
どこからが自分の仮説であるのかを示すことはコミュニケーションの作法として非常に重要だ。
p153
いつものように関係会社の一社に大量の指摘を送ったあと、関係会社のリーダーである長谷川という男から強い口調で、
「どう考えても指定された締切りに終わる量の依頼事項ではありません。
相手のことを考えて依頼してくれているのであれば、そういう頼み方にならないのではないですか」と電話がかかってきた。
長谷川は国内最大手のシステムインテグレー ション企業に属する20年選手であり、叩き上げのエンジニアであった。
たしかな知識と経験に裏付けされた技術を持ち、一方で職人の親方のような風貌と口調が特徴的な長谷川は、
頭でっかちでプライドが肥大化していた当時の若いコンサルタントたちにとって天敵とも言える存在だった。
長谷川は、私の資料に対する指摘事項を「形式的すぎてシステムの実装にとってなんら影響のない瑣末なこと」と切って捨てた。
しかし、私は私で、品質管理という職務を担っている。
それが形式的な指摘であったとしても誤りは誤りであると強く信じていた。
当時の私は、長谷川の抗議の言葉を真剣に受け止めず、自らが陥っている沼にも気づかず、
ただ今自分の場所から見えることを、見える範囲の正しさで行い、日夜仕事を続けた。
p156
この疾患に罹患すると人間は放漫になる。自分にできる仕事ができない人を見下すようになってくる。
慢心は油断を、油断は無配慮を、無配慮は周囲への不遜な態度を呼び込む。
若手社員の中には、パソコンの操作でコピー&ペーストをできない年配の方を見ると、無意識に能力のない人間だと見下す人間が出てくる。
その程度の差異で、できる人・できない人とラベリングしてしまうような思考は、自ずと接し方や口調に表れる。
表面上、取り繕っても、敬意のない人間の言動にまわりはすぐ気づくものだ。
そんな一つひとつの振る舞いの綻びが人間関係の不信感へとつながり、関係者間に深い溝をつくってしまう。
p157
現場とのリレーションを深めるためには何よりも相手へのリスペクトが肝心だ。
クライアントの会社や業界がどのような歴史的経緯で発展し、今の事業を行うにいたったかをクライアント以上に理解し、その歴史と価値に敬意を払おう。
アサインのタイミングで、クライアントに関連する本を少なくとも3冊は読み、基礎知識を押さえておくのは最低限のマナーだ。
クライアントの業界における最新のトレンドを把握し、日経新聞の電子記事は用語検索やタグ機能を用いて最新情報が常に目につくようにしておくと良い。
p159
クライアントが許可してくれるのであれば、率先して現場(売り場や工場等)の視察をしたい。
クライアントがどんな点にこだわり、情熱を持って仕事をしているのかを知るには、現場を見るのが一番だ。
働く人々の人柄や哲学をその目で見ることは、自分のアウトプットにリアリティを持たせることになるため、時間が許す限り、現場で何が起きているのかの一次情報は自分で刈り取りにいくと良いだろう。
p163
これが改善したのは、出席するクライアントのパーソナリティをイメージできるようになってきてからだ。
親しい友人や家族間で会話が円滑なのは、相手の人となりやどのような情報であれば興味を持ち、どう言えば不快に思うのかを理解しているからだ。
初見の場合、情報は限られがちだが、クライアントの上役であればあるほど、
何かしら過去に取材された記事がWebなどに出ている可能性はあり、
そこで何が語られているかで、この事業を通してどういう世界を実現したいと思っている人物なのか、あたりをつけられる。
SNSも有用な情報収集ツールだ。
Twitter や Facebook で公開されている情報を集め、その人が生きてきた時代背景やキャリアの変遷を想像しよう。
LinkedInに略歴が載っていれば非常に重要なインプットとなる。
エンジニア出身のクライアントであれば技術にこだわりを持っている可能性が高く、その場合はテクノロジー有識者を揃えて臨むべきである。
こちらの技術に対する造詣の深さを示すことができれば、リレーションの深まりを実現できるかもしれない。
Facebookや社内SNSのアイコンがマラソンやフットサル、音楽活動を行っている写真である等、
特定の趣味が明らかなクライアントの場合は、それらの話題はリレーションを深めるための有効な一手になり得る。
そんな日常的な会話で相手の心がほぐれたタイミングで、今業務上気にしていることや課題感をそれとなく聞き出すと、
どんな情報をどんな解像度で聞きたい人なのかを知る手がかりとなる。
エンジニアとコンサルタントの立場の違い p168
昨今のコンサルティング会社の仕事をテクノロジーと切り離して遂行することは不可能だ。
マッキンゼーやボストンコンサルティンググループといった戦略コンサルティングを売りにした老舗企業においても、
テクノロジーに特化した部署を新設しており、技術に関する知見の強化を進めていく大きな流れがある。
さらに守備範囲の広い総合コンサルティング会社では、多大なコンサルティングリソースを必要とするクライアントの基幹業務システム刷新のプロジェクトに関わる可能性が高い。
そのため、コンサルタントの多くがキャリアの中で一度はSAP等の基幹システム導入を例としたシステムインテグレーションに関するプロジェクトに何らかの形で携わることになる。
さて、アナリストからコンサルタント職になると特定の担当領域を任され、
チーム全体の進捗や品質についてコミットメントを求められる場面が増えてくるだろう。
この時、システム開発が関連しているプロジェクトは、いわゆるコンサルタント職の同僚のみならず、
プログラミングを通して実際に開発や運用を行うエンジニアの同僚や協力会社の社員とチームを組んでプロジェクトを推進することになる。
コンサルタントとエンジニアによって構成されたチームは、通常コンサルタントが、社内外に対してのコミュニケーションのハブとなる。
そのため、コンサルタント職の人間はエンジニアの同僚や協力会社の作業の進捗も含めて取りまとめ、プロジェクトの状況を「可視化して報告」する役割を担うことが多い。
この際、問題になるのは、技術的な素養のないコンサルタント職が、
技術的なバックグラウンドを持つエンジニア系の同僚の生産性を可視化し、管理しなければならないということだ。
プログラミングを実際にしたことがない人間が、一体どのようにその開発の進捗や生産性を管理すれば良いのか?
結論から言うとできないのだ。
コンサルティング会社の社員には自分自身を全知全能のように勘違いしている人間も多く、
運悪くそういう人間が上司にいたりすると「普通にできるでしょ」と言われる場合もあるが、自分ができない作業の生産性を正しく評価し管理することはできない。
私もPMOロールを担った際、協力会社の出してきた開発の見積りやスケジュールの見込みが本当に正しいかどうかについて、その正当性をロジカルに評価し、問題点を炙り出すことにトライしていた。
例えば1つの機能のプログラムを書くのに1日分の開発作業とテスト作業が必要なのであれば、5つの機能のプログラムであれば5日分、というような塩梅だ。
しかし、現実にプログラムを書くエンジニアからすれば、このような見積りは絶対にありえない。
一つひとつの機能は異なるため、その複雑さに応じて開発やテストに必要な時間も異なるし、
中核を担う重要なプログラムであれば1つの機能の開発だけで3日、さらにテストで3日ということも十分にあり得る。
また、先端的な技術を取り入れる場合、その技術が想定した環境の中で動かなかったり、
主要メンバーが実はそれほどの技術力がなかったりといったトラブルは日常茶飯事で、
ある程度正確な予測を立てるためには、実際にそのメンバーたちである程度の期間、開発をしてみた上での評価が必要になる。
事業会社のように同じメンバーで長い時間チームとして働いてきたエンジニアチームの長であれば高い確度で見積りを作れもするであろうが、
コンサルティング会社はプロジェクト内の人の入れ替わりが頻繁に発生し、かつ期間の定められたプロジェクト単位で働く性質上、(特にプロジェクト初期の段階において)見積りは不確実な前提のものにならざるを得ない。
たが、PMOロールの担当は常にクライアントや社内に対して状況の報告や説明責任を負う。
そのため、将来の見通しがわからない状態は強いストレスとなるだろう。
しかし、無理にエンジニアに対して「前提を置いてでも、いついつまでに終わると、言えないんでしょうか?」といった一方的なコミュニケーションをとっても関係性がれるだけだ。
しっかりとした仕事をしようとしているエンジニアであればあるほど「まだできるかわからない」という回答をするであろうし、
約束された納期がほしいコンサルタントとは永久に平行線になってしまう。
このような進捗に関わる管理を強要すると、エンジニアのモチベーションを日に日に削り取っていってしまうだろう。
p186
また、その業務で使用されることが多いシステムを複数実際に利用し、システムごとの特徴、強み弱みを把握しておくと良い。
営業でよく使われるシステムとしては Salesforce.com や kintone といった SaaS 製品が一般的だ。
それぞれの機能を把握し、どのようなクライアントに対して相性が良いのか、自分なりの意見をまとめておくと良いだろう。
特定の製品ソリューションに対しての専門性 p187
特定課題の解決策となり得るソリューションのスペシャリティを持つことも一つのキャリアの方向性になる。
古くから存在する SAP や Oracle といった ERP 製品に加え、 Salesforce や Anaplan、 Microsoft Azure 、 AMW (Amazon Web Services) や Google Cloud Platform 等の SaaS やクラウドソリューション等も、昨今ではコンサルティング会社を支える武器となってきている。
積極的に会社の研修やトレーニングに参加してこうしたテクノロジーを学び、武器にすると良いだろう。
これらのソリューションのトレーニングは1つの講座につき数十万円という参加費用を要することがあり、会社からの補助で受講できるのであれば、ぜひ利用しておきたい。
私の同僚には、20代にして十数種類存在するAWSのすべての認定資格を網羅した猛者もいた。
また、この分野のスペシャリティを身につけていく際の注意点としては、コンサルタントとして、経営者に対してプレゼンテーションできるような俯瞰した目でソリューションを説明できる必要がある。
コンサルタントとしてキャリアを歩む以上、この製品ソリューションを用いることで経営にどのようなインパクトを出すことができるのか、をわかりやすく説明できなければならない。
そのためには、一つの製品のみならず、複数の製品を使い分け、製品ごとの長所と短所を比較してみる経験も必要となってくる。
なお、これらのテクノロジーに関する強みを持つと、転職時においても強力な武器になり得る。
p202
クライアント自身に現在のやり方の問題点に気づいてもらい、
主体的に変革に参加してもらえるように誘導できるかが、コンサルタントとしての腕の見せ所になる。
対面しているクライアントとのコミュニケーションの中で、
「もし○○さんが、社長であれば、今の業務のやり方をどう変えますか?」というカジュアルな問いかけをしてみるのは一つ、クライアントの考え方を拡張する有効な手段になる。
ロジカルシンキングと併せて取り入れられているデザインシンキングという問題解決の手法においても、
「もしあなたが、アメリカの大統領であったら?」「もしドラえもんがいたら、この問題をどう解決すると思いますか?」と発想を拡張する手法が用いられている。
また、クライアントに対して、「本当はどのような仕事の仕方をしたいのか?」という質間を投げかけるのも有効な方法だ。
クライアントの中には長年一つの領域を務め、自分の仕事に対して強い思いを持っていながらもなかなか実現できずにフラストレーションを抱えている人がいる。
特に転職を経験しているようなクライアントは、前の会社であれば効率的にできていたことが今の会社ではなんらかの事情でできない場合、本来こうあるべきだという業務に対する明確なイメージを持っている人がいる。
例えば、クライアントが、毎日行っている様々な雑務を自動化するためのシステムを作りたい、という相談を持ちかけてきたとしよう。
そのままクライアントの言う通りに雑務を自動化するシステム開発を受託し自動化すればクライアントは楽になり、喜ばれ、その後も継続的に仕事を受注することができるかもしれない。
しかし、相談を受けた時に、クライアントはそもそもどのように働きたいのか?を聞いてみると、
前職ではより先進的な方法で同様の業務をこなしていたため、本当は今の雑務の単なる自動化よりも、
業務そのものの最新化を一緒に進めてくれる仲間を探しているとわかったりする。
もしそのようなクライアントの思いに寄り添うことができれば、クライアントと二人三脚の強い信頼関係で、
より大きなインパクトのある変革を組織にもたらすことができるかもしれないのだ。
人から直接言われるよりも、クライアント自身が対話の中で「気づき」を得て、言語化し、
変革の方向性を起案し、具体化する展開が一番望ましい。人は自分で考えて内発的な動機づけを得たものがあってこそ行動へと駆り立てられるからだ。
クライアントの中にあるわだかまりを言語化し、思考の手助けをすることができれば、プロジェクトへのモチベーションとコミットメント度も大きく向上できるだろう。
パワー型クライアントとの戦い p220
働き方改革の潮流の中、選抜された狂戦士(バーサーカー)のみが生き残るコンサルティング業界から、
様々な属性の社員が働くようになった時代に、私が対峙することとなったあるクライアントは、最凶のパワハラ型クライアントであった。
それまで私が出会ってきたクライアントは幸いにして皆、物腰が柔らかく丁寧なコミュニケーションをとってくれる紳士的な振る舞いの企業が多かったのであるが、
新たに担当することとなったクライアントは明らかにそれまでと毛色が違った。
恫喝とも言えるようなフィードバックが毎日のように発生した。
先輩社員の中には10センチ以上あるキングファイルを投げつけられたり、不備のあった資料を床の上で手直しさせられた、という人もいた。
煌びやかなコンサルタントとしてのキャリアに憧れて入社してきた社員は次々と倒れていった。
1週間ごとにチームのメンバーが脱落していくため、自衛隊出身者であったり、物理的に戦闘用に鍛え上げられた肉体を持つ特殊部隊出身者であったりと、
戦国武将さながらのコンサルタントたちがクライアントの前に立つ役割を担うことになり、異様な空気が職場を満たした。
社外の人間をチームに入れる場合の注意点 p230
チームを持つ、ということは必ずしも自分よりも年下の新卒社員と働くということではない。
即戦力として、サブコントラクターと呼ばれる業務委託のフリーランスのコンサルタントをチームメイトとして迎え入れることもある。
同じチームメンバーといえど、社内の人間に対する依頼の仕方と社外の人間に対する依頼の仕方は雇用形態が異なるため、
チームリーダーはその点を踏まえたコミュニケーションを行うことが求められる。
スタッフ時代にほぼすべてのタイプのミスを経験した私は、業務委託の協力会社の管理においても重大なミスをおかしている。
これらの知識は管理職になるまでは研修として会社から教わるものではなかったのだが、人を自分のチームに雇い入れることへの自覚があまりにも欠如していたと反省している。
協力会社の方たちとの契約に関しては社内の営業担当者に任せきりだったために、ご法度である発注前案件着手 (正式に両者捺印の契約を取り交わす前に業務委託の作業に着手すること)となるところだったのだ。
業務委託の協力会社へ作業の依頼を行う際は、社内以上に気を遣ってインプット、アウトプットの形式、作業手順、期日を明確に示す必要がある。
当然ながら依頼は、発注した内容の範囲内で行われる必要があるため、契約内容はしっかり読み込んでおきたい。
最初のうちは、依頼を出した後に1日寝かせて進捗を確認するのではなく、
3時間くらい経過したタイミングで作業が想定通りに進んでいるか、予定外のことが発生していないかを確認する。
うまくいっていない場合は指示の出し方が悪かったと思うべきであり、作業者のせいにしてはいけない。
依頼作業のアウトプットはすべて自分が責任を負う覚悟を持とう。
大切なことは、チームメンバー一人ひとりが、「あの人の指示はきっとこういう意図なのだろう」と想像できるように暗黙知を積み重ねていくことだ。
そのような良好な関係性を作ることで、徐々にメンバーそれぞれが自発的に仕事をできるようになり、
すべて細かく指示を出さなくとも、チーム全体で有機的に動けるようになっていく。
こうなれば、自分自身の多くの作業時間を短縮できるし、チームとしてのパフォーマンスが大きく上がる。
失敗を美談にしない p235
人間の頭の中は非常に便利なもので、強烈な失敗の体験であっても時間が過ぎれば「あの体験は、あれはあれでよかったのかもなぁ」と綺麗な思い出として消化できるようになっている。
だが、チームのリーダーが失敗を美談にし続けている限り、チームが成長することはない。
2週間に1回は定期的にチーム全体で振り返り会を行おう。
特別な準備は必要なく、当初予定していた仕事は客観的に見て進んでいるのか遅れているのか、
その理由はなんなのか、どんな失敗があったのか、お互いにどういうサポートがあればもっと良い成果が出せたのかをフェアに話し合う場にすると良い。
この時、特定メンバーの仕事の成果を特別に褒め上げたり吊し上げたりするのは、絶対にNGだ。
チームが一つの人格として、自分たちの成果を振り返り、失敗から学び、次の2週間をどう過ごすのかをしっかりと話し合おう。
奇才・カワシンとの出会い p262
新たな部署で私の上司になった男は、転職組のカワシンと呼ばれる奇才であった。
システムインテグレーションを生業とする日本企業を退職後、カリフォルニアのビジネススクールでMBAを取得し日本へ戻ってきた彼は、
これまで私が出会った上司の中で最も自由であり、強烈な個性を放っていた。
チームの全員に英語学習と読書、そして感想のアウトプットを強く推奨し、 LinkedIn のプロフィールに英語でレジュメを公開させ、
自分自身が一体何ができ何ができない人間であるのかの"価値の可視化"を強く求めた。
私は当時31歳になっていたが、特に強い専門分野があるわけではない自分を見つめ直す必要に迫られた。社内外の政治と調整はできる。
しかし、戦略コンサル的な思考方法に強いわけでもなければ、英語もできない。テクノロジーに対する理解も浅い。
およそ社会がマネージャーに求めるエリート像からはかけ離れた場所に自分がいることを自覚しなければならなかった。
相変わらずボロボロなプライドと生活の中、私は足掻くことに決めた。
既に30歳を過ぎてはいたが、考えてみれば社会人生活の4分の1が経過したにすぎず、腐ったまま過ごすには残り30年は長すぎると感じた。
意を決して自分自身の不得手なことを一つひとつ潰していくことにした。
自己改造プログラム p264
かくして私はコンサルタントとして人格矯正するためのプログラムを実行する。
最初のターゲットは英語だった。
10年後も英語にコンプレックスを持ったままコンサルタントでいるのは、こうありたいと考える自己イメージとあまりにもかけ離れていたからだ。
英語コンプレックスを徹底的に克服するため、留学を目標とした勉強を開始することにした。
渋谷の大手留学予備校の門をたたき、TOEFL対策講座を60万円で一括で購入した。
また、コンサルティングにおける戦略的思考とは何なのか、テクノロジーとはどういうものなのかを一から理解し直すために、
手当たり次第に書籍を買い、始業前、クライアント先の近くのスターバックスに入り読み込んだ。
世で売れているコンサルティング技術に関する本から各分野の先進技術に関する本まで徹底的に押さえることにした。