資料がうまいだけでは届かない──ITコンサルで評価される課題設定の型

ITコンサルという仕事に興味を持つと、最初に気になるのは資料作成力かもしれない。

きれいなスライドを作れるか。
論理的な構成で説明できるか。
経営層や部長クラスに向けて、見栄えのする提案書を出せるか。

たしかに資料作成力は大事だ。情報を整理し、論点を並べ、相手が読みやすい形にする力がなければ、会議の場で話を前に進めることは難しい。ただ、実務の中で感じるのは、資料がうまいことと、評価されることは同じではないということだ。

見た目は整っている。構成も分かりやすい。ページ数も十分ある。それでも会議が終わったあとに、結局、何を決める場だったのか分からない資料がある。

逆に、資料としてはそこまで凝っていなくても、相手の判断が前に進むものがある。

この差は、資料作成力ではなく、課題設定力に出る。

ITコンサルで評価される人は、資料を作る前に、何を課題として置くかをかなり慎重に見ている。目の前の困りごとをそのまま課題にしない。顧客が言った言葉を、そのままタイトルにしない。現場で起きている症状の奥に、何が詰まりを生んでいるのかを見にいく。

たとえば、顧客がシステムが使いにくいと言ったとする。

資料作成だけに意識が向くと、システム改善案、画面改善案、UI改善案、機能追加案を並べたくなる。もちろん、それが必要な場合もある。ただ、本当の課題は画面ではないかもしれない。

業務手順が部署ごとに違うのかもしれない。
承認ルールが複雑すぎるのかもしれない。
入力項目が多いのではなく、誰が何を判断するのかが曖昧なのかもしれない。
現場が使いにくいと言っている背景には、そもそもその業務を続ける意味が整理されていないこともある。

ここを見誤ると、資料はきれいでも、提案はずれる。

ITコンサルの仕事は、正解らしいことを並べることではない。相手が本当に決めるべき問いを置き直すことだ。僕はここに、SEやPMの現場経験が活きる余地があると思っている。

現場を知っている人は、きれいな理想論だけでは動かないことを知っている。仕様を変えれば終わるわけではないことも、ツールを入れれば業務が変わるわけではないことも、関係者の合意がなければ何も進まないことも知っている。

その経験は、単なる過去の苦労話ではない。課題設定に変換できれば、かなり強い武器になる。

では、課題設定とは何をすることなのか。

僕は、少なくとも三つに分けて考えている。

一つ目は、症状と原因を分けること。

問い合わせが多い。手戻りが多い。会議が多い。承認が遅い。属人化している。こうした言葉は、現場でよく出てくる。ただ、これらは多くの場合、課題そのものではなく症状だ。

問い合わせが多いのは、マニュアルがないからなのか。画面が分かりにくいからなのか。権限が細かすぎるからなのか。そもそも運用ルールが毎回変わるからなのか。

手戻りが多いのは、開発力が低いからなのか。要件定義が曖昧だからなのか。意思決定者が途中で変わるからなのか。変更管理が機能していないからなのか。

症状を課題として扱うと、打ち手は浅くなる。原因に名前を付けられると、資料の説得力は一段変わる。

二つ目は、誰の意思決定を進める資料なのかを決めること。

資料は、情報を説明するためだけにあるわけではない。特にコンサルの資料は、誰かの判断を前に進めるためにある。

部長に予算を判断してもらう資料なのか。
現場責任者に業務変更を受け入れてもらう資料なのか。
経営層に投資優先順位を決めてもらう資料なのか。
プロジェクトメンバーに次の行動を揃えてもらう資料なのか。

ここが曖昧なまま作ると、資料は説明過多になる。情報は多いのに、判断が進まない。読んだ人がなるほどとは思っても、では何を決めればいいのかが残らない。

評価される資料は、ページがきれいなのではなく、判断の置き場所が明確だ。結論、論点、選択肢、リスク、次の一手がつながっている。

三つ目は、実行に落ちる粒度まで考えること。

ITコンサルの提案で弱くなりやすいのは、ToBeは描けているのに、現場が動けない状態だ。あるべき姿は正しい。方向性も間違っていない。でも、それを誰が、いつ、どの順番で、どの制約の中で進めるのかが見えていない。

これでは、資料は立派でも現場には残らない。

SE出身者やPM経験者が強みを出せるのはここだと思う。現場には、予算も人員もシステム制約も既存運用もある。理想を語るだけでは進まない。だからこそ、課題設定の段階で、実行条件まで見ておく必要がある。

この課題は、業務変更で解けるのか。
システム改修が必要なのか。
権限設計の見直しが必要なのか。
現場教育で足りるのか。
そもそも、今の組織体制で進められるのか。

課題設定が甘いと、打ち手は派手になる。課題設定が深いと、打ち手は現実的になる。

ITコンサルで評価される人は、難しい言葉を使う人ではない。相手が薄々感じていた違和感に、使える名前を付けられる人だと思う。

現場が困っていること。
管理職が決められずにいること。
経営が見たいこと。
システム側が守りたいこと。
業務側が変えたくないこと。

それらを一枚の論点に集約し、何を決めれば前に進むのかを示す。ここまでできて、初めて資料が意思決定に届く。

もし今、ITコンサルを目指していて、資料作成力に不安があるなら、スライドの見た目だけを磨くより先に、日々の現場で課題設定の練習をしたほうがいい。

会議で出た不満を、そのままメモしない。
これは症状か、原因かを分ける。
誰が決めれば進むのかを見る。
その課題は、実行に落とせる粒度になっているかを確認する。

この癖は、SEにもPMにも必要だし、ITコンサルではさらに強く求められる。

資料がうまい人は、情報を整える。
評価される人は、判断を整える。

ITコンサルで問われるのは、きれいなページを作る力だけではない。相手が本当に向き合うべき課題を置き直し、現場が動ける形までつなぐ力だ。

あなたが今作っている資料は、情報を並べているだけだろうか。それとも、誰かの判断を前に進める課題設定になっているだろうか。

次に読む：

はじめての方へ：

マガジンの紹介：

IT業界の「技術×キャリア×整える」を束ねるマガジンを公開中です！
ビジネスや心と体を整える良記事が集まってきていますので、
是非、覗いてみてくださいね。
記事は全て無料記事のみです。
気に入って頂けたらマガジンのフォローもよろしくお願いします！
共同マガジンに参加希望の方も募集中です！

＜PR＞

次のキャリアを考えたい方へ。
求人サイトGreenを応援しています。