情報サービス業の課題と対策

ここでの情報サービス業とは、主に中小規模の受託ソフトウェア業を対象にします。この業界は多くの課題をかかえています。その多くは、他産業と共通した課題ですが、情報サービス業ではそれらが深刻なものになっています。
　これらの課題を解決することは、情報サービス業の健全な発展のためだけではありません。ユーザ企業が品質の高いサービスを安価に迅速に得られる環境を創出することは、ユーザ企業の健全なＩＴ活用のため、さらには、国際競争力の強化のためにも重要です。
　そのため、情報サービス業の努力だけでなく、ユーザ企業の協力や国の施策なども必要になるのです。

下請構造からの脱却

情報サービス業が労働集約型産業になっているのは、ＩＴ技術者の大半を占める中小企業の受注ソフトウェア企業がプログラミングなどの下流業務を下請受注しているからです。しかも、多段階な下請構造になっており、末端下請では極端な労働集約型業務になっています。
　次のような理由により、情報サービス業では下請構造が構成されやすいのです。

需要に繁閑があるため社員数を少なくする

ユーザ企業からの個々のソフトウェア需要に応じる受注開発ソフトウェア業が多く労働集約型産業であること、しかも、その需要に繁閑の差が大きいからです。そのため、自社の社員を少なくしておき、不足分を下請利用によりカバーする手段がとられます。 （説明）

ユーザ企業からの発注に繁閑の差が大きい理由には、次のことがあります。

• ユーザ企業の景況
  ユーザ企業が好況のときは、積極的に新規開発を行いますが、不況のときは、新規開発をする余裕がなくなります。ここで重要なのは、その幅が大きいことです。情報システム関連費用は、ハードウェアやソフトウェアのレンタル費用など既存システムの維持支出が大きいので、ユーザ企業としては、不況でもＩＴにそれなりの費用はかけているとしても、新規開発の発注がほとんど行われないこともあります。
• 法律改定等による特需
  西暦２０００年問題などの自然現象、Ｊ－ＳＯＸ法などの法律改定、国際会計基準への移行など、ユーザ企業にとっても外部的な要因により、情報システムの大規模な改訂が必要になります。これは、全産業に共通に発生することなので、一挙に大きな需要になります。
• 短納期化の要請
  ユーザ企業は、競争激化に対応するために、情報システムを立案してから短期間で実施する必要があり、情報システム開発の受注から納入までの期間が極端に短縮することが要求されるようになります。これは、短期間に大量の要員投入が必要になること、長期的に安定した受注が得られないことになります。

　さらに、大規模情報サービス業から受託した中規模情報サービス業は、同じような理由により小規模情報サービス業を下請として利用します。それで、多段階な下請構造になりがちです。

中小ソフトウェア業には受注での資金的な制約がある

受注する情報システムの規模が大きくなるのに伴い、資金的な制約から中小のソフトウェア業では資金面の制約から受注できず、大手ソフトウェア業の下請になります。元請けとなった大手ソフトウェア業は、付加価値の高い上流工程を自社で担当し、労働集約型で付加価値の低い下流工程を下請に回します。 （説明）

システム開発を請負契約したとき、代金支払いは納入後になるのがこれまでの慣例でした。ＩＴ化の対象業務が大規模になると、中小の情報サービス業では開発途中の資金繰りができなくなります。
　２００７年の企業会計基準改正に伴う税法改正により、２００９年４月から、ソフトウェア開発も工事進行基準が適用されました。しかし、それを実施するには、進捗度の把握などベンダの総合的なマネジメント能力が求められます。（参照：「工事進行基準」
　システム開発を工程ごとに分割して契約する（後述）のがよいのですが、それには発注側との折衝が重要になります。

上流工程も含めた受注ができる人材がいない

労働集約型ではない付加価値が高いのは上流工程です。システム計画立案や仕様の作成などの上流工程を受注するには、客先の経営者に適切な提案ができなければなりません。ＩＴコンサルタントやＩＴストラテジストの技量が求められます。これまで下流工程を下請受注していた中小情報サービス業には、そのような人材が欠けています。

末端下請では、受注の不安性をまともに受けます。需要が大きいときには、過重な労働が強いられ、需要が小さいときは、不利な条件での受注を強いられたりする状況になります。これでは、安定した経営はできませんし、ＩＴ技術者は劣悪な労働環境を強いられることになります。
　これは本人にとって不幸であるだけでなく、一般の人がＩＴ技術者に関するイメージを悪くしています。健全な情報化社会を構築し国家経済を発展させるために、ＩＴの高度利用が必要であり、優秀な人材をＩＴ分野に向けることが重要だとされています。３Ｋ的なイメージが多いと、その実現が阻害されてしまいます。

ユーザ企業への影響とユーザ企業の協力が必要な課題

情報サービス業界が多段階下請構造になっていることは、ユーザ企業にとっても大きな問題になっています。

システム開発コストが高くなる

多段階になるほど、中間マージンが多くなります。ユーザ企業が直接に実際の作業者と契約すれば、コストを低減できます。しかしそのためには、ユーザ企業がシステムインテグレータと同様な管理体制が必要になります。一部の企業を除いては、そのような人材が欠けています。

ユーザ企業から実作業者が見えない不安

多段階下請構造は、ニーズが実作業者適切に伝わらない、責任の所在が不明確になる、個人情報の漏洩などセキュリティ対策が困難になるなど、多くの問題を抱えています。

ユーザ企業からの受注の繁閑が下請構造の原因だといわれても、ユーザ企業に平準化を求めるのは無理があります。契約での対策がとられていますが、副作用もあります。

下請発注禁止契約

ユーザ企業が元請ベンダと契約するときに、多段階下請を禁止すること、下請を利用する場合はユーザの承認を得ることなどの条項を加えることが考えられます。ところが、これを進めることにより、かえって下請企業が仕事を失ってしまうことが考えられます。

分割発注

ユーザ企業が一括して発注するから規模が大きくなり複雑になるので、上流工程と下流工程に分割、情報システムをサブシステムに分割するなどを行えば、下請発注を減らすことができます。しかし、そのためには、ユーザ企業でシステムインテグレータのような業務を行える高度な技術者が必要になります。 （説明）

システム開発は、不確定要素が多いことなどから、開発途中や事後になってからトラブルが生じることが多いのです（参照：「情報システム調達契約での問題点」）。それで、外部仕様書作成までの上流工程、プログラム作成および実装までの下流工程、運用工程などに分割して契約するのが望ましいといわれています。

• 不確定要因に関する契約
  本来ならば、構築すべき情報システムに関して、ユーザ企業がニーズを明確に示し、ベンダ企業がそれを十分に理解して最適な情報システムを提案できる必要があります。ところが、対象業務の関係者が多様になり、ニーズが複雑になるのに伴い、「いつになっても要求がまとまらない」「開発が進んだ段階になってから要求変更が起こる」などの問題が発生します。
  　これらは、納期遅れや大きな手直しの原因になり、契約した期間や金額をオーバーしてしまいます。それをめぐって訴訟になるケースも多くあります。このようなトラブルを避けるために、不確定の要因に関して契約時で明確にしておく必要があります。
• 分割契約の必要性
  従来は、プロジェクト全体の全工程を一括して契約することが通常でした。それを、要求定義までの工程、システム構築の工程、運用・保守の工程のように分割し、システム構築の部分をサブシステムに分割して契約する分割契約にするほうがよいとされています。
  
  • 一括契約では、不確定要因が大きな初期段階で、全体の費用や納期を決めるので、計画と実際の差異が大きくなります。分割することにより、各工程での不確定要因を小さくすることができます。
  • 分割することにより、それぞれの工程に適したしたベンダを選べるので、効果的な結果が得られ、開発価格を下げることができます。
  • 一括契約では規模が大きいので小規模ベンダでは受注できないのですが、分割することにより、小規模サービス業、専門技術に特化した情報サービス業が直接に受注できる機会が増大します。
  　しかし、分割契約にすることは、システムインテグレータに丸投げしていた業務を、ユーザ自身が行わなければなりません。それには、高度なＩＴ技術者や管理能力が必要ですし、かなりの作業が必要です。
  　２００９年４月から、会計基準が「工事進行基準」になりました。情報サービス業の決算（４半期ごと）では、受注した情報システムの開発がどこまで進んだかを基準に原価を算出することになりました。これに対処するには、各工程での売上や費用を明確にする必要があります。この基準への移行は、分割契約を進めるきっかけになると期待されます。

人月ベースの見積もりからの脱却

情報システムの価格は、伝統的理由、管理的理由などにより、開発に要するプログラムステップ数を推定し、平均的なプログラマの生産性から工数を算出して、人件費等を乗じる方法がとられてきました。これを人月ベースの見積もりといいます。下請への発注もこのような方法で「○○ステップのプログラムをいくらで開発するか」で決定しているのです。
　これでは、優秀なシステム設計、プログラム設計の能力をもつ技術者の価値が反映されませんし、部品を適切に再利用する技術も生かされません。これが、情報サービス業が労働集約型産業から脱却できない元凶であるといわれています（説明）。

全投資におけるＩＴ投資の割合が高くなるにともない、コストダウンの要請が強くなります。
特に情報システムの開発では、コストのメカニズムが不明確であることが問題になっています。

• 情報システムの価格
  通常の商品では、価格は利用者からみた価値（効用）で決定されるのが一般的ですが、個別システム開発では、開発にかかる費用を基にした価格交渉が行われるのが通常です。しかも、開発費用の見積もりには多様な方法があるのですが、開発工数すなわち人月（何人が何カ月従事するか）をベースにした見積もりが広く行われています。
• 人月方式による算定方法
  昔は、システム開発にかかる作業の大部分はプログラミングでした。それで、開発すべきシステムのプログラムステップ数を推定して、標準的な１人のプログラマが１カ月で作成するプログラムステップ数を用いて人月を算定したのです。また、事後での評価でも、開発に要した費用と、実際に従事した人月や仕上がったプログラムステップ数を用いていたのです。
• 労働集約型の温床
  人月方式は、システム開発を単純労働としてとらえています。優秀なプログラマは、プログラム作成の生産性が高いだけでなく、既存のサブプログラムや共通する要素をサブプログラムとして部品化して再利用する能力が高いので、プログラムステップ数を少なくできます。また、品質を向上させるために、必要なロジックを追加してプログラムステップを増やすかもしれません。
  　ところが、そのような工夫をすると、かえって不利なことになります。すなわち、優秀なプログラマを投入することがベンダ側の利益にならず、平凡なプログラマを安価で使うほうが有利な環境にしているのです。これが、労働集約型産業にしている原因だと指摘されています。
• オフショア開発による圧迫
  経営に密着した分野や大規模プロジェクトの運営など付加価値の高い業務を主とする企業と、指示されたプログラムを作るような分野を主とする企業では、格差があるのは当然です （図表）。
  　中国やインドなどは、日本にくらべて人件費が安価で、しかも、国をあげてＩＴ技術者の育成を行っています。また、日本語の習得意欲も盛んです。そのため、安価で優秀なＩＴ技術者を求めて、情報システム開発を海外に発注する傾向が進んでいます。それをオフショア開発といいます。オフショア開発は急激に増加しており、下請情報サービス業は、オフショア開発との価格競争に追い込まれる状況です。
• 生産性向上努力の阻害
  個別にシステムを構築するのではなく、「ＥＲＰパッケージ」のような既存の統合パッケージによる開発が普及してきました。また、個別仕様のシステム開発でも、白紙の状態からプログラムを作成するのではなく、部品化・再利用、品質向上のための技術や方法論が発展してきました。ところが、このような技術や方法論を活用することは、人月方式では単価が高いというマイナスの評価になります。これでは豊富な経験、蓄積されたノウハウ、開発方法論などが適切に評価されません。
• 上流工程の価値
  経営に役立つ情報システムにするには、プログラミング以前のシステム化企画、要求分析などの上流工程が重要です。これには人数ではなく質が問題になります。人月方式では、このような工程に優秀な人材を投入するインセンティブを阻害します。

人月見積から脱却することは、品質の良いシステムを低価格で短期間で開発することがベンダの利益に直結することを意味します。これは、発注者であるユーザ企業にとってもよいことです。

情報サービス業の課題

当然、情報サービス業自身が取り組むべき課題は山積しています。

パッケージソフトウェア業へのシフト

受注開発ソフトウェア業を継続していれば、労働集約型産業にとどまってしまいます。パッケージソフトウェア業へとシフトすることが根本的な解決になります。しかも、多様なパッケージソフトが流通することは、ユーザ企業にとっては、特注品でなく既製品で購入できるので、これも品質・価格・期間の面でよい影響をもたらします。ところが、日本では、パッケージソフトの利用が（近年は進んできているのですが）他国とくらべて低い状態です。 （図表） （説明）

パッケージソフトウェア業に転換すると、次のように、労働集約型から脱却する効果があります（パッケージソフトウェア業には、第三者が作成したパッケージを販売する場合と自社開発をする場合がありますが、ここでは自社開発を例にします）。

• 新規パッケージの開発には費用がかかりますが、多数のユーザ企業に導入されれば、大きな利益が得られます。
• 価格が工数で決まるのではなく、パッケージの価値によって決まります。技術力の向上が利益に直結しますし、それが蓄積されます。
• 開発スケジュールが自社で決定できるので、繁閑差を少なくできます。すなわち、全体としての生産性を高めることができます。

しかし、それには高いハードルがあります。

• 多数のユーザ企業に採用されるには、対象業務のベストプラクティスに関する知識・スキルが求められます。
• よいものを作るだけでなく、ユーザに認知されること、ユーザ満足を得られる商品にすることが必要です。商品開発、初期利用のためのユーザ企業の協力を得るためには、人脈も必要です。
• 初期投資から回収までの時間がかかります。その間の資金繰りができる財務能力が必要です。
• 常に改良が求められます。そのための体制を整備しなければなりません。

パッケージによる開発には、ユーザ企業側の対応も重要です。、従来の自社仕様の個別システムではなく、共通仕様のパッケージによる開発を重視する考え方の転換が求められます。ＥＲＰパッケージの普及により、その転換が進んできましたが、それでも日本では個別システムの比率が大きいといわれています。

最近は、クラウドコンピューティングが注目されています。これは、ユーザが必要とするサービスをオンラインで利用する形態で、「所有から利用へ」の転換です。このような利用形態が進むことにより、個別システム受注から共通部品としてのサービスの開発へと移行しやすくなります。

提案力の向上

情報サービス業が業績をあげるには、ユーザ企業からの受注を得ることが必要です。ユーザ企業があるベンダを選択するときに、ベンダの提案力を重視しています。（図表）

• システム開発の提案内容が優れていること、それに要する価格が重視されるのは当然です。
• 優れた提案をするため、開発においてユーザとベンダの間でのコミュニケーションを円滑にするためには、ベンダがユーザの業種・業態の知識が高く、他社で類似のシステムを構築した経験があることが重視されます。
• ユーザ企業、既存システムなどについてよく知っていること、すなわち、これまでに「つきあい」が多いことも重視されます。そのため、受注した案件でユーザを満足させて、リピート客になってもらうことが重要です。
• 受注した業務をユーザの期待以上に実現できる能力が期待されます。

　それなのに、多くのユーザは、ベンダに「提案をしてくれない」ことに不満をもっています。開発するシステムに関して、ユーザが期待することを単に実現するだけでなく、ユーザの真のニーズを理解して、期待以上の提案をすることが必要です。
　受注した案件だけでなく、日常的にユーザと接触して、ＩＴ化について相談を受けたり提案をすることをユーザは望んでいます。ユーザはベンダがＩＴの関する情報源、コンサルタントになってほしいと思っているのです（図表）。

コア・コンピタンスの確立

これらの対策を、中小の情報サービス業が大企業と同様に行うのは無理があります。しかし、ユーザ企業の業種・業態は多様ですし、そのニーズも多様です。また、技術面でもネットワークやデータベースなど多様な技術が必要になっています。中小の情報サービス業が特定の分野に特化すれば、大企業と同等、それ以上の能力をもつことは可能です。
　コアコンピタンスを強化することにより、付加価値の高い案件を直接受注する機会が得られますし、システムインテグレータとの関係を下請から対等なパートナーとしての関係になり、契約条件を有利にすることができます。

人材の育成

中小企業が下請けから脱却するには、高度に専門的な分野に特化して、元請けと対等な立場になることが求められます。そのためには優秀な人材を確保し育成する必要があります。情報サービス業界では、他産業にまして、人材の確保・育成を経営の最重点政策として認識し努力しています。 （図表）。

　ところが、情報サービス業は上述のユーザの期待に応じるためのコンサルタントやＩＴアーキテクト、システム全体を計画通りに実現するためのプロジェクトマネジメントなどの職種が不足しています。
　このような職種の人材は、新卒採用に期待できません。それで中途採用や社内での育成が重要になります。新卒の人には早期にソフトウェアデベロップメントやアプリケーションスペシャリストとして一人前になること、その業務を行っている間に、上記の職種へ移行できる知識・スキルを習得してほしいと期待しているのです。 （図表）