DXの本質をなるべく簡単に語ってみる

最近、いろいろな企業とDXの話をすることが多いのだけれど、本音ベースになったときに結構「DX（デジタルトランスフォーメーション）が重要と言われてやらざるを得ないが、実はいまひとつ、ピンときてない」という方が多いんですよ。

仕事は楽しくしたいよね

それで、ちょっと僭越ながら「単純化して、こう考えたらどうでしょう？」という話をしますね。ちなみに僕は授業でDXの講義をしたり、とある地方自治体のDXアドバイザをやってたりしてて、一応、理屈としてのDXも現場のDXもそこそこわかってるつもり。

さて、突然ですが、たとえば皆さんが定期的に友人と飲み会をしてるとします。その時に一番大変なのは日程調整で、LINEなどを使って「いつにする？」「自分は〇月〇日ならOK」などとたくさんやりとりして、やっと調整がついているとします。これって、たとえば電話をかけあってやりとりするような方法と比較すれば、一応デジタル化ですね。だけどまったく非効率。

積極的に調整幹事をやってくれる人がいるともうちょっとまともで、ネット上のスケジュール調整ツールを使って「じゃあここに候補日程をあげたので、皆さん〇△×で回答お願いします」とかやって、〇が多いところに決める。これはちょっと効率化されてます。

さて、この頻度があがって幹事も面倒なので、これをもう少し効率化したいとします。たとえば、みんなが日常的に使うスケジュール管理をGoogle Calendarに統一して「飲み会仲間」登録をしておくと（お互いのスケジュールは見えない）、前の飲み会から半年くらい経ったころ、全員のスケジュールで夜が空いているところがあると、みんなのカレンダー上で候補日が少し目立つ色になって、メンバーが全員が気が向いて「いいね」ボタンを押すと成立。こういうシステムがあったとすると、誰も調整幹事をやらなくてもちょうどいいところに設定されます。

最後の方法は、もしそういうシステムがあったとするとわりと便利ですね。3つ示したどの手法もデジタルなので「デジタル化」ではなくて「情報の流れの変革」。よく「DXはデジタル化ではなく、（デジタル）業務変革のこと」と言われるのはそういう意味です。ここではカレンダー調整を例にしたけど、在庫管理も財務管理もすべて同じです。複雑になるほど、変革の効果は大きい。

これを一般化すると、DXをやるには何が必要でしょうか？最初にやるべきなのは、「どういう情報をやりとりして、最終的に何を実行する必要があるのか？」という情報の流れの整理です。具体的に言えば、「飲み会日程設定 ＝ みんなの空きスケジュールを検索して、その結果が合致する日程を候補とし、全員に提示し、みんながOKを押したら確定すること」という整理をすることです。この例なら誰でもわかりそうだけど、たとえば在庫管理・発注・財務管理などを連動させようとするとまじめに整理が必要。だけど、本質は同じです。だからDXでやるべき最初のことは「情報の流れの整理」です。

さて、実はこれよりもっと大事なことがあります。それは「すばらしい仕組みに聞こえるけど、結局誰も使わない」という結果にならないようにすることです。それは「みんな使ってね」としつこく言うことでしょうか？　違います。

「DXの課題はUXである」という言葉を聞いたことがあるでしょうか？UXとはユーザエクスペリエンスです。要するに「それを使ったときに、利用者はどういう体験をすることになるか」です。

そう、さっきのストーリーで設計してセキュリティ的にも完璧なシステムができたとして、すべてが破綻するかも知れない最後のポイントは、ものすごく微妙な、利用者の「感覚」です。たとえばさっきの例で、「なんとなく目立つ色になった日に、いいねボタンを押す」というところが「ときどき候補日がカレンダーにポップアップして『OK』『キャンセル』のどちらかを押す」といううUX設計になっていたとします。ちょっとうっとおしくないですか？「うっとおしいからポップアップをオフにしよう」とかなったりますね。

そう、完璧につくったはずのシステムでも、たとえばこれですべて破綻します。「せっかく作ったのに誰も使わない」ということが起きます。

この「ちょっといや」というのは不思議なもので、人間というのは、「このアイコンをタップしてアプリを開くのがなんか面倒」とか「ボタンを押して画面が返ってくるのが微妙に遅くて（それも0.2秒とか）待つのが面倒」というだけで、そのアプリを使うのが嫌になったりします。ここがわかっていない人が多すぎる。

世の中には、「情報の流れの整理もアプリの開発もすべて完璧にやって開発したのに、UX設計だけがちょっと甘い」というシステムが、よくあります。これで全部破綻する。だから、UX設計がきちんとできていないシステムは、どんなに完璧でも無駄になります。

そして最後に、実はもっとも重要なことを言うと、このUX設計をしっかりやろうと思っても、システム開発の最後のフェーズでは間に合いません。やるべきタイミングは、一番最初です。しかもその段階でシミュレーションしたものを利用者に使ってもらったりして、根本的な部分をしっかり固めておく必要があります。なぜなら、それがシステムの全体設計（専門的には、システムアーキテクチャと言います）の根幹にかかわってくるからです。たとえば「データをアプリの中に保存するか、クラウド上に保存するか」という点を変えるだけで、アプリを操作したときの応答が0.2秒くらい違って、その遅れが使いやすさに決定的な影響を与えたりします。全部できあがった後で「ここを0.2秒速くしたいんだよね」と言っても、そのために必要なデータを通信する時間が必要で、もとのシステム構成ではどうやっても無理だったりします。だから、「ここは、次の画面を表示するまで0.6秒かかっても大丈夫か、あるいは0.4秒以内でないとまずいか？」というようなUX設計を最初の段階で確定しておかないと、データをアプリの中に保存するかクラウド上に置くかという重要なシステム設計さえも決まらないのです。

というわけで、最初はもう少し簡単に説明できると思ったわりにちょっと複雑になってしまった気もしますが、ちょっとでも「なるほどね」と思っていただけたらうれしいです。