日本大手ゼネコン系ITベンダー凋落の歴史
大手ゼネコン系ITベンダーの力が弱まって久しい
ここ何年か、ユーザー企業のシステム担当からよく聞く話として、また大手ゼネコン系ITベンダー(以下ITベンダー)は退職して複数のユーザー企業にて逆に提案を受けて評価する立場となった実感として、ITベンダーの力量は低下する一方であり、回復傾向が見えないと感じている。
もちろん、例外はあって、顧客をリードできる強い人材やプロセスを持っているところはある。そういうところは総じて値段が高いが、プロジェクトの炎上を経験してきた企業であれば、リスク回避を優先して採用することが多いように思える。
しかし、多くのITベンダーは、こちらの本質的な要件を理解することができないし、また理解したとしても目的に直結する提案をすることができていない。
酷いところになると、実現性の無い構築計画を持ってくるところもある。先日などは、パッケージベースの提案を求めたところ、パッケージが日本の法制度に適合していないにも関わらず、ゼロカスタマイズを前提とした超短期の構築計画を出してきたところがあった。カスタマイズ量のコントロールはユーザー企業側に一義的な責任があっても、ITベンダーが要件定義をリードする力量が極めて重要であるにも関わらず、法制度対応すら考慮していないところを採用することは難しい。
- 要件理解力のところを補足すると、情報提供依頼(Request for Information: RfI)や提案依頼(Request for Proposal)を文章＋口頭で伝えても、帰ってくるのは抽象的な説明しかない機能群やアセットやソフトウェアの紹介であり、それらがユーザー側の希望を満たせるのか解釈に苦しむ場面が多い。そして、なんとか解釈しようと議論を重ねても、分かることは、的外れとまではいかないまでも焦点がぼやけていて相当の調整が必要が必要であることであり、結局ベンダー提案の評価結果に自信を持ちきれないことになることが多い。（もちろん支援者としてそこを突破するのだが大変な負担がかかる）
- なお、大手ゼネコン系ITベンダーとは、主に大手企業向けのパッケージ・アセット・ソフトウェアをもとにユーザー企業向けシステム開発を行う企業を指している。つまり、GAFA・スマゲーメーカーなどは該当しない。
なお、この文章はこれまでの仕事の中でふんわり集まった断片的な知識を元とした、ふんわりとしたものである。よく言えば仮説であり、根拠不十分な駄文であるかもしれない。ITの歴史に精通した先達の厳しい有益な批判を歓迎するし、それを得て私の知識がアップデートされることが、この文章を描いた目的の１つでもある。
なぜITベンダーの凋落が問題なのか
ITベンダーの弱さは、日本企業の競争力を大きく損ねている。
まず前提として、これを読むような人には釈迦に説法だろうが、現代の企業経営はITに強く依存している。多くの簡易な手作業をITで簡略化・自動化していかなければコスト競争で打ち勝てないし、ITは24時間・距離や場所を問わない・迅速かつ高度な顧客サービスを実現する力がある。ITを他国や他社よりも高めることは、競争優位に直結する。
そして、日本に拠点を置いて活動する企業は、日本の雇用制度を踏まえると、引き続きITベンダーの深い支援を切実に必要とせざるを得ない。システム開発は、段階によって必要とする人材数が大きく変動するものであり、簡単に採用・解雇ができない制度化においては一企業では対応しきれない。全部自社で行う「内製化」の潮流はあるが、当面主流になるのは難しそう。
- 開発段階を要件定義➔設計➔開発/テスト➔受入検査などと分けた時、開発/テストでは大人数が必要になるが、最初と最後ではそうでもない。加えて、全行程を行えるスーパーマンは極小なので、人数比だけでなくスキルも考えなといけない。このような激しい人数・スキル変動に対応するには、プロジェクト期間内だけ採用することが必要となるが現行制度では難しい。
（ちなみに米国では出来ている。その結果、米国ではIT技術者の75%がユーザー企業に所属するが、日本では25%にしか満たない。） - 加えて、これは後で書くがITベンダー潮流の原因は人材レベルの低下にあるので、募集しても「一緒に働きたい」と思える人はなかなか現れない。
- 「これからアジャイル開発が主流になるから気にしなくてもいいのでは？」という意見もあるが、当面は影響しないと思っている。この理由は長くなるので、いずれ別に書きたい。
ITベンダーが弱い原因はなにか、その歴史的経緯
ここからが一番書きたいところ。なぜ、こうITベンダーは頼れないのか？直接的な理由は以下２点に集約されるように思える。
- 技術や構築の勘所を理解していない
- 論理思考力が低い
この２つは結局のところ人材レベルの低下という意味で同じ。なぜこうなったかは事例列に見たほうが分かりやすいかもしれない。
1. 1980年代：自己流開発の時代
この時代、ユーザー企業もITベンダーも、特段の手法無く職人芸的に個人個人の方法でわいわいとシステム開発を行ってきた（と先達からはよく聞く）。余談だが、いまアジャイル開発を大企業でやろうとすると、この時代を知る部長・役員クラスの古株が「昔と似ている」と言いながら課長級の中堅よりも柔軟に受け入れることが多いのは、このことに起因するように思える。
使っている技術といえばメインフレームやオフコンのようなシステムのすべての要素が１つのベンダーのものであり、今と比べると単純だった。
2. 1990年代：オープン系とウォーターフォール開発の普及
（ここも伝聞や文献からの推測だが）このころからITの価値が高まり始め、開発スコープは膨れ上がり、複雑になっていった。最大級のプロジェクトといえば、銀行の第3次オンラインだろうか。
加えて、この頃からオープン系の登場によって、いろいろな技術が生まれてきた。Unix、RDBMS、JavaとかCとかの言語。
そうなると、もはや職人芸では対応できない。要件の複雑さ、定義してからテストまでの期間の長さは人間の記憶力を大きく越えていた。また、１人が多様な技術を使いこなすことも無理だった。そのため、ウォーターフォール開発モデルが広まっていった。要件や設計を文書の書ききることで目に見えるもの（形式知）にした。さらに、開発の流れを工程ごとに分断して完了基準を設けることで、長期間化・大規模化・分業化が可能になっていった。
3. 2000年代：ウォーターフォールの定着、不況、「薄皮饅頭」の発明
各ベンダーは開発手法とプロジェクトマネジメント力を高めていき、プロジェクトの成功率を高めていった。そして、その知識体系は「開発標準」や「開発管理標準」といった形で結晶化されていった。ユーザー企業も、ベンダーに習って標準を整備していった。
この時まで、ITベンダーは一定の尊敬をユーザーから得ていたように思える。給料も高かった。しかし、凋落の始まりはここから始まる。
まず、プロジェクトでやるべきことを標準に沿って切り分け、細分化し、若手に「簡易な作業」として渡していった。これを行うのは経験豊富はおじさん達で、若手の仕事は、標準の徹底的な理解と作業実施がメインとなった。結果、作業効率は飛躍的に向上したが、若手は教科書たる標準を墨守するばかりで０から考える経験を得られなくなり、柔軟な思考力を持てなくなっていった。（私のように）
さらに、この頃からIT業界は不況になっていき、後半にはかなり深刻になっていった。発注数は減り、大手ITベンダー各社は受注を競った。この厳しい環境で案件を勝ち取る手っ取り早い方法は何か。それは、価格を下げることである。そのため、サーバーやソフトウェアなどの大幅な値下きが認められるようになった。人によるサービスはどうするか。これを可能としたのが「薄皮饅頭モデル」だ。その構造は、表面的には大手ITベンダーがサービス提供を行うが（薄皮）、実作業はすべて下請けに丸投げする（餡）ことだ。
ユーザーは安く大手ITベンダーのサービスを購入できるので、薄皮饅頭モデルを使った提案は受けた。だから、みんなこの手法を使った。
別の理由でも薄皮饅頭モデルは業界に定着した。最初に「日本の雇用制度ではユーザー企業は技術者を抱えられない」と書いたが、必要な人材数の変動に苦しんでいるのは大手ITベンダーも一緒だった、受注できなければ仕事がない大量の技術者に給料を払わなければならない。だが、下請けへの丸投げを行えば、この問題をある程度解消できる。例えば、A社とB社が受注を競ってAが勝ったとする。そうなると、普通はBの技術者が大量に余る。しかし、両方とも丸投げモデルを採用しており、二次請ベンダーはA・Bのどっちが勝っても同じなのであれば、余るのはBのプロマネだけとなる。プロマネ層は提案活動で使える。個社で見てもIT業界で見ても、損失は明らかに小さい。
こうして、薄皮饅頭モデルを元に、IT業界で悪名高い多重下請け構造が業界に深く根付いた。
そして、技術者の給料は大きく下がった。ウォーターフォールによる分業化は、「お前の代わりはいるんだぞ」を作り出す。もはや、技術者達に下請けへの転属、給与ダウンに逆らう力は残っていなかった。
その結果、大手IT企業に残った人間は、顧客の御用聞きをして安値で勝ち取る営業、下請けを使い倒すことに優れたプロジェクトマネージャー、品質管理部だ。不況の折り、開発サービスの利益率は薄かったのでプロジェクトの炎上は許されなかった。そんな状況で、会社の経営陣が求めたのは、磨き上げた実績あるウォーターフォール開発の遵守徹底だった。品質管理部は現場の工夫なぞ認めず、チェックリストに沿ってプロマネ達を冷徹に管理した。みんな、ウォータフォール生まれ、ウォーターフォール育ちだった。
4. 2010年代～現在：日本のITの地盤沈下
大手ITベンダーは引き続き、給料を下げ・採用を絞っていた。優秀な新卒は、ITベンダーに入ってこなかった。優秀なベンダー技術者は、他業界へ去っていた。大手ITベンダーの人材は空洞化していた。
これに、ユーザー側も気づいてきた。「大手ITベンダーに高いマージンを払って契約する意味がどれだけあるのか？」と。そうして、小規模案件や保守業務は大手ITベンダーに発注されなくなってきた。
ここに来て、大手ITベンダーは技術力を失っていることに危機感を持ち始めた。丸投げ禁止＆自社技術者による開発を掲げた。しかし、これは技術力を失っている大手ITベンダー技術者を、下請けより高い値段で売りつけることだった。ユーザーは簡単には同意しなかったが、大規模開発においては他に選択肢はなかった。
これとは別に、ビッグデータなどのテクノロジーブームが幾つかあったが、大手ITベンダーは活用する創造力を失っていた。こうして、ユーザー側もITイノベーションを享受できなかった。
日本の法人向けIT業界が夜明けを迎えるにはどうしたらいいのか
ユーザー企業側が頑張るしかないのではないかと感じている。
まずは、マイクロサービス化とAPI化の推進。システム開発が小規模になれば、大手ITベンダーに依存する必要性が下がる。二次請けクラスとやればいい。
しかし、大企業では、複雑に絡み合った現行システム、メインフレームが存在していて、すぐに開発単位を細切れにすることが難しい。そのため、これらをマイクロサービス化・API化すれば、巨大なシステムテストは不要になるし、機能を追加していくことでシステムを「少しずつ育てる」ことを可能にしてくれるから、開発規模の圧縮に役立つ。
問題は、マイクロサービス化・API化をしたところで直ぐに企業の価値が上がらないことにある。かなり投資が必要になるくせに、やり遂げたところで社内業務は効率化されないし、顧客満足度も上がらない。ただ単に、これから改変がやりやすくなるだけ。一般的なROIは成立しない。だから、みんなやらない。でも、この価値はかなり大きいんじゃないかと思っている。
次に、アジャイル開発の推進。まだ予感レベルだけど、かなりの側面でアジャイル開発はウォーターフォールより優れているのではないかと思っている。技術的な議論は、色々されているっぽいから多くは語らないが、１つだけ言いたいことはウォーターフォールよりアジャイルのほうが人間味があり柔軟な思考力を鍛えるがゆえに、より早く良いものを生み出せるように思える。
とはいえ、大企業の基幹システムにアジャイル開発導入には考えることが多い。例えば、バックログの合意をどうするか、品質保証をどうするのかなど。でも、大手ITベンダー側はもっとガチガチで頼れない。だから、やるならユーザー側でやるしかない。（そして、アジャイルはもともと内製でやるものだ）
なお、アジャイル開発は小規模開発のほうが得意だから、マイクロサービス化・API化とは相性が良い。
機械学習を使ったAIについても色々あるが、既存のシステム開発と性格が大きく異るのでここで扱っても仕方ない気がするので議論対象から除外する。
得られる教訓・ITベンダーへのお願い
ここまで描いてきた歴史的な何かが正しいとすれば、IT業界が失ったのは"自分で考える力を持った人材"だ。業界は違うが、マクドナルドも人材を失って苦しんだようだ。良い人材は良い人材を引きつけ育てるため、一度人材を失ってしまえば復調は容易ではない。優秀な人を手放すのは最後にすべきで、IT業界はこれをやってしまった。
総じて大手ITベンダーの歩んだ流れは、人の歯車化であったように思う。私が在籍していたころ、毎年末に行われる人事評価指標は「稼働率」ただそれだけであった。良いアイデアを出したとか、顧客に感謝されたとか、新しいことを学んだとかは全く見ていなかった。まさに工場における生産機械のそれだった。
いま、それを責めようとは思わない。IT業界は「アーキテクト」とか「工事進行基準」とか数千年の歴史がある建築業界の用語を使っているし存在感もあるから勘違いしやすいが、極めて未熟な産業であって、どんな産業も標準化や分業化を経験しているから、必要だったことなのかもしれない。（中の人としては辛かったが）それに、薄皮饅頭モデルを採用しなかったら倒産していたのかもしれない。
しかし、これからは技術者を大事にしてほしい。給料を上げ、育成に時間と金を投資してほしい。アジャイルもAIもマイクロサービス設計も、とても個人のスキルが重要だ。人を生産機械化するばかりでは限界がある。そして、かつての尊敬を取り戻してほしい。
