では、実際にどのようにDX施策を進めていけば良いのでしょうか？
今回のコラムでは、DXの基本的な進め方を記載します。
DX実現の流れ
DXする上でまず必要なことは、DXの目的を定めることです。
顧客や従業員への新たな価値提供を、どのように成し遂げたいのかを考えましょう。
顧客相手の場合は、例えば、新サービスによって新たな商品を届けたい・既存の商品価格を下げることで顧客に還元したい・商品のレベルを上げ今までよりも良いものを提供する等、顧客のためになることを考えます。
コツとしては、顧客のことを考えるときは顧客行動や広告を見たときの顧客心理を想像してみることです。他にも理想のカスタマージャーニーを考えるということもあります。理想の顧客像を思い浮かべ、その購入ロードマップを考えてみます。
ある顧客のAさんがいるとします。Aさんは、あなたの会社の広告を見てその商品が欲しいと思い、店舗へ行って購入する。その商品もAさんにとっては理想的なもので、リピーターになってまた利用していただく、というジャーニーを考えたとき、実際の顧客と比べてみて、そうなっているでしょうか？
Aさんと実際の顧客の差は何であるのか、どうすればAさんのようなお客様が増えるのかを考えることで、DXする部分が見えてくることもあります。
従業員への価値提供の場合は、業務の効率化により残業を減らしてあげる・ボーナスアップやベースアップを狙う・業務上のストレスを少なくするなど、従業員のためになることを考えます。
また、社内の業務改善では、身近な業務について考えると見えてくることもあります。今ある業務の課題をso what（だから何？）構文で深掘りしていくというのもやり方の１つです。
”毎回報告書を書くのが煩雑である”という業務上の問題点があるならば、「煩雑であるから何？」と自分に問いかけます。そこから「煩雑だから他のことをする時間がとれない」「煩雑だから適当に書いてしまう」「煩雑だから残業になってしまう」といったようにあらたな問題が見つかってきます。そこからまた深掘りして「他のことをする時間がとれないから何？」「適当に書いてしまうからどんな影響がある？」と詰めていくことで根本の問題が見えてきます。根本の問題が見えて初めて対策をねられるので、この作業は有効的です。
社会の変化から業務やビジネスを見直すということも考えられます。これは顧客・従業員・社内全てへの価値提供に使えます。
最近では、SDGsの目標や働き方改革、それらに伴う助成金の導入や新NISAの開始など色々な社会の仕組みが変わってきました。その仕組みの中で自社では何ができるのか、何をしなければならないのかを考えることからも、DXの目的となるような価値を見つけ出せるかもしれません。
このとき、ブレインストーミングをしてアイディアを出したり、過去の社歴や基幹システムの設計履歴からどんなことができるのかを考えていくことをおすすめします。
ブレインストーミングは、先ほどの目的探しの時にも使える方法です。まずはたくさんのアイディアを出して、そこから実現可能そうなものや優先事項の高いものを絞っていきます。
非現実的なアイディアや一見業務とは何の関係もなさそうなものであっても、最初からはねのけるのではなく、候補として置いておくことが重要です。
目的を定めるということは、DXの対象となる業務領域を定めることです。
重要なのは価値をどこまで提供できるのかということ。
コスト削減や業務システムの廃止が目的なのではなく、それをすることで顧客・従業員・社会にどのような価値を提供できるのか、を軸に考えることが重要です。
そこを間違っていると、コスト削減は成功したけど他の点で上手くいかない・DXはひと段落完了したものの、新たに提供できた価値がないなど、成果が思った通りにならないこともあります。
さて、さまざまな目的が見つかったとしましょう。次は、実際にどのようなDXをするかの立案をします。
大まかに言うと、現在の業務を見直し、具体的な課題を洗い出し、その解決のために使えそうなデジタル技術やITシステムについて設計をします。
まずは見つけた課題に対して、仮説を作りましょう。仮説、というと難しく聞こえるかもしれませんが、簡単にいうと、「その課題を解決させるためにできそうな対策」なので、気負わなくても大丈夫です。
課題がたくさん見つかった場合も、もっとも優先順位の高い課題から解決させていくことが重要です。全てを最初から完璧に一括で問題解決するのではなく、一番重要そうな課題を解決できるような対策を考えます。最初は小さなステップで良いです。
その対策も、絶対にこれで解決する、というようなものではなく「解決できそうな対策」といった確度の低いもので構いません。それを試してみて、成功すればより強化していきましょう。失敗すれば、また他の対策を考えてみましょう。
この「まず対策を試してみる→成功or失敗する」という仮説検証の1セットをPoC（Proof of Concept）と言います。
現在の業務を見直す、といったときに一番簡単なのは、業務フローを図として書くことです。
まず、その業務に登場する人物を書き出します。
レストランのホールの作業を見直したい場合は、シェフ、レストランのオーナー、ホール担当の従業員やアルバイト、お客様、食材を運んでくる運送業者、レストランがフランチャイズの場合は本社の社員…など一見関係なさそうに見える人物も書き出してみます。
その上で、現在の業務フローを項目ごとに書き出し、またその項目ごとの課題や修正できそうな案を書き出します。それらを最終的まとめ、この業務に対して行えそうな仮説を作り上げます。
業務フロー図は、新たにこの業務に関わる全ての人にとって有益なものとなりますので、丁寧に作ることが必要です。もしその情報が古いものであれば、更新していくことも重要になってきます。
業務フロー図を書くとき、1項目の単位は、フローの中で次の人にタスクが渡る時を意識するとよいでしょう。レストランで言うと、シェフが料理を作る、が1つの項目です。その料理をホール担当の従業員が運ぶので、タスクはシェフからホール担当者へと変わっています。もし、より細かく項目を刻みたい場合は、別のフロー図でその部分のみをピックアップして書くと、フロー図がごちゃごちゃにならずにすみます。
フロー図が書けたら、その業務内容から、問題となっている箇所を探し出します。そして効率化できないかを考えます。
実際によく使われるのは、「自動化」「廃止」「標準化」の３つです。
その業務をデジタルの力などで「自動化できないか」
冗長になっている工程は「無くせないか・減らせないか」
パターンが多かったりカスタマイズが多用されている部分は「標準化できないか」
これらをフロー図で書いた項目に当てはめてみて、業務の効率化を考えます。
フロー図の中で効率化できそうな部分を課題として設定し、それがどうなったら理想的なのか・解決したらどうなるのかを考えます。
その後、解決させるためには、どのようにすれば良いのかを考えます。例えば、課題が「予算編成の承認プロセスが長く、手戻りが多い」という場合、実現したいことは「承認プロセスの中で、形骸化していて流れ作業のようになっている上長からの承認を無くす」「いちいち紙の書類を手渡しして承認ハンコをもらっているので、今後はシステム化してハンコも電子印に変更する」という解決策が考えられます。
具体的なその手段としては、紙の予算編成書類をデジタル上で入力できるシステムを構築、導入することでシステム上で予算編成を行うようにする」といったようなことです。
この課題、解決策、その手段まで考えると仮説のアイディアを立てやすくなります。
業務フロー図を作り、課題、解決策、その手段まで考えられたら、DXした後の業務フローを想定して新フロー図を未来予想して作ります。
その新フロー図では、業務は改善できていますか？
1つの作業の全体時間が少なくなっていたり、一人あたりの作業数が減っていたりすると効率化されている可能性が高いです。
ただし、効率化を優先させて本来の作業の意味が薄れるくらい簡略化してしまったり、作業の質が落ちてしまうことは避けるべきです。自動化するために導入するシステムを作るのにも時間は必要になります。もし、不必要な自動化を採用しようとしていると逆に非効率になることもあります。
また、当初のDXの目的である顧客満足度や従業員満足度を損なうようなフローになってしまっていないかも確認が必要です。
新システムを導入する場合のポイントは、本当に必要な物だけを追加・削除するということ。例えば、今使っているシステムが使いにくい・作業が煩雑、という理由から新システムを導入しようとする場合、全てのシステムを変える必要は果たしてあるのでしょうか。
そのシステムの特定の部分のみ使いにくいということなら、その部分のみアップデートをかける方法もあるでしょう。
あるいは、例えば、画面のボタンがわかりにくいなら画面の部分をわかりやすく改修したり画面の部分のみ更新した新システムを開発し今のシステムに連携させたり、データが重くて動作性が悪くて使いにくいのであれば、より処理レベルの高いDBにしたり保持するデータの優先順位を見直してみたりすることができます。
他にも、特定の部分のみ他のシステムと連携させ、その他システムを使うこともできます。今はAPIなどを使い、1つのシステムに別のシステムの機能を追加できるものも多いです。
本システムに連携しているサブシステムのサービスが終了したとしても、そのサブシステムを他のツールと置き換えれば作業自体は滞らせずにすみます。小さいサービスを連携させて使うことにもメリットはあるのです。
現状使っているシステムを全て変える必要があるのかを含め考えてみましょう。
これまでアナログな作業をしていて、今からクラウドサービスやデジタルサービスを導入したいという場合、クラウドサービスを紹介している情報サイトを見て探すこともおすすめです。（「ITreview」「G2」が有名です。G2は海外ツールも多いのでグローバル化を強化したい企業や外資系企業で使えるかもしれません）
実際に立案ができたら、改善プロジェクトを立ち上げ、経営層なども巻き込んでDX施策を実現していきます。
この時、DX施策を周囲に理解してもらいやすくするために、DX実現までの道のりを達成目標のステップごとに分解して提示すると良いです。このステップ1つ1つがPoCとなります。
最初のステップは、導入する内容による簡易的な効果として、わかりやすく顧客満足度や従業員満足度が増えることを確認できるようなもの。
次のステップは、そこから少し進んで導入したシステムによってROIを高めるような工夫を取り入れます。
最後に、「今後こうなったらいいな」という理想も混ぜた、少し大きな目標を込めたステップを持ってきます
例えば、コールセンターで今まで人力でやっていた部分に関して、応答をチャットボットに任せ、簡単な質問や問い合わせ程度であればAIに自動で処理してもらい、より複雑な問合せには後日担当者が折り返す、というシステムに変更するとします。
最初のステップは、「チャットボット導入によって、今までは平日17時までしか対応できていなかったコールセンターが365日24時間体制で動くようになり、顧客満足度のアップにつながる」「より多くの顧客とやりとりできるようになる」という生産性アップです。
次のステップは、「より多くの顧客と話せることで、機会損失をなくす」「チャットがこれまでの履歴から新たな提案をする」などチャットだからこそできる効果を提示します。
最後は「チャットを利用することで得られたデータを使って既存事業の枠にとらわれない新たな新規デジタル事業（例えば新商品の開発や新サービスの開始など）を提供する」といったことを提示するステップです。最後のステップでは、データを活用して新たな価値を付与しようとしている点でDXの本質に近づいていると言えます。
このようにステップごとに説明することで、周囲の理解を得られやすくなり、円滑にDX事業を進めていくことができるようになるでしょう。
「これらのステップをふむとチャットボットの導入で、〇〇円のコスト削減になります！」と言いやすくなりますし、ただ単に「チャットボットの導入で、〇〇円のコスト削減になります！なのでやりましょう！」とだけ言うよりも説得力が上がります。
このステップは、ここに書いたことに縛られず自由に考えてよいです。周囲に説明するときにわかりやすくなればステップが減ろうと増えようとかまいません。中にはもっと細かく刻みたい人もいるでしょう。
中でも大切なのは一番のステップです。最初の目標値が大きすぎても実現できそうに思えないし、小さすぎると「そんなのやって意味あるの？」と言われかねません。わかりやすく顧客満足度や従業員満足度で目にみえるようなものを設定するのがおすすめです。
それがうまくいって初めて、次の費用対効果を説明するのがよいでしょう。
最後のステップにてDXの説明を聞いた全員が「そうなったらいいなぁ」と思うようなことを提示することで、DXに対するやる気が増し、DXに対する理解が広まりやすくなるでしょう（この後でも少し書きますが、周囲の理解を得られるかどうかはDXする上での課題になります）。
さて、実際にDXの施策を実行することになりました。
DX施策のプロジェクトでは、デジタル技術の導入や新ツールの開発が多いため、ここではそれらの作業を中心に話をしていきます。
実際に、導入や開発を行わないというDXもあると思いますので、その場合はまた別のアプローチが適切であると思います。
導入や開発において、まず必要なのはプロジェクトマネージャーを決め、その人に進行管理をしてもらうことです。今までDX施策についてまとめてきた、この文章を読んでいるあなたがプロジェクトマネージャーになることが多いと思います。
その後の流れは企業によってそれぞれかと思いますが、一般的に作られる書類は、プロジェクト計画書、業務フロー定義書、要件定義書、業務要件一覧、機能要件一覧と非機能要件一覧、機能配置図、ER図、システムのDBテーブル一覧、システム画面遷移図、ライセンス一覧、テスト計画書などです。
注意が必要なのは下のようなポイントです。
- DXするシステムについて外注する場合、どこからどこまでを外注するか確認しましょう。専門的な分野は外注でも良いですが、要件定義などその企業との関わりが深い部分については自分で作った方がより効果的な達成につながります。
- プロジェクトに関わる人の責任範囲を細かいところまで決めておくこと。決めておかないと、プロジェクトを進める上で、判断基準が曖昧になり、思わぬトラブルになりかねません。
- プロジェクトスケジュールを作る際は、無理のない範囲で作ること。ステークホルダーなど外部との連携が必要なフェーズは予期せぬ事態も想定して長く見積り、内部チームのみで完結できるようなフェーズはその分短くするとバランスがとれます。
- 要件定義書は、「何を作るのか」「その開発にいくらかかるのか」を決めるものです。
- ユーザーの作業とは直接関わらないサーバーやネットワークの設定など、非要件についても確認が必要です。非機能要件としてまとめましょう。
- プロジェクトマネージャーは要件定義書を書くところまでは中心となって動き、それ以降の開発作業では、開発の管理業務が主になってきます。
- 開発のための設計書は、コードを書く一歩手前、もうあとは手を動かすだけであるという段階まで内容をまとめられていればOKです。
- プロジェクトの進行管理に関してトラブルを避けるために、毎朝その日のTodoを確認、終業時にできているかの確認、というのをチーム内で共有することをおすすめします。
なお、Todoとは担当者や内部チームが手を動かせば即時に終わる作業のこと、DXの課題とは他のチームや部署の誰かに意思決定してもらわなければ進めない作業のことを言うことが多いです。自分だけの力ではどうにもできないことを課題と言います。また、リスクとは、まだ発生していないがこれから起こる可能性がある課題やTodoのことを指します。
これらTodo・課題・リスクの認識が誤解されていると思い通りに進まないこともあります。
プロジェクトマネージャーの仕事では、そのフェーズの本当の目的を見据えながら、その目的を達成するために要件定義書などの書類を書いたり、プロジェクトの進行を管理したりすることが重要です。
そして、プロジェクトが終了した後も改善できる部分はないかと常に考え続けることが必要です。
今回は、DXを実行する上での流れについてお話ししました。
次回のコラムでは、DXを話す上でよく使われる用語のご紹介をします。