日本のDXが遅い一因は、作り手が「社外」にいること
目次
画面のボタンを1つ動かすだけで、見積書と稟議が必要になる会社があります。
たとえば、申込フォームの入力欄を1つ減らしたいとします。作り手が社内にいれば、相談した翌日に直っていることもある変更です。
システムを外部に発注している会社では、流れが変わります。変更内容を文書にまとめ、委託先に見積もりを依頼し、社内の承認を取り、発注し、納品を受けて検収する。数行の修正でも、この手順は省けません。
担当者が怠けているわけでも、委託先の腕が悪いわけでもありません。改善の1往復ごとに、契約の手続きが挟まる構造になっているんです。
改善の往復は、契約の単位で区切られる
ソフトウェアを外注すると、「気づく→直す→確かめる」の1周が、契約の手続きを通るたびに止まります。
従来型のシステム開発でよく使われる請負契約は、あらかじめ決めた成果物を完成させることに対価を払う契約です。作り始める前に仕様を固め、途中で変えるなら変更の手続きを踏む。品質と費用の責任を明確にするための、筋の通った仕組みです。
ただ、仕様を途中で変えながら育てる開発とは相性がよくありません。
情報処理推進機構(IPA)は2020年3月、アジャイル開発向けのモデル契約書を公開しました。前提にしたのは請負ではなく、専門家として業務を遂行すること自体に対価を払う準委任契約です。開発の途中で機能の追加や優先順位の変更に柔軟に対応するため、と説明されています。
契約の形が改善の回し方を縛ることを、公的機関も認めて手当てしたわけです。
及川卓也さんは『ソフトウェア・ファースト』で、内製を重視する理由をスピードとノウハウの蓄積に置いています。ユーザーの反応にすぐ応えるには、社内で完結する体制が要る。そして仮説検証で得た失敗の学びは、作った側に残ります。
及川さんは、自社で巻き取れないシステムは作った日から負債を抱えているようなものだ、とも書いています。
日本の作り手の7割は、IT企業の側にいる
日本では、情報処理や通信に携わる人の約7割がIT企業に所属しています。米国では逆に、約3分の2がIT企業以外、つまりシステムを使う側の企業や組織にいます。
IPAが『DX白書2023』で、日米の統計調査をもとに比べた数字です。
- 日本
- 約125万人のうち、IT企業に所属する人が73.6%(2020年の国勢調査)
- 米国
- 約498万人のうち、IT企業に所属する人が35.1%(2021年の職業別雇用統計)
前回の比較(2015年の数字)では、日本が72.0%、米国が34.6%でした。数年たっても、ほとんど動いていません。
シリコンバレーでAI事業の支援をしてきた石角友愛さんも、『いまこそ知りたいAIビジネス』で同じ日米差を取り上げています。本では日本が約8割、米国が約7割と書かれていますが、ここではIPAの数字を採りました。
この数字の読み方には注意が要ります。示しているのは所属の分布で、DXの遅れを直接測ったものではありません。所属の違いがDXの速さを決める、という因果を示したデータは、私が調べた範囲では見つかりませんでした。
それでも、改善の往復が契約で区切られる仕組みと重ねると、日本の会社の多くで1周が長くなりやすい理由の一つとして筋は通ります。
経済産業省の『DXレポート2.1』(2021年)は、この関係を「低位安定」と呼びました。発注する側は委託でコストを抑え、受託する側は低リスクで安定した仕事を得る。一見どちらも得をしているようで、実際にはデジタル競争で負けていく関係だ、という指摘です。
問題にされているのは、発注する側と受ける側の関係の組み方のほうです。
AIで速くなるのは、往復の一区間だけ
AIでコードを書く速さが上がっても、契約の手続きに使う日数は縮みません。
改善の1周を区間に分けてみます。
- 気づく
- 利用者の反応やデータから問題を見つける
- 決める
- 何をどう直すかを決め、仕様にする
- 手続き
- 見積もり、承認、発注、検収
- 作る
- 設計、実装、テスト
- 確かめる
- 公開して反応を見る
生成AIが大きく効くのは、主に「作る」の区間です。たとえば実装が5日から2日に縮んでも、手続きに3週間かかっていれば、1周の長さはほとんど変わりません。全体の速さは、いちばん遅い区間で決まります。
及川さんは、人月で値付けする受託の商売では、工期が縮むと売上も減るため、効率化が歓迎されにくい場合があるとも指摘しています。速くなった分が委託先の不利益になるなら、短縮は進みにくくなります。
AIの導入そのものにも、同じ構造が影響します。石角さんは、社内に技術を理解する人がいないと、経営陣がAIの開発や運用を具体的に想像できないと書いています。その結果、AIに何でも任せられると期待しすぎるか、実態のない不安を抱くかに振れやすい。
AIは、データを入れて試し、精度を見て直す往復で育てる技術です。たとえば需要予測のモデルを試して、最初の精度が足りなかったとします。使うデータを足すか、予測の単位を変えるかを決めて、もう一度回す。この判断を毎回見積もりと発注に載せていたら、1回の試行に数週間かかります。
往復のたびに契約が挟まる会社では、試せる回数そのものが減ります。
全部を内製しなくていい。主導権を社内に置く
差を生むのは技術者の人数より、何をどう直すかを決める人が社内にいるかどうかです。
日本企業が外注を選んできたのには理由があります。必要なときに必要な人数を集め、終われば手放せる。『ソフトウェア・ファースト』も、外部委託がコスト削減や雇用の調整に役立つと考えられてきたことに触れています。そのうえで及川さんは、外部の力を借りる場合でも、すべての段階を自社でコントロールできる状態を保つべきだと述べています。
誤解:DXを進めるには、エンジニアを大量に採用しなければならない → 最初に要るのは、仕様を判断できる人を社内に1人置くことです。石角さんは、経営と技術の間に立って課題をAIの使い道に翻訳する役割を「AIビジネスデザイナー」と呼んでいます。
誤解:外注先を変えれば改善が速くなる → 委託先を変えても、往復のたびに見積もりと承認が挟まる構造は残ります。たとえば頻繁に直す画面だけ準委任で継続契約にし、月ごとの範囲内なら都度の見積もりなしで直せる形にする。こうした契約の組み替えのほうが効きます。
誤解:すべてのシステムを内製に切り替えるべきだ → 会計や勤怠のように、他社と差がつかない仕組みは既製のサービスで足ります。手元に置くのは、顧客の反応を見て何度も直す部分です。
5分でできること:最近の改善1件の往復日数を数える → 「直したい」と最初に言った日から、本番に反映された日までを数えてください。そのうち作業していた日数と、手続きを待っていた日数を分けます。待ちのほうが長ければ、ツールより先に見直すのは契約と体制です。
おわりに
DXが遅れる理由は、経営の優先順位、人材の不足、古いシステムの負債と、いくつも重なっています。作り手の所属は、その中でも見落とされやすい一つです。
同じAIを入れても、1週間で1周できる会社と、1周に1か月かかる会社とでは、1年で試せる回数がまったく違います。
この記事で参考にした本
『ソフトウェア・ファースト』及川卓也さん → DXの本質を、ITの全段階を自社で握る「手の内化」と定義した視点
『いまこそ知りたいAIビジネス』石角友愛さん → 日米の技術者の所属の違いと、経営と技術を橋渡しする「AIビジネスデザイナー」という役割
合わせて読みたい
『いまこそ知りたいDX戦略』石角友愛さん|DXは「ツール導入」ではなく「コアの再定義」だった 同じ著者が、DXを事業の中心から組み直す手順を書いた本です。主導権を社内に戻したあと、何から手をつけるかを考える材料になります。
『プロダクトマネジメントのすべて』及川卓也ほか|「ミニCEO」なのに権力を持たない人の戦い方 この記事で「社内に1人置く」とした、何をどう直すかを決める役割の仕事を詳しく扱っています。
『スクラム 仕事が4倍速くなる世界標準のチーム戦術』ジェフ・サザーランド|計画通りに進めるほど、仕事は遅くなる 仕様を先に固めて作る開発と、短い往復で直しながら作る開発の違いを、具体的なプロジェクトで比べられます。