Blog
ブログ

本当に求められている「業務改革DX」とは ─ DXを加速させるUXデザイン ─。セミナーダイジェスト

多くの企業でデジタルトランスフォーメーション(DX)は経営上の重要な課題となっています。しかし業務の効率化を目指し業務システムを導入しても、現場のユーザーについての深い理解がなければ、せっかくお金と時間をかけて作ったシステムも使われなくなってしまいます。

三菱ふそうトラック・バス株式会社に1人目のITデザイナーとして入社、デザインチームを立ち上げられた三宅 智子さんに、トラック・バスなど商用車のメンテナンスサービスの業務管理のデジタル化に、UXデザインの考え方を適用したプロジェクトについてお話しいただきました。

今回はそのダイジェストをご紹介します。

全編の動画はこちらで公開しています>>

はじめに

皆様こんにちは、三菱ふそうトラック・バス株式会社の三宅と申します。

事前にご質問もいただきまして、ありがとうございます。
その中で、同じようなところを課題に思っている内容もたくさんあり、共感しておりました。

ただ私も、全て答えを持っているわけではなく、一業界の人として挑戦している過程におります。とはいえ、自分が今まで経験してきた中で、皆さんに何かお伝えできることがあればと思い、お時間をいただきました。

話者背景

1社目は株式会社アルムというところで、医療系の会社におりました。その中で人と医療と介護を繋ぐteamというアプリの営業や、大手通信会社さんとの事業提携のアシスタントや活用支援に携わっていました。

そして現在、三菱ふそうトラック・バス株式会社におります。トラックコネクトと言われるトラックのIoTのプロジェクトを遂行後に、現在はどちらかというとDXに近い業務に携わっております。

三菱ふそうでデザイナーというとトラックのデザインを意味していましたが、デジタルのソリューションをデザインするメンバーとしては、「1人目のデザイナー」となります

そして徐々にデザインのニーズを訴求していき、デザインチームのリードをやらせていただいております。もともと国際系学科を卒業しているのでビジネス畑の人間ですが、そこからデザインの勉強をしてきました。

今日は自戒も込めて耳が痛いようなこともお話ししますが、2社のべ9年間DXをやってきた経験の中で「今日明日どういったことをやっていけばいいのか」ということをお伝えできればと思います。

私自身のよくある失敗は「イライラした時に感情的になってしまう」ことや、「事を大きく捉えすぎて動けなくなってしまう」「計画ばかりしてプロジェクトが進まなくなってしまう」など、自分でハンドリングできなくなってしまうことがあります。

話すと長くなるくらい本当にたくさんの失敗をしています。本日は、それらを踏まえて聞いていただけたらと思います。

DXの定義

「DX=デジタルトランスフォーメーションとは」

現日本における解釈の参考
※出典:DX推進指標とそのガイダンス(経済産業省 令和元年7月)

<参考: 「DX 推進指標」における「DX」の定義>
「企業がビジネス環境の激しい変化に対応し、データとデジタル技術を活用して、顧客や
社会のニーズを基に、製品やサービス、ビジネスモデルを変革するとともに、業務その
ものや、組織、プロセス、企業文化・風土を変革し、競争上の優位性を確立すること」

日本企業は、世界平均よりもビジョンと戦略の不足時間と費用の制約を課題にあげる人が多いと言われています。

ビジョンと戦略の不足
 どういう目標に向かっているのか分からない。

時間と費用の制約
 ビジネスをやっている以上基本的にあることだと思います。
 時間もお金も人もあってやりたい放題な環境はなかなかないと思うんですね。

普段から普通に存在していた問題ではあると思うのですが、イノベーションをしようと会社で「DX」を掲げたときに、改めてビジョンと戦略の不足時間と費用の制約が大きな存在としてのしかかってくるのだと思います。

そこでさらに難しく複雑に感じ、お金がない時間がない人がいない、と、なおのこと問題に感じるのかと思いました。

まずはできることから始める

今まで大丈夫だと思っていたことが、DXが始動して「大丈夫じゃない!」「ヤバイ!」となっている状況なのではないかと思いますが、不満を言っていても前に進まないので、まずはできることから始めます。

おすすめの心構え

「爽やかに前にどんどん進めていこう」というのが1番大事なことだと思います。

また、「どういうニーズがあるのか」を把握することから始めるのが、結局は一番前に進めていけるのではないかと思います。

①しなやかに気前よく
・ビジョンがない!→プロジェクトでビジョンを作っていけばいい
・戦略がない!→プロジェクトで戦略を立てていけばいい
※DXは変革を含むため、世で「イノベーションで重要なことはDXにも汎用性が高い」と考える

②Leanを意識する
・お金もない、時間もない、その中で成功させなければいけないのがDX。証拠がないものは全て仮説
・とにかく「具体的」にしていく、自分がある行動を取ろうと思ったらすぐに手順が分かるレベルに
・継続的かつ建設的に成果を上げ続ける仕組みを作っていくことが、必要不可欠

③士気の高いところから巻き込んで拡大させていく
・ニーズのあるところから応えていく
※DXは変革を含むため、世で言うChange Managementで重要なことはDXにも凡庸性が高いと考える

制約とニーズ、リソースの確認と共有

「ニーズがあるところにソリューションを出していくことが効率が良い」ということを考えると、まず誰が何をして欲しいと思っているのかを確認するのが最初のステップだと思います。

課題にあったように時間やお金の制約がどのプロジェクトでもあるので、それを正確に把握することが大事です。

夢とかイリュージョンなどではなく、本当に明日から変革できる企画を出していこうと思うと、実現可能なクリエイティビティを考えることが必要となります。

<できることを洗い出す>
(例)
・お金はいくらかかるか
・時間はどれくらいかかるか
・リソースはどれくらいあるか
・端末は何を使うのか
・ツールは何を使うか

意思決定の理由の明記と、効果的なRetro&Working Agreement

メンバーの成長のためにやったこと

下記のような課題があったとします。

課題「メンバーのプロジェクト参加目的や、期待成長が曖昧なことにより プロジェクトのモチベーション低下が生じる傾向が見受けられる」

どうしたらいいか分からない状況の時に、一人ひとりのモチベーションは大事になってきますが、自分が直接メンバーに干渉できるかできないかで変わってくるかと思います。

干渉できる場合

自分が指導していい相手の場合、(端的に言うと)求人サイトで好きな求人を3つくらい見つけてきて要約し、そこに書かれている人物像や求められているスキルをまとめてもらいます。

達成していこうとする中で、プロジェクトの中で「できること」「やらないこと」を仕分けます。それが終わったら、「こういう姿勢で、こういうプロジェクトをやります」とメンバーの前で宣言してもらいます。

干渉できない場合

外注派遣や他部署など、自分が直接指導することができないメンバーがいた場合は「プロジェクトにはこういう姿勢で臨んでほしいけどどうかですか?」と伝えます。実はメンバーの前で言えなかった課題などを抱えているようなことがあるので、対話を進めていくと、高度で複雑なプロジェクトに抵抗感がある人もいます。

心地良い環境で仕事がしたいと思う人には、お互いにベストフィットするように環境を変えたりなどします。これらを実行するためには、いつ誰がいなくなっても大丈夫な状態にしておくプロジェクトが重要になり、そういう意味でもWorking Agreementは大事だといえます。

リサーチと改革を進める

UXを一人で始める際に行ったこと

目的とビジョンがよくわからない場合、まずは「これを目先にやってほしい」と言われていることにテンポよく対応していく。ただ、対応していくうちに「これ本質的じゃないな」「デジタル化が目的化してる」と感じてくることもあると思います。

それをどう変えていくか?と考えたときに、言われたことをどんどんこなしつつ、水面下での動きも私は大事かなと思います。

社内での自分自身の信用と実績を積みながら、「本質的な課題はこれだから、これをやった方がいい」とどんどん考える。そして、プロジェクトの次のフェーズにいく直前に「次はこれをしたほうがいいと思う」というのを、タイミングを狙って打ち込んでいきます。

その中で、先ほど個人のモチベーションの話をしたと思いますが、やはり自分がやりたいことや、プロジェクトの中でどういう関わり方をしていきたいか、というのはあると思うので、同時進行で体制も整えながら、自分のUXかつDX全体を先手先手で進めていく、というイメージになります。

事実証拠を収集、不足を洗い出す

最初にとにかく、資料には全部目を通します。やりたいことがたくさん出たときには、「それをどうしてやりたいのか?」「うまくいくのだろうか?」など根拠がないこともたくさんあると思いますので、そういう事をひたすら洗い出します。

仮説を当てて、その差異の影響と大きさを考える

「じゃあ、これがうまくいったらこうだけど、うまくいかなかったらこうだよね」という仮説を出します。つまり、自分で出した疑問「これってうまくいくんだろうか?」の仮説の回答を自分で出します。自問自答するんですね。

そうすると、コストやタイムラインへの影響などが出るポイントが見えてきますこの辺が仮説思考だと思うのですが、一番プロジェクトにとって大きなリスクになってきます。そこが、周りの人に訴えるべきところであり、リサーチを入れていった方が良いと思うところです。

単純な疑問をひたすら書き出す

ペルソナが持っている業務携帯は「スマホ?ガラケー?」「それは今後変わる?」など、単純に「分からない」と思ったことを書き出します。これによって、どんなインターフェースのプロダクトを作るべきかが大きく変わってきます。

業務フローを仮に作ってしまう。

業務フローの仮説を一度立ててみると、「なぜこの人がこの作業をしてるの?」「ここの業務フローは何を基準に分岐しているの?」など、ここでもたくさん疑問が出てくると思います。

この「よく分からない」という疑問が、リスクになったりうまくいく要因にもなるので、このような状態をメンバーに説明するのが大事になってきます。そこからコストとタイムラインの話を持っていくイメージになります。

基本的な出戻り作業のコスト、タイムラインへの影響

基本的に、事前の理解と確認がないと出戻りが多いということになりますので、「今、先に確認しておいたらこれくらいの工数で済んで、これくらい早く終わりますよ。」と、提案しながら進めます。

※普段はおおよそこのような流れで進めています。

そのようにやっていくうちに、「知らないことってたくさんあるんだな」と感じてもらえたと思いました。

私がデザインチームを構築していったイメージ

UIとUXの違いなども私は半年くらいかかりましたし、とりあえず手が足りなかったので、「手伝ってほしい!」ということで参加してもらったのが、ハーフタイムの学生さんや業務委託の外部の方でした。
そして、確認して明らかにしていくと、「プロジェクトがどういうことをしたかったのか」「こんな不確定要素があったままで進めようとしていて危なかったね」など、分かってきました。

メンバーが増えた流れ
まずは1人で効果と実績を出す→メンバーが増える→次はこういう結果が出たのでこういうメンバーが欲しい→メンバーが増える

このように、効果と実績を出していき、段階的に「メンバーを増やしていいよ」という流れになりました。

私が日常的に回しているリサーチの規模、深度の大小

例えば、いきなり500万の予算を組んでリサーチを進めようとしても、予算をもらえなかったりするので、上記図のサイクルのように「自分で直接得られるデータ全てを取得する」ところから小さくスタートし、リサーチができることを確認したり、リサーチの幅や深みを増やしていきます。最初から3ヶ月フルタイムで10人でリサーチ!という感じではありません。

DX現場の例

ユーザーの行動の理由を、すべて言葉のロジックと物理的証拠で証明できるまで調べます。
下記の図はサービス事業部の方々で、「サービス品質向上に繋げられるか?」というテーマで進めているところです。

下記の図は、付箋を使って各ステークホルダーのプロジェクトへの期待や、部署目標、目的にどう影響しているかを説明している風景となります。前後関係がどう繋がっているかが見えてくるもので、前と後ろに何があるかが大事になってきます。

まとめ〜今日から自分一人でも始められること〜

Q&A

Q:業務フロー改善のフロー書き出しに関する質問です。三宅さん目線のご意見をお伺いしたいです。フロー書き出しは、全社員に向けて行った方がいいでしょうか?それとも、例えば30人をピックアップして書き出しを行った方がよろしいでしょうか?
背景としまして、社員1000人以上の規模の企業のフロー書き出しとなると、書き出す期間/書き出しの集計の時点で莫大な時間がかかり、現実的ではないと考えています。

A:業務フローに時間がかかるのは、同じように私も書いている身としてすごく分かります。やっぱり小さく始めるのがすごく大事だと思っています。まずは会社として一番課題に感じている部分、変革したい部分から始めるといいと思います。

変革が必要と感じる部分に対してアプローチをするためには、「ここまでわかったらとりあえずここは始められるな」というのがわかるはずなので、その程度で止めて一回何かソリューションを出してみて、それが効果的に働いているか考えてみる。うまくいかなかったら粒度を細かくしていくか範囲を広めていく、とやってみたらいいと思う。

最初から1000人規模の全員分はやらなくていいと思います。一番高次元の一番改善した方が良さそうなところからスタートするのが良さそうだと思います。

Q:利用者はこれまでのフローを変更することに対して抵抗感があると思いますが、新しいシステムを使ってもらうようにするためにどのようなことをされましたか?

A:3つあります。

1つ目は、「試しにやってみましょう」というアプローチの仕方をすることですね。「やってください、絶対ですよ」とせまっていかない。

2つ目は、業務フローを変える際に、小さい単位に落とし込む。「1ヶ月目は今やっている1〜10まであるうちの、3番だけこれで代わりにやってみてください」「来月は1〜5の範囲まで、再来月は6〜10の範囲までやってみてください」。段階的に成功体験を積めるように細かく落としていくというのをやっていきます。

3つ目は、絶対に既存のフローを否定しない。「今やっていることは大変ですね、私たちのやり方のほうがいいですよ」というのは絶対にやらない。お互いリスペクトを持って、「今1つのことやるのに35分かかってるのを15分に縮めてみたいので、一緒にやってみませんか?」というようなアプローチをします。

Q:29ページ目の時間軸は、どのくらいかかっていますか?

A:時間で言うと4年くらいかかっています。ただ、この間に私がプロジェクトを変わったりしているので、またイチから振り出しに戻ることもある。1つはインターンや業務委託の方がいた、次のプロジェクトではまた1人で始まる、ということをやっていたりします。

Q:情シスについて、システム化の話(デジタライズ)がくるが、部署最適になっている面がある。横ぐしでやらないとDXの効果が薄いと感じているが、どこが予算を持つのか、という話で進められないことがある。全体の巻き込み方のヒントはありますか?

A:予算関係になってくると、上層部の力がいると思いますので、可能であれば社長レベルの方から「お互い出し合いなさい」と、鶴の一声を出してもらうのが最も事が進むのかなと思いますが、社長にお願いできるパイプがない場合もあると思います。

その場合は、例えば「じゃあ今年は私たちが1回出すね、次はまたその時の状況で話し合おうね」というようなやり方も大事かと思います。

また、上長が予算を出したくない場合は、予算をうちのチームで出して、「こういう風にうまくいったらうちのチームの株が上がって・・」、といったように、未来に繋がるような話をできればいいのかなと思います。

Q:UXリサーチをするときに、共感マップやカスタマージャーニーマップなど、アジャイルでよく登場するフレームワークを使って現状を明らかにされますか?それとも、フレームワークにこだわらず、業務フローや、究極は箇条書きなどでやられたりしますか?

A:あまり私はフレームワークを使っていません。どのフレームワークを選ぶのかの議論に時間を使うともったいないと思いますし、特にBtoB環境では全然状況が違うと思いますので、あくまでも「自分たちはこういうことを明らかにしたい」と思った時に、フォーマットに求める要件というのが出てくると思います。それで使えるものがあれば使えば良いし、なければ自分で生み出していくのが良いと思います。

Q:プロジェクト推進とは別に、社内へのUX浸透活動などは行いましたか。ある場合、どんなことをされてきましたか。

A:大きく分けて3つほど行いました。

1つは自分の休み時間を使って3ヶ月間社員10人くらいに向けて2週間に1回ほど、UXの輪読会をしました。

そこから、一般職員のメンバーが自分たちのプロジェクトに行って「管理職の巻き込みがいる」という話になったので、その後私の場合はITの管理職20人くらいに向けて、デザイン志向のワークショップをドイツの本社の人を巻き込んで一緒にやることで、グローバルのヘッドクォーターレベルでも「こういうことやった方がいいと言ってるんだよ」というのを外から言ってもらう、というのをやりました。

また、近年社内でカスタマーエクスペリエンスというイニシアチブが立ち上がったので、それに対するアドバイザリーみたいなことをやっています。プロジェクトやりつつ啓蒙活動も出来る限り同時にやっていたりします。

Q:DXの目的がはっきりしないときに、会社や幹部のせいにするのではなく…というのは重々承知しつつも、では、どんな目的や効果を発揮させるか?を具体化する必要はあると思います。DXで発揮したい効果が曖昧なとき、どうやって会社公式の目的・目標にしていっていますか?

A:先ほどの自問自答するに関わってくると思うのですが、「目的が曖昧だ」となったときに、「じゃあ選択肢は何が有り得るのか」というのを書き出し、その中で「それが1番売り上げや利益に貢献するんじゃなかろうか」という推測を一個二個選ぶ。「今こういう情報と前提条件の元で、これを掲げてやっていきます」と。

ただ「前提条件変わったら、また更新します」という留意事項付きで公的に掲げる。だから「この前提条件変わったから、目標も更新します。目的も変えていきます」というのを、その後柔軟にやっていけるようにしています。

Q:今、リサーチするとき、なかなか現場のフィールドワークしにくいと思いますが、どのようにやられているか、ヒントはありますか?(リモートワークの面で)

A:「できない、やれない」ということは、優先順位が下げられているという話だと思うので、そこから優先順位を上げてもらうために、「なぜそれが大事なのか」「こういう準備で行くから、こういうことやらせてください」というのを事前に話をしていくことで、むしろ「来てー」とか、「じゃあこういう風にやってくれたらいいよ」となるので、

「行かせてください」ではなく、「どういう目的のために、どう言うことが知りたい」ということをご説明することで、双方合意するまで議論する。それでも「現地に来ないでください」となったら、「行かなくてもできることから始める」となると思います。

セミナーの内容は以上です。

【無料Ebookダウンロード】今日からできる!ユーザーテスト入門

500回以上のユーザーテスト経験を踏まえて、現場で実際にできる「簡易ユーザーテスト」について、準備の方法、当日の進行のコツ、レポート作成のパターンなどを余すところなくご紹介! 実際のテスト様子の動画教材もあるので、習得しやすい!