00:00
(♪ BGM)
おはようございます、Zerotopicです
またまたお久しぶりという感じですね
ちょっと久しぶりに時間ができたので
収録をしようかなと思って
実は会社の中でこういう話を撮ってほしいとか
こういう話をZerotopicで出してほしいとか
実はいっぱいなんか要求リストみたいなものが
上がってるんですけど
これらは全て無視して
ちょっとカジュアルに話せるものを
15分ぐらいで撮れればいいかなと思って
マイクに向かってます
今日は先日システムオブレコード
あとはシステムオブエンゲージメント
この2つの概念をうまくマネージしていくの大事だよ
みたいなツイート
というか1級のCTOの伊藤直哉さんの資料が素晴らしくてですね
これを何度も読み返してるんですけど
これが素晴らしいよみたいな話をしたら
結構ツイッター上で反応いただいて
これについてウィッチがどう考えてるかみたいな
僕がどう考えてるとか
TENXではどう解釈して
どういうふうに使われてるか
みたいな話をしようと思ってます
まずはじめにシステムオブレコード
これSORでシステムオブエンゲージメント
これがSOEそういう呼び方されてるんですけど
あまりこうプロダクト開発の観点でも
そんなに聞き慣れた言葉ではないかなと思うので
これをそれぞれ軽く説明しようと思ってます
まずSORの方なんですけど
これどういった性質のシステムかっていうと
精密に記録を残すっていうことに対して
ものすごい品質が求められるっていう
そんな性質のシステムを指してます
なので成功というか
性質としては非常に安定していることだったり
アウトプットが予測可能であったり
あとはリスクが低く利用可能だったり
あるいは要件が極めてクリアであるっていう
なんかそういう性質が求められて
システムの領域としては
主にバックエンド側によることが多いですと
例えば認証システム
IDパスワード入れてアクセストークンもらうとか
このトークンを使って
いろんなウェブアプリケーションを動かすっていうのが
いわゆるアプリケーション上では
一般的な構成だと思うんですけど
それにあたって認証の仕組みって
絶対にミスしちゃダメ
例えばIDパス入れたら
他の人のトークンが返ってきて
なんか全然違う購入利益見えてる
みたいなものが起きると
おそらく一発で大事故というか
場合によっては会社から数億円とか数十億円とか
そういうお金が飛んでくような事故になるので
これは絶対ミスできないですとか
あと在庫とかですね
お客様にこれを販売できるっていう在庫の管理が
図3で買ったんだけど
全部欠品でしたみたいになった場合
あるいは決済とかもそうですね
03:00
クレジットカードでチェック切ったんだけど
実はその3倍金額を下されてました
すいませんてへぺろみたいなのは許されないわけで
こういった領域はSORで捉えられることが
できるかなと思っています
この直屋さんの資料概要欄にも貼っておくんですけど
その中で開発手法とかプロダクトマネジメントとか
ケイパビリティとか
そういうところについても言及があるんですが
あえて僕はここは今回は言及しないでおきます
理由はこの領域ってSOR SOEでは
パリッと区分けできるものではないというか
必ずしも区分けしなくてもいいものかなという風に
個人的には思っているからです
もう片方のSOEの方ですね
SOEの方は何かというと
それを使ってくれるシステムを使ってくれる
ユーザーのつながり
エンゲージメントなんで要は何度も使ってもらうとか
リテンションするとか頻度を高めるとか
そういう観点が非常に重要になるシステムです
どういうところに対して適応されるかというと
一つはユーザーのインターフェース
そこの印出を保っていくとか
インタラクションとか
ボタンを押したらどういう反応が返ってくるかとか
そういったものがこれに当てはまっていて
業務としてはかなり探索的な業務
要は正解がないので
どうやったらエンゲージメントが高まるかという
ゴールだけは同じなんだけど
そのゴールに対しては探索が求められるとか
あとはスピードが必要だったりですとか
あとは探索=トライアンドエラーとか
あとはプロタイピングを通じて
実験の速度を速めていくとか
そういう性質があるのかなと思っていて
システムの領域としては当然なんですけど
フロントエンドとかモバイルアプリのクライアントとか
UIとかCRMとか
そういった領域に適応されやすい
考え方かなと思っています
この資料の中では
SORはウォーターフォール寄りで
SOEはアジャイル寄りで
みたいな開発の手法については書かれてるんですが
これは先ほどお話しした通り
他層とは限らない
SORでもアジャイルでやってるところもあれば
SOEだけどウォーターフォールでやってることもあって
それは必ずしもパリッと分かれるものではないかな
というふうには思っています
というのがまずざっとした概要ですね
これはなべさんの資料を読んでいただけるとわかるんですけど
ガートナというコンサルが
バイモダルという戦略を2011年にも掲げていて
こういう2つの異なる文化を合わせ持つっていうのが
これからの組織にすごい大事だよってことを
おっしゃってたようです
今から11年前とかなんで相当早いですよね
なぜ僕がこれ取り上げてるかっていうと
すごくこの観点って
我々の事業に対して
ダイレクトに重要な概念だなってふうに思ってるからなんですよね
06:01
どういう意味かというと
Stellaっていう10Xがやっている事業はB2B2Cのモデルで
どういうプロダクトがその中に入っているかというと
当然お客様を扱って
エンゲージメントを高めなきゃいけないものってのが入りつつ
そのお客様が例えば何かを買ったってなったら
その注文の履歴を正確に残さなきゃいけないとか
さっきのクレジットカードとか認証とか
まさにこのサービスの中に詰まっているので
そのあたりはSORだよねっていう
そういう区分けがまず簡単にできますというのがあるんですけど
同時に我々スタッフさん向けのアプリ
要はエンプロイ向けのアプリっていうので
B2B2E
あとは本部の方が使う
これもB2B2Eの管理画面とか
なんかそういったものを使って
彼らがサービスを運用していくための
全てをご提供していたりするんですよね
こういう中においては
彼らが使っているモバイルのクライアントアプリもあるんですよ
ただこういうものも実は全部SORとSOEの
両方の性質を持ったシステムで構成されてるなって感じています
業務用だから全てがSORだとか
2Cだから全部がSOEだとかそういうことはやっぱりなくて
なんか一つ一つの塊
プロダクトとしての塊の中に
やっぱり両方の性質を常に合わせ持つなと思っています
例えばなんですけど業務の中で使うっていうのだと
ネットスーパーはお客様から注文を受けた後に
大量の商品を売り場からピッキングしてきて
でそれはお客様のごとかつ
温度帯、常温、冷蔵、冷凍ごとその3つに分けて
パッキングをするっていう業務があります
でこの業務って間違ったら大事故なわけなんですよね
例えばあるお客様に入るべきではない商品が間違って入ってしまったってなると
買ったものと違うものが届く
でもそれ20何点かける何十件とか何百件やってたら
数千商品を間違わずに入れなきゃいけなくて
これってなんか業務上はものすごいSOR的な仕組みが求められるんですけど
この作業をより簡単にするとか
やってて従業員が気持ちよく完了できるようにしないと
言うたらめちゃめちゃ苦痛なんですよね
紙とかでやったら本当に大変なんですよ
なのでSOE的なスタッフアプリ、アプリケーションのクライアント上で
いかにその体験を良くするかっていうその概念を合わせ持っていたりします
ので僕らのプラットフォームとかその上に乗っかってくるアプリケーション一つ捉えても
このSORとSOE両方の概念っていうのが混ざってるよっていうのが
まず我々に捉えた時に必ず起きてることなんですよね
これは実はどの会社さんも同じなんじゃないかなと思ってて
特にSaaSとか作ってる場合はSOEの領域が弱いと
09:00
多分カスタマーサクセスにめちゃめちゃ負担がかかります
なのですごい体験が良いBMKのアプリケーション頑張って作ろうっていうのは
圧力としてあるだろうなっていうふうに思いますし
CMKで見てもCMKなんでSOEだらけかっていうとそんなことはなくて
さっきみたいなSOR的な観点っていうのは必ず必要になってくる
要はレコードをちゃんと残していくっていうのが重要なのかなって思ってます
SORだとQCDでいうとクオリティっていうのがまず100担保した上で
どんだけデリバリーを詰めていけるかみたいな概念で
割とトップダウンのプロジェクトマネジメントが多いよってことが書かれてたり
逆にSOEのところだとボトムアップ寄りで正しいっていう仕様自体は存在しないんで
なんか検証をとにかく早く回せるようにしようっていう
この2つで分けれるよっていうふうに書かれてたりするんですけど
さっき言ったとおり1つのプロダクトの中にこの両方の要素領域って必ず混ざってるんですよね
なのでどちらかがどちらみたいなパッキーとした区分けっていうのはできなくて
どちらかと必要になるのは品質もデリバリーも両方をマネージするためには
どういうプロセスを設計すべきかとか
その上で不確実性を徐々に処理していくためにはどうしたらいいかってことを考えると
実は最近のちゃんとアジャイルのメソッドロジーというか方法論をちゃんと導入するっていうのは
実はアジャイルって早くやろうっていうよりはその不確実性を正しく早く処理しようっていう概念で作られてる開発プロセスなので
実はSORもしっかりアジャイルで対応することができるんじゃないかな
で逆にウォーターフォールでSOEを対応しようとすると非常に使用の検討みたいな正解がないものに無駄に時間をかけてしまうので
不確実性の対処が正しくできない可能性がありますと
そういう観点で言うと実はうまくアジャイルっていうものを使いこなせると
SOR SOE 両方を使えるシステム開発に対してはいい影響を及ぼせられるんじゃないかなっていうふうには思ってますね
それがまず一個とあとは組織の話をしたくて
よく逆コメというかあるべきシステムの設計像と組織の設計像を合わせていこうみたいな話にもこの概念って結構使えるなというふうに思っていて
僕らで言うと今マトリックス型の組織形態を取って仮に取っていて
10月1日から新しい組織形態に完全に行こう
そのマトリックス組織に移行しようっていうのですごい準備をしてきています
これ大体1年がかりぐらいのプロジェクトですかねという形で進めてきていって
マトリックス型の組織っていうのは縦が顧客に向き合う事業をやっていく
チームトポジで言うとストリームアラインドチームで
横にプラットフォームチームとかエネベレメントチームみたいなその縦のストリームを支援するためのチームができる
なので縦はやっぱりその我々で言うとパートナーを向いている事業開発とかのチームになっていて
12:02
横にプロダクト開発とかグロースみたいなチームが横についていて
ここから人をアサインするとか縦と横の間でインタラクションができるコミュニケーションできるパイプを
Xアザサービスモードみたいな形で作ったりしながら
プラットフォームとしての価値を高めていくって事と事業価値を高めていくって事を
両方縦横のラインで進めていくっていう組織設計なんですよね
この中でもいわゆる横の中ではここは100%SORですっていうチームもあれば
ここはかなり100%SOEに近いですっていうチームもあれば両方混ざってますっていうチームもあります
縦は必ず両方が混ざります
顧客の体験を成功させるためにっていう概念と
顧客のレコードちゃんと残して業務に支障が出ないようにするみたいな概念と2つあって
組織の設計的には実は箱の単位でここはSORだよねとかここはSOEだよねって
100%区切れると理想だったなって風には思ってるんですけど
当然やっぱりそうはできない
システムがコンプリケットというか混ざり合っている以上は
この2つの概念をちゃんと処理するチームっていうのもうまく設計したり
そこらへんは投資の方針みたいなものもちゃんと決めて
1つのチームの中で同じようにそれをさばけるようなプロセス
さっき言ったアジャイルみたいなプロセスの中で
両方の仕組みを解消できるような
開発できるようなプロセスに寄せていくっていうことの方が
僕ら正しいのかなっていう風に考えていて
現状はそういった経過をチームに持たせていくような流れになってます
なのでうちのストリームアラインドチームとしての縦の組織っていうのは
すごい要件定義とかプロジェクトマネジメントみたいな
いわゆるエッサイアーさんが得意とされるような経過も持ちつつ
その中に例えばデザイナーがクロスアサインされて
ユーザーインタビューした結果から
お客様のエンゲージベントを高めるためにはこういう仕様がいいんじゃないか
これを開発ボリュームできるだけ少ない中で試すにはどうしたらいいかみたいな議論が
両方内在してて
その両方をそこの事業を見ているメンバーは
しっかり認識するっていうそんな体制になっています
これ認知不可自体はやっぱり少し上がってしまうものの
ある一社あるパートナーを成功させようと思った時には
やっぱあのなんですかね
SORとSOEをパッキー分けて同じパートナーに対応するんだけど
それは別のチームですっていう状態よりも
はるかに何ですかね価値を出していく流れはスムーズだなって風に思っていて
TENXではそういう風にこのSORとSOEの概念をうまく活用しています
はいということでちょっとね子供も起きてきたんで
だいたい話したいことも話せましたので
今日はこんなところかなと思っています
ぜひこの概念についてはすごく皆さんというか聞いてる方の会社のサービスとか
15:04
組織開発上ではどう運用されてるかなって
メタ認知してみるのもすごく面白いですし
なんかその意見を聞かせていただくのも結構僕にとっても勉強になるなっていう風に思ってるんで
もしご感想とありましたらぜひお聞かせください
はいそれでは
(♪ BGM)
