2019年12月20日更新

DX時代にバリバリ活躍するIT技術者になるためのこれだけは知っておきたいスキルセット・ガイド第03回 わたしたちがまだ知らないDXの推進プロセス

株式会社サイクス 代表取締役 宗 雅彦 氏

今回のねらい

第二回目のコラムでは業績不振の更科そばがDXで業績の再生を目指す上では、なによりもまず「DXビジネスモデルコンセプト」の構想企画からはじめる必要があることを書きました。この「DXビジネスモデルのコンセプト」とは、「現実世界の事業モデルのコンセプト」と「仮想世界のITシステムモデルのコンセプト」を結合したものだということを思い出していただけたでしょうか。

それでは今回は、わたしたちが慣れ親しんでいる従来型のIT導入プロセスと、DX推進のための導入プロセスの詳細を具体的に比較して、DXを推進するうえで、わたしたちに不足しているプロセスが何かの理解をめざしたいと思います。

イメージ

わたしたちが慣れ親しんでいる従来型のIT導入プロセス

それでは前号と同様に、再度、業績不振の更科そばに登場してもらいましょう。

こちらも前回、確認したように(前号、図1へのリンク)、従来型のIT導入の目的は、その多くが「社内業務の効率化」であるということでした。更科そばに例えれば、フロア担当の注文を受けたり会計したりする業務や、厨房担当が注文を受け取ったり料理が出来上がったことを伝達する業務をタブレットを使って効率化する場合がそれにあたります。では更科そばの店内の業務を効率化する場合の、従来型のIT導入プロセスを具体的に確認しましょう。

図1
図1 店内の業務プロセス

例えば更科そばの要求が店内の業務プロセスのうち、「注文を受ける・調理する・配膳する・会計する」といった業務における情報のやりとりや会計計算をIT化することで業務の効率化をはかったり、注文受け取り・伝達や会計計算の誤りを減らしたりすることだとしましょう。

このようなとき、わたしたちは「注文を受ける・調理する・配膳する・会計する」といった業務をITで効率化するために、「注文を受ける」から始まって「会計する」という業務までにまたがる情報のやりとりや集計・計算をIT化するために「ソフトウェア要件定義」からプロセスを始めることが一般的ではないでしょうか。そして「設計・実装・運用」に続く開発プロセスを進むか、パッケージアプリケーションを導入するといった手順に進むことが多いのだと思われます。

図2
図2

ここで留意すべきは、「なぜ、どのようにして、IT活用で業務の効率化をしたり業務上の誤りを減らしたいのか」という「構想企画」や業務プロセス全体を理解する「業務の見える化」や、あるいはあるべき業務プロセスやITサービスを設計する「サービスデザイン(業務設計・業務要件定義)」を省略してしまうことが多いことです。それはなぜかと言えば、現状の業務プロセスを対象に、つまり現状の業務の仕組みを見直すことなしに、現状業務のままIT化をしてしまうことが多いからだと思われます。

わたしたちはこのように、つい「構想企画」や「サービスデザイン(業務設計・業務要件定義)」を省略してしまいがちになるのですが、この方法には大きなデメリットがあることを覚えておいてほしいのです。

図3
図3

筆者は日比谷公園に散歩に行くことが良くあります。日比谷公園にはそれは見事に手入れされた木がたくさんあります。みなさんはその木の一本を選んでスケッチブックにスケッチする課題を出されたと思ってください。

ここでこの一本の木は、これから開発したい業務やITシステムの全体像にあたります。木の幹は、どのような業務をどのようにIT化することでどうしたいのかという「構想企画(コンセプトの概念設計)」にあたります。木の幹から張り出している木の枝は「サービスデザイン(業務設計・業務要件定義)」にあたります。そして木の枝に咲いている一枚、一枚の葉っぱが「ソフトウェア要件」にあたります。

みなさんは木の幹や木から張り出している枝を描かずに、葉っぱだけを描くことで、その木の全体像が描けると思いますか。そんなはずはありません。ここで葉っぱを描くという行為は「ソフトウェア要件定義」に当たることを思い出してください。実はDX推進以前に「ソフトウェア要件定義」、つまり葉っぱにのみ目を向けがちになるというのは、日本におけるIT導入の最大の悪習慣なのです。誰でも葉っぱをうまく描くことだけでは木の全体像を描けないことに気が付きますから、木の幹や木の枝という全体像、つまり「構想企画」や「サービスデザイン」を確かめにいくことになります。しかしそれは準備されておらず、しかも限られた「ソフトウェア要件定義工程」を先に進めなければならないので、無理矢理、次工程に進んでしまい、手戻り作業が爆発してしまうのです。そしてその結論はプロジェクトの失敗です。著者は、日本のIT導入プロジェクトの大半の失敗要因は「ソフトウェア要件定義にしか目を向けない悪習慣」にあると言っても過言ではないと考えています。

図4
図4

さらなるデメリットもあります。枝が飛び出していたり、葉っぱが生い茂って剪定されていない形が整っていない木、すなわち複雑な業務をIT化しようとすれば、おのずとITシステムも複雑化してしまいます。つまりムダが内在した効率的ではない業務のためのITシステムは、やはりムダが内在した効率的ではないITシステムになるのです。この問題を解決するためには木の剪定にあたる作業、すなわち業務のシンプル化が前準備として必要なのです。そのためには全体を俯瞰した「サービスデザイン(業務設計・業務要件定義)」が必要です。業務の効率化を目的としたIT導入においてもサービスデザインは必須と言えるのです。

それではDX推進に必要な導入プロセスはなんですか?

今度はDX推進に必要な導入プロセスを考えてみましょう。

図5
図5

前回の更科そばの事例では、業績不振の更科そばを再生するためのアイデアのひとつとして「ランチタイムに行列に並ぶことをいやがるお客様を逃さないために、テークアウトを充実させる。加えてスマホアプリで事前予約できる」というものがありました。

繰り返しになりますが、DX推進の導入プロセスにおいては、このように「ビジネスモデルのコンセプト」つまり「DXの構想企画」から始めることが必ず必要になります。

図6
図6

次に必ず必要になるのが、図では「お店の行動プロセス」と「お店のITサービスプロセス」にあたるサービスデザイン(業務設計・業務要件定義)です。

これら「お店の行動プロセス」や「お店のITサービスプロセス」はどのようにデザインすれば良いのでしょうか。それはお客様の行動プロセスにおいて、お客様の購買行動のハッピー、つまり顧客満足度を最大化できるようにサービスをデザインすることが大原則です。そのためにはどうすれば良いのでしょうか。そうなのです。なによりもはじめに「お客さまの行動プロセス」を理解することが大前提となります。「お客様の行動プロセス」を理解して、それに一対一対応するかたちで「お店の行動プロセス」や「お店のITサービスプロセス」をデザインすることが大原則なのです。「デザイン思考」と呼ばれるアプローチをご存知の方は、このようにお客様の行動を理解してサービスをデザインすることを「カスタマージャーニーマップを描く」ということをご存知でしょう。DXの本質のひとつは「お客様とのデジタル直結でCX(カスタマーエクスペリエンス)を最大化する」ということでしたが、そのためにはこのように、お客様とお店側のサービスプロセスの全体像を理解してサービスデザインすることが必ず必要になるのです。

図7
図7

DXにおけるサービスデザインについて、もう一点、大切なことがあります。図6で例示したようなサービスプロセスをどのようにデザインするかという、その方法についてです。

更科そばの事例では、DXビジネスモデルを構想企画した成果、つまり新しいビジネスモデルのコンセプト(アイデア)は、「テークアウトを充実させる」と「スマホアプリで事前予約できる」ということでした。つまり更科そばのサービスプロセスは、最終的に「テークアウトを充実させる」と「スマホアプリで事前予約できる」というサービスが実行できれば、最もシンプルで効率的なプロセスが望ましいということになります。

このようなときには、「テークアウトを充実させる」と「スマホアプリで事前予約できる」というゴールからスタート地点へ逆算(バックキャスティング)してサービスをデザインすれば良いのです。逆算はゴールから始めてロジカルシンキングでもっともシンプルなプロセスへブレークダウンできるようにデザインします。この方法を「ゴール指向・バックキャスティングメソッド」と言います。バックキャスティングにはロジカルシンキングのちょっとした慣れが必要ですが、覚えておいて損のない方法です。

本コラムのまとめ

図8
図8

今回の解説をまとめると、この図になります。ここで知っておいていただきたいのは、「ビジネスモデルの構想企画」や「サービスデザイン(業務設計・業務要件定義)」は、DX推進でなくても大切なIT導入のプラクティスだということです。米国のIT投資対効果は日本の2倍であるという統計データをよく見ますが、その原因の多くは、ソフトウェア要件定義にのみ目を向けてしまいがちになる日本のIT導入の悪習慣にあるというのが筆者の意見です。

ところで「知らないこと・やったことは連想できない」という課題がここにあります。つまり「ビジネスモデルの構想企画」に注意を払うことが少ないわたしたちの多くは「ビジネスモデル構想企画の方法」を知らないのです。だから「構想企画がうまくいかない」、「ビジネスモデルのアイデア出しをどうしたらいいかわからない」という声を多く聞くことになります。

そこで次回は「経験が少なくても学びやすく成果が出やすい」と評価の声をいただいている「ビジネスモデルのコンセプトづくり」のメソドロジーをお伝えしたいと思います。それでは次回を楽しみにお待ちください。

著者プロフィール

株式会社サイクス

代表取締役 宗 雅彦 氏

「方法こそが未来創造に向かうための武器なのです」をモットーに、IT経営の変革、DX(デジタルトランスフォーメーション)のためのビジネスモデル創造の方法の研究・普及活動に取り組む。近年は、DX推進の人材育成、新規創造プロジェクトの支援のために精力的に活動。
外資系コンピュータメーカーでUNIXオペレーティングシステムの開発業務に従事。その後、シリコンバレーに駐在し、ITベンチャーの発掘・投資・事業開発推進業務に従事。2000年に株式会社サイクスを創業。IIBA(カナダ・トロント)のBABOK(ビジネスアナリシスの知識体系ガイド)バージョン3の開発リーダーなど、社会貢献活動にも参加。

宗 雅彦氏

ページの先頭へ