The Lean & Digital Transformation
VUCA
「VUCA」 という言葉を聞いたことはありますでしょうか。聞いたことがない方はこちらのサイトを参照してみてください。
- V: Volatility(変動性)
- U: Uncertainty(不確実性)
- C: Complexity(複雑性)
- A: Ambiguity(曖昧性)
VUCA は上記の頭文字をとったものです。上述のサイトによると VUCA は次の一言で表されています。
VUCAとは、一言でいうと「先行きが不透明で、将来の予測が困難な状態」を意味します。
VUCA 時代のビジネスにおいてはこれまで想定していなかったプレイヤーが急に出現し、経営資源だと思いこんでいたものを全く意味のないものに変え既存プレイヤーが容易に真似(イミテーション)をできないビジネスモデルを展開していきます。
具体的にいうと、Netflix、Uber そして Airbnb がそれにあたります。
既存 DVD レンタル業界において、「店舗」、「DVD」、「スタッフ」がかつては経営資源でした。しかし、Netflix の登場により、それらは何の意味もなさないものになってしまいました。
「企業資産の負債化」という、経営資源が足かせとなる現象があちらこちらで起きています。これまで企業は「設備投資をする」「自社に必要な人材を雇用し育成する」などを行って、それらを固有の資産とし、競争優位を築いてきました。しかし、テクノロジーの著しい進化によって、経営資源として抱えていたものが意味を持たなくなるような製品・システムが次々と生まれています。
経営資源は、即座に組み替えることは不可能です。
例えば、「過剰だから」といっていきなり従業員を半分解雇、といったことはできません。
そうこうしている間に新しいビジネスモデルで、新しい企業が勝ち上がっていく。
このような事態が今まさにあちこちで起きています。
つまり、既存プレイヤーの破綻や撤退が起き始めているわけです。
今まで「常識」だと思っていたものが「非常識」に、今まで「非常識」だと思っていたものがこの先の「常識」になっていくのです。
Amazon が展開している Amazon Go もこれにあたると思います。
顧客が何を手に取り、何を買い物かごに入れ、何を棚に戻したかは店内に設置された3Dカメラなどで自動的に探知され、アプリのバーチャルショッピングカートに反映されます。店を出た時点で、購入したものの合計金額が計算され、アカウントに課金されるという仕組みです。既存のスーパーのビジネスモデルは、顧客がスーパーに直接来店し、買いたいものをカゴに入れ、レジに並び、スタッフがレジスターに商品を登録して、価格の合計を算出し、お金を払ってもらうというものでした。
しかし Amazon Go では以下のものが不要になります。
- レジ(POS レジや iPad)
- レジの占有スペース
- レジのスタッフ
このように大変化が起こる時代を VUCA と呼びます。
既存プレイヤーが大切にするリソースとリソース効率性
Amazon Go の話題が出たのでスーパーのレジの話をしましょう。
既存のスーパーのビジネスモデル
既存のスーパーは以下のビジネスモデルを構築していました。
- 顧客がスーパーに直接来店する
- 買いたいものをカゴに入れる
- レジに並ぶ
- スタッフがレジに商品を登録してくれるのを待つ
- 価格の合計を算出
- 顧客にお金を払ってもらう
- 退店する
スーパーに買い物に行った際、レジが非常に混雑していたらどうでしょうか。
- 配備されているレジの担当者はほぼ100%で稼働しています。
- 顧客は自分の欲しいものが買えるまで行列に並んで待つ必要があります。
二つの効率
リソース効率とフロー効率
上記の1をリソース効率と呼び、2をフロー効率と呼びます。
リソース効率とはリソースであるレジのスタッフの稼働率やレジそのものの稼働率を中心に考える効率のことです。
対してフロー効率とは顧客に価値を届けるためのリードタイムを重視して考える効率性のことです。
行列ができている上記の図のような状態だとリソース効率は高いが、フロー効率は低いと言えます。
Amazon Go が変革したビジネスモデル
なぜこんな話をしているかというと Amazon Go におけるビジネスモデル変革はフロー効率を高める努力がしてあるからです。従来のビジネスモデルから不要になったプロセスを考えてみます。
- 顧客がスーパーに直接来店する
- 買いたいものをカゴに入れる
- レジに並ぶ → 不要に
- スタッフ(既存プレイヤーにとっての経営資源)がレジスターに商品を登録してくれるのを待つ → 不要に
- 価格の合計を算出 → 不要に
- 顧客にお金を払ってもらう → 不要に
- 退店する
多くのプロセスが不要になっている上、顧客は混雑するレジに並ぶ必要すらありません。
このビジネスモデルでは、顧客が商品を買い物カゴに入れた瞬間にデジタル上のカートに商品が追加され、店を出る際に自動で決済されます。買おうと思ったらカゴに入れ、不要だと思ったら棚に戻す、顧客にはその瞬間瞬間に価値がフィードバックされています。
顧客に価値を届けることを重視した結果、「レジ」、「店舗」、「スタッフ」は顧客に価値を届ける際の単なる手段の一つであると判断したのではないでしょうか。
既存の経営資源重視やリソース効率性重視の考え方をしていては、Amazon Go のような従来の経営資源を不要とするビジネスモデルを構築することは不可能です。
従来の考え方を変革する必要があります。
フロー効率を高める手法
リソース効率とフロー効率はお互いに相反しています。加えて従来のサービスを展開する企業は効率 = リソース効率だと考えていて、経営資源であるレジや人のリソース効率が上がるようビジネスモデルをデザインしています。
これでは顧客との接点である来店が顧客にとってよくない体験(UX)になる可能性があります(長いこと待たされる)。その上、ディスラプターが出現すると、頑張って効率をあげてきたこれらのリソースそのもの(レジ、販売スタッフ、レジのスペース)すら、無意味なものに変換させられる恐れがあるのです。
企業はこのままリソース効率だけに着目していて良いのでしょうか。フロー効率を高めるためには何をすれば良いのかを見ていきます。
ちなみにフロー効率は以下の書籍で詳細に取り扱われています。
Value Stream Mapping
価値の流れに着目してプロセスを変革する手法があります。バリューストリームマッピングと言います。
バリューストリームマッピングはトヨタのカイゼンをもとにしているという説もありますが、製造業だけにしか適用できないというわけではありません。さまざまなプロセスに適用することができます。
バリューストリームマッピング (VSM) は、仕事の現状を分析し、将来的により効率的な状態を作り上げるための手段です。このプロセスを実行すると、自分の働き方を可視化できるため、改善の必要な領域を発見できます。
バリューストリームマッピングを使用して自分達の業務を可視化してみましょう。どこにどれだけのリソースを割いていて、ボトルネックとなる箇所が明らかになります。
VSM を利用した開発プロセスの短期化
開発プロセスを短縮した以下のケースを参照してみてください。
※例では開発プロセスになっていますが、IT 関連のプロセスしかバリューストリームマッピングで扱えないというわけではありません。日頃のプロセスなどの見直しにバリューストリームマッピングが使えます。
P.26 に開発プロセスのリードタイムをバリューストリームマッピングを使用して図示したものがあります。
バリューストリームマッピングではプロセスが無駄なく稼働したときにかかる時間(プロセスタイム)、正確率(%C/A)、リードタイム(84h や 100h)等を使用してプロセス全体を表現します。正確率は再作業の必要がないものの比率になります。つまり上記の「リリース作業」に着目して見てみると、プロセス自体の時間は1時間しかかからないが、上流から流れてきたプロセスをそのまま完遂できるのは 20% であり、残りの 80% は再作業を強いられているという見方ができます。
バリューストリームマッピングについては Google の Cloud アーキテクチャセンターを見て知見を深めるのも良いかもしれません。
DMM では 268.5 時間かかっている開発プロセス全体の 85% (228.25 時間)をステークホルダーとの調整(承認を得るための会議や待ち時間)に費やしていたため、そもそも承認をとるためのその会議必要なんだっけというところから入ったのが上述の例のようです。
結果、228.25 時間かかっていた本プロセスのリードタイムを40時間に短縮することができたそうです(188.25 時間の削減、82.5% の大改善)。
DMM の場合、他の開発作業やリリース作業＋準備にも無駄があることがわかり改善していますが、全体のリードタイムのほとんどをステークホルダーとの調整に使われていたため、この部分を改善しないと全体のスループットが上がらないと言うことに気づいておられます。
【番外】その承認作業、ものすごいリードタイム使ってませんか・・・？
昨今なんでも自動化自動化と叫ばれていますが、途中のワークフローをいくら自動化したところで、「承認」と呼ばれているプロセスが人任せである以上、リードタイムが短縮できず価値を届ける時間は変わらないままなんてことがよくあります。
上記の DMM の事例と同じです。プロセス上、承認 MTG 一言で片付けられるため、清流化されたプロセスのように見えますが、その承認 MTG の準備にかかる時間がバリューストリームマッピングを利用しないと可視化できません。
ワークフローツールはただの手段の一つです。上記の「承認」がなぜリードタイムを必要とするのかを深堀しなければワークフローツールを導入したもののただ IT 化しただけで終わり、リードタイム短縮なんて全くできなかったなんてことになってしまいます。
Excel で承認ポイントを細かく記載 + メール + 電話の業務の方が早かったなんてことも考えられます。Excel + メール + 電話はただの手段であり、ワークフローツールもただの手段です。
継続的に価値を届けるスクラム開発
昨今ではバリューストリームマッピングはアジャイル開発を代表するワークショップの感も否めませんが、そもそもアジャイルを代表するスクラム開発は顧客に価値を継続的に届けるための手法でもあります。
ウォーターフォール開発では、最初から完璧な設計を理想として開発していく手法ですが、これでは完成するまでに長い時間がかかる上、完成した頃には世の中が大きく変動してしまっている可能性があります。VUCA 時代に対応させるアプリケーション開発にはそぐわない開発手法です。
各企業のお金を稼ぐ主戦力である、製品、サービス、ビジネスモデルの開発には、仮説(IDEA)を立て、仮説を基にした最小製品 MVP(Minimum Viable Prodcut)を構築(BUILD)し、市場にリリースし、メトリクス計測し(MEASURE)、計測したデータから学習(LEARN)して次の仮説を立てて開発に活かすという仮説検証型の開発サイクルが必要となります。これは IT 製品だけに限った話ではありません。
このサイクルをリーンスタートアップサイクルと呼びます。本件については以下の書籍が詳しく説明しています。
DX とは
IDC Japan の定義でも、経済産業省の定義でも以下のように定義されていて個人的には同じ意味だと捉えています。
VUCA 時代における
- 組織・プロセス・企業文化・従業員の変革
- 新製品・新サービス・新ビジネスモデルの変革
いままでのリソース効率重視の考え方から顧客に価値を届けるためのリードタイム重視の考え方の変革、従来のウォーターフォール開発からスクラム開発のようなアジャイル開発への変革が必要になってきます。
そしてその結果生まれた製品やサービス、ビジネスモデルによって変革を起こして初めて DX と言えるのではないでしょうか。
製品やサービス、ビジネスモデルによる変革は既存の経営資源を過去のものにするようなインパクトが求められます。
