コンサルティングファームの経験が社内SEでは有用ではない理由

別の記事で優秀な社内SEを目指すという事を考えた場合、
コンサルティングファームの経験は決して必要ではない
と書きました。

この記事では具体的にどこら辺がそう言える根拠なの?
という事について書きたいと思います。

結論から先に言うと、
・「リスクヘッジ」の考え方が根本的に違う
・「当事者意識」が違う
・スキルが偏る
という所です。

一つずつ見ていきます。

【「リスクヘッジ」の考え方が根本的に違う
これは言い換えると発注側と受注側の違いとも言い換えることができます。
Sierでも同じなんじゃないの?と思うかもしれませんが違います。
説明がちょっと難しいですが、大事な所なのでちゃんと説明したいと思います。
まず、仕事の立場としてコンサルもSierも発注側の人間の一部として働くことはあり、
企業のIT部門の一員として、別ベンダーに指示を出したり、管理をすることはあります。
しかし、コンサルはあくまで「お手伝い」というスタンスは崩しません。
それはなぜかというと、コンサルにおけるリスクヘッジが「自責にしない」だからです。
ここでいう「自責」とはその字面の通り、自分の責任という事になります。

なので、その作業の中で何か問題が起きても、かならず自分が責任を負うような事態にはならないように立ち回ったりします。自責になりそうなタスクについては

「それについては我々では責任取れませんので、御社でお願いします。」

といったように線引きをしたりします。

一方、Sierはそのスタンスは取らないことが多いです。
それは発注側のほうが立場的に圧倒的に強いことや、企業規模も大きなことが多いからという事もありますが、Sierは、いかに発注側に寄り添えるか?いい会社だと思ってもらえるか?という事に評価を見出す傾向が強いからです。
その思いの中に、「あわよくば食い込みまくって、切れなくしてやろう」というような思いが働くからでもあります。
この為、
そこにクビを突っ込むと、将来的に自責になるような事態に発展しかねない
という事がわかっていても、そこに手を出したりします。

この違いが出る理由の一つとして

Sierは発注企業と長い付き合いを目指す一方、コンサルはプロジェクト単位で利益を出そうとする

という所があると思います。

Sierは発注企業とその場限りの関係とは考えず、長く関係を維持し、その企業から発生するプロジェクトを独占したいと考えることが多いので、付き合いが長ければその分利益が増える一方、コンサルは特定の企業とずっと一緒にいようとは考えません。世の中にはプロジェクトが溢れていますし、そのプロジェクト一つ一つでしっかり利益を出して、短期的に利益を確定していくという風に動きます。

このスタンスはSierに日系企業が多いこと、コンサルに外資系企業が多いことにも起因していると思います。

こういう思いで動いているとどうなるかというと
プロジェクトの利益を目減りさせるような要因は可能な限り排除したいので、手戻り要因や、言った言わない、プロジェクト完了後も尾を引くよう課題には最初から拘わらないというようなアクションをとるようになるわけです。

このように、Sierとコンサルは同じプロジェクトに在籍していても、リスクの取り方は全く違うので、コンサルに長く居て、このリスクヘッジの仕方が染みついてしまうと、社内SEになったときに、
「それってどう考えてもヤバい案件ですよね?そんなのに手を出したら、うちの部署の責任になってしまうから、やめておいた方がいいですよ」
みたいなことを口走ってしまったりします。
自責にならないように振る舞うわけですね。

しかし社内SEになった時点で、「しない」という判断にも責任が付きまとうので、自責というリスクからは逃げられません。

上記のようなことを言おうものなら
「こいつ何言ってんの?」
という空気が流れてしまいます。

よって、社内SEがしなくてはいけないリスクヘッジは
・自分たちのせいにならないようにすること
ではなく
・実現に伴うリスクを如何に低減するか?
でしかありません。
実現するかしないか?という話から始まりません。
実現するということが前提におけるリスクヘッジです。
「実現しない」という選択はあくまで、どうやってもメリットがリスクを上回れない場合の苦渋の決断としてしかありえません。
最後の最後に出てくる選択肢であり、最初からテーブルに並べられているものではないという所に注意が必要です。

リスクヘッジという言葉が持つ意味が、これほど違う為
コンサルとしての思考が染みついていると、そこにかなりギャップが生まれてしまい
人によっては、アジャストすることができず、コンサルに出戻ることになる
そんなことが起きたりするわけです。

【「当事者意識」が違う
この話はリスクヘッジと共通する部分が多いですが
敢えて分けてみました。

これは平たく言うと
「社内SEには逃げ場はない」
という事です。

社内SEというのはプロジェクトの当事者であり、逃げる場所はありません。
社内SEは社内のIT課題を解決することが目的ですが、
そのIT課題というのは自分たちの課題でもあるわけです。

例えば、リモートワークを実現しないといけない状況になったとしましょう。
自分たちでその問題が解決できないので、リモートワーク自体をあきらめた。
という判断をすると、どういう事が起きるか?
同業他社は続々とリモートワークを実現しているのに、
自社だけ実現できていないため、働き方に制約があり
優秀な人材が確保できないだけでなく、自社の人間まで流出してしまう。
というような事態を招くかもしれません。
それはおそらく高確率で会社の業績に直結しますし、ゆくゆくは自分の給料にも影響がでてくるでしょう。

また、あきらめないにせよ
実現するには膨大なコストが発生する手段を提案した
というようなケースもダメですね。
自分たちが課題解決をするために使うお金は
「お客さんのお金」ではなく「自分たちのお金」です。
無尽蔵にお金を使って実現したとしても、そのコストが経営を圧迫しては意味がありません。
やはり自分の給料に影響してしまいます。

かと言って、限界まで安くあげようとしてせいで
セキュリティ的な問題、内部統制的な問題をはらんでいる場合もNGです。
会社がつぶれてしまっては、給料云々の話ではなくなってしまいます。

このように問題解決をする上でも、
お金の問題、内部統制の問題、社内のITリテラシーの問題
といった自社の様々な要素をすべて考慮して、最もバランスの良い問題解決を図らなければならず、下手をすると自身の収入に影響が出てしまうという意味でも他人事ではないわけです。
ちなみに、お金の問題の捉え方はSierという立場でも他人事であることは同じですが、内部統制的に無理とか、メンバーのITリテラシーが低すぎて無理とかは、長く社内にいるSierであれば身にしみてわかっているはずなので、そこがコンサルとは目線が変わるポイントです。

コンサルが対処する問題はあくまで他人事です。
リスクヘッジのところでも書きましたが、プロジェクト単位で動く為、
その認識はどこまでもドライです。
プロジェクトが終わってしまえばオサラバ
という感覚が前提にある中で、当事者意識を持てというのが無理かもしれません。
一方、Sierは長くユーザーである社内SEと一緒にいるので、
彼らがどういったことに苦慮して、課題解決にあたっているかは目の当たりにしているので
勘所が経験値としてたまっていくところが違います。

しかし、一度社内SEになってしまえば、
そんなコンサル的な考え方では企業は困るわけです。
営業や、工場の人達と同じ目線で我が事として考えてくれるITのプロフェッショナル。
それが社内SEであって、「うちの部署に関係ないです」といった風に他人事で判断されては困ってしまいます。
そもそも、そういう思考でいいというのであれば、それこそコンサルに依頼すればよいとなり、わざわざ固定費を増やしてまでIT部門を維持する必要はないということになってしまいます。
なんだか言葉遊びみたいになってしまいますが
企業が欲しいのは、

会社の課題を諸々の要素を考慮して自分事として解決にあたってくれる社内SEであって、一般論としての解決策しか提案できないのであればコンサルでいいので、そもそも社内SEがいらない

という事です。

【スキルが偏る
コンサルというのは今やITコンサルと読み替えてもよいと思います。
それぞれが特定のソリューション(製品)のプロフェッショナルであり、プロジェクトマネジメントのプロになります。

例えば、セールスフォースの導入コンサルは、セールスフォースの仕様に精通しており、他社の導入事例などのノウハウを持っていて、導入の為のマネジメントに長けている
そういう人達です。

一方、社内SEに求められるスキルは多様です。
社内で使っているITツールは多様ですし、関わる人間も多様です。
システム仕様に精通しているに越したことはないですが、それよりも
さまざまなツールやそれに付随するあるあるや、その解決に慣れていたり、
プロジェクトコントロールに長けていたり、ITリテラシーを問わず、
誰にでも対応できる柔軟さが必要です。

例えば、
「うちのユーザーはほんと曲者ぞろいだ。彼らのせいで全くシステム化が進まない。」
こういう問題にコンサルを投入しても、全くの見当違いです。
問題はシステムの理解や仕様の謎ではなく、
前向きにシステム化に取り組んでくれない社員の意識改革であったり、
システムとは?という人達に対して、階段を下りて行って、一緒に2階まで上がってきてくれる、そういうアプローチなのです。

しかし、上にも述べているようにコンサルはプロジェクト単位で動く為、
そういった能力は培われません
極端な話、導入プロジェクトの中で非協力的なユーザーがいたとしても
コンサルからすれば「面倒な人たちだけど、まぁこの人達には社内SEが対処するでしょ。私たちはシステムの導入はしたので、責任は果たしました。」と去っていくわけです。
これではこういうスキルは磨かれませんし、次々にプロジェクトを渡り歩く為、特定のシステムには精通しても、そこにばかり能力が磨かれて行ってしまい、スペシャリスト化はしてもジェネラリストにはなりえないのです。

このため、コンサルに長くいればいるほど、
社内SEとは毛色の違う人間になってしまうので、
コンサル歴の長い人ほど、社内SEにキャリアチェンジしようとした時に
そのギャップに苦しむことになりかねません。

どうでしょうか。
大きく3つの理由を書きましたが、その内容に心当たりがある人もいるのはないでしょうか。
ただ、気を付けていただきたいのはコンサルという存在そのものが悪いというわけではありません。
述べているように、彼らはスペシャリストです。
あくまで社内SEとは必要とされるスキルも、役割も違うというだけです。

社内SEになろうと思っているのであれば
コンサルというキャリアがあまり役に立たない
むしろ足を引っ張ってしまうかもしれない。
そういう事を書いているので、自身のキャリアのゴールが社内SEでないのであれば
この記事の内容は参考になりませんので、その点も踏まえて参考にしてもらえればと思います。

コメント

このブログの人気の投稿

Stories 5話:今までの経緯を知らないまま、運用設計をする

社内のコミュニケーションを活性化!グループウェア導入のススメ

ITにどう向き合う?どう向き合ってもらう?