この辺が少し言語化出来た気がするのでメモる。

顧客にITによる便益を提供するはずのIT企業で、「こういうITを用意するといいですよ」という要件定義や顧客のコミュニケーションを取れる人間がいない。

要件定義や顧客のコミュニケーションが出来る人がいないって話は、ITプロジェクトを立ち上げるノウハウが組織の中に蓄積できていない、と同じだ。これが答えだと思う。

ITプロジェクトを立ち上げるというか、プロジェクトを立ち上げるために必要なことって、ゴールデンサークルの精度。「WHY→WHAT→HOW」の落とし込みが練られているかそうでないかは、HOWのレベルで分かる。大抵詰まるのが「How」への落とし込みだから。

最近あった話だと、オムニチャネルにおける顧客データの一元管理。実店舗とネットショップを運営していて、ネットショップはASPを使っている。実店舗の顧客とネットショップの顧客が全く別になっており、どうしたら一元化できるかわからん、と。

やりたいことは、実店舗のプレゼンス向上と、顧客のLTV向上。これがWhyに当たる。一元化の先にあるものがWhy。Whatが「顧客データの一元管理」「実店舗とネットショップの連携(ネットで実店舗の在庫がわかる等)」

問題が「How」だ。どうやって一元管理するのだ。店はPOSで売上を立て、ネットはネット。新規会員はこの2つの道からとめどなくやってくる。

結論から言えば、親となるDBを立てて、POS/ネットショップの会員情報と同期させるしかない。完全に1つのDBにはできないから。

次に問題になるのが、POSで売りを立てる時に身分証明。QRコード的なものを発行し、POSで読み取り、一元化したDBに問い合わせるフローが必要だ。ネットショップの場合だと会員登録が終わったタイミングでDBに問い合わせ、二重登録を防ぎつつ、ネットの購入履歴と実店舗の購入履歴をマージしないと意味がない。こんな感じで色んな「HOW」を、この時にどんな物事が起こり得る？それはどうやって処理するもの？・・・を、詰める。

こういう地道なやり取りの果てに、Howが固まってくる。Howが固まらないと機能要件が導けない。Howの議論が立ち行かないと感じた時は、ゆーすけさんの記事にもあったサービスブループリント(With Miro)を起こして、議論をする。

サービスブループリントの大切なところは、人とシステムが全部網羅されていること。サービスを享受する人の目線と、享受したサービスを作って回す人の視点及びその根拠(ITやツール)に認識違いがあると、うまくいかない。

業務と作業に分解できていることも大切。サービスブループリント単位が業務。中分類がITで行うタスクで、赤い四角のレーンに書かれている内容がそれ。このタスクをこなすのにUIが必要になるので、ページとか画面とか、そんな単語が見え隠れする。

このサービスブループリントの考え方は、開発にとどまらない。例えば、端末の資産管理やプロビジョニングなどのサービスを導入する時も、整理ができる。こういう全体像の中でやりたいのはこれで、それを実現できる複数のサービスから何を選ぶか、みたいな判断軸ができてくるはず。

この全体像を作ることが、要件定義じゃないかなって最近感じている。

こういうスキルをどこで身につけたら良いかって？ わかんない。ただ、この種の議論ができるコミュニティが無いように思うので、こういう話が好きな人だけで懇親会でも・・ってコロナなんだよな〜