日本は『デジタル敗戦国』なんですか？：連載第1回
あらすじ
日本は『デジタル敗戦国』だとの批判の声が聞こえてきます。しかしデジタル敗戦問題は、デジタルやITのせいではなく私たちのビジネスモデルを作り出す活動の停滞が招いた問題です。この連載記事におけるDX（デジタルトランスフォーメーション）とは、デジタルやITを使った新しいビジネスモデルを作り出すことで、新しい市場や収益を生み出す活動のことです。この連載記事では米国を起点とするDXの動向が、どのようにボクたちの社会を変えてきたのかや日本の現状と比較することで問題の理解を深め、問題解決の糸口になる〈新しい方法〉を提案します。
はじめに
この連載第1回から第3回までが本論となっています。長文になったことから、第3回までの〈まとめ〉を第4回に書きました。コンパクトに全体像がみえるように要約しましたので、よろしければそちらをご覧ください。
1.日本のデジタル敗戦に、がく然とした岸田総理大臣
2023年8月4日、マイナンバーカードの紐づけ誤りをめぐる混乱についての記者会見でのことです。岸田総理大臣は謝罪したうえで会見をこう締めくくりました。
欧米諸国や台湾、シンガポール、インドなどで円滑に進む行政サービスが、我が国では実現できないという現実に直面し、我が国がデジタル後進国だったことにがく然といたしました。このデジタル敗戦を二度と繰り返してはならない。主要先進国に大きく後れを取っている我が国行政のデジタル化の遅れを取り戻したい。
岸田総理大臣の会見内容を要約すると、このようになります。
マイナンバー登録を進める中で起きた様々な登録ミス問題は、手作業で登録していたために起きたことであり、デジタル化の遅れが原因です。近年、起きた以下の問題もすべて原因は共通しています。
・国民への給付金や各種の支援金における給付の遅れ
・感染者情報をファクスで集計することなどによる保健所業務のひっ迫
・感染者との接触確認アプリ導入やワクチン接種のシステムにおける混乱
すべて手作業での処理を強いられたことが原因です。
これらの問題には、表面的にはスマホアプリやWebブラウザーから自動的に登録が行われたかのようにみえても、その背後に人間がいて手作業で処理していた問題が含まれています。
実はこのニュースを知ってボクもがく然としました。マイナンバーカード登録は手作業だったんですね。（遠い目）
本当に日本は『デジタル敗戦国』なんですか？
いいえ、日本は『デジタル敗戦国』ではありません。岸田総理大臣のこの発言にも関わらず、日本を『デジタル敗戦国』とよぶのはふさわしくありません。
岸田総理大臣がいう〈デジタル敗戦国問題〉とは、マイナンバーカード登録にまつわる混乱など〈アナログ手作業問題＝デジタル化の遅れで手作業を強いられたことにより起きた現場の混乱〉を指しています。しかしふたつの理由で、日本を『デジタル敗戦国』とよぶのはふさわしくありません。
ひとつ目の理由は、アナログ手作業問題の原因がデジタルやITにあると思われていますが、実はそうではないからです。デジタル敗戦国問題といったとたんに、ボクたちはそれをデジタルやITに関わる問題だとつい思いがちです。なんとなくボクたちには関係ない感が出てしまいがちになります。でもそういうことじゃないんです。
そのうえ、このアナログ手作業問題を解決するのは、それほど難しいことではありません。だからこの問題は国をあげて騒ぐほどの問題ではないという意味でも『デジタル敗戦国』は適切なネーミングではありません。
「そんなこと、いっちゃって大丈夫なんですか？」という声がいたるところから聞こえてきます。いや、たしかにそうですよね。国をあげてデジタル化の遅れを取り戻そうと大騒ぎしています。それにもかかわらず、はかばかしい成果が得られずに混沌としているのです。それなのに、そんなことをいっちゃって大丈夫なのかと思うのは当然です。
でも大丈夫です。だって不思議だと思いませんか。国際摩擦を引き起こす気はありませんが、ボクは日本人が国際水準からみれば優秀な部類に入ると思っています。ちょっと統計資料を探せば、それを裏付けるデータはいくらでもあります。少なくとも平均以上の能力を持っていると誰もが思っているのではないでしょうか。
その一方で岸田総理大臣がいうように、欧米諸国や台湾、シンガポール、インドなどではITによる円滑な行政が当たり前のように行われています。お隣の韓国もデジタル行政が進んでいることで昔から有名です。
日本人の能力が、これらの国よりも劣っているのでしょうか。劣っているからアナログ手作業問題が起きているのでしょうか。そんなことはないはずです。アナログ手作業問題の原因は、他の国では当たり前のように行われていることが日本では行われていないことにあるのです。
それが問題解決のボトルネックになっているのです。でもそのボトルネックに気づいていないのです。ボクの考えだと、そのボトルネックの存在が当たり前になっていて、それが問題として目に入らないのです。
しかしそのボトルネックの解消は難しいことではありません。だからその問題の所在に気付いて、そのボトルネックを解消すれば大丈夫だとボクはいうのです。
ボクたちはスケールの大きな問題に直面している
ところがふたつ目の理由があります。アナログ手作業問題の背景には、とても〈スケールの大きな問題〉が隠れていて、ボクたちはその問題にこそ目を向けるべきなのです。そのスケールの大きな問題も、デジタル敗戦国問題とよぶのはふさわしくありません。
もちろんアナログ手作業問題による現場の混乱は大問題です。ボクも現場で泣かされた経験が数多くありますから、この問題の大変さは身にしみてわかっています。むしろこの問題の大変さを語らせたら、ボクの右に出るものはいないと思うくらいです。
でもアナログ手作業問題の背景には、とてもスケールの大きな問題が隠れています。その問題があるためにさまざまなコトが起きています。そのひとつは、日本が経済的な敗戦国に凋落したことです。
日本が〈失われた30年〉の長くて苦しいトンネルから抜けられないのも、日本のGDPがドイツに抜かれて世界第4位に後退したのも、このスケールの大きな問題によるものです。
先進国の中で唯一給料があがらない国になってしまったのも、この問題が原因です。なぜならば給料の原資である〈国民ひとりあたりGDP〉が、世界第38位（2024.5時点）に後退してしまったからです[2]。ボクはこの世界第38位という現実にこそ、がく然とすべきだと考えています。
アナログ手作業問題はさっさと解決して、このスケールの大きな問題の解決に一日でも早く向かうべきだと思うのです。
この連載第1回では〈ひとつめのテーマ＝アナログ手作業問題は解決できる〉をあつかいます。そして第2回で〈ふたつめのテーマ＝ボクたちはスケールの大きな問題に直面している〉について書く予定です。さらに連載第3回では、この連載記事の本論として、このスケールの大きな問題の解決の糸口につながる〈新しい方法〉を提案します。
2.なぜIT化できずに手作業に追われているのだろうか？
マイナンバーカードのアナログ手作業問題に限らず、ビジネス現場でも問題が起きています。ボクたちはIT化を実現できずに、いまだに手作業に追われ続けている現状があります。はじめにこの問題の現状と原因を掘り下げていきたいと思います。
即時に電子市民権が得られるエストニアの電子政府
さきほども述べたとおり、海外にはデジタル行政が円滑に進んでいる国がたくさんあります。でもボクが知っている限りにおいて、現時点での行政デジタル化の世界最先端はエストニアの電子政府です。[3]
世界のどこにいてもデジタルで市民権が即時に発行され、会社をつくるのも、ものの数分でできるなんてなんだかすごすぎだと思いませんか。
ということはエストニアのデジタル行政には人手が介在していません。手作業がないんです。99%が、つまりほとんど全てがデジタルの世界で完結しています。まさに『攻殻機動隊』の電脳空間の世界観です。
草薙素子は肉体的にはいったん滅んだはずなのに、サイバーネット空間にコピーした人格が残りました。そしてサイボーグとして復活したのです。つまり、もしも仮に〈エストニアは滅んでもネットに残る〉のです。
このように世界の行政においては〈全自動〉があたりまえです。ビジネス現場でもそうです。せっかくスマホアプリやWebブラウザからデータを入力したのに、手作業でデータを再入力している国は、先進国の中では日本だけなのです。
遠い目にならざるをえない日本のビジネス現場
行政に限らず、ビジネス現場でもアナログ手作業問題が深刻です。手作業に追われて混乱が起きています。もっとも人生、いろいろ、ビジネス現場も、いろいろです。だからボクの限られた経験が、日本企業全体の傾向だということは決してできません。
でもマイナンバーカードのアナログ手作業問題を知ったときに、ボクにはどうしても遠い目にならざるをえない記憶がありました。
商品を製造販売しているメーカーのEコマース。Webブラウザー経由の注文がEメールに飛ばされて届きます。すると担当者が手作業で注文内容を登録します。
ITベンダー（！？）のサービス受注。注文が直接Eメールで届くので手作業でさばきます。
Eメールでの受注は本質的にミスを避けられない仕組みです。人間である以上、目視での確認ではミスを避けることができません。大量のEメールを目視で漏れなく確認するのは至難の技です。
しかし実際に受注ミスが起きてしまえばそれは大事故です。だからダブルチェックと称して受注ミスがないかどうかを、もう一人の担当者が目視でチェックします。
それでもミスを避けることができません。膨大な数のEメールを目視で確認すること自体にミスが起きるからです。ダブルチェックがトリプルチェックに。どこまで人手をかければよいのでしょう。
そのうえ手作業での登録自体が問題を引き起こします。業務マニュアルは存在せず業務研修もありません。担当者ごとの属人的な判断に頼った登録が行われた結果、マイナンバーカードのアナログ手作業問題と同様のミスの連発です。
Webブラウザやスマホアプリからの受注作業は全自動が当たり前です。Eメールなんて論外です。そこから販売管理、在庫管理や配送管理,、会計管理まで、どこまで仕事の流れを自動化できるかが課題です。
全自動を実現すれば担当者がひとりもいらないものを、このITベンダーでは手作業の事務処理のために、10人の担当者を配置していました。それでも頻発するミスの対応に、現場は毎日、大混乱です。
業務効率があがるわけがありません。ひとりあたりGDPが後進国なのは当然です。マネージャも顔を真っ赤にして怒ります。担当者からすれば生きた心地がしません。だからボクには、マイナンバーカード登録の現場の混乱が手に取るように想像できるのです。
ではこのアナログ手作業問題の正体はなんでしょうか。どのようにすれば当たり前のように全自動にできるのでしょうか。
ビジネス君とITさんの親密な関係
それでは〈アナログ手作業問題＝デジタル化の遅れで手作業を強いられたことにより起きた現場の混乱〉の原因を探っていくことにします。
図表1.2が示すように、IT化におけるビジネスモデル空間にはふたつの仕事の流れが同居しています。ビジネスモデルにはいくつかの意味がありますが、ここでは業務を運用する仕組み（仕事の流れやルール）という意味で用いています。行政については厳密には行政モデルというべきですが、ここではひっくるめてビジネスモデルとよぶことにします。
ビジネス君の仕事：人が営む現場（物理空間）における仕事の流れやルール
ITさんの仕事：ITが営むコンピュータ内部（仮想空間）における仕事の流れやルール
この前者を〈ビジネス君（の仕事）〉と呼ぶことにします。後者は〈ITさん（の仕事）〉です。
ボクたちはあたかもITさんという実体が存在していて、ITさんがひとりで頑張ってせっせと働いているかのように考えがちです。ITさんの仕事ぶりに問題があるから、わが国はデジタル敗戦国とよばれるのだと考えがちです。でも違うんです。それは冤罪です。
ビジネス君とITさんの仕事の流れには〈鏡写しの法則〉があります。
ビジネス君の仕事をITさんに任せようと思ったとします。つまり〈業務移管〉です。そのためにビジネス君がルールに沿って進める仕事の流れを鏡写しします。そしてITさんが同じルールに沿って、同じ仕事の流れを進めることができるように教える必要があります。
たとえば旅費精算業務の担当者、ビジネス君がいます。そこには電卓しかありません。するとビジネス君は旅費精算申請書を読んで、旅費の精算規定（ルール）に沿って電卓をたたいて処理を終えなければなりません。
これをITさんに業務移管しようと思ったら、ビジネス君は正しい旅費精算業務の仕事の流れや正しい旅費の精算規定（ルール）をITさんに教える必要があります。
実はここに問題の根っこの一丁目一番地があるのです。
ITさんへの業務移管がうまくできていますか？
行政にしてもビジネスにしても、いろんなところで業務移管がうまくいってません。ITさんは融通が利かない堅物なので、教えたとおりにしか仕事をしません。だから人間以上にきっちり教えないと、ミスの粗製乱造機になってしまいます。
岸田総理大臣の報告ではマイナンバーカードの紐づけ誤りは、マイナンバーカード登録業務の属人化が原因とされています。ビジネス君の現場でも業務の属人化が日常茶飯事です。この業務の属人化が第一の問題になります。
属人化とは、ビジネス君の仕事の流れやビジネス君が参照した規約（ルール）が、ビジネス君ごとにばらついていることを意味します。この状況でビジネス君の仕事のIT化をはかろうとしたとします。つまりビジネス君の仕事をITさんに業務移管したいと思ったとします。
ここで鏡写しの法則を思い出してください。ITさんは鏡写しの法則で、ビジネス君が教えてくれた仕事の流れやルールどおりにしか仕事ができません。そこでビジネス君ごとに仕事の流れや参照した規約（ルール）がばらついていたら、どうなるかを考える必要があります。
ビジネス君ごとにITさんを雇って、異なる仕事の流れやルールを移管するのでしょうか。それとも1人のITさんが、複数のばらついた仕事の流れやルールを指示されるのでしょうか。
いずれにしてもビジネス君がITさんに移管した業務がばらついていたら、ITさんにはばらついた業務を再現することしかできません。〈鏡写しの法則〉があるからです。
だからもしもそんなばかげたことをやったとしても、ITさんは属人化した仕事の流れを再現するだけです。そして紐づけ誤りや受注ミスのような問題を再現し続けることになるのです。
ボクは実際に、複雑な業務の移管を受けた経験があります。マニュアルがない状況で、前任者から終日、業務の移管を受けるのですが、どうしても理解できません。なぜかといえば前任者が思いつきで、スパゲティに仕事の流れやルールを説明するからです。
不明点を質問すると、それはあのファイルにあるはずだから見てくれということでした。でもどのファイルも過去の作成書類を集めたものばかりで、仕事の流れや規約（ルール）を書いたものは存在しなかったのです。
結局、業務マニュアルをゼロから作りました。そうするしかなかったのです。それでも前任者が説明し忘れたルールがいくつかあって、それが原因でミスをしてしまいました。どこかのテレビCMみたいに「最初から言っといてよ」と思いましたが後の祭りです。
結局どえらい怒られ方をしたのですが、ボクは心の中でそっと「冤罪だ」とつぶやくしかなかったのです。この悲しいエピソードは何を示唆しているのでしょうか。
〈業務マニュアル〉がボトルネックなのです
ITさんに業務移管するにあたっては、ビジネス君ごとに属人化している、ばらついた仕事の流れやルールの〈標準化〉が第一に必要です。そのうえで、その標準化した業務を正しく説明した〈業務マニュアルをつくる〉ことが大前提になります。
業務マニュアルなしには人外の記憶力をもった人間でない限り、複雑な仕事の流れや多種多様なルールを正確に伝えることはできません。教えられた方も混乱するばかりで、業務を覚えることはできません。
その後、それをITさんが理解できるプログラミング言語やデータベースに落とすことができてはじめて、ITさんに期待する仕事をしてもらうことができるのです。ところがどうもボクたちは、このプログラミングやデータベースに落とすところに問題があると考えがちです。
このようにしてビジネス君には大きな勘違いが生まれます。アナログ手作業問題は、IT部門やITベンダーのデジタルやITに関わる問題になってしまうのです。業務マニュアルをつくる役割を自分たちが担っていることを知らないのです。
だってそうでしょう。業務マニュアルを作ることができるのは、業務を知っているビジネス君以外にはいないのです。でもその役割をになっていることを知らないのも無理はありません。なぜならば誰もそんなことを教えてくれないからです。ビジネス君には長年にわたって、そもそも業務マニュアルを作る習慣がないからです。
出来合いのパッケージソフトウェアを買ってくる場合でも、SaaSでアプリケーションを利用する場合でも、業務マニュアルは必要です。SaaS（Software as a Service：ソフトウェア・アズ・ア・サービス）とは、インターネットを通じてソフトウェアをサービスとして利用することを指します。
これらについても業務マニュアルに照らし合わせることで、そのソフトウェアをカスタマイズしたり利用したりができるようになります。例えば財務会計ソフトのような汎用性がとても高いものですら、勘定科目を適切に設定しなければ使えません。
日本のITシステム開発は、業務マニュアルを書く力がめちゃくちゃ弱いことが大問題です。大上段に腕を振りかざしていいます。まずはこれをどうにかすることが先決です。ビジネス君が業務マニュアルを書けるようになるのが先決です。業務マニュアルを正しく書けない限り、いつまでも手作業の悪夢から脱することはできません。
アナログ手作業問題は、プログラミングやデータベース設計などの〈IT＝テクノロジー〉に関わる問題のように表面的にはみえるかもしれません。もちろんテクノロジーをうまくあつかえることは必要です。しかしこの問題の根っこには、テクノロジーの問題以前に、ビジネス君の業務マニュアルを書く習慣の欠落があるのです。
つくるはわかる・わかるはかわる
でも業務マニュアルの書き方なんて知らないよ。多くのビジネス君がそういうでしょう。当然です。業務マニュアルを書いたことがなければ、業務マニュアルの書き方はわからないからです。
理論物理学者のリチャード・ファインマンは、こういいました。[4]
What I Cannot Create、
I Do Not Understand.
つくれないものは、わかっていない。
誰もがそれを〈作る〉ことによって理解します。手を動かして、身体を動かして、作ってみることで、やってみることで理解するのです。竹細工の作り方は、竹細工を作ってみなければわかりません。泳げない人が、水泳のマニュアルをいくら読んでも泳ぎ方はわかりません。
でも作ってみて、やってみて、〈わかる〉と世界が変わってみえます。一本の木をスケッチする前とスケッチした後では、その木は変わって見えるはずです。自転車に乗れるようになってしまえば、なぜ以前は乗れなかったのか、わからなくなるはずです。その背景にある世界観が変わって見えることもあるでしょう。
ではなぜ世界が変わって見えるのでしょうか。それは自転車に乗れるようになった人の能力が変わったからです。その身体的な能力が成長したからです。つまり〈できる〉ようになったからです。
〈一本の木を描く＝絵をつくる〉はわかるであり、わかるはかわるなのです。つくることでわかるのであり、そして自分がかわるのであり、できるようになるのです。
ボクはライターですが、ライターの方なら誰でも身に覚えがあるはずです。ライターは書くことによって〈ほんとうに書きたいことがわかる〉のです。言葉を尽くして書くことで、自分の考えが深まっていくのです。世界の見え方が変わっていくのです。先人はいいました。「いい文章を書きたければ、とにかく書く、たくさん書く」と。
業務マニュアルだって同じです。業務マニュアルを書くことで、そのビジネス君は業務をほんとうの意味で理解できます。ほんとうの意味で業務マニュアルを書くことができるようになります。業務マニュアルを書くトレーニングは人材育成に直結します。作ることは人の成長を導くのです。世界が見えるようになり、できるようになるのです。
だから業務マニュアルを部分的にでも書きはじめることが必要です。でもそれは難しいことではありません。書き方をガイドするわかりやすい方法が世の中には存在します。
その昔、ヨガは師匠に弟子入りして、一子相伝で長年にわたって修行しマスターするものだったといいます。でも今は本屋に行けば、ヨガを手軽に始めることができる入門ガイドがあふれています。YouTubeをみたっていいのです。あちこちでヨガの入門教室も開かれています。
まわりに誰も業務マニュアルの書き方を教えてくれる人がいなければ、はじめはインストラクターが必要かもしれません。でもボクは業務マニュアル（専門用語では〈業務要件定義〉という）の書き方を教えたことがありますが、ボクの経験でいえば、3か月間のトレーニングで自分が担当する業務のマニュアルが書けるようになります。
日本ではいま、DX人材の育成が問題になっています。座学が役に立たないとはいいませんが、人材育成には座学よりも手を動かすことです。つくるはわかる。わかるはかわるです。そしてかわるはできるです。業務マニュアルの作成から、ビジネス君のトレーニングを開始すべきです。
これまで述べてきた通り、アナログ手作業問題のボトルネックは〈業務マニュアルを自分で書く習慣の不足〉です。業務マニュアルを書くことさえできれば、後はIT部門なりITベンダーとの協働の問題になります。
それにIT部門やITベンダーに聞いてみてください。業務がわからないことや業務マニュアルが書けないことが深刻な課題になっていると、きっというはずですから。
このボトルネックの解消法は〈石の上に3か月！ 業務マニュアルをとにかく書いてみることからはじめる！〉という実にシンプルなものです。方法のガイドは必要です。でも自分たちで100%、コントロールして解決できる問題なのです。
3.テクノロジーの問題のようにみえても、それは人間の問題である
アナログ手作業問題のボトルネックは〈業務マニュアルを自分で書く習慣の不足〉です。デジタル敗戦国問題というと、それはデジタルやITの問題のようにみえるかもしれません。でもその正体は〈業務マニュアルを自分で書く習慣の不足〉という人間の問題なのです。昔、ワインバーグという賢人が言いました。
テクノロジーの問題のように見えても、それは人間の問題である。
業務の標準化とはなんですか？
ところがもうひとつ、人間の問題があります。ITさんに業務移管するにあたっては、業務の標準化が必要だと述べました。そのうえで、その標準化した業務を正しく説明した業務マニュアルをつくることが大前提だとしたのです。
それではこの業務の標準化とはなんでしょうか。ビジネス君ごとに属人化してばらついた仕事の流れやルールを標準化するとは、何をすればよいのでしょうか。業務の標準化とは何かを説明するために、ボクが経験した事例をご紹介します。
先任者が引き継ぎ損ねたルールを原因としてミスをしでかしてしまい、どえらい怒られ方をした事例をさきほど紹介しました。この現場ではミスの予防はもちろんですが、書類作成に時間がかかりすぎることが問題となっていました。この問題に関するマネージャの問題意識は〈担当者の業務の不慣れをどうにか改善しなければならない〉というものでした。
そこで現状の業務について業務マニュアルを書いた結果、以下のように業務処理に時間がかかっていた原因が判明しました。この問題を理解する目的で業務マニュアルを書くことを〈業務の見える化〉といいます。
業務マニュアル不在で業務移管が失敗していたために、属人的な業務が行われていたこと。それによってミスが発生し、その対処のために時間がかかっていたこと。
書類作成に必要なデータを事前に用意していなかったこと。書類作成をはじめてからデータ収集をはじめていたので、時間がかかっていたこと。
書類に書き込むデータのマネージャ承認に時間がかかっていたこと。この現場ではあらゆることにマネージャ承認が必要で、しかもマネージャ承認に数日間かかることがざらだったこと。もちろん作成済み書類の承認に時間がかかる問題も起きていた。
実は書類の作成自体にかかる時間は5分もなかったのです。しかしマネージャにはそれが理解できません。なぜならば業務マニュアルを書いた経験がないので、問題が起きている状況が想像できないからです。
そこで以下のように〈ルールを変更〉し、図表1.6のように〈あるべき業務を設計〉しました。そして業務マニュアルを書き換えました。この目的で業務マニュアルを書くことを〈業務改善＝あるべき業務の設計〉といいます。つまり〈業務の標準化＝業務の見える化＋業務の改善〉なのです。
新ルール（＝あるべき業務）
業務マニュアルを作成し、移管業務の質を改善する。
書類作成をはじめる前に必要なデータの収集を終える。つまり必要なデータの収集を終えなければ、書類作成をはじめてはならない。
書類に書き込むデータのマネージャ承認を書類作成の前に終える。つまり書類に書き込むデータのマネージャ承認を終えなければ、書類作成をはじめてはならない。
百聞は一見にしかずです。この新ルールへの変更により、書類作成にかかる時間は5分とかからないことが体感できたのでした。
注目すべきはこの〈業務の標準化＝業務の見える化＋業務の改善〉には、デジタルやITは登場しないことです。それでも書類作成時間が5分に短縮できたのです。繰り返しになりますが〈テクノロジーの問題のように見えても、それは人間の問題〉なのです。
生成AIがもたらすイノベーションを享受する
少しだけ脱線します。業務マニュアルを書きさえすれば、ChatGPTをはじめとする生成AIがもたらすイノベーションを享受できる可能性が広がります。それはどういうことか、さきほどの事例にもとづいて紹介します。
ITの問題ではないことを示すために先ほどはあのようにいいましたが、じつはITを使って全自動化しました。手順は以下のとおりです。
手元には作成した業務マニュアルがある。
書類作成に必要なデータを事前に用意しておく。
書類に書き込むデータの事前承認を終えておく。
日本語で書いた業務マニュアルの内容を、そのまま日本語でChatGPTに指令文（プロンプト）として入力し、Excelのマクロ言語（VBA）に変換するよう指示する。
Excelにデータを入力しマクロ言語を実行することにより、瞬時に書類が全自動で作成できることを証明した。
言い換えると〈ITによる全自動化〉には、その事前準備としての〈業務の標準化＝業務の見える化＋業務の改善〉が必要だということです。この事前準備がなければ、そもそもIT化ができないうえに、IT化できたとしても書類作成に時間がかかることは変わりません。この事前準備がアナログ手作業問題を解決するためのカギであり、そのために業務マニュアルを書くことが必要なのです。
ところで4.と5.にかかったのは、わずか2日です。本当に時間がかかったのは（1）業務マニュアルの作成と（2）データの事前準備や（3）マネージャの事前承認を得ることです。でもこれ以降、もう業務移管に悩む必要はありません。なぜならば〈ITによる全自動化〉が実現できたからです。
担当者の仕事はもはや、（1）業務マニュアルの作成保守と、（2）データの事前準備や（3）マネージャの事前承認を得ることに変わったのです。
ちなみにボクはそれまでExcelのマクロ言語（VBA）のプログラミング経験がありませんでした。でも問題ありません。ChatGPTがプログラミングしてくれるからです。
もちろんChatGPTの出力が誤ることもあればマクロ言語にエラー処理を加えるなど、継続した改良が必要です。でもそれだって難しいことではありません。というのは作業の大半は日本語で書くChatGPTへの指令文（プロンプト）を整備することだからです。
生成AIがもたらすイノベーションとは、日本語で指令文（プロンプト）を発行できることから生まれます。ビジネス君が日本語で指令（プロンプト）を発行すれば、それをChatGPTが〈テクノロジー〉に変換してくれるのです。
ボクはビジネス君が業務マニュアルを書けるように支援すること、ビジネス君が生成AIに発行する指令文（プロンプト）を円滑に発行できるように環境整備をすること。それがこれからのIT部門の新しい役割になるといいんじゃないだろうか。そんなことを考えています。
さて脱線してしまいました。そろそろ本題に戻ることにしましょう。
4. なぜ業務マニュアルを書く力がメチャクチャ弱くなってしまったのだろうか？
それにしても不思議な話です。ボトルネックは〈業務マニュアルを書く習慣の不足〉でした。ではなぜ海外と比べてひとり日本だけに、その習慣が不足しているのでしょうか。その理由を探るためには歴史をさかのぼる必要があります。
ジャパニーズ・ソフトウェア・アズ・ナンバーワン
米国の産官学合同の調査団が日本を訪れました。目的は日本で生まれた先進的ソフトウェアをどのようにして開発することができたのか、その秘密を研究することです。研究成果を米国に持ち帰った調査団は、品質が良いソフトウェアを開発できる組織のあり方についての制度設計に取り組み、その普及につとめました。
もう歴史の片隅に埋もれてしまった、こんなことがあったといえば、みなさんは驚くでしょうか。
1980年代の日本のソフトウェア工学は、世界の最先端を走っていたのです。とりわけ急速な経済成長と金融の自由化・国際化に対応するために、日本の金融機関が開発した第三次金融オンラインシステムは、世界最先端の日本のソフトウェア工学によって支えられていたのです。
〈ジャパニーズ・ソフトウェア・アズ・ナンバーワン〉の時代です。
1989年12月29日、日経平均株価は３万8915円87銭の史上最高値を付けました。この時点をもって日本経済は歴史的なピークを迎えたといえます。〈ジャパン・アズ・ナンバーワン〉と世界から絶賛された日本経済の絶頂期です。そしてそれは失われた10年、失われた20年、それから失われた30年のはじまりでもありました。
図表1.7は、日本の株式時価総額ランキングではありません。1989年当時の世界市場ランキングです。世界から絶賛された日本経済の絶頂期を示すものです。このトップ10の5つを、日本の金融機関が占めていたことに注目してください。
日本の金融機関が必要とした第三次金融オンラインシステムを提供したのが、ビッグ5とよばれた日立、富士通、東芝、NEC、そして日本IBMの〈SI’er（システムインテグレーター）〉です。このSI’erが1980年代の日本経済を電算化（電算化！？）の面から支えたのです。
ナンバーワンとしてのジャパニーズ・ソフトウェアは、ナンバーワンとしてのジャパニーズ・バンキング・ビジネスのニーズに適応して、ビッグ5 SI’erが提供したのです。これらSI’erのビジネスモデルを〈日本型SIビジネスモデル〉と呼びます。
この連載記事では、当時の〈ユーザー企業＋SI’er〉がエコシステムを構成していたし、いまでもそのエコシステムは基本的な形を変えずに存続し続けていると考えます。この1980年代に隆盛を極めた日本型SIビジネスモデルが、基本的な形を変えずに存続し続けていることに注目してください。これが問題理解にむけてのカギになります。
ビジネスにおけるエコシステムとは、ある特定の分野において複数の企業や組織が互いに連携し協力し合いながら価値を生み出す仕組みのことです。
日本型SIビジネスモデルは、なぜSIガラパゴスと揶揄されるのだろうか？
いまIT業界では、この日本型SIビジネスモデルを〈SIガラパゴス〉と揶揄する意見が根強くあります。
それはこのビジネスモデルが機能しない場面や効率が悪い場面が目につくようになってきたからですが、その責任をただひとりSI’erに問うのは間違っています。〈ユーザー企業＋SI’er〉によるビジネスモデル全体で問題を理解しなければ、原因の根っこはみえてきません。
では〈なぜ日本のITシステム開発は業務マニュアルを作る力がメチャクチャ弱いのか〉の問題に戻ることにしましょう。
日本IBMが日本型SIビジネスモデルを発明した当初の目的は、ユーザー企業を〈ゆりかごから墓場まで囲い込む〉ことでした。ユーザー企業は何もしなくてもいいから〈SI’erに全部おまかせ〉が基本コンセプトだったのです。
メインフレームという大型コンピュータ全盛の当時、高額なメインフレームを販売した利益はとても大きかったので、SI’erはユーザー企業の要望に応えるために、SE（システムエンジニア）をユーザー企業に常駐させることが許された時代でした。
しかも当時は電算化する業務も財務会計システムなどシンプルなものでした。だからこの日本型SIビジネスモデルは実にうまく機能し、1980年代のジャパン・アズ・ナンバーワンを支えるに至ったのです。
しかし時代の歯車は逆転しました。厳しくなる一方のビジネスを取り巻く状況のもとで、過酷な短納期とコストカット要求の嵐の中、SI’erは進化し続けるテクノロジーをキャッチアップするのに精一杯です。納期の面からもコストの面からも、顧客の複雑化した業務を理解する余裕はありません。顧客と同等以上に業務を理解するには、SEがその現場に常駐するしかないのです。
その一方でゆりかごから墓場までSI’erに丸投げが常態化したユーザー企業は、自ら企画書や業務マニュアルを書く力を失っていきました。いかに業務を知っているはずといえども、業務マニュアルを書いたことがない人には、業務マニュアルの書き方がわからないのは既に申し上げたとおりです。
このようにしてITベンダーに丸投げが常態化したユーザー企業には、企画立案はもとより業務マニュアル（業務要件定義書）を書く力がありません。かたやSI’erにはユーザー企業に常駐して、ユーザーと同等以上にビジネスモデルや業務を理解する余裕はありません。
かくして日本は先進国にはまれな〈アナログ手作業問題に悩む国＝ユーザー企業＋SI’erによる総体としてのITガラパゴス〉に凋落していったのです。
『デジタル敗戦国』と似たような意味で、日本のDX（デジタルトランスフォーメーション）は海外に比べて周回遅れと揶揄される問題があります。しかし率直にいってアナログ手作業問題に悩んでいるうちは、（本稿における定義による）DX推進に着手するのは難しいと思います。
この日本企業の主流がビフォアーDX問題は、連載第2回目で取り扱う予定です。
状況変化への適応を試みる〈ユーザー企業＋SI’er〉
この事態を重くみたユーザー企業の中には〈内製化〉と呼ばれる、自分でつくる活動に舵を切る企業群が存在します。さらにスタートアップは自由です。日本型SIビジネスモデルに頼る必要はありません。
しかし50年にもわたる商習慣や取引契約、法規制のうえに築かれた〈大企業を中心とするユーザー企業＋SI’er〉は今日においても日本経済の中核です。一朝一夕に作り変えることができません。
それがあって内製化についても、大勢としては動きが緩慢であるように思えます。ボクはITシステム開発にとっても、失われた30年が重くのしかかっているのだと考えています。
しかしそもそも〈ユーザー企業＋SI’er〉という対概念であるとか、内製化という言葉自体が日本にしか存在しないのです。海外の大企業は〈企画立案〉をはじめとして〈業務要件定義（業務マニュアル作成）ーIT要件定義ー設計ー実装ーテストー運用〉の一連の活動において、自分でつくり運用するのが当たり前です。
実装やテストなど大量の工数が必要な工程では、インドなどのオフショアベンダーにアウトソースすることがあるのです。ボクも内製化というか海外企業型が〈あるべき姿〉だと考えています。
一方、SI’erも試行錯誤を続けています。たとえばオーダーメードで、ユーザー企業の要望に緻密に細かく応える〈作りこみ型のソリューション提供〉を可能な限り避ける努力を続けています。顧客ごとに作ることを回避して〈レディメードの既製品〉を、クラウド上にSaaS型で提供する形に変える努力を続けているのです。
しかしオーダーメードの要望がなくなったわけではありませんし、レディメードでもカスタマイズ要求がなくなったわけでもありません。だからSI'erと協業するにせよユーザー企業が内製化の第一歩として業務マニュアルを自分で作る本来あるべき姿に向かうことが、問題のボトルネックを解消するクリティカルポイントであるとしたのが第1回の結論です。
これは今日から解決に着手できる問題なのです。冒頭で申し上げたとおり、この問題の解決自体はたいしたことはないのです。なんといっても100%、自分たちでコントロールできる問題なのですから。
5. スケールの大きな問題と向き合う
しかしデジタル敗戦の背景には〈スケールの大きな問題〉が隠れています。
スケールが大きいの意味はいくつかあります。ひとつには長い時間をかけた蓄積や変化の結果、起きた問題という意味でのスケールの大きさです。〈時間的なスケール〉のことです。それだけ時間をかけて起きた問題という意味で、問題の大きさも大きくなります。つまり〈問題の大きさ〉という意味でのスケールの大きさがあります。問題の大きさが大きければ、その〈解決の難しさ〉という意味でのスケールの大きさもあります。
スケールの大きな問題とは社会の仕組みや価値観の変化のこと
何が変化するかといえば、社会の仕組みやボクたちの価値観です。図表1.9はよく知られている世代を特徴づけるネーミングと誕生年です。世代間の相互理解の難しさが話題になることがありますが、それは世代ごとに主流となる価値観が違うからです。
では社会の仕組みや価値観を変化させるものは何でしょうか。本稿が注目するのは〈テクノロジー＝IT〉の役割です。
ボクたちはスマホの便利さを知ってしまったら、もう元には戻れません。自宅に居ながらにして買い物ができる便利さを知ってしまったら、もう元には戻れません。Googleの検索エンジンは〈情報を得ること〉を〈ググること〉に変えました。SNSは〈世間との向き合い方〉を大きく変えました。生成AIの登場は〈社会の仕組み〉を根本的に変えかねない勢いです。たとえば教育の仕組みやあり方に大きな変革を求めています。
ボクのような昭和に青春時代を過ごしたおじさんも、知らず知らずのうちに大きな影響を受けています。イーライ・パリサーはSNSなどのITが個人の嗜好性を増幅することで、自分とは異質なことに非寛容になってネット炎上が頻繁に起きたり、相手を無視する〈フィルターバブル現象〉を指摘しました[4][5]。
YouTubeに表示される番組やX（twitter）のタイムラインに流れる投稿は、サービス提供者のアルゴリズムによってコントロールされています。たとえばボクがライティングの仕事にかかわる情報を読んだり視聴したら、ライティングの仕事にかかわる情報ばかりが流れるようになります。
それは便利なことだというお話なのですが、でもそれだけに留まりません。ボクが今度の選挙で「A候補者には正義がないから当選すべきではない」という考えを持ったとします。そしてそのような投稿や番組を好んで読んだり視聴したとします。するとアルゴリズムはボクの嗜好を理解して、A候補者に批判的な情報ばかりを流すようになります。A候補者を応援している人には、A候補者に好意的な情報ばかりが流れるようになります。つまりITが個人の嗜好性を増幅するのです。その結果、社会的な分断が起きているというのがパリサーの指摘です。
本題に戻ります。本稿が注目するスケールの大きな問題の一例を既に述べました。1980年代から形を変えずに存続している〈ユーザー企業のビジネスモデル＋日本型SIビジネスモデル〉は、当時の大企業のニーズや社会の仕組みに最適化されたものでした。
しかし失われた30年はあまりにも長かったのです。その間にボクたちの社会の仕組みや価値観は激変しました。ボクは日本型SIビジネスモデルがビフォアーDXのニーズに応えることで、いまも日本経済の中核に存在し必要とされていると考えています。なぜならばユーザー企業のニーズの主流がビフォアーDXだからです。
しかし米国を中心とする海外企業の影響で、ボクたちの社会の仕組みや価値観、ニーズは激変しました。だから日本経済の中核がビフォアーDXの状況で安定しているとしても、いまの社会の仕組みや主流となる価値観とは大きなずれが生じています。
だからボクは新しいビジネスモデルを自分で作るプラクティスに向かうべきだと考えています。アナログ手作業問題が業務マニュアルを自分で作るプラクティスで解決できるように、このスケールの大きな問題の解決に、時間がかかるにしても取り組むべきだと考えているのです。
連載第2回では、米国発のDXがどのような進化をとげ、ボクたちの価値観やニーズにどのような影響を与えてきたのか。それに対する日本の現状はどうあるのかをテーマに書く予定です。
ここまで長文を読んでくださってありがとうございます。第2回でもお会いできれば幸いです。
出所
[1]マイナンバーカードについて岸田内閣総理大臣記者会見（全文）https://www.jimin.jp/news/press/206429.html
[2]世界の１人当たり名目GDP 国別ランキング・推移（IMF）
https://www.globalnote.jp/post-1339.html
[3]電子国家「e-Estonia」へようこそ
https://e-estonia.com/wp-content/uploads/2828-e-estonia-introduction-presentation-jap-estonian-design-team-19121622.pdf
[4]『情報環世界』渡邊淳司、伊藤亜紗、ドミニク・チェン、緒方壽人、塚田有那ほか著、NTT出版2019年
[5]『閉じこもるインターネット』イーライ・パリサー著、井口耕二訳、早川書房2012年
連載記事一覧
[連載04]押しの経済時代のエフェクチュエーション
[連載05]生成AIは神か悪魔か？芥川賞作家の神回答がツボにはまった件
[連載06]劣等感の真実
[連載07]こたつ記事ライターのエフェクチュエーション① - 絶望感を克服して愉しく生きる方法
[連載08]こたつ記事ライターのエフェクチュエーション?- 収入の不安定さをコントロールする
[連載09]こたつ記事ライターのエフェクチュエーション３：目的や目標ではなくて手段からはじめた方が幸福になれる理由
[連載10]幸せの青い鳥の原則
[連載11]noteとクラウドソーシング、こたつ記事ライターがめざすべきなのはどっち？
[連載12]noteがブルーオーシャンになる理由
[連載13]新しい記事を書くってなんでこんなに愉しいのだろうか？
[連載14]ライターが「やりがい搾取」を感じるとき
この記事が参加している募集
この記事が気に入ったらサポートをしてみませんか？