このエントリーをはてなブックマークに追加LINEで送る

2.1. 丸投げ文化

ハッピィ・エンジニアリング表紙

「日本のシステム業界は丸投げ文化である」

 

 開発の実態として丸投げが横行していることは多くの関係者が認めるところである。それにもかかわらず、本当の当事者はそれを認めたがらないため、状況は改善されない。

 

 ユーザ企業側で、丸投げにより恩恵にあずかれるのは発注担当者だけである。実質的に何も仕事をしなくてもSIベンダからお殿様扱いされ、システムができあがっているのだから、こんな楽なことはない。

 

 仕事の流れは単純だ。ユーザ企業の発注担当者は発注権限に基づき発注を行うが、要件定義書ひとつ作成するわけではない。せいぜい、数枚程度のメモ書きのようなものがあるだけである。お抱えの元請けベンダの営業マンも慣れたものである。仕様もあいまいなままに「なんとかしましょう、お任せください」を通用させてプロジェクトをスタートさせていく。

 

 スタートのいいかげんさが後に尾を引くことは誰もが経験していることであろう。度重なる仕様の追加要求を「ご無理、ごもっとも」とばかりに受け入れ、際限なくプロジェクトのスコープは膨張していく。それでも、なんとか、とにもかくにも納品までこぎ着け、営業マンは次の仕事を頂戴しに行くわけである。

 

 その結果、割を食うことになるのはSIベンダの技術者とシステムのエンドユーザ、そしてユーザ企業の経営者である。開発メンバには無理が、ユーザ企業にはさまざまな意味で損害が襲いかかってくる。「業務を熟知している」といわれるSEによってかろうじて維持されているボロボロのシステムが稼働し、一見すると、良好な関係のように見えるSIベンダとユーザだが、その根底には、営業と発注担当の丸投げによるなれ合い関係がある。発注担当者はSIベンダに甘え自らのやるべき職務を放棄して丸投げし、ベンダ側も癒着することで高い利益を確保しようとする。甘えと癒着の構図である。

 

 もう少し細かく見ていこう。プロジェクトは、発注金額が要件定義以前に確定するところから始まる。

 

 ユーザ企業の発注担当者による、かなり適当かついいかげんな要求(例えば、「売り上げを管理する」程度の言葉)に対して、SIベンダが値づけをして多少の駆け引きの末に発注金額が確定する。

 

 その際に、「有能な」営業マンなら相手の懐を探る。発注側が、いくらの予算をそのシステムに投じようとしているのかをつかもうとするのである。すべては「初めに予算ありき」なのだ。提案段階では夢を語り、同業他社の事例で横並び意識と危機感をあおり、仕様を膨らませ、思いきり予算枠を拡大するのである。

 

 予算が確定した後、SIベンダはエンドユーザにヒアリングを行い、要件定義「的なこと」を行う。

 

コラム:要件定義「的なこと」

 

 なぜ「的なこと」とつけたかというと、要件定義とは本質的に大きく異なるからである。簡単な打ち合わせ資料は作成するにしても、SIベンダ側で、要件定義の内容をすべて文書化し仕様凍結を行うことはまずあり得ない。これには以下のようないくつかの理由がある。

 

  1. このようにルーズな発注元企業の場合、どうせ要件定義書を納品物に加えない。そもそも要件定義書は発注元が作成するという建前がある
  2.  

  3. 「 仕様凍結」がしょせん儀式にすぎず、開発の過程でどうせ仕様追加が多発することはわかっているので表立った行為はしない
  4.  

  5. 仕様を極小化してコストを抑えることが目的なので、仕様の規模が視覚化され把握しやすくなるのは好ましくない
  6.  

  7. 近年ドキュメンテーションコストが増大している。できることなら、文書化のコストと工期を省き、とりあえず動くもの、つまりプログラムを納品することでごまかしたい

 

本来であれば、ユーザ企業の発注担当者が追加機能のコスト見積もりを元請けに要求し、ROI(Return On Investment:投資対効果)を算定して追加開発の是非の判断を下すところだ。だが、上述のとおり、それまでの経緯自体に合理性や正当性は何もないため、ユーザ企業側はカットオーバ直前まで「あれを入れろ、これをやれ」とわがまま放題のことを言う。殺し文句は「この機能がなければ、このシステムは役に立たない。検収しないぞ」である。本当にそこまでやることはまずあり得ないが、妙に慣れた発注担当者はよくこの手を使う*1。結局は、現場で営業やプログラマとユーザ企業の発注担当者が、「ああだ、こうだ」と言い合いながらその場で機能を追加しているのである。

 

 結果から見ると、当初の予算を前提にするとボロもうけだったはずが、仕様や機能が膨らみ、まあまあ大もうけ程度になってしまうわけだ。これが丸投げの実態である。さらに丸投げが下請けに連鎖する場合には、このような駆け引きすら抜きで中間搾取に徹する。*2

 

 2005年6月14日付の読売新聞のWebサイトの記事に、この丸投げ文化による甘えと癒着の構図を象徴したものが掲載された。各府省庁別に、年間経費が10億円を超え、長年にわたり特定業者との間で随意契約が結ばれてきた16府省庁の36のシステムの「刷新可能性調査」を行ったところ、それらの契約方法を見直すことにより、年間の運用経費を最大で計950億円も削減できることが明らかになったと記載されている。*3

 

 この記事で調査対象となったシステムは、あくまでも年間経費が10億円を超え、長年にわたり特定業者との間で随意契約が結ばれてきた16府省庁の36のシステム、つまり全体から見たら氷山の一角である。長年にわたり官公庁のシステム調達は、長期にわたる随意契約によってシステムの調達金額を高めているといわれていた。

 

 この調査により、その実態として以下のような問題が指摘されている。

 

  1. センター設備・端末・ネットワークなど、徐々に減額が可能なものへの支出が変化していない
  2. 次年度契約のための予算策定にあたり、過去の実績を参考に適切な経費に近づけていく方策が取られていない
  3. 実績と大きくかけ離れた過剰なシステム投資が行われている

 

 これが甘えと癒着の構造なのだ。ユーザ企業の発注担当者は、いくら暴利をむさぼられても、「よきにはからえ」と悠然として契約を継続する。これは、自社に対する背任に等しい行為である。ユーザ企業には、それを監査する能力がないことを露呈しているともいえよう。

 

 このように、丸投げ文化の一番のデメリットは、ユーザ企業が適切なものを適正な価格で入手できないということである。少数の優れた例外を除けば、ほとんどの場合、ユーザ企業に多くの問題が生じている。ITガバナンスの崩壊と呼ばれる現象である。以下に具体例を挙げる。

 

  • 「システムのことはよくわからん」という言い訳で経営戦略におけるシステム戦略の立案を放棄
  • 中途半端なシステム知識を持ち、妙な技術論に陥る半可通
  • SIベンダの食い物にされているお殿様(「よきにはからえ」)

 

 結果的にSIベンダの提案を待つという愚かなスタンスになる。このようなボタンの掛け違いが、「情報システム産業の企画提案型ビジネス」という「あだ花」を生むのである。

 

 ここで、「あだ花」という表現に違和感を覚えた読者も少なくなかろう。「企画提案型ビジネスの、どこがあだ花なんだ!?」と思われるかもしれない。しかし、冷静に考えてもらいたい。規模の大小を問わず、ひとつの企業が経営を行っていくには、企業戦略が必要となる。経営戦略のひとつの要素として情報システム戦略が存在する。あたりまえの話だが、情報システム戦略は、それ自体単独で存在し得るものではない。商品戦略や営業戦略などと密接な関係を持つ。そうした一企業のあるべき姿を実現するために、中・長期のシステム・ビジョンが作られ、そこに至る道筋を明示したシステム化計画が立案される。当然すぎるほど当然の姿である。建前上は多くの企業がこうした計画を立案している(ことになっている)。

 

 しかし、舞台裏の実態は大きく異なる。システム企画部門の企画能力は著しく衰えている。*4 空虚で実態のない計画書もどきがあるだけである。結果的にユーザ企業の企画部門は、自社の将来のシステム・ビジョンを策定することもできないままに、お抱えのベンダを中心にベンダ各社に声をかけ提案書を持ってこさせる。

 

 上述のとおり、経営戦略が情報システム戦略に優先する以上、結果は自明であろう。しょせんシステムの専門家にすぎない連中に、その業界や業種・業態におけるシステム化のビジョンを委ねること自体が大間違いである。システム営業を行うものが多く経験してきているように、まともな提案書が書けるのは「同一業種の横展開」のときだけである。A社で得た業務知識を同業他社のB社に持っていくから見てもらえるのであって、まるで未経験の業界に提案書を持っていったところで相手にされないのがオチだ。

 

 ごくあたりまえの考え方を積み重ねていくだけで、「情報システム産業の企画提案型ビジネス」というものの「いかがわしさ」が見て取れる。にもかかわらず、こうしたビジネス手法が必要悪として成り立ってしまう商慣習や文化をじっくりと見直す必要がある。
 システム開発の実態は図2-1のようになっているのである。

 

 

 

 あるSEが自嘲気味につぶやいた言葉がある。

 

「大きなシステムを動かすには人柱が必要なんだ。そのサーバの下にも2〜3人埋まっているぞ」

 

 確かに大規模プロジェクトを推進する過程で心身を病んでつぶれていくSEは後を絶たない。図2-1は、しわ寄せが最末端に位置する下請けの開発会社に集中する図式で描いた。もちろん、プロジェクトごとに誰に過大な負荷が加わるかは異なるが、実際にものづくりをしている者が厳しい立場に置かれるケースが多い。低賃金で過重な業務量に押しつぶされていっている。

 

 開発側のみならず、発注側であるユーザ企業にも問題は多い。

 

 ユーザ企業からシステム開発機能が失われて久しい。ほんの一部の企業は血を流しながら開発機能を復活させようとしているが、多くの試みが成功しているとは言い難い状況にある。

 

 歴史的に見ると、さまざまな企業がいわゆる「システム開発部」を持ち、自前でプログラマを抱えていた。しかし、そこには大きな問題があった。

 

 ユーザ企業の基幹系システムの開発は数年の周期で行われる。バージョンアップやリビジョンアップはともかく、本格的なリプレースを毎年行うことは投資対効果の観点からあり得ない。ところが、SIベンダや専業の開発会社はその間に「横展開」という名のもとに、最新の要素技術を取り入れながら同一業界・業種・業態で同種の開発を繰り返していくことができる。

 

 ユーザ企業のシステム開発部のエンジニアと、SIベンダや下請けの開発会社のエンジニアでは、現場経験の量が異なるうえに、反復による学習効果によってスキルレベルの差が大きくなってしまったことは否めない。

 

 ユーザ企業は、スキルレベルが低く、ほかに潰しが効かない、妙にプライドの高いシステムばかを多数抱えることになってしまった。結果として、多くの企業がシステム開発を外注化し、低コスト化・高品質化・余剰人員の整理を行うこととなった。

 

 日本企業は高度成長期以降、終身雇用制を標榜し生え抜き偏重であったために、労働市場の流動性に乏しかった。その結果として、ユーザ企業にはシステム技術者が存在しないという状況が生まれたのである。それに対して、SIベンダはどのようにアプローチしたか。

 

「私どもにすべてお任せください。悪いようにはしません」

 

丸投げ文化の発生である。

 

運命からの脱却

 

 では、「丸投げ文化」から脱却するにはどうしたらよいのだろうか?
「丸投げ文化」は甘えと癒着から発生している。それならば、その癒着した部分を切り離すだけのことである。

 

  • 競争入札を行い、適正価格で発注する
  • 設計と製造の作業を分離し、それぞれを別の企業に発注する

 

 単にこれだけのことで、癒着した部分を切り離すことができる。

 

 プラント開発の場合、設計と製造は別々の業者に発注されるのが一般的である。それぞれの仕事がいいかげんでは、完成したプラントに問題が発生する。プラント事故は下手をすれば地球規模の災害となる。このような高いリスクを軽減するために、発注された業者は、受注した業務と同時にそれぞれの仕事に対して監査の役割も併せ持つのである。

 

  • プラント設計は専業の企業が行う
  • 設計者は発注企業側の立場に立つ
  • 設計者は製造側が設計を順守していることを監査する
  • 設計企業はプラント製造に関与しない

 

 同じ会社に設計と製造を任せたら、作り手にとって有利になるように設計するのが当然なのである。

 

 システム開発の世界では、開発を「設計−製造」の2段階ではなく、「要件定義−設計−製造」の3段階に区分するのが一般的である。そして、「要件定義」と「設計−製造」の2つを対立的にとらえている。その結果として、「要件定義が不十分だった」という愚にもつかない反省が何十年も繰り返される結果となっている。しかし、本来は「要件定義−設計」「製造」に分けるべきなのだ。

 

 設計と製造を同一の会社が行うと、自然に「製造しやすい設計」を意識的または無意識のうちに行ってしまう。しかし、本来は要件定義で確定した業務仕様をシステム仕様に落とすという設計作業で、重要なのは「要件定義を満たす設計をすること」であり、「製造を意識した設計をすること」ではない。*5

 

 ユーザ企業が自社で設計ができないのであれば、プラント設計事務所ならぬ、システム設計事務所に依頼すればよい。システム設計事務所は、無理に仕様を膨らませて多くの金額を取りにくる必要はなく、要件の追加に頭を悩ます必要もない。適切な設計料で適切な設計書を納品すればよいだけのことだ。

 

 

 


*1 ユーザ企業の発注担当者が強気に出たときのあしらい方は千差万別で、営業・SE・個々人で違い、相手によっても出方が違う。ある意味で職人芸である。

*2 実際にはプロジェクトが火を噴き、後始末に追われ収支がトントンに終わることも往々にして起こるため、中間搾取イコール利益とはならない場合が多い。また、二次開発や運用による収益を見込んで、一次開発は安値で受注する場合もある。
*3 http://www.yomiuri.co.jp/national/news/20050614it01.htm ※本書発売時点では、すでにリンク切れとなっている

*4 これも多くの関係者が認める現象でありながら、当事者は認めたがらないもののひとつである。
*5 実現可能性については、製造を意識するのではなく別途設計工程と並行したフィージビリティ・スタディ(実現可能性調査)を行うことで担保する。

シェアしてくれると嬉しいです!
このエントリーをはてなブックマークに追加LINEで送る

2.1. 丸投げ文化 ハッピィ・エンジニアリング関連ページ

2.2. 価格破壊+やらされ仕事=低い満足度
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
2.3. 中間搾取でボロもうけ
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
2.4. 人手余って人材足らず
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
2.5. 根性、根性、ド根性
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。

ハッピィ・エンジニアリングとは? 書籍を読む プロフィール コンサルティング