いつもとちょっと違うイキフンのタイトルなんですが、今回はDXに取り組むビジネスサイドに求められる変革についてお伝えしようと思います。

とその前に。

DXってなんやねん

と思われる方もいらっしゃいますよね。

そんな方にはこちら。

テッテレーーーー♪

手前味噌ですが、こちらをどうぞ。

簡単に解釈すると、DXとは「データとデジタル技術を活用して、競争上の優位性を確保する」ということです。

誰のための、どういったモノを作るのかは定義されていません。

なので、

「DX」を掲げてどのような価値を創造するかは、その企業次第ということです。

誰にも正解はわかりません。

本題に入る前に、少し過去のコンテンツを使っておさらいをさせてください。

DXにまつわるおさらい

①DXとは「オープンエンドな課題」に取り組むこと

まず前提として、以前こちらのコンテンツでも書いたのですが、Co-Liftでは（一部の例外を除いて）デジタルプロダクト開発に終わりはないと考えています。

従前に決められる正解がないと言った方が伝わりやすいかもしれません。

例えば、スマホゲーム。

スマホのゲームって、事前に決められたゴール（ゲーム的に言うとエンディング？）がないですよね。

パズルゲームはもちろんのこと、ポケモンGOのようなフィールドゲームもゴールはありません。

次から次へと、新しいイベントやキャラクターが追加されて無限に遊べますよね。

新しいイベントやキャラクターの追加は、そのスマホゲームのリリース当初からスケジュールに落とし込まれてたんでしょうか？

答えはおそらくNOだと思います。

そのスマホゲームを開発した企業が、「次はこういうイベントを仕込んでみよう」とか「キャラクター追加は何段階かに分けて行おう」とか言いながら、ユーザーの反応を見て試行錯誤した結果、今のスマホゲームになっているのだと考えます。

もちろんスマホゲームだけではなく、ECも、BtoBマッチングサービスも、ポータルサイトもそうで、従前に決められるゴールはないことが大半です。

このような事前に正解が分からず、あらかじめゴールを定義できないような終わりなき課題をCo-Liftでは「オープン・エンド」な課題と定義しています。

そして、

DX=オープン・エンドな課題に取り組むことだと考えています。

さらにもう少しだけ、おさらいにお付き合いくださいませ。

②オープン・エンドな課題に取り組むのに適した開発手法が「アジャイル」

Co-Liftでは、オープン・エンドな問いを解決するために発展し、標準化されたソフトウェア開発手法が「アジャイル」である、という捉え方をしています。

システム開発手法の一つである「アジャイル」と「ウォーターフォール」の違いについては、下記で詳しく触れてます。

システム開発において重要なのは、直面している課題の性質を正しく認識し、課題の性質に適した開発手法を取っていくことです。

③おさらいのまとめ

おさらいが長くなってしまい恐縮です。軽くまとめますね。

• DXとは「データとデジタル技術を活用して、競争上の優位性を確保する」ということ

• DXに予め分かっている正解はない

• 事前に正解が分からず、あらかじめゴールを定義できないような終わりなき課題＝オープン・エンドな課題

• オープン・エンドな課題に取り組むのに適したシステム開発手法が「アジャイル」

さて次がようやく本題です。

じゃあ、いざデジタルプロダクトを開発するぞ！ってなった時に、

開発組織や開発ベンダーに

アジャイルでよろしく！！！

って言えばいいかというと、

そうは簡単に行かない。

むしろDXにおいては、発注する側にこそ変革が求められています。

DXにおいて必要とされる発注側の変革とは？

システム開発とは、ビジネスが実現したい「コト」をシステムという「モノ」に変換するということです。

ビジネス側がやりたい「コト」を「モノ」側にうまく伝えられるかが鍵となります。

それでも、これまで業務の電子化などに取り組んできた経験のある方などは、「ある程度の大枠を開発ベンダーに伝えれば、開発側からヒアリングしてくれたよ？」と思われるかもしれません。

なぜ上手く行ってたのかというと、取り組む課題の性質がクローズド・エンド、すなわち「正解のある課題」だったからです。

クローズド・エンドな課題の場合

例えば、紙に押印するハンコをなくして、全て電子ハンコにするというシステム開発を考えてみましょう。

この時のゴールは「すべての書類のハンコをなくし、電子化する」です。

ビジネス側の要件を受け、開発ベンダーはこのようなヒアリングを行うでしょう。

・現在、ハンコを使っている書類の種類や総量はどのくらいですか？
・現在、誰がハンコを使っていますか？
・いつまでに電子化したいですか？

そして、ヒアリングが終わると要件定義書と見積書を出してくれるでしょう。
・現行業務とのギャップを考慮して、機能Aと機能Bを開発します
・予算はXXX万円、開発期間はXXヶ月です。

そう。

「クローズド・エンド」な課題、すなわち、予めゴールが設定できる類の課題に対しては、モノ側から翻訳作業を行うことが可能なのです。

なぜ「モノ」側から歩み寄って翻訳作業が可能になるかというと、
・基本的に一度だけ
・正解が定義可能
・「モノ」を作り始めたら大きな変更が起こらない
からです。

オープン・エンドな課題の場合

では、オープン・エンドな課題、すなわちDXに取り組むときはどうなるでしょうか。

DXの正解は誰にもわかりません。

あるのは、ビジネス側が立てた「仮説」です。

仮説を立て、その仮説に基づいた要件仮説を作り、開発し、顧客にぶつけてみてフィードバックを得て、改善・修正を行う・・・という仮説検証の反復（イテレーション）が求められます。

そのため、やりたい「コト」を定義して作りたい「モノ」に伝える翻訳作業は、何度も発生します。

先ほどのスマホゲームの例で一連の動きを考えてみましょう。

ーーーーーーーーここから妄想ーーーーーーーーー

ビジネスさん「GPS連動で、特定の場所に行くと謎解きが出来るゲームを作ったらどうだろうか？」（←初期仮説の立案）

開発さん「GPS連動機能と、マッピング機能と、謎解きコンテンツそのものがあれば出来ますね」

ビジネスさん「ではそれで行きましょう」（←初期プロダクト要件の確定）

開発さん「承知した」（←初期プロダクト開発）

ーー祝！初期プロダクトリリースーー

ビジネスさん「初期プロダクトのダウンロード数は好調だった。しかもTwitterでユーザー同士の会話が盛り上がってる」（←ユーザーフィードバックの検証）

ビジネスさん「ソーシャル機能もつけたら、もっとユーザー数が増えるかもしれない」（←次の仮説立案）

ビジネスさん「開発さん、アプリ内チャット機能もつけられますか？」

開発さん「チャット機能だと、XX人月ですね」

ビジネスさん「ではそれで」（←プロダクトv1.1の開発スコープ決定）

開発さん「承知した」（←プロダクトv1.1の開発）

ーープロダクトv1.1リリースーー

ビジネスさん「チャット機能だけだと、思ったほど増えない。相変わらずTwitterでは盛り上がってるのに」（←ユーザーフィードバックの検証）

ビジネスさん「Twitterアカウントでログイン出来る様にすればいいんじゃないか？」（←新たな仮説の立案）

ーーーーーーーー妄想おわりーーーーーーーーー

みたいに、リリースしてすぐにユーザーの反応をみて、搭載する機能やサービスを機動的に修正していくことが求められます。

仮説通りにうまく行くことなんてほとんどなくて、何度も何度も顧客にぶつけてフィードバックを貰い、また新しい仮説を立てる・・・という繰り返しになるので、要件は変わり続けます。

こうなると、モノ側からの翻訳が非常に難しくなります。

開発側（モノ側）は顧客に直接向き合っている訳ではないので、仮説の精度はビジネス側（コト側）ほどは高くありません。

何度も何度も、ビジネス側に「この仮説で合ってる？」と確認するのでは、時間もかかってしまいますよね。

だから、DXにおいては

直接顧客と向き合って、やりたい「コト」の仮説を定義できるビジネス側こそ、この翻訳作業を行うべきなのです。

では、発注側は具体的にどうなればいいの？

「じゃあ、DXにおいて翻訳作業ってどうすればいいの？」

「そうは言っても、システム開発のことなんて分からないよー！」

「開発の人ってカンタみたいにすぐ呪文唱えるじゃーーーん！」

と思われる方もいらっしゃるかもしれません。

否。

むしろ殆どの方がそう思われるのではないでしょうか。

大丈夫です。

焦らないで。

Co-Liftの研修受けてもらえれば、出来るようになります。

というのは冗談で。

今後のnoteでも、研修のすべてはお見せできないですが、エッセンスを掻い摘んでお伝えできればと思います。

長い長いおさらいに加え、横文字ばかりの今回のnote。
最後まで読んでいただきましてありがとうございました！