いろいろやってみるにっき

てきとーに生きている奴の日記

古いエントリのサムネイル画像がリンク切れになってたりするけど、チマチマ修正中


地方にITエンジニアは必要か?(その4)

いい天気ですね。引きこもってますけど(挨拶)。

 

バックナンバーはこちら。

地方にITエンジニアは必要か?(長くなったのでその1)

地方にITエンジニアは必要か?(その2)

地方にITエンジニアは必要か?(その3)

 

元記事をもう一度読んでみた。

地方からITエンジニアがいなくなる|DOL特別レポート|ダイヤモンド・オンライン

 

こういう論旨でいいだろうか?

  1. SIerはどんどん集約されている
  2. そのせいで要員の首都圏集約が進んでいる
  3. SIerは集約が進み大企業化した結果、地方企業の案件は金額規模が小さすぎる
  4. そのせいで地方企業のIT投資が遅れたり、完結しなかったりする

題名とは直接関係ない著名な地方在住エンジニアの話や、ブラック企業の話も入っているが、水増しっぽい話なので措いておく。この話の対象は、元記事と同じく地方の中小企業ということにする。大企業は地方にITエンジニアは必要か?(その3) に書いたようにSIerがなんとかしてくれる。

 

まず企業がIT投資をする場合、SIerに依頼するような内容になるのは、どういうケースか。

  1. オンプレミスインフラの更新
  2. ERPパッケージやCRMパッケージなど、カスタマイズ前提パッケージの適用
  3. 上記カスタマイズ開発・アドオン開発
  4. 自社用アプリケーション開発
  5. 配布用・販売用アプリケーションの開発代行

元記事にあるように今時仮想化に着手とかだと、相当遅れているのかも。そういうことであれば、地方にITエンジニアがいないという点は同意せざるを得ない。まず仮想化だが、なんでSE(システムエンジニア)がいないという理由で進捗しないような案件になっているのか?

 

オレが仮想化をビジネスにし始めた2005年くらいは、情報も無かったし、最新機能を使おうと思うと英語版を選択する必要もあったし、周辺のツールや監視ソフトなども海外ベンダのものを探してくる必要があった。そういうプロジェクトであれば、SEが掛かりきって設計したり構築したりなので「要員ガー」という話になる。ところが、現在は仮想化は特別なものではない。ハイパーバイザーをプレインストールした物理サーバも売られているし、仮想アプライアンスのラインナップも拡充しているので、工程は短くて済む。オンプレミス必須でなければIaaSやVPSでもいい。

つまり、プロジェクト開始時点でのmake-or-buy分析(内製対外部調達の得失分析)に問題がある。発注側にmake-or-buy分析をする能力が無い+受注側もmake-or-buy分析する能力が無いという組み合わせか、発注側にmake-or-buy分析をする能力が無い+受注側はどうすれば安く上がるかを分かっていながら受注額が増えるmakeを選んだという組み合わせのいずれかだろう。工数を掛ければ掛かった人月分の費用も、余分に乗っているということになる。

 

2008年4月1日にリース会計は変わり、所有権移転外ファイナンスリース(早口言葉なので声に出して3回言ってみましょう)はオンバランスということになった。きちんと説明すると、それまで物を買っても所有権移転外ファイナンスリース(リース物件はリース会社のものとするリース契約)にすれば、B/Sに載せなくてよかった(=オフバランス)。借りている扱い。ところが所有権移転外ファイナンスリースもオンバランスになったので、B/Sに載せる必要ができた。中小企業の経営者は所有権移転外ファイナンスリースがそれまでオフバランスだったので、オンプレミスのIT投資をしても賃貸借処理だと思い込んでいる場合もある。さらには減価償却会計の制度も変わっていたりする。バランスシートに載せる以上、減価償却もきちんと考慮要。

そういう企業から案件を請ける場合、凍死する企業投資する企業には、会計制度の正しい知識を持ってもらった上で(税理士や会計士に聞けって言えばいい)、購入したうえでオンプレミスなのかレンタルサーバでオンプレミスなのかIaaSやVPSを使うのかというmake-or-buy分析に進むべきであって、目先の受注額が大きい方法を選ばせてはいけない。そんな焼き畑農業(じゃなくてIT)をするIT企業がいるから、日本の中小企業のIT投資は過小なままとなる。

話は戻るが、知ってて焼き畑ITをするようなIT企業はいないんだという性善説に立てば、地方の中小企業から案件を請けているIT企業は力不足なんだということになる。うん、確かに人がいないと言える。

 

 

次にパッケージ適用とカスタマイズ開発・アドオン開発だが、これは要員をその発注企業に張り付けないと開発できないわけではない。従事する要員のほとんどは、日本中どこにいてもいい。オンプレミスのサーバで動かすのであれば、サーバの設定などは現地。仕様の調整も現地。テストや検収や研修も現地。ただそれ以外の工程は別に現地じゃなくていい。要員の張り付け方は、いわゆるスマイルカーブを描くことになる。プロジェクトの開始時点と終了時点は現地の作業は多いが、中工程は現地である必要はない。アジャイル開発ということでも、コミュニケーション手段はWebカンファレンス(Web会議)でできる。

 

自社用アプリケーション開発と、配布用・販売用アプリケーションの開発代行は一応作るものの扱いが異なるので別分類とした。発注企業の自社(あるいはサプライチェーンの関係先)で使用されるアプリケーションを自社アプリケーションとした。一方、配布用・販売用アプリケーションは、PC及びスマホタブレット向けのアプリケーションで発注企業の顧客に使ってもらう物という位置付け。いずれもアプリケーション開発という意味では大差ないんだが。

さて、なぜアプリケーションを作るのか。そのアプリケーションによって差別化を図り、競争優位を確立するためである。そういう意味ではインハウスで開発したほうが合理的である。しかし中小企業の場合、定常的に存在しない本業外の要員を抱えるのは資金力的にも難しかったりするし、マネジメント的にも難しかったりする。

そういう中小企業に代わってアプリケーション開発を行うIT企業は、上のパッケージ系の話と同じで、別に全工程で全要員を現地に張り付けておく必要はない。

ただ問題は、パッケージ適用とそのカスタマイズ開発・アドオン開発よりも少し面倒。パッケージ適用とカスタマイズ開発・アドオン開発というのは、特定のパッケージを適用するという制約があるため、当該パッケージの扱いが得意な企業の中から選定して発注することになる。一方、単にスクラッチでアプリケーション開発となると、制約が減るため発注先の選定が難しい。

METIITコーディネータ(ITC)みたいなクソの役にも立たない制度・資格を作るのではなく、こういう発注側と受託開発会社ミスマッチを少なくするため、マッチングを制度化するべき。あ、クソっていうのは汚い表現なので訂正しておく。うんこうんこーw。ITC持っている人、ごめんなさい。

ということで、ミスマッチ状態だと思うが、これは地方にITエンジニアがいれば済むというものではない。これについては、オンプレミスのインフラの話のように正しい情報があれば改善するわけではなく、よりよいマッチングが改善の道。

 

 

上記のどのようなシステム開発にも言えることだが、地方の中小企業のIT予算観には改善の余地があると考えている。「SIerは集約が進み大企業化した結果、地方企業の案件は金額規模が小さすぎる」という課題提起だが、SIer側の問題もあるのだが、発注側の問題もある。

発注側の問題であるが、中小企業の経営者はIT投資に対して、一律どのような投資も「コスト」として捉えているのではないか?というもの。それは違う。例えば会計(ERPでもいい)システムのように他社並を実現するものはコストとという捉え方が正解。コストなのでTCO極小化を図るのは正しい。一方、他社との差別化に掛けるIT投資は、ROIで見るべき。TCO極小化という見方で投資を絞ってしまうと、所定の投資効果を得ることができず単なる無駄になる。それなら差別化を諦め、そのIT投資もやめたほうがいい。

 

SIer側だが、「SIerは集約が進み大企業化した結果、地方企業の案件は金額規模が小さすぎる」というセンテンスの中に一つの矛盾と一つの改善可能な要素がある。まず矛盾についてだが、集約したときに何を目的に集約したのかということ。集約の目的の一つは、分割損を無くしシェアドサービス化などで低コスト化を図るというものであるはず。総社員数は大きく変化が無くても、間接部門を集約するなどで低コスト化を図れる。大企業化するとコストが増えるんじゃ、集約の意味が無い。元記事では多分気付かずに書いたと思うが、おかしな話。

もう一点は「地方企業の案件は金額規模が小さすぎる」だが、これは改善可能な要素。部門予実算評価と仕事の請け方。受注金額で見れば小さいことは否めないだろう。大企業みたいには大枚をはたいてくれない。しかし、仕事の請け方を変えてしまえば、高粗利を実現可能。中小企業相手にビジネスをする部門や子会社の評価は、受注規模ではなく総粗利でみるような部門予実算評価が必要。仕事の請け方は、共通化の推進。例えば上に書いた仮想化案件なら、個別設計の構築作業を請けるのではなくプレインストールモデルやIaaSの活用とか。アプリ開発もWhatは発注企業毎の個別だが、Howは極力共通化(アプリケーションフレームワークとかIDEとか色々工夫できる)。

 

ということで、「地方にITエンジニアがいなくなる」という課題提起に対しては、現状は改善の余地が多々あるが、解決方法は地方にITエンジニアを置くことではないよという話。なお、おまけがあるが、ここまで長くなったので、別途。

地方にITエンジニアは必要か?(長くなったのでその1)

地方にITエンジニアは必要か?(その2)

地方にITエンジニアは必要か?(その3)

のぼり旗 地方発送致します

お時間あったら、他のエントリもクリックして頂ければ幸いです。