コンサルティング会社完全サバイバルマニュアル（アナリスト編）

はじめに

記載にあたって2009年から13年にわたり自分自身に就労と学習の機会、何よりも掛け替えのない仲間を授けてくれた会社に感謝する。そしてすべてのコンサルタントにこの文書を捧ぐ。

当文書は2009年9月から13年コンサルティング会社に勤務し、同社でシニアマネージャまでのキャリアレベルを経験した人間が、自身の独断と偏見にのみ基づき記載する業界内サバイバルマニュアルである。そのため、所属業界・会社の総意ではなく、あくまでも個人の体験を基にした非公式文書となる。

当文書を執筆している2021年は大コンサル時代ともいえる時代を迎えている。筆者が就職活動をしていた15年前に人気上位であった総合商社やメガバンクといった伝統的な国内大企業を抑え、東大京大生の就職人気ランキングでは戦略、総合コンサルティング会社あるいはシンクタンクと呼ばれる企業が上位を独占している。加えて即戦力の補填を目的とした中途採用の積極化により、業界全体では年間で万をこえる人間が新たにコンサルタントとしてそのキャリアを歩み始めている。

かつての激務の印象は社会の働き方改革の波に後押しされながら少しずつ、しかし確実に薄れ始めており、昨今は女性向けファッション誌においてカジュアルかつやりがいも得られる新世代のワークスタイルモデルの一例として紹介されているケースもあり、世間の注目が集まるのもなるほど理解できる。業界内部にいる人間として業界の繁栄を極めて喜ばしいと思う。しかし、一方で非業界経験者と新卒上がりのいわゆる生え抜き社員間における文化や価値観の乖離、一部の社員に対する負荷の集中は世間で揶揄されている通りの現状であり、昨今の急激な変化の副作用が発生していることもまた否定はできない。

筆者が入社した2009年は現在においては到底許容されないような業界特有の長時間労働やパワハラに相当するレベルのしごきに対し、社会・業界全体の問題意識が今ほど顕著ではなかった。そのため、当時のコンサルタント達は物理的な超長時間労働を通して身体でサバイバル術を身につけ、無事その術を身につけたものが生き残り、会社や各プロジェクトにおける中核構成員となっていった（あるいは逆に生き残ったからこそ身についたのかもしれない）。

一方で今この時、新たに大量採用で業界に入社した社員は、筆者世代のコンサルタントが圧倒的な時間によって体得していったサバイバル術を同様の暴力的な手法で身につけることは良くも悪くも法律的に許されていない。

加えて、2019年から拡大したコロナ禍は先輩の仕事の仕方やコンサルタントとしての振る舞いを見よう見まねで盗むことができるオフィスを新入社員から奪い取ってしまった。そのため、ここ数年間でコンサルティング会社に入社した多くの社員はいわゆる旧世代のコンサルタントと比較すると、サバイバル術を獲得する時間的・空間的環境が極めて限定的にしか与えられていない状態となっている。

プロジェクトによって業務内容が異なるために、定型的な業務の「マニュアル」化が難しいという業界特性の中、新入社員らは自分自身の存在意義を自問自答しながら、トライアル＆エラーを繰り返し、サバイバル術を徐々に自分自身で獲得しなければならなくなっていると推察する。

当文書は上述した現状を改善すべく、筆者がかつて長時間の物理的な就労を通して体得したサバイバル術を可能な限りで体系的に言語化し、業界の歪みの解決を目指すものである。

当文書は長らく業界の落ちこぼれであった筆者が、業界内で生き抜くために日々何を心がけ、どう行動していたのかを記録・記載するものである。

そのため、既にコンサルタントとして自律的に業務を推進できるようになっている読者であるならば、当文書はおそらく自明のこと、あるいは初歩的に過ぎることのみが記載されていると感じるかもしれない。かつて筆者がこの業界に足を踏み入れた時代に業界に多く生息していた強く賢く、唯我独尊を貫ける往年のコンサルタントにとって、当文書はまったく不要のものになるだろう。

当文書はむしろ、かつての筆者と同様、何かしらの運命の糸に引っ張られ、迷い込むようにこの業界に足を踏み入れ、進むべき方向を見失っている人に向けて、ある一人の先人が手記として残すものである。

筆者は当文書においてコンサルタントの働き方はかくあるべしと、一義的な定義をすることを目的としていない。ここに記載されている一つ一つのサバイバル術は筆者が仕事を生き延びるために、脳内で創造したイマジナリーなもう一人の筆者が、筆者自身を縛る規律である。筆者は、当文書をいわゆる叩き台とし、諸君ら自身がコンサルタントの働き方の解釈をそれぞれ拡張し、より自由で、自分らしいコンサルティングのスタイルを確立することを望む。

記載にあたっては当時筆者が犯してきた数々の過ちを具体定的に例示し、いわば死亡フラグともいうべき分岐点を可能な限り多く示すようにした。

都内私大文系を卒業後、IT、コンサルティングに関する一切の知識を有しない状態で当業界に新卒で入社し、なんら特出した強みがあったわけではない筆者が13年間業界内で生き延びた経験は、同様の背景を持つ多くの同志諸君に対し、何かしらの指針、参考になりうるのではないかと願い記録する。

アナリスト編

本章は新たにコンサルティング業界に足を踏み入れ、業界内ではアソシエイトあるいはアナリストと呼ばれる職位からそのキャリアをスタートする諸君らに向けて記載をしている。

入社する前、諸君らはコンサルタントについてどのようなイメージを持っていたであろうか。スリーピースのスーツと高価な腕時計を身につけ、ホワイトボードの前に3つの論点をMECE（もれなくダブりなく）に並べてクライアントに経営課題を説く、そのような所だろうか。しかし諸君らも入社後少しずつ気づいている通り、昨今の業界の空気は急速に多様化している。中途採用の拡大によってより様々なバックグラウンドを持つ仲間が業界に参画してきているし、働き方改革のムーブメントにより、よりフラットで、よりカジュアルな働き方が広くこの業界の中にも浸透してきている。

実際に筆者はかれこれ2年近くスーツを着ていない。クライアント会議においてもUNIQLOのフリースやスウェットシャツで参加することが一般的になってきている。筆者は特別カジュアルな人間であるか？といえばそういうわけでもなく（ここに議論の余地はあるかもしれないが）、筆者の上司達、統括本部長クラスでもカジュアルな服装での会議参加がここ数年で一般的になってきたと感じている。また、前職が芸能関係であったり、客室乗務員であったりと、多様な経歴を持った同僚と接しながら、日々の業務をこなしている。

ではそのような時代、これまでコンサルタントのイメージを形作ってきていたステレオタイプが急速に変化している時代に、それでもなお、コンサルタントをコンサルタントとして形作っているものは一体なんなのであろうか。

あえて一つあげるとするならば、筆者は「速度」であると考えている。

コンサルティング会社を退職し別の業界に就職したOG、OBはよく、「同僚達と会話のプロトコルが通じない。コンサルティング会社で働くことがどれだけ恵まれていることなのかがよくわかった。」と過去を振り返るという。世間からはよくプライベートのシーンにおいても横文字やホワイトボードを多用するコンサルタント仕草が批判や嘲笑の対象となっているが、まさしくそれこそがコンサルティング会社が赤い彗星が如くスピード感を持って仕事を推進できる理由であると筆者は考える。
Aという事象が発生した場合はB。Cという事象が発生した場合はD。というように、もはや考えたり悩む間も無くインプットした情報はそのまま神経を伝達し、行動にうつっていく。そのような基本動作の集合体がコンサルタントのスピードの正体である。

簡易な例を挙げるならば、クライアントから何かしらの資料やデータを受領した場合、そのファイルをチームの他のメンバーが見れるような場所に格納し周知する。会議が終われば30分後くらいにその会議の議事の要点と期限と担当が割り振られたToDoが展開されてくる。これはコンサルタントであれば誰の指示を受けるでもなくできる必要がある。

また、提案書を作成する、というお題が出たときに、目次構成と各目次ごとに記載するメッセージをドラフトし、まずは骨子のドラフトとして他メンバーと議論するためのいわゆる「叩き台」を作り、内部会議を設定をする。ここまでを一呼吸でできるのがコンサルタントである。

もちろん正しくはこれらはすべて上司の業務指示として降りてくるべきものであるが、すべての指示を待っていて行動するのと、事前にこう動くであろうと意識しておいて日々の仕事をするのでは、結果として両者の速度は圧倒的に異なる。ボールが飛んでくる所に予め身体をおいてサッカーをプレイするが如く、日々次の業務を予測しながら行動できるからこそ、コンサルタントの仕事は「速い」のである。

そしてその基本動作を所属しているメンバー全員が無意識に行い、メンバー間の阿吽の呼吸が実現するからこそ、コンサルティング会社の仕事は組織として「速い」のである。

速度を作る一つ一つの所作はコンサルタントという仕事の中における基本中の基本であり、それらがそのまま諸君らの中核スキルになることはないであろうし、将来において他の誰かとの圧倒的な差になるのか？と言われればそうではない。あまりにも当たり前の前提だからである。コンサルタント、マネージャとキャリアレベルが上がっていくにつれ、業務の複雑さと判断の際に考慮しなければならない変数は増えていくため、基本動作のみだけで解決できることは減っていくだろう。しかし、だからこそ、基本動作一つ一つについて、思考しながら行動していては遅いのである。本章ではコンサルタントの「速度」の要素となっているコンサルタントとしての基本動作を中心に記載したいと考えている。

さて、マニュアルを読むにあたり偉そうなことを述べている筆者が当時どのような人間であったのかを紹介し、まずは諸君達に安心していただくこととしたい。概ね自分語りであるため、興味がなければ読み飛ばしたとしても構わない。

アナリスト編：邂逅：どのようなアナリスト時代であったのか？

2009年10月、筆者は東京某所のコンサルティング会社のロビーにいた。約1ヶ月間の研修期間を終えた後、次々とプロジェクトへ派遣されていく同じ研修を受けていたはずの同期を横目に2週間のアベイラブル期間を経てついに受け取ったアサインメールに指定された場所だった。

2週間のアベイラブルは世界随一のコンサルティングファームに内定したはずの筆者を含む新入社員のプライドを砕くには十分なものであった。筆者が就職活動を終えた2008年の春から約半年後、サブプライムローン問題に端を発するリーマン・ショックは全世界の経済に大打撃を与えていた。筆者が入社したコンサルティング会社のクライアント企業も例外なくその影響を受け、多くの企業は利益の確保のためにコスト削減の余地を探し、コンサルティング会社も仕分けのターゲットになっていた。入社以降は寝る間もないという評判を聞いていた新入社員は、自分達を受け入れる先の仕事がない、という会社の状況に混乱していた。毎日ただ決まった場所、決まった時間に出社し、配属後に役に立つかどうかもわからないWeb研修を検索して受講する。隣には明らかに覇気を失った中年社員が研修コンテンツとは異なることが明らかな動画を見ている。さらに奥には光を失った目で転職サイトをスクロールするまた別の社員がいる。彼らはもしかすると近い将来の自分の姿なのではないか、そんな不安を抱えながら毎日を過ごさざるを得なかった。もはや働けるのであればなんでもよかった。社会から、組織から必要とされたかった。先月25日に振り込まれたばかりの月給は、貧乏学生であった自分にはあまりにも高額であり、それに報いるための何かを求めていた。なぜあの同期はアサインされ、なぜ自分はアサインされないのか。研修中の成績にそこまでの優劣が存在したのか。明確な処遇の差についての説明は与えられず、様々な思惑が頭を巡り、同じくアベイラブルの処遇を受けている同期と研修会場の付近をぶらぶらとうろつき、将来の不安を言葉にするでもなく空気で共有した。

アサインメールはアベイラブル期間2週目の最終営業日にあっけなく届いた。

「9時に本社ロビーで。プロジェクトの担当者が迎えにいきます。詳しくはそこで。」要件のみのメールで送り手の印象はメール文面からは全くわからなかった。舐められてはいけない。これだけが当時唯一の行動原理であった筆者は、約束の日当日、ほぼシルバーに近い光沢のあるスーツを着て、迎えに来るはずの先輩社員を待っていた。

やってきた男は「西崎です」と名乗った。「君の上司は今別件で迎えに来られなくて、代わりに僕が迎えにきた。出会い頭にこんなことを言うのも、あれなんだけど、君の上司になる人は少し優秀すぎる所があってね。まず、アメリカ帰りで日本語のコミュニケーションができない。そして、パフォーマンスの低い部下に激怒してそいつの腕を折ったことがある。君、英語はできる？」

完全な想定外だった。当時の筆者のTOEICスコアは650点程度。外資の会社に来るには高いとは言えないスコアであり、加えて受験勉強以降完全に研鑽をサボっていた自分は特にリスニングとスピーキングに大きなコンプレックスを抱えていた。しかし、ここで出来ないと言えば、もしかしたらあのアベイラブル部屋に戻ることになるかもしれない。そう考えるともはや退路はなかった。頭が判断するより前に「できます」と口から出ていた。

筆者の上司になる男だと紹介された男は、本社ビルと道を挟んだ雑居ビルの一室の2階にいた。髪も目も黒い。どこからどう見ても生粋のアジア系、というよりも日本人に見える。しかし足を組みながら英字新聞を広げ、スターバックスのグランデサイズのコーヒーを持つ姿はなるほど確かにウォール街を思わせた。「ヤマウチ　デス」とその男は唐突に握手を求めてきた。（日本語？日本語で話しかけてくれているのか？）、事前情報からかなり気難しい人間と推測していた自分は、混乱しつつもその握手に応じ、「ども。●●です」と完全に日本語で応答した。ヤマウチはなるほどという顔をしながらこう続けた。「Fukkinn、Kyoukin、Johwan-nitohkin, subete kitaereba kimimo…」私は一言も聞き逃すまいと内ポケットに忍ばせていたメモにヤマウチと名乗る男の謎の言葉のメモをすべて記録した。

「PERFECT BODY」

確かにそう聞こえた。ヤマウチの言葉の意味を頭で理解するよりも先に、PERFECT BODYという英語を自分自身の耳が理解できたという高揚感が脳を満たし、その言葉をメモに残しつつ大きく「わかりました」と頷いた。

「わかりました、じゃないでしょ」とたしかに日本語が続いた。ヤマウチはたしかに日本語のイントネーションでそう私に言っていたのである。訳がわからなかった。アメリカ帰りの英語しか喋れない優秀で知られる上司が、私のために日本語を喋ってくれているのか？様々な可能性が脳をめぐる中、下をむき必死に溢れでる笑いを我慢している他の先輩社員を見て気づいたのである。

最初から私は嵌められていたのだと。

「クライアント会議だから準備をしろ、議事録をとってもらうからね」と言われ、配属初日にすぐにクライアント先を訪問することになった。はじめてアサインされたプロジェクトはプロジェクト自体が開始後間もなく、まさしくクライアントとの初回キックオフとも言える会議が筆者の社会人初会議であったのである。筆者は高揚していた。入社から約1ヶ月と半月、研修の成果を遂に発揮する時が来たのである。研修中、プログラミングについては得意な同期に全てを委ねる他なかったが、幸にして議事録については平均以上の評価を得ていた。月給に報いなければならない。そう思い、クライアント先の会議室でメモを取ろうと胸ポケットに手を入れた時、自分がペンを持っていないことに気がついたのである（当時は会議先にPCを持参せず、会議資料を紙に印刷し、議事メモも紙で取ることがまだ比較的一般的だった）。進んでいくクライアントとマネージャ陣との挨拶、もう次の瞬間には最初のアジェンダに関する議論が始まる、そう思った時、筆者は両の眼を瞑り、全ての神経を自身の両耳へと集中させた。まさしく全集中の呼吸である。（この会議のすべての会話を、一言一句、一字漏らさずに記憶してみせる）そう覚悟を決めた時、集中させていた右耳が「ドンッ」という音を捉えた。

隣に座る女性先輩社員がものすごい形相をしながらこちらを睨み、そしてボールペンを机に叩きつけていたのである。

「ありがとうございますございます────────」

そう小声で囁き、筆者はメモを静かにとり始めた。

会議が終わった時、既に時計は18時を過ぎていた。会議場所であったクライアントのオフィスからプロジェクトルームへと戻る途中、先輩達はサービスタイム中のモダンテイストな居酒屋で軽い歓迎会を開いてくれた。軽いつまみと各自１杯だけビールを頼み、それを飲み干し、プロジェクトルームへ戻り、鞄を持って退社しようとしたところ、ヤマウチは「議事、何時にできる？」と問いかけてきた。

振り返った筆者は眼を疑った。既に時刻は20時を回っていたが、誰一人として帰る素振りを見せていないのである。皆黙々と業務を再開していた。

このようにはじまった筆者のアナリスト時代は散々な物であった。そもそも筆者はプロジェクトに入るまで、コンサルティング会社というものがいったい何をしているのか、まったく理解していなかった。コンサルタントの価値というものが何なのか、クライアントがコンサルタントの何に報酬を払っているのか、具体的なイメージを全く持てていなかったのである。そのため、当たり前の結果であるのだが、自分が何をすれば良いのかわからなかった。一方で自分にできることはなんでもやろうという心意気だけはあった。

今の自分にできることはなんなのか？迷った末に辿り着いた結果は、朝の声出し（遅れてくる先輩達に対して怒涛の挨拶）とプロジェクトルームの机磨き、そしてプリンタの紙詰まりを解消することであった。完全にバイトである。偉い人はしばらく筆者をEpsonの保守スタッフと認識していたと後に述べている。

ヤマウチは周囲から学歴詐称を疑われている筆者にあらゆるコンサルティングの基礎を叩き込んだ。議事録作成、基本的な資料の書き方、データ集計、提案書作成、PMO業務のイロハ、メールの書き方に至る一挙一動のすべてである。壮絶な2年間だった。

メールは送信までの間に5回以上差し戻されていたし、議事録に至っては紙から1m離れてみれば赤い紙なのではないか？と思える程赤ペンでコメントが入っていた。筆者の書いた原稿はもはや原型をとどめていなかったが、ヤマウチは決して自分の手で議事を修正することはせず、プリントアウトした紙に赤ペンでコメントを残し筆者自身に修正させた。印刷したA4の用紙の余白に入り切らないコメントは付箋に拡張され、赤いたんぽぽの花のクラフトワークのようになっていた。修正を繰り返し反映してはまたたんぽぽのような付箋付きの原稿を受け取り、そしてまたそれを反映するの繰り返し。一つの議事録を書き上げるのに、通常は会議と同程度の時間で書き上げることが理想と研修では教わっていたが、修正反映を含めて6時間以上の時間を要していた。

当時入社前の研修資料で配られた「やさしいJava」の環境構築を大学の友達に丸投げするほどITリテラシーのなかった筆者は、IT案件全盛期のコンサル会社においてやれることは何もなかった。また、生まれつきの大雑把な性格が災いし、データの集計をやらせれば合計値を間違えたし、両面印刷の資料の奇数ページのみを印刷して会議に持参しクライアントに指摘されはじめて気づいたこともあった。Excelシートの印刷時に、設定を誤り1列ごとに印刷されてしまったのであるが、（再印刷は紙が勿体無い）という謎のサステナブル思考を発揮し、そのままヤマウチに提出して叱責されたこともあった。

あらゆる新卒っぽいミスのバリエーションを片っ端から網羅し、そうして何をすると怒られ、何をすれば怒られないか、ギリギリの線引きを日々体得していった。

ほぼ毎日、家に帰ることができたのは午前0時を回ってからだった。クライアント定例がある毎週水曜日の前日は必ず徹夜になっていた。どのように段取っても絶対に徹夜になってしまうため、あるタイミングから火曜日は快適に徹夜ができるようにスウェットパンツと洗顔料を持参し、事務所の椅子を４つ並べて仮眠し、会議に出席した。「徹夜対策を考えてきた」という筆者の言葉を聞き、何かしらの段取り面の改善を予想していたヤマウチは、より快適に徹夜する方法を考えてきた筆者に驚愕しているようだった。電車で家に帰ることが出来た日はその日が終わるのが惜しく、けいおん！の動画を見て涙を流し酒を飲み寝た。

はじめての出張は大阪だった。初の出張、初の大阪オフィス。約束の場所を訪問すると会議室の机の上に男の体が横たわっていた。オフィスに霊安室あるの？と驚愕したが、幸いにして死体ではなかったようで、東京からの派遣組に気づいた寝そべり男は机から起き上がるとこの提案の責任者だと背景の説明をはじめた。はじめての大阪でやる気だけは溢れていたが、アサイン2日で筆者のすべての作業品質に疑問点があることを先輩達は見抜いていた。筆者が開いたファイルのインデントはことごとく破壊されていたためにルールブレイカーの称号を得た。特にやれることがなくなった私はひたすら業後の飲み会の場所を探し続け、予約した時間になっても先輩たちの仕事が終わらないため、30分単位で店に謝罪し、予約時間を遅らせてもらうことにその心血を注いだ。東京から大阪まで来たのに依然として私がやれることはバイトだった。学生のバイトでも流石にもう少し何かしらできたのではないかと今では思う。なぜか一番働いていないのに酒を飲まなければ自我を保てないので酒を煽り、翌日先輩達が働きはじめている中完全な寝坊をぶちかました。

大阪出張の目的であった提案書作成が一応の完成を見せた夜、東京へと向かう新幹線で宇多田ヒカルを聴きながら自分の不甲斐なさに泣いた。東京に戻ってからも毎日がただただ降ってくる仕事を終わらせ、酒を飲み、寝る。金曜日は午前5時まで飲み、土曜は夕方に起きて日曜は死んだように過ごし月曜から働く。社会は大変とは聞いていたがまさかこれほどとは...と呆然としているうちに季節はめぐった。

一年が経過した頃、隣のチームのシニアマネージャに議事録をヘルプで取るようにお願いされ、初めて出る会議の議事をとった。そのシニアマネージャは資料の日本語については極めて高い品質を求めることで知られていたため、一旦のドラフトを書き上げレビューに提出した時、かなりの修正量がやってくるものと予想していたが、書き上げた私の議事にコメントが入ることはなかった。「良く書けていた」のである。

一年間、膨大な時間を書けて培った基本動作は確実にコンサルタントの基本動作に変換されていることにその時初めて気がついた。このコンサルタントの基本動作、とはつまるところなんだったのであろうか。以降ではそれを振り返りたいと思う。

アナリスト編：アナリストに求められるものとは？

さて、アナリストをサバイバルするに必要な要素はコンサルタントのアイデンティティたる速度を構成する要素、即ち「当たり前のことを当たり前にできる」点に尽きると言える。

この点、筆者のように注意散漫な性格をしている人間、あるいは何かしらの一発逆転にすべてをかけようとする人間はアナリスト時代に非常に苦労することになる。

諸君らは幸か不幸かアナリストという最初のキャリアレベルから当業界で働くことになったわけであるが、結果として”新卒でコンサルティング会社でアナリストを経験したことがある人間”という十字架を背負うことになる。これが意味することは以下の「当たり前のこと」であり、また社内のマネージャレベルがアナリストに期待することも同じ点に集約される。

• 指示に対しての作業が迅速かつ正確である

• プロジェクト進行におけるロジ（ファシリテーション）ができる

• 想定外に対してのエスカレーションがはやい

• 現場レイヤーのクライアント情報を解像度高く吸い上げることができる

• No surprisesの徹底

一つ一つ見ていきたい。

指示に対しての作業が迅速かつ正確である

一般論として会社あるいはマネージャレベルがアナリストに対して作業の大方針の組み立てを求めることは少ない。それはマネージャあるいはシニアコンサルタントレベルの仕事であり、アナリストはそこから切り出された仕事をいかに正確に迅速に遂行できるか？が評価ポイントになる。ここでのキーワードはスピードと正確性である。

• 一つの作業ロットを２時間にする
  まず諸君らにおいてはダラッと作業する癖を徹底的に排除する必要がある。それを可能にするために、1日の作業ロットを細かく分割することを推奨する。
  例えば朝、何か上司から指示された場合、日を跨いで結果を見せるのは遅い。朝一であった場合、遅くとも午後一では上司に一度何かしらの作業進捗を見せるようなコミュニケーションを心がける必要がある。なぜか。まず作業が手戻るリスクを最小化するためである。万が一その日1日をかけて作業した内容が、まったく上司の意図と異なるものであったことが翌日明らかになった場合、もはやリカバリーすることが出来なくなってしまうからである。
  まず２時間を一つの作業ロットとしたい。２時間、その中で何かしらのアウトプットが出せるかどうかを自分で考え、ひとまずそこまでの成果をぶつけるのである。作業を進める中で20分以上手が止まる場合は2時間を待たず、即エスカレーションすることを心がけたい。作業指示をもらった際に、あらかじめその日の中の中間チェックポイントを上司と設定しておくのが良いだろう。
  20分考えて手が止まる場合は作業のやり方がイメージできていないことを意味する。作業の手順を具体的に指示するのは上司の仕事の一環でもあるので、その場合遠慮なくエスカレすること。結果としてその方が早く終わり、かつ諸君らの残業代が節約される分プロジェクトのファイナンスも改善する。これは立派な会社への貢献である。
  

• 自分はどの作業がどれくらいのスピードでできるのか？を理解する
  作業見積もりの精度を上げる必要がある。例えば1時間の会議の議事録であればどの程度で自分の納得いくレベルのドラフトを完成させることができるのか？課題のアップデート、進捗資料作成等であればどの程度でドラフトできるのか？この辺りの自分の出力時間をアナリストの1年目のうちに徹底的に感覚値として体に叩き込みたい。この感覚値は一生モノの技術となるため、はやめに体得することを推奨する。
  はじめのうちは一つの作業を開始する時に、どれくらいの作業時間がかかりそうなのかを自分で予測した上で、実績をストップウォッチで計測するのが良い。おそらく予測時間を上回るのであるが、その後、どの手順や予定外のことがあったから予測時間を上回ったのかを振り返ることが重要である。予定外の手順を一つずつ予測時間に組み込んでいくことで諸君らの作業見積もりの精度は向上していくし、上司やクライアントに対して、なぜそんなに時間がかかるのか？という質問に対して明確な答えを持って切り返せるようになるのである。
  作業時間の精度を把握しない限り、正しい作業見積りはできず、いつまでに終わるのか終わらないのかをコミットすることができない曖昧な社会人になってしまう可能性がある。これではいつまで経っても仕事を任せてもらうことはできない。
  

• 「答え」を持っている人間の当たりをつける
  少し乱暴な言い方であるが、諸君らコンサルタントに対して支援を依頼するクライアントというのは世界あるいは日本有数の大企業であることが多く、現代の大企業における経営アジェンダであったりDX文脈において今後実施しなければいけないテーマというのは自ずから似通ってくる。
  そのため、諸君らコンサルタントがクライアントと議論しなければならないいわゆる論点であったり、提案することになるソリューションについてもある程度の体系化が可能であり、議論の”型”がなにかしら存在している。
  そしてその各課題のテーマや提案テーマについて、その瞬間社内で最も詳しい人間、すなわち社内有識者がコンサルタント企業には存在する。例えば管理会計であればAさん、人事周りであればBさん、データ統合基盤であればCさん、ゼロトラストセキュリティであればDさん、といった形で、テーマ別に誰を議論に入れれば”会社としての”答えに辿り着けるのか？を日頃のネットワーキング活動等を通して事前に把握することで、諸君らが答えにたどり着くためのスピードも当然上がる。
  有識者がどこにいるのかについては、社内勉強会であったり、会社の広報活動等で先進事例として紹介されている記事を誰が書いているのか？を意識することで比較的簡単にわかることである。
  もちろん諸君らにおいてもクラアントのために自分自身の脳を限界まで使うことは必要になるのであるが、クライアントが求めているのはあくまでも諸君らが所属している”コンサルティング会社”としてのベストであり、諸君ら個人のベストではないということを忘れてはいけない。そのため、自分が所属しているプロジェクトのテーマに応じて、社内有識者の頭脳をフルで使用することがクライアントのために必要になる。諸君らが頭を使うべきは、誰をどの議論にどのように巻き込めばクライアントに会社全体として最も貢献することができるのか？である。
  

• "拠り所になる資料"を理解する
  当たり前すぎてあまり誰も教えてくれないのであるが、プロジェクトはクライアントとの契約に基づき、指定されたスコープ、予算、納期が定義されている。そのため、自分が何をすればわからず手が止まってしまった時、大原則としてプロジェクトが全体として何ができれば良いのかはクライアントとの合意文書を読み込むことである程度想像・仮定をおくことができる。
  どのプロジェクトにおいても必ず、仕様書と呼ばれるクライアントが発注先であるコンサル会社に何をして欲しいのかを取りまとめた文書と、提案書と呼ばれる、仕様書に対し、コンサル会社が何をするつもりなのかを具体化した文書は存在しており、コンサルがプロジェクトにおいてやることは原則としてすべてこれらの文書の記載に包含される。
  包含されないことをやってしまった場合、厳密にはコンプライアンス的にアウトとなるため、建前上は必ずこの文書が作業の拠り所となる。これらの文書にはプロジェクトそのものの目的や背景などが通常記載されている物であるため、これらを読むことで、自身がやっている作業が何のためなのか？どこに向かっているのか、そしていつ頃までに終わっていなければいけないのかのあたりをつけることができ、それを知っていることは作業のスピードや確度に影響を与えるため、必ず読んでおくことが求められる。
  

• "成果物間のつながり"を理解する
  あらゆる資料には文脈と前後関係が存在している。上述した提案書は仕様書と対応しているし、プロジェクトを通して作成するものは提案書に明記していある成果物一覧に紐づく。成果物間も基本的には何かしらの前後関係があるはずであり、Bという成果物はAという成果物をインプットとしているしBはCのインプットとなる。
  そのため、資料間には必ずキー（両者を紐づける情報）が存在しているため、それを意識して資料を読み、かつ資料を作成するときはこのキーを壊さずに作業を進めることが求められる。
  資料間の関連が頭に入ると、何か情報が必要となった時に、どこにアクセスすれば欲しい情報が手に入るのかがわかるため、これらはプロジェクト参画後、2週間以内には理解しておきたいところである。
  

• 常に自動化の余地を探す
  プロジェクトが軌道にのり、諸君らの日々の業務もある程度のルーティンになってきた時、日々の業務の中で自動化する余地を探すことが必要である。これは作業速度のみならず品質についても爆発的な改善を実現することができる。
  よくある自動化の手段としてVBAを用いたマクロ作成等が古典的であるが、最近はMicrosoftが提供しているPower Automate等でもかなりの作業を自動化することが可能であるため、これらを有効活用するのが良いだろう。
  大量のデータ集計等が日常的に行われる場合はExcel管理を脱却し、DBを構築してみる、Pythonによって処理をさらに自動化する等の工夫をすると、将来的に諸君らのキャリアの武器にもなるため、一石二鳥である。
  これらの自動化を行う際は、その仕様が複雑化・ブラックボックス化すると長期的に見た時にプロジェクトの負の遺産になるリスクがあるために、その仕様については最低限のドキュメント化と定期的な更新・チームメンバーへの共有を行う必要があることを忘れてはならない。
  

• 考える必要のない所に時間を使わない
  パクれる場所はパクり、アレンジにこそ頭を使うべきである。上述した通り、経営マターの検討にコンサルティング会社を使うような巨大な資本をもった、あるいはキャッシュの状況に余裕がある大企業が、一般的にどのような問題点を抱えており、それに対してどのようなソリューションを当て込むべきなのか？という点は体系化が可能である。試しに時間がある時に特定のテーマに焦点をあて、社内の提案書をいくつか見てみると良い。概ね似たような課題仮説であったりソリューションの当て込みがなされているはずである。
  クライアントのどこに病状（課題）があるのかを初期診断するためのチェック項目、それを踏まえた上での論点の設定、それに対してどのような解決策が有効となり得るのかの仮説出しといったプロジェクトの骨になる議論は社内有識者を含めて短期集中的に行うべきであり、ここについて検討時間を必要以上に費やすべきではない。
  あえて夢のない言い方をするが、諸君らのクライアントがコンサルタントに求めているのは諸君ら個人一人一人の頑張りではない。そんなものは当たり前だからである。クライアントが人材派遣会社でもなくSI構築事業者ではなくコンサルタントにあえて依頼をしているのはコンサルティング会社が組織としてもっている膨大な知識とノウハウがあるからであることを忘れてはいけない。それらの情報を有効活用することは決して怠慢ではないということを知っておいて欲しい。
  では諸君らはどこに時間を使うべきなのか？それは一般論と諸君らが向き合っているクライアントの"差"の分析である。「分析とは何か？」

社内の有識者を含めた議論ではおそらく、一般的にはこうであるからこのクライアントにおいても、こういうことが問題になるのであろう。という点が話される。これは有識者は広く業界を見ているが故にそうなるのであるが、ここに一味加えるのは諸君らの仕事である。
例えば、いわゆるベストソリューションと呼ばれる解決策は広く世の中で使われている最適解であり、それがそのままクライアントの業務に当て込むことができるかと言われればそうでない可能性がある。一般論として、Purchase to Payと呼ばれる購買、財務会計、固定資産管理といった企業の金の流れに関する業務はそれほど業界の特性に関わらずに検討が可能と言われる領域であるが（SAPといった高額なERPパッケージがあらゆる業界に実装されているのはそういった理由からである）、それであっても個別のトランザクション件数であったり業界特有の慣習・法規則への対応であったりと、一般的なソリューションでは対応できない”何か”は必ず存在している。それが具体的に何なのか？そしてそれは一般論に対してどのような影響を与えうるのかを考えることこそ諸君らが時間を投下する場所である。

具体的な話をしよう。諸君らがクライアントからなにかしらのコンサルティング支援の依頼を受け、提案書作成にあたり「なぜなにをやるのか？」をクライアントと討議するシーンを想定して、時間を使わなくて良い部分と使うべき部分がどこにあるのかを例示してみたい。

1. そもそもなぜやる必要があるのか？はパクれる
   多くのクライアントはこのなぜ？の動機付けが非常に曖昧であることが多い。なぜやるのか？の部分は是非クライアントにこそ考えていただきたいとコンサルタントとして思う所ではあるが、我々に依頼がくる仕事の中には、年末になんとなく予算が余ったからとりあえずお金を使い切りたいという理由から無理矢理に作り出された仕事も少なからず存在しているのである。
   そのような動機が曖昧なクライアントとなぜやるのか...についての哲学的な問いをあまり議論している時間はない。
   このなぜなぜ分析の沼に落ちると曼荼羅のようなWHY（俺らこれなんでやってるんだっけ？）の相関図が出来上がっていく。曼荼羅で経営は変わらない。
   基本的にあらゆる会社の活動は会社の利益に紐づかなければならない。もしくは株主あるいは顧客へのリターンの最大化、近年ではSDGsといったものも含まれてきてはいるが、概ねなぜやっているのか？の大目標は業界や企業が違えど同じようなものに帰結する。答えがわかっているものを0から検討するのは時間と労力の無駄であるので、ある程度この辺が答えになるだろうな。。。の感覚を知っている我々から、「だいたいこの辺りを目標としてこういう取り組みをされるお客様が多いのですけど、そういうことですよね？」というPush形の議論でクライアントを誘導し、議論をリードするのが望ましく、ここに必要以上の脳のリソースと時間を投下すべきではない。実際に何かものができるわけでもない活動に必要以上の議論の工数を投下することは誰のためにもならない。
   

2. なにをやるのか？（課題はなにでそれに対してなに（アクション）をするのか？）のオプションもパクれる
   ”なぜ”が決まれば次になにを？を決める。”なぜ”に対しての”なにを”についても、実はそこまで多くのオプションが存在しているわけではなく、ここも社内の”わかってる人（有識者）”の力をフルで使いスピードを重視して一気に検討することが重要である。売上を伸ばすために必要なことは、認知をあげる、コンバージョンをあげる（途中の離脱を回避する）、継続的に購入してくれる人を増やす等の施策があり、では認知を上げるためには一般的にどんな施策をすれば良いのか？という一段下のレイヤーに関するアクションまで、やることは概ね決まっている（最先端のソリューションというのがあるいはあるかもしれないが、コンサルティング会社に依頼をする大企業はそれなりに実績のあるソリューションを求めるため、社内有識者が出してくれるオプション以上のものは求められないことが多い）。これを諸君らが0から検討するのはまさしく時間の無駄であり、時間の無駄はクライアントの予算の浪費であることを心得よう。
   また、”なにを”の目標は定量的に定める必要がある。例えば売り上げを２倍にする、コストを30％落とす、欠品率を3％下げる。なんでも良いのであるが、なぜやるのか？に紐づく形で、本来こうでなければならない状態を定量的に定義し、それに向かってなにをしなければいけないのか？を他の事例やクライアントの中長期計画等を一旦のインプットとして機械的に決めていくものであり、この具体的な数値もこのタイミングで時間をかけてやるものでもない。とりあえず決めることが大事であり、運用をしながら適宜見直せば良いのである。具体的な数字目標は未来の縛りになるために、この数字の議論を嫌がるお客さんも多いのであるが、ここは強い気持ちで一緒に決めましょうと迫る必要がある。数字を決めなければ振り返りができず、振り返りができなければそこに改善の余地がないからである。どうしてもお客さんが数字を決めたがらない時は、諸君らの上司のマネージャ以上を連れて行き、一緒に説得を試みるのが良いだろう。この数字の決定はクライアントの説得に時間を要することがあるが、数字の目標をいくつに設定するかについてはある程度の決め打ちとなるような場合が多く、脳のリソースを必要以上にかける所ではないと考えている。
   

3. 自分達の特別な部分は何なのか？は脳を使ってよく考える
   さて重要なのはここからである。上述は有識者を入れた一般論の議論として、いわば議論の「土台」を作る部分でありどんどん他所の知識をパクってスピード重視で作り上げてしまうことが重要である。
   その上で、土台の上にプロジェクト特有の議論そのものを作るのは諸君らの仕事であり、まさに脳のリソースと時間を費やす部分になる。例えば、売り上げを上げるためのアクションとして「認知をあげる」という施策が出てきた時、クライアントの顧客がどこにいるのかにより、一般的には筋の良い施策とされているものが、筋の悪い施策になることがある。我々はこの一般論との「差」がどこにあるのかについてフォーカスして脳のリソースを使う必要があり、そしてまさにここをクライアントと議論する必要がある。
   例えばクライアントのメインの客層が高齢者であり、デジタル機器のリテラシーが一般的なクライアントと明らかに異なるような場合、一般的なデジタルマーケティングの施策を打っても仕方がない。そのため、この場合はデジタルマーケティングではないマーケティング施策としてどんなことが一般的であり、そして効果を見込めそうなのか？というような方向に脳のリソースを使う必要があり、そしてその我々の仮説がクライアントにとっても納得のあるものであるのかの確認を議論を通して進める必要がある。
   以上は極端な例を挙げたものであるが、パクって問題ない所（むしろパクるべき所）と脳と時間を費やさなければいけない所を作業において明確に識別することで、諸君らの仕事のスピードは劇的に改善することを覚えておいてほしい。

• 悩まない
  我々はプロなのでアウトプットが全てである。どんなに時間を使って徹夜で悩んだとしても、アウトプットがなければ無駄である。無駄な時間を美談にしてはいけない。ただお客さんのお金がドブに流れただけである。答えを知らない人間が悩むことに意味はない。考えなければいけない。答えを知らないなら知る人を探す、調べる、そのようにしてインプットの量を上げるしかない。頭と手が止まっている場合はすぐにインプットを増やす方に舵を切ること。作業が進まないのはまだ考えるに値する材料がないことを意味しているからである。

筆者も全面的にこの意見に同意する。筆者は2021年現在、シニアマネージャであるのだが、仕事がどうにも終わらないチームメンバーの仕事を観察していると共通して「悩んで」しまい、一見手は動いているのだが、どこへ向かっているのか、このまま向かっていけばゴールへ到達するのか？がわからない状態で作業をしてしまっていることがわかる。この作業によって、この答えがわかる、という明確な目的意識を持たない作業はもはやゴミを作っているのと違いはない。
もし自分が今何を明らかにしたくてExcelやPPTを触っているのかがわからないのであれば、今諸君らがするべきは、手をとめ、上司ともう一度話すことだ。そのまま作業を続けてはいけない。

• 品質担保の手順を自分の中に持つこと
  さて、当然であるが高速でゴミを量産しても意味がない。速さは正確性とセットでなければならないし、両者は決してトレードオフの関係ではない。
  もちろん速度と品質の両立が難しいことは他の誰でもなく筆者が一番よく知る所である。当文書を読んでいる諸君らであればすぐに気づくと思われるが、筆者控えめに言ってミスが多い。諸君らの中に筆者同様、なぜそこを間違えるの？と自分で自分に突っ込んでしまうようなケアレスミスが多い読者がいるのであれば、アナリストの間にミスの多い自分との付き合い方を学んでおくことを推奨する。
  さて、ミスをする人はなぜミスをしてしまうのか。筆者が辿り着いた結論は、自分は確認（セルフチェック）はするが、そのチェック観点が主観的すぎるということであった。ミスの多い人間は、決まって自分は頑張ってセルフチェックしました。と発言する。実際に頑張ってセルフチェックしているのである。しかし、漫然とやっているに過ぎない。ある一つのチェックによってどのようなミスを減らしたいのか？の目的意識が希薄なのである。なので、いつまでやっても品質が上がらない。
  どのようなミスを減らしたいのか？という目的から、その類のミスはどのように減らすことができるのか？の方法・手順を考え、それをただただ自動的・機械的に適用することが品質担保には必要になのである。
  我々はパンや惣菜を作っているわけではないのだから「丹念に気持ちを込めて丁寧に作りました」等という言質は不要である。機械的に自動的にチェックをかけており、機械判別できない点については人の目で、このような観点で整合をチェックかけております。というような客観的で淡々とした説明こそがコンサルタントの作業の品質に迫力を持たせる。以下、具体的な方法論の例を紹介する。

1. 品質の拠り所になる正誤表を作れ
   サーバーとサーバが一つの文書に混在している等はわかりやすい例であるが、同じ意味の言葉が複数の表記でなされている場合、読者はその表記の違いが何らかの意味を持つものかと考えてしまう。このようないわゆる表記揺れを回避するためには、正誤表を作り文書を閉じる前に正誤表に基づいて一括検索を使ってチェックをおこなうことが必要である。どの表記を正とするかについては、原則としてクライアントが使っている言葉に合わせるのが一般的であるから、クライアントが提示している資料や仕様書等のベースライン文書の言葉遣いを採用し、正誤表を作るのが良いだろう。
   

2. コメントはすベて一覧化し対応表としてトレーサビリティを担保せよ
   言ったことがなおっていないといった指摘を回避するためには、言われたことを全て一つのコメント表にまとめ、それぞれの指摘に対してアウトプットはどの箇所をどう対応したのか？のトレースが可能になる中間資料を手元に持っておくと良い。どのように現時点のアウトプットを作成したのかについての自分の思考の整理にもなる。
   多くの人が閲覧する資料については多数の人からの指摘が同じ箇所に刺さり、どちらの指摘を正とすべきか？等のコンフリクトが発生する場合もあるため、より対応表の重要性が増す。指摘がコンフリクトした場合は、それぞれのコメント者、特にコメントを採用しない側に対し、その経緯を説明する必要がある。せっかくしたコメントが成果物に反映されていないと、コメントするモチベーションが失われ、不信感へと繋がっていくからである。
   継続的な更新が見込まれる文書についてはGit等の構成管理ツールの導入を検討する方が結果として管理工数の削減につながる場合もある。
   

3. セルフチェックリストを運用せよ
   自分が過去やってしまったミスについては一覧化しておくと良い。また頻出のケアレスミスを回避するための手段も記録し、関連する作業を行う際には作業の終了前に、そのリストに基づいてセルフチェックを行うのが良い。Excelの資料を作成するのであれば例えば、

   • ページ設定をプレビュー形式で確認したか？

   • 不要な作業シートが含まれていないことを確認したか？

   • PPT側の資料に記載されている数と一致していることを確認したか？
     等の具体的なアクション単位で指差し確認をするのが良いだろう。

プロジェクト進行におけるロジ（ファシリテーション）ができること

コンサルティング会社に勤務している諸君であれば、どこかで「ロジ」、という言葉を聞いたことがあるのではないだろうか。調達物流を表すロジスティックスの意味に加えて、最近は広く裏方調整業務のスキル、という意味合いでプロジェクトの現場では比較的広く使われており、筆者も筆者の同僚達も本来の調達物流とは別の意味合いで使っている場合が多い。筆者は勝手に「空気を読んでいい感じにやっておく能力」であると考えている。ロジ周りはあえてネガティブな言い方をすれば雑務である。その仕事自体に本質的なクライアントへの提供価値はない。しかし、ロジができない会社は本質的な価値を提供する以前にクライアントの心象を損ねてしまい、極めて不利な状況に追い込まれるのが実態である。例えばZoom会議がはじまる瞬間に資料の投影がいつまでもされず10分程浪費してしまったなんて会議を経験したことはないだろうか？その後、どんなに言葉を尽くした説明をしたとしても、何となくイケてない印象は拭えなかったのではないだろうか。そうならないためにも、円滑なロジの実現は当たり前に実現できている必要がある。
ロジは現場に最も近いアナリスト諸君らの使命であり、そして力の見せ所でもあることを忘れてはいけない。
では具体的にロジができる、とはどのようなことなのであろうか？以下はシーン別に見ていきたい。

1. 会議調整編
   もちろん会議調整ばかりをやるために諸君はコンサルタントになったわけではないのであろうが、パートナーやシニアマネージャの時間単価と諸君の単価を考えた時に誰でもできるロジ周りを誰が負担することがクライアントにとっても最も経済的であるか？を考えると、答えは必然的にアナリストになる。そして雑務を雑務と考えてはいけない。
   コンサルタントは一般的に月単価X00万円相当の超高級商材である。毎月車が買える。雑務も一流でなければいけない。雑務もただやれば良いというわけではなく、一流の雑務にはストーリーを感じさせる洗練された品質がある。
   特に会議調整はプロジェクトの全体スケジュール、マイルストンを意識し、どのタイミングで、誰が、何についてどこまで合意したのか？を逆算しなければできない高度な業務であり、ストーリー性が求められる。ただの調整タスクと考えずに会議という一つの舞台演出として取り組む必要がある。
   まず、会議調整は即効性が命である。タスクが発生した後、可能であれば１時間以内に実行すること。なぜか。マネージャ以上のスケジュールは30分単位で更新されており、１分の調整の遅れが結果として１週間のプロジェクト遅延へと波及するリスクがあるからである。すべてのタスクに優先して会議調整を行うことを推奨する。
   
   会議調整を頼まれた場合、確実にそのタイミングで以下を確認しておくこと。これがなぁなぁになると会議は失敗する。そして会議の調整依頼は会議終了１分前とかのギリギリのシーンで指示されることが多く、えてしてなぁなぁになりがちなのである。これは会議調整に限った話ではないが、何か仕事を頼まれた場合、その仕事を確実に終わらせるための情報は指示者にめんどくさがられても必殺の精神で刈り取るようにしよう。繰り返すが諸君らは会議の舞台監督である。会議の成功に責任を持っていると考えて万全を期してほしい。
   
   ・必須参加者、任意参加者
   ・何を決めるのか（アジェンダ）？
   ・会議時間
   ・場所（どう喋りたいのか、プロジェクタ、マイクは必要か）
   ・投影資料を誰が準備するのか？それのレビュー者、レビュータイミングはいつなのか？
   
   インビテーションに含まれる送信先の中で、会議が設定された背景がわからない人がいる場合は、詳細に上記、特に会議の主題、なぜその人が呼ばれているのかを明記すること。宛先の人間から「これ何の会議？」と聞かれたらインビテーションの出し方が良くないことの証左である。
   会議場所は特にリアル開催の場合注意が必要になる。クライアント会議の場合、しっかりと会社対会社でオフィシャルにやりたいのか、とりあえず温度感を探りに行きたく、相手に構えさせたくない雑談に近い形式でやりたいのかで確保する場所は当然変わる。前者の場合は机を挟み、公式さを演出する必要があり、ここの決定事項は引き返さないポイントになることをクライアントにも理解させる必要がある。また、会議室の椅子の数が出席者と比べて十分であるかは事前にチェックしておく必要があり、足りない場合は他の場所から借りる段取りをつける所までを行う必要がある。10名以上が出席する会議である場合、そもそもビルの中にそのような場所が限られることが多く、事前に予約をしておくか、複数会場からリモートで繋ぐ等の対応が必要になる場合もあるため、会議日程が決まった段階ですぐに場所を抑えておくことが重要になる。
   後者（相手に構えさせたくない会議）の場合、逆にカジュアルに話せるようなクライアントサイドのオープンスペースなどを利用し、机を挟まず、隣に座り、同じ画面を見ながら話すなど、なるべく手作り感、かつカジュアルさを演出すること。
   
   投影資料が複数にわたる場合、どのタイミングで何を投影すべきなのかを事前に確認し、また可能であれば会議場所は事前に訪問した上で、端末の規格とプロジェクタの規格が合っている（変換アダプタが必要なのか）か？大規模な会場である場合はマイクの使用方法、画面の切り替え方法などのリハーサルを想定する操作が予定通りできるかの確認を行うこと。特にマネジメント層が出席する会議で投影したい資料ができないといったロジ周りの印象は心象を損ね、会議のコンテンツ以前の問題としていけてない業者、いけてないスタッフとして烙印を押されることになりかねない。
   
   資料の印刷が必要な場合、印刷時間を考慮すること。製本を含めてかなり時間がかかる場合があるため、事前に印刷の要否、印刷断面の資料の締め切りは確認しておく必要がある。会議運営後は議事録を作成することになるため、大人数の場合は何らかの方法で全員の名前と役職、所属を把握できるようにしておくこと。白紙を回して名前を明記してもらう形でも良い。Zoom会議の場合は出席者をキャプチャで取っておくと便利である。議事録の作成については別途後述する。
   
   コンサルティング会社のマネージャ以上の人間の中には、自分は会議にきてただ喋れば良いと考えている人間も残念ながら一定数いることを忘れてはいけない。少しでも会議当日の段取りに不安を感じるところがあれば、はっきりするまで詳細を具体的に詰めていくことが当日に慌てるリスクを最小化する唯一の方法である。
   

2. PMOロール編
   諸君らに割り当てられたミッションがPMOロールという名前のついたロールでなかったとしても、一つのチームが運営される上ではPMOに近いタスクは多く発生する。それらを手早くこなし、プロジェクトが円滑に回せるように日々努力すること。これはアナリスト特有のタスクではないが、アナリストでもできることであるため、率先してやることを推奨する。スケジュール、WBS、課題管理、リスク管理、タスク管理表はどのプロジェクトにも概ね存在しているが、えてして期限が切れたり次のアクションが決まっていなかったりするものである。これらを決して無視しないこと。自分でどのように更新するべきかがわからない場合は、更新を目的とした会議をチーム全体にアナウンスし、誰が何をするのかを確認すること。管理簿はExcelでもカンバンなどのアジャイルツールでも良いが、原則として日次でトラックする場をアナリストが主導して設定していくとプロジェクトが活気付く。プロジェクトで作成した会議資料、受領資料、成果物を時系列に整理し、プロジェクト資産として定期的に整理すること。ディレクターのあの資料、どこだっけ？に対して数秒以内に回答ができるようになることを目指すこと。
   これらの資料は新規参画者がプロジェクトに来た際にも非常に有用な資産となりうる。各資料の作成・更新については後述することとする。

想定外に対してのエスカレーションがはやい

上司が認識できていない何か、が発生した場合、それが良いことであっても悪いことであってもTeamsやメールですぐに共有する必要がある。その事象が持つ意味合いを自分で解釈するのは非常に危険である。諸君らは知らないが、上司が既に持っている情報と諸君らが新たに手にした情報を組み合わせると、プロジェクトにとって非常に重要な意味をもつ情報になる可能性があるからである。
例えば、諸君らが明日の会議にA係長というクライアントが出席しない、という話を耳にしたとする。諸君らが見えている会議の中のアジェンダのみに限定すればこれ自体はさほど大きな意味を持たない情報かもしれない。しかし、上司は他のチームのアジェンダにおいて、A係長のサポートをもらいながら、B部長に対して何かしらの重大な決裁を迫ろうとしているかもしれない。諸君らが情報を共有しないと、B部長の決裁は予定通りもらうことができず、スケジュールに重大な遅延をもたらすかもしれない。これは諸君らがエスカレーションしないと上司はわかり得ないことである。
また、何かしらの違和感を感じた場合も同様にエスカレーションするのが良い。違和感とは、誰々が◯◯という発言をしていたが、これはどういう意味だったのかわからないが、自分の感覚として何となく嫌な感じがする、というような物を含める。違和感はその原因がわからなくとも上司に共有し、その違和感の正体を一緒に議論するのが得策である。筆者の経験上、大体その違和感は2週間後に爆弾になる。
ネガティブであることが明らかな事象についてのエスカレーションは一切の時間的・手段的配慮遠慮は不要である。上司にチャット、電話、時間に関わらず行うこと（繋がらない場合は考えられるすべての手段で行うこと）。深夜早朝であっても同様になる。その分は残業申請を行うこと。上司が不通の場合、さらにその上へとエスカレすること。自分で判断しない。これを鉄則すること。仮に大袈裟すぎると後で怒られたとしても、なぜエスカレーションしなかったのか？となるよりもはるかにマシである。

現場レイヤーのクライアント情報を解像度高く吸い上げることができる

マネージャ以上の社員は複数のプロジェクトを掛け持ちしている場合が多く、現場レイヤーのクライアントについて避ける時間は物理的に限られてしまう。そのため現場レベルのお客さんが何を考え、何を大切にしているのかをもっとも解像度高く理解できるのはアナリストレイヤーであることを自覚すること。毎日クライアントと何かしらのコミュニケーションをとり、彼女彼たちが何を考え何に困っているのかを理解することが重要になる。これは現場の一次情報として極めて重要なプロジェクトインプットになる。
特にクライアント現場におけるクライアント間のパワーバランスを把握することは現場に長い時間張り付いている諸君らにしかできない業務である。
例えばこんな事例を考えてみてほしい。諸君らのプロジェクトの長であるシニアマネージャが、今のプロジェクトとは別に追加スコープの提案を誰かに持っていきたいとする。この時、現場を知らないシニアマネージャは機械的にプロジェクトの体制図をみて、決裁権を持っているであろうB部長に話をしにいこうと考える。
しかし、B部長は基本的には部下の主張や当事者意識を尊重するタイプの人であり、実質的な現場リーダーはC係長であったとする。
上記のようなケースにおいて、C係長の存在、そしてC係長を説得すればB部長の決裁は手続き的に終わるであろうことをシニアマネージャにインプットするのは諸君ら現場にいるコンサルタントだけができる仕事なのである。クライアントを全身を目にしてよく見ておくこと。これが結果としてプロジェクトを助けることになる。

また、今現在現場で発生している細やかな問題があるのであれば、それらの問題について自分なりの原因と解決策の仮説を立て、定期的に上司やマネージャと議論するとよい。そしてそれがプロジェクトスコープであるかどうかにかかわらず俯瞰的に、真の問題はどこにあるのかを常にコンサルタントとして追求することが必要である。
例えば諸君らのカウンターである購買部のクライアントが月末になると締め処理に終われ、会議設定すらできなくなってしまい、それが恒常的に数ヶ月続いているとする。それ自体は諸君らの責任でもなんでもないし、プロジェクトスコープ上、解決する義理もないのかもしれない。しかし、恒常的に業務ピークが月末に寄っていて、定時での業務完了すらもままならない状態であるならば、そこには大きな課題が隠されている可能性がある。そもそもなぜそんなことになってしまうのか？をよく観察し、どうすれば解決するのかを上司やクライアントとも議論してみるとよい。これが未来の諸君らの飯の種になるかもしれないからである。

上記のようなアクティブな観察やコミュニケーションは週次の大きな会議に出ているだけではこのような関係は当然作れない。何かしらの方法で現場レベルのクライアントとカジュアルなコミュニケーションが可能になる方法（グループチャットツール等）を自ら構築し、クライアントに関連するニュースがあればそれに対する感想をつけて送ってみる等、カジュアルに話せる関係性を作っておくことが重要である。
オンサイトであれば毎日、5分でも時間を作ってもらいこちらの作業の状況や相手の作業の状況を作るように心がけることが重要である（チャットツールは必ずマネージャ以上を宛先に入れ、個別連絡にならないように注意する必要がある。クローズドなコミュニケーションの場はハラスメントの温床になる等、思わぬトラブルを招く可能性があるため）。

No surprisesの徹底

コンサルティング会社のマネージャはコーチングタイプで言うところのいわゆる「コントローラー」タイプのキャラクターが多いと言われている。コントローラータイプは物事を自分のストーリーにそって進めることを喜びとするため、そこに想定外の事象が発生した時に諸君らが思っている以上に拒絶的な反応を示す場合がある。
そのため、会議資料については同席するマネージャレベルについては事前に閲覧してもらい、文言のニュアンスを含めてチェックをしてもらうことがベストであるし、それが不可能な場合であれば、そのマネージャの守備範囲についてだけでも事前にレビューをもらっておく等の事前調整を怠ってはいけない。この社内レビュー巡業は非常に手間がかかるが、それこそが品質担保の手順となるため、自分の判断のみで資料（特に数字を含むものは、プロジェクトの今後をミスリードしかねない）については外部に出してはならない。
これはクライアントに対しても同様である。クライアントのマネジメント報告にあたっては事前に現場レイヤーのクライアントに報告内容を確認してもらい、報告のニュアンスやエスカレーションすべき事項の抜け漏れをチェックしてもらう必要がある。マネジメント報告の場で現場のクライアントの検知していない問題がある場合、マネジメントがそのクライアントの管理不届をその場で糾弾しはじめる場合もあり、そうなれば現場のクライアントの信頼回復が非常に困難になる。あらゆる場面においてNo surprisesを徹底すること。

アナリスト編：頻出業務の要諦

コンサルタントの日々の業務はそのプロジェクトの特性に応じて変化するために、手順の一般化が難しいものであるが、アナリストが日々行うこととなる業務というのはある程度類型化が可能であると考えるため、思いつく限りを記載したい。

議事メモ・議事録の作成

昨今音声入力精度の向上によって、会議内容を機械が自動的に文字に起こしてくれるサービスが一般的になっているようであるが、幸か不幸かコンサルティング会社でアナリストを経験することができた諸君達においては、筆者個人の思いとして是非議事録を綺麗に書けるようになって欲しいと考えている。なぜなら議事録とは文字起こしではないし、文字起こしをすべて読んでいる時間は多忙なコンサルタントにはないからである。

議事が美しく書ける、ということはその会議の目的・文脈、要点、そしてこの次何をすべきであるのか？を証明する最も簡潔な手段であり、逆も然り（書けない奴は何もわかっていないことの証明）である。では記載にあたり何を心がければ良いのだろうか？

1. 会議前準備
   準備が万事である。投影資料がある場合、読み込んでおくこと。そして、その会議がどのような帰結になるのかをシミュレーションしておくこと。誰が何を言えば成功で何が決まらなければ失敗なのかを事前に仮説として持っておくとよい。少し極端な例にはなるのだが、筆者はかつて上司から、会議前に議事録くらいは書き終えておけと怒られたことがあり、当時はそんなことは無理だと思っていたのだが、自分が説明する内容とクライアントをどう誘導させるのか？のイメージがあれば、実際には５割程度の内容は会議前に書き終えることができるはずなのである。
   

2. 会議中
   ここは全集中でとにかく聴く、という他にあまりないが、端末を使ってメモをとる場合、タイプ音が議論の邪魔になる場合があるため、その点のみ注意してほしい。
   

3. 会議後ドラフト作成
   不明点は会議終了直後に上司やクライアントを捕まえて解消しておくのがよい。その場で解消する癖をつけなければいけない。ただし、不明用語、業界用語を自身が知らないだけの場合もあるので、念のため会議中にググった上で質問すること。
   議事録は所定のフォーマットが必ずプロジェクトには存在しているため、クライアントか上司にフォーマットを確認し、そのフォーマットと粒度に沿って作成すること。
   議事はオフィシャルに書いたとしても会議時間そのものよりも時間をかけてはいけないというのが一般的に言われることであり、そのため録音をした上で文字を起こすというのは二重の手間となるため、原則として認めない。絶対に聞き逃すことができずまた、技術的、業界専門的で理解が難しい内容に限り、クライアントの許可を得て録音すること（また音声ファイルの扱いには十分に注意すること）。
   議事録の取り方はプロジェクトの作法に依存するところが大きいが、基本的には議論した内容が重要であり、資料の冒頭を説明している箇所は（資料に沿って説明）などの記載とし、投影資料とのリファレンスを取るなどで代替することで議事録の分量を減らし、また討議内容にフォーカスした議事とすることができる。
   議事録は原則としてドラフトは当日中に社内に展開すること。
   当日が難しい場合は翌日の午前がデッドラインである。この期限が守れないのであれば他の作業との優先度を調整するか、既にタスクが溢れている可能性が高いため、タスクシェアを上司と相談すること。

各種資料の作成

コンサルタントといえば大事なポイントが３つ書かれたスライド。そんなことを考えながら綺麗な紙を書ける自分をイメージしてコンサルティング会社に入った人も諸君らの中には多いのではないだろうか。
ところで、筆者は紙を書くのが苦手である。というか、そもそも生まれつきの面倒くさがりであり、できるだけ最小の工数で最大の成果を得たいと常日頃考え、みんなが頑張っているプロセスをなんとか省けないかと考えながら生きている人間である。概ねそういった邪念を抱きながら生きているとろくなことがないのであるが、仕事をする上においてはこれがプラスに作用することも少なくない。特にこの資料作成については、どれくらい良い意味でサボれるのか？が諸君らの生産性に大きく影響を及ぼす。

筆者は目的達成のために最もチープな手段こそが最も価値があると信じるものである。なので、資料を作らずして目的を達成する。これが仕事の仕方として筆者は最も価値が高いと考える。
仕事をはやく終わらせたいのであれば、いかに美しく紙を書くか？に頭を使うのではなく、如何に書く紙を減らすか？にこそ頭を使うべきである。

さて、以下具体的に資料を作ることになった場合を想定して、留意すべきポイントを記載したい。

1. 本当にその資料は必要なのかを考えよう
   そもそもなぜ資料を書く必要があるのであろうか？諸君らにおいては、資料を書き始める前に冷静になってこれを今一度考えて欲しい。すべての資料には目的がある。逆にいえば、目的を達成できるのであれば資料はなくても良いのである。資料はどこまで書いても資料でしかない。そして資料は沼である。こだわろうと思えばいくらでもこだわることができるし、時間はどこまでも溶けていく。
   我々コンサルタントはクライアントを変革に導く仕事であるからして、変革に必要な情報が過不足なくそこにのっていれば資料としては十分であり、その資料に絵画的・芸術的な加点要素は必要ないと筆者は思っている（ここについては議論の余地があるはずであり、諸君らの上司とぜひ話してみてほしい）。
   例えば、AなのかBなのか、現場のクライアントの温度感を確認するくらいの話である場合、ゼロからスライドを作り、それをベースに30分間の会議をセットしてプレゼンテーションをし、議事録を作るのであろうか？そんなことをしていたらいつまでたっても仕事は終わらない。上記は極端な例ではあるのだが、実際のプロジェクトになると上記に近からず遠からずの状態が発生し、無限に工数を浪費していく地獄のような状況が比較的カジュアルに発生するのである。PPTを開く前に深呼吸しながら以下を考えてみよう。

   • 現時点の現場のクライアントの温度感を非公式に把握するなど、チャットや立ち話でクライアントに「うん。」といってもらえればすむ話ではないのか？

   • 書くにしても１スライド、あるいはExcel等の活字レベルの情報で議論できるような内容ではないのか（絵によるビジュアル化が本当に必要なことなのだろうか）？

   • 念の為、提案書上で作成物として定義されている資料ではないか（ないのであれば絶対に作らなければいけない訳ではない）？
     

2. 読む人は誰なのか、そして読む人にどうリアクションして欲しいのかを想像しよう
   例えば現場の前提が込み入っていたり、データを見せての議論が必要である、というようなビジュアライズがある程度必要な議論が予想される場合はPPTを使わざる得ないだろう。しかしまだ紙を開くのは早い。まず以下を想像しよう。その想像が終わるまで、PPTを開いてはいけない。
   

   • その紙を読む人は誰だろうか？紙である以上、読み手がいる。そして読み手がわかる内容が書いていなければその紙はゴミである。
     まずその紙の読み手の現在地点を想像しよう。彼女彼は今何を考えているのだろうか。そもそも諸君らの会社が自分に関連していることを知っているのだろうか？知っている場合、どんな印象を持っているだろうか？

   • 彼女彼らのミッションはなんだろうか？仕事で何を達成できれば嬉しくて、何が発生すると困ってしまう人なのだろうか？今一番の関心ごとはなんなのだろうか？
     このプロジェクト自体のことを知っているのであれば、どの断面の情報をどの程度今時点で知っているのであろうか。

   • 読んだ人がどんなリアクションをしてくれたらその会議は成功になるのだろうか？
     私たちはその人の承認が欲しいのだろうか？それとも情報を共有したいだけなのだろうか？あるいは何かしらの情報の提供やアクションをしてもらう必要性があるのだろうか？会議が終わった時の会議室の空気を想像してみよう。どうなっているのが全員がハッピーなのだろうか。

   • してほしいリアクションを読み手にしてもらうために、読み手が気にするポイントはなんであろうか？意思決定をして欲しい場合、どんな情報があれば、読み手は決めることができるのだろうか？
     

3. 最低限のメッセージだけで起承転結を書いてみよう
   繰り返しになるが、資料は目的達成のためにチープであればチープであるほど良い。
   ２で想像したイメージをもとに、どんなストーリーの紙であればクライアントから欲しいリアクションを獲得できるかを考えて、必要最低限のメッセージだけを活字で書いてみよう。まだこのタイミングでは図やグラフは作成してはいけない。
   読み手からなんらかの合意や承認を取り付けたい場合は、筆者の経験的には以下のような資料構成になる場合が多い。
   

   1. 打合せの背景と目的
      この打合せが開かれた理由。読み手がこの会議に必要な理由。読み手と我々はどのような関係性であるかの説明。この会議によって決めることが、読み手にとってどのような意味（メリットあるいはデメリット）があるのかの説明を概要として示す。

   2. 現状の整理
      今何が起きているのか？を可能な限り客観的に事実をベースに示す。このタイミングでは諸君らの意思や思いを書いてはいけない。クライアントを含めて、我々が直面している状況をありのまま、正確に記述する。読み手のクライアントに関連する部分についてはハイライトする等、興味を持ってもらえるように工夫する。

   3. 現状についての評価
      今何が起きていることについて、客観的な評価を示す。基本的にはヤバいよ、ということを伝えにきている場なので、どの程度ヤバいのかを定量的に示せるようにデータを示すと良い。一般的な事例との比較を使うのが有効である。

   4. 対応案
      今何が起きているヤバいこと、についてじゃあどうすれば良いのか？を示す。この際、一つの対応策だけを示されると他の方法はないのか？という話になってしまうため、とりあえずなんでも良いので３案くらいは持っていく。その中で本命の案の合理性を説いてそこに着地できるとスマートである。

   5. 今後の段取りとやって欲しいことの説明
      対応案を合意できたら今後どのようにプロジェクトが進んでいくのかの段取りを説明する。そしてもし読み手のクライアントに何かしらのアクションをしてもらう必要があるのであれば、いつまでに何をして欲しいのかを具体的に明示する。次のタッチポイントとなる会議をいつ頃設定するかまでここで話しておくのが良い。
      
      1-3までの筋書きを2時間以内に実施できると理想的である。3が書き終えた段階で一度上司や同僚とこのような話し方にしたいと思います。というところを説明して合意するのが良い。
      

4. スライドの見栄えをよくしよう
   合意ができたらスライドを磨き込もう。特に事実を見せるためのデータについては可能な限り事実を正確にかつわかりやすく理解してもらうために図表を使う等の工夫をするのが良い。一方で、こだわり出すとキリがない所ではあるので、2時間程度を目処に磨き込みを行い、それ以上の品質を求めるかどうかは上司と相談しながら決めるのが良いだろう。
   以下は磨き込みの際に気をつけるポイントとなる。スライドの見栄えをどのように美しくするかは各種デザインに関する本を各自で参考として欲しい。

   • いかにネガティブなことであっても、可能な限りポジティブな書き方をしよう（「〇〇がない。」ではなく、「〇〇をいつまでに、実装することが、〇〇のために重要、必要、」といった書き方が推奨される）。

   • 色を多用するのはやめよう。色が多いとどこを見れば良いのかがわからなくなってしまう。基本的には２色のみでとどめ、白黒印刷でも伝わる資料を目指そう。

   • 特に複数人で同じスライドを更新するような場合、会議のギリギリまで修正アップデートが行われることがよくあるため、どれが最新版であるのか？がわからなくなってしまう所謂デグレ問題が発生する。このデグレはプロジェクト全体のモチベーションを一気に下げる事象であるため、細心の注意を払ってファイルのマスタ管理を行ってほしい。
     Gitを用いた管理までを行うことは稀であろうが、Teamsの共同編集機能を用いる、定期的に断面管理を行う等して最新版の取り扱いには最大限の注意を払おう。
     これを失敗すると言いたい紙が本番でない、等の大惨事が待っている。

   • 最終的な品質担保を行うのは自分であるという自覚を持ち、アップデート個所は確認するとともに、最初のページと後のページでいっていることに齟齬はないか？各ページで使用されている数字のインプットにずれはないか？用語にゆれはないか？フォント、体裁や使っている色にばらつきはないか？リファレンスは壊れていないか？他プロジェクトの用語が残ってしまっていないか？等の細やかなチェックを行えるとアナリストとして非常に重宝される。確認観点はリスト化しておくとよい。

以降ではアナリスト諸君らが頻繁に作成するであろう資料について、作成の要所を記載する。

進捗報告資料　

週次進捗定例、月次進捗定例等の名のついた会議体で現状報告を行うために使われる資料であり、通常アカウントやプロジェクトで使われている所定のフォーマットがあり、それに基づき記載することになる。
この資料の目指すところは、プロジェクト進行上の課題の有無とその影響の度合い、その対応方針を示すことであり、逆にそれだけはっきり書かれていれば良い。資料の構成は概ね、サマリ、全体スケジュールにおける現状（稲妻線）、各領域別の詳細報告（遅延の度合い、規模、課題、リスクの有無の報告）、ToDo確認となる。どのプロジェクトであってもこれらのコンテンツが入ってくることは変わらない。
どのように書いても退屈な資料になりがちであるため、資料の中でサビとなるポイントを意識して書くことが必要である。
例えば直近の設計工程完了にあたり、この領域に大きな遅延リスクがある。しかし、これはこういう方針をもってして、良い感じに落ち着く予定であるが、なにかご意見あるか、というようなハイライトシーンを２，３つくっておくと全体的に締まりのある報告となる。
強弱なく説明されると聞き手は飽きるのである。このサビのポイントをどこに置くかは社内でよく討議するとよい。
また進捗報告資料は各領域の進捗をクライアントのPMレベルに報告するのが常であるため、各領域進捗は会議前にクライアントの各領域進捗担当と合意すること。進捗会議で一番恐ろしい事態は、コンサル会社が勝手に書いた、と各領域担当に梯子を外されることである。各領域担当と一体、ワンチームとなり、状況をクライアントの上層部にレポートし、対応を討議する下準備が何よりも重要になる。

1. 進捗は定量的に示すことが必要であるが、これがなかなか難しい。なぜなら特にコンサルティング業務である場合、3日かけて作業したら50％、その倍の時間をかければ100%の進捗になる、といった簡単なものではなく、その進捗の度合いをいかにしてはかるかは非常に困難であるからである。そもそも検討資料作成について、何をもってして10％の進捗とするのか？はかなり哲学的な問いとなる。100ページ作ると最初から決まっているわけでもないので、10ページかいたら10％にもならないし、内容がカスであればそれは何の進捗にもなりえない。ので、通常は資料について誰の承認までを得たのか、等で進捗を図ることが多いが、このあたりの哲学議論に時間を費やすと肝心な検討そのものに割く時間が削られるため、上司ととっとといったんこうしましょうという決めをつけて進めるのが良い。クライアントにも、なぜこれは10％といわれるのか？と問われることがあると思うが、いったんこういうルールで記載しています。ということが説明できればそこまでうるさくいってくる人は筆者の経験上少ない。
   

2. 最も重要な点であるが進捗資料であるため、進捗が明確に根拠を持って書かれていないといけない。進捗とは極論、オンスケか遅延かのニ択であり、これが記載されていない進捗報告はどんなにページを重ねてもただのゴミである。遅延である。その場合は何日分の遅延である。なぜ発生しているのか。そして今後どうするつもりなのか。これが書かれて入れば最悪1ページで報告はできる。変なディテールの作りこみよりも、これを徹底的に説明し、対応を議論すべきである。過去筆者が敬愛する先輩で進捗ステータスを「着手中」「やや遅延」と記載し、社内レビューで爆散した人がいるため、彼らの屍を超え、不要な怒られは回避するように努めたいところである。

3. 課題、リスク、ToDoについては、それぞれの性質をしっかりと理解し、書き分ける必要がある。よく、いつまでに何々をしなければならないことを課題と呼んだり、明日こうなってしまったらどうしようといったことを課題と呼んだりする人がいるのだが、これをコンサルがやっているとかなり恥ずかしい。コンサルのくせに課題の定義を理解していない人間とみなされるからである。
   課題、リスク、ToDoはPMO用語として明確な規定があるため、それは必ず自主学習をしておくことを求めたい。
   ざっくり言えば、今後おこるとヤバいまだ起こっていないことはリスク、既に発生してしまったヤバいことは課題、やらないといけないことがToDoである。リスクが顕在化すれば課題になり、課題に対するアクションはToDoへと落ちる。これは最低限の定義として理解してほしい。
   リスクは天変地異を含めて可能性を言い出したらキリがないため、発生したらプロジェクトが詰みになるレベルの影響があり、かつまぁまぁ起こりうるものをピックして記載し、その対応をクライアントと議論する必要がある。
   対応をとる場合は当然追加で予算であったり人手が必要になったりするので、そこまでしてリスク対応をとるのか？取った方が良いと思っているのか？が討議のポイントとなる。リスク管理についてはあまり重要視されないことが多いのであるが、筆者としては発生する可能性がある程度高いリスクに対していかに先回りして対策をとっておけるかがPMO本来の肝であり最も大事な機能と考えている。
   ToDoについては特にお客さんに動いてもらわなければならないことを明確に期限を提示して会議の中で渡し切る必要がある。クライアントがやらなければならないことをクライアントに依頼することについては遠慮する必要はない。淡々と依頼すること。クライアントでやるべき庶務業務をコンサルに負担させようとするクライアントも残念ながらたまに存在するのであるが、それらを引き受けていると、ただの時間単価の高い庶務代行となってしまい会社自体の品格が長期的に傷つくことになってしまうことを理解してほしい。クライアント自身でできることを我々がやることはクライアントの予算の無駄になることをマネージャを通してでもクライアントに説明してもらう等して、我々は我々がやるべきことに集中する必要がある。
   課題については、どんな課題なのか、このまま放っておくと何がおこってしまうのか、なぜ起きてしまったのか。どうすればよいのか、を明記するようにしたい。課題管理簿のみを会議に出席していない人が見ることもあるため、なるべく背景や影響を含めて詳細に記載する方が良い。

課題検討資料

思考の柔軟性とスピードが求められ、これが書けるとスタッフとして重宝されるのがこの種の資料である。プロジェクト進行上、何かしらの課題や討議のポイント（論点）が発生した際に、その論点を決着させるために作られる資料となる。論点はプロジェクトにより様々であるが、筆者の場合であればＡという業務目的を実現するにあたり、もっともよいソリューションパッケージはどれか？この進捗遅延あるいはシステム機能上の不全を解消するために、どのようなオプションがありえるのか（システム改修か運用回避か）？といった点をクライアントを含む関係者全員で合意するための資料であることがキャリアを通して多かったように思う。
この種の資料はまったく論点や背景を理解していないクライアントの現場の人やマネジメントが読む可能性があるため、なぜこれが問題なのか、解決しないとどうなるのか？を誰が読んでもわかるように記載できるかどうかが重要である。ここで興味をもってもらえなければ会議自体が失敗する。

資料の構成は以下のようになることが一般的である。スライドが９枚以上になるのであればなんとなく書いてある紙が含まれている場合もあるため、伝えたいことを削ぎ落とし、どの紙だけあれば言いたいことを説明し切れるのか？をストイックに研ぎ澄ましていくことが重要である。課題検討資料においては、以下のコンテンツは最低限含まれていることが理想である。

• 今何がおきているのか（症状はなんなんのか）

• なぜおきているのか（原因）

• ではどうすればよいと思っているのか

• どんなオプションがあるのか

• オプションを選ぶにあたって重視する観点はなんなのか

• 重視する観点を踏まえるとどのオプションがベストなのか

もし手が進まない場合はインプットが不足している可能性が高いため、有識者ヒアリングを行うなどの手段を上司と相談する必要がある。資料自体は気合いをいれれば3-4時間程度で書き終わるため、上記を作るための正しい情報の収集に時間を割くことが重要となる。なお、オプションはとりあえず松竹梅の3案示して本命を竹に設定しておくと良い。

詳細の説明は引用しているような行動経済学の本にお任せするが、何かの意思決定を誰かに求める場合、選ばせる人間に選択の余地を残しておくことが重要である。自分で選んだかどうかは意思決定者の当事者意識に大きく影響を及ぼすし、1案しか提示しない場合、他に考えられる可能性はないの？と痛くもない腹を探られ結局他の案を無理矢理に捻り出すことになる。

それであれば最初から3案を作っておいた方が気が利くコンサルタントとしての印象を最初から与えることができるし、結果として早く仕事が片付く。クライアントも我々が作った資料を使って誰か（取締役であったり株主であったり）に対して説明巡業をする場合が多く、クライアントが説明をしやすいようなストーリーにするためにも、複数案を作っておくことは有益である。引用した文にあるように3案それぞれの長所短所を作っておき、本命が最もポイントが高くなるように見せることが重要である。松竹梅で出された場合、ほとんどの人間は竹を選ぶ。

マネジメント報告資料

いわゆる中間報告資料、最終報告資料である。これはどのようなプロジェクトをやっているのか？にもよるが、中長期のロードマップ等が中心になるであろう。
マネジメント報告資料に関しては基本的にはその骨子、メッセージはシニアマネージャやパートナークラスがメッセージスクリプトを作るべきであるため、アナリスト諸君らはよっぽどでない限りはそれに従えばよい。スタッフとしてはそのメッセージを自分の言葉として理解し、部品となるエビデンスを書くように務めること。メッセージが出てこないシニアマネージャやパートナーはいわゆるFake野郎である可能性が高いので、別ルートで内部エスカレーションをする等するほうに舵をきることも選択肢として考慮すること。エスカレーションの仕方は別記する。

PMO関連資料の作成と更新

1. WBSとスケジュール　
   プロジェクトのマスタスケジュールをアナリストの諸君らが引く事は基本的にはないであろうが、自分のチームや作業のWBSやスケジュールを作ることはあり得るため、基本的な考え方を記載しておきたい。
   まず、WBSである。まずは提案書あるいはプロジェクト計画書に記載されている作業の中で自分のチームあるいは自分自身が担当する作業工程を確認する。提案をしっかりと書き込んであるプロジェクトであれば、その資料の中で既にある程度の成果物イメージや作業アプローチが定義されており、それがインプットとなる。提案書やプロジェクト計画書はおそらく週単位のスケジュールのレベルとなっているため、これを細かく分解し、自分自身が1日1日、何をすれば良いのかの手触りが持てるようになるまで作業として分解していく。例えば「あるべき業務フローの整理」という工程が一つの矢羽としてスケジュールに記載されていた場合、具体的に何が終われば業務フローの整理が終わったことになるのか？を考え、作業分解していく必要がある。業務フローの整理の場合であれば、
   例えば、

   • 他案件の参考資料の収集（同様の業務や事例の収集）

   • サンプル業務フローの作成

   • サンプル業務フローの内部レビューと指摘反映

   • サンプル業務フローのクライアントレビューと指摘反映

   • 購買業務領域業務フロードラフト作成
     
     程度の、数日でおわり、書く作業のおわりの条件が明確になる単位にばらしていく。ばらしの単位は大きくなりすぎず、細かくなりすぎずの塩梅が難しいのであるが、今自分がやっていることがなんなのかが周囲の誰からみても明らかになるような粒度にするとよいであろう。例えばプロジェクト管理。とかであると、具体的に何をしているのかはわからないが、請求業務通常系の業務フローのドラフト作成。であれば同じプロジェクトの人間であればどのような成果物がその作業の結果出てくるのかの想像が可能になるため、それくらいの粒度感であれば基本的には文句は言われない。
     
     WBSをばらし終わった後はそれを並べてスケジュールとする。スケジュールを引くときはまずスケジュールの制約となるマイルストンを先に整理するとよい。マイルストンを言い換えるならば、この時までにこれをやらないと死ぬ期限である。
     典型的な物で言うとクライアント内部の取締役会、マネジメント報告会等があり、このマイルストンを目指して我々の検討のスケジュールがひかれる、ということはよくある。クライアントの業務上のマイルストンがスケジュールに大きく影響する場合もある。例えば請求系のプロジェクトである場合は請求書発行や経理の〆等は業務上の重大なマイルストンとなるため、その期限までに何がどこまで終わっていなければならないのかをクライアントによく確認する必要がある。クライアントがクライアントのお客様や外部事業者に対して何らかのコミットメントをしている場合、それらの期限もスケジュール上加味する必要がある。官公庁等のクライアントの場合、調達の公示スケジュール等もマイルストンとなりスケジュールを引く上での制約要素となる。経理部等の特定の繁忙期を抱えているクライアントに関しては、特定の週は会議設定すらできない等の落とし穴もあるので、スケジュールを作成する際に最初にクライアントによく確認しておくことが望ましい。
     
     作成したスケジュールは更新のタイミングを決めておくと共に、プロジェクト全体でスケジュールの現在地を共有・議論する場を最低でも週次で良いすると良い。
     プロジェクト立ち上げ時など、不確定要素が多く、各人の生産性が安定していないタイミングでは週２或いは日次で開催するいったこともあり、状況を見て柔軟に判断するとよい。筆者はコロナによるリモートワークになって以降、日次で朝会と夕会15分ずつで実施するようにしていた。

2. 各種管理簿作成
   昨今はTeams上でPlannerを使うこともあるが、クライアントと一緒にひとつの課題管理簿、リスク管理簿、ToDo管理簿等を作成する場合がある。通常これらの管理簿は用途に応じて別々に作成することが望ましいとされるが、実運用上、管理簿が複数存在するとどの管理簿がアクティブでどの管理簿は事実上運用されていないのかがわからなくなる等の運用上の問題が後々発生することがあり、工数を一元的に把握するという観点からは一つの管理簿になにもかも突っ込み、各レコードが課題なのかリスクなのかToDoなのかのフラグで識別するような形をとる方が良い場合もある。この辺りはプロジェクトオーナーの好みが分かれるため、作成時に討議すると良い。それぞれの管理簿に何を記載するべきかは、基本的に社内の誰かが先輩が過去に使っていた管理簿があることが多く、それを流用しつつ、プロジェクトの特性に応じて不必要なカラムは削除し、必要なカラムを付け足せばよい。
   スケジュールと同様、一つ一つのレコードのステータスについては最低週次でその進捗を追いかける場をプロジェクトで持つとよい。全員の目に触れない管理簿は必ず形骸化するため、目に触れる場所に置き続けることが重要である。
   また、期限が過去日のままになっている等、明らかに現状と異なる物については放置せず、その対応をプロジェクト内で議論し、新たな期限を引き直すなどの更新を随時行うこと。
   

日報作成

筆者自身はスタッフ時代にまともに作成した記憶がほとんどないのであるが、昨今労働時間管理が厳格になっている業界事情を考慮すると適切な粒度で日報作成をしておくことが自分自身のみならず上司たちを救うことにもなるため（部下の労働時間の管理は義務であるため）、自主的にでも作成しておくことを推奨する。
日報は1時間単位で何をしていたのか、そのタスクの結果、何がアウトプットとして作られたのかを必ず記載すること。「で、アウトプットはなんなの？」と必ず聞かれるため、作業結果はこれです。この作業における自分の付加価値（何がお客さんにとって＋になったのか）はこれです。は日々説明できるようにしておくとよい。

アナリスト編：サバイバルTips集

以降は業務を効率で円滑そして何より楽しく進める上で役立つTips集として読んでいただきたい。

クライアントフェイシング編

1. クライアントの業界・仕事そのものに興味を持つ　
   現場のクライアントとのリレーションを深めるためには相手へのリスペクトが必須である。クライアントの会社や業界がどのような歴史的経緯で発展し、今の事業をするにいたったかはクライアント以上に理解し、その歴史と価値にリスペクトを示すこと。リスペクトとは相手に対しての深い理解である。アサインのタイミングでクライアントに関連する本をAmazonで最低3冊は購入し、読み理解すること。
   これはコンサルと名のつく仕事をする人間であるのなら必ずやらなければならない。最新のトレンドは把握し、クライアントや業界に関する日経新聞の記事は用語検索やタグ機能を用いて最新情報が常に読めるようにしておくこと。
   クライアントの業界特有の資格がある場合可能であれば取得してみることを推奨する。特に現場のクライアントや叩き上げのマネジメントは、同じ苦労、同じ目線を持った人間に心を開く。そしてそれがリレーションとなり自分自身の武器と専門性になっていく。
   筆者はなにかと無線通信系の仕事に縁のある星に生まれたようで、クライアント理解のために実際には一度も使ったことはないのであるがアマチュア無線技士の免許を取得している。普段特に持っていて得をすることもないのであるが、通信業界におけるエンジニアのクライアントとの初対面の際に、ちょっとした話のネタとして使えるし、少なくとも技術について勉強をする姿勢を敬意として示すことができるため、クライアントリレーションの観点から非常に効果的な取り組みだと考えている。
   

2. 会議はクライアントに喋らせろ
   これは非常に良くある失敗であるが、書いてきた紙が打ち合わせの制約になってしまうのはよくない会議であると筆者は考えている。もちろん紙を準備するのは大切である。しかし、会議は出席者間で目線を合わせることが一番の目的であるため、その紙に書いてあること以外のことをクライアントが話しはじめた時、無理やり自分の紙に書いてある内容に議論を引き戻そうとすると、クライアントが重要だと思っているのにも関わらずこちらが見落としている何かに気づかないことがある。
   大切なことはなぜその人は今、この場で、私たちに、これを伝えているのか？をイメージし、その裏側にある隠れたSOSを掘り出すことである。SOSの形をすぐに掘り出せない場合は、その場で「今お話しいただいているのって、こういうことですか？」というような形で自分等の仕事との関連を探すように努めよう。両者が繋がった時、これまで自分達が捉えていた課題がいかに平面的であるかに気付けるかもしれない。
   

3. 大人数の会議を開く前に不確定要素を可能な限り潰すこと
   例えばクライアントの役員以上に何かしらの承認をもらうような会議があったとしよう。相場には部長以下、様々なレイヤーのクライアントが経理部、購買部、営業部、製造計画部から出席するとする。この際、役員以外のクライアントがその議題に対してどのような意見をもっているのかがわかっていない状態でこの会議を開催してはいけない。これは必ずと言って良いほど失敗する。
   役員以上のレイヤーの多くは、その議題が現場レイヤーのクライアントの中でどの程度議論されているものなのか、誰の意思であるかを気にする。そのため、現場レイヤーのクライアントが我々がもってきているアジェンダについて「？」と言う顔をした瞬間に会議はお葬式になってしまう。そしてコンサルティング会社もキャリアレベルが上がれば上がるほどこの辺りの現場調整を細かくする時間が限られてしまう。そのため、ここはコンサルタント・アナリストクラスの諸君らの腕の見せ所となる。
   具体的に言おう。例えば既存の購買システムや業務のあり方について何かしらの問題点があり、このやり方を変更するために、予算が必要で、それを役員に承認を得る必要がある場合を想定しよう。この際、本来であればこの議題は、その業務の主管であるクライアントの購買部が起票する形として、コンサルタントはそれの支援として資料作成を行う、といった役割分担とするのが望ましい。もしクライアント側にプレゼンテーションスキルの不安がある場合は、コンサルタントが代弁することも可能であるが、必ず購買部の代わりの人間として意見を述べていることをしっかりと意識しながらプレゼンテーションを行い、説明の最後には、補足はありますか？と言う形でクライアントに一度マイクを渡すことが必要である。このような段取りで進めるために、資料は必ず事前に購買部のクライアントと議論を重ね、マイクを渡すタイミングを含めて合意して会議に臨むべきである。
   加えて、この業務によって影響を及ぼすであろう他部署についても、このような議題が会議に上がることを事前に伝え、その業務変更によって、各部署の業務や予算がどのような形で変化する可能性があるのかを討議し、会議当日、それは既に現場の総意としてして付議しているアジェンダであることを役員に示せるように準備しておく必要がある。
   この一連の壮大な準備こそが「ロジ」と呼ばれるスキルであり、コンサルタントが入ることでプロジェクトが加速する大きな要因となっている。事前準備と調整には万全を期すこと。
   

4. 今ある情報のすべてを動員してクライアントの思いを想像せよ　
   調整をミスらない、会議のアジェンダを外さない。と言われる人はなぜそれができるのかを考えたことはあるだろうか。筆者もかつて会議のアジェンダをよく外し、お通夜さながらの雰囲気を作り出すことがあった。自分としては練りに練ったアジェンダを持参し、紙についても十分に推敲していたはずなのに、実際に会議をやってみるとどうにも盛り上がらないのだ。しかし、あるタイミングから自分が主催する会議においては、いわゆるお葬式みたいな会議にしてしまうことはなくなったように思う。これができるようになったのは出席するクライアントの心情を把握できるようになってきたからであると思う。諸君らも親しい友人や家族恋人と会話するにあたってそのコミュニケーションにすれ違いがないのは聞き手である相手がどの程度の情報を現在持っていて、そして今何をしたい人なのかがある程度わかっているために、今彼女彼らがどのような情報であれば興味を持ち、どのようなことを言えば不快に思うのかを理解しているからである。仕事になるとなぜかこれができなくなり、会議で見当違いのアジェンダを持っていって「これってなんの会議でしたっけ？笑」のようなちくちく言葉をいただきあえなく退散の憂き目にあう。 特に初見のクライアントの場合、情報はどうしても限られてしまうが、公開されている情報と想像である程度補うことはできる。まずネットストーキングである。クライアントの上役であればあるほど、何かしら過去に取材された記事がインターネット上に転がっている可能性はあり、そこで彼女彼が何を語っているのか？どういう世界を実現したく、そして何に怒っている人なのか？の"あたり"はつけることができる。SNSも有用な情報収集ツールである。TwitterやFacebookで公開されている情報を集め、その人が生きてきた時代背景やキャリアの変遷を想像しよう。LinkedInに略歴が載っていれば非常に重要なインプットとなる。今取得できる情報をかき集め、今この瞬間彼、彼女はどんな情報をどんな解像度で聞きたいのか？を想像するとよい。以下は例である。

   • エンジニア上がりのクライアントであれば技術にこだわりを持っている可能性が高く、中途半端なテクノロジーの議論を持ちこめばこちらの知識の浅さを露呈することになりかねない。こちらもテクノロジー有識者を揃え、分厚い布陣で臨むべきである。そうすることでこちら技術に対する造詣の深さを示すことができるし、技術というトピックを通したリレーションの深まりを実現できるかもしれない。

   • カウンターとなるクライアントが最近別会社から入社してきている場合、そのクライアント自身もまだその会社の中の仕組みやルール、慣習に慣れていない場合が多く、その場合はチャンスである。彼女彼らは社内にどう溶け込むのか？を探っている最中であることが多く、会社にコミュニケーションの相手が不足していることが多い。諸君らが議論の相手になることで、彼女彼らは今すぐ欲しい共に働いている仲間を得ることができるし、孤独な時に寄り添ってくれた相手というのは長期にわたってその関係性が維持するものになるからである。彼ら自身もプロジェクトの背景や社内事情を十分に理解できていない状態なのであるから、それらについて彼らにヒアリングするような議題や会議を設定してはいけない。むしろ、自分達が知っているこれまでの経緯や知識を提供する場を設定することによって、信頼を勝ち取りやすい相手といえる。

   • Facebookや社内SNSのアイコンがマラソン後の写真やフットサルの写真、あるいは音楽活動に従事している写真である等、特定趣味を持っていることが明らかであるクライアントの場合はそれらについての話題はリレーションを深めるための有効な一手になりうる。公式な会議の場ではなかなか話せないであろうが、ちょっとした隙間時間や立ち話のタイミングで、その話題に触れてみると良いであろう。日常的な会話である程度相手の心がほぐれたタイミングで、今仕事上気にしていること、感じている課題感をそれとなく聞き出すと、どのようなことが聞きたい人なのか？を知る重要な手がかりとなる。
     
     クライアント内の組織体制図についてもクライアントの心情を知る重要な手がかりになるため、早期に獲得するのが良い。体制図に表れているのはズバリレポートラインである。そのクライアントは最終的に誰にどういう報告をしなければいけない人なのかが表現されているからである。カウンターのクライアントもサラリーマンであり、何かしらの報告義務を抱えている。経営陣であっても、顧客や株主への説明責任がある。これらの義務はクライアントが「今したいこと」「聞きたいこと」に如実に反映される。明日、自分が誰かにうまく説明しなければいけない何か重大なイベントがあるときに、関係のない話をされたら人間は不機嫌になるが、まさしくそこで使える有益な情報なのであれば身を乗り出して聞いてくるのが人間である。これらの情報は基本的には比較的容易に手に入るものであるからフル活用し、想像し、話の準備をするのが良いだろう。
     上記の準備をすることで、諸君らは打ち合わせの際、おそらくこの顧客はこういうことを打ち合わせでいうであろうな。。。という仮説を持って打ち合わせに挑めるようになっていると思われるが、実際の打ち合わせにおいて、クライアントがこちらの意図しない何かを発言したとき、それはクライアントのことをよりよく知るための重要なヒントであるから、その言葉を絶対に聞き逃してはならない。その言葉は諸君らが見落としているクライアントが気にしている"何か"であり、そしてあえて言っている一言であるのだから、その重要度は高いことを意味している。もしその発言の趣旨がわからないのであれば、「今おっしゃっていた・・・って、こういう所を気にされている感じですか？」というような形で、うまくその言葉の真意を拾い上げよう。
     

5. クライアントに言ってはいけない言葉集
   諸君らはコンサルタントである。クライアントは諸君らの月額金額を諸君らよりもよく知っているし、その金額の大きさについては複雑な心象を持っている人も多い。当たり前である。現場が一生懸命稼いだお金が諸君らを雇うために使われているのであるから、その使い方をよく想わない人はたくさんいるであろう。特に小売業等の利益率が低い領域においては仕入れを10円単位で調整しビジネスを日々行なっているのである。そういうクライアントと対峙していることを我々は忘れてはいけない。以下は例である。
   「こちらで問題ありませんでしょうか？」「なにが課題ですか？どこが問題なんですか？」
   と聞かれたらどう思うだろうか。
   「それが知りたくてお前らを雇っているんだが？」以上である。
   クライアントに課題を直接的な言葉で聞くことは自分達の存在意義を否定するに等しいため避けた方が良い。ではどうすれば良いのか。
   クライアントに何か聞くにしても絶対に「こうなんじゃないかと思っているんですけど、実際のところいかがですか？」を徹底すること。こうじゃないかと思っているんですけど。は仮説であり、よくいう議論のたたきである。これを出せるのがコンサルタントであるのでこれが出せないコンサルタントは金返せ。となる。では仮説はどう出せばいいのか。コンサルタントの教科書を振り返るとこのように書いてある。

仮説をどのように立てれば良いのかについては、仮説思考のご本家を必ず履修いただきたいが、筆者が日常的にどのように仮説を立てているかというと以下である。

• とりあえず一般論としてどうなのか？のあたりをつける。例えば営業改革の文脈のプロジェクトであれば、通常似たような営業部隊を抱えている会社はどのような問題に直面するものなのか？を一通り調べてみる。あまり時間を使う必要はなく、5つ6つくらい肝となる課題の仮説が出せればとりあえず30分くらいはそれをベースに議論できるのであるから、これはとっとと調べる。可能であれば会社のその道の有識者に調べた情報が最新のものであるかどうかは確認できるとさらに良い。

• クライアントの様子や資料をよく観察する。時間があれば上述した一般論と比較して、今のクライアントは同じ課題を抱えているのか、あるいは別の特殊な何かが発生しているのかを、クライアントから受領した資料の中から読み取れるものがあれば読み取る。もしカジュアルな立ち話が可能なクライアントがいるのであれば、こんな感じなんじゃないかなーと思ってるんですけどどうですかね？と聞いてみて、考えていることの確度を少しずつ高めていくのが理想である。

「こちらで問題ありませんでしょうか？」
これも禁句である。なぜならそんなことわからないし判断できないからである。承認をした場合にどのような影響がでうるのかを本人がわからないものについて承認を求めるのは暴力である。諸君らは例えば業務フロー等の成果物を作り、クライアントのユーザー部門に承認を得なければいけない。その際、「これで問題なければ承認いただけますか？」と言ったとしよう。ユーザー部門のクライアントが気にするのは、もし私が承認といった場合に、私はどんな責任を取らされるのか？という点である。ここを明示し、クライアントに対しての逃げ道を用意していない状態で承認を迫ったとしても、クライアントは判断することができないのである。
この場合必要なのは、このタイミングで絶対に決めてほしい所、引き返せないところはなんなのか？を明示し、逆にどのレベルの修正であれば、将来引き返すことができるのかの明示である。例えばこのタイミングでは、「業務フローの数が、原則として設計上存在する業務の数、となるため、テストも原則として、この業務フローの数だけ行うことになります。なので、これ以外の業務のパターンが増える場合は、ご予算の調整が入ってしまうかもしれません。業務のパターンというのは、ユーザーの数や扱うシステム、またがる日数等で累計しており、この業務の中で入力するデータはデータパターンとして一つの業務の中で細かく分岐するものとなるため、データパターンがどの程度増えるかについては現在考慮いただかなくて結構です。」というような言い方をすることで、今この瞬間、将来テストの対象になる業務のパターンの数だけは決めてください、と言われているのだ。とクライアントは理解できるのである。ただ漠然と問題ありませんか？という言い方は議論を長期化させるだけの悪手と心得よう。

「これから勉強させていただきます」「ご迷惑おかけすると思いますが」
シンプルに高額なフィーを払っているコンサルタントにこんなことを言われたら普通にぶん殴りたくなると思われる。アサイン間もなくても言ってはならない。

またこれは人間として当たり前になるが、クライアント、クライアント商品、競合、自社メンバーの陰口やネガティブな発言は絶対にしてはならない。自分にそのような意図がなくとも、誰々が・・・といっていたらしい、と言う伝聞は意図しない速度で意図しない範囲まで広がっていく。一度こうなってしまうとその信頼を回復することは実質的に不可能であるため、例えクライアントがそのような話題をふってきたとしても曖昧に笑って誤魔化すなどして明言を避けるようにすること。

社内編

1. プロジェクト以外の横のネットワークを広げておくこと

上述した通りであるが、クライアントが諸君らに期待していることは諸君ら個人の頑張りではなく（もちろん頑張ることは前提なのであるが）、会社としての総合力である。そのため、諸君らが社内の総合力をどれほど引き出せるのか？はそのままクライアントの満足度に影響を与える。クライアントへの提供価値最大化の観点から社内ネットワーキングは積極的に行うことを推奨する。
また、プロジェクト・上司と自分自身の相性が合わない、ということはどうしてもあるし、すべてのマネージャや上司が残念ながら善人であるわけでもない。そのため、なにか違和感を感じた時に、自分の違和感を第三者的に相談できるプロジェクト以外の先輩を多く抱えておく方がサバイバルの観点からも良い。

そのため、所属組織の懇親会や飲み会、サークル活動等は疲れない範囲で顔を出し、自分の人となりを理解してもらい、同じ人間性を持った先輩がどのあたりにいるのかを把握しておくこと。

1. レビュー依頼の注意点
   上司、あるいは先輩社員にレビュー依頼をする際、おそらく諸君らは近いうちに必ずこういう質問を投げかけられる。「見るのはいいけど、どういう観点で見ればいいの？」である。ジュニアスタッフにとってこの質問は極めて答えづらい物であろう。私はそもそも何を聞かれているのか、質問の意図すらわからなかったというのが正直な所だ。これは何を聞かれているのだろうか。
   先輩社員が聞いているのは「私はなぜこの資料を見なければいけないのか？この資料に私がOKを出すと、会社として品質上何を担保したことになるのか？」ということである。わかりやすく極端な例を出そう。諸君らはパートナーに資料レビューを依頼するとき、誤字脱字がないかのチェックをお願いするだろうか？おそらくしない、というよりもしてはいけないのである。誤字脱字は高等教育を受けている諸君らであれば自分自身で確認できることであり、それは時間単価の高いパートナーに依頼することではないからである。パートナーに依頼するとしたらなんであろうか？例えば、そのパートナーが抱えているセールス上の戦略との整合であったり、他プロジェクトとの足並みの整合であったりと、「その人にしかわからないこと」についてチェックしてもらうことが重要であり礼儀になる。ので、依頼するにあたっては例えば、「隣の●●のプロジェクトとの整合という観点で、特にスケジュールのプロジェクト横断的な前後関係や成果物の粒度感について、確認をいただきたい」等の見てほしいポイントの指定の仕方が重要になるのである。
   

2. 先輩社員の使い方
   何か隣のチームにお使いに行く必要がある時、特に中途採用で他業界からやってきた先輩社員の中には、アナリストごときが私に話しかけるのは失礼、というような価値観を持った人がいることを悲しいかな理解しなければいけない。ウルセェボケこっちも仕事や、で済めば良いのであるが、諸君らとしての臍を曲げたおっさんの世話に時間を摩耗したくないであろうから、こういう場合はすぐに先輩社員、可能であればマネージャレベルの方から直接話してもらうように躊躇なく依頼すべきである。また、他チームやクライアントへの依頼については軽微な物であってもマネージャ経由で依頼することが望ましい。残業時間のチェックが厳しくなっている昨今、スタッフ間でタスクのやり取りをすることは他チームのマネージャの工数の計算を狂わせる要因になる。そのため、隣のチームに何かを依頼するときは、作業の目的、欲しているアウトプット、必要工数（想定）を明記した上で、自身の上司であるマネージャを経由して依頼を行うのが通常である。
   

3. プロジェクトリリースは恥じることではないと知ろう
   例えば所属しているプロジェクトがあまりにも過酷で、心身に不調の兆候が出たとしよう。この時はプロジェクトリリースを自ら申し出、そして躊躇なくメンタルクリニック等の専門機関の診断を受けてほしい。プロジェクトは人間の集合体であり、人間と人間が集まって仕事をしている以上、相性の良い人間と相性の悪い人間は必ず組み合わせとして存在する。気が合う上司である可能性もあればどうにも人間的な価値観が刷り合わない上司とチームを組むこともあるかもしれない。人間的な価値観が噛み合わない上司と少なくとも1日8時間程度を共にすれば魂は汚れていくし、魂に負荷がかかれば必ずそれは体調に現れる。この際、自らその不調を検知してその場所を離れることは決して悪ことではないと覚えておこう。ジャンケンで負けたくらいに思っていれば良い。ずるずると不調を引きずりながら活躍できないプロジェクトで働き続けることの方がクライアントに対して不誠実になることもあり得る。そして一度体調を崩せば、その回復には相当な時間がかかり、そして将来の再発リスクを抱えながら仕事をすることになる。そうなってからでは遅いのだ。キャリアの1年目、2年目の評価など、長い目で見ればいくらでも巻き返せる。倒れる前に行動しよう。プロとして自分の身を守れるのは最後は自分であることを忘れずにいてほしい。
   

4. 休める時は遠慮せず休もう
   働き方改革により業界全体として有給取得率は増加傾向にあるのであろうが、それであっても管理職であるマネージャたちが諸君らの有休消化率を100％にするべく日々生きているか？と言われるとおそらくそうではない。何せ忙しいのである。有給は主張する人間のみに認められた権利としり、積極的にどのタイミングで取るのかを上司と相談して100％取得を目指そう。コンサルタントの仕事、すなわちプロジェクトには必ず繁忙期と閑散期が存在するので、閑散期のタイミングでの有給はむしろプロジェクトの人件費を抑制する手段ともなり、プロジェクトファイナンスへ貢献するということも知っておくと良い。
   

5. 社内恋愛はこれを禁ず
   いうまでもなく会社は仕事をする場所であり、我々コンサルタントの就労時間はクライアントの予算から捻出されたお金にチャージされる。仕事中、恋愛に割いている脳のリソースはないはずである。また、軽率に同僚と男女関係に発展した場合、得てして損をするのは女性側である。男の中には一夜を共にした女性を勲章のように扱う阿呆がおり、そういう阿呆はいかにその場では二人だけの秘密だと話をしていたとしても、翌週末の飲み会では同僚にその夜の話を着色して拡散する。そうなればいかに仕事で良い成績を上げたとしてもフェアに評価してもらうことが難しくなってしまう。余計な看板を背負わないためにも、確実に結婚へと発展するような一部の例外的なものを除き、同僚と恋愛関係になることは推奨しない。

これを避けるためには基本的に異性の先輩社員や上司と１対１で飲みに行く、ということはしない方が良い。そもそもそういう空気にしないことが何よりも大切である（そもそも就労規定で制限されていることもあり、事前によく確認しておくこと）。

日々の心がけ編

1. 将来を見据えてコンプレックスを早期に解消しておくこと
   今後いつ退職するにあたっても諸君のファーストキャリアはコンサルタントである。コンサルタントなのに英語がしゃべれない場合、なぜかがっかりされる。世間はコンサルタントは当然英語くらいしゃべれるものと考えているようだ。
   もし今時点でできないのであれば英語については今日から何とかすること。逃げることはできないと考えた方がよい。留学予備校の門を叩き、50万円程課金すればよい。この投資は必ず回収できるのでケチらないでほしい。
   英語学習後は桁違いにインプットが増えるため、仕事上も有効であるし、英語でのコミュニケーションが突発的に発生した際にひるむことなく議論に参加できるようになると自己肯定感を損なわなくて済むようになるため、精神衛生もよくなる。
   プログラミング等のテクノロジーにコンプレックスがある場合はドットインストールやUdemy等を使い、手を動かしながら毎週何かテクノロジーに触れること。何でもよい。やっているうちに何となくわかるようになる。テクノロジーについては独学と並行して、社内のベストプラクティスと呼ばれる資料をなるべく多く読み、自分の言葉にすること。どれが社内でなにがもっともイケてるソリューションなのかを把握できるとともに、キレイなスライドを脳に繰り返し脳内にすりこむことになるため自身のアウトプットの質も副次的に向上する。
   上記は短期間でなんとかなるものではない。３か月でも効果はでない。しかし１年、２年後に必ず武器になるので継続すること。近年の働き方改革の波で諸君らは業後ある程度の時間を確保できるはずである。2時間、1時間でもよい。自分の将来のために投資せよ。同年代より多くもらっているはずの給与を未来のために使え。酒は週末だけに限定することを強く推奨する。何も残らない。
   
   技術について何をどこまで勉強すればよいのか？で悩む人も多いと思う。実際に自分もそうであった。この点については好きなものを好きな粒度まで勉強すればよいという他あまり答えはない。
   というのも、もちろん詳しいにこしたことはないのであるが、実際のところ技術についてはそこまで詳しくなくともコンサルティングファームで生きていくことはできてしまうからであり、またイヤイヤ勉強して身に付く程簡単な物でもない、という領域であるからだ。技術に詳しくあるためには息を吸うように日々進化するテクノロジーを自主的に吸収するような、所謂技術オタクでなければ到底続く物ではないのである。
   
   どうしてもテクノロジーについて興味が持てないのであればそこについては詳しい人に頼るというのも一つの生き方である。ただし、その場合は自分の武器の選択肢がひとつ減るわけなので、であるならばどのようにチームに、クライアントに価値提供するのか？という点を真剣に考える必要が出てくる。
   
   業務システムコンサルタント、として生きていく必要がある場合には、最低限、そのテクノロジーや技術がクライアントビジネスに対してどのような影響を与えるのか？という点（経営者レベルの視点）と、そのテクノロジーを現場の人はどのように業務で使っているのか（現場オペレーションの視点）で理解しておくとよい。
   経営レベルの視点でテクノロジーがどのように事業に影響を与えるのか？は各種経済誌であったりビジネス本、日経コンピュータのあたりを読みつつ、社内のテクノロジーに関する記事を読んでいればある程度キャッチアップできると考えている。
   現場オペレーションの視点で理解するためには、実際に現場のクライアントが使っているシステムについて、画面を触りながら一通りの操作をシャドウイングしてみるのが近道だろう。各種システムやテクノロジーを現場にいる人たちがどのように使っているのか？どんなデータを入力して、それはどのようなアウトプットへと繋がっているのか？これは立派なテクノロジー理解の入口である。もし余力があればクライアントが行っている業務について、他の会社はどのようなシステムを使っているのが一般的であるのか？という比較の視点がもてると良いだろう。
   

2. 怒られが発生した時にどうメンタルを維持するか？
   まず大前提として、真剣に仕事をしていればそのうちミスはするし、そのうち失敗はする。そして必ず怒られる。これはもう地球には雨が降る日があるのと同じくらいに仕方がないことだと割り切る必要がある。怒られただけでいちいち凹まない。まずそこからはじめよう。問題は怒られている内容の質である。自分自身に責任があるのかないのか、これを明確に切り分けた方が良い。前者の場合、例えば言われていたことが守れなかった、判断のミスがあった、禁止されていることをしてしまった。これはしっかり凹もう。反省すべきである。なぜそうなってしまったのかを省みて、なぜそうなってしまったのか、どこで間違えたのか、そして次発生しないようにするためにはどうすれば良いのか。周囲にどう協力してもらうことで再発を防げるのか？しっかり考えて行動計画に落とそう。これができない人間は遅かれ早かれ信用されなくなる。
   一方で組織で働いていると、必ずしも自分自身の責任ではないところで流れ弾に被弾する可能性が少なからずある。これにいちいち凹んではいけない。別に他の人間のミスまで抱え込む必要はない。この場合、怒っている相手が社内の人間なのか社外の人間なのかで対応をかえる必要がある。社内の人間が自分の担当と異なるポイントで怒っている場合、一旦怒っているポイントをしっかり聴き、情報として整理する必要がある。怒っている理由を噛み砕くのである。最悪なのは、はやく怒られている状況を脱するために、適当な謝罪を決めて変な宿題を持ち帰ることである。ひととおり怒らせたあとに、「つまり、本来こうであったところが今こうなっているので、その点についてご指摘いただいていると理解したのですが、あっていますか？」というような形で、怒り手の怒りを構造化して確認しよう。一般的にコンサルタントは、論点の議論を持ち出されると、その直前まで感情的に怒り狂っていたとしても突然思考が左脳に切り替わり、あれ？どうだったかな？そうだったのかな。
   というモードに入れ替わる。こうなれば勝ちである。あ、そういうことではなくてね。とか、そうそう。だからこうじゃない？普通。みたいなトーンに持ち込める。怒り手の理性スイッチを入れてさえすれば、「実はその件に関しては私の作業範囲になく、本当は一緒にお話し持って来ればよかったのですが。。。」とこちらの不備（不備でなかったとしても）について一言謝罪も入れつつ、相手の怒りの矛先が自分でないことを説明しよう。まともなコンサルタントであれば、自分の怒りが見当違いであったことにここで気づき、ああそうなんだね。ごめんね、となるはずである。
   
   怒っている相手がクライアントの場合、もう少し事態は複雑である。まずクライアントが自分の作業ではなくとも会社に対して何かしらの不満をもって怒っている場合、これはもう反論してはいけない。ただひたすら、怒っている内容を聞き、その内容を分解する。怒りポイント（本来こうであったはずなのに、こうなっていることにお怒り）を正確に把握することに努めよう。クライアントの勘違いであることが明白である等の例外的な場合を除き、クライアントの怒りに対しての反論は絶対的な勝算がない限りはしない方が良いため、まずは持ち帰り上司と作戦会議をするようにすることを推奨する。しかしこれも自分自身に責任がないのであれば心を痛める必要はない。流れ弾が飛んできた思って、飛んできたゴロをファーストに送球するがごとく事務的に行うのが良い。
   

3. 自分自身の行動をKPI化して管理する癖をつけること
   これはよく営業成績が伸びないセールスマンに対して営業マネージャがいうアドバイスであるが、何回顧客に会いに行っているのか？電話をしているのか？の数をまず自分自身で意識する癖をつけること。
   筆者自身の経験の中でも、自分自身がうまくパフォーマンスしていなかった時代は、数に対してのコミットメント意識が自分の中で希薄であったと感じている。特に行動目標に定量的な数を設定しない人間は、過去を振り返る時、失敗した原因を自分の都合の良いように振り返ることができてしまう。
   なぜ定量的な目標が必要なのかと言えば、到達しなかった目標にパフォーマンス不全の原因となっている行動の不足が如実に現れるからである。
   クライアントや上司との関係性がうまくいかないと悩む時、何回会いにいき、直接会話をしたのかを振り返ってみると、単純にコミュニケーションの数があまりにも足りてない、ということも往々にしてあるのである。
   自分は果たして本当に上司、そして顧客と悩むだけ会話をしただろうか？自分は今、考えるに足るほどインプットとなる資料や書籍を読んだだろうか？という振り返りができるようにしておくこと。プロは悩まない。数（そこにある事実）を振り返り、仮説を修正しただひたすらに実行せよ。
   

4. やりたい仕事があるのであれば自分で勝手に詳しくなろう
   例えば事業企画、例えば戦略案件、例えばデータサイエンスに関する仕事がしたいと諸君らが望んだとする。当然世間一般で騒がれるようなバズワードには人気が集中するため、諸君らの他にもこれらの仕事をやりたいと考えている人は多い。あとは席の取り合いになる。この際、諸君らが採用する側だとして、取りたいのはどういう人間だろうか。
   実際にやったことがある人間である。
   結論、もし諸君らが特定テーマの案件をやりたいのであれば、自分で勝手に経験を積んでみるのが一番の近道である。事業企画や戦略であれば自分で副業申請を出して自分で会社を一つ立てて経営をやってみれば良いのである。データサイエンスであればWebの講座でもなんでも受けてみて自分で公開データを元に何かしらのインサイトを出してみれば良いのである。そのようなコミュニティは腐るほど存在しているし、そういう環境が世の中にあるのにやらないのであればそれは諸君らがバズワードに流されているだけである可能性が高い。

アナリスト編：失敗事例集

上述のエピソードに記載するほどのものでもないが、筆者がアナリスト当時やってしまった失敗集を参考に載せて起きたい。かなり怒られるのでアナリスト諸君においては同様のミスをしないように心がけるとともに、何かミスがあった際の心の支えにしてほしい。これだけやってもまだ人は生きていける。意外と心優しい業界である。

• 両面印刷の紙資料を片面印刷設定のまま印刷。そのまま気づかずにホチキス留めをしてクライアント会議に持参する

• 提案書提出前日、全てカラー印刷が終わった400頁相当の提案資料の逆側に穴あけ、印刷やりなおしになる

• クライアントの運用センターの指紋認証が通らず、30分間二重扉の間の謎空間で閉じ込められ会議序盤をバックれる

• 常駐先で他人のセキュリティケーブルを誤って端末に繋いでしまい身動きが取れなくなる。解決しようと10,000通りの暗証番号を静かに一つずつ試し解決を人知れず試みるが、いつも以上に挙動不審な様子をクライアントに指摘され事態が発覚し爆笑される。ケーブルは切断できたものの、金具の部分については除去できず、裏道で業者のチェーンソーで鍵部分をぶった斬ってもらうことになる。

• ランチミーテティング中でみんなでピザを食べながらやることになり、ピザの発注を頼まれるが、自分の好みであるパイナップルピザと女子の先輩向けにカスタードアップルピザをチョイスしてしまいバチ切れされる

• 常駐先の旧式のプリンタのトナー交換のやり方がわからず、分解しているうちに組み立て方がわからなくなる

• 深夜のオフィスでプリンタのトナーをひっくり返し事務所をマゼンダ一色に染め上げる

• 納品ファイル一式のPDF化を頼まれただけなのになぜかそれらのファイルがすべてプリンタに出力されはじめる。それに気づかず大量の紙が消費される。

その他アナリスト向けに参考になる書籍等の紹介

筆者の大先輩にあたる方の比較的新しい書籍。ビジネスとは、会社とはそもそもなんなのか？からコンサルタントとしての視点を持つことはどういうことなのか？がわかりやすく書いてあり、初学者向け。

筆者がヤマウチに最初に渡された本。眠くなるが、読まなければ始まらない。正しい日本語が書けなければそもそも何も伝わらない。

新しくアサインされた時、この秀和システムが出しているシリーズはクライアントの所属する業界のマクロ情報を短期間で把握するのに非常に重宝する。上記は通信事業であるが、かなりニッチな業界まで出版されているので、一応調べてみると良い。

システムについてどの程度のことを知っていれば良いのかわからないが何もしていないのは嫌、という人は一旦応用情報あたりの粒度の勉強をしてみるのが良い。基本情報と実はそれほど難易度は変わらないし、午後問題はコンサルタントであれば基本情報のそれよりも解きやすい傾向があると思っている。

精神がお終いになりそうな時用。ユーフォはいいぞ。