未分類

ユーザ企業はなぜシステム開発を丸投げするのか?

「仕様変更をするなら、ユーザ企業が自分でシステムを作ればいいんじゃね?」

そう考えるシステムエンジニアの方は多いだろう。SIerの自分たちよりユーザ企業の方が業務要件は詳しいはずだし、少なくても仕様書をレビューする程度の技術力もあるはずだし、なによりコッチは徹夜作業でお腹いっぱいなのに、お前らは定時で帰っているだろ、と。

そこでこのエントリでは、10年以上携わってきた社内SEの観点から、ユーザ企業はなぜシステム開発を丸投げするのかについて考えてみる。

結論から言えば、内製開発をした方がいいと思っていても丸投げが不可避になるという、摩訶不思議な組織力学のダイナミズムに行き着く。

システム開発を丸投げする原因は?

ユーザ企業の人事部は技術者を求めていない

まず、ユーザ企業の人事戦略を考えてみる。

一般に、日本の大企業の人事担当者は「どれくらい人事異動を成功させたか」で評価される。昨年度の採用方針・給与方針・組織構造などが全く問題なかったとしても、前年踏襲では人事担当者自身は全く昇給しない。つまり、何でもいいから変えることにインセンティブがある。

また、人事の視点では「ある社員がいなくなったときに会社が回らなくなること」は事業存続に関わる経営上のリスクとなる。このリスクを回避するため、どれだけ業務の属人性を撤廃するのかがミッションとなる。あくまで社員は会社の部品であり、それは代替可能でなければならない。

このインセンティブおよびミッションは、「多角的視野をもたせる」という大義を作り上げ、定期的な人事異動をすすめていくことにつながる。とりわけ、現在の部署で結果を残し、高い評価を受けている社員が異動の対象になる。

その結果どうなるかといえば、必然的に「広く浅く」対応できるジェネラリストな社員で満たされていく。極端な話、営業部長が情シス部長になったりもする。すると、Oracle DBとMySQLの違いすらもわからないCIO(最高情報責任者)が生まれるわけだ。

そう、あなたは信じられるだろうか。ある日突然、100億円級のシステム開発の決裁権限者が、つい先日まで営業部門で飲んだくれていたオッサンになるのだ。

システム開発には高度な技術者が必要である

一方、競合他社と競争していく上で、社内業務のシステム化は必須である。

なんでもいいけど、たとえば、請求書発行を手作業でやる会社と、全て自動化している会社があったら。たとえば、稟議書でハンコ・リレーをしている会社と、ワークフローシステムで Just in Time で稟議可決できる会社があったら。もはや議論の余地なく、後者の企業が優位になるだろう。やっぱり情報技術ってすごいわけだ。

だが、実際にシステムを構築するためには、極めて高度な専門的知識が必要になる。技術戦略、要求開発、要件定義から始まり、クラウドにするのかオンプレにするのか、どんなハードウェアを用意してどういう高可用構成をとるべきか、どのデータベースを選定しどんな設計にすべきか、アプリケーション・フレームワーク、コーディング、テスト、サービスデスク、セキュリティ、プロジェクトマネジメントなど、様々な領域のスペシャリストが一同に介して作り上げられる一品物の芸術品である。

先日まで営業部門で飲んだくれていたオッサンにはこの芸術品の価値は分からない。オッサンが認識しているのは、いままで自分が必死に稼いできた金を湯水の如く使う、横文字だらけのよく分からないハコだ。

システム開発はだいたい失敗する

他方でもう一つ。システム開発に失敗はつきものである。

JUAS(一般財団法人 日本情報システム ユーザ協会) の2015年レポートを参照すると次の数字が出ている。

  • 14年度、500人月超案件で、スケジュール遅延がなかったのは 25.5%
  • 14年度、500人月超案件で、予算超過がなかったのは 32.1%

システム開発が失敗した原因は、要件がまとまらない、仕様変更が多発した、予算が足りない、想定よりも多くのトラヒックが発生した、製品バグを踏んだ、プロジェクトマネージャが病院送りになったなど理由は様々だが、恐ろしいことに大規模案件の半数以上は失敗する

さて、ユーザ企業においてこの「失敗」はどう映るのだろうか。高い金を払ってプロにお願いして、それでも失敗するしたとしたら、もちろん誰かが責任を取らなければならない。すなわち、失敗したとき用の保険が必要だ。

丸投げしか選択肢がない

定期的な人事異動により「広く浅い」人材育成するミッションがある一方で、システム開発は極めて専門的知識を持つ「狭く深い」人材がいなければ実現できない仕事である。システム開発には専門的な技術者が必要だからといって、自社で人材育成したり中途採用したりすれば、属人的であるとの理由から他の部署に移動させられる。

にも関わらず、だいたい失敗するので、責任を取らせる「誰か」を保険として用意しておく必要がある。

 

なんかひどい話だね・・・

うん、結局、自部署とか自分の保身が大事なわけで。

 

さて、この矛盾を解決する手段はあるだろうか。

つまり、「丸投げ」になるわけだ

 

ユーザ企業も分かっている。自社のコア・コンピタンスを支えるシステムなのだから、自社で作ればいいのだと。だが、組織力学のダイナミズムにより、自社社員は「広く浅く」人材育成し、専門技術は丸投げし、責任を取らせる保険としてSIerを用意すること。これが人事と経営層が結託したときの唯一の解になっている。

 

そうして選ばれた発注側システム担当者が、あなたの眼の前に居る人だ。彼は、つい先日まで営業部長だったオッサンに毎日こう言われているのである。

お前らが技術に精通していないから外注しているんだろ、非機能要件とか難しい言葉を使うな、性能が出ないとか論外だろ、追加工数など認められるワケがない、ローンチが遅れるとかよくも平然と報告できるな。そもそもこんなプロジェクトはじめるべきではなかったのだ、俺が稼いできた金を無駄にして楽しいか、このSIerを選んだ責任はお前が取れ、俺の手を煩わせるな、二度とその辛気臭いツラを見せるな。

もちろん、だからといって、あなたの眼の前の人を優しくしてあげてとか、同情してあげてとか、察してあげてとかいうつもりは一切無いのだが、多重請負構造のさらに上流にも同じくらい深い闇があることを知っておくと、有用な局面があるのかもしれない。

じゃあどうしたらいいのか?

じゃあ、どうしたらいいのかといえば、丸投げせずに内製開発を推進していくことが解になるだろう。仮に「簡易に・誰でも」内製開発ができるのであれば、高度な技術者は不要になるので、人事戦略にも、責任問題にも発展しなくなる。

で、実際のところ、「簡易に・誰でも」な内製開発がはじまっている。

SoE(System of Engagement)系を中心に、API文化が根づき始めたことで、ひとつひとつのシステムの規模が小さくなり始めていることから、技術的ハードルが下がりつつある。僕の実感としても、大鑑巨砲的なモノリシックシステムの引き合いは減りつつある。

また、クラウド技術などの発展により、システム開発の民主化がはじまっている。当然、サーバ設置工事をしなくてもいいし、OracleのREDOファイルを誤って消すこともありえない。僕自身で言っても、AWSやsalesforceなどで遊んでいたりするのだけど、これらのマネージドサービスを使うと、ほとんどコーディングせずとも簡単な業務システムを作ることができてしまう。

つまり何がいいたいかといえば、今後、システムエンジニアの食い扶持が社内SEに奪われるかもしれません。(笑)

おわり。

COMMENT

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です