なにしてみよっか

サービスってなんだろな?を細々と。基本マニアックなネタが多いです。トヨタ生産方式を信奉してます。某製造業の営業と社内SEをやってました。

SoRとSoEはちゃんと考えようって話(4/5)

4回目です。

前回やこの長編全部を確認する場合は、タグから選んでください。

 

前回まででSoRもSoEも大切であり、でもそれぞれの役割の違いと求められる俊敏さの兼ね合いから疎結合なシステムでなければならないという話をしました。

余談になりますが、それはお客様向けのシステムであっても、従業員向けのシステムであっても変わらないという話もしました。

 

今回は、じゃあそんなシステムってどうやって作るの?って話です。

 

実は前々回のAmazonでお買い物する例えにヒントはあります。

こう書きました。

SoRに記録されている購買履歴とSoEの欲しいものリスト、閲覧履歴、さらにSoRの他の顧客の購買履歴とを突合させ、SoEとして「この商品を見た人はこんなものも買っています」(レコメンド)機能を出します。

欲しいものをSoEのカートに入れ、SoRで決済します。

SoRとSoEを行ったり来たりするもいうことを伝えるためにかなり端折ってるのは申し訳ありません。

この顧客体験を究極にシンプルにすると、

  1. 買い物に来る(アプリの立ち上げ)
  2. 商品を検索する
  3. カートに商品を入れる
  4. お届け先を入力する
  5. 決済する

以上。これら各々SoEのサービスです。いいですか?これから各々個別のSoEです。

 

前々回は決済はSoRって言ってました。すいません。実は正確に言えば決済した後、会計上の仕訳を行うフェーズがSoRです。しかし、お客様が決済を行うフェーズではSoEなんですね。

 

今回は端折らず正確に書きましょう。(と言いつつ、抜けてるかもしれません)

 

決済するってのは、こういうことなんです。

 

例)お客様がご自身のクレジットカードで決済する場合

  1. お客様がクレジットカードの番号を打ち込む
  2. 信販会社に問い合わせる。
  3. 信販会社が与信枠を確保する
  4. 信販会社が仮売上を立てる
  5. OKがカートシステムに返ってくる。
  6. 在庫が引き当てられる
  7. 理論在庫が1つ減る
  8. 「注文ありがとう」画面に変わる
  9. 購入履歴に記録される
  10. 売上、経費(輸送費、手数料など)のお金が仕訳られる

 

うーん、今思いつくのはこんなところでしょうか?

 

私の認識では、SoRは6,7,9,10で、それ以外はSoEです。とはいえ、これを一個ずつ作って疎結合にするのはナンセンスだと思います。

個人的な意見ですが、これらの手続きというかタスクを洗い出したら、「誰が」「誰に」を意識し、fromとtoが一緒なら1つの機能にまとまるかなと思います。今回の例なら2と3と4、6と7かなと。

そうすると決済に関わるプロダクトバックログは、SoEが4、SoRが2。合計6つになります。

これがシステムの作り方、だと思います。

 

今回はあくまで一例でかつ、現実的ではありませんが、イメージは掴んでいただけたでしょうか?

 

今回お伝えしたかったことは、今回の例のような1つのサービスを考えた時、プロダクトオーナーは、5つのバックログを考えるでしょう。しかし、スクラムマスター(とそのチーム)はその5つのうちのたった1つを6つにより深く分解し、バックログに登録する。

つまり、○○を提供したい!をバックログに落とし込むためには業務フロー、業務タスクをより小さく選り分け、かつどれをシステム化するのか仕組みでカバーするのはどれかなんてことをプロダクトオーナーと決めていかないといけないということです。

そしてその中にはSoRもSoEもある。

 

これをマジのガチでやろうとすると今までのような会議体では絶対にできません。

チームで寄り集まり、何を作るのかを全員が同じ目線で認識し、ワイガヤでやらないとバックログはできませんし、減ることもないでしょう。

 

そして、プロダクトオーナーは元より、スクラムマスターもサービスの内容を熟知した上で、かつ、サービスで儲ける内容をエンドツーエンド(顧客に届けることからビジネスの成果を記録するところまで)を認識していないとどのシステムを作り、どの既存システムを活用するのかを判断できません。もっといえば、記録したデータに基づくKPIを設定する事で、経営から現場までゴールに向けた即断即決のビジネスプロセスが生まれます。

 

スクラムマスターはどう頑張るか。

チームとともにサービスを構成する業務プロセスを細かく分析し、細かいサービスに分解し、それをプロダクトオーナーに理解させる。チームを鼓舞し、ティーチング、コーチングし、自分たちの提供するサービスの中で作るのか、それとも外部のサービス(既存のシステムを含む)を使うのか、仕組みでカバーするのかを決めるまたは決めるための判断材料を整え交渉する。つまり、社内を渡り歩くだけの知識を持った人間として立つ。

これが、スクラムマスターが頑張らなければいけないことだと私は思います。

 

今は、サービスをお客様に提供することにフォーカスが当たっていますが、近いうちにそれを記録するところまでを見据えて仕組み化(あえてシステム化とは言いません。なぜなら、システムとして構築するのは手段に過ぎませんから)する事にチャレンジしなければなりません。

なぜなら、経営はそれを欲しているからです。自社の成果を見えるようにするためには記録することをサボっては即断即決になりません。

経営は現場から一番遠いです。でも判断は経営がしないといけない。現場で起きていることを目の前に。そのためには、リアルタイムでのデータの記録と可視化。

 

今、企業にある記録するための基幹システムはおそらくそんな機能は備えていない。それだけはちょっと悲しいことなんですけどね。

 

 

さて。

SoRもSoEも大切であり、密接に絡むものでありながら疎結合でなければならない。ユーザー企業の担当者(プロダクトオーナー)はもっと全体(お客様から成果を記録するところまで)を俯瞰して価値を提供するという考え方にならないといけない。そんなことをお話ししてきました。

 

では、そんな人間にどうしたらなれるのか。今の私が一番苦しいところを共有できればなと。