Technical Blog テクニカルブログ
  1. HOME
  2. テクニカルブログ
  3. 【デネクトの和】#9 【前編】現場の熱意を引き出すDX、デザイン思考で「課題の核」を見つけ出す方法

【デネクトの和】#9 【前編】現場の熱意を引き出すDX、デザイン思考で「課題の核」を見つけ出す方法

投稿者:danect⁺コラム


DXプロジェクト、うまく進んでいますか?

近年、DX(デジタルトランスフォーメーション)への取り組みは、多くの会社でも積極的に取り組まれる業務の1つとなりました。
しかし、実際にやってみると当初想定していた成功イメージから大きくかけ離れてしまった・・・という事はありませんか?

「デジタルツールを導入しても、現場が使ってくれない」

「上層部から『DXをやれ』と言われたが、現場は何がしたいか分からない」

「プロジェクトの目的が『新しい技術の導入』になってしまい、現場でのメリットが見えない」

なぜこういう状況に陥るかというと、プロジェクトが「技術先行」または「経営層の指令先行」で進んでしまったことが挙げられます。このような“やらされ感”に満ちた取り組み方では、真に組織を変える力にはなりません。

DXとは、デジタル技術を用いて「業務」を変えることではなく、「人々の働き方や、顧客への価値提供のあり方」を根本的に変えることです。そして、その変革の核は、「課題の発見力」と、「現場を巻き込む力」にあります。

今回は、私たちが提供する「danect⁺課題解決ワークショップ」でも核とする考え方である「デザイン思考」を応用して、現場の熱意を引き出しながらDXを成功に導くための実践的な4つステップを前編・後編に分けてご紹介します。


Step1 技術に先行せず、真の課題はどこに隠れているのか?を見極める

多くのDXプロジェクトが失敗する最初の原因は、課題の特定をせずにソリューション(技術)から入ってしまうことです。
現場には、目に見える「表層の課題」と、その下に隠された「真の課題(課題の核)」があります。
分かりやすくまとめると以下の通りです。

  表層の課題(症状): 「会議が多い」「紙の書類が多い」「システム入力に時間がかかる」など、目に見える問題点

  真の課題(病根): 「会議の目的が曖昧で決定権者が不在」「必要な情報が分散していて集約されていない」
           「入力作業ではなく、情報の共有や活用に価値を感じていない」など、行動や意識の根本に
           ある構造的な問題

技術先行のアプローチでは、この「表層の課題」に飛びつきがちです。 例えば、「会議が多い」という課題に対して会議をいつでもどこからでも出来るようにするために「オンライン会議システムを導入」しても、会議の目的や進め方が変わらなければ、場所がオンラインになっただけで、無駄な時間は変わりません。

「課題の核」を見つけるためのデザイン思考アプローチとは?

「課題の核」を見つけ出すために、私たちはデザイン思考の最初のフェーズである“共感”に全力を注ぎます。これは、プロジェクト担当者が認識している情報だけで進めるのではなく、徹底的に現場の視点に立つことを意味します。実際にどのように行うのか、以下にポイントをまとめました。

【実践テクニック:共感マップの作成と5回の「なぜ」で原因を深堀り】

  1. 現場を観察する(シャドーイング):
    • システムを操作している時、現場の担当者はどこで手が止まるか、どんな表情をするかを観察します。
    • 単に「Aという作業をしている」だけでなく、その作業中に「誰と、何を話しているか」「何を考えているか」をメモします。
  2. 共感マップを作成する:
    • 現場担当者が「何を見て(See)」「何を聞き(Hear)」「何を考え、感じ(Think & Feel)」「何を言い、行う(Say & Do)」を整理します。
    • 特に重要なのは、「Pain(不満・不便)」「Gain(達成したいこと)」を浮き彫りにすることです。
  3. 「なぜ(Why)」を繰り返す(5 Whys):
    • 表層の課題(例: システム入力に時間がかかる)に対して、「なぜ?」を5回程度繰り返し、真の原因にたどり着きます。

    「なぜ(Why)」を繰り返す(5 Whys)」について、わかりやすく例を挙げてみます。
     (生成AIに頼んで作ってもらいました。)

  例:システム入力に時間がかかっている

  Q1: なぜ入力に時間がかかるのか?
   → A1: 必要な情報が3つの異なるシステムに分散しているから。

  Q2: なぜ情報が分散しているのか?
   → A2: 部署ごとに独自のシステムを使ってきた歴史があり、互換性が考慮されていないから。

  Q3: なぜ部署ごとに独自のシステムを使うのか?
   → A3: 部署間の連携よりも、部署内の効率が最優先され、全社最適の視点が欠けていたから。

  Q4: なぜ部署内の効率が最優先されてきたのか?
   → A4: 現場の評価制度が縦割りで、他部署への協力や全社的なデータ利活用が評価に反映されないから。

  Q5: なぜ全社的な貢献が評価されないのか?
   → A5: 評価基準が「目標達成度」のみに偏り、「プロセス」や「他部署との協調」といった無形の貢献を
      測定し、言語化する仕組みが存在しないから。

この例でいえば、「課題の核」は単なるシステム統合ではなく、「全社最適を促す評価制度や組織文化の欠如」である可能性が高いことが見えてきます。技術的な解決策を考える前に、まずこの構造的な課題に目を向け、「人々の働き方や意識」を変えるアプローチが必要になるのです。


Step2 デザイン思考による「課題の定義」と熱意の巻き込み方を知る

「課題の核」が特定できたら、次はその課題を現場が「自分ごと」として熱意を持てる形で再定義する必要があります。次からは、どのようにすればうまく再定義できるかを、2つのポイントでご紹介します。

ポイント1 課題を「How Might We(どうすれば〜できるだろうか)」で定義する

課題を明確化するフェーズ(このフェーズをDefine:直訳だと定義する という意味です)では、発見した真の課題を、「解決の可能性」と「現場の熱意」が湧き出る問いの形に変換します。これが、デザイン思考で用いられる「HMW(How Might We:どうすれば私たちは〜できるだろうか)」の問いと言われるものです。

例を挙げるとこんな感じです。

 例① 真の課題HMWの問い(解決すべき課題の定義)
     →縦割りの組織・評価制度のため、部署間の情報連携が遅い
    この場合のHMW
     →どうすれば私たちは、部署の垣根を越え、お互いの情報活用に感謝し合える仕組みを作れるだろうか?

 例② 真の課題HMWの問い(解決すべき課題の定義):マニュアル作成が目的化し、現場が使いたい情報が
                          書かれていない
    この場合のHMW: どうすれば私たちは、マニュアルを読む時間よりも、顧客に向き合う時間が増える
             情報共有の仕組みを作れるだろうか?

この例でいうと、「縦割り組織」や「マニュアルを読む時間」というネガティブな要素の言葉を、「感謝し合える仕組み」や「顧客に向き合う時間が増える情報共有」というポジティブな解決志向の問いに変換することで、現場は一気に「自分たちが何を達成したいのか」をイメージしやすくなります。熱意は、ネガティブな指摘ではなく、ポジティブな目標設定から生まれるのです。

ポイント2 「インサイト」と「ペルソナ」で現場の共感を深める

課題を定義する際、具体的な現場担当者の「インサイト(深層心理)」と「ペルソナ(典型的なユーザー像)」を明確に設定します。これはマーケティングでもよく使われる手法です。
では、インサイトとペルソナについてそれぞれ見ていきましょう。


インサイト(深層心理)
インサイトとは今回のDXプロジェクトを成功させるために不可欠な、現場ユーザーの行動や発言の裏側にある深層心理や無意識の動機のことです。自分自身でもうまく言語化できていない、行動の根源にある本音や願望を表しており、「〜したいわけじゃない。本当は〜したいだけだ」という形式で表現します。

 インサイトの例を挙げるとこんな感じです。

 例①「私はマニュアルを改善したいのではない。マニュアルを作成する無駄な時間を減らして、早く帰って家族と過ごしたいだけだ」

 例②「私は新しいシステムを使いたくないのではない。これ以上、自分のミスで他部署に迷惑をかけたくないから、慎重になっているだけだ」

この生々しいインサイトをプロジェクトの目標として共有することで、「ああ、自分の言いたいことはこれだ!」と現場担当者が共感し、「このプロジェクトは私たちのためのものだ」という当事者意識(熱意)が芽生えます。


ペルソナ(典型的なユーザー像)
ペルソナは、架空の人物像ではありますが、実在のユーザーを深く理解するために、徹底的に具体的かつ現実味のある情報で構成することが重要です。
DXや業務改善のプロジェクトにおける「現場の熱意を引き出す」ためのペルソナ作成に必須となる13項目とそれぞれのポイントについても、ちょっと細かいですが今回は敢えて確認してみましょう。

 基本属性(Who)
 ペルソナの背景を理解するための土台となる情報です。

No.項目説明
1名前・年齢実在感を持たせるため、具体的に設定します。
2部署・役職組織内での立ち位置や権限、日常的に関わる業務範囲を明確にします。
3勤続年数業務への習熟度や、既存のやり方への慣れ(慣性の強さ)を推測するために重要です。
4スキルレベルITリテラシー、特定のソフトウェアの使用経験、新しいツールの学習意欲などが該当します。

  日常業務と行動(What & How)
  ペルソナの「行動」を理解し、どこに課題が潜んでいるかを探るための核となる情報です。

No.項目説明
5主な業務内容日々、最も時間を使っている具体的なタスク(例:データ集計、顧客対応など)を列挙します。
6業務プロセス業務を行う際の手順(例:システムAからデータをダウンロード → Excelで加工 → システムBに入力)を具体的に記述します。その中で「どこで手が止まるか」が重要です。
7利用ツール日常的に使っているシステム、ソフトウェア、アナログツール(例:FAX、紙台帳)を明記します。
8人間関係業務で頻繁に連携する部署や人物(例:営業部門、上司、他部署の担当者)を記述します。

  感情と動機(Why & Feeling)
  ペルソナの「熱意」や「抵抗」の源泉となる、最も重要な項目です。この項目こそが、デザイン思考における「インサイト」につながります。

No.項目説明
9Pain
(抱える不満・課題) 
「表層の課題」と「真の課題」の両方を記述します。
例:システム入力が面倒(表層)→ 入力作業に価値がないと感じている(真の課題)
10Fear
(恐れていること)
変化によって失うもの、起こり得る最悪の事態。
例:新しいシステムでミスをし、部署に迷惑をかけること
11Motivation
(動機)
業務改善を通じて達成したい個人的・仕事上の目標。
例:単なる作業者ではなく、戦略的な役割を担いたい
12Gain
(獲得したい利益)
変化によって得られる具体的なメリット。
例:残業を減らしたい、上司に褒められたい、顧客満足度を向上させたい
13インサイト
(深層心理)
ペルソナの行動の根底にある、本人も気づいていないかもしれない本音を、一人称で記述します。
例:「私は効率化したいのではない。もっと自分の仕事に誇りを持ちたいだけだ。」

以上がペルソナ作成に必要な13項目です。「なんだか大変だな・・・」と思われた方も多いでしょうが、実際にペルソナ作成を行う際には、以下3つのポイントを意識していればOKです。

・実在のデータに基づくこと
アンケートやインタビュー、現場の観察(シャドーイング)を通じて得られた、生の声を基に作成することをおすすめします。

・感情移入できること
プロジェクトチームの全員が、そのペルソナの立場になって「どう感じるか?」を議論できるレベルまで具体化しましょう。

・絞り込むこと
すべてのユーザーの平均像を作るのではなく、プロジェクトの成果に最も影響を与えるキーユーザーに焦点を絞って作成しましょう。複数のペルソナが必要な場合もありますが、最初は核となる1~2人に集中することが成功の鍵です。

インサイト及びペルソナを作成する=誰のためにデザインするかを明確にして、検討の軸と意思決定の基準を作るという重要なポイントになります。これらが明確になることで、ユーザーの心に響く革新的なアイデアが生まれやすくなります。


今回はここまでです。

いかがでしたでしょうか。今回ご紹介した内容が、皆さんのDXプロジェクトを進めるための一助になれば幸いです。
次回の後編ではMVP(実用最小限の製品)思考や継続させる「仕組みづくり」についてご紹介いたします。

日本情報通信(NI+C)の「danect⁺ 課題解決ワークショップ」は、今回ご紹介しているデザイン思考とMVP思考に基づき、現場の当事者意識を最大化しながら、短期間で真の課題の発見から実証用プロトタイプ作成までを支援する実践的なプログラムです。

皆さんの「変えたい」という情熱を、確かな成果と現場の熱意に変えるため、私たちは伴走支援いたします。

サービスの詳細はこちらから→ danect⁺課題解決ワークショップ


  お客様のデータ利活用やAI導入をご支援します

豊富な導入実績をもとに、貴社に最適なシステムデザインから運用までを一貫してサポートいたします。
ご関心・ご興味がございましたら是非お気軽にお問い合わせください。

ページのトップへ