DXにおいて発注側が身につけるべきスキルとは？ ー後編ー
前回のnoteでは、DXを推進するにあたってビジネスサイドが身に付けなければならないのは「やりたいコト」を「つくりたいモノ」に翻訳するスキル＝システム開発にあたって必要となる重要論点を書き下せるスキルであるとお伝えしました。
例えば1to1マーケティングで言うと、このくらいのシステム構成図が書けると良いです。
いや、しかし！！！
そんなん突然言われましても！！！！！
という方の気持ちもわかります。
大丈夫です。
ドントウォーリー
今回はシステム構成図を書くための具体的な方法についてお伝えします。前回でもお伝えした「IPO」を覚えていらっしゃいますでしょうか？
このIPOを使って、ステップを踏んで解像度を高めていきましょう。
ステップ1：やりたいコト全体をIPOで捉えなおす
ステップ2：Pを小さな動詞に分解していく
ステップ3：PとPの間のインターフェースを決める
【ステップ1】やりたいコト全体をIPOで捉えなおす
まずは、ビジネスサイドがやりたいコトを、IPOで捉えなおしてみましょう。
IPOを端的に言うと、
Input：何を
Process：どうして
Output：どうなる
です。
例えば、ECサイトにおけるユーザーの閲覧履歴や購入履歴に基づいて、ユーザーにおすすめする商品のレコメンドメールが送られる場合を考えてみましょう。
Outputから考える方がわかりやすいかもしれません。Outputは、「ユーザーにレコメンドメールが配信される」ですね。
そして、Inputは「ユーザーが商品を閲覧もしくは購入する」です。
問題は、Processですね。ここが難しい。
レコメンドメールが配信される時、システムは何してるかっていう話ですよ。
一旦、ステップ1では以下のようにしておきましょう。
Input：ユーザーが商品を閲覧もしくは購入した情報を
Process：（システムが何やらかんやらして）レコメンドメールを配信する
Output：ユーザーにレコメンドメールが配信される
詳細はステップ2で考えます。
【ステップ2】Pを小さな動詞に分解していく
次に、Pを小さな動詞に分解していきます。
ユーザーの閲覧履歴に基づくレコメンドメールにおいて、Pは一旦「（システムが何やらかんやらして）レコメンドメールを配信する」と置きましたので、これを細分化していきます。
細分化していく時、システムはどのような挙動をしているのか？を、考えていきましょう。
ポイントは、後ろ工程から考えることです。後ろの工程、すなわち下図で言うところの「Output：ユーザーにレコメンドメールが配信される」ためには、何がどうなっている必要があるか？を考えます。
ここは簡単かもしれません。
そう、「システムがメールを配信する」です。
システムがメールを配信するから、ユーザーにメールが配信されるのです。
え？そんなこと？
とお思いになる方もいらっしゃるでしょう。
はい、そんな簡単なことでいいんです。難しくないでしょう？
ちなみにこの小さなPの塊をここではコンポーネントと呼ぶので覚えておきましょう。今後も使います。
では、次に移りましょう。
システムがメールを配信するためには、どのような工程が必要となるでしょう？
メールがどのような要素で出来上がっているか考えてみるといいですね。
はい。
答えがわかった人は手を挙げてください。
ここで手を挙げる人、
素直で先生は好きです。
そうですね。メールを送るためにはメールを送る相手（メールアドレス）とメールの中身が必要です。
と言うことで、Pの細分化はこうなります。
さらに続きます。まずは配信先リストから考えましょう。
メールを配信したいターゲットは、どんな人たちでしょう？
答えはInputのところに書いてありますね。
商品を閲覧/購入したユーザーです。
そのため、「配信先リストを生成する」というコンポーネントの前工程として「配信条件を設定する」が必要となります。
「配信条件を設定する」は、自動的にそれを行なってくれるツールももちろんありますが、ここではマーケターが手動で行うことにしましょう。
ちなみに、システム開発を行なっていると忘れがちなのが、このように突然出てきたマーケターのように「誰がそれを実行するのか？」のオペレーションの論点です。本題からは逸れるのでここでは触れませんが、めちゃくちゃ重要な論点なので、忘れないようにしましょう。
では次に、「配信コンテンツを生成する」ために必要な工程を考えてみましょう。
送りたいメールは「閲覧/購買履歴に基づいたレコメンドメール」でしたね。
なので、「こういう商品を閲覧したユーザーには、次はこの商品がオススメ」というレコメンドの計算が必要となります。
さらに、そのレコメンドの計算が発動する（発動って言い方かっこいいな）ためには、そもそもユーザーがサイトを訪問し、商品を閲覧したり購入したりしなければなりません。
これをコンポーネントで表すとこうなります。
さて。
これで「Process：レコメンドメールを配信する」の大枠が完成です。
ステップ2の最後に、各コンポーネントで意思決定していかなくてはならない論点を抽出していきましょう。
例えば、下図のような論点が抽出できると思います。
ここまで来て、こう思う方がいらっしゃるかもしれません。
「Pの細分化って、そんな荒くていいの？」
と。
・・・さすが
鋭いですね。
その通りです。
Pの細分化は、細かくしようと思えば、どこまでも細かく出来ちゃうものです。
できるだけ細かく表現して、モノ側の負担を軽くしたい！一刻も早くプロダクト開発に向かいたい！という方は、このくらい細かくしても良いと思います。
上記の微細化したシステム構成図が作れるかどうかは、IT知識があるかどうかで決まります。
システム構成図が細かければ細かいほど、システムを作るモノ側の解像度は上がっていくので、開発スピードは上がりますし、コミュニケーションコストは下がります。
【ステップ3】PとPの間のインターフェースを決める
最後のステップとして、PとPの間のインターフェースを決めます。
インターフェースはI/Fと表されることもあります。
インターフェースは要するに、細かなPのコンポーネント間が、どのような条件下でどのように挙動するのかの条件です。
例えば、ユーザーが商品を閲覧/購入したときのI/Fにおいては、
・商品閲覧/購買はどのくらいの頻度でデータ取得するのか
・クッキーベースでデータ取得するのか？IDベースか？
・自動で後工程にデータが送られるのか？手動で行う必要があるのか？
等々の決めるべき条件が挙げられます。
ええ、、、こんな細かいことを全部決めなければダメなの？
分かんないよ、そんな細かいこと。
そう思われる方もいらっしゃるかもしれません。
でも大丈夫です。
もちろん、最終的にデジタルサービスやデジタルプロダクトを開発するためには、すべてのインターフェースを事細かに決めていく必要がありますが、すべてのインターフェースを厳密に決定していくのはモノ側、つまりシステム開発を担うベンダーや開発部署の仕事でもあります。
インターフェースの決定において、コト側（ビジネスサイド）に求められるスキルは以下の3点。
I/F仕様書が読める事
主要論点のヌケモレが分かる事
論点を決められる事
です。
例えば、開発サイドに「配信コンテンツは固定ですか？可変ですか？」「配信頻度はどうしますか？」「いつの閲覧履歴を使いますか？除外条件は作りますか？」等々を聞かれた時、適切に判断できる人がビジネスサイドに居ないと、開発スピードは遅くなってしまいます。遅くなってしまうならマシな方で、もし致命的な判断ミスをした場合には、ビジネスサイドが想定していたものとは違うモノが出来上がってしまうのです。
だから、ビジネスサイドもスキルを身につける必要があるのです。
ちなみにI/F仕様書とはこんな感じ。
「どこからどこへ？」「どういう状態で？」「どのようなデータをやり取りするのか？」などを、ここから読み取る必要があります。（これでもまだ荒いものですがサンプルということで）
ちなみに（「ちなみに」多くてすみません）、このI/F仕様書を決めるときに割と、相手先のシステムと「え・・・これってどっちが決めるんですかね？」「うちのシステムに合わせて、そちらが開発してくれるんですよね？（圧）」とお見合い状態になることは、よく起こります。
そう、まるで・・・
あと数センチだけ残して冷蔵庫にしまわれる麦茶のごとく、お互いに面倒なタスクをなすりつけ合うことになるのです。
I/F仕様書を巡るあれやこれやは、またどこかで。
まとめ
前編後編で分けた今回のnoteでは、DXを進めるにあたってビジネスサイドに求められるスキルのアップデートについてお伝えしました。
・よくあるポンチ絵ではダメな理由
・必要とされるスキル
・ポイントとなるIPOとその細分化
を、順を追ってご説明しました。
できる限り簡潔に、分かり易いようにこのnoteで伝えたつもりですが、伝えきれないこともたくさん。
まずは、「やりたいコト」を「つくりたいモノ」に翻訳するスキルが、ビジネスサイドに必要な理由と、その具体ステップについて、イメージが付いたようでしたら幸いです。
本日も読んでくださいましてありがとうございました！