今日から始めるデジタルトランスフォーメーション(DX)
DXってなに？
DX、デジタルトランスフォーメーションのやり方を書き付けておきます。これは特に成功事例があるとかではなく、このようにすれば理屈上はうまくいくんじゃないかというアイデアレベルのものです。
そこで最初にDXって何？というところの意識合わせをします。これは筆者と読者の意識合わせでもあり、DX推進者と遂行者の意識合わせでもあります。
世の中にはDX推進者の数だけDXの定義があります。これは誇張なく、誰もが思い描いているDXのあるべき姿が違うという意味です。ですから、これをきっちり合わせこまないとDXは実現できません。特に、DX推進コンサルタントなどではこれが顕著で、その後につながるビジネスだとか利害関係だとかがどうしてもDXの定義に贅肉をつけていきます。この稿では可能な限りビジネス的な思惑とか利害関係を排除しぎりぎりにまでそぎ落としたDXを定義し、それを共有してやり方を考えたいと思います。
ここでは、DXは「ブラックボックス化したシステムに業務を追従させることでプロセス上の判断を一切せずに業務を遂行し人的リソースを非システム化領域の判断に集中させること」としておきます。
何言ってるのかよくわかりませんね。であればいっそデジタル化による顧客満足がどうのこうのなんてお題目を並べておいたほうがよいくらいですが、そのようなお題目に従うと「DXをやれば顧客満足は上がる」が前提となり、万一顧客満足があげられなかったとき、それはDXの失敗だと定義しなければならなくなります。それは違うと思うんですよね。
同様に、DXの目的を「業容の変革」と説く人もいますが、それもまた違います。究極的には企業の目的は利益を上げることですから、業容を変えなくとも利益が上がっていたら変える必要はないし、業容を変えた結果かえって利益が減ることも考えられます。何より、誰もかれもがDXで業容変革、と言い始めると、おそらく似たようなビジネスモデルの真っ赤な海にあらゆる規模の企業がひしめき合う地獄を作り上げてしまいます。業容を変えよう、というのは、利益を得るための手段であるはずで、業容を変革させることを目的にするのは、まさに手段の目的化。
そうではなく、システムに従うことで非システム領域に向かう人材を増やす、仮に市場の急激な変化が予測された場合でもシステムにお任せしておくことで苦労せずに業容の変革を含む会社の改善改革が進められるような組織にしておく、これがDXです。
こうしたことを実現するために、まず「システムに従う」というマインドがあるかないか。DX成功のカギはこの一点です。ですから、DXの出発点を「ブラックボックス化したシステム」としています。そして、「判断するな」ということです。システムは常に正しい答えを出すと信じることです。最後に、「そうやって余剰が生まれた人的リソースを全力でシステムでは判断できない領域に突っ込め」です。
たとえば、どうやれば顧客満足を上げられるのか？ あるいは、顧客満足をくみ上げる指標、その先行指標、後続指標はどんなものがあるか？ といったことを考えること。こうしたことを人が考え、そして最後はそれをシステム化し、ブラックボックス化することで業務はまた一段と自動遂行に近づき、さらに多くの非システム化領域をカバーできるようになります。
もちろん、顧客満足だけではありません。論文を書くのが仕事なら論文添削システムに従う。論文添削システムは昨今の査読傾向を分析して適切な添削ができるようにアップグレードしていく。航空管制ならサインを出すタイミングをすべてシステムが制御し管制官は無判断でサインを出す。事故事例や新型機材の情報をもとに管制システムをアップグレードする。
とはいえどうしても「人間が判断しなければならない」ものは残ります。航空管制なんて良い事例です。あえて例に挙げましたが、こういうのはたぶん法的にやっちゃダメな例です。しかし、こうしたごくまれな例を除けば、多くのことがシステム化できるはずですし、昨今、システム化されていない業務はほとんど無いと思います。
作るな、使え (Don't make, use)
大切なことなのでもう一度書きます。「昨今、システム化されていない業務はほとんど無いと思います」。
それは、過去に誰かが業務をより効率化しようと考えに考えた末に導入したもののはずです。あるいは、そうした様々なノウハウが詰め込まれたパッケージシステムかもしれません。いずれにせよ、そのシステムは業務を適切に進めるためのノウハウが詰まっているはずです。もしそのシステムの外に判断をしなければならないことがあるのだとすると、それはそもそも無駄かもしれません。
例を挙げます。ある社で、稟議回付システムが導入されました。例えば買い物をする稟議であれば、何をいくつ、どんな理由で、いくらで誰から買うのか、そういった判断に必要欠くべからざる情報をすべて入力することで回付ルートに回すことができる、というものです。もちろん、回付された側も必要欠くべからざる情報はすべて記載されているので、その稟議システム上に記載された情報だけで判断できるはずです。そうした要件を取り込んだうえでシステムを作ったのですから。
しかし、業務プロセスはおかしな方に転がり始めます。ある日、稟議回付が期限までに終わらず、重要な稟議が可決しなかったがために事業影響が出る、という事件が起こりました。これは完全に被回付者、つまり上位権限者の責任です。しかしこの事件の振り返りの結果、「稟議回付前に上位権限者全員にいつどんな稟議が回されるかをリスト化して送るように」という業務が追加されました。エクセルで（笑）。もちろん、下書き中の稟議リストを表示したり、本稟議前に予備稟議を上げて事前予告する、そうした仕組みも稟議回付システムは持っていました。でも、エクセル（笑）。上位権限者が「回付稟議がある」というメールを無視し、稟議システムを開かなかったことの対策が、これです。もう予想はついていると思いますが、しばしばエクセルファイルはロックされ編集できなくなり、あるいはファイルが破損して一週間ほど時間が巻き戻る、そうした事態が頻発し、そのたびに社員は無駄な作業を何度も繰り返し生産性は落ちていきました。
また別のある日、全社コスト削減施策として、「稟議を回付していいかどうかの判定会」が設けられることになりました。その稟議が会社にとってどのくらい重要なもので、どのくらいぎりぎりまでコストを下げているか、そうしたことをパワポを使って切々と訴える陳情会です。関連部門の責任者全員を集め、各部門の部長クラスの人が、その会で役員クラスの人に陳情するんです。部長決裁レベルの金額の稟議でも。そこでOKが出たら、稟議書の備考欄に「判定会可決番号」を記載して稟議回付。判定会可決番号がない稟議は却下する、というルールになりました。そう、もともとどんな理由でどのくらいの金額がかかるか、そういった必要な情報は入力されていて、稟議回付ルート上の権限者が適切に判断をすれば問題ないものを、わざわざ謎の陳情会を開くことになったのです。その後、全案件判定会にかけるというのはやりすぎということになり、金額により「判定会」「判定会分科会」「予備判定会」等々、かけなければならない判定会議は細分化していきましたが、金額が大きければ下位の会から順次諮問していく必要があり、例えば一千万円以上の稟議であれば、部門内で承認を得てから稟議回付をするために最低二か月かかる、というとんでもない事態になっていきました。当然会社の判断はどんどん先延ばしとなり、割を食うのは顧客です。
もともと、システムはそれなりの機能を備えています。にもかかわらず、システムの利用を誤る、システム外に業務プロセスを増やす、こうしたことがどんな業務でも当然のように行われています。最終的には、システムを無視してシステムの外で業務プロセスが行われ、システムは単に記録を残すために使われるということになります。上述の稟議システムが良い例で、回付待ち稟議のリストを人力で作成して送り、稟議内容を階層ごとにパワポで説明して了承を得ていき、最後に稟議システムに入力した後は決裁権限者は判定会の可決番号が入力されていることだけを見て決裁する。これでは、システムを導入した意味がゼロです。もうお分かりかと思うので白状しますが、上述のバカげた仕組みは私が昔いた会社で実際に起こっていたことで、私はある日、ふざけて稟議本文に嘘八百を書いてみましたが、問題なく可決されました（さすがに金額にまで嘘は書きませんが）。その瞬間、システムは死んだのです。
必要なのは、新しいシステムを作ることではなく、今あるシステムを正しく使うこと。システムを使いこなすというマインドを上から下までいきわたらせること。これがDXの入り口です。これがない限り、DXは決して実現できません。
DXで業務革命ができるのはなぜ？
今あるシステムを使うだけでは業務革命は起こせない。当然誰でもそのように思います。そのために、DXの専門部門を準備したり、DXに向けたシステム構築を始めたりするわけです。DXを始めるにはDXを始めなければならない。今多くの会社で叫ばれているのは、一言でいえば、これ。この進次郎構文でDXが進んでいます。
違います。DXをやろうと思うのであれば、まず、DXから一番遠いところから業務改善を始めなければならないのです。つまり、システムを使いこなせていない事業部門から、です。
システムを使いこなせないのはなぜでしょうか。バカだからでしょうか。これも違います。バカになり切れていないからシステムを使いこなせないのです。「システムより俺たちのほうが偉い」というおごりがどこかに残っています。こういうところは、DXから一番遠いところです。実際、定型的な業務しかサポートしていないシステムより、どんな業務にも柔軟に対応できる人間のほうがはるかに賢いのは事実です。そうした業務は「聖域」としてシステム化せず職人への属人化を残しましょう。私の考えは、そうした聖域こそ人間の出番であり、属人化大いに結構、だと思っています。しかし、そうしたおごりたかぶりをシステム化された領域に持ち込むな、ということです。システム化された業務に関してはバカになり切る、これができる人はそうそういないと思います。業務依頼をやり取りするシステムがあるのに「俺がちょっとあっちの上に掛け合ってきた方が早い」とドヤ顔でカバンを持って飛び出していくおっさんは、DXの敵です。
ということで、バカになり切ってシステムを使いこなせ、ということ。これを上から下まで一貫すること。
しかしこれがなぜ業務革命につながるのか。
簡単です。完全にシステムに寄りかかって仕事をすると、システム上の不備に気付きやすくなります。無駄な手続きを見つけられます。顧客の本当の声を反映するためにシステムに施す改善策を思いつきます。そうした声を集め、システムを改善していくのです。そして実のところ、世界的な大手と言われる業務システム屋のシステムは、世界中のそうした声を反映したシステムのアップデートを毎月のようにリリースしています。自社開発のシステムなら、情シスに声を上げることで改善されますから（情シスに業務プロセス介入を含む絶大な権限と予算を与えることが前提です）、改善されたシステムに従って全社員が業務を進めることで一つの改善要望の声が全社の業務効率を上げます。大手システムであれば、バカになり切ってそのシステムに従ってすべてのプロセスを進めれば業務プロセスが常に世界レベルのアップデートを受けている状態になるわけです。
かつて、80年代から90年代、日本の企業で行われたオフィスオートメーションはすべて「業務の一部をデジタル化する」という方向で行われました。人が作った業務プロセスの一部をコンピュータに代替させる、というものです。実のところ、昨今の業務システムはまだこの延長線上です。この部分の情報のやり取りだけを簡便にしたい、この部分の記録だけを自動化しておきたい、そういった使い方なので、業務改善と言えば紙の上で絵をかき会議で議論するもの。十分な費用対効果がありそうならシステム化を検討する、という程度です。しかし、DXでやらなければならないことは、「システムから外れたことをするな」「変えたければシステムを変えろ」です。システムを主役とするのです。2000年代初めにSAPなどの黒船が来航したとき、日本の大手企業はこぞって「システムのカスタマイズ」を始めました。業務プロセスにシステムを合わせていったのです。当然、いったんカスタマイズしたシステムは国際的なアップデートから取り残され、苔が生え錆びついていきます。SAPに出会ったとき、取るべき態度は、「国際的な成功事例を集めた業務システムにわが社の業務プロセスを合わせこめば、わが社も国際的な競争力のある会社になれるのではないか」……これだったはずです。
話がそれていきそうなのでこの辺にしておきますが、DXとはデジタルによる変革であり、それは、高度化したシステムに業務プロセスの判断の多くを委ねてしまい、システムそのものをさらに高度化することで無理なく業務変革を成し遂げましょう、ということなんです。DXの究極形は、すなわち、ブラックボックス化したシステムであり、システムの無矛盾性に完全な信頼を置いて業務を遂行する社員なのです。そのうえで、このシステムの内部にAIを使ったマーケット予想だとかなんとかをばれないように組み込んでいって判断の質を上げていく。社員は何もしなくても改革は静かに進んでいきます。
では、今日、何をしよう？
では、今日から、全社員に「システムを完全に信頼せよ」「システムに反した行動をとるものは反乱者として処刑する！」なんていうディストピア通告を出すのは待ってください（笑）。システムは変われますが、人間はそう簡単に変われません。
そこで一つ提案です。これが最適解というつもりはありません。もっと良い方法があるかもしれません。ですが、今日始めるのには手っ取り早い方法の一つです。
それは、どこか小さな一部門を「DX特区」として指定することです。この特区部門では、システム上許されているすべての操作が許されます。また、システムの外で進行するすべての業務プロセスを廃止します。そのためにはもちろん、システム化されていない業務プロセスが少ない部門を選ぶ必要があります。
例えば先ほどの稟議回付システムの例でいえば、そのDX特区では、稟議予定リストを事前に作成する必要はありません。判定会議に稟議を付議する必要もありません。決裁権限者は、稟議システムから読み取れる情報からだけで稟議の決裁を行います。稟議内容に疑義があれば、システム上でコメントをつけて差し戻せばよいでしょう。こうした手続きが多くの部門で一斉に行われれば決裁権限者はパンクしてしまいますが、今はまだDX特区からの稟議だけなので、何とか回せるはずです。
社内のシステムでは、実は有効利用していないものもあります。会計・財務の総合パッケージを導入しているのに、実際は購買申請にしか使っていない、などといったケースです。そうしたシステムで許されている申請はすべて許します。また、よくあるパターンですが「システム上〇〇が入力できてしまいますが入力しないでください」というのもダメです。入力できるものは入力を許します。なぜなら、そうした一見無駄に見える入力一つ一つに、そのパッケージの他のユーザのノウハウが凝縮されているからです。入力を受け付ける側、例えば購買の例でいえば購買部門のようなところは、そうした入力や、受け付けたことのないシステムからの申請に混乱するかもしれません。でも、それをどう扱うか、「自分がシステムにどう使われるか」を、しっかりと訓練してください。大丈夫、DX特区はまだ小さいので、十分にさばききれるはずです。
もちろん、DX特区の社員は、システムをとことん使いこなしましょう。システム上でできることはすべてシステムで。仮にシステムの主幹部門からのお達しに「その申請はシステムではなくメールでお願いします」と書いてあっても、それに従う必要はありません。システム上許されているすべての操作が許され、システムで可能な業務をシステム外で進行することは禁止されているからです。
こうして、DX特区を起点にして、社内のいろんなところに「システムに使われる」というマインドを浸み込ませていきます。システムに使われるということは、システムを完全に使いこなすということと同義です。
こうした中で、システム化されていない業務や、他のシステムとの連携業務などが浮かび上がってきます。同時に、どこまでがそのシステムのカバー可能な範囲かも浮かび上がります。主幹部門では、そうした例をどのように扱うのかを検討します。昨今流行りの「DX専任部隊」のような特務部隊が出てくるのはようやくここからです。システムの間の三遊間をカバーするためのシステムを自作したり、重複している部分の橋渡しをしたりするために、デジタル技術を思う存分に振るいましょう。
つまり、サイクルはこうです。
DX特区でシステムを徹底的に使う
使われた側で対処に苦慮する
苦慮した対処をシステム化する
DX特区で行われる業務がほっといても勝手に進むようになれば、第一段かい終了。DX特区を別の部門に広げましょう。そして同じことを繰り返すだけです。
DXは大変です。簡単ではありません。でも、やり方は見えてきたのではないでしょうか？ 一足飛びに流行りのシステムを導入してもDXは成功しません。なぜなら、一番大切なのは「社員のマインド」だからです。「ブラックボックスのシステムを使いこなす」≒「システムに使われる」というマインドがとても大切です。誰もがこのマインドを持てば、ある日システムがしれっと新しい情報を要求してきても「あれ、これ入力しなきゃいけないんだ、オーケーオーケー」と入力してくれるようになります。実はその情報、社長が来年度施策の取捨選択をするための非常に重要な判断に使うものかもしれませんが、そんなクドクドとした説明さえ不要になるわけです。何より、そうした予備情報を与えると、結局行きつく先は「陳情会」です。DXではありませんね。最終的には、そうした情報を山のように積み上げ、ビッグデータ＋AIで取るべき戦略の方向をアドバイスしてくれる、そうしたものを導入することも容易になります。まさに、DXが目指しているもののはずです。
DXで何をしたいのか？ なんてことを考えている暇があったら、今あるシステムを徹底的に使いこなすところから始めてみましょう。
まとめ
DXは「システムに使われること」である
システムに使われることを全社員に浸透させることで、絶大な権限を持つ情シスによるシステムの改善が即業務の改善となり、業容の変革となる
はじめの一歩は「DX特区」の導入である
この記事が気に入ったらサポートをしてみませんか？