DX に必要な知識と心構えを考察してみた

何から手を付けたらよいのか？デジタルトランスフォーメーション（〔狭義の〕デジタル化）と言われても、そんな簡単に “変身/変革” できるものではない。大きな組織であればナオサラだ。しかし組織として生き残るためには、このDX時代の “新しい武器” すなわち Cloud Social Mobile Analytics の４技術を取り入れていくしかない。それらは戦国武将にとっての “鉄砲” みたいなモンなんだろーなーと思う。（IT業界歴20年）

クエステトラは、フロー図・業務データ・引受ルールの設定で開発が完了する No-Code BPM です

1. “脱外注” がDXの第一歩

アナタの目の前で繰り広げられている “アナログ業務” 、、、

【A.猛進】デジタル化すべく、速攻で外注する？
【B.学習】まずは、デジタル化スキルを身に付ける？？

オススメしたいのは、「B.まずはスキルを身に付ける」である。（←急がば回れ）

すなわち『簡易なデジタル化（ITシステム化）なら自分達で実現できるようになるべき』と考えている。今日、”デジタル化スキルの学習コスト” は著しく下がっている。

いまや “オンライン上にデータ化されていない存在” は『悪』なのだ。「FAXで届く注文書」「紙で郵送している請求書」「紙に刻印されるタイムカード」「ハンコ押印する契約書」などは、もはや “抹殺されるべき存在” なのだ。しかし抹殺されるべきは紙業務だけではない。「個人アドレスで受注」といった “活用しづらいデータ” や「Excel職人による集計」といった “検証不能なプロセス” も、同時に一掃されるべきと言える。

DXプラットフォームとは、Cloud・Social・Mobile・Analytics の４技術基盤。

1-1. そもそも “DX技術” ってナニ？

『DX』なる言葉は “バズワード” だ（Digital Transformation）。流行語としての賞味期限は、あと２・３年といったところだろう。IT業界がグルになって連呼し、企業のIT投資を喚起しているに過ぎない。

と、は、言うものの、、、 “完全無視” は得策ではない。『第3のプラットフォーム』（The Third platform: wikipedia）と呼ばれる情報通信基盤はそれなりに正しい方向性が示されている。つまり、提唱者たち（主に米IDC・米Gartner・米IBM）の主張が広く支持され、米国政府や日本国政府も積極的に推進する立場となる、、、に至っている。（←もはや「DXは “デラックス” やないでぇ」とチャカせない雰囲気に…）

たとえば日本国政府は「過去技術との決別」を強く推奨し、『メインフレーム技術』（第1のプラットフォーム）や『クライアントサーバ技術』（第2のプラットフォーム）からの脱却を真剣に訴えている。「2025年までには “第3のプラットフォーム” に移行しなければならない！！」と。（←いわゆる「2025年の崖」）

Social Media:
- パーソナルネットワークを活用する（”Facebook”、”Twitter”、’社内チャット’、…）
Mobile Computing:
- 移動通信デバイスを活用する（’スマホ’、’タブレット端末’、’スマートウォッチ’、…）
Analytics:
- ビッグデータを分析する（Webコンテンツ、オープンデータ、ビジネスログ、…）
Cloud Computing:
- 仮想サーバサービスを活用する（’SaaS’・’PaaS’・’IaaS’ レイヤの各種サービス）

もう、好むと好まざるとにかかわらず、”SMAC”（第3のプラットフォーム）の中で生きていくしかない。そして “閉鎖的なIT活用” からは脱却しなければならない。ソレは正しい。

Cloud・Social・Mobile・Analytics の技術群は、DX時代の「武器」だ。新しい武器を取り入れない組織は、やっぱり生き残れない。昔ながらの “騎馬隊戦術” にこだわり続け “鉄砲” というテクノロジーに目を向けないようでは、もはや “勝てない” のだ。既に『COBOL(コボル)』や『PL/I(ピーエルワン)』は伝承不能と言わざるを得ない。『メールサーバ』や『Webサーバ』を自社設置するスタイルも、「電気コンセントを拒絶して自社で発電機を回し続けているようなもの」だ。たとえば負の遺産の象徴である “サーバルーム” は廃止するしかない。いっそ “防音の個室”（←オンライン商談用）を並べてしまう、のが良い。

もっとも… “DXを啓蒙している風の日本政府” はこれまで「DXに対して抵抗しまくってきたオヤダマ」だった。まぁ、『DXレポート～ITシステム「2025年の崖」克服とDXの本格的な展開～』（2018-09-07）や『DXレポート2（中間取りまとめ）』（2020-12-28）で、心を入れ替えたようなので（？）、これからは「まず隗より始めよ」の心構えで取り組んでもらいたい。特に商務情報政策局周辺の方々は “デジタル庁のお下知” を待つような状態に陥らないで欲しい。

（”SMAC” は “SMAP” やないでぇ～。「あの頃の未来に僕らは立っているのかなぁ♪」）

まだ “第2のプラットフォーム” をフル稼働させて様々な魔法を使いまくっているヒト、まだ “なりたい自分” になり切れていないと自覚しているヒト、、、を、「崖の上のポニョ」という（←ウソ）

1-2. DX成功のカギはSaaSフル活用

情報システムの「内製化」と聞けば、大きなストレスに感じるかも知れない。

しかし、よく考えて欲しい。

要件やユーザーストーリーの定義
（その為の社内での打ち合わせ）
“メインフレーム機” や “社内設置サーバ” の選定
（その為のベンダとの打ち合わせ）

などといった話は、今となっては、もう “昔話” だ。たとえば、、、マカリ間違っても「Webメールシステムを自社開発しよう」とか「ファイル管理システムを自社開発しよう」とか、思ってはならない。

ITシステムの構築において、まず第一に考えるべきは SaaS だ。

顧客関係や商談状況を管理するために “Salesforce” を導入する
リード顧客との信頼関係を構築するために “HubSpot” を導入する
カスタマーサポートを管理するために “Zendesk” を導入する
ソフトウェア開発基盤として “GitHub” を導入する
ビジネスコミュニケーション基盤として “Slack” を導入する
コラボレーショングループウェア基盤として “Google Workspace” を導入する
名刺情報を一元管理するために “Sansan” を導入する
財務会計情報を一元管理するために “MoneyForward クラウド会計” を導入する

なんせ申し込めばその日から使える。しかも利用期間だけ料金を支払えばイイ。つまり「選定の失敗」など気にしなくて良い。むしろ幾つか失敗して様々なSaaSに触れた方が良い経験になる。

「提供されている機能に業務プロセスをあわせる」という方針は、とても合理的だ。特に『社会保険申請』や『会計記帳』など、企業ごとの差異が少ない業務において “オリジナリティ” を出す必要はない。むしろ “出来合いのITシステム” の方が都合が良い。

1-3. PDCA の呪縛

PDCAサイクルは大切だ。（Plan:計画する・Do:実行する・Check:評価する・Act:改善する）

しかし「DX時代のITシステム」にあっては、“壮大な計画” は禁物だ。

全社戦略と事業戦略と情報システム戦略の策定が必要ダ…
情報システムユーザースキル標準に基づく人材配置で…
失敗を避けるために先行事例や失敗ケース等についても…
DX 実現基盤となる IT システムの構築ステップについての認識の共有を…

そんな議論をしていると、いつまで経っても “変身” できない。むしろ、最初の計画(P)は、

まずは様々な SaaS を試してみる

くらいの “シンプルな計画” にしてしまうのが良い。

実際に試運転(D)し、システムの各機能を評価(C)し、発生したインシデントに対応(A)してみれば良い。そして、身をもって経験した内容を共有し、その上で次の計画(P)を立てれば良い。たとえばもしDX推進チームが10人なら、それぞれが別々のSaaSを申し込んでみて、10個のITシステムを仮運用してしまうくらいが良い。

ナンにせよ、最初から「一発で “変身” してみせる」と意気込む、のはキケンだ。特に「カスタムメイドなITシステム」を創ろうとする、のは清水の舞台から飛び降りる覚悟が必要だ。（←きっと死ぬ）

“借家にすら住んだことない人間” が「家のあるべき姿」や「建築手順」について考える事自体がオコガマシイ。特に素人たちが「ウォーターフォール開発よりアジャイル開発の方が…」といった方法論を議論するなんて不毛だ。ちなみに「戦略」や「KPI」についての計画議論が繰り返し為されることは『PPPFサイクル』（Plan-Plan-Plan-Forget Cycle）と呼ばれる。（←ウソ）

ちなみに、初っ端から “アジャイル” だの “ウォーターフォール” だの「開発手法」を論じる方々は、あまりスキになれない。自立心が無いというか、自尊心が無いというか。。。まずは「自力で何とかしよう！」と “自分で出来る範囲” について考察して欲しい。「トライ＆エラー上等」だ。

もし貴方が PaaS レイヤや IaaS レイヤのサービスを使いこなせる玄人であったとしても、積極的に SaaS 活用すべきだと思っている。学ぶべき点は、ホント、多い。

2. SaaSフル活用体制

近年、SaaS製品の導入数は、急速な増加傾向にある。

DXに積極的な日本企業で言えば、10種程度のSaaS製品を導入している会社が多い。Cloud先進国の米国で言えば、100以上のSaaS製品を導入しているという調査もある。（←導入数や投資金額など、最新情報のアップデートは、各種メディア記事に委ねたい: note記事、webtan記事、nikkeibp記事…）

ちなみに、経産省の「DXレポート」にも、第2弾（中間とりまとめ）で『事業継続を可能とする最も迅速な対処策として市販製品・サービスを導入』という記述が足されている。（←ココ、もっとアピールした方がイイと思うんだけどなぁ）

2-1. SaaS メリット

メリットは「手軽」のヒトコトに尽きる。

“導入” も手軽だが、”辞める” のも手軽だ。そして種類も豊富。”業務を絞った製品” の方が知名度はあるが、他方（利用者のハードルがより低い） “業界を絞った製品” も多くなってきた。

業務特化型 (Horizontal SaaS):
- Office Suite
- SFA: Sales Force Automation
- CRM: Customer Relationship Management
- MA: Marketing Automation
- CS: Customer Support など
業界特化型 (Vertical SaaS):
- 医療業界向け予約受付システム
- 外食業界向け予約受付システム
- 建設業界向けスケジュール管理システムなど

業務を絞った製品は、業界の違い／国の違いを吸収し “ヨコ展開” される傾向が強い。そのためIT関係者達は『水平展開型SaaS』（Horizontal SaaS）と呼ぶ。一方で、業界が絞られたSaaSは『垂直展開型SaaS』（Vertical SaaS）と呼ばれる。たとえば「一人の医師が運営するクリニック向けの機能」といった “深く掘り下げられた機能” が実装されている。

ちなみに、”DX時代の４技術”（SMAC）の中核は C（Cloud）であり、”Cloud の3形態”（SaaS/PaaS/IaaS）の中で、ユーザ企業にとってもっともハードルが低いのは SaaS である。

（ポジショントークっぽくて恐縮だが）、SaaS は社会全体のデジタル化に欠かせないツールと言える。

SaaS 活用の場合、事業環境の変化にも追随しやすい。つまり、新しい制度や新しいテクノロジーは、新機能として積極的に反映されるだろう。ユーザ自身のスキル向上が求められる場合でも、セミナーや社内勉強会などに参加するだけで良い。仮にコンサルティング等の支援サービスを受けざるをえないケースでも、一定水準の品質が期待できる。

SaaSフル活用。業務データや業務プロセスが、業務ごと・部署ごとに分断されがち。

2-2. SaaS デメリット

デメリットは「分散」だ。

すなわち、業務データと業務プロセスが、業務ごと・部署ごとに分断される傾向にある。どうしても “連携されていない状態” に陥ってしまいがちだ。

しかしながら、ソレはソレで「それぞれの部署が責任をもってデータを管理している・業務プロセスを管理している」とも言える。「中央集権 vs 地方分権」のような話と同じで、どちらが良いという話ではない。そして、歴史的・巨視的には、循環する傾向にある。

ただ、たとえば “顧客企業名” というデータが全部署でバラバラに管理されているといった状態は望むべくもない。もし、「適時更新メンテナンスされている部署」もあれば「一度手入力されただけの部署」もある、といった状態では、効率的なデータの受け渡しがままならない事態に陥ってしまう。

情報システムの分散現象は「サイロ化」と呼ばれる。窓がない円筒形貯蔵庫（サイロ）が乱立してしまうと、中に入っているものが穀物なのかミサイルなのかすら分からなくなってしまう。基本的には “窓を持たせる” といった改善が必要となる。

ちなみに、、、「サイロ化」と聞けばネガティブな印象しか持てないが、「サイロ化されている方が望ましいデータ」もある。（個人情報、財務情報、その他秘匿性の高いデータ）。より厳格な “通行手形” （OAuth2 Access Token）発行手続きを経て、API 通信してもらうことになる。

2-3. プロセス整備の必要性

“SaaS を使った自治” が進めば、部署同士の「連携」が欠かせない。

たとえば、販売部門が勝ち取った『受注データ』は製造部門で『出荷データ』となって製品サービスが出荷される。そして管理部門に渡されて『売上データ』として格納されるだろう。前払い・掛け売り、タイミングは様々だが『財貨データ』（債権回収データ）としても格納されることになる。

人が介在するか、システム同士が直接通信するか、基本的にはどちらでも良い。いずれにせよ “必要なデータ” がスムーズに渡されるようになっていなければならない。

システム連携は伝統的に「統合」（Integration）という訳語が使われてきた。様々なベンダが作ったハードウェアやソフトウェアを１つのシステムとして「統合」していた時代（←”第2のプラットフォーム” の時代）には、ソレで良かった。しかし、独立性の高い複数の Cloud サービスが連携されている状態はもはや「統合」とは言いづらい。むしろ「調和」くらいの訳語が良いと思っている。（←たとえば “European Integration” くらいなら「欧州統合」と訳しても問題ない。しかし “Racial Integration” は「人種統合」と訳せない。あくまでも「人種隔離／人種差別」（Racial Segregation）の反対語であって「人種間の調和」くらいの表現にしかならない。）

3. DX 時代のデータ連携

業務データの受け渡しには、以下のパターンが考えられる。

ヒト ⇒ コンピュータ： Webフォーム入力、スマホアプリ入力、…
コンピュータ ⇒ ヒト： Web表示、スマホアプリ表示、メール通知、…
コンピュータ ⇒ コンピュータ： API通信、…

玄人さん達はイロイロな”受け渡しの通信方式” を想像しがちだが、、、基本的にはウェブ（HTTP）とメール（SMTP）だけ、の前提で考えるのが良い。人間からの要求には “Human/User Interface” が利用され、他のコンピュータからの要求には “Application Programming Interface” (API) が利用される。それだけ知っていれば十分だ。

“コンピュータへの接続部” はインターフェース (Interface) と呼ばれる。少しヤヤコシイ話だが、近年では、ロボットコンピュータ（RPA）さんが “User Interface” を利用する場合もある〔スクレイピング〕。

HTTP: HyperText Transfer Protocol、SMTP: Simple Mail Transfer Protocol。（そう言えば FTP: File Transfer Protocol 使わなくなった／使われなくなったなぁ…）

コンピュータ同士の通信には、 "Application Programming Interface" (API) が利用される

3-1. システム同士の連携

“Web API”（「REST API」と呼ぶことも）を利用したシステム間のデータ受け渡し（リソース参照）は、もはや珍しいものではない。

たとえば個人ユースの領域でも、『家計簿アプリ』に “銀行の入出金ログ” を（銀行システムの参照系APIを通じて）自動取得させている。あるいは『通販サイト』にFacebookの登録氏名や登録誕生日を（FacebookのAPIを通じて）自動取得させている。（←これらの自動通信はあらかじめリソースの所有者によって許可されている）

ただ、全てのSaaSが、他の全てのSaaSと通信できる訳ではない。“SaaSフル活用体制” においては「仲介役」を置くことが多い。

すなわち「仲介役」が「上流のシステム」に対して “欲しい情報” をリクエスト（←”GET Request” と呼ばれる通信になることが多い）して、その Response を得たのちその結果を「下流のシステム」に対して “格納依頼” をリクエストする（←”POST Request” と呼ばれる通信になることが多い）のだ。

なお「仲介役」をになうことが出来る SaaS はタクサンある。要は “Data Integration” （データ交換）が実現できるツール群であり、その歴史は長い。カテゴリ名としても多種多様な呼称が派生している。筆者自身はこの業界に20年以上いるが、ナンデこんなにも沢山のカテゴリ名が必要なのか、良く分かっていない。（もちろん “Web API を介したデータ交換” に対応していない製品も含まれている）

Enterprise Service Bus (ESB) software
Enterprise Application Integration (EAI) software
iPaaS software
Electronic Data Interchange software
Cloud Migration software
Extract/Transform/Load (ETL) tool
Workflow Automation tool
Business Process Management (BPM) software
Big Data Integration Platform
Hybrid Integration Platform (HIP) Software

自動取得の議論においては、「格納されているデータ」のことをリソース（Resource）と呼ぶことが多い。ちなみに、情報の所在を示す “URL” も “Uniform RESOURCE Locator” の略だ。

それぞれの自動通信は “RESOURCE オーナー” の権限で許可（業界人たちは「認可」と言う）される必要がある。なお、それぞれの通信許可は「30日有効」だったり「90日有効」だったり「定期的な通信がある限り永遠に有効」だったり、様々だ。また “RESOURCE オーナー” が自身のパスワードを変更したら自動的に取り消されてしまう場合もある。（イロイロと慣れが必要）

運用実績が長くなると「上流のシステムに聞く」というスタイルがイジラシク感じるようになる。その様な際には “Webhook” という（「リバースAPI」とも呼ばれる）テクノロジーが使われる。つまるところ「上流システムのイベント」がトリガーになるのだが、運用難易度がチョット高くなる。

ワークフローSaaS内のTSVデータがGoogleスプレッドシートに自動追記される

ワークフローSaaS内の請求データで決済システムに自動課金され、さらに自動配分される

3-2. ヒトとシステムの連携

最も大切な視点は「ヒトの負担を最小限にする」という視点だ。

そもそもヒトなる存在は、業務プロセスから見れば “邪魔モノ” でしかない。すなわち、入力モレや誤入力は日常茶飯事だし、毎日寝るし、ときに長期の休暇を取る。「必要な業務データをスムーズに流す」という観点では居ない方が良い。しかも、どうしても「Web 画面で閲覧」が基本となり、そのWeb画面上に “入力方法” や “分かり易い解説” を書いてやる必要がある。挙げ句、どれだけ手をかけても「UXがイケテナイ」と毒づいてくる。（？！！）

まぁ、出来得る限り「ヒトを介在させない方法」を考えるべきだ。

稟議プロセスは、10万円未満なら「同僚のチェック」だけでOKにする
毎月の請求プロセスは、一定時間後に自動的に送信されるようにする
各種集計レポートは全工程を自動化して、自動投稿されるようにする

そして、必要最小限の「意思表示」や「データ入力」は、ワークフローエンジンを搭載したSaaSで実現されるべきだ。（もっとも、製品選定はナカナカ難しい。。。数値やファイルなどのデータ型を厳格に取り扱う製品もあれば、文字列型中心な製品もある。Web Form が自動生成される製品もあれば、詳細に設計できる製品もある。全ユーザが同じインターフェースになる製品もあれば、ユーザごとのパーミッション設定が可能な製品もある。）

Workflow software
Workflow Management software
Business Process Management (BPM) software
Case Management software
Task Management software
Spreadsheet software
Form Creation software
Ticketing System software

「システム⇒ヒト」の方向において、ヒトの “入力” を何も求めない場合、「メール通知」や「アプリ通知」などで済ませてしまうのも良い。

ちなみに、スキルアップのための『演習課題』としては「資料請求対応プロセス」を題材にすることが多い。理由は、(1)外部トリガーである、(2)組織によって最適解が異なる、(3)資料によって最適解が異なる、(4)時期によって最適解が変わる、(5)KPIが設定しやすい、あたり。もし社会人経験のない大学生であれば「レポート採点プロセス」がイイと思っている。