DX（デジタルトランスフォーメーション）という言葉が流行し、猫も杓子もデジタル化という言葉を使い始めました。さて、デジタル化とは何なのか、そして流行しはじめたのはなぜなのか。
端を発するのは経産省の「2025年の崖」のレポートだと言われていますが、レポート読んではみたものの本題はSAP ERPの保守期限を意識した基幹システムの刷新化と技術的負債の返済であるにもかかわらず、日本企業のスピード感の話だったり、なぜかマイクロサービスとAI、アジャイルサービスなど流行のワードがたくさん出ており、論点がぼやけている印象を受けてしまいました。
基幹システム刷新化においてマイクロサービスなどは一部で使えるかもしれませんが、銀の弾丸とは思いませんし、現状整理によってはきちんとしたデータベース設計とウォーターフォールを主としたロジック移行が最適解であることも十分にありえるといち技術者としては思います。
僕自身はキャリアとして、大企業の40年ほど稼働していたメインフレームの基幹システムの総入れ替えをベンダー企業側（ITコンサル/SIer）や、監査法人の内部で仮想通貨監査のためのブロックチェーンを分析するための開発をアジャイルで行ったなど、トラディショナルな企業で技術的負債の返済や新規技術を用いた業務システムの開発をやってきました。
その経験を経ていると、基幹システムの負債を改善するという大昔からある、それこそ僕が10年ほど前に取り組んだ課題に対して、なぜ今こんなに「デジタル化」、「DX」という言葉を用いて盛り上がっているのかがよく分かりませんでした。
そこでこの記事では、昨今の流行の技術トレンドを捉えて、業務システムの分野において
- デジタルという言葉が流行している理由
- なぜシステム化ではなくデジタル化という言葉が使われているのか
- アジャイルの流行など、管理ではなくコーディングに強いエンジニアが強く求められているのか
について考えを述べてみます。DXという言葉は新規サービスの文脈などで使われることもありますが、今回はあくまで業務システムの分野におけるデジタル化に限った話に限ります。
ウォーターフォールとはそもそもシステム開発だけの話ではない
これまでのシステム化の流れについて振り返ってみましょう。そもそも、ウォーターフォールとはシステム開発の話だけではないと思っています。
上図はよくあったもの（今も？）ですが、1.まず戦略を決める、2.戦略に基づいて業務が決まる、3.最後に、業務要件に基づいてシステム開発が始まる、というものです。いわゆる要件定義というものはシステム開発のボックスの中（あるいは狭間）から始まります。要件定義を上流とするなら、業務改善や戦略は「超上流」工程などと呼ばれることがあります。この上流が全てをきめる、という流れがあったためコンサルティング業界でも戦略コンサルが一番偉く、業務コンサル、ITコンサルの順にえらいという風潮がありました。
実はすでにこの戦略策定や業務改善プロセス自体がウォーターフォールではないか、戦略、業務フローがガチガチに決まった状態でアジャイル開発、としても結果的にできるものは大きく変わらないのではないかと考えています。
技術要素によって業務フローが変わる時代
業務フローをまず決めると、アクターがいて、影響のあるデータを洗い出し、どこに情報を集約するかをBPMNなどで洗い出し、システム設計においてはDFDなどで業務を見て管理のための画面項目などを設計するでしょう。
例えば、アクターである品質管理担当者が、工場で製造した製品について不良品を検査し、原因種別ごとのレポートを集計し製品別品質管理マスタに登録する、といった文言がこの段階で並んでくると思います。この時、愚直にデータとシステムの入力プロセスなどを単純なCRUD（情報の参照/検索/更新）に基づいて起こしていくことは伝統的なやり方でした。
しかしながら、製品の製造検査について、良品不良品は画像処理技術を用いた検査を行うことで、自動的に品質と原因種別を判定、良品率を集計することができるという前提が現れればフローが変わります。なんなら、品質判定ソフトウェアと業務マスタで相互にAPIが解放されているならAPIを通した連携を行って自動的な登録が可能になる、という形で人間が介する業務のフローはさらに変わる可能性があります。
従来通りの、業務を設計して愚直にシステムに落とすというやり方は、技術的な発想が抜け落ちていることが起きえます。単純なCRUDに基づいた業務設計は、「論理的思考」と呼ばれる能力を持っていさえすれば、フローを明確化することは可能でした。一方で、技術革新が起きることで、新規技術を前提とした業務設計が求められるようになります。
そこで威力を発揮して相性が良かったのが、AI、IoT、クラウドなどの技術要素で、日経新聞をよく賑わしました。
- AIは、要はこれまでの事例に基づいた確率予測判断です。
- IoTは現実世界で計測したデータをネットワークを介して他のソフトウェアに転送する技術といえます
- クラウドは単純にサーバーを移転するというだけのものではなくなってきており、AWS、Azure、GCPといったエコシステム内に多くのソフトウェアツールが存在しており、自分たちのソフトウェアを強化するためのソフトウェアがたくさん並んでいます。
過去事例からの確率予測判断、計測データの連携技術、クラウド上で強化するソフトウェアを前提として業務を設計すると、伝統的なCRUDに基づいた業務フローとは異なることになるかと思います。
作っているものはソフトウェアなのだが、従来的なシステムとどうも違う、魅力的な技術を使っているシステムをどう呼ぶべきか、それを感じて「デジタル化」という言葉で「システム化」と区別し始めた、ということではないでしょうか。
そうなると当然、業務を定義してからシステムを開発する、というやり方はアンマッチになります。先程のウォーターフォールの図は必然このように相互作用をする図の方がイメージに即するように思えます。
戦略、業務設計は「上流工程」ともてはやされましたが、個人的には全体フローに大きな影響を及ぼす可能性のある技術要素を軽視した「上流工程」をもてはやす事に対しては大きな違和感があります。
リーンの考え方は、状況に応じて戦略を変えていくこと
要素や状況に応じて全体方針を変えていくことは、リーンの考え方にも通じます。リーンの考え方は、全体設計よりも素早い実験を行って仮説検証を行ってゴールを決めていきます。スタートアップや新規事業のような不確実性の高い文脈では綺麗なパワーポイントによる戦略設計よりも素早い仮説検証が重視され、どんどん確からしい方向へ方針を変えていきます。
ちなみに、リーンとアジャイルはよく一緒にされますが実は違います。あくまで早め早めに仮説検証をして、何を作るかを変えていくことがリーン。アジャイルは小さなサイクルで細かなリリースを行っていく手法という理解をしています。スプリントを組んで細かなリリースを行っていても、結局開発内容の仮説検証をしていなければそれはリーンではありません。
実際、リーン・スタートアップではアジャイルで開発していたのにリーンではなかったという失敗エピソードが書籍前半に出てきます。
アジャイル開発で進めていて多くの新規技術も用いているが、開発内容の仮説検証をプロセスに組み込んでいないというプロダクトも見てきました。リーンの文脈としてみると、アジャイル開発はリーンの仮説検証を押し進めるための手法であるが、あくまで手法でしかないと考えます。全体方針をあまり最初に決めすぎず、開発内容の仮説検証に応じて柔軟に方針を決めることがリーンです。
アジャイル開発を行うことが銀の弾丸と持て囃されているような節もたまに見かけますが、それは足元を掬われてしまうのではないか、と思います。
デジタル化の流行と上流工程の終焉
タイトルに戻ります。ここまでで、単純なシステム化（ウォーターフォール的な業務設計、CRUDにもとづいたシステム設計）によって作られるものは技術要素によってひっくり返される可能性があると見てきました。
であれば、業務を考える人間が技術要素に通じる必要があり、いわゆる「デジタル技術」が業務に適用可能かを素早く検証するということが求められるでしょう。
技術要素をきちんと理解していないと「AIでなんとかできるかもしれない」という解像度の低い話になってしまう可能性がありますが、解像度が高いと「AWSの画像認識APIによる製品のデータ化と、ルールベースによる不良検査ロジックを組むことで、品質工程で業務フローを大幅に変更できる可能性がある」といった話ができます。そのような解像度になるには、管理や論理的思考だけではなくコーディングの経験や、ありもののソフトウェアを利用して実験をしたことがある能力が必要になるでしょう。
いわゆるこれまでの「上流」だけではあまりワークしない時代になってきているかと思います。各種コンサルティングファームがこの5年程度「デジタル」部隊を強化してきた背景はこの辺りがあるでしょう。なお、自身で技術の解像度を上げたくないため、技術に詳しい人間を部下につけて考えさせる、ということも見てきた経験ではあまりワークしないように思えます。結局意思決定をするラインの人間が最低限正しく判定できなければ負のループを生むだけのようです。
余談ですが、技術はコンサルがやる仕事じゃないといって技術理解をしようとしない業務コンサルを新卒で入ったITコンサルの会社では「チャラチャラ上流コンサル」と呼んで、そうなるなよと注意喚起されていました。
- デジタルという言葉が流行している理由
- なぜシステム化ではなくデジタル化という言葉が使われているのか
- アジャイルの流行など、管理ではなくコーディングに強いエンジニアが強く求められているのか
今回、この3つについて考えました。最近、B2Bの業務SaaSを開発しており、技術を中核においた業務改善について考えることが増えたため最近の考えについてまとめました。
