サービスは作るか、買うか | A Day In The Boy's Life

A Day In The Boy's Life

とあるエンジニアのとある1日のつぶやき。

Open Source vs SaaS @ Casual Thoughts


この辺りの話題って、


・ 自社開発 vs パッケージ(ASP)

・ 社内運用 vs レンタルサーバー(ホスティング)

・ 社内要員 vs コンサルティング


という構図でも成り立つと思います。

コストや導入期間、カスタマイズの容易さなどは、ここで挙げられているメリット、デメリットがそのまま適用できるかと。

3番目は人ですが、その特性はよく似ているものかと。


まだ、Open Source vs Saasという構図は私は経験したことが無いのですが、ここで挙げた3つの例はシステム化施策が持ち上がった際に、必ずといって良いほど出る話題です。

このレベルならわざわざ社内で決裁をあげて、サーバーを調達しなくてもレンタルサーバーの方が運用コスト含めて安くね?とか。


情報システム部門は、基本ベクトルが内を向いているわけで、そこで提供できるサービスレベルなどたかが知れていたりもするわけです。

グローバルに展開している企業で、昼夜問わずアクセスがある社内システムを運用しているならまだしも、国内の拠点を結ぶだけのようなシステムであれば、情報システム部員が24h/365d張り付いて監視するメリットというのはほとんどの場合ありません。

他の社員同様に就業時間が過ぎれば返りますし、土日も普通に休むわけです。(トラぶれば連絡がきますが)


個人的な意見ですが、私はこれらの社内調達 vs 外部調達という構図に対しては、自社ですることによさを感じている方です。

コストや導入期間では、場合により外部から調達してきた方が早いことが多いですが、それを外部から簡単に持ってきてしまう事で生まれる弊害も大きいと感じています。


まずは、社内のスキルレベルの低下。

外部から調達してきた場合、社内のリソースが費やす時間の大部分は上流工程です。

技術的な要因がもとより、それにかかるコストを懸念して外部から調達するわけですから、社内の人がその技術的な領域に足を踏み入れる要因はほとんどありません。

あるとすれば、社内でそれを展開するにあたって必要な月並みで局所的な技術要素のみ。

例えば、社内でサーバーを運用するに当たってのポリシーとか、社内ネットワーク利用に関する制約とか。

これでは人が育ちません。

せっかくシステム関連の部門に勤めているのであれば、技術的な要素に触れて日々精進したいというのはエンジニアの願いでもあるかと感じます。

なので、そのスキルが社内ではありきたりであり、それを誰かに任せることにメリットが無く、かつ時間的な制約からコストをかけてもよいと判断できた場合、外部からの調達を考えたいと。


次に、外部から調達したものの場合、そのスキルが局所的でしか使えない場合が多く、エンジニアのキャリアパスを描く事ができない。

あるパッケージを導入した場合、それがメジャーで広く世界に通用するものであればよいですが、そうではない場合、それを運用する事で得られるものはほとんどありません。

基幹系のシステムであったりした場合、そのパッケージのライフサイクルは相当長くなったりもしますので、それを運用する人は、極端な表現をすればそのパッケージと心中する羽目になります。


最後に、引継ぎコストとシステムの愛着の低下。

外部から調達した場合、その展開までの期間は社内で作り上げるものに比べれば著しく短く済みます。

ただ、そこからのコストが結構あって、それを運用に持っていくまでの引継ぎのコストが結構かかる点。

また、外部から持ってきたシステムであった場合、そのシステムに対する愛着というものがでません。

それが仕事なのに何をそんないいかげんな感情で、と仰るかもしれませんが運用部隊にとってはそのシステムに愛着を感じるかどうかもモチベーションにつながったりするものです。

愛着が出過ぎるのは困りもの ですが、適度の愛着を持っていれば、いやいや運用するシステムよりは効率的にその業務を回していく事ができます。

生みの苦しみを経てリリースしてシステムはやはり愛着が出るものです。


ビジネスのスピードが加速を続けていく中で、社内のリソースを使ってというのは足枷になる場合も多いのですが、それを導入する事の弊害というのも考えてみる必要があるかと。

逆を言えばエンジニアはその外部のサービスに抵抗しうる武器を持ってないと厳しいとも言えると思います。