メインコンテンツへスキップ
見出し画像

「顧客のため」だけでは、デザイン思考を半分しか使っていない|『スタンフォード式デザイン思考』で考える、人事・経営・管理職の問題解決【Case OS BOOKS #98】

    Case OS BOOKS #98

    デザイン思考という言葉を聞くと、多くの人はまず、新商品開発、新規事業、UX、マーケティング、営業提案といった、「外側の顧客」に向けた活動をイメージするのではないでしょうか。

    顧客を観察する。顧客の困りごとを見つける。本当のニーズを探る。アイデアをたくさん出す。プロトタイプをつくって試す。確かに、デザイン思考はこうした領域と非常に相性がいい。

    今回読んだ『実践 スタンフォード式デザイン思考』でも、デザイン思考は「人」を中心に据え、ユーザーの経験を観察し、本当に解くべき問題を見つけ、試作品をつくりながら検証していく問題解決のアプローチとして紹介されています。書籍冒頭から、売上やユーザー数といった数字そのものではなく、人が実際に何を求め、どのような体験をしているのかを見ることの重要性が強調されています。(出典:『実践 スタンフォード式デザイン思考』)

    ただ、読みながら一つの疑問が浮かびました。なぜ、この考え方を顧客に対してだけ使うのでしょうか。

    会社の中にも「人」がいます。社員がいる。管理職がいる。経営者がいる。採用候補者がいる。異動した社員がいる。新任管理職がいる。育児や介護と仕事を両立している社員もいる。それぞれが、会社の制度、仕事、上司、会議、評価、キャリアといったものを日々「体験」しています。

    それならば、人事制度をつくるとき、組織改革をするとき、マネジメントを変えるとき、経営戦略を実行するときにも、デザイン思考は使えるはずです。むしろ私は、現在のように「正解」が見えにくくなった組織では、人事・経営・管理職こそデザイン思考を必要としているのではないかと思います。

    今回は、「デザイン思考=顧客向けの商品開発手法」という理解を少し広げて、会社そのものを、人間中心で設計し直すための思考法として考えてみます。


    今回紹介する本

    『実践 スタンフォード式デザイン思考』

    本書では、スタンフォード大学d.schoolで用いられている考え方をベースに、デザイン思考を、共感(Empathize) → 定義(Define) → アイデア(Ideate) → プロトタイプ(Prototype) → テスト(Test)という5つのプロセスで整理しています。しかも、これらは一方向に進めるものではなく、必要に応じて何度も行き来しながら問題への理解を深めていきます。(出典:『実践 スタンフォード式デザイン思考』)

    ここで重要なのは、アイデアを出すことではありません。最初に置かれているのが、「共感」であることです。そしてその次が、「問題を定義する」です。

    つまりデザイン思考は、「良い答えを出す方法」である前に、「そもそも何が問題なのかを問い直す方法」なのだと思います。


    デザイン思考の本質は「アイデア発想」ではなく、自分の前提を疑うこと

    デザイン思考について研修をすると、ブレインストーミング、付箋、アイデア発想、プロトタイプが印象に残りやすい。だから、「自由にアイデアを出す手法」と理解されることがあります。

    でも、本書を通して読むと、私はそこが本質ではないと思いました。むしろ中心にあるのは、「自分たちは、本当に相手のことを分かっているのか」という問いです。

    本書では、ユーザーインタビューについて、単に「何が欲しいですか」と聞くのではなく、相手の体験、行動、違和感、感情の変化、矛盾などを深く観察することが重視されています。「驚き」「雰囲気の変化」「矛盾」といった小さなサインから、本人さえまだ言語化できていないニーズへ近づこうとします。(出典:『実践 スタンフォード式デザイン思考』)

    ここが、人事やマネジメントにそのまま当てはまります。例えば人事が、「社員はキャリア自律を求めている」と思っている。だから、キャリア研修、社内公募、キャリア面談を導入する。でも社員側は、「選択肢が欲しい」より先に、「今の仕事で何を期待されているか分からない」と感じているかもしれない。

    あるいは、管理職が、「若手はもっとフィードバックを求めている」と思っている。だから、1on1を増やす。しかし若手本人は、「面談の回数ではなく、仕事を任せてほしい」と思っているかもしれません。

    人事制度でも同じです。「社員は公平な制度を求めている」と考え、評価項目を細かくする。でも社員が本当に困っているのは、評価基準ではなく、上司によって運用が全く違うことかもしれない。

    つまり、こちらが解こうとしている問題と、相手が実際に経験している問題は一致しないことがある。

    本書には、表面に見えている問題は氷山の一角であり、本当に解くべき問題はその下に隠れているというイメージも示されています。(出典:『実践 スタンフォード式デザイン思考』)

    これは顧客だけの話ではありません。組織課題でも全く同じです。

    だからCase OSでは、デザイン思考を、デザイン思考とは、アイデアを生み出す手法ではなく、「自分たちが正しいと思っている問題設定」を一度疑うための思考法であると捉えたいと思います。


    人事に必要なのは、「社員のために制度をつくる」から「社員と一緒に制度を検証する」への転換

    人事制度には、少し特殊なところがあります。制度をつくる人と、制度を使う人が、違います。人事が制度を設計する。経営が承認する。管理職が運用する。そして社員がその制度を経験する。この間に、かなりの距離があります。

    例えば人事が、「キャリア自律を促進する制度です」と設計していても、社員側には、「選択肢が増えた」ではなく、「キャリアを自分で何とかしろと言われている」と受け取られることがあります。

    人事から見れば、「公平性を高めた評価制度」でも、社員から見ると、「項目が増えて複雑になっただけ」かもしれない。

    ここでデザイン思考の発想を使うと、人事制度の作り方そのものが変わります。


    制度を「完成品」として出さない

    通常の制度改革は、調査する、設計する、経営会議で決める、説明会をする、全社導入するという流れになりがちです。いわば、ウォーターフォール型です。

    一方、デザイン思考では、まず小さく試す、反応を見る、修正する、もう一度試すというプロトタイピングを行います。

    本書でも、プロトタイプは完成品ではなく、ユーザーから学ぶためのものとして位置づけられています。素早くつくり、早く失敗することで、方向性を修正していくことが推奨されています。(出典:『実践 スタンフォード式デザイン思考』)

    人事制度でも、もっとこの発想があっていいと思います。例えば、新しい1on1の仕組みを全社導入する前に、一部署で試す。社員と上司双方に、「何が使いやすかったか」「何が負担だったか」「どこで会話が止まったか」を聞く。

    評価制度であれば、実際に評価シートを書いてもらう。模擬評価会議をやる。フィードバック面談も試す。そこで起きた問題を見てから全社展開する。

    つまり、人事制度も「つくってから説明する」のではなく、「使ってもらいながら完成させる」という発想です。

    これは社員迎合とは違います。最終的に制度を決めるのは経営です。全員の要望を叶える必要もありません。

    ただ、制度を設計する側の想定と、制度を経験する側の現実のズレを確認する。このプロセスがあるだけで、人事制度の質は大きく変わると思います。


    管理職に必要なのは、「正しい指示」より「部下の経験を観察する力」

    管理職にも、デザイン思考はかなり使えると思います。マネジメントでは、「部下に何を伝えるか」「どう指示するか」「どうフィードバックするか」が重要視されます。でも、その前に、部下が今どんな仕事体験をしているのかを観察できているかという問いがあります。

    例えば、最近、部下の発言が減った。管理職は、「主体性がない」と解釈するかもしれない。

    でも、デザイン思考的には、すぐ解決策を出しません。「なぜ発言しなくなったのか」「会議では誰が話しているのか」「以前と何が変わったのか」「発言したとき、周囲はどう反応したのか」を観察する。すると、本人の主体性ではなく、毎回上司が最初に結論を言っているため、話す意味がなくなっていたということもあり得ます。

    ここで問題の定義が変わります。「部下の主体性不足」ではなく、「管理職が意思決定の余白を残していない」かもしれない。


    1on1でも、「聞くこと」より「仮説を捨てること」が重要

    管理職研修では、「傾聴しましょう」「質問しましょう」と言います。もちろん重要です。

    ただ、本書のインタビューの考え方を見ると、さらに一段深いところがあります。自分が持っている仮説に相手を当てはめないことです。

    本書では、インタビュー時に、答えを提案しない、沈黙を恐れない、矛盾を探す、非言語的な反応も見る、「なぜ」を掘るといった姿勢が紹介されています。(出典:『実践 スタンフォード式デザイン思考』)

    これは1on1にもかなり近い。「最近大変そうだね。仕事量が多いの?」と聞けば、すでにこちらが原因を決めています。

    そうではなく、「最近、仕事はどう?」と聞く。相手の言葉を待つ。「忙しいです」と言ったら、「何が一番そう感じさせている?」と掘る。

    すると、業務量ではなく、「何を優先すればいいのか分からないこと」が負担かもしれない。

    つまり管理職にも、問題を解く能力の前に、問題を正しく見つける能力が必要です。


    経営こそ、デザイン思考を「戦略の実装」に使える

    デザイン思考というと、経営より現場向けの手法にも見えます。しかし私はむしろ、経営にも重要だと思います。特に、組織変革、新しい働き方、DX、AI活用、人的資本経営など、「正解がまだないテーマ」では有効です。

    経営戦略は、考える、決める、実行するという直線で描かれがちです。しかし実際の組織変革は、そんなに簡単ではありません。

    例えば、「出社回帰を進める」と経営が決めた。合理的な理由もある。コミュニケーション、育成、イノベーション。でも、社員はどういう体験をするでしょう。通勤時間、育児、集中できる環境、チームごとの仕事特性によって全く違います。

    それを見ずに、「週3日出社」だけ決めても、期待した成果が出ない可能性があります。

    ここで必要なのが、戦略そのものを仮説として扱うという考え方です。


    経営判断は「決めたら変えない」ではなく、目的を守りながら手段を変える

    デザイン思考では、プロトタイプをつくり、テストし、うまくいかなければ戻ります。本書でも、5つのプロセスは直線ではなく、何度も行き来しながら進めるものだと説明されています。(出典:『実践 スタンフォード式デザイン思考』)

    これを経営へ当てはめると、目的まで毎回変えるということではありません。例えば、「部門を越えた協働を増やす」という目的は変えない。

    ただし、オフィス出社が効くのか。プロジェクト制が効くのか。評価制度を変えるのか。社内公募を増やすのかは試せる。

    経営が守るべきなのは「最初に決めた施策」ではなく、「実現したい目的」であると思います。

    施策に固執すると、「一度決めたから続ける」になります。目的に固執すれば、「この方法で駄目なら別の方法を試す」になります。この違いは大きい。


    組織開発にも必要なのは、「答えを導入する」より「一緒につくる」こと

    人事コンサルティングでも、他社事例、ベストプラクティス、成功企業の制度を求められることがあります。もちろん参考になります。

    しかし、A社で成功した人事制度を、B社へそのまま入れても、成功するとは限りません。

    企業には、歴史、文化、事業、人材、マネジメントがあります。つまり組織は、コンテキスト依存性が非常に高い。

    だから、「正解を持ってくる」より、組織の中の人たちと一緒に、「仮説をつくる。試す。修正する」の方が合う場合があります。

    本書でも、多様なメンバーによるブレインストーミングや、異なる背景を持つ人を組み合わせることで、視点を広げる重要性が繰り返し扱われています。(出典:『実践 スタンフォード式デザイン思考』)

    これを組織開発へ翻訳するなら、制度を人事だけで考えない。現場管理職、社員、経営、場合によっては顧客も参加する。

    例えば、新しい管理職像をつくるなら、人事が「理想の管理職」を定義して終わるのではなく、実際に、部下、管理職本人、経営から、「どんな行動によって助かったか」 「何に困っているか」を聞く。

    すると、人事部だけでは見えなかった管理職の役割が見えるかもしれません。


    ただし、デザイン思考を「みんなで話し合えば正解が出る方法」にしてはいけない

    ここは注意が必要です。デザイン思考は、ユーザー中心、共感、多様性、対話を重視します。だから、「みんなの意見を聞きましょう」という民主的プロセスに見えます。でも、意思決定を多数決にする方法ではありません。

    経営には、判断しなければならないことがあります。人事制度でも、全員が喜ぶ制度はつくれません。報酬差をつける。配置転換する。事業を撤退する。人員構成を変える。厳しい決断もあります。

    デザイン思考は、その意思決定を放棄するためのものではありません。むしろ、判断する前に「何が起きているのか」をより正確に理解するためのものだと思います。

    「共感する。だから、相手の希望を全部受け入れる」ではない。相手の経験を理解した上で、会社として決める。この順番が重要です。


    もう一つの限界|全てを「実験」にしてはいけない

    「プロトタイプ」「テスト」「小さく試す」は非常に有効です。でも、何でも実験していいわけではありません。

    例えば、給与、解雇、ハラスメント対応、労働安全、個人情報のように、失敗のコストが大きいものがあります。社員を相手に、「まず試してみましょう」で済まない領域です。

    だからデザイン思考には、試してよい領域と、最初から一定の品質・法令遵守が必要な領域を分ける視点も必要です。

    プロトタイピングを称賛しすぎると、制度変更によって影響を受ける人間の存在を忘れてしまう。それでは「人間中心」と矛盾します。


    AI時代になるほど、デザイン思考の価値は「アイデア出し」から「問題設定」へ移る

    今なら、アイデアを出すだけならAIがかなりできます。新規事業案を100個。新しい人事施策を50個。1on1の質問例を100個。数秒で出せます。

    だから、「アイデアをたくさん出せること」自体の価値は以前より下がっています。

    むしろ重要になるのは、「何を解くべきなのか」です。

    社員が離職している。AIに、「離職率を下げる人事施策を20個考えて」と聞けば出てくるでしょう。でも、なぜ辞めているのか。どんな社員が辞めているのか。どんな瞬間に辞めたいと思うのか。何が残る理由になっているのかは、現場を見なければ分かりません。

    デザイン思考の「共感」と「問題定義」は、AI時代にむしろ価値が上がる可能性があります。

    AIは答えを大量につくれる。だから人間には、「どの問いをAIに解かせるべきか」を決める力が必要になる。


    Case OSとしての結論|デザイン思考とは「顧客志向」ではなく、「人間中心の意思決定」である

    『スタンフォード式デザイン思考』を読みながら、一番残ったのは、新商品をどうつくるかではありませんでした。問題の中心に「人」を置くということです。

    この「人」は、顧客だけではありません。社員もいる。部下もいる。管理職もいる。経営者もいる。採用候補者もいる。取引先もいる。

    だから、デザイン思考を営業やマーケティングだけのものにするのはもったいない。むしろ、人事制度、マネジメント、組織開発、経営戦略という、人を通じて成果を出す領域ほど使える考え方です。


    Case OSとして今回、最も残したいのは、この一文です。

    デザイン思考とは、「顧客のために考える手法」ではない。
    意思決定によって影響を受ける人の経験から、問題そのものを問い直すための思考法である。

    人事なら、「良い制度とは何か」から始めるのではなく、社員は今、何を経験しているのか。管理職なら、「部下をどう動かすか」ではなく、部下は今、仕事をどう経験しているのか。経営なら、「この戦略をどう浸透させるか」ではなく、「この戦略によって、顧客・社員・現場には何が起きるのか」から考える。

    そして、観察する。問題を定義する。アイデアを出す。小さく試す。反応を見る。修正する。これを繰り返す。


    良い会社とは、最初から完璧な制度を持っている会社ではないのかもしれません。むしろ、自分たちの前提を疑い、現場の経験から学び、仕組みを更新し続けられる会社。そこに、デザイン思考の価値があります。

    そして管理職にも、人事にも、経営にも必要なのは、「私は答えを知っている」という姿勢より、「本当に解くべき問題は、これで合っているだろうか」と問い続けられる姿勢なのだと思います。

    Case OS BOOKS #98


    今回紹介した本

    『実践 スタンフォード式デザイン思考』


    免責事項

    本記事は『実践 スタンフォード式デザイン思考』を起点として、デザイン思考、人事、マネジメント、組織開発、経営についてCase OSとして考察したものです。本書では、人間中心の問題解決を前提に、共感・定義・アイデア・プロトタイプ・テストというプロセス、ユーザーインタビュー、ブレインストーミング、POV、HMW、プロトタイピングなどが実践的に紹介されています。(出典:『実践 スタンフォード式デザイン思考』)

    本文中の「制度を使ってもらいながら完成させる」「経営が守るべきなのは最初に決めた施策ではなく実現したい目的」「デザイン思考=意思決定によって影響を受ける人の経験から問題そのものを問い直す思考法」等は、本書そのものの表現ではなく、本書の内容を人事・経営・管理職の領域へ接続してCase OSとして展開した独自の考察です。

    また、本記事はデザイン思考を万能な意思決定手法として扱うものではありません。法令、安全、公平性、権利保護など、試行錯誤そのものに大きなリスクを伴う領域では、プロトタイピングの適用範囲を慎重に判断する必要があります。
    Amazonのアソシエイトとして、うな重|コンサルが解く、人と組織は適格販売により収入を得ています。

    この記事が参加している募集

     
     
    複雑な問題を、事実・構造・前提・価値・選択肢に分解し、「自分で判断できる状態」に変えるコンサルタント。AI・組織・本・法務・本人訴訟の実践をCase OSとして発信。Amazonアソシエイト参加中。

    あなたへのおすすめ