「本物の」ITコンサルタントの仕事とは？【発注者・初心者～中級者向け】

安達 奨（Susumu Adachi）

ITコンサルタント／Knowledge marketing合同会社 代表

IT業界で15年以上の経験を持ち、システム開発の上流工程から下流工程に至るまで幅広く精通。（企画、要件定義、設計、プログラミング、テスト）
現在ではシステム開発のみならず、ツール選定、ベンダー選定など、大手～中小企業向けのIT支援を多数手がける。
本サービスでは、特に事業会社時代から "システム開発会社の見積" に疑問を感じており、これを是正すべきと考え監修を行っている。

▶ 出演：
ITエンジニアのリアルな転職事情／「ITエンジニアのシン常識」前編
残業時間から在宅ワーク率、悩みまで／「ITエンジニアのシン常識」後編

はじめに：ITコンサルタントとは何者か？

デジタル技術の発展により、あらゆる企業がIT活用を前提とした事業運営を求められる中、「ITコンサルタント」という職種が注目を集めています。しかしながら、ITコンサルタントという名称はあまりに広義であるため、その役割を正確に理解できている人は意外と少ないのが実情です。

最近では「Salesforce導入支援」「SAPプロジェクト支援」「PMOとして参画」などの名目で、SIerやSIer出身のエンジニアが“なんとなくコンサルタント”を名乗っているケースもありますが、これは本質的なITコンサルティングとは言えません。

ITコンサルタントとは、あくまでも「IT領域が専門のコンサルタント」であり、「ただシステム開発に詳しいだけの人」では決してないからです。

結論：ITコンサルタントが本当に担うべき業務とは？

では、そんなITコンサルタントが行うべき業務とは、大きく次の3つに分けることが出来ます。

• 要件定義
• ベンダーコントロール（調整・管理）
• 受入テストおよび品質評価

「システム導入の支援」といった表面的な役割ではなく、「ビジネス成果を出すための手段としてのIT導入」に責任を持ち、戦略立案から実行・評価までを担うにはこれで大きく外すことはありません。

では、より具体的にそれぞれの業務を見ていきましょう。

第1章：要件定義とは「未来の業務設計」である

要件定義は2つに分類できる

要件定義とは、ITコンサルタントの仕事の中でも最重要フェーズです。主に次の2種類に分けられます。

• ビジネス要件（または業務要件）
• システム要件

これだけだとかなり曖昧な言葉になってしまうため、事例を交えて説明を行っていきます。

【例】知育メーカーのEC立ち上げプロジェクト

ある知育玩具メーカーが、自社でECサイトを立ち上げたいと考えました。その結果、以下の様にビジネス要件とシステム要件を整理したとします。

ビジネス要件

• 目的：販路の拡大による売上増加
• 目標：初年度売上150%アップ、次年度以降はオペレーションコストの削減
• プロセス：
• ペルソナ：0～3歳児の家庭
• 集客チャネル：SEO／リスティング広告
• 業務フロー：
• 購入者：商品検索 → 決済 → メーカー通知
• メーカー：通知受領 → 在庫発送 → メールで完了連絡

システム要件

• LP、商品管理、決済機能、在庫連携、管理画面表示
• 性能：月間1万アクセス、画像：商品500点×5枚（約1MB/1枚）、SSL対応など

この時点でも少しだけ専門用語を交えてはいますが、こういった内容を正しく作成できる人材を雇用している企業もあれば、雇用できていない企業もあります。

しかし、どんなクライアントから相談されるか分からないのがコンサルタントという職業。だからこそ、こういったシステム開発をする上で重要なベースの部分も作れ、かつ詳細設計やプログラムの世界まで理解していなければなりません。

機能スコープの最適化（フェーズアプローチ）

実際の要件定義では、ビジネスインパクトの大きい部分（見積が大きくなる機能）に対し、機能を段階的に導入する＝フェーズアプローチが最も重要です。

先ほどの例を更に深堀するのであれば

• ブログ管理機能は後回し：初期はリスティング広告が主チャネル（売上目標を短期的に達成するにはオーガニック検索は重要でない）
• ユーザー管理も最小限に：DB保存のみで十分
• 発送通知はメール返信で代用：商品購入時にメールアドレスが分かっていれば連絡は可能。これが公式LINEを使うなどでも全く問題ありません。

この様に判断することも可能です。

近年、こういった考え方や手法はPoCやMVP開発といった言葉になるのですが、そもそも論これらの言葉を作ってきたのがコンサルタントです。だからこそ、ただ業務を代わりにするだけではなく、「どうしたらより上手く出来るのか？」を常に考え続ける人をコンサルと呼びます。

コンサルファームでは、「考え方を考えろ」などとも言われますが、こういったことを本当に考えることが出来ている人はかなり少ないように思います。

※余談になりますが、コンサルになりたい学生向けのイベントなどで「やりたいことが誰かのためでない人はコンサルに向いていないよ」と説明することもあります。上記のような考えとはある種真逆の考えであることは言うまでもありません。

第2章：ベンダーコントロールは「調整業務」ではない

ITプロジェクトにおいて、開発ベンダーと適切な関係性を築き、品質・コスト・納期を管理することは極めて重要です。しかし、多くの“ITコンサルタント”がこの領域を誤解しています。

よくある誤解と正しいコンサルの動き

誤り：ガントチャートで進捗を可視化するだけ

→ 正解：工数見積の妥当性を精査し、工程そのものを再評価する

誤り：成果物が納品されたかを確認する

→ 正解：「要件に対する妥当性」を確認する

品質責任はコンサルにもある

「ベンダーが悪いからプロジェクトが炎上した」と言い訳するITコンサルは少なくありません。しかし、ベンダーに責任を丸投げすることこそが最大のリスクです。

真のITコンサルタントは、ベンダーの力量や工数の見積を冷静に評価し、仕様漏れや工数過少の兆候を早期に検出し、必要に応じて仕様を見直す提案を行うべきです。

第3章：受入テストは「納得の最終ライン」

受入テスト（UAT）は、最終的に「このシステムでビジネスが回せるか？」を判断する極めて重要なプロセスです。

ユーザー視点を持たない受入は意味がない

• チェックシートを作っても、現場が操作できなければ意味がありません。
• 想定した業務フロー通りに動くか、例外パターンでも崩れないかまで確認する必要があります。

現場の声をシステムに反映する

• 受入テストで「このボタンが分かりづらい」と言われたら、UI改善の余地があります。
• 「処理が遅い」との声には性能要件見直しの提案を行う。

ITコンサルタントは、テストを“システムの不具合探し”ではなく、“ビジネス遂行に耐えられるかの確認”と位置付け、意思決定の支援者として立ち回るべきです。

第4章：ITコンサルタントの業務範囲まとめ

第5章：ITコンサルタントの単価・報酬相場

フリーランス・中小コンサルティングファーム（ブティックファームなどとも言う）・コンサルティングファームなど所属形態で単価は異なりますが、フリーランスから中小のファームであれば以下が参考値です。

 これが外資系のファームなどになれば2～3倍は当たり前ではあるものの、それだけ外資系ファームは良く学んだ上で働いてくれます。（近年ではそれも残業規制などで変わってしまいましたが、やはりプロフェッショナルとしてのマインドやスタンスは全く違います）

おわりに：ITコンサルタントとは「目的達成の伴走者」である

ITコンサルタントとは、単にシステム導入を手伝う存在ではありません。目的を見極め、現実的なアプローチを設計し、確実に成果を出すための実行力を備えたビジネスパートナーです。

ツールの知識やベンダーとの折衝力だけではなく、広い視野で本質を捉える力こそが、真のITコンサルタントの武器なのです。