資料を作るとき、「内容さえ正しければ、あとは体裁の問題だ」と考えていないでしょうか。SIer(システムエンジニア)時代の私は、まさにそう思っていました。
ITコンサルタントへ転職してから、資料作成のノウハウを紹介する記事はたくさん見つかりますが、そのほとんどは「1スライド1メッセージ」や「ワンスライド・ワンメッセージ」といった型の説明にとどまっており、その型を体に覚えさせる過程で実際にどんな指摘を受け、何につまずいたのかという一次体験まで書かれたものはあまり見かけませんでした。この記事では、その体験に絞って書いていきます。
私自身はSIer(システムエンジニア)としてSE〜PMの実務を数年経験したのち、ITコンサルタントへ転職しました。数字や規模は記事ごとにぼかしていますが、資料作成にまつわる指摘の内容そのものは、当時の実感に沿って書いています。
この記事でわかること
- SIer時代の「情報量で語る」資料の作り方が、コンサルでなぜ通用しなかったか
- 「1スライド1メッセージ」を型として体に染み込ませるまでにやったこと
- レビューで一番こたえた「情報を載せる意図」という指摘と、その向き合い方
SIer時代の「情報量で語る」資料から抜け出せなかった
SIer時代、私が作る資料は仕様書や設計書の延長のようなもので、決めた内容をもれなく書き残すことが正義でした。会議で使う資料も、関係者があとで読み返しても分かるようにと、情報を詰め込みがちでした。
スライド1枚に、背景・現状・課題・対応案・スケジュールまで全部詰め込んで、「これを見れば全部分かる」資料を作ることに達成感すら覚えていました。当時はそれが丁寧な仕事だと信じて疑いませんでした。
コンサルに転職して最初のレビューで、「結局このスライドで一番言いたいことは何か」と聞かれて即答できなかったのを今でも覚えています。情報を漏らさず載せることと、伝えたいことを一つに絞ることは、まったく別の作業だったのです。
「1スライド1メッセージ」が体に染み付くまでにやったこと
最初のうちは、1枚のスライドに複数の主張を詰め込んでしまい、上司から「結局どれが言いたいことか分からない」と何度も指摘されました。1スライド1メッセージを頭で理解することと、実際にそれを毎回実践できることの間には、思っていた以上に距離がありました。
徐々に効いてきたのは、上司や先輩の資料、過去のプロジェクトで使われた資料から、図表の見せ方やオブジェクトの配置、色味など「使えそうな表現」を自分の中にストックしていくやり方でした。ゼロから毎回考えるのではなく、引き出しを少しずつ増やしていく感覚です。
あわせて意識するようになったのが、スライド単体の完成度だけでなく、資料全体を通して「ストーリー」がスムーズにつながっているかという視点でした。1枚ずつは正しくても、並べたときに話が飛んでいると、結局読み手は迷ってしまいます。
SIer時代は、資料を作り終えてから上司に見せることが多かったのですが、この進め方も少しずつ変えていきました。骨子だけのドラフト段階で先に相談し、ストーリーの方向性を早めに揃えてから細部を詰める方が、結果的に手戻りが少なく済むと気づいたからです。
一番こたえたのは「なぜここにこの情報を載せているのか」という指摘
型そのものよりも苦しかったのは、レビューで「このスライドの情報、なぜここに載せているのか」と意図を問われたことでした。「深い意味はなく、参考にした資料に載っていたので合わせただけです」という理由は、コンサルの現場ではまったく通用しませんでした。
自分の意思として、その情報を載せる目的を言語化できて初めて、レビューする側も納得してくれます。逆に言えば、目的を説明できない情報は、たとえ間違っていなくても資料に載せる資格がないということだと、痛感させられた出来事でした。
SIer時代は、仕様書に書くべき項目がある程度決まっていて、その枠を埋めることが仕事の中心でした。だからこそ、「なぜそこに書くのか」を一から自分で説明する場面自体が少なかったのだと、後になって気づきました。
情報を載せる意図を言語化するために意識していること
- スライドを作る前に、そのスライド1枚で「相手に何をしてほしいのか」を一文で書き出しておく
- 載せようとしている情報一つひとつについて、「これがないと、その一文が成立しないか」を自問する
- 資料の見た目を整える前の下書き段階で、上司や先輩に意図だけを説明し、方向性がずれていないか確認する
この3つを意識するようになってから、「なぜこれを載せたのか」と聞かれても、自分の言葉で答えられる場面が増えていきました。特別な才能というより、手順として身につけられる部分だったと感じています。
もちろん今でも、レビューで意図を突かれて言葉に詰まることはあります。ただ、以前のように「なんとなく」で載せる情報がほとんどなくなった分、指摘を受けたときの立て直しは以前より早くなったと感じています。
これからコンサルを目指す方へ
この「意図を言語化する」練習は、コンサルに転職してから初めてできるものではありません。今の仕事の資料でも、「このスライド・この資料で相手に何をしてほしいのか」を一文で書き出してから作り始めるだけで、同じ練習が始められます。
資料作成そのものについていけず苦労した時期の話はコンサル転職後、資料作成・議論についていけなかった私が克服のためにやったこと5つにまとめています。あわせて、コンサルで求められるスキル・資格全般についてはITコンサルで求められるスキル・資格、実際に感じたことを全部書くでも整理しているので、気になるテーマから読んでみてください。
自分の今のスキル・経験が、コンサル転職でどう評価されるのか一人で判断がつかない場合は、一度エージェントに率直に相談してみると、思わぬ視点が見つかることもあります。資料作成のような実務の型は入社後に身につく部分も多いので、まずは今の自分の経験がどう映るのかを聞いてみるところから始めてみてください。
型を知っているかどうかより、「なぜそれをそこに置いたのか」を自分の言葉で説明できるかどうかが、コンサルの資料作成では常に問われます。転職前の今からでも、その練習は始められるはずです。
資料作成は、コンサルで求められるスキルのほんの一部にすぎません。他にどんな場面で戸惑いやすいのか、あらかじめ知っておきたい方は、関連記事もあわせてチェックしてみてください。
