農と仕事

2026年のITコンサルに必要なスキルのお話

2026.06.25

Contents

「AIに仕事を取られる」は半分正解、半分ちがう

最近、コンサルをしているクライアント先でも「AIがあればコンサルいらないんじゃ？」という声をちらほら聞くようになってきた。正直に言うと、半分は正しい。でも半分は違うのでは？と私は思っています。

AIが得意なのは「答えが決まっている問いへの回答」。
たとえば議事録の要約、標準的なひな形生成、とある技術の概要説明なんかは人間がやるよりもずっと素早く、かつ、的確にAIが十分うまくやれちゃいます。わたし自身、日常的にAIを使っていて、「あ、これはAIで十分だな」と感じる場面が増えました。

じゃあ何が残るか。それは「答えがまだ決まっていない問いを立てること」と「人と人の間で意思決定を動かすこと」だと確信しています。

スキル① 「問いを立てる力」

クライアントが「システムを刷新したい」と言ってきたとき、それをそのまま受け取るのはコンサルじゃなくてベンダーの仕事です。コンサルがやるのは「なぜ刷新したいのか」「刷新して何が変わるべきなのか」「そもそも刷新が正解なのか」を掘り下げることだと思っています。

たとえば「運用業務が属人化している」という課題。
これをそのまま「ではシステム化しましょう！」と持っていくと、よくある提案に。
でも「なぜ属人化しているのか」を掘り下げると、「担当者が変わるたびに引き継ぎが発生していて、その引き継ぎコストが本当の問題」だったり、「そもそもやり方が人ごとに違って正解という正解がない」という構造的な問題だったりします。

AIは与えられた情報から答えを引き出すのは得意ですが、「何を聞くべきか」の設計はまだまだ人間の領域なんじゃないでしょうか。
インタビューで何を問うか、会議でどんな問いを投げるか——ここに個人差が出ると思っています。
（ワールドカップの試合を見ながらも同じことを考えていました笑⚽）

優れた課題設定は、ソリューション提案の何倍もの価値を持つと思います。
高いコンサル料に見合うパフォーマンスはAIができないこと・得意じゃないことにあるはずです。
「答えを出すこと」より「正しい問いを見つけること」に時間をかけることの大事さを改めて感じてほしいなと思います。
それがきっと今後クライアントのため、自分の成長のために必ずなるのだから。

スキル② 「翻訳力」

2026年現在、ITコンサルの現場では「技術は分かるけどビジネスが分からない人」と「ビジネスは分かるけど技術が分からない人」が両方います。そしてその間が、いつもぽっかり空いている気がするんです。
その隙間を埋める翻訳力が、リアルに差別化になっていると感じています。

具体的に言うと
技術→ビジネスの翻訳例：
「ServiceNowのFlow Designerを使えばオーケストレーションが実現できます」
→「今まで担当者が手動でやっていたA・B・C作業が、決めた条件で自動的に動きます。月換算で約50時間の削減が見込めます」

ビジネス→技術の翻訳例：
「承認フローをもっとシンプルにしたい」
→「現状の承認ステップが5段階あって、そのうち2・3段階目は条件付き自動承認に置き換えられます。ただし権限設計の見直しが前提です」

この翻訳、意外と難しい・・！
片方の言葉だけで話すと、相手に「で、結局どうなるの？」と言われた経験ありませんか。
両方の文脈を持っていて、かつ相手の文脈に合わせて話せる人が重宝されるITコンサルタントです。

もちろん技術のことを把握していないITコンサルタントはお話になりませんが、ただ技術に詳しいコンサルよりも
技術を使って経営判断を助けられる人のほうが希少でニーズが高いことに間違いありません。
自分がどちら側に寄っているか、たまに立ち止まって確認してみてほしいなと思います。

スキル③ 「シナリオ思考」

プロジェクトは計画通りに進みません。これはもう前提として受け入れたほうがいいと腹をくくってます笑

大事なのは、計画が崩れたときに慌てるのではなく、「崩れたらこう動く」を事前に設計しておくこと。これがシナリオ思考です。

たとえば大きな意思決定を伴う提案では、「フル実装案（松）」「中規模案（竹）」「最小構成案（梅）」のように複数の選択肢を設計して、それぞれのリスク・コスト・効果（メリデメ）をセットで示します。
これは単なる「念のための代案」じゃなくて、お客さんに「自分で選んでいる」感覚を持ってもらいながら、意思決定を前に進める技術だと教わったことがあります。

プロジェクト内でも同じ発想が使えます。
よく開発プロジェクトでアジャイル開発という言葉をきくと思いますが、まさにアジャイル的な進め方はシナリオ思考の実践だと思います。
全部決めてからスタートするのではなく、動きながら微調整をしながらしかるべき方向に向いていく。

「完璧な計画」を出すことより「変化に強い構造」を作ることのほうが、長いプロジェクトでは価値があります。
不確実性をリスクと捉えるのではなく、設計対象として扱えるようになると、提案の質が変わるのではないでしょうか。

スキル④ 「場を動かす力」

これは言語化しにくいのですが、めちゃくちゃ重要だと感じています。

どれだけ良い資料を作っても、会議室でその内容が「いいですね！検討しましょう！」で終わらなかったら意味がない。
逆に言うと資料が荒削りでも、場の温度を読んで適切に問いを投げられる人は、ちゃんと前に進められるし、次回に持ち越しをしません。

「場を動かす力」を分解すると

空気を読む（≠ 忖度する）：今この場で何が起きているか、誰が躊躇しているか、どこに引っかかりがあるかを察知する
沈黙を使う：問いを投げた後に焦らず待てる
反対意見を資産にする：「懸念はよく分かります。そこを踏まえるとこういう設計になります」と転換できる
決断を促す：「今日この場で決めるべきことは何か」を明示して、ふわっとした終わり方を防ぐ

特に大きな組織のお客さんを相手にするとき、この力の差が顕著に出ます。

うまく動かせる人、ファシリテーションの上手さ、さんまさんのようなMC力は天性の才能じゃなくて、意識して努力して鍛えられたスキルなんだと思います。

スキル⑤ 「自分ごと化する力」

最後に、ちょっと内面の話をしようかなと思います。

ITコンサルがよくハマるパターンがあり、私は「第三者ポジション」に収まりすぎることだと思っています。
例えばですが、「客観的に見て〜」「一般的に〜」「他社事例では〜」という言い方が多くなると、クライアントから「あなたはどう思うの？」と聞かれたときに確実に答えに詰まります。
クライアントの立場になってみても「この人はウチのことをおもって提案してくれてるのかな？」と思ってしまいますよね。

自分ごと化する力とは、クライアントの課題を「自分の課題」として引き受けられることだと思います。
言い換えると、「うまくいかなかったら自分も悔しい」という感覚を持ちながら仕事ができるかどうか！！

これはクライアントに対してだけでなく、プロジェクトチームに対しても同じです。
「自分のタスクだけやればいい」という姿勢と、「このプロジェクトが成功するために自分は何をすべきか」という姿勢では、積み上がるものが全然違ってきます。

逆に、自分ごと化しすぎて感情的になりすぎるのも問題なので、当事者意識を持ちながら、俯瞰する余裕も持つというバランスが理想です。
その感情的なコミットメントがある人ほど、クライアントももちろん上長、プロジェクトメンバーの信頼を長期で獲得できると確信しています。