この仕様書作成の期間に半年、1年とかかることもある。システムの規模によっては、30人単位の派遣になるから、日本のITベンダーはいわば“ヒト入れ業”だ。人海戦術でシステムが構築されていくのだ。

それでシステムができたと思っても、発注側はシステムを評価する力もないから、そのまま運用を始めてしまう。実際に使い始めると営業などの現場から次々と改善要望のクレームが集まる。それを情シスはリストアップして、ベンダーに対して「お金はたくさん払っているから直してくれ」と、追加料金なしで修正事項をぶん投げるのだ。ベンダー側も、不満はあってもお客様に対してNOとは言えないから、“サービス残業”をして徹夜で修正作業に取り掛かるのだ。

こうしてカスタマイズを重ねていくと、その会社独自のシステムができあがる。開発したベンダー以外では、もう改修ができないほどに作り込まれるのだ。運用し始めたが最後、途中で「このベンダーはやめて別のベンダーに乗り換えよう」と思っても、社内常駐からやり直しで多額のコストがまた必要だ。そのため不満だらけのシステムを使い続けなければならず、ベトナム戦争のように泥沼化していくのだ。

この最たる例が、日本の行政だ。12省庁・47都道府県・1718市町村がそれぞれバラバラにシステムを開発しており、どれも開発ベンダー以外は改修できないくらいに作り込まれてしまっている。行政のシステムやデータベースは1つでいいので、この問題にデジタル庁は取り組む必要があるのだ。

しかし、IT企業の社長と頻繁に会食しているだけの自称「IT通」デジタル大臣と、デジタルの専門家でないデジタル監は、使い勝手が悪い「マイナンバー制度」を改修することしか頭にない。日本政府も、日本企業と同じように自治体別、省庁別に泥沼にはまっているのだ（デジタル庁が作るべき国民データベースについては28年前の拙著『新・大前研一レポート』にて詳述）。

アメリカ企業やインド企業であれば、発注側もカーネギー・メロン大学の提唱する厳格なシステム構築の手法を用いて（CMMIレベル5ベースの）スペックを書ける優秀な人材を抱えているから、このような問題はまず起こらない。日本はプロジェクトマネジメントをするのはITコンサルタントやベンダー側だが、アメリカ企業なら発注側にしっかりプロジェクトマネジメントできる人材がいるのだ。

システムがわかる人が経営者になれ

経営者にとって、今やプログラミング思考は必須科目だ。自分のアイデアをどうシステム化するのかを語れることが重要で、優れた経営者たちはプログラミング思考を学び、挫折することなく習得している。

例えば、日本交通の川鍋一朗会長。彼は日本初のタクシー配車システム「日本交通タクシー配車アプリ」（後の「ジャパンタクシー」、現在「GO」）の原型を構築した。このシステムによって、タクシーをスマホで呼ぶことができるし、タブレット端末をタクシーに設置することでキャッシュレス支払いに対応し、乗客の属性に合わせた動画広告配信が可能となり、タクシーに新しい価値を生み出すことに成功した。