総合スクラッチ開発偏重が引き起こす人材不足
IT業界は大規模開発案件が集中したことで、「2015年問題」と言われる人材不足が深刻化してきている。しかし、これはIT需要に対して十分な供給体制が取れていないというIT企業側だけの問題なのだろうか？ 需要側であるユーザー企業には問題はないのだろうか？ IT人材不足を引き起している原因をユーザー企業、IT企業の両面から分析し、解決の方向性を探る。
2015年問題とは
2015年問題とは、アベノミクスによる景気回復に伴う情報システムへの投資拡大や、大規模プロジェクトの開発ピークの重なりによって、IT企業が2015年を中心にIT人材不足に悩まされている状況のことを指す。
2015年をピークとする大規模プロジェクトとしては、みずほ銀行の新勘定システム構築（開発規模3000億円、ピーク時開発要員数8000人）、マイナンバー制度システム構築（同3000億円）、日本郵政グループのシステム刷新（同4900億円、ピーク時開発要員数1万人）、東京電力の持ち株会社制移行に伴うシステム改修（同600億円）などがある。また、2020年開催が決まった東京オリンピックも新たなIT開発需要を生む可能性が高く、2015年以降もIT人材不足に悩まされる可能性は高い（図表1参照）。
（図表1）大型プロジェクトの開発予定と規模この際、十分なIT人材がIT企業側で用意できなければ、システム構築が遅れ、ユーザー企業の事業活動に大きな影響を及ぼす。2015年問題はIT企業側だけの問題ではなく、ユーザー企業にとっても大きな問題なのだ。
では、2015年問題は今回だけな一過性な問題なのだろうか？
IT企業におけるIT人材の量に対する過不足感を見る（図表2参照）と、過去5年間、常に50％近い企業が不足していると感じており、年々その割合は拡大する傾向にある。2013年度は19％の企業が大幅に不足、63.2％の企業がやや不足していると回答しており、79.2％の企業がIT人材不足の状態にある。
2015年問題が表面化してくる2014年以降は、さらに深刻な状態になることが予想される。これらから、IT人材不足は2015年前後だけに起きる一過性の問題ではなく、現在の日本のIT企業が抱える根本的な問題であると言える。
では、なぜ、日本のIT人材は不足するのか？
IT企業側で「需要に見合った人材採用・育成ができていない」という点が、表面的な原因だ。しかし、根本的な原因はユーザー企業側にある。そのひとつがスクラッチ開発偏重の姿勢だ。
業務パッケージや開発ツールを導入すれば開発作業自体が削減され、開発作業に従事するIT人材を削減することができる。しかし、日本のユーザー企業は業務パッケージや開発ツールの導入に対して消極的であり、ゼロから作り上げるスクラッチ開発を好む傾向が強い。そのため、開発作業を削減することができず、多くのIT人材をIT企業に求めることになりIT人材不足を発生させている。
なぜ、業務パッケージや開発ツール導入が日本のユーザー企業では進まないのだろうか？ その原因を探ってみる。
進まない業務パッケージ導入
日本においても、“業務パッケージ導入を積極的に進めよう”という時期があった。
1990年代後半から2000年前半のERPブームである。会計・販売・購買・在庫・生産管理などの基幹系業務をパッケージで提供し、業務間連携やリアルタイム更新を実現するERPパッケージの登場と2000年問題が同時期に起きたことにより、業務パッケージ導入が一気に進むかに思われた。
しかし、結果は「金食い虫のERPが課題」（オリンパス代表取締役社長執行役員 笹宏行氏、「トップインタビュー」日経コンピュータ2013年12月26日号、PP38-41）と言われる状態にある。
ERPパッケージ導入失敗の原因は大きく2つある。1つ目はERP適用業務範囲に起因する問題（図表3参照）と、ERPで実現する業務内容に起因する問題（図表4参照）である。
（図表3）ERP適用業務範囲に起因する問題
（図表4）ERPで実現する業務処理内容に起因する問題前者は、どの業務までERPパッケージを適用するかの問題である。多くの企業で見られたのは、パッケージ導入がしやすい会計業務だけにERPパッケージを導入し、他の業務は現行システムのままという個別業務にERP導入するパターンだ。
この導入方法は、ERPパッケージと現行システムとのインターフェイスの多さによる開発・保守運用コストの増加、複数マスター連動による複雑な障害対応という問題を引き起こす。SOA（Service Oriented Architecture）を採用したERPや、MDM（Master Data Management）ソフトウェアなどにより解消が図られつつあるが、いまだに現存する問題である。
後者は、自社の業務のやり方に、ERPパッケージをどこまで合わせるかの問題である。自社の現行の業務手順や理想の業務手順をERPパッケージで実現しようとすると、膨大なアドオン開発が必要となり、自社開発と変わらない開発・保守運用コストが掛かることになる。また、ERPのバージョンアップ時に、アドオン部分のテスト・改修が必要になるため、さらにコストが増加してしまう。まさに、「金食い虫のERP」状態になってしまう。また、最悪の場合アドオン部分の問題でバージョンアップ自体ができない可能性もある。
業務パッケージは、パッケージが提供する業務プロセスを、そのまま導入しなければ開発が必要となり、一時的な開発コストだけではなく、保守運用コストも増加させてしまうのだ。基幹系業務は企業競争力に関わる部分が少なく企業間の相違も少ないので、パッケージの提供する業務プロセスを導入しようというのが欧米企業の考え方であり、その考えの下、業務パッケージの導入が進んだ。
しかし、日本では自社流の業務プロセスや細部へのこだわりによってアドオン開発を多く行ってしまったため、パッケージ導入による経済的効果が得られないことが多く、結果として、業務パッケージ導入が進まない状況にある。
進まない開発ツールの活用
業務パッケージの提供する業務プロセスをそのまま導入することができないのであれば、スクラッチ開発するしかない。スクラッチ開発で開発作業・要員を削減する方法としては、プログラミングせずにシステムを開発できる“開発ツール”の活用がある。
最近、超高速開発に関する本が出版されたり、コミュニティが作られたりなど注目を集めつつある開発ツールだが、最近になって開発されたものではない。その歴史は古く、4GL（Fourth Generation Language）として1980年代から存在するものである。今頃になって話題になるということは普及していない証拠だろう。
また、開発ツールを使用することによってプロトタイピング・反復型開発やアジャイル型開発が行いやすくなるが、いまだに開発の主流はウォーターフォール型開発であること（図表5参照）からも、導入が進んでいないことが分かる。
開発ツール導入の障害になるのは、細部にこだわる姿勢である。細かなデザインや機能にこだわると、どうしても開発ツールでは実現できない部分が出てきてしまい、「使えない」と評価されてしまう。そのため、なかなか開発ツールの導入が進まない状況にある。
スクラッチ開発を減らすには
プログラミングによるスクラッチ開発偏重姿勢を正し、開発作業を削減すれば、日本のIT人材に対する需要を削減でき、人材不足を解消できる。そのためには、ユーザー企業は次の2点に取り組む必要がある。
（1）こだわりを捨てる
業務パッケージ導入の阻害要因の最も大きなものは、自社流の業務プロセスへの“こだわり”だ。「事業部門から『システムはこうしてもらわないと業務ができない』と声高に要求され、全社的な業務の整流化（標準化：筆者加筆）に取り組まずにバラバラにERP導入プロジェクトが進んでしまったのです」（笹氏、同上）ということのないように、自社流へのこだわりを捨てる必要がある。
また、開発ツール導入の阻害要因も、細部にこだわる姿勢にある。開発ツールで実現できない部分ばかりに注目して「使えない」と判定する悪癖を止め、「どう使うか？」を考える前向きな姿勢が開発ツール活用では求められる。
自社流や細部へのこだわりを捨てない限り、スクラッチ開発偏重姿勢は改善されない。しかし、細部へのこだわりは日本人の特性とも言え、高品質な製品・サービスを生み出した源でもある。これを捨てるのは非常に抵抗があると思われるが、ぜひ、取り組んでいただきたい。
（2）稼働までのスピードを重視する
自社流や細部へのこだわりを捨てることにより、得るものはスピードである。
事業環境の変化は激しい。
変化に対応して事業活動の根幹となる情報システムも変化しなければならない。情報システム対応の遅れにより事業環境の変化に対応できないと、企業競争力を損なう可能性が高い。競合よりも一日も早い稼働が企業競争力に直結する時代だ。こだわりを捨て、早期稼働を目指す姿勢がユーザー企業のIT部門には求められる。
そのためには、業務パッケージや開発ツールなどの活用だけではなく、クラウドサービスの活用や、核になる部分だけ稼働させ、稼働後に徐々に機能アップを図るリーンスタートアップやアジャイル開発なども有効な方法になる。
ユーザー企業のスクラッチ開発偏重姿勢を解消することにより、自社の企業競争力が増すとともに、IT企業のIT人材不足も解消することが可能になる。まさに、両者の利害が一致するのだ。