国内IT市場の不連続性と、SIの終焉の予感
前回は国内のITビジネスに長く携わる中で、最近になって初めて感じた市場の変化について、クラウドを中心に置いて考えてみた。すなわち以下の3点である。
- 顧客は、以前は複数年にまたがる投資を先払い的に実施していたが、最近はクラウドを利用して、初年度投資額を抑えたいと考えるようになった
- 顧客は、以前は自社向けのシステム開発を多数行っていたが、最近はクラウド採用かつ、自社向けカスタマイズは避けたいと考えるようになった
- 顧客は、以前はオンプレミス以外考えられなかったが、最近は基本的にクラウドを検討し、選択肢があるならばSaaSをより望むようになった
論として広げる前に気を付けなければならないのは、クラウド中心に捉えようとも、クラウドが市場へ影響して変化をもたらしたのではなく、市場の変化が結果としてクラウドを歓迎したという事だ。新しいIT議論の常々の課題として、自らベンダーの立場を有利に導くために論旨をひっくり返して極論に徹してしまう事がある。私もサイオステクノロジー株式会社にてGoogle Appsのライセンスビジネスに従事しているので、本当は「Google Appsがその破壊的ソリューションによって全世界のITシーンを一変した!」と言いたいところだが、そう言ってしまっては論旨がすぐ破たんする。
市場を変えた一因としてGoogle Appsを始めとする具体的なクラウドサービスの登場が寄与している事もあるとは思うが、因果関係は専ら逆だ。前回の最後に触れたように、2つの歴史的事件、リーマンショックと、東日本大震災が変化の原因であるという方がまだわかりやすい。Google Apps的な立場で言い直すと「企業は、長引く不況でIT投資を抑えていたが、震災経験からBCPを重要テーマと捉えたため、市場の変化がクラウドを歓迎し、結果Google Appsは爆発的に普及した」とでもなるだろうか。
IT投資サイクル間隔の適切な長さ
奈良や京都をはじめ、日本の各地には数百年前からあるような神社仏閣がゴロゴロ存在する。数百年前の日本の建造物だからもちろん木造だ。材木は雨風によって痛むために何もしなければやがて朽ちて倒れてしまう。そのためにおよそ30年に一度というようなペースで大規模な修理を行い、場合によっては部分をそのまま建てなおしてしまうような事を繰り返し行っているのだ。ペースが30年に一度というのには大きな意味がある。木造建築は、数百年は持たずとも50年から、うまくすると100年以上は長持ちする。しかし、じゃあ経済的に100年に一度の建てなおしにしましょうという事になると現実的ではない。建物は持っても、建てなおす宮大工の寿命が持たないのだ。仮に100年に一度のペースで寺社を建てなおすとすると、関係者は確実に全員、前回の構築経験が無い。祖父が辛うじて関わったが自分にはこれまで同等の機会が無かったという孫やひ孫の世代にて、誰も実践的な経験の無い環境での重要建築物の再建とは心細い。監督する寺社側も含め、人間の世代交代はおよそ30年。一生涯に一度でなく2~3度の参画を行うには、長くともこのワンジェネレーションの間になんとかしないといけないのである。
実は企業ITの世界でもまったく同じ事が言える。継続的なビジネスを行っている企業において、ITへの投資は断続して行っていかなければならない。特に重要なシステムについてはシステムを構成するハードウェアもしくはソフトウェアの耐用年数によって寿命を決めるのではなく、システム再構築を行う体制が維持できる時限内に計画遂行しなければならない。そして、どうもそれは3年もしくは長くても4年なんじゃないかと私は思っている。一般的にシステムインテグレーターと呼ばれるようなITにおける構築力を提供する企業において、IT技術者が現場の第一線で活躍し続けられる年数はどのくらいだろうか?また、施策側の企業においてもシステム開発を監督すべき担当者は同じシステムに何年関わり続けるのか?どちらもそれぞれは一般論で断じ難く、所属企業や当人の適性次第としか言い様が無いが、多数者が関わる企業のITシステムにおいて最小限の人数だけでも、キーマンが揃い続けられる年数は3年でも難しいかもしれない。
ここらへん論旨が乱暴だが、毎度のシステムリプレースメント案件における課題はキーマンをそろえられない事に起因する事が多い。企業の資金的もしくは会計的な期間ももっと長く、買い求めるハードウェアの耐用年数も最近であれば10年ぐらいは壊れない。そのため普通は少なくとも5年、長いと10年近くも既存のシステムに継ぎはぎ保守を行って運用している。そしてそうであるからこそ、いざ再構築を行わなければならない時、「仕様がわかる人もいませんし、ソースコードも最新のものかはわかりません」と言う。前回構築時の成功も失敗も知識を失い、すべてまっさらにゼロからスタートしていてはリスクが高く、効率は低い。結果これまで多数の「動かないコンピューター」を産み出してきている原因となってしまっているのではないか。
図1:イントラ業務システムの開発プラットフォーム(クリックで拡大) |
連載バックナンバー
Think ITメルマガ会員登録受付中
全文検索エンジンによるおすすめ記事
- Google Appsの普及に見る、企業ITインテグレーションの変化
- これまで企業向けSIに関わってきたエンジニアのためのサバイバルガイド
- IT災害復旧計画を策定してみる
- BCP(事業継続計画)におけるIT
- 震災で改めて考えるIT-BCP
- AIリスク管理プラットフォーム「Robust Intelligence platform」を提供する米Robust Intelligence Inc.共同創業者 大柴 行人氏インタビュー【後編】
- BCPを理解して災害復旧計画に取り組む
- グルージェント、米国CloudLockの日本語版を販売開始
- 「これからの自分のキャリアと人生、どうしていく?」WITI Leaders Panel vol.5 レポート
- セキュリティリスクの深刻さを理解しない三菱へ願うこと