まだ目途が立たず。壊れた実家のシャワー水栓の部品が届かないらしい。こんなに掛かるなら、こっちで通販で買って送ればよかった。いくらなんでも時間掛かり過ぎだろ。普段通りの生活したい。朝早起きできないし、散歩にも行けない。我慢の限界を超えてる(挨拶)。
さて、題名の件。「何か問題でも？」とおぎやはぎの挨拶が思い浮かんだ。
地方からITエンジニアがいなくなる｜ＤＯＬ特別レポート｜ダイヤモンド・オンライン
一応、起業中ながら業界の人間なので、この件をどう考えているのか書いておく。今回は第一回、続き物になったのでリンクを貼っておく。
まず日本のIT業界の構造。日本の企業がITを導入するときにどういうモノの買い方をするのかに最適化されている。
まず大企業だが、パッケージよりもスクラッチ開発を好む。理由は「ウチの社内業務のやり方に合うパッケージが無い」。昔に比べればERPの適用などでパッケージを選択する企業の比率は大きくなっているが。そうなるとシステムインテグレータ(SIer)の出番。ERPを適用するにしてもカスタマイズしたがるし。理由は「パッケージをウチの社内業務のやり方に合わせたい」。またパッケージを使ってもスクラッチ部分との接続もある。SIerとしても金になるいい客である。
本当のことを言えば、パッケージが適用できなかったり、大カスタマイズが必要なほど、特殊な社内業務などほとんど無い。言い切る。無いよ。答えは業法や業界慣習にある。一般法規を守る、業法を守る、というのはリーガルリスクを低減するために必須。業界慣習に従うのは、それがその業界内でより低コストで業務を実施できる道だから。そうなってくると、同業他社がやらない業務や売らない商品を扱うなど、独自の部分だけが特殊であると言える。それでも、他業界を見れば同じようなことをやっていたりするので、本当に世の中に同じことをやる会社が極少なくて、世の中にパッケージが存在しない場合だけ、パッケージが適用できなかったり、大カスタマイズが必要。
話を戻す。大企業はそういうIT投資をするのだが、その大企業の情報システム部門の所在地はどこなのか。多くの場合は大都市圏。ありていに言えば、首都圏に集中している。それがSIerが要員を首都圏に集中させる理由である。
では中小企業～零細企業はどうか。基本的にパッケージを使う。スクラッチ開発への投資は企業体力から言って難しい。本当は中小企業こそ、大企業がやらないような独自業務をやっていたりするので、少しスクラッチ開発やパッケージのカスタマイズをしたほうが、さらにその独自部分の競争力を増すのだが。そういうアプリは一発作ればいいというものではなく、業務(内容の進化)に合わせてエンハンスしていくべきなので、メンテナンスコストが負担できない中小企業には投資判断が難しい。オレがこんな事書く何年も前に、一度や二度スクラッチで開発をして、時間経過とともに陳腐化しているだろう。本業なら陳腐化したものを見て、再投資・追加投資する判断もできるだろうが、モノが分かりにくいITでは単に失敗と捉えて再投資・追加投資しない判断をするのは容易に想像がつく。
結局、日本全国津々浦々に存在する中小企業は、SIerが食いつくようなITエンジニアを大量に動員するIT投資はしない。SIerにとっては、金が動かない地方にITエンジニアを置いておく理由が薄い。
と、どこにSIerのITエンジニアを置くかという観点で話を展開してきたが、別の観点の話を２つする。SIerとは関係ない話もあるがそれは別途。
一つ目。現在多くのSIerはオフショア開発拠点を持っている。初期の中国に始まって、今はどんどんアジアを南下している。アジア地区の広範に渡るはず。言語(自然語のほうね)や文化の違いがあるので、海外のアプリ開発会社に仕事を振ると一定以上の品質で仕上げてくるなんてことはなく、金と時間を掛けて意思の疎通を深化させるので「オフショア開発拠点を持っている」という表現になる。
本来であれば、日本語が通じる国内の地方開発会社に仕事を振るべきかもしれない。でも、今のところプラザ合意以降随分と円高が進んだので、国内の地方開発会社の目は薄い。今の104円台程度では円安と言えるところまで戻ってないし。
もう一つは、SI案件の多重下請け構造。発注側の問題もあるのだが、中小の開発会社が自立しにくい。大きな問題が2つあるのだが、まず大規模な開発プロジェクトを発注する企業があるとして、プロジェクトマネジメントを完全に発注側に置く企業がどれだけあるか？日本の企業の場合、どう考えてもほとんど想像つかない。IT投資が多い各業界トップクラスの数社の中で、情報システム部門をSIerに売り払っていないところといった所だろう。そうなるとプロジェクトマネジメントのメインはSIer側になる。それでは、どうしても中小の開発会社が直請する構造にならない。発注側は開発能力が高い中小の開発会社をプロジェクトの中核に据えたいと思っても、SIerにプロジェクトマネジメントを発注するのであれば、SIerがプロジェクトマネジメントの一環として使いやすい開発会社を選択することになる。
中小の開発会社が直請しにくい理由はもう一つある。発注側の開発費用の払い方である。現在は工事進行基準での払いもあるが、それにしても期毎の支払という事が多い。最短サイクルでもクオーター(3か月)だろう。単に人月仕事なら毎月払うこともできるだろうが、プロジェクトマネジメント上は成果物に対しての支払いをしたい。そうなると、検収コストを考えれば短くして6か月サイクルがギリ、3か月サイクルは分割損が大きくて厳しい。これは資金力のない中小の開発会社には厳しい。社員が給料を6か月ごとでいいですよ って言ってくれればいいのだが。毎月給料を支払いながら6ヶ月ごとの入金(ただし検収でケチが付かなければ)という状況は、想像すると胃が痛い。検収で何かあれば減額や入金時期のずれがありうる。そうなると、そういうファイナンスができるSIerが直請してくれて、検収のリスクも負ってくれて、毎月派遣した人数分支払ってもらうビジネスモデルを採る中小の開発会社が多くなるのは仕方ない。SIerとすれば、自前でプログラマを抱えておくリスクがヘッジできるので、Win-Win。大量にプログラマを抱え込んでも、全員を食わせるだけのプロジェクトを受注できない可能性はあるわけで、自社の社員じゃなければ発注しなければいいだけ。レイオフを考える必要が無い。そういうことで、SIerからすれば子会社孫会社系列会社を中心に廻していくので、地方の独立系開発会社というのはなかなか難しい。そういうことを言う事情は無いわけではないが「プロジェクトルームに頭数揃えろ」という発注元もいるので、本拠地が遠いのは不利。オフショア開発とは相反するが。
じゃ、海外はどうなのってことになるのだが、基本的にインハウス開発。パッケージ適用もスクラッチ開発も。ITエンジニアの雇用流動性も高いのであまり問題にならない。プロジェクトが終わって通常運用のサイクルに入ったら、要員規模を縮小していけばいい。プロジェクト要員のほうも、次もすぐに同じようなプロジェクトが見つかる。
そういう意味でSIerのような形態は日本発祥で、欧米系の文化圏だとほとんど聞かない。
----
そういうわけで、長くなったので一旦おしまい。
