DXで本当に変えるべきモノとは

DX記事の第4弾です。

なぜDXが必要なのか ~2025年の崖~


古い既存システムをそのまま使い続けた場合、システム担当者の引退、既存ソフトウェアやハードウェアのサポート切れなど様々な問題が今後起こってくることが想定されています。


これらの課題を放置したままでいると、トラブルやセキュリティのリスクも高まりそれらの対策やシステムの保守などで想定以上の費用がかかってくると言われています。


2025年以降それらが一気に経済損失として膨れ上がっていく(最大で現在の約3倍、年間12兆円)というのが「2025年の崖」とのことです。


www.meti.go.jp


経産省もこのように警鐘を鳴らして、今のうちにDXを推進しよう!と叫んでいます。


なぜDXが必要なのか ~世の中の急速な変化~


AIなどの技術はどんどん進歩しています。先進企業はそれらを率先して活用あるいは自ら研究開発してビジネスに活かしてきます。


それらは世の中に大きなインパクトを与え、人々のライフスタイルや価値観にさえ影響を及ぼします。


そうした中でいつまでも旧態依然としたビジネスモデルやシステムで戦っていけるだろうか、新しい技術を取り入れないと時代に取り残されていくのではないか、などの不安を感じている人も少なくないでしょう。


DXは実現できなくても問題ない?


DXに取り組む理由がこのような不安感や危機感からのものであっても、最終的に当初描いていたTOBE図が実現できれば問題ないのかもしれません。


しかし動機が不安感や危機感の解消である場合は、最終的にDXが進まないままでもそれらが解消されればそこで終わりということも十分ありえます。


例えば、

・競合他社もDXの取り組みが進んでいないから取り残される不安が薄れた

・現状特に影響もなくこのままでも問題ないんじゃないかと思うようになった

・DXとはまた別に課題や優先事項が生まれてそちらに注力するようになった


こうした状況からDXプロジェクトが停滞したまま新たに動き出さないという企業もあるのではないでしょうか。


DXで本当に変えるべきモノ


f:id:custle:20200802005634j:plain
きなこもちさんによる写真ACからの写真


DXの定義(経産省ガイドライン)を再掲します。

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


最近、実はこの企業文化・風土の変革というのが一番大事なのではないかという考えも芽生えてきました。


というのも、顧客や社会のニーズは不変ではなく、DXも一度デジタル化(システム化)すればそれで終わりとはならないでしょう。


企業がこれから先も生き残っていくためには、引き続き顧客や社会のニーズの変化に応じて、サービスやビジネスモデルなどを絶えず変革し続けることが必要と思われます。


そう考えると、いかにリスクを恐れずスピード感を持って新たなチャレンジを繰り返していける組織・企業であるかが必要条件になってくると思います。


そのような企業文化・風土でなければ、常に保守的な考えや現状維持バイアスの方が優先されてしまい、変革が実現しないといったケースが多くなるのではないでしょうか。


ではどうすればそうした組織・企業に変わっていけるのか。


組織・企業の文化や風土はそこで働く人々によって醸成されていくものではありますが、とにもかくにもその中で経営層の影響は非常に大きいはずです。


経営層は企業のビジョンやミッションを定めて、さらにあるべき価値観や行動指針などを整え、それらを従業員に浸透させることに尽力します。


いわば企業文化・風土の基盤作りを行います。


ただしそれらの内容が経営側にとって都合がいいだけのものや、対外的に聞こえの良いメッセージだけで実体の伴わないものであれば、従業員にはただのきれいごととしか思われずほとんど浸透しないことでしょう。


当然それらは形だけのものではなく、従業員みなが納得して実践できるように実際の制度や環境なども整えられたものでなければなりません。


DXというシステム的な改革をきっかけに、それを支える企業文化・風土といった基盤も改めて見直してみるべきかもしれません。


難しい課題ではあるのでしょうが、高成長や先端事例として紹介される企業では、優れたコアバリューやユニークな社内制度・文化なども併せて紹介されたりしています。


参考1:「経営者目線を持て」


結構有名な言葉かと思いますが、この言葉を乱発して一般従業員から冷めた目線を向けられるという話もよく聞くのではないでしょうか。


「自分はただのいち従業員で経営者じゃないから必要ないよ」


「やりがい搾取か!?」


などのような感想を持つ人も多いでしょう。


ただ、実はこの言葉が指す経営者とは「その会社」の経営者ではなくて、「今の自分の仕事を行う会社」の経営者のことを指すようです。


つまり、今の仕事を主力事業とする企業の経営者になったとしたらどう考えるか、ということです。


よって、今の会社の経営者のために滅私奉公せよということではなく、今の立場で自己の利益を最大化するためにはどうすれば良いか考えろ、ということでもあります。


とはいえ、そのためには実際にある程度の権限や予算を持たせてもらうなど経営者としての武器を用意してもらえないとどうしようもなかったりするでしょう。


誤解を生みやすいメッセージであったり、誤解を誤解のまま放置するようなら従業員の意識の変革は厳しいでしょう。

参考2:Zapposの事例


ZapposはAmazonがどうしても欲しがった企業として買収され有名になりましたが、そのコアバリューも事例として色々なところで紹介されています。


全部で10個ありますが、そのうちのふたつを紹介します。


Embrace and Drive Change
変化を受け入れ、その原動力となれ


Be Adventurous, Creative, and Open-Minded
リスクを恐れず、創造的で、オープンマインドであれ


これらのコアバリューを実践できるように、Zapposでは社員に大きな裁量権を持たせ、評価や採用基準とも強く結びつけているようです。


DXシリーズまとめ

第1弾 DX(デジタルトランスフォーメーション)の第一歩

第2弾 DXの最初の壁を乗り越えるには

第3弾 DXのロードマップの作り方

DXのロードマップの作り方

DXは小さく始めるべきか、大きな絵を描くべきか


前回はDXのTOBE像を構築するためのヒントを考えてみました。


custle.hatenablog.com



今回はTOBE像構築後のそこに至るためのロードマップの作成について検討してみたいと思います。


その前に、AI導入ではスモールスタートで小さな成功を積み重ねる方が最終的に近道であるという意見を耳にすることがあります。


DXも同じようにまずは小さな成功を重ねていくやり方が良いのでしょうか。


実現できるかどうかわからない大きなTOBEを描いてしまうと、途中でプロジェクトが頓挫してしまう可能性が高くなるのでしょうか。


結論としてはある意味どちらも正解だろうと思います。


ただ、DXの場合はAIのようにシステムのいち機能だけでなく、業務システム全体や広範囲に影響を及ぼすことが多いので、スモールスタートがしにくい面もあるかと思います。


特にシステムの導入や改修となると高額な予算や時間も必要となります。


最初からそうした部分も計画に盛り込んでおかないと、途中で気づいてなんとかしようとしてもなんとかなる可能性は非常に低いです。(私も実際経験しました)


DXのロードマップの作り方


f:id:custle:20200721203025j:plain
oldtakasuさんによる写真ACからの写真


DXの実現方法は最終的にシステム導入や改修になることが多いので、ロードマップ作成もシステム開発につながるようなものになります。


そのため一般的なシステム開発時の流れとそれほど差がないかと思います。


ざっくりいうと、まずは業務要件を定義してそこからシステム要件に落とし込み実現方法を設計し、開発・テストと進んでいきます。


業務要件の定義は、まずTOBEを元に大きな粒度での業務フローを設計し、そこから現場レベルでの業務フローとデータの流れを確認しながら詳細設計に落とし込んでいくことになると思うので、結構大変です。


さらにこれまでに経験のない全く新しい業務などがある場合は、後で想定外や考慮漏れのプロセス等が発生する可能性も高くなるので、最初に手運用もしくはプロトタイプシステムでのPoCなどを実施して業務要件のチェックをしてみるのも必要かと思います。


一部の業界・業種では結構前から業務パッケージの開発・販売がなされており、ある程度業務フローもテンプレートが用意されているので、そうしたものをベースにするのもありかもしれません。こうした業務パッケージの開発は今後さらに進むかもしれませんね。


次のシステム要件をまとめる段階では、既存システムの扱いをどうするかも悩みどころでしょう。


新しい業務要件が既存システムで一部カバー可能なら、丸ごとリプレースではなく、既存システムの一部継続利用も考えられます。


ただし、一部継続利用するならば新しく必要な機能をどう実装するのか、インターフェースやデータなどの連携をどうするか、既存業務に影響が出ないようにするにはどうすればよいかなど、なるべくコストがかからないやり方とリスク面の両方を踏まえて検討する必要があります。


プロジェクト体制も、DX推進を任された担当者だけでなく、対象業務の現場の担当者からシステム担当者など多くの人を巻き込んで歩調を合わせて進める必要があります。


場合によっては外部のコンサルやベンダーも関わるでしょうし、少なくとも数十人の規模にはなるのではないでしょうか。


以上のことを考慮して、DXシステムの導入計画、もといDXのロードマップを作り上げる必要があります。


さらにもちろんシステム導入「後」の運用やリスクと期待効果などについても事前に考えておかなければ、稟議は通らないでしょう。


プロジェクトを失敗させないためには


私の経験した失敗事例です。↓

・TOBEやロードマップがないままプロジェクトが開始され、現場担当者間では何をすべきかまとまらず時間切れ。


・TOBEやロードマップがないままプロジェクトが開始され、一部の業務でそれらを整理してPoCまでは成功しつつも、予定にないシステム予算の追加や既存システム改修が認められなくて断念。


繰り返しますがDXでは大体のところシステム開発や改修といった落としどころになると思われますので、AIやデータ活用といったキーワードを伴うからといってデータサイエンティストやデータアナリストだけで進めるのはおそらく厳しいでしょう。


またDXのようにゴールイメージがあいまいなものは、プロジェクトを見切り発車させずに、時間がかかっても最初にTOBEとロードマップを備えるのはやはり必要でしょう。


その際にもなるべくなら現場の業務担当者やシステム開発プロジェクトの知見のある人たちにも加わってもらった方が良いと思います。


さらにシステム導入まで含めると時間も人手もそれなりに必要なので、そのための体制・予算・スケジュールもあらかじめ確保しておく必要があるでしょう。こうした準備体制を整えておくのもプロジェクト成功のためには非常に重要だと思います。


スモールスタートのDX


DXを進めるに当たって、全ての業務をデジタル化するとか、現在のシステム基盤をデジタル化のために全て刷新するとなると、どれだけ時間や費用がかかるだろうかと途方に暮れてしまうかもしれません。


冒頭でも述べましたが、まずは身近なところでできそうなことからやってみるという考えも間違いではありません。


幸いにもDXは定義こそありますが、具体的でなく拡大解釈が可能なので、これがDXだ!と言い切れば通じると言えなくもありません。(AIも同じかも。。)


業務の一部のみシステム化を行ったり、新たにちょっとしたスマホアプリを開発したり、とりあえず何らかの形ある実績作りを優先してスモールスタートさせることも可能です。


AI導入のケースでいうと、多くはAIによって何かを変えようというよりむしろ「AI導入そのものが目的」であったりします。(PRになるので)


であれば小さく始めた方が成功しやすいのは自明です。それに小さなプロジェクトであってもAI導入の実績ができれば、それを元に周りの人々が感じているAIの敷居の高さや苦手意識を払拭させて、より広められやすくなる土壌も醸成できるようになるかもしれません。


DXも同じようにまずは小さくても実績を作ることを優先するやり方もあります。


ただし、TOBE像とロードマップがないとそれで終わってしまってそれきり続かないということも珍しくありません。


途中で目的がすり替わるパターン(DX推進がいつの間にかアプリユーザ何万人を目指そう!とか)も見たことがあります。


ロードマップの終着点はなるべくブレないようにはしたいですね。


DXシリーズは次回でひとまず最後となります。


custle.hatenablog.com

DXの最初の壁を乗り越えるには

DXの最初の壁


f:id:custle:20200721200746j:plain
bBearさんによる写真ACからの写真


前回はDXの最初の壁とそれを避けて第一歩を踏み出してしまった場合の末路(!)について紹介しました。


custle.hatenablog.com


DXを進めるにはまず最初にASIS(現状の姿)とTOBE(あるべき姿)を定めます。そして次にそのためのロードマップを作成します。こうした準備を整えてようやくプロジェクトが開始できるようになります。


しかし兎にも角にもプロジェクトを始めることを優先してしまうと、手段ありきで進んでしまい大抵がPoCの段階で次にどうすれば良いかわからなくなってしまうという事例が多発しています。


今回はまずDXを成し遂げた先にあるTOBE像を描くにはどうしたら良いか、何かヒントのようなものはないかを考えてみたいと思います。


自社以外はどう変わっているか


Transformation(変革)の主語について考えてみましょう。


DXの定義にあったのは、「製品やサービス、ビジネスモデル、業務や組織、プロセス、企業文化、風土」などですが、どれも「自社」目線のものです。


ここでもう少し視野を広げて3C視点で考えると、「競合」や「顧客(マーケット)」の変革にも目を向けられます。


例えば世の中では、シェアリングエコノミーが流行しています。


UberやAirbndなどに代表される新興企業が提供したサービスによって、消費者の間ではモノを買うよりもシェアしようという意識の変化が顕著に表れてきています。


またそうした流れからか、所有するよりも定額で使い放題という利用権の方を好む人たちに応じたサブスクリプションビジネスも広がりを見せています。


他にも未来の都市構想のスマートシティを実現するために、IoTや次世代通信システムなど様々な先端テクノロジーを活用に関する々ニュースは時々目にします。


労働力不足の解消や様々な都市問題の解決のために、自動運転カーや無人店舗、ロボティクス、キャッシュレスなどの実証実験や取り組みが様々な企業で進められています。


さらに昨今の新型コロナの影響もあって、様々な業務やサービスのオンライン化も急速に進んでいますね。会議、営業、教育、商談、飲み会、イベントなどなど。


オンライン会議ツールを提供する企業はもちろん、それらを活用してサービスを持続的に提供できる仕組みやサポートを行う企業も業績を伸ばしているようです。


自社単独で変わろうとするのではなく、これら世の中の既に変わりつつある動向やキーワードを元に、自社ならどう関われるか/どういった立ち位置にあるべきかといったTOBEイメージを具体的に考えてみるのもひとつのヒントになるかもしれません。


小売業界の変革


ちなみに私が案件等で携わった経験の多い小売業界の変革というと、やはりオンライン化の進展でしょうか。


スマホの普及等により消費者がオンラインで過ごす時間が増えたことで、オンライン上もマーケットの場として注目されるようになりました。


Amazon楽天といった巨大なECプラットフォームも誕生し、オンラインでのモノやサービスの流通はますます盛んになっています。


扱う商品やサービスも増加の一途をたどり、おそらくもうAmazonさえあれば生活するのに困らないという人もたくさんいることでしょう。


小売業からするとこうした風潮は大変な脅威です。


そのためコンビニなどの小売業者もオンラインでのマーケティング活動にも力を入れており、アプリ等を使っていかに自らの店舗に呼び込むかというO2O(Online to Offline)施策を繰り広げています。ポイントでの還元やクーポン発行などが代表的ですね。


また店舗を商品やサービスを販売する場ではなく、ブランディングの場として活用しようということでショールーム化を進めているところもあります。


家具・家電のモデルルームを設置したり、体験型のサービスを提供したり、インスタ映えする店舗作りを行ったりして、顧客を店舗へ誘致する施策が行われています。


さらに小売業は足元では人手不足の影響を大きく受けている業界の一つとして騒がれています。その解決のためにセルフサービスの導入や、業務の自動化・省力化などの研究開発も着々と進められています。


3C観点で代表的な課題をまとめると以下のような感じでしょうか。これらの課題に対してデジタルを含む様々な取り組みが進められているのが実情です。


【Competitor】
Amazonのような巨大プラットフォームの競合にいかに打ち勝つかあるいは協調するか

【Customer】
オンラインとオフラインをいかに活用して顧客とのリレーションを強化するか

【Company】
人手不足の解消と人件費削減をいかに進めるか


まずはこのように自社を取り巻く環境を網羅的に分析し、その上で自社が目指すべき方向や注力すべき課題を定めることが、DXを進めた先のTOBE像を具体化する上では必要なのではないかと思います。


次回はDXのロードマップの作り方を紹介します。


custle.hatenablog.com

DX(デジタルトランスフォーメーション)の第一歩

DX(Digital Transformation)とは


今回はDXについて書いてみようと思います。


f:id:custle:20200720150926j:plain
fujiwaraさんによる写真ACからの写真


ちなみに経産省ガイドラインでは、DXとは「企業がビジネス環境の激しい変化に対応し、データとデジタル技術を活用して、顧客や社会のニーズを基に、製品やサービス、ビジネスモデルを変革するとともに、業務そのものや、組織、プロセス、企業文化・風土を変革し、競争上の優位性を確立すること」と定義されています。


www.meti.go.jp


この定義には主に2点の変革について書かれています。


・製品やサービス、ビジネスモデルの変革

・業務や組織、プロセス、企業文化、風土を変革


ただし、変革といっても具体的にどのように変わることがDXなのかは書かれていません。


それがDXがなかなか進まない大きな原因ではないかという気がします。


DXを進める最難関の壁


「変革」という言葉だけでは前に進めないので、まずはその前後の姿であるASIS(現状の姿)とTOBE(あるべき姿)を具体的にすることから始める必要があるでしょう。


ASISとTOBEを定められれば、そのギャップをどのように埋めていくべきかというロードマップやプロセスの議論に入ることができます。


それらがないままプロジェクトを進めることは出口のないトンネルを延々と掘り続けるようなものです。


まず、ASISに関してはDXの定義の中で主な対象種別(製品、サービス、ビジネスモデル、業務、組織、ビジネスプロセス、企業文化や風土)が例示されています。


ここから自社の環境に照らして対象を選択するのはそう難しいことではなさそうです。


しかし、TOBEに関しては「顧客や社会のニーズを元に」とか「競争上の優位性を確立」などの補足的な言葉しかなく、ちょっとイメージしにくいのではないかと思います。


おそらくここが大多数が行き詰まってしまう最初にして最大の壁なのではないでしょうか。


DXの最初の壁を避けて第一歩を踏み出すと


TOBEのイメージが構築できないとそこに至るためのロードマップを作成することもできず、プロジェクトがいつまでたっても開始できないまま時間だけが経過してしまいます。


その状態でずっと悩んでいるわけにもいかないので、先に手段(技術)を決めてとにかくスタートしてしまおうというパターンもよく聞きます。


ここで採用される手段とは高い確率で「AI」です。


これまで自社の業務やサービス等では取り入れていなかったAI技術を使えば、それイコール変革ではないかとの考えでDXプロジェクトがとりあえずスタートされます。


本来TOBEのようなゴールや目的、それに至るロードマップもないまま手探りでプロジェクトを進めても成功確率は低いはずなのですが、AIの活用事例などが世の中に広まりつつあるので、AIを使えばなんとかなるだろうという期待感が先行してしまっているのかもしれません。


しかし、残念ながらPoCまで実施したところで次に何をして良いのか再びわからなくなり、再度DXの推進が停滞してしまうというのもよく聞く話です。


PoC以降に進めない原因については、色んなところで議論されています。主には経営層の無理解、リーダーシップ不足、戦略丸投げといったものから、現場の抵抗、データが不十分、導入や運用体制が整わないなどでしょうか。ただ突き詰めればやはりTOBE像とロードマップの準備が不十分であることに帰着するような気がします。


しかしなかなかそれらの課題を克服した成功事例が増えてこないのも厳しいところですね。それだけ最初の壁が高いのか、それとも他にもつまづくポイントがあるからなのか。。。


DXの最初の壁を乗り越えるには


DXの最初の壁を避けてプロジェクトを進めようとすると失敗の可能性が高くなるので、やはり最初の壁を乗り越えることは避けて通れないのではないでしょうか。


次回はどうすればこの壁を越えられるのか考えてみたいと思います。


custle.hatenablog.com

データ活用とは具体的にどうすれば良いのか

データ活用の失敗パターン


データ活用とはデータ「を」効果的に使うことですが、あくまでデータは主体ではなく別の何かのために補助的に使うことを指します。


しかしこの「別の何か」が暗黙の了解とされてしまったり、あるいは省略されてしまうということが頻繁に起こります。


そのためにデータ活用の対象や目的が関係者間でも統一されず、何らかの分析を行ったとしてもそれが実際に役に立ったのかどうかの評価も定まらないということに陥ってしまいます。


そうなると結果的に成果が挙げられていないと判断され、失敗とみなされることが多くなります。


まずはデータを活用する対象である「別の何か」を明らかにし、それによって期待される「効果」を具体的にイメージすることがデータ活用の第一歩ではないでしょうか。


データ活用を行うための前提条件


私はこれまで色々なデータ分析の仕事をしてきました。


KPIの設計とモニタリング、仮説の検証、今後の見立てや見積もり作成、施策の分析と改善、リソース配分の最適化、KPI増減の原因調査。。。


ここから考えると、常に何らかの業務ありきでデータ分析を行ってきたといえるのではないかと思います。


もちろん特定の業務とは関係なしにただ単にデータを見せてくれとか、何らかの示唆を出してくれという依頼もありました。


しかし当然ながらそうした依頼で次のステップに進んだということはほとんどなく、振り返るとおそらくそれらはやらなくても問題ない依頼だったのではないかと思います。


ただ、業務ありきといっても最終的にその業務に何らかのフィードバックができる形にもっていけないと、データ分析を行った意味がありません。


おそらくここがデータ活用と呼べるかどうかの境目のような気がします。


つまり、データ活用を進めるにはまず「対象となる業務が定量的に評価可能な状態にあること」を満たし、実際のデータ活用とは「その業務の評価、改善、フィードバックといったPDCAを回すこと」ではないかと思います。


この前提部分があいまいだとまずもってきちんとデータ活用の「評価」ができなく、そうすると当然期待される効果である「業務の改善」もできたかどうか不透明ということになります。


データ活用はこの前提部分が非常に大事なのではないかと思われます。


逆にいえば、この前提部分がしっかりできていればあとはデータを見てどこに手を打つべきかを判断するだけで、それほど難しいことではないといえるのかもしれません。


業務とデータのリンク


そうした状態になっていないということは、この前提部分に問題があるということになります。


例えば「営業」であれば、目標売上xx円という定量的に評価可能な指標を設けているところはほとんどだと思います。


現状の売上がデータで評価可能な状態で、もし予定と進捗に乖離がある状態がわかれば何らかの改善が必要ということで、次の手を打つべしという判断が下せます。


ここで終わると基本的なデータ活用例として成功ですね。


しかし、実際にはこの「次の手を打つ」の内容が定まっていないと、結局営業担当者にハッパをかけて危機感を煽るなど「本当に効果的かどうかわからない手段」しか取れず、とたんにデータ活用から遠ざかってしまいます。


もし営業担当がサボっていることが判明しているならハッパをかけるでも良いのかもしれませんが、そうでないなら別の手段をとらなければ問題解決につながりません。


上記で述べた「対象となる業務が定量的に評価可能な状態」は業務のざっくりとしたレベルだけで終わらず、どの手を打つべきかといった判断が必要な粒度まで対象とできるかどうかでデータ活用可能な範囲も決まってきます。


そのため各業務におけるKPIの設計が重要となります。


そのKPIは当然ながらデータとして計測可能なものでないといけないので、その元となる業務ログをデータとして取得する仕組みも必要になります。


そうして業務とデータがリンクできた状態を構築できれば、データ活用によって業務状態の正しい評価を行い、適切なタイミングで改善を図ることも可能になるというわけです。


データ活用を進めやすい業務


主にバックオフィス系の業務は、ある程度マニュアル化が進んでいて、業務内容も標準化されていたり業務ログも収集されていたりするので、データ活用しやすい環境にあるのではないかと思います。


そうした業務ではサービスレベルの一定品質を担保するためにワークフローを可視化して、ボトルネックを検知したり必要に応じてリソースの再配分を行えるように調整することも可能でしょうし、さらなるコスト削減を目指して業務プロセスを分析して効率化や省力化・自動化といった改善を施すなどのデータ活用イメージが想像できます。


データ活用を進めにくい業務


一方でなかなかデータ活用が進まない業務の代表は、営業やマーケティングなどでしょうか。


これらの業務は、顧客や市場といった移り変わりの激しいナマモノを相手にするため、たびたび柔軟で臨機応変な対応が求められることが多いようです。


特にベテランの人間などはこれまでそれでうまくいってきたとか、そうした環境だったからこそ成長してきたと主張するかもしれません。


そのためなかなか自動化・定型化するといったことも難しく、結果として各担当による属人的な業務に陥ってしまいがちです。


実はこれはこれで間違ってなくて、個人的には営業やマーケティングのような業務は全てをガチガチに自動化・定型化させるまでは必要ないかもしれないと感じています。


もちろん自動化・定型化はコスト削減や品質の安定化にはつながるので、ある程度は進められるとそのメリットを享受できるでしょう。


しかし、そうしたシステマチックな業務からは、新たな知見・ノウハウ・クレーム(顧客の課題やニーズ)といった業務改善のヒントも得られにくくなるのではないかとも思います。


もちろん現場が完全に担当任せになっていても、そうした新たな知見やノウハウはせいぜい個人やチームの中くらいで閉じてしまうので同じようなものかもしれません。


現場の知見やノウハウを正しく評価し、効果的と見なされればそれを全体に共有・実践・管理する仕組みがあるだけでも業務の改善が進みやすくなるかと思います。


そのときにデータ活用の出番も出てくるでしょう。


データ活用のかたち


一例として、バックオフィス系業務と営業・マーケティング業務でのそれぞれのデータ活用の形を紹介しましたが、決まった正解があるわけでもないのでこれで全てでもないと思います。


一方で、上記で紹介したデータ活用の前提条件や業務とデータのリンクなどはデータ活用を進めるために欠かせないポイントだと思うので、抑えておいてほしいところです。


なお、データ活用を進めるにはさらに大きな壁(社内の抵抗勢力や予算交渉など)がまだありますが、それらの乗り越え方はいずれまた。。。

アナリティクストランスレーター

Analytics translator is "must - have" role ?


最近表題の職種についてよく見かけるようになりました。元ネタはマッキンゼーのレポートのようです。

www.mckinsey.com


以前からビジネスとアナリティクスの間を埋める役割が必要とされているという話はよく聞こえていました。


確かにデータサイエンティストをうまく活用できない原因のひとつに、ビジネスサイドでの理解不足やコミュニケーション不全などもあるのでしょう。


しかし、新たにアナリティクストランスレーターなる人材を投入すればそれが解決されるのでしょうか?


上記のマッキンゼーのレポートでは、must have role と書かれていますが、実際のところは must have ではなく、nice to have なのではないかと思います。


つまり、「いたら便利かもしれないけれど必須ではない」ということです。


ビジネスサイドもアナリティクスサイドも求めているのはプロジェクトの成功やアナリティクスの導入・活用であって、アナリティクスの翻訳ではないはずです。


ある場面でアナリティクスの翻訳が必要なことはあるかもしれませんが、それを主とした役割の人材がいないとプロジェクトが成功しないなどという必須条件であるとはとても思えません。


おそらくそうした人材が無償かあるいはごく低価格で調達できるならばお願いしたいというニーズはあるかもしれません。


しかし、もしビジネスサイドやアナリティクスサイドの人材と同じくらいかそれ以上のコストがかかるというのならば、アナリティクスに知見のあるビジネスの人材やドメイン知識が豊富なアナリティクス人材を雇うほうが良いと判断されるのではないかという気がします。


Analytics translators need "project management skill" and "entrepreneurial spirit" ?


レポートでは、アナリティクストランスレーターには、プロジェクトマネジメントスキルと起業家精神が必要と書かれています。(あとドメイン知識と一般的な技術スキルもおそらく前提条件として必要とのこと)


確かに本来の目的であるプロジェクトの成功やアナリティクスの導入・活用を達成するためには、単なる用語や考え方の翻訳だけではなく他にも必要なスキルはあるでしょう。


ただそれが、なぜプロジェクトマネジメントスキルと起業家精神なのかはよくわかりませんでした。(私の読み方が浅いせいかもしれません)


個人的には以下のスキルの方が必要ではないかと思いました。


・アナリティクスの特性や注意点を踏まえたプロジェクト企画やプロダクト開発計画を立案できるようビジネスサイドを支援するスキル
 プランニングスキル
 アナリティクスプロジェクトの経験


・ビジネスサイドとアナリティクスサイドのコミュニケーション不全を解決して意思統一を行うためのスキル
 ファシリテーションスキル
 ネゴシエーションスキル
 ヒューマンマネジメントスキル
 調整力・根回し力
 プレゼンスキル(説得力)


To success projects


一方でビジネス側がアナリティクスを学ぶ、アナリティクス側がビジネス(ドメイン知識)を習得するという流れも今や一般的です。


個人的にはこちらの方がしっくりきます。


というのも、最初に述べたようにアナリティクストランスレーターはプロジェクトの成功などの目的に対して必須の役割ではないので、わざわざそのポジションに人をアサインすることまで必要なんだろうかと思います。


現状ではビジネス人材もしくはアナリティクス人材がそのポジション「も」こなすほうが、お互いの理解も進みプロジェクトの成功につながる気がします。


IT業界においてもビジネスサイドとエンジニアサイドの間にITトランスレーターやエンジニアリングトランスレーターといった職種の人は通常いませんよね。両者の間の橋渡しは、プロジェクトマネージャーやシステムエンジニア、ITコンサルタント、営業などの人たちが業務の一部として行っているのではないでしょうか。


ただあえてそのポジションの必要性を考えてみると、ビジネスとアナリティクスどちらにも寄らない立場の人間がいれば、双方からの苦情・苦言・不満などを吸い上げやすくなり、ガス抜きもできるという意味で緩衝材などとしては有用かもしれませんね。


さらにビジネスとアナリティクスとの橋渡しや緩衝材としてだけではなく、彼らをともに理解し、まとめあげ、お互いの強みを活かして相乗効果を発揮させられるような付加価値を生み出せる人材なら、歓迎される可能性は高いでしょう。


そのような優秀なアナリティクストランスレーターの活用によってプロジェクトが成功に導かれたといった事例が増えてきたら風向きは変わるかもしれません。


Where can we find them ?


さて、そんなアナリティクストランスレーターはどのように調達すれば良いのでしょうか?


レポートでは、外部からの採用はその企業に対する知識が十分でないため厳しく、内部人材を育成する方が良いとしてマッキンゼーのトレーニング実績が紹介されていました。


半分ポジショントークかもしれませんが、今までなかった職種に適正のある人材を新たに探して見つけるよりも、ベーススキルや経験のある人材に成長してもらう方が合理的な点は確かに納得できます。


ただ、よほど高いマネジメントスキルやコミュニケーションスキルを持つ素養のある人材が社内にいるならば、プラスアルファのトレーニングでなんとかなるかもしれませんが、そうでない人材に対しては一人前まで育てあげるのは容易ではないでしょう。


ということで今のデータサイエンティストのように役割を細分化されてそれぞれ得意な人たちを集めてなんとかするということになるのでしょうかね。


それで結局アナリティクス用語と考え方を翻訳するだけの人しか集められなかったら悲しいことになりそうですね。

私の経験とスキル

私自身データ分析職として約10年が経過し、ひとつの節目を迎えました。(社会人経験はもっと長いですが。。。)


それだけが理由ではないのですが、色々と思うところがあって現職を退職することにしました。


いい機会なのでこれまでの自分の経験とスキルをまとめておこうと思います。


実務経験について

データアナリスト


ここ7年ほどは、自社事業のデータアナリストと他社向けのデータ分析コンサルタントをやっていました。


自社事業のデータアナリストは以下のような感じです。

・営業部門  ⇒ 顧客分析、営業戦略立案のアドバイザリー
・経営層   ⇒ KPI設計/モニタリング/報告、意思決定アドバイザリー
・製品部門  ⇒ 商材の改善アドバイザリー
・販促部門  ⇒ 販促の企画立案支援、効果検証支援
・データ部門 ⇒ データ整備支援、データ仕様整備支援、BIレポート整備支援


他社向けには、マーケティングコンサルに近い感じで主に以下のプロジェクトなどを担当してました。

・流通業A社 ⇒ 需要予測、商品分析
・小売業B社 ⇒ 顧客分析、販促施策分析
・食品業C社 ⇒ マーケティング戦略立案、顧客分析
・小売業D社 ⇒ ロイヤリティプログラム改革


特に上記を含む数社からは是非うちに転職して欲しいと誘われ、それなりに満足してもらえたのではないかと思っています。


データアナリストリーダー


上記の企業にて、直近3年ほどはチームリーダーとしてチームの運営やマネジメント業務なども担当していました。


現場にアナリストを派遣するチームと、分析やデータ集計を受託するチームの2チームで、どちらも10名弱となります。


アナリストは若手中心で体制も確立されていなかったので、チームの業務体制の整備、役割分担、ビジョンと方向性の提唱、情報共有の仕組み、採用・育成プラン立案と実施などデータ分析の実務以外にも多岐に渡る業務を担当しました。


その他の仕事


上記の企業に転職する前の話ですが、ソーシャルゲームの分析官を1年弱ほど、またデータ分析関連ソフトウェアのセールスエンジニアを2年強ほどやっていました。


当時はビッグデータというバズワードが流行しはじめたくらいで、まだデータ分析などが一般的ではなかったため、なかなか前例や事例、ノウハウといったものがない中、手探りで色々と試行錯誤した記憶があります。特に機械学習ツールはなかなか良さを理解してもらえなくてセールスにはかなり苦労しました。


さらにそれ以前はプリセールスエンジニアとしてミドルウェアの評価・PoC(検証)・提案・導入・運用・サポート・コンサル・啓蒙活動・技術書執筆など色々とやっていたこともあって、多少の技術力と柔軟性は身についたのではないかと思っています。


それらは今も色んな面で活かされることもあり、自分の血肉となってるなあとも感じます。


技術スキルについて


データの抽出・集計としては、一番長く使っているのはSQLです。(データ分析職としてはほぼいつも使ってるので経験としては10年くらい)


データベースも、Oracle、Redshift、MySQL、(若干SQL Server)など色々と触ってきました。


専用のツールとしては、SAS EGとSPSS Modelerをどちらも3年以上の経験があります。


SQLでできない統計処理や機械学習用に使うツールは、主にRです。他にそのときの環境に応じてSPSSやDataRobotなどのリッチなツールの活用経験もあります。


強み(?)について


流通・小売系のマーケティング領域のデータ分析経験は豊富なほうかと思います。


特に顧客分析や販促施策の企画立案支援と効果検証は数多くをこなしています。


さらにKPI設計とデータ分析設計も簡単なものも含めればかなりの数をこなした経験があります。(おそらく100事例以上)


ブログでもよく書いてますが、データを意味ある形で活用できるように取り組んできましたし、これからもそうしたことに注力したいと思っています。



※※データ活用やデータ分析に関して、アドバイザリーやコンサルなどのご相談があればこちらからお願いします。