- この記事について
- 共感している
- そもそもDXとは何か
- デジタル中心のビジネスにどうシフトするか
- デジタル中心のオペレーションにどうシフトするか
- 顧客や従業員がラクになる体験(UX)
- 最近やっている案件
- みんなすごい
この記事について
- 下書きの状態で公開することにした。
- 主観と経験で書いているので、細かい話は要事実確認。
- 反響があったら後でブラッシュアップするかも。
- 特定の名前が分かる形での非公開情報は載せていない。
共感している
DXという言葉は使わなかったけど、過去に似た内容で登壇したので、一連のツイートに共感しますhttps://t.co/bh8dWDxjpWhttps://t.co/gJjrvLf6tu https://t.co/cTW35ELvIE pic.twitter.com/ImjPYWPP5R
— ゆずたそ (@yuzutas0) May 26, 2020
そもそもDXとは何か
- 本質的には、時代の変化に応じた組織の進化だと思っている。
- ビジネス観点
- 歴史
- トヨタ:糸から自動車へ
- 任天堂:花札からテレビゲームへ
- リクルート:クーポン雑誌から予約サイトへ(デジタル化)
- 最近の「デジタル化」はレコメンドを指しがち。
- Googleの話。Yahooのようなリンク集から、被引用数を軸とした検索エンジンへ。「探しているのはこれですよね」をレコメンドする世界。
- Gunosyの話。ニュースを探す世界観からレコメンドの世界観へ。
- Tiktokの話。動画を探す世界観からレコメンドの世界観へ。
- そこまで露骨ではなくても、Amazonの「この商品も一緒に買われています」クロスセルも、ここまでスケールすると超強力。
- 要するに「顧客がラクになる体験の創造」だと解釈している。
- 歴史
- オペレーション観点
- 歴史
- 手書きからタイプライターへ
- タイプライターからWord文書へ(デジタル化)
- 最近の「デジタル化すごいですね」は、SaaSを指しがち。
- 契約書の電子化とか。
- オフィスに行って、郵便物を受け取って、「無事に受け取りました」と連絡して、署名・捺印して、封筒に入れて、郵送して、「郵送しました」と連絡する。
- これが数クリックで済むようになる。
- 要するに「労働者がラクになる体験の創造」だと解釈している。
- 契約書の電子化とか。
- 歴史
- ビジネスとオペレーションは密接に関わっている。
- なぜなら新規ビジネスが既存オペレーションを塗り替えるから。
- 既存:駅前の書店で購入 → 新規:Amazonで購入(デジタル化)
- 組織観点(詳細は割愛する)
- 根本的には組織文化の革新が必要になる。
- 文化は日々の言動を通して結果的に形成される。
- なので「文化を作ろう」「文化が大事」では何も言っていないのと同じ。
- クレドを掲げて制度やコミュニケーションに反映させる。
- デジタルトランスフォーメーションを阻む壁=肥大化したレガシーシステム。
- 突破するために技術観点で経営をリードできる人材が必要。
- と『DXレポート ~ITシステム「2025年の崖」克服とDXの本格的な展開~』で語られている。
- と tokoroten さんが言っていた。
- 根本的には組織文化の革新が必要になる。
ようやく、DXがOAとかFAと何が違うのか分かったよ……
— ところてん (@tokoroten) February 28, 2020
Slackを導入しましょう、Web会議を導入しましょう、RPAしましょうとか、そういう話じゃないのがよくわかった。
OAやFAは効率化の文脈だけど、DXはイノベーションとアジリティを指向している。
なので、課題に正面から立ち向かうことがDX
デジタル中心のビジネスにどうシフトするか
リクルート:クーポン雑誌から予約サイトへ。
- 歴史
- 1) 雑誌入稿や掲載審査の観点で業務システムを導入
- 2) 雑誌の画像をサイトに貼り付けただけの簡易サイト(予約は電話)
- 3) サイトで予約してメール通知を送るシステム
- 4) サイトで予約履歴を可視化
- 5) 自分の予約状況だけでなく、全体の予約状況(在庫)を可視化
- 6) モバイルアプリ対応(競合劣位による危機感から)
- 注目したいのは、既存の事業の延長上で進化した点。
- 「雑誌の画像をサイトに貼り付けただけ」から始まっている。
- 紙媒体に比べると社内でのシェアも低かったところから逆転した。
- 「テクノロジー x 改善 x 試す」の延長での成功。
- 色々と試して生き残ったものを採用する計画的偶発性の仕組み化
- マーケットや競合をウォッチ→模倣→勝ちパターンの言語化→横展開
- 定期的な担当者変更によるリニューアル(=再コンセプト定義)の機会
- 各現場が勝手にテクノロジーを試す→トラブル多発→機能軸組織を作って品質を担保&知見を集約→コモディティ化→各現場に裁量を移す
デジタル中心のオペレーションにどうシフトするか
関連するテクノロジーの話から読み解く。
- ERP
- 利用者にとって高コスト。
- カスタマイズでの導入が前提。
- コンサルや開発費で稼ぐモデル。
- 利用開始のトレーニングなど。
- 高コストで時間が掛かる。
- 試行錯誤しにくい。
- 改善できない。
- 「使いにくいもの」のまま変わらない。
- 「テクノロジー x 改善 x 試す」が出来ない。
- オペレーションレイヤーでの継続的改善を行いにくい。
- Excel帳票、手書きメモ、独自シートが生き残った。
- 現場で改善しやすいから。
- だけど担当者の工夫が全体のシステムに反映されない。
- 積もり積もって全体のオペレーションが複雑怪奇になった。
- データの入力ができないので、DWH/BI/MLも機能しない。
- 入力されていないデータを統合することはできない。
- 統合されていないデータを分析することはできない。
- 統合されていないデータを活用することはできない。
- 足りないのはAIではない。現場への愛だ。
- ERPのカウンターパートがSaaS。
- 個別カスタマイズではなくスケールのビジネスモデル。
- 顧客が離脱しないように改善して磨き込まれたプロダクト。
- その背景にあるのが、継続的なソフトウェア改善を実現するアジャイル開発。
- また、継続的デプロイを可能にしたクラウドインフラベンダーの台頭。
- 各社が社内でアジャイル・リーン的に仕事を進められていない。
- 代わりにSaaS提供者がその分を投資している。
- なのでSaaSに置き換えられていく。
- 外部環境が変わったり、事故が起きたり、予算見直しで、トリガーは起きる。
「テクノロジー x 試す x 改善」が本質
- トヨタ方式、リーン、アジャイル、ITIL、DevOps、SRE、DXと言葉を変えているが、根っこは同じ。
- それぞれのHowは時代に応じて変わる。
- どのテクノロジーを使うのかとか。
- テクノロジー
- 変遷を見る
- BtoCのBがデジタル化された世界。
- 会計などの基幹業務システム。
- 利用者(労働者)は本来Cの世界の住民。
- 慣れないBのシステムを使えるようにトレーニングを受ける。
- BtoCのCがデジタル化された世界。
- インターネットが人々に開かれた。
- プラットフォーム化。
- 社内トレーニング提供ができない。
- 使いやすさが磨き込まれる。
- BtoC → CtoCがデジタル化された世界。
- 掲示板やSNSの延長。
- 簡単に楽曲を投稿できる。
- 簡単に写真を販売できる。
- 簡単にフリマ出品できる。
- 簡単に部屋を貸せる。
- BtoCのBの再デジタル化。
- SaaS。
- ディップの事例:従業員がモバイルアプリで営業データを入力。
- より磨き込まれた設計・UXで業務をデジタル化することに意味がある。
- BtoCのBがデジタル化された世界。
- プラットフォーム
- こうした変化はソフトウェアのレイヤー構造の変化によって生じる
- Before:サーバ、クライアントPC、ブラウザアプリ、WEBアプリ
- After:モバイル端末とモバイルアプリが入り込む
- モバイルアプリで従業員の入力がラクになる
- これまで可視化できなかった顧客との関係性を扱えるようになる
- LINEを業務プラットフォーム兼CRMプラットフォームにするヘアサロン
- 変遷を見る
- 試す
- バーベル戦略
- ポートフォリオを分ける
- 8割はメインの事業に割く
- 2割は新規の取り組みに投資する
- 担当者で分けたり、時間で分けたり
- 新規の取り組みは、自社で独自開発する前に、既存のツールを使ってみる
- 試してみて良かったらマニュアルに反映する
- 反対派の存在
- チェンジ・マネジメント
- 反対派なんて存在しないのに脳内で勝手に作っているだけパターン
- 部署間で短期的な目標が異なっているから手伝えないだけパターン
- 最終的なしわ寄せを受ける部署が反対しているだけパターン
- そりゃイヤだろ反対するだろ
- DevとOpsの分離は後述
- 「いつの間にか導入出来ていた!」
- 小さくはじめる、素早く勝つ / Small Start, Quick Win
- 徐々に置き換える(カナリア・リリース)
- 継続的改善の中に「試す」を組み込む
- 例:顧客管理
- とりあえず部署AではKintoneにつっこんでみる
- リーガルやセキュリティ部門は現場が安心して試すためのガイドラインやサポートを提供
- 上手くいくコツがわかってきたので部署Bにも展開してみる
- バーベル戦略
- 改善
- 目標と現状の差分を埋めるのが改善
- 継続的に改善し続ける
- 着手したけど改善できていない→やり方を変える
- 着手できていない→ごちゃごちゃ言ってないで、さっさとやれよ!
- アジリティ=スピード=生産性=ムダ・ムラ・ムリのなさ
- 改善によってムダ・ムラ・ムリが減っていることをモニタリングする
- ワークフロー=VSM :Value Streaming Map=ボトルネックを取り除く
- プロジェクト進行=WBS=ブロッカーを取り除く
- PDCAサイクル。
- 定期的に見直すための時間を設ける。
- 週に1回、1時間を取って、マニュアルを直す。
- スクラム開発のレトロスペクティブと呼ばれる手法。
- マニュアルを元に作業を進める
- マニュアル=高い解像度=5W1H
- まず標準化
- トヨタ生産方式はマニュアル化(標準作業表)から始まった
- 意思決定は判断基準を設ける
- 「なぜ承認したのか」を言語化する
- それをマニュアルに反映すれば次から承認者の対応を待たずに済む
- 承認者の判断基準を言語化する
- 作業手順だけでなく意図を明記する
- この作業はなんのためにあるのか
- もっと良い方法があるなら手順を変えていく
- 気付いたときに気付いた人が改善する
- マニュアルは盲目的に従うものではなく、常にアップデートし続けるもの
- 現場の経験や暗黙知を、マニュアルという形式知に変換する
- マニュアルを作り、直せる人材こそが鍵
- 担当者の「まぁいいか」が積もり積もって腐敗する
- マニュアルを無視して作業する者
- マニュアルを改善せず陳腐化させる者
- そういった行為を許容するマニュアルのあり方自体を変えていく
- ボーイスカウトは気付いた山のゴミを拾って帰る
- 登山前より登山後のほうが綺麗になる
- ボーイスカウトのような仕事の仕方を行う
- Developers(仕組みを作る人)とOprations(仕組みを使う人)を分けない
- Devが仕組みを作っても、Devは問題に気付けないので、改善できない
- Opsは仕組みを直せないので、Opsが問題に気付いても、改善できない
- トヨタのアンドン:問題に気付いたら誰でもストップを掛けられる。
- オペレーションでの気付き・改善をもとに、ビジネス変革につなげる
- ビジネス観点DXとオペレーションDXの接合点
- SECIモデル・知識創造
- 営業が顧客から受けた意見を持ち寄って、商品を開発する
- 例:電話予約→サイト予約+予約完了メール→サイト内予約管理へと進化
- 時代の変化→顧客の意識や行動の変化→キャッチして追従し続ける
- ビジネスやワークフローの見直し
- 発想法「そもそもこれって必要なの?」など
- その1つが「デジタル化」=「この業務をデジタルに置き換えたら?」
- 例:そもそも24時間受付窓口って必要なの?電話じゃなくてメールに置き換えたら?
- 例:そもそも印鑑って必要なの?紙じゃなくて電子契約に置き換えたら?
- こうした発想の大元にあるのは不安感
- 本当にこのままで大丈夫なんだっけ
- パラノイア(悲観論者)だけが生き残る
- 盛者必衰
- 我々は沈む船に乗っている
- 常に漕ぎ続け、水漏れを防ぎ、悪天候に備え、座礁に気を配り、進路を変え、別の船に乗り換え、試行錯誤を続けなければならない
- 硬直思考の従業員が蔓延すると見えにくくなる
- 教科書を暗記してテストで100点を取ればOKという価値観
- 指示通りの作業すればOKという価値観
- 現実逃避の共同幻想
- あらゆる物事がソフトウェアによって置き換えられていく
- Software Is Eating The World
- 社会の前提は変わり続ける
- 10Xの変化に備える
- 本当にこのままで大丈夫なんだっけ
- 目標と現状の差分を埋めるのが改善
顧客や従業員がラクになる体験(UX)
ムダの削減=ラクになる
- トヨタ生産方式では、ムダを「付加価値を高めない各種現象や結果」と定義している。
- アジェンダのない会議
- おしゃべりしたいなら、そのための場を設けろ、混ぜるな
- 会議は何かを解決するもの
- 目的、目標、現状、課題、制約、選択肢、決定事項、ネクストアクション
- 言語化スキル=思考力
- Amazonの会議やDocsがすごい
- ハンコ、署名、原本郵送
- 契約書を毎回のように弁護士が細かくチェックして条文の交渉を行うのもムダでは。
- 有利な条件で契約できるよう交渉しあうのではなく、お互いにとって益のある案件に全力投球できるようにしたい。
- そのためには公開しても反感が寄せられないようなフェアな条文で、契約書テンプレを作って、そのまま公開してしまえ。
- そこから案件に応じた微調整だけで済ませれば良い。
- 「社会人として当然」と言われているマナーや慣習は、多くがムダ。
- 昭和の常識は、令和の非常識。
- 破壊的なプレイヤーに持っていかれる。
- 思考停止の共同幻想が崩されて、社会が進化していく。
- 特にここ50年くらいはデジタル化の波ですよ。
- それがDXなのではなかろうか!
最近やっている案件
一部抜粋
データマネジメント案件で呼ばれたが、どちらかというと業務フローの改革がメインなので『ビジネスプロセスの教科書』を読んでみた。めっちゃ良い。https://t.co/Lun18GMjW6 pic.twitter.com/4MHgnEtOha
— ゆずたそ (@yuzutas0) May 6, 2020
- 1社目。
- スタッフによる手動マッチング業務。
- 不動産賃貸とか中途採用斡旋みたいなのを想像してもらえると良い。
- これをデジタル化する。
- 最初はツール導入で業務フロー改善しようとした。
- 「そもそも手動でやる必要あるの?」
- 自動マッチング促進に舵を切る。
- 1週間でMVP開発。
- マッチング駄目なら手動でやるから言ってねオペレーション。
- 徐々にMVPを磨き込んで、シェアを移していく想定。
- その磨き込みの過程で、手動マッチングで担当者に散在していたデータや脳内手順を、ツール・マニュアルに置き換えていく。
- ビジネスとオペレーションを同時に磨き込み、なおかつ短期的なコンバージョン向上も実現する。
- これがいいのは、カウンターパートが、システム開発部だけでなく、商品企画・事業企画といったビジネス部門の担当役員であること。
- めちゃくちゃやりやすい。
- 話が進みやすくて楽しい。
- ビジネスから変えていくので本質的。
- 2社目。
- セミプロ向けのダッシュボード。
- CtoCプロダクト。
- 写真販売とかそういうのをイメージしてもらえると良い。
- 伸びている市場。今後も伸びる市場。
- コンテンツ提供者はセミプロ。
- セミプロが試行錯誤できるような機能を提供してマーケットを育てる。
- という商品開発>機能開発>ダッシュボード開発。
- 3社目。
- マルチベンダーによるデータ基盤開発。
- あちこちで「日本におけるデータ基盤の第一人者」と呼んでもらえるようになって、ここ数年でその手の案件を相談いただくことが増えた。
- 各業務を改善していくに当たって、ワークフローがどのように機能しているのか、事業数値がどうなっているのか、モニタリングしたい。
- 推測するな。計測せよ。
- 計測して問題の大きいところに、改善のためのリソースを割く。
- ただ、大規模組織の難しい点として、既存の業務システムの管理を、複数の部署・ベンダーでそれぞれ担当している。
- 本来やりたかったはずのことに対して、現行の複雑度が高すぎる。
- 横断して見るには、様々な調整が必要になる。
- というのを地道にプロジェクト化して、そして推進していく。
- 4社目。
- メガベンチャー。
- 業務フローがカオスで、そのままデカくなってしまった。
- かといって業界1位でもないので、勝ち筋を模索している。
- 業務フローを改善しないとやばい。
- だが勝ち筋に辿り着くまでは、そこにリソースを割けない。
- そういうときこそ、ビジネス施策とオペレーションを同時に改善するのが良いのだが、カウンターパートがビジネス部門でなく、距離が遠くて、なかなか手強い。
- 打てる手が限られているので、まずは目先の状況を安定化させようと思い、チケットツールでの課題管理から始めた。
- 課題を可視化して適切なエスカレーションが行えるようになると、そこから建設的な施策に繋げることができるはず。
- 5社目。
- いわゆるSaaS、iPaaS、業務支援WEBサービスの導入支援を始めたので、その案件。
- 何社かクライアント企業からの要望もあったし、各サービス提供者からも声を掛けていただいている。
- ただ導入するだけだと意味がないので、いかにビジネスを加速させるかという観点から戦略を描き、現場のオペレーションを継続的に改善できるようなマニュアル整備をセットで行おうとしている。
- まだ始めたばかりでそんなに実績は出ていない。
- この支援に限らずだが、ミーティングのアジェンダや課題管理など、自分と一緒に働くだけで「こうやって仕事を進めると効率的だな」「こういう発想で意思決定していくと業務が加速するのか」ということを感じてもらえるような働き方を心がけている。
- まぁでもそんな上手く行っているかと言われると、まだまだ改善余地だらけなので、自分自身が日々改善サイクルを回している。
他にもやってるけど割愛。 DXという言葉は使わないけど、まぁDXっぽいといえばDXっぽい。 もう少し上手いこと商品化したいと思いながらここまで来てしまった。
みんなすごい
10XやLayerXのプレスを見て、すげぇなぁと思った。自分も同じように戦えるネタを持っていたはずなのに、その規模で戦えていないので、そういった意味でモヤモヤした。領域を特定して大型案件を取りに行くなり、徹底的にリテールに寄り添うなり、自分なりのポジションを取って、徹底しないといかんなぁと思った。
リクルートの営業を思い出す。喫茶店のマスターは、コーヒーの勉強はしたかもしれないけど、お客様を呼んだり、アルバイトを雇うための勉強をしていない。だから、人が来ないからと言って、新メニューを開発したりする。課題と打ち手が合わない。そこでリクの営業が集客や採用の手伝いをする。でもコンサルティングのような目に見えないサービスにお金を払ってもらいにくい。だから代わりに雑誌の広告枠を高単価で買ってもらう。割高に感じるけど、お世話になっているから、まぁ仕方ないなって思ってもらう。広告媒体に高単価を払ってもらいながら、実際にはコンサルティングサービスを提供している。
この構造をDXとツールで再現するところが強いのだろうなぁと。ツール導入という名目で入り、実際にはコンサルティングサービスを提供する。10XやLayerXが良いなぁと思ったのは、まさにこれで、モバイルアプリやブロックチェーンというソリューションを見せながら、実際にはDXコンサルで入っているっぽいのが、かなり良い。
なんかこう熱いものが込み上げて来る。自分はプロフィットセンターというか顧客接点&売上増加みたいな領域が好きなので、リテール x CRM系とかでチャレンジしたいかもしれない。そんなことを思った。
「小説形式でDXを学ぼう!!製造会社は3ヶ月でデジタル化できるのか!?」みたいなタイトルに変えたら、中身そのままでも行けそう。隠れた名著。https://t.co/IJcRCcBPnx
— ゆずたそ (@yuzutas0) March 27, 2020