デジタルとビジネスの類似性

日本はDXから周回遅れ、と言われている。様々な業務において、コミュニケーションやフローの方法が旧いままで、大幅な改定・刷新といえる社会的な転換や、そういった製品なかった状況を言い表している。

大幅な改定・刷新というと、何かものすごいチャレンジングな事の様に思える。現状を否定し、真新しい概念を提示したうえで、それを体現する高い生産性を生み出す仕組みや、チームを創出する、そんなイメージだろう。

しかし、エンジニアの立場からするとそれは絵に描いた餅だと思う。

エンジニアが新しい機能を実装するとき、まず最初にプロトタイピングを行う。まず目的があって、それを実現する必要最小限のコードを書く。あるいは、既存のコードが無いか、その目的とする機能のキーワードを頭の中から捻りだし、検索して、他者の公開しているコードを流用する。そうしてベースとなるプロトタイプコードを生み出す。誤解を避けるために言及すると、プロトタイピングとはいっても、機能を求めている人にとってはこの段階で満足するレベルのものである。リリースしようと思えばこの時点でリリースして使った頂く事は可能だ。

実際プロであっても、ここで手を止めてしまうエンジニアは沢山存在すると思う。

そのあとは改善の繰り返しである。たとえば、コードの中に埋め込まれたマジックナンバーをまずは定数化し、その次にはコマンドオプションにしたり、ファイルで永続化したり。

そのあとは、プログラムやデータ構造の見直しになる。同じ種類のデータを使う機能群でグループ化してクラス分割したり、あるいは、規格化できそうなデータ構造を新たに型定義して、どのモジュールからも安全にデータアクセスできるようにする。

つまり、表面的には1日で実現できる機能であったとしても、実際完成するのはその3倍、10倍ほどの時間を要する事が当たり前だ。

エンジニアの世界ではこれをリファクタリングと呼ぶ。表面上の機能的には何も変化はなく、嬉しさはない。したがって誰も望まない作業である。しかしエンジニアは進んでこれに何十倍も時間と手間を費やすのである。

なぜこんなムダな事を行うのか。それは、そのソフトウェアにそのあと追加される機能や仕組みを組み合わせやすくするためである。

一般の事務仕事の現場を考えてみたい。例えば、お客様から商品の見積依頼が来て、それを各商品のメーカ毎に仕入れ価格と納期を問い合わせて、自社の売値基準に照らし合わせ販売価格を決定し、見積書を作成する、というフローがあったとする。

規模の小さなスタートアップであれば、このフローを独りで対応するだろう。依頼された品目毎に納品価格を調べ、売値をどうするかBossに相談しながら決めて、見積回答する、そんな流れである。

実際、それだけで顧客からは満足したアウトプットが得られるのである。

しかし、その顧客が1日に1000件見積対応しなければならないとすれば、とたんに破綻する。都度Bossの判断が求められると、Bossとしての役割は果たせなくなる。何も意思決定が進まないまま、組織は弱体化する。

つまり、見積担当者は見積業務に、Bossは価格の適正化に対する意思決定、という役割をしっかり果たせるようにする業務フローの再構築が必要になる。そのためには以下が必要だ。

• 売値を決めるルール（原価、販管費に対する利益率）に基づいた売値の計算式を決める。
• 原価、販管費の実績を統計的視点で損益分岐点を見える化する。これに基づいて定期的に売値を更新する。
• 見積額はこのデータベースから自動的に出力されるようにする。

こうして見積業務、と呼ばれる販売費工数を極小化し、能力に基づいて適切に役割を定義し、その役割に応じたタスクを割り当てる、といった、業務フローの「リファクタリング」をまず行ってから、適切な業務量に応じた作業者のインスタンスを起ち上げる。これがビジネスにおける変革である。

つまりは、ソフトウェアにおけるリファクタリングと、ビジネスフローにおけるリファクタリングはほとんど似ていると思う。

顧客体験に基づいたDXの理論であるが、実のところ、こうした土台の大幅な改変無しには、その次の 大幅な顧客体験の向上 は見込めないのである。

DXに求められるデジタルスキルとは

ひとことで言えば、「リファクタリングこそコアバリュー（革新的価値である）」という共通認識ではないだろうか。上述の様に、リファクタリングはプログラムコードだけではなく、あらゆる場面で必要とされる。これらすべてが顧客体験に直結するのである。

しかし、この感覚・センスを持つのは残念ながらリファクタリングの恩恵を体験しているエンジニア特有なのである。それが問題の核心だ。

いつまでもビジネス現場ではハンコ、稟議書で意思決定が行われ、過去の業務ログはExcelで情報のサイロ化が起こる。全くリファクタリングが行われないまま数十年を過ごす。壮大な機会損失が行われているのである。

その状態を平然と受け入れていることが、センスやリテラシーを持ち合わせていない事の証左ではないだろうか。エンジニアはその状況を苦々しく見つめている状況である。

リファクタリングは新たな概念を生み出す

リファクタリングという作業は、やった方が良い、程度の改善ではない。業務の流れ、処理（役割）の分析、データの整理、など日本が得意としている5S（整理、整頓、清掃、清潔、躾）を目指すものと同じだ。

これは普段何気なくやっている事を、点検によって新たな本質に「気づく」効果がある。この気付きは最も大きな価値を生み出す可能性がある。なぜなら、新たな商品、仕組みというのはこういった日々の業務の点検作業の中から生まれているからだ。いままでなぜこのようなやり方してたんだろう？ということを掘り下げる事で、「要するにこういう事だよね」を再定義する事だ。

リファクタリングで大事なことは、プロタイプレベルのコードを積み重ねたあと、まとめて行うのではなく、都度都度行う事が避けられない。なぜなら、人間の記憶や規模の大きな仕組みを一度に把握する能力には限界がある。鉄は熱いうちに打て、の世界である。

DXで最も求められるのは、新たなテクノロジーや仕組みを導入する、というよりも、その現場にいる人々が求める機能を素早く提供しつつ、継続的にリファクタリングを行い、常に最適化されたボリュームとシステムをメンテナンスし続けるスキルである。