単一ベンダと複数ベンダ

昨日の記事(無料のがあるんでしょ)で「無償で使えるソフトウェア」について触れたので、システム開発に携わるものとして発生する費用という側面からまとめてみました。

目次

前提

一応、Webアプリケーション開発・運用保守。

TCO

TCOは、システムを構築・維持する上での"総所有コスト"を指し、請求書として上がるものだけでなく人件費なども含みます。
この人件費が、実際にシステムを開発・運営する上で比重が大きいので、TCOという考え方が広がりました。
自社開発の場合はエンジニアの固定費、外注の場合はベンダコントロールに関わる時間がそれに該当します。

自社開発

一番理想的で、諸刃の剣でもあります。
理想的な理由は、

  • 会社の文化・仕組みを理解しているので、ユーザフレンドリーなシステムを設計しやすい
  • 見積書発行・精査、稟議などの工程を省略できるので機動的
  • システムを俯瞰できるSEがいるはずなので連携部分などで問題が出にくい、出ても対処しやすい

などでしょうか。

逆に、潜在的な課題としては、

  • システムを俯瞰しているSEが退職すると、運用に支障をきたすことがある
  • ドキュメントが整備されていないので、OJTができず社員が定着しない
  • ドキュメントが整備されていないので、アウトソースできない
  • 事業部門は要件定義などに不慣れのため、いざ外注するとトラブる
    (会社の文化・仕組みを忖度してくれるシステム会社ばかりではありません)

などが挙げられます。

複数ベンダ(マルチベンダ)

企業には複数のシステムが導入されていることが一般的です。
導入された時期が異なり、それぞれが連携しないシステムの場合、影響は殆ど無いか少ないでしょう。
もちろん、事業部門毎に発注している場合(情報システム部門不経由)は間接費が増える傾向にあるので、SCMの観点からはマイナスです。
これについては、以下のBPRの説明文が分かりやすいです。

based on http://e-words.jp/w/BPR.html

1990年にマサチューセッツ工科大学のマイケル・ハマー教授が提唱した概念で、その背景には高度に分業化されたため、部分最適に終始した非効率な組織への反省がある。

特に危険性をはらむのは、開発時に機能毎に分割してコンペ → 異なるベンダに発注するケースです。
大体において運用開始後、不具合があった際にユーザが気づくタイミングは実際に問題のある箇所よりも下流になるので、トラブル時には原因の特定や復旧に時間がかかることが容易に想像できます。
しかもベンダをまたがっていると、システム担当者は複数ベンダを説得しながらユーザとも調整しなければならず、且つ経営層からの業務継続のプレッシャーに苛まれるという三重苦を味わうことになります。

単一ベンダ

マルチベンダよりは理想に近いように感じます。
実際にシステム部長さんの中には、ベンダ丸投げに精神安定剤と同様の効果を見出している方もいらっしゃるようです。
企業にとって、メリットがある場合とそうでない場合を見てみましょう。

OKなケース

  • 長期的な関係を築ければ、ベンダと情報共有が進んでコストを抑えられる可能性あり
  • 受注ベンダが1社で開発を行っている or 下請のベンダコントロールができている場合、不具合発生時の迅速な対応を期待できる
  • 受注ベンダが1社で開発を行っている場合、サポート窓口が一本化されており且つ対応が早い

NGなケース

  • 単発の発注になってしまうとコスト高になる傾向がある
  • ベンダとコミュニケーションが取れないとベンダロックインになる可能性が高まる
  • 開発は下請任せで、元請がプロジェクト管理のみだと対応が遅くなりがち

まとめ

一番多い形態はマルチベンダだと思います。
端的に言うと、会社の方針や情報システム部門の能力・パワーバランスに依るところも大きいので、どれが良いというのは一概には言えません。

ただ、今現在、自社開発できていたらラッキーです。
昨今の金融関係や官庁系のプロジェクトに人員を割いている時代ですから、エンジニアを自社開発要員として確保するのは相当の覚悟・投資(支出)が必要です。

最後に、マルチベンダでも単一ベンダでも偏に管理です。
適切にベンダコントロールができる体制・ドキュメントを作っておかないと、すぐに制御不能に陥ります。
逆に、ビジネスパートナーとして歩調を合わせて努力すれば、結果が帰ってきます。
(どちらかが甘える関係は長くは続きません)

コメントを残す