私は以前、DXの企画屋でした。新規事業だったり、コスト削減だったり目的は様々でしたが、今ではDXと呼ばれている方面の様々な企画を立てて、“パワーポイント”の資料を量産し、関係者に話を通して企画に関する合意をまとめることが仕事でした。ただ、合意をまとめた後は「実行はビジネス部門の担当ね」と自分の手を離れていきます。そして、自分の立てたDX企画がそのまま実行に移されたことは一度もない（少なくともそのまま実行されたことは）という事実に気付き愕然としました。
なぜか？ 一言でいえばDX企画が全て「絵にかいた餅」だったからです。例えば、カメラ付きデジタルサイネージでは、画像認識を使えば通行人の性年代別に広告画面を出しわけることができるはずですね。そういう企画をしたこともありました。結果、うまく行きませんでした。その時は画像認識で性年代が判別できる距離にまで通行人が近づいてくれる状況ではなかったそうです。事業部も強い興味を持っていたので、ITベンダに委託して数か月かけて実験したそうですが、結局うやむやのうちに企画ごと無かったことになりました。
このようなDXの企画の立て方は、今から思えば根本的に間違っていました。この記事の結論でもあるのですが「DXの企画段階において試行錯誤のプロセスは決して外注してはならない」ということだったのです。
外部のベンダにDX企画に関する実証を依存するということは、失敗（＝学習）の機会が失われるという問題があるのですが、高尚な議論抜きにしても単純に時間がかかり過ぎます。外部のベンダに仕事を投げたことがある人なら分かると思いますが、仕様書を作成して、外部のベンダを呼んで企画を口頭で説明して、相見積りを取って、企画書をもらって、企画書を評価して、契約の条件交渉をして、ということをしている間に１～２か月は軽く空費します。そして外部ベンダさんはそのDX企画の実証実験を行った後、必要以上に丁寧な報告書を作成することを余儀なくされます。発注側社内の意思決定上は、「この方法はこういう理由でダメだった。次試すならこの方法にすべき」という２～３行の結論で十分なのですが、それでは調達部も国税も納得しません。「高い金を払ったのだから」と折り目正しい報告書を作成させ、DXうんたら企画会議の関係者も招いて報告会をしたりします。報告会の日程調整でさらに最低１週間は無駄にしますね。ところが一連の外注プロセスの中でDXの企画にとって本当に価値があるのは「実証実験」の部分だけで残りの部分は全部時間の無駄です。
そしてこのような実証の結論は「このままでは企画は上手くいかないが、こういう方法で試せば上手くいくかもしれない」であることが非常に多いのです。ただ、こんな結論を導くのに３か月も空費していては、どんなDX企画も前に進むはずがありません。もし自分で実証ができれば、外部のベンダと契約を結ぶまでの時間で実証実験を３回転はさせて、企画がうまくいく方法を見つけ出していることでしょう。
もう一つ課題を指摘すれば、実は外部のベンダも社内で作業をしていないことがあります。以下の図はSNSでよく目にしますが、特に大手のSIerに委託する場合は、この絵は99％正しいです（残り1%は運よく個人的に技術力を持つ人に当たるケース）。大手のSIerの社員は新卒入社時から「外注を手配するのが単価の高い当社社員のお仕事」と刷り込まれ本気で信じて疑っていない「システムエンジニア」ばかりです。一体なんのエンジニアなのやら・・。いずれにしても、外部のベンダを使ってDX企画の実証をするのは、時間の面でもお金の面でも無駄でしかありません。
日本の多くの企業も官庁もデジタル活用／DX化の波に完全に乗り遅れたと言われていますが、上記のような企画の進め方の問題が大きいです。DX企画を立てる人が実際には技術がわかっていないので机上の空論に走ってしまうという問題です。本気でDXを進めるためには、企画段階で重要な技術課題を潰しこむ必要があるのです。
とはいえ自分の意のままに動いてくれる研究者やエンジニアさんが身近にいますか？ 仮に立派な研究所をお持ちの大企業に所属していても、あなたの意のままに動いてくれる研究者が身近にいて、いつでも自由にお願いできるという人はほとんどいないはずです。つまり、ある程度の実証実験はあなた自身でやれなければいけない、ということです。
では問題は、はたして素人が自分でDXの実証実験やら技術開発やらが可能かということです。これに対しては私の実体験として「自分で技術を触ることは可能である」と断言できます。私自身、大学に在籍していた2000年前後は理系の学生だったので指導教官の下で卒論を書くため、よくわからないままWindows CE（知らないでしょ？）端末の上で動作する実験用のプログラムを書いたことがありました。しかし、当時もサーバ系の知識は１ミリもありませんでしたし、その後、社会人になってからは一貫してパワポ屋さんだったので、技術知識は錆びついたまま止まっていたわけです。この５年くらいDXのため（というよりは個人的興味が強かっただけですが）一念発起して様々な技術を学びなおしました。そこで分かったことですが；
- 学問に王道はないが、DX企画の実証程度が目的なら王道がある
- 最近の計算機はサーバもPCもマイコンも似通っていて、わりと潰しがきく
- やっているうちに楽しくなってきて、素人もそのうち本物になってしまう
一つ目の「王道」に関してですが、完成形で動作するシステムを微調整して挙動を試すことが最速の理解につながる、というものです。教科書を読んで１行目からコードを書き進めるというのは素人には時間の無駄です。動くコードやシステムのパラメータを変えてみながら、どういう挙動を示すのか試すことで一気に理解が進むというのが私の経験です。
二つ目の「潰し」についてですが、私が学生だった2000年前後はマイコンやPCやサーバなど計算機環境ごとに、利用可能な言語から開発環境まで全く違う状態でした。しかし、最近のハード・ソフトの進化のため、多くの種類の計算機上でPythonだったりPHPだったりといった言語が共通的に動作します。コードを書くならとりあえずPython だけ、あるいはPHPだけ覚えてしまえば、それなりに何でも作れてしまいます。
三つ目の「本物」について、学生の頃「この人は化け物だ」と畏敬の念を抱いたスーパーエンジニアの方を知っていました。当時だれでも知っている有名なメールソフトを一人で開発した人で、PCのソフトから組み込みソフトまで何でもこなすスーパーマンでした。「どうやったら、こんな人が出来上がるのだろう？ きっと長い間、刻苦勉励してこうなったのだろうな」と思っていました。現在は、私自身もスマホアプリからクラウドを駆使した様々なシステム、電子回路から機械設計に至るまで１人で何でもこなせるようになり「あの人」に少し近づけた気がします。ただ、ここに至るプロセスは全く思ってもみないものでした。刻苦勉励とは程遠く、楽しんで来ただけなのだと。「近道」をたどりながら「潰し」が効くようになってくると、色々な物が作りたくなってきます。それを作っていく過程でどんどん知識が広がりいつの間にか「本物」になる、というカラクリだったのです。
このブログでは、私自身の体験に基づき、読んで下さる多くのDX企画屋さんが、実際に王道を通って、潰しが効くようになって、最終的に本物になってもらうことをご支援していきたいと思っています。このために、「そのままでも使える具体的なビジネスアプリケーション」を前提として「動作する完成形の作り方」を詳しく載せていきたいと考えています。実際に動くシステムを触りながら、パラメータを調整したりコードを書き換えてみたりしながら、自分のモノにしていって頂ければ幸いです。