スポンサーリンク
前回の記事では、コンサルのプロジェクトを3種類に分類した上でそれぞれの解説をしました。
コンサルのプロジェクトは多岐にわたっているが、大まかなには①戦略、②業務、③ITの3種類に分類することができる。種類に応…
今回はその中のIT案件に関連してよく聞かれるトピックとして、「ITコンサルとSEは同じじゃないの？」にお答えしたいと思います。
お客さんの要望に従い、完璧にシステムを作り上げ行く人がSE
お客さんの要望を踏まえつつも、独自の提案をしてコンサルが考えるお客さんにとって最適なシステムを作り上げていく人がITコンサル
というのが僕の理解です。違い、イメージできますか？
SEとは
システムエンジニアといわれる通り、システムを設計・プログラミングをします。彼らにとっての正義は、「いかにお客さんの要望を正確に反映するか」ということになります。なので、お客さんの要望が明確かつ詳細に纏まっていればいるほど、SEとしては仕事を進めやすくなり、プロジェクトが成功する可能性も高まります。
反面、お客さんの要望がふわっとしているとSEは困ります。どのようなシステムを組み立てていいかが、要望がない状態だと考えることができないからです。
ITコンサルとは
では、ITコンサルには何が求められているのでしょうか？
SEとは異なり、ITコンサルがお客さんの要望に従って完璧にシステムを作り上げたからといって、100点満点はもらえません。
なぜならお客さんの要望は時にToo muchだったり、見当違いだったりすることもあるのです。お客さんによっては予算の兼ね合いで中途半端な額を投資して、中途半端なシステムを導入して、結果として大した効果が得られなかった、というケースも出てきます。それをいかに正しくいくかがITコンサルの腕の見せ所なのです。
例えば、基幹業務システム（SAP等）を導入するようなコンサルだとこのような形でシステム開発の範囲や方法を定義します。
- お客さんの現行業務・システムの理解
- 基幹業務システム（SAP）を使用した時の業務・システムへのインパクトを説明
- 業務を変えるか、もしくはシステムに手を加えるかをお客さんに提案して意思決定
この最後のプロセスは、提案型で行うことがキーポイントです。どのようなシステムにするか、もしくはそもそもシステム化するべきかについて、あるべき論やお客さんの実態を踏まえて様々な観点（コスト、業務効率化への貢献度合い、スケジュールインパクト等）から比較を行い、お客さんをリードしてシステムロジックを決めていくのです。
だからこそ、コンサルには行動力があり、主体的に動くことができる人が求められているのです。（詳細はこの記事を見てください）
ITコンサルとSEの違いが理解できないと・・・
ある会社（ここではA社とします）の新規事業を支援するプロジェクトに参画していた時にこんなことがありました。そのプロジェクトではお客さんが、SEの会社（ここではB社とします。）と契約をしてあるシステムを作り上げ、そのシステムを用いて新規事業を展開する予定でした。
お客さんは僕にこんな相談をしてきます。「B社（SEの会社）は全然システムの提案をしてくれない。こちらの要望を伝えないと何も動かないし、こちらから要望を伝え損ねたらシステムに反映されない」
お客さんはB社に対してITコンサルとしての動きを期待していますね。
一方でSEの会社の担当者も僕にこう愚痴ります。「A社（クライアント）は全然要件を出してくれない。出してくれても曖昧な要件ばかりでシステムに落とすことができない」
B社はSEとして真っ当な主張です。
こうなってしまうとお互いがお互いの愚痴を言い合うだけでそもそもボタンを掛け違えてしまっているのでなかなかプロジェクトが前に進まないのです。コンサルを使う側も最低限の理解が必要ですね。
まとめ
- SEは、クライアントの要望に従い、完璧にシステムを作り上げ行く人
- ITコンサルは、クライアントの要望を踏まえつつも、独自の提案を行い、コンサルが考えるお客さんにとって最適なシステムを作り上げていく人
こちらの本はITコンサルとは何ぞやというところの神髄を解説しており、僕が感じていることを言語化した書籍です。お時間が許せばぜひ読んでみてください。
スポンサーリンク
