いつまでたってもシステム運用でユーザー企業とSIerの利害が一致しない理由

あらゆるものは作った人が維持し続けられるなら、それに越したことはないのです。

家をリフォームする場合、知らない大工さんに頼むよりも、その家を建てたに大工さんにお願いする方が手間は少ないでしょう。
大きなノッポの古時計も、もし御存命なら作った職人さんが直した方が良いでしょう。
壊れかけのレディオを直したいなら、半田ごてが得意なおじさんにお願いするよりもメーカーに修理に出した方が良いでしょう。

システムも構築した人が運用する方が上手くいく場合が多いと思います。
トラブルが発生しても、細かい設定値も把握しているし、構築中に起こった事象も把握している。
そして何よりも、システムを動かしているアプリケーションや製品を最初から構築したノウハウがある。構築期間で設定値を色々と試したノウハウがある。
こういったノウハウのすべてを運用者へ引き継ぐことは不可能です。

運用者に引き継ぐ場合、まずはアプリケーションや製品の技術的な習得から始まるのでロスが大きいし、そのスキルが期待値に届くまで年単位の時間がかかる場合もあります。

ユーザー企業は、構築したメンバ―が運用に残って安定させてほしいのが本音かと思います。
しかし、SIerからしたらシステムを構築した経験を積んだ人は次の案件で活躍させたい。スペシャリストに育てて、単価を上げていきたい。
運用は単価も低いし、違うメンバー（もしくは下請け）に任せたい。
（ここには業務委託という契約の問題も含まれている場合がありますが、それはまた別の機会で）

こうして、あまり知識とスキルがない人がシステムの面倒を見る仕組みが出来上がります。
これは逆の弊害もあって、運用と開発・構築が分断されることにより、運用をしたことない人がシステムを構築をし続けることになります。
するとすべからく、運用をあまり考慮しないシステムが構築され続けることになります。

じゃあ、ユーザー企業でエンジニアを抱えれば良いかというと、それでも少しだけ問題が残ります。
ユーザー企業では基本的に1つのシステム導入を1回しか経験できないので、その体験を相対化することができません。
自身の経験を相対化するためには、似た内容のことを複数回こなす必要があります。
相対化できないということは、自分たちのシステム導入や運用がベストなのか判断できないということになります。
その結果、他の企業は同じシステムをもっとよく使っているのではないか、隣の芝生は青いのではないか、という疑念に心がとらわれてしまいます。

SIerであれば、現場から現場へ渡り鳥のように飛んでいき、システム構築ができます。特定の技術領域についてあらゆることを試し、経験をどんどん相対化していくことができます。
スペシャリストを特定の領域ですべての地雷を踏んだことがある人と定義するなら、SIerの方がユーザー企業でエンジニアをするよりも圧倒的に早くスペシャリストになれるでしょう。

これらの問題を解決するには、いくつかの方法があると思います。
ユーザー企業同士が情報連携する仕組みを作るのも良いでしょうし、SIerのスペシャリストから定期的に運用チームにノウハウを提供する仕組みを確立するのもありでしょう。

次回、このあたりをもう少し掘り下げて考えてみたいと思います。

【宣伝】
運用設計のノウハウで迷ったら、「運用設計の教科書」がオススメですよ！

運用設計の教科書 ～現場で困らないITサービスマネジメントの実践ノウハウ