日本におけるシステム導入の問題点

<スポンサーリンク>


池田信夫blogの人材鎖国という記事のコメント欄で、興味深い議論が続いている。就職氷河期っ子さんの周辺では、IT業界の大手ベンダーによる99.9%の搾取がまかり通っており、孫受けやひ孫受けなどの会社のエンジニアは技術を高めるほどに収入が低くなるという、悲惨な状況が起こっているそうだ。しかし私は、TOMさんの意見の方が理解できます。

TOMさんが既に似たようなコメントされているようですが、業務系システムにおける真の技術力とは何なのでしょうか?私の長い経験から得た答えは、「お客が必要としている機能を十分に深く、広く、精度良く理解して、技術者に理解できるように仕様書類に表し、必要とされる実装技術を決め、精度良く開発納期を算出するか」という事だと思います。場合によっては「現在のお客の業務ワークフローについて、システム化した場合の非効率性を指摘して、全体最適化を前提としたリエンジニアリングを提案し、説得力ある言葉でお客に受け入れさせる」事も必要です。それが100%出来れば、開発中に仕様が増えたり変わったり、デスマーチが起きたりする事は有り得ません。

もちろん、そのような技術者はお客の業界の業務知識をお客以上に豊富に持ち、お客がやりたい事(やるべき事)を把握しなければならないでしょう。お客はしばしば、やりたいと言っている事と、実際にやるべき事が違う場合があり、その差を自ら認識して、自分の業界知識で補正して正す事が必要です。それだけの高い業務系システム設計の技術力があれば、安い給料に甘んじる必要は微塵もなく、どこへでも転職できるし、独立すれば良い仕事を選んで受ける事も可能でしょう。銀河氷河期っ子さんの言われる技術力は、そういう意味で言われているのでしょうか?それともプログラマとしての実装技術の事を言っておられるのでしょうか?

まあ、このような事を100%やる事は神業といえるでしょうし、そのようなSEを私は見た事がありませんが、優秀な業務系SEはこれらの事を自分なりに努力して実現して、ある程度実現しているのだと思います。ところで日本の業務系システム業界では、なぜこのような困難な作業を要求されるのでしょうか?それはこのブログ記事の表題とも関連していると思いますが、日本の会社(特に事務系組織)は、一つ一つの会社が独自に構築した、特殊化された業務ワークフローを持っていて、これがサラリーマンの転職の壁を厚くし、雇用の流動性を阻む要因のひとつとなっています。逆にIT業界のプログラマは開発言語やプラットフォームの知識や経験は他社が容易に価値評価可能なので、昔から雇用の流動性が高かったですね。この、一社一社の業務ワークフローが特殊化されている事が、大規模な業務系パッケージソフトの発展を阻み、毎度毎度、膨大な費用と時間とエネルギーを注ぎこんでカスタム開発で作り込む必要を生み出しています。

もう1つ、日本で大規模なパッケージソフトが(今ではSAPやORACLEなどもだんだん普及しているようですが)を普及させる事ができなかった理由は、日本のソフト会社が、実装技術ではそれなりに技術と能力を伸ばしても、システム導入に適合した合理的な業務ワークフローのリエンジニアリングを苦手としてきたのではないか、という事です。そもそも業務システムには合理的な業務ワークフローが求められますが、日本の企業は人員削減と称して、作業の内容と担当部署がきちんと分離されておらず、同じ人間(部門)が複数の業務処理に顔を出し、書類やデータが行ったり来たりを繰り返し、入力作業が特定の部署に集中するという傾向もあります。このようにシステム化の観点からは非合理的な業務プロセスに手をつけぬままにシステム導入を行うので、通常のパッケージソフトをカスタマイズ無しで導入する事はまず不可能です。それどころか、お客の「人間に最適化された業務ワークフロー」をシステム化する為には、非常に高度な実装技術を必要とします。この問題が、日本のソフト業界でデスマーチを生む1つの要因になっていると思われます。

では、なぜ日本のITベンダーは特殊化した業務ワークフローを、全体最適化を前提としたシステム化に適合させる為のリエンジニアリング苦手なのか。それは、このコメント欄でも指摘されている、お客の企業内に優秀なIT担当者が不足しており、またIT担当者の社内での地位が十分に高くないという事が上げられると思います。お客の現場では、慣れている業務ワークフローを捨てて新しくする事は、ほとんどの場合は反対されます。反対の理由は幾らでも作り出せますし、上司は担当者の反対理由を反駁する事ができないし、自分で責任を負う度胸も無い。IT業者はしょせんは部外者ですから現場の上司に出来ない事を実施するのは難しい。しかし、私は良い例も見てきました。お客の社内に、ある程度はシステム技術を評価できるリーズナブルなIT担当者がおり、システム導入のリスクを最小限にしようとしており、IT担当者が社内の部課長クラスへ「業務フローの変更」を命令(またはそれと同じ効果を持つ提案)する事ができるような社内的に権威ある組織(監査部門や財務部門など)に属している場合です。このようなIT担当者と組んでシステム設計を行う場合、システム化に不都合な業務処理の変更は比較的容易であり、パッケージソフト(当該業界に適している事が前提だが)のカスタマイズは最小限となって、費用的にもシステム導入の労力も最小限で済む場合があります。

これと良く似た例はSAPなど外国製の大規模パッケージソフトの導入に見られます。昔は、SAPといえば導入費用だけでウン億かかり、しかも失敗する会社が多いという話がありました。それからかなり経って、今のSAPはある程度は日本の文化を吸収して導入しやすくなったようですが、SAPの導入例が増えているもう1つの理由は、過去の「日系コンピュータ等で繰り返し述べられてきた」失敗を繰り返さない為に、経営トップがSAP自らが、業務ワークフローをパッケージソフトへ合わせる努力を行っているという事がいえます。グローバル化した企業が全世界の(連結対象となる)関連会社でSAP(などの世界的なパッケージソフト)を導入する事は合理的な選択といえますが、一方でそれに失敗するという事は、経営者として大きなマイナス評価となるので、これまでの業務プロセスを捨ててでも導入を成功させようというインセンティブが働くのでしょう。

最後に、もとの話題に戻って、就職氷河期っ子さんの言われる「ITゼネコンとの悲惨な関係」の理由は、就職氷河期っ子さんの経営者としての能力の問題と言えるかもしれません。IT業界に限らずどのような企業であれ、自分で独立したからには、十分な営業力と経営戦略が必要です。以前にも別の記事のコメント欄で述べましたが、経営戦略(といえるかどうかわかりませんが)いかに沢山のエンドユーザー顧客を開拓するかという事が大事であると思います。毎月の経費をカバーするだけの収入をエンドユーザーからの仕事で得られれば、大手からの下請け仕事は、質の良いものだけを選ぶ事ができるようになります。それだけの「営業力」がなく、ただ言われたシステムを開発する能力しかないのであれば、その辺にいくらでもある孫受け、ひ孫受け会社の列に入る事はやむを得ないのかもしれません。