10Xのアドベントカレンダー
こんにちは、ゼロトピックです。
この数日で寒くなって、めちゃくちゃ冷えてきたんですが、皆さん、体調いかがお過ごしでしょうか?
ということで、これが今年最後の収録になるかなと思っています。
おそらく、年始は1月の3週目か4週目ぐらいからスタートしたいなと思って、少し間が空くんですけども、
今日はですね、10Xのアドベントカレンダーの方で、最終日、本日25日、クリスマスですね。
自分は記事を書いたので、そちらについてちょっと解説というか、口頭でもお話ししていくような回をとれればなと思っています。
まず、10Xのプロダクトアドベントカレンダー2023なんですけども、
去年、一昨年もやってたのかな?去年かな?
去年からアドベントカレンダーを弊社としても開始してまして、かなりいろんなメンバーが書いてくれました。
今年のみんなが書いてくれた記事を眺めていくと、結構テーマが似通ってるものが多いなと思っていて、
一つはデータの話。例えばデータの話で言うと、そうですね。
12月14日。
天神林さんが書いてくれた品質と約束っていう話だったり、16日。
データアザプロダクトに考える谷口さんが書いてくれたものだったり、あるいは18日。
データ提供はプロダクト機能の一部であるっていうところで、村中さんが書いてくれた記事だったりっていうところで、ちょっとデータ周りの話がいくつか続いていて、すごく弊社の中でもホットな話題なので、ぜひ読んでみていただけると嬉しいなと思います。
他にはコードとか、あるいはプロダクトを分割してオーナーシップをどんどん作っていくという話がありました。
あるいはプロダクトを分割してオーナーシップをどうするかっていうところについての記事も多かったなと思っていて。
それは12月3日、石川さん、CTOのモノリス解体に向けたパッケージ構成という記事だったりですとか。
あとは12月6日、より良いオペレーションのためのプロダクトとは、宮前さん。
PMの宮前さんが書いてくれた記事だったり。
あとですね、オーナーシップだと、12月12日、鈴木さんが書いてくれたお届けとなった記事。
あとですね、オーナーシップだと、12月12日、鈴木さんが書いてくれたお届けとなった記事。
小野さんというチームでコードにオーナーシップを持つためにやってることだったり。
この辺りかなっていう感じがしますね。
もう一つのテーマが品質みたいなところで、 品質の周りのことなんですね。
プラットフォーム化の取り組み
12月5日、DevOpsのループ図考察について書いたブロッコリーさんが書いてくれたものだったり。
あとはそうですね。全部品質なんですけどね。
全ては品質に関わるんですが
カズさん 12月22日 もし過去に変えられるなら
もっと早く導入したかった開発の取り組み
この辺りはまさに品質に関わる
ダイレクトな話だかなと思っています
今日最終日は自分が書かせてもらったんですけども
プラットフォーム界の歩みっていう記事を
出させていただきました
ちょっとこれを上から解説していこうかなと思っています
初めにですね
TenXのプラットフォーム化みたいなものに対して
のろしを上げたところからスタートするんですけど
昨年の6月ですかね
Stellarはどういうプラットフォームになるのかっていう記事を
書かせて出させていただいてました
これがなんだかんだない外に対して
プラットフォームっていう言葉を
プラットフォーム プラットフォーム プラットフォームって言い始めた
一番視点だったのかなっていう感じはしてます
この記事ではですね
プラットフォームの定義をアグリゲーターとの比較の中で整理して
Stellarは明確にアグリゲーターではなく
プラットフォームを目指すんだ
あるいはプラットフォームの定義っていうのは
ユーザーに対してサードパーティーの人が
ユーザ体験をコントロールするための
ツルハシを提供する
そういうことに徹して
ユーザ体験に対して間接的に関与する
これがプラットフォームのあり方である
みたいな定義をしていきました
これに加えてですね
2022年の11月
ちょうど1年ぐらい前には
特にStellarが主戦場とするのが
巨大なエンタープライズ向けのプラットフォームなので
超巨大なエンタープライズ向けってなると
そこで特質的に求められてくる
あるいは強く求められる要求ってなんだろうとか
それを答えていくためには
プラットフォームとしてどういう方向に進むべきか
みたいな考察を書いたりしていました
というところが
昨年プラットフォームを目指したいっていう形で
のろし的に書かせていただいたもので
そこからこの1年半
ぐらいどういう歩みがあったのかなみたいなのを
振り返ったのが
僕が書いた記事になってます
その取り組んだ内容を
少しパラパラと説明できればと思っています
まず一つ目はですね
プラットフォームへの内部方針提示と開発チームの移行
プラットフォームとして
内部方針を提示するってことを
今年ですねしてきました
今年下って言っても結構中頃以降なので
割と最近っちゃ最近なんですけど
はじめはプラットフォームマニフェストとか読んでたんですが
今は指針と読んでいますと
この中ですね
えっと
特に個別性みたいなものに対して
謳ってるんですね
そのスタンスを
例えばその指針5つの項目ができていて
それを読み上げると
1機能的個別性は存在してはいけない
機能個別性とは特定のパートナーのみが
特定のサービスを実現するためだけに
開発される機能を指す
2開発される機能データは
新たな追加開発なしで
すべてのパートナーへスムーズに
横展開できるようにする
3技術的個別性
ソースコードやクエリなどの個別性は
存在しても良いが
必要十分な範囲に
最小化されなくてはいけない
4機能が活用された結果
創出された価値を
客観的に評価されなくてはいけない
価値はTenXとパートナーの双方の
需要価値の視点を統合し評価する
5ステーラー上に存在する機能は
以下の両方が満たされることを確認し
機能の場合はその機能は削除される
両方を満たすように改善しなければならない
A横展開可能な状態を満たしている
B価値を創出できる
という形で
かなり強くスタンスを取り切った
指針みたいなものを出しました
これを必要とした背景が2つあって
機能的個別性の発散が
常に続いていたんですね
これを抑えるためにも
強い制約が必要だと感じたところです
もう1つ目が
機能的個別性に頼らないで
事業をスケールするという形に
ある種我々が決めて
事業活動全体をそういう風に変えていく必要があった
という風に思っています
これは点で見るとマイナスというか
やめてよという
ところもあると思うんですね
例えばパートナーと向き合っている
特定の事業開発の人間とかからすると
そうするとパートナーの言うこと聞きづらいじゃん
みたいな
結構ネガティブなリアクションもあり得るものなんですが
ただここに対しては強く会社として俯瞰すると
スタンスを取っていかないと
すごいスケーラビリティに問題がある
という風に感じていたので
こういった方針みたいなものを示してきました
なので方針って結構分かりづらくて
どっちに進むか分かんない
みたいな結構中庸なものだったり
何て言うんですかね
賛否両論
賛否両論?違うな
何て言うんだ
両論兵器が
両論兵器されたものよりは
ネガがあってもこっちに進むんだってことを
明確に強く打ち出しているものの方が
良いかなという風に思って出しました
当然議論はあるんですよね
既存の議論の個別性もすぐ排除すべきなの
めっちゃコスト高いんだけどみたいな
なんですけど
そういうことを議論すること自体も
非常に良いと思ってますし
結論今みたいな問いに対しては
割と事業の状況だったり
コスパみたいなものと見合わせながら
どういうタイムラインで取り組んでいくかについては
ケースバイケースであるという
結論になってるんですが
こういう議論が生み出されるのも
どういう方向に進みたいか次第だと思っているので
これ自体はまずまず機能しているんじゃないかな
という風に思ってます
二つ目がですね
専門性ごとの開発チームへの移行というので
この内容については
まさに先ほどちょっと紹介した
カズさんのブログで
このブログの中で詳細に触れられているので
詳しくはそちらをぜひ読んでみてほしいんですが
今までのステーラーの事業というのは
そもそもネットスーパー事業とか
小売さんに何が必要かというのを
我々自身が見定めるのが難しいところから
スタートしているので
小売さんにしっかりくっついて
小売さんのチームに対して
プラットフォームへの移行
特定のパートナーに相対するチームに対して
開発チームを組成してアサインするという
こういう形で
パートナーの要求とすごく近しいところで
開発ニーズを汲み取って
開発していくということを進めてきたんですね
これはその当時の事業の進め方としては
あるべき状況だったと思いますし
逆コンウェイの法則としても
一定正しかったかなと思っています
ただ今年の4月にこれを大きく変えて
そうするとさっきの個別性みたいなのが
発散しまくるので
そうではなくて
専門性ごとに開発チームを組成して
パートナーの関心を専門性ごとに分離して扱うという
順序逆転を起こしました
これはある種事業の
メタ認知すると
プラットフォームを事業の主軸にして
そこに達したようなパートナーを迎えられるという
事業のパラダイムの変更でもあったかなと思っていますし
そこに向けた組織を再編成したというふうにも
言えるかなと思っています
これに踏み切った背景としても
特定の必要な機能は見えてきていて
市場揃って枯れ始めてきているところだったり
あとはより中長期的に伸びていく事業
ネットスーパー事業はそういうものなので
品質と運用をとにかく重要視してるんですよね
そうなった時にチームで担保する姿に
やっぱり変化していく必要があったなと思ってます
あとは専門性が特定のチームに閉じ込められることによって
開発の認知負荷っていうのを一気に下げられると思って
なんかこういったところを狙って
踏み切ったっていうのが背景ですね
移行してからはですね
品質への取り組み
ドメインを分割していく上で
例えばこのコードってどっちがオーナーシップを持つべきなの
みたいな議論はやっぱり曖昧なものがたくさんあって
それを一つ一つクリアにしていくっていう作業が
未だに続いてるかなと思っています
そういう意味で言うとまだ慌ただしい状況かなとは思ってるんですね
一方でこれに移行したことで
チームの専門性だったり運用の安定性だったり
何より品質に長期的に
投資していくってことはしやすくなったと思っていて
リターンは確実に得られたと思ってます
あとはこういうチームのガラガラポンというか
大きい組み替えって非常にカロリー高いと思うんですけど
特に先ほど紹介したカズさんだったり
あとはPMチームが
すごくオーナーシップを持って進めてくれたので
非常に良いプロジェクトだったなっていうふうに
振り返ると思います
次が品質のフォーカスが強く進んだっていうところで
先ほども少し話したんですが
Stellarってパートナーの事業を丸ごと預かってるので
あとは中長期でネットスーパーが成長し続けていく
そういうことに別途していますし
現にそういう事業だと思っているので
非常に高い品質が求められるなと思ってます
一方で品質って何ってところに
我々自身があまり解像度を持ってなかったっていうのが
今年のスタートだなと思っています
ここに対してやっぱり2つのアプローチで
かなり理解改善が進んだかなと思っていまして
SLO
Stellarって非常に多くのプロダクトがあって
いろんなユーザー
例えばそれはエンドユーザーもいますし
スタッフさんもいますし
本部の方もいるっていうユーザーがいると
やった時に
最も重要なユーザーストーリーを
Critical User Journeyっていうふうに定めて
これを言語化していくっていう
ユーザーストーリーを言語化していくって作業をしました
ユーザーストーリーが言語化されると
そのストーリーが満たせてるってことを表す
メトリクスが設定できるなというところで
このメトリクスが
メトリクスの設定も定めて
これをモニタリング改善するという取り組みを
内部的に始めました
かなり大きいチェンジだったので
軽直下で特別なチームを組成して
PMのえなみさんにリードしてもらいながら
これを進めてきたところがあります
この取り組みを通じて
Stellarにとって高いアップタイムとか
レスポンスのパフォーマンスを約束すべき
コアはないっていうところに
かなり深い理解が
できたかなと思ってます
これは僕自身もできたなと思ってます
あとは客観的に数字を通じて
品質の状態把握を
こういったCUJに対してはできるようになったので
これも素晴らしい進捗だったなと思ってます
これDataDockというプロダクト上に
ダッシュボードが可視化されてるんですが
これババロットさん
SREチームが数日ぐらいで
欲しいものがこんな感じですっていうので出てきて
やっぱ結構あっという間にそこから全社に展開されて
かなりびっくりしたのを覚えています
二つ目は独自の品質定義っていうのがあってですね
今年秋ぐらいに中期の経営方針っていうものを出しました
計画じゃなくて方針なんで
こういう方向に進みたいですと
その中でその経営方針を達成するには
どうしてもプロダクトの品質のギャップを
埋めていく必要があると
ギャップを客観的に洗い出そうっていうことをしたんですね
これはISO IEC2501-0に定められるんですけど
いわゆる品質の8項目っていうのがあって
それに対して僕らって今どうなんだろうっていう
言語化を進めていきました
こうしていくと我々にとっての品質上の大きいギャップ
っていうのは保守性にまずは今詰まってるなと思っていると
なんかそんな結論が出てきました
さらに保守性を深掘りしていくと
僕らにとって大事な保守性って
運営の自律性とかシステム運用効率性とか
テスト用意性とか
こういった独自のキーワードが出てきたんですよね
これは
前回の石川さんが作ってきたものです
こういった独自の品質というか
Stellaだからこそ例えば運営自律性が必要だよねみたいな
議論自体は非常に良かったなと思っていますし
今では例えば運営自律性とかシステム運用効率性みたいなものを
さらに各開発チームごとにどういう状況なんだっけって
可視化してモニタリングして改善しようっていう取り組みに
昇華されています
責任分解の切れ目
今思うと去年
プラットフォームの定義として要はプラットフォームはユーザー体験に間接的に関与する
そのためにツルハシを提供するんだっていう定義をしたと思うんですけども
この運営自律性っていうのは要はサービスを運営していくための
ツールが無事にちゃんと提供されていて我々の手を離れていて
パートナーだったりあるいは非常に少ないリソースで
我々がサポートするだけで運営が回っていく
なんかそういったものを指していてですね
なんかまさにこういうふうに言うと
これ運営自律性っていうものこそがプラットフォームたる品質を
指し示す一番わかりやすい言葉なんじゃないかなとも思いましたし
パートナーさんの事業そのものを担う
Stellarだからこそ出てくる
すごい独自性が高いキーワードでもあるなと思っています
品質って終わりに飽きたびにいいだなと思ってるんですが
品質が最重要であるというふうに宣言して
全社で取り組めてるってことは
本当に今年得た
すごい大きいものだったかなというふうに思ってますし
個人的にも結構誇りを感じる部分です
という感じでかなり品質と向き合ってきたので
例えば今品質で評価される会社って
過去どうだったんだろうっていうのを
結構調べる機会があったんですけど
自分が一番感銘を受けたのが
ファストリテイリングさんが2004年に出した
世界品質宣言っていうのがあって
すごい簡単なスライドを9枚10枚ぐらいできたものなんですけども
明らかに安かろう悪かろうみたいなユニクロから
それが世界で認知されているユニクロに変わろうってする
結構ターニングポイントになったスライドだったんじゃないかな
というふうに思っていて
しかも今のユニクロに対する自分たちの認知って
値段の割に品質が高い
というか品質は普通に高い
そういう認知をしてるかなと思って
20年近くかけて
そういったところに持ってきてるところに
すごいリスペクトも感じましたし
ある種やっぱこうやって旗が立って
初めて進める方向なんじゃないかというふうに思っていて
今では自分のバイブルかな
というふうに思っていて
思っています
最後はですね
内外の責任分解が切れ始めたというところで
ステーラーがどういう存在なのかということを
こうやって定義していったり
考えていくことによって
プラットフォーム化への挑戦
これまで我々がバックとパートナーの事業を成長するために
全てを自分たちを一回中に入れて
自分たちで何でもやってきた
その最大例がマスターデータの生成の仕組みなんですけど
パートナーさんの機関システムとかから
いろんなデータを持ってきて
我々が加工
変畳
編集
あるいはロジックを組んで
パイプラインを通してデータを編集していく中で
最終的にこう
ステーラー上
ネットスーパーに使える
マスターデータに変えていく
という取り組みをしているんですが
初めはですね
全てのデータを一旦受け入れて
我々が我々の席で
これを加工したり編集したりしていくんですけど
運用していくうちにですね
例えばその機関システムから
仕様書とは全く異なる型のデータが来てしまったとか
特定のデータカラムが全部ブランクだとか
あるいは表ズレ起こしちゃってるとか
そういう問題が起きた時も
我々がリカバリーを
我々の席ですって形でしなきゃいけないみたいな
非常に苦しい状況が過去はあったんですよね
そこからプラットフォームはどこまでやるのだとか
プラットフォームとしての責任範囲はここまでですって形に
ちゃんと区切ることによって
これはお互いちゃんと
例えば監視をしましょうとか
あるいは監視したものに対して
ちゃんと改善するとか
改善をしましょうとか
何かあったらお互いに検知責任があるとか
あるいは障害の要因が先方にあるのであれば
それは先方の中で解消してくださいとか
こういったことをより低いコストで運用できるように
そうするとお互いが健全になっていくと思うので
内外の責任分解をしっかり切り分けるようなことが
品質の重要性
進み始めたんですね
初めはどうやったら自由が立ち上がるか分かんないので
一定に我々が席を引き受けることの合理性はあったかなと思うんですが
それで
スピードを得た反面
過剰な運用コストとか
お互いの曖昧な責任とかがあったかなという風に
反省がありました
これが中長期的に改善する方向には
今迎え始められてるんじゃないかなという風に
思っています
というのが
大きく4つですかね
自分の視点で考えたプラットフォーム化に向けた
今年の歩みだったかなと思っています
というところで
そうして
2022年にプラットフォーム化していくぞ
みたいなことを言い始めて
1,2半かけて
ゆっくり進んできたわけなんですが
こういったものって
例えば
開発チームが独立して頑張ってね
というものではなくて
やっぱり前者的に取り組むことによってしか進まなかったな
というのが
今の正直な感想です
例えば品質改善するには
ソースコード自体が変わるということも大事なんだけど
やっぱりパートナーとの初めの期待調整とか
契約書のあり方とか
ありとあらゆるものを通じて品質ってできているので
あるいはそういうことを品質でそうやってできているんだって認知を
今年やっぱり自分としてもチームとしても蓄えてきたなと思っているので
誰か一人とかどっかのチームの努力に頼るんじゃなくて
経営として意思決定してベクトルを作って
痛みともないながら
その方向に向かっていけるなっていう
類のものだったなというふうに思っています
先ほどの事業の性質上も
ステーラーというプラットフォームにとっては
パートナーとの長期的な成長が必要重要だし
その最重要のドライバーは
やっぱり今は品質だなというふうに思うんです
当然品質の中には機能適合性と言われるような
彼らが事業を運営する上で
十分な機能が提供できているかという観点もあるので
品質って全てを指すんですが
その中でも我々にとって
例えばQCDと言われるような
クオリティコストデリバリーってあるんですが
特に重要なのはやっぱり品質だなというふうに今思っています
こういった取り組みの先に
昨年の11月に掲げたような
エンプラ向けのプラットフォームには
こういう要求が必要だよねっていう
5つの要点があるんですけども
その5つの要点も満たせるようになるんじゃないかなと思っています
その当時書いたものですね
1は高いアップタイム
2 強いセキュリティ
3 カスタマイズの重要性
4 連携の容易性
5 ベンダのロックアウトっていう
この5つを書いたんですけど
こういった方向に
実際我々の今年の取り組みは
そんなにみんなが意識してたわけではないんですけど
確実に進んでるなというふうに思っているので
改めてプラットフォーム
プロダクトカンパニーとして
これをしっかり突き詰めてやっていきたいなっていうのが
来年以降の抱負かなと思っています
はい ということで
これをもって
TENXのプロダクトのアドベントカレンダーの
締めともさせていただければなと思っていますので
記事の方もぜひ読んでいただければなと思っています
はい じゃあ
ということで
今年もゼロトピックありがとうございました
来年もよろしくお願いします
