品質と約束、そして夫婦の家事分担の話
この記事は10Xアドベントカレンダー2023の14日目の記事になります。
昨日は@sota1235さんが、GitHubの監査ログを定期的にexportして保存するという記事を公開しています。
ちなみに去年も同じ順番でパスを受け取っています、バスケネタだけに。
Stailerにおけるネットスーパー・ドラッグストアの売り場生成では、「いつ・どの店舗で・どの商品が・何個・いくらの金額で売っているか」のようなマスターデータを作るロジックを独自開発している、という特徴があります。
StailerのLPにおいても、提供機能であるお客様アプリ・スタッフアプリ・管理画面と並ぶ形で、商品マスタが紹介されています。
2023年10月、これらの機能開発を担当するチーム、つまり僕たちが所属していた組織について、実は大きな変化がありました。
この出来事が、改めてマスターデータ・売り場生成というプロダクト品質について考えるきっかけとなり、更には夫婦の健全な家事分担にも繋がる話だと思ったので、今回はそれについて書こうと思います。
組織変更があった
これまでも何度か言及してきましたが、先述のような売り場生成に向けたマスターデータ作成機能について、僕たちは「データプロダクト」と呼称し、かつそれをグロース本部に所属する形で扱ってきました。
なぜならば、用いられる仕組みやスキルセットなどが、社内分析用のデータマート作成に出自を持つためです。
マスタデータ作成のような業務も、元々は社内分析用のデータマート整備に専門性が由来している。 StailerがWhole Productとして成長する中で、最初はエンジニアの方々が実装していたマスタデータ生成プロセスにつき、事業機会拡大に伴う工数増加を解決するため、データ人材である僕たちがこのイシューを受け持ったのだ。
当時のグロース本部には、データアナリスト・アナリティクスエンジニア・マーケター・・・などなど、多様なスペシャリストが所属しており、データやファクトという共通の武器を持ってして、事業に伴走していました。
しかし嬉しいことに、「データプロダクト」の存在感・責任感がどんどん増していき、売り場生成における重要な役割を占めるようになって、事業伴走もさることながらプロダクト・プラットフォームとしての特性が強まり、より一層の安定した品質が求められるようになりました。
プロダクトで使われるマスタデータ生成において、個人的に感じる一番の違いとしては、品質に対する責任感だと思います。 例えば、社内の可視化用途で用いられるデータマートであれば、細かい数字の揺らぎやログの欠損は怖いものの、その修正が1分1秒を争うような事態はあまり発生しにくいです。 一方で、マスタデータはパートナー小売企業が商いをする・エンドユーザーが買い物をするプロダクトに直接的に結びついていることから、万が一障害が起きるとその影響が瞬時に広がってしまい、はじめはビクビクしていました。
とはいえ、品質の高い売り場を作ろうと思ったときに、あくまでデータの中身のみを成果物とする僕たちの力だけでは、必ずしもこれを達成し得ないという問題がありました。
具体的には、パートナー小売企業から生データを受領する仕組みだったり、加工されたデータを最終的にアプリケーションに取り込む仕組みについては、ずっとソフトウェアエンジニアが担当していました。
そのため、グロース本部とエンジニアリング本部という、元来担当領域が異なる組織間でオーナーシップを発揮しながら、雰囲気で共同管理している状態であり、もちろん随時協業しつつも、互いの専門性へのリスペクトもあって近いが遠いような、微妙な距離感が詰め切れずにいました。
旧組織体制では・・・
- グロース本部
- データプロダクト部: データの中身、ひいてはその加工ロジックを作る
- データプロダクトマネージャー
- データプロダクトエンジニア
- データサイエンス&エンジニアリング部: あまりデータプロダクト領域はやらない
- (アナリティクスエンジニア)
- (データサイエンティスト)
↑↑ お互いのリスペクトと、中々詰め切れない距離感 ↓↓
- エンジニアリング本部
- アプリケーション開発部
- ソフトウェアエンジニア: データを取り込む仕組みを作る
したがって、より品質の高い売り場ひいてはプロダクトを作るための第一歩として、それに取り組む組織へテコ入れをする必要がありました。
結論、僕たちは慣れ親しんだグロース本部を離れ、データプロダクトを扱うメンバーはエンジニアリング本部とプロダクト本部へ異動、さらにソフトウェアエンジニア・SET・プロダクトマネージャーも招聘した上で、「マスターデータ」という新しい開発チームを組成する形となりました。
さらに同じタイミングで、同様にグロース本部に所属していたアナリティクスエンジニアなど一部職種についても、データプロダクトと選定技術や専門性を集約する目的から、エンジニアリング本部に異動となりました。
新しい組織体制だと・・・
- プロダクト本部
- プロダクトマネジメント部
- プロダクトマネージャー[New]
- データプロダクト部
- データプロダクトマネージャー[ex-グロース本部]
- エンジニアリング本部
- データサイエンス&エンジニアリング部
- データプロダクトエンジニア[ex-グロース本部]
- (アナリティクスエンジニア: 引き続きマスターデータ領域はやらない)
- (データサイエンティスト: 引き続きマスターデータ領域はやらない)
- アプリケーション開発部
- ソフトウェアエンジニア
- SET[New]
→全員が「マスターデータ」という開発チームでひとつに！！
これにより、Stailerにおける売り場生成のための商品・在庫といったマスターデータ生成パイプライン構築業務につき、As One Teamに一気通貫して担えるようになりました。
以下は、新体制における各職種の主な担当領域・データパイプラインの流れを示しています。
また、最新の10X プロダクト本部・エンジニアリング本部 紹介資料にも、プロダクト本部・エンジニアリング本部配下の各組織からアサインされる形で、マスターデータチームが組成される体制図が描かれています。
品質とは約束によるものではないか
繰り返しますが、今回の組織変更の目的は「品質が高いマスターデータ・プロダクト・売り場を作ること」です。
しかしながら、元々分かれて活動していたスペシャリストを一つのチームにしたり、異なる思想で組み上げたアーキテクチャを近づけただけでは、もちろん初めから上手く行くはずがありません。
では果たして、品質が高い、という状態は何を持ってして判断することができるのでしょうか。
極端に言えば、出自の違うものが寄せ集められた状態だったとしても、何かしらの判断軸さえあれば、概ね共通したゴールに向かって突き進むことができるはずです。
そもそも品質とは、言葉としての定義が広い割には、非常にカジュアルに使われてしまいがちな言葉でもあります。
ある時は個人から見た主観的な水準だったり、ある時は他の何かと比べて相対的に決まるものかもしれません。
そこで僕たちは、品質とは他者へ交わしている約束であり、品質が高い状態とはその約束を守っている状態である、と解釈した上で、その約束の定義に向けた対話を重ねてきました。
具体的に考えたことと進め方の順番は、以下の通りです。
- 改めて自分たちの作る・抱えている現状の「成果物・仕事」を明らかにする
- 現状の「成果物・仕事」を再整理して、「本当に作るべきもの・やるべきこと」にフォーカスする
- 「本当に作るべきもの・やるべきこと」に対して、ステークホルダーに求められている「約束」を明らかにする
- 「約束」が満たされていることイコール「品質」と定義する
これにより、新設される「マスターデータ」という開発チームの担当領域においても、引き継がれるであろう旧組織に由来するステークホルダーや成果物などを再確認していきました。
またその過程でも、特に自分たちの担う領域の境界線の外側には誰がいるか？どんな基準を求められているのか？守れなかったリカバリは何か？などなど、発展して考えることも多く出てきました。
仮に組織変更が無かったとしても、組織を長らく固定化して運営していたならば、その中で業務が暗黙的に最適化されてしまったり、いつの日か洗い出しや再設計が必要になるタイミングは来ていたのかもしれません。
ちなみにデータアナリスト出自の自分にとっては、品質については全くの初心者だったので、せめて議論に付いて行くため社内でオススメされた以下の書籍を参考にしました。
夫婦の家事分担で考えてみる
いきなり突然ですが、素人ながらの感想として、
- かつて出自の異なるもの同士が、あることを境にひとつのチームになること
- 特定のステークホルダーがいる中で、一定の品質や約束を満たす必要があること
- 長らく運用を続けていくと、業務が暗黙的に最適化されてしまう恐れがあること
これらについては、夫婦で共同生活を送ることにとても良く似ているなぁ、と思いました。
夫婦でよくある？のが「私 or 俺ばっかり家事してるんだけど！！！」ではないでしょうか。
初めから一方のやる気が無いのであれば救いようがありませんが、お互いに一定コミットしている意識があるにも関わらず、このような喧嘩になってしまうのは、何とも悲しいことです。
では、このような喧嘩がなぜ発生してしまうのかと言うと、たとえば以下のような原因が推測されます。
- 家庭で必要とされている家事の総量の認識齟齬がある。その結果、一方がもう一方の認識外に溢れている or 必要無しと判断している家事を担っている。
- とある家事について、一方が担っている事自体、もう一方が認知していない。その結果、負担がかかっている事自体に気付くきっかけがない。
- 互いに認識できている家事について、基準・タイミング・依存関係などの前提にギャップが有る。その結果、役割上一方が担っていたとしても、もう一方が先回りなどカバーせざるを得ない。
他にもあるかもですが、まあ大体こんなところでしょう。
そこで、先述したような組織変更だったり、品質の基準になる約束を考えるプロセスについて、とある北海道に暮らす夫婦の家事分担を例にとって考えてみたいと思います。
各ステップの画像が見づらい場合、以下にwhimsicalでも公開していますので、必要に応じてぜひご参照ください。
1. 全員がやっていることを洗い出す
まず初めにやることは、なるべく夫婦各々の目線に立った上で、やっている家事を全て書き出すことです。
付箋をペタペタ貼っていったり、whimsicalで同期的に書き出すなどして、思いついたものからどんどん文字に起こしていきます。
粗々で始めてもぜんぜんOKでしょう。
その後、なんとなく近い家事をまとまりにしていったり、左から右に順番が流れるように整理していきます。
ここまで書けば、イベントストーミング・ユーザーストーリーマッピング的な考え方で、家庭内で行っている家事の全体感が明らかになったり、後続プロセスで問題特定やアクション策定がしやすくなります。
2. 依存関係と担当者を可視化する
次はそれぞれの順番や依存関係を明らかにするため、書き出した家事同士で矢印を引いていきます。
併せてこのタイミングで、家事の優先順位付けについてもお互い目線を合わせておくと、以降の議論がスムーズです。
それにより、どの家事が下流のブロッカーになる可能性があるのか、未達成によるネガティブインパクトが大きいのか、などを明らかにすることができます。
例えば、ある夫婦の依存関係だと・・・
- 夫はジムに行くついでにマックスバリュに行っている、かつこれは週末午前中である
- 妻はオフィスに行くのでおしゃれ着が多くなる、なので妻自身のタイミングで洗濯したほうが良い、一方で部屋着は適当でも良い
- タオルの交換から洗濯については、プロセスが循環している
例えば、ある夫婦の優先順位付けだと・・・
- 昼食は適当でOK、夕食はできるだけ一緒に食べたい
- マックスバリュよりもコープのほうが生鮮食品が美味しいので、なるべくコープで買い物をしたい
- 掃除グッズは外に買いに行くのが面倒くさい、なので宅配・トドックで届くと便利
また、家事ごとに夫と妻、現状どちらが担当しているのかも可視化します。
一方的に負担が寄っていたり、あるいはもう一方がそれを認識していない、みたいなイシューがあること自体はぜんぜんOKです。
まずはお互いにGAPがあるという認識を揃えることで、以下のような痴話喧嘩も防ぐことにも繋がります。
例えば、ある夫婦の会話にて・・・
夫「シンク汚れてるね（単純に感想言っただけ）」
妻「はぁ？気付いたならやってよ！？（掃除しろって命令されたと思った）」
本事象については、実は妻が影でシンク掃除をしていたことを、夫は気づいていなかったのが根本原因なのかもしれません。
3. 抽象化して問題点を挙げる
さて、これで夫婦で担う家事の全体像や業務フローが徐々に明らかになってきました。
しかしこのままだと、扱う粒度が非常に細かくなってしまい、問題点の特定や解決に向けた議論がしづらくなってしまいます。
よって、それぞれをジャンルごとにまとめるなどして、一段上へ抽象化することを試みます。
家事の場合はわかりやすく、掃除・洗濯・料理など、大枠が掴める適切な粒度・数量の塊に落とし込んでみました。
抽象化の後に、今度は各塊に対してよりクリティカルな問題点を洗い出していきます。
夫婦どちらか一方に寄ってしまっているもの、ボールが落ちてるもの、制御不能な制約条件があるもの、などなど。
例えば、ある夫婦の問題点だと・・・
- オフィスで仕事だと、どうしても家事をする時間やタイミングに制約を受けてしまう
- トドックは品揃えが限定されるため、マックスバリュ or コープでの買い物が不可欠となる
- 夫は美しく衣服を畳むことが大の苦手であり、その作業は妻が担うのが最も効率的かつ高水準である
- バスタオルは毎日交換する前提の場合、枚数的にも最大3日に1回は洗濯する必要がある
- シンク掃除は担当・タイミングなどが明確に決まっていないものの、妻の方が衛生感度が高い
もっと言うと、そもそもボランティア的にやっていた家事について、役割分担が明確でないにも関わらず一方が期待してしまっていた場合には、後続プロセスで再度約束を引き直す必要が出てきます。
上記の場合、てっきり夫は妻がシンク掃除を担当していると思っていましたが、妻はあくまで衛生感度からアクションを起こしたに過ぎなかったり、なんだかすれ違いがあった模様です。
このように、予め根本となる原因をどれだけ具体的に深堀れているかが、最終的な品質基準を大きく上下することにも繋がります。
4. 求められる約束を言語化する
最後は挙がった問題点を踏まえた上で、それを生じさせないためのアプローチ・約束の言語化をします。
ここで注意すべきは、本当に守るべき約束の範囲や目標をきちんと見定めることです。
どういうことかと言うと、何か下流に位置する家事を担当する場合には、その上流の保証内容を考慮した上で、下流の約束を決める必要があります。
仮に、上流の家事が50%の確率でしか達成されない場合、下流の家事が50%以上の達成を担保することは、直感的にもかなり厳しいことが分かるでしょう。
言い換えると、根本的に達成し得ないような約束はすべきではありません。
その場合、完全達成を目指す約束をガチガチに引いてしまうのではなく、大まかに良くする方針を握るだけに留めることで、お互いを満足させる方法もあります。
洗濯については、おしゃれ着を乾燥にかけたりしなければ、ふんわりとやり方やタイミングが決まっていれば良い、といったように。
また、守ることになる約束と目標は可能な限り定量指標だと、お互いの認識齟齬も起きづらいです。
特に家事の場合では、週に何回・何曜日・何時など、タイミングや時間的な定量目標が敷かれることが想定されます。
例えば、ある夫婦で決めた約束だと・・・
- 夫は週に1回はジムに行き、マックスバリュで標準的な食材を買うこと
- 夫婦一緒に週に1回はコープに行き、美味しい生鮮食品を買うこと
- 夫は妻の帰宅前までに洗濯乾燥を終わらせ、その後に妻は衣類を畳む作業を担うこと
- 妻は月に1回程度、気になったときで構わないのでシンク掃除を担うこと
以上で策定・合意した、約束が満たされている状態を品質が守られている状態、と定義することになります。
結局シンク掃除は妻が担当することになりましたが、当事者同士さえ良ければ、着地としてはそれでも構いません。
約束している内容をお互いに認識し合うことが目的であって、無理矢理平等にする・押し付けるのは目的ではありません。
ちなみにですが、何か提供サービスなどの場合において、守られるべき基準に関する合意をSLA（Service Level Agreement）、これを外部に対して守るための内部的かつ一層厳しい目標をSLO（Service Level Objectives）、それらの達成状況を測定するための指標をSLI（Service Level Indicators）と呼ぶらしいです。
さらに蛇足ですが、データパイプラインの構築や運用などは動作要素も多かったり、複数のコンポーネントの分業や掛け合わせも不可欠なため、これらの定義が相当困難だったりするようです。
確かに、今回の組織変更によって多様なスペシャリストが合流する形となったように、カバーする業務範囲やステークホルダーが多岐に渡る「マスターデータ」の難易度として、とても納得感があります。
5. 約束自体が変わることも考えておく
一度定義された約束ですが、これは時間の経過とともに変わり得るものでもある、という認識を持つことも非常に大切です。
仕事、健康、引越、出産育児などなど、人生にはライフイベントが沢山存在し、家庭生活の根底も変化していく以上、その上に載る家事についても都度考え直す必要があります。
恐らくプロダクトについても同様で、例えば一定の閾値を設けてエラー判定・アラートを出す仕組みなどについては、事業規模が成長していくにつれて、その閾値や仕組み自体も変わっていくことが想定されるでしょう。
例えば、ある夫婦であり得る変化としては・・・
- 子どもが生まれたら、現状週2回で済ませている掃除機が毎日必要になるかもしれない
- 転職で二人ともオフィス出社が必要になったり、一方が長期間離職するかもしれない
- あまりにも色々が忙しくなってきて、コープに行けるのが月に1回になってしまうかもしれない
- ゴミ収集の曜日が変更になって、掃除を前倒して済ませる必要が出てくるかもしれない
あるいは、そもそも自分たちで家事全てをこなそうとするのではなく、他者に代行してもらうこと・思い切って捨てることも選択肢になるかもしれません。
変化がどんどん大きくなるに連れて、今まで通りの水準も継続して期待されたり、より高く設定され直してしまうと、トレードオフとして新しい事ができなくなってしまいます。
そのため、自動化・委譲・削減の余地がないか、時間創出に向けた探索も併せて行っていきます。
例えば、ある夫婦の時間創出に向けた取り組みとしては・・・
- 自動化のために、食器洗浄機を投資判断するかもしれない
- 委譲のために、家事代行サービスへ特定の家事を発注するかもしれない
- 削減のために、衣類を畳む家事自体を諦めても良いかもしれない
結びに
今回は夫婦の家事分担を例にとって考えましたが、これを仕事や組織に当てはめると、周辺には他にも色々な事柄があるはずです。
半期のチーム・個人の目標とアラインする形でインセンティブ設計できているか、会社や事業の状況を踏まえた上で適切な投資判断ができているか、などなど。
結局のところ、なぜ・何を・誰が・どこに・いつ・どれだけ投資するかの意思決定が、回り回ってプロダクトの品質自体も大きく左右するのだろうと、まさに新体制で動きながらも僕自身肌で感じています。
加えて、品質への投資はわかりやすく見えるものではなく、実際に問題が起きるまで課題だと気づかないことも多いです。
特にマイナスをゼロにするような営みの場合、評価されにくかったり、モチベーションが続かないこともあり得るかと思います。
そのため、約束はドキュメントなどに言語化・明文化したり、価値貢献が日々レポーティングされる形式を意識したり、遵守を当たり前と思わないことや感謝をきちんと口にすることが大切なのかもしれません。
つまり、何が言いたいか。
「愛する妻へ、いつもありがとう」
さて、そんな妻への愛が溢れる僕が所属するマスターデータチームに限定されず、10Xでは現在データ基盤やデータプロダクトを一緒に作っていくエンジニアを正社員・業務委託ともに募集しています！
明日はSREのKuriharaさんが記事を公開する予定です、お楽しみに！