楽水

人々の創造が自由に表現できる舞台づくり

DX ビジネス

デザイン思考経営

投稿日:

ここでは、デザイン思考経営について次の観点で説明します。

なぜデザイン思考経営なのか

変化が激しく、不透明で先行きが予測できない昨今の経営環境を、
Volatility(変動性)
Uncertainty(不確実性)
Complexity(複雑性)
Ambiguity(不透明性)
の頭文字をとってVUCA(ブーカ)という言葉で表すことがあります。
それは、SNSやモバイル技術により、人と人がつながる時間や距離が短くなったことで、個人の欲望や考えがすぐに世界中に広がり、個人が求める欲求の新陳代謝が激しくなっているからではないでしょうか。
このような時代、表面的な現象に翻弄されていては、時間も資源も浪費し、何も生み出せない空虚な人生に陥ってしまいます。
充実した人生を送るためには、目の前の出来事に流されることなく、その背後にある本質を見極め、それを基に生きる目的を定め、試行錯誤を繰り返しながら、環境の変化に応じて価値を生み出し続けることが重要なのではないでしょうか。
これは、軸はブラさず、手段は変えるという一貫性と柔軟性を両立させる生き方だと言えるでしょう。

デザイン思考とは、一言でいえば、人間を中心に、目的に向かって走りながら考えることです。
そして、デザイン思考で経営するとは、人間の価値観という本質を基軸に事業パーパスを定め、その実現手段を環境に合わせてアジャイルに変えていく経営のことです。
それでは、デザイン思考で経営することの効果は何でしょうか。
ここでは、それを
企業の
継続力を上げる
成功力を上げる
適応力を上げる
ことだと考えています。
一つひとつ見ていきましょう。

企業の継続力を上げる

デザイン思考経営では、人間の価値観という本質を中心に据えて、事業のパーパスを定めます。
企業を構成するメンバーがこのパーパスに共感し、ともに歩むことで、自らの貢献と成長を実感し、そこに喜びや意義を見いだすことができます。
この貢献と成長による内発的な動機づけが、メンバーのやり抜く力(グリット)や、しなやかさ(レジリエンス)を育み、結果として、企業の継続力を向上させます。

企業の成功力を上げる

デザイン思考経営では、事業のパーパスを実現するために、環境に応じて仮説と検証を繰り返しながら、最適な手段を探ります。
そのプロセスの中で得られた学びや失敗をナレッジとして蓄積し、再現性のある成功パターンを築いていくことで、成功確率の高い経営基盤を構築することができます。

企業の適応力を上げる

たとえ有望な仮説が見つかっても、業務やシステムがそれに対応できなければ実現には至りません。
デザイン思考経営では、業務やシステムをモジュール化、レイヤ化し、目的に対して統合することで、新たな戦略や価値創出の要請に、迅速かつ柔軟に対応できる「変化に強い構造」を実現します。

デザイン思考は、人間の意志に基づく創造的な思考です。
近い将来、AIエージェントが多くの業務を代行する時代においては、「何を目的とし、どのような価値を生み出すか」を考える力――すなわち人間の意志によるデザイン思考が、これまで以上に重要になるのではないでしょうか。
デザイン思考経営とは、この力をを経営の中核に据えることを意味しています。

デザイン思考経営のアーキテクチャ

ここでは、デザイン思考経営を実現するために、企業が備えておく必要があるアーキテクチャ(基本的な仕組)について説明します。
企業が成功力、適応力、継続力を上げるために必要なアーキテクチャの要素は次の3つになります。
仮説検証の仕組
変化に強い構造
価値創造の企業文化
一つひとつ見ていきましょう。

仮説検証の仕組

デザイン思考で経営するとは、人間の価値観という本質を基軸にパーパスを定め、その実現手段を環境に合わせてアジャイルに変えていく経営のことです。
なので、デザイン思考経営を実現するためには、まず、仮説検証を繰り返すことで体系的にナレッジ(何をすればうまくいくか、何をすればうまくいかないか)が蓄積され、やればやるほど成功の確度が上がる仕組みを備える必要があります。
社員一人ひとりがデータを利活用してマネジメントサイクル(PDCA)を遂行し、自律的に業務課題を解決することができる経営をデータドリブン経営といいますが、企業がデータドリブン経営を実践することで、企業に仮説検証の仕組を導入することができます。
AIの技術がこれまで以上に発展すると、デザイン思考経営の仮説検証と実行のスピードが劇的上がります。
なので、データドリブン経営も、近い将来、人がAIエージェントを訓練することで、意思決定を要する部分だけ人が介入し、それ以外はAIエージェントがタスクを遂行するという、人とAIエージェントの共創型経営になる時代がくるかもしれません。

人とAIエージェントの共創型経営

変化に強い構造

仮説検証を通して最適な方法が見つかっても、新しい方法に業務とシステムが適応できないと、その方法は実現されません。
デザイン思考経営を進める上で重要なのは、不変的な事業パーパスと、その実現を支える変化に強い構造の両立です。
ここで言う「変化に強い構造」とは、環境の変化にアジャイルに適応できるように設計された業務とシステムの仕組、エンタープライズアーキテクチャ(EA)を指します。

さて、一般的に変化に強い構造は、モジュール化(分解)×レイヤ化(分類)→プロセス統合(業務とシステムをモジュール化、レイヤ化し価値を生み出すプロセスに対して統合する)によって創ることができます。
変化に強い構造←モジュール化(分解)×レイヤ化(分類)→プロセス統合
詳細は、変化に強いシステムを創るための3つのポイントを参照してください。

エンタープライズアーキテクチャ

企業を変化に強い構造にするには、エンタープライズアーキテクチャ(企業の業務とシステムの基本構造、以下、EA)をモジュール化×レイヤ化→プロセス統合で設計する必要があります。
EA←モジュール化(分解)×レイヤ化(分類)→プロセス統合
下図は、ビジネスを、縦軸を構成要素(目的・資産・場所・機能・活動)、横軸をレイヤ構造にして分けた図です。
これをビジネスストラクチャマトリクスと呼びます。


EAを設計するときのフレームワークにムザックマンフレームワークがありますが、ビジネスストラクチャマトリクスは、ザックマンフレームワークを踏襲し簡略化したかたちになっています。
まず、縦軸ですが、これは、なぜ(目的)、誰に(顧客)どのような価値(製品)を、誰が(メンバー・パートナー)、何を使って(情報資産・財務資産)、どこで(場所)、いつどのよう(機能・活動:ジョブ・ビジネスプロセス)に提供するかという5W1H(目的・資産・場所・機能・活動)によってビジネスの構成要素を分解しています。
次に、横軸ですが、これは、型、分類、実例という抽象レベルで、それぞれの要素を分類しています。
ビジネスストラクチャマトリクスに基づいてビジネスを縦軸×横軸で分解、分類し、縦軸にある活動に統合することで、モジュール化(分解)×レイヤ化(分類)→プロセス統合されたEAを設計することができます。
それでは、ビジネスのモジュール化(分解)×レイヤ化(分類)→プロセス統合について具体的に見ていきましょう。

ビジネスのモジュール化

システムの構成要素であるモジュールは、相手の要素にインターフェースだけを公開し、実装(実現)部分はブラックボックすることで、システムの構成要素をモジュール化することで、実装部分が自由に交換でき、保守性が向上するとともに、モジュールを再利用することによって生産性が向上します。
つまり、モジュール化の要は、
仕様と実現の分離
です。
ビジネスの場合、モジュールの仕様部分がジョブ(職務)になります。

ジョブはビジネス機能の仕様(型)で、それが遂行すべき複数のタスク(課業)を持ちます。
そして、ビジネス機能の仕様を実現するのがメンバー、パートナー、アプリケーション、財務資産(機械など)など能動的な資産になります。

ここでは、アプリケーションの一種と考えられるAIエージェントも、今後重要な位置づけになるので分離して表しています。
具体的に見ていきましょう。
点検担当者というジョブがあり、設備の点検と点検の報告というタスクを遂行するとします。

点検担当者というジョブをメンバーが実現する場合、次の図のようになります。

パートナーである協力会社に依頼すると次の図のようになります。

点検担当者のタスクの仕様を、点検管理システムが実装し、メンバーが点検管理システムを使う場合、次の図のようになります。

これらを見ると、点検担当者というジョブを、メンバー、パートナー、アプリケーションという様々な資産が実現してもジョブ自体は不変であることがわかります。
実現要素は変わっても、点検担当者が遂行すべき設備の点検と点検の報告というタスクの仕様は不変です。

ビジネスをモジュール化する場合は、まず、仕様となるジョブを設計して、それをどの資産が実現するか考えます。
将来、多くのジョブがAIエージェントによって遂行されるかもしれません。

ビジネスプロセス統合

ビジネスを構成する各モジュールであるジョブを、顧客を中心とするステークホルダーに価値を提供する単位、つまり、事業パーパスを実現する単位であるであるビジネスプロセスに統合することで、ビジネスを、事業パーパスを実現する仕組にすることができます。
ビジネスストラクチャマトリクスの縦軸には、その最下位に、統合先であるビジネスプロセスが位置づけられています。
下図は、ビジネスの構成要素であるジョブとタスクを組み合わせてビジネスプロセスが設計されていることを示しています。

ビジネスの構成要素は、モジュール化されているので、ビジネスプロセスを構成するジョブとタスクの組み合わせは変わりませんが、例えばメンバーからアプリケーションに変えるなど、環境の変化に応じて、それを実現する要素を変えることができます。
下図のビジネスプロセスは、「保守管理者」というジョブを保守サービス会社が実現している、また、「製品の出荷指示」というタスクは出荷管理システムが実現していることを示しています。

このように、環境の変化によってジョブやタスクを実現する要素が変わっても、ビジネスプロセスの本質的な流れは変わらないので、事業パーパスに対する機能や構造の一貫性を担保することができます。
先程の点検担当者の例で見てみましょう。
次の図は、設備管理者、点検担当者のタスクを定期点検プロセスに統合した例です。

設備管理者が策定した点検計画に従って、点検担当者が設備を点検し、その結果を設備管理者に報告するという業務フローになっています。
現状、設備管理者にアサインされたメンバーが設備管理システムを使用し、点検担当者にアサインされたメンバーが点検管理システムを使って定期点検プロセスを実現しているとすると次のような構造になります。

例えば、点検業務の効率化と品質向上をするために、点検作業をドローンが行い、点検報告をAIエージェントが行うようにビジネスモデルを変更するとどうなるでしょうか。

下図のように、設備の点検タスクは、メンバーがドローンをコントロールすることで実施し、点検の報告タスクはAIエージェントが行うという構造になります。

これを見ると、設備管理者と点検担当者の間のコミュニケーションは、設備管理システムと点検管理システムの間で行われるため、従来メンバーが行っていた点検業務をドローンとAIエージェントが代行することになってもてメンバーである設備管理者のタスクに一切影響しなことがわかります。
このように、ビジネスをモジュール化し、プロセス統合することで、環境の変換に合わせて、業務とシステムを柔軟に変更することができるようになります。

ビジネスのレイヤ化

ビジネスストラクチャマトリクスの横軸は、
型(タイプ)→分類(カテゴリ)→実例(インスタンス)
というレイヤ構造になっています。
型(タイプ)→分類(カテゴリ)→実例(インスタンス)については、ビジネスの分類を参照してください。
これは、変わりにくいレイヤ(本質)と変わりやすいレイヤ(現象)を分離して設計することで、環境が変わったとき変わりやすいレイヤの要素だけ変えればよくなり、より柔軟に変化に対応できるという考えに基づいています。
ビジネスストラクチャマトリクスを見ると、型であるジョブは、部門に分類され、部門の実例がワーカーになっていることがわかります。
人事管理上も、ジョブは役割である職務を表し、部門は、事業(市場×製品)別にジョブを分けた概念になります。

ちなみに、職位は、部長、課長、マネージャ、リーダーなど、特定の責任や権限を与えられた組織上の地位を表します。
職務によって等級が決まり、それによって基本給が決まりますが、職位の場合、それによって役職手当が決まります。
例えば、下図の場合、社員の山田太郎さんの職務は生産管理者で、職位はマネージャ、所属する部門はA事業部・生産管理部になります。

さて、ビジネスマトリクス上のジョブ、部門、ワーカーは次のような関係になります。

設備管理者とうジョブが事業ごとの設備管理部に分類され、部門に具体的な人がアサインされたワーカーが配置されていることがわかります。
時代の変化によって組織戦略が変わると部門は変更されますがジョブは不変です。
また、部門は同じでも、戦術の見直しによって、そこに配属されるワーカーは変わります。
組織ナレッジで考えると、ジョブのタスクレベルのナレッジは、部門横断的な不変的なナレッジとして蓄積され、部門のアクションレベルのナレッジは事業ごとに異なるレベルのナレッジとして蓄積されます。

部門のアクションレベルのナレッジは事業戦略の見直しによって書き換わりますが、タスクレベルのナレッジはビジネスモデルの見直しが発生しない限り不変です。
ちなみに、この組織ナレッジは、AIエージェントの学習データとして大変重要な情報になります。
このように、変わりにくいレイヤ(本質)と変わりやすいレイヤ(現象)を分離して設計することで、環境が変わったとき変わりやすいレイヤの要素だけ変えればよくなり、より柔軟に変化に対応できるようになります。

価値創造の企業文化

業務やシステムの仕組みは整っていても、それを運用する人が動かなければ絵に描いたもちで終わってしまいます。
企業を構成するメンバーが事業パーパスに共感し、アイデアを出し、仮説を立てて行動することで、顧客対する価値を創出し続けるための文化を醸成する必要があります。
メンバーが、透明かつ公平な評価の下、事業への貢献と、事業とともに成長する喜びを享受することで価値創造の企業文化が育まれていきます。
そして、この価値創造の企業文化が、仮説検証の仕組と変化に強い構造を支える精神的支柱になるのです。

学習し進化する組織

仮説検証の仕組、変化に強い構造を創り、価値創造の企業文化を育むことによって、企業は、成功力、適応力、継続力を上げていきます。
価値創造の企業文化と変化に強い構造という土台を築き、その上で、仮説と検証を繰り返すことによって、企業は、事業パーパスに向かって、継続的に学習し進化する組織になります。
この学習し進化する組織こそが、デザイン思考経営のアーキテクチャそのものなのです。

デザイン思考経営のアプローチ

それでは、具体的にデザイン思考経営は、どう進めていけばよいのでしょうか。
デザイン思考経営の事業ライフサイクルを見ると、戦略サイクルがあり、設計フェーズ、戦略フェーズ、構築フェーズ、運用フェーズという4つのフェーズから構成されていることがわかります。

事業ライフサイクルの詳細は、事業ライフサイクルを参照してください。
設計フェーズ、戦略フェーズ、構築フェーズは、ビジネスストラクチャマトリクスの型(タイプ)→分類(カテゴリ)→実例(インスタンス)に対応しており、設計フェーズは、ビジネスの型、ビジネスモデルを設計するフェーズ、戦略フェーズはビジネスの型を分類して事業戦略を策定するフェーズ、構築フェーズは、事業戦略に従ってビジネスモデルの実例でありビジネスシステムを構築するフェーズになります。
そして、運用フェーズは、PDCAというマネジメントサイクルを通して、ビジネスシステムを運用するフェーズです。
運用フェーズを構成する一つひとつのマネジメントサイクルでデータドリブン経営を実践します。

デザイン思考経営は、手段の前に軸を決めるというアプローチになっていることが特徴です。
例えば、デザイン思考経営の戦略サイクルでは、
ビジョンの前にパーパスを定める
戦略の前に価値をデザインする
という順番になっています。
なので、デザイン思考経営の戦略サイクルでは、戦略フェーズでどこを攻めるか(戦略)を考える前に、設計フェーズで誰をどう幸せにするのか(価値)を考えるという順番なっています。
「手段の前に軸を決める」デザイン思考経営の戦略サイクルは、

  • 設計フェーズ
    軸を定める:ビジネスモデルの設計
    人間の価値観を基準に事業の目的と仕組(ビジネスモデル)をデザインする。
  • 戦略フェーズ
    仮説を立てる:事業戦略の策定
    時代に適した戦略を考える。
  • 構築フェーズ
    仮説検証の基盤を作る:ビジネスシステムの構築
    仮説を検証するためのビジネスシステムを構築する。
    ビジネスシステムとは、ビジネスモデルのインスタンス(実例)で組織と情報システムを指します。
    情報システムには、各種基盤(IT基盤、データ管理基盤、マイクロサービスなどアプリケーション基盤、生成AIなどBPM基盤)、ナレッジベース、変革アプリがあります。
  • 運用フェーズ
    仮説を検証する:ビジネスシステムの運用
    ビジネスシステムを運用して仮説を検証する。

というアプローチになります。
今後、AIの技術が発展すると、構築フェーズと運用フェーズの回転速度が劇的に上がります。
デザイン思考経営では、人間の意思が最も重視される設計フェーズに比重を置いているのです。

ビジョンの前にパーパスを定める

まず、パーパスとビジョンの関係についてみていきましょう。
デザイン思考経営の事業ライフサイクルを見るとビジネスには不変的な事業パーパスと、それを実現するための一里塚となるビジョンがあることがわかります。
事業パーパスは、ビジネスが終焉しない限り変わりませんが、時代時代に合わせてビジョンは変わります。
なので、ビジネスストラクチャマトリクスの目的は、型がパーパス、分類がビジョンになっています。
ちなみに、ビジョンのインスタンス(実例)は、その実績になります。
時代に応じて、事業パーパスの一里塚であるビジョンを設定し、設計フェーズ(ビジネスモデルの見直し)、戦略フェーズ(事業戦略の見直し)、構築フェーズ、運用フェーズという4つのフェーズを通して、それを実現するサイクルが戦略サイクルです。
ビジョナリーカンパニーZEROという書籍に次のような一節があります。

山岳地帯で案内星を追いかけるたとえ話を思い出してほしい。
パーパスはこの案内星で、常に地平線上に浮かんでいる。
決して手の届かないものだが、常に前へ前へと導いてくれる。
一方、ビジョン(書籍ではミッション)はあなたがその時々に登っている山だ。
頂上に着いたら、再び案内星に視線を戻し、次に登るべき山を選ぶ。

誰をどう幸せにするのか。
ビジネスは常に地平線上に浮かんでいる事業パーパスを追いかけて、その時々に適したビジョンを定めて進み続けるのです。

戦略の前に価値をデザインする

次に、顧客と製品について見ていきましょう。
通常の経営の場合、最初に、事業戦略の一環として、顧客カテゴリ×製品カテゴリで市場をセグメンテーションし、ターゲット市場を選定します。
しかし、デザイン思考経営の場合、顧客カテゴリ×製品カテゴリを考える前に、その型である顧客タイプ×製品タイプを考えます。
事業パーパスは、
どのような価値観を持った人(誰に)に、どのような価値を提供するのか
という観点で定義します。
顧客の価値観が顧客価値で、それを満たす製品の価値が製品価値です。
顧客タイプは、顧客価値が定義された顧客の型で、製品タイプは、製品価値が定義された製品の型になります。
つまり、デザイン思考経営では、どこに攻めるか(顧客カテゴリ×製品カテゴリ)を考える前に、誰をどう幸せにするのか(顧客タイプ×製品タイプ)を考えるのです。
ターゲットとなる市場セグメント(顧客カテゴリ×製品カテゴリ)は時代によって変遷しますが、誰をどう幸せにするのか(顧客タイプ×製品タイプ)というビジネスの本質は不変です。
技術環境の変遷によって、ウォークマン、iPod、Spotifyとプロダクトは移り変わりますが「音楽を好きなときに好きな場所で楽しみたい」という本質的な顧客の価値観は不変です。
P.F.ドラッカーは、企業の目的は「顧客の創造」であるとし、それはニーズをデマンドにすること、つまり、顧客の潜在的価値観を顕在化することだと言いました。
ユニクロは、生活を快適にしたいという顧客のニーズを、ライフウェア(生活を快適にするための部品)を提供することで顕在化し、
スターバックスは、自宅と職場に挟まれてリラックスしたいという顧客のニーズを、自宅(ファーストプレイス)や職場(セカンドプレイス)でもない、誰もが気軽に立ち寄り、リラックスできる居心地の良い空間、サードプレイス(第三の場所)を提供することで健在化しました。
デザイン思考は、顧客の価値観という本質に基づいて、いまだ顕在化していない製品価値を創造する思考なのです。

デザイン思考経営とDX

次の図は、DXによって企業価値が増大するプロセスを表すDX戦略マップです。

ここでは、DX(デジタルトランスフォーメーション)を、企業がデータやデジタル技術を活用して、デザイン思考経営ができる“体質”へと転換するための手法として位置づけています。
つまり、DXは単なるIT導入ではなく、人間中心の価値創造型経営を実現するための基盤整備であり、デザイン思考経営ができる組織になるための変革プロセスなのです。
DXはデザイン思考経営の事業ライフサイクルの一つの戦略サイクルで実現します。
具体的なDXのプロセスについては、DXプロセスを参照してください。
それから、具体的にDXを導入する場合、下図のように、まず、各DX領域でDXの成熟度レベルを定義します。

その上で、下図のように、DXプロセス×領域ごとのDX成熟度レベルで具体的な計画を立案します。

さて、DX成熟度のレベル4の「プロセスが管理された状態」ですが、これは、マネジメント基盤を構成する各マネジメントが統制され、ガバナンスが働いている状態を意味します。
マネジメントが統制され、ガバナンスを働かせるには、マネジメントを実行する組織と、それを監督する組織を分掌し、監督組織が実行組織を統制する必要があります。

これによって、マネジメントそのものを監督するサイクルが確立し統制をかけることができます。
例えば、BPMの場合、次のように、BPM監査計画に従ったPDCAサイクルで、BPM(PDCAサイクル)そのものを監督します。

データマネジメントの場合も同様で、次のように、データマネジメント監査計画に従ったPDCAサイクルで、データマネジメント(PDCAサイクル)そのものを監督します。

アプリケーションマネジメントの場合も同様で、次のように、アプリケーションマネジメント監査計画に従ったPDCAサイクルで、アプリケーションマネジメント(PDCAサイクル)そのものを監督します。

ITマネジメントの場合も同様で、次のように、ITマネジメント監査計画に従ったPDCAサイクルで、ITマネジメント(PDCAサイクル)そのものを監督します。

デザイン思考経営では、戦略サイクルの設計フェーズで、各マネジメントの型となるポリシー、スタンダード、プロシージャを定義し、運用フェーズで、その内容を遵守して各マネジメントが遂行されているか監督します。

-DX, ビジネス

執筆者:


comment

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

関連記事

データ管理基盤

ここでは、企業のデータを&#19 …

【実践!DX】ビジネスアーキテクチャの設計方法

ビジネスアーキテクチャは&#12 …

【実践!DX】情報資本ポートフォリオとDX投資

今回は、情報資本ポートフ&#12 …

【実践!DX】資産と活動

ビジネスモデルを考える場&#21 …

【UPで学ぶ】システム開発プロセス

ここでは、統一ソフトウェ&#12 …