「我々はどこに向かっているのか」を問い続けるための仕組みづくり / Establishing a System for Continuous Inquiry about where we are

by daitasu

Embed

Start on current slide

Slide 1

Slide 1 text

千株式会社 2024.07.23 SEN Developer Meetsup @daitasu 「我々はどこに向かっているのか」を問い続けるための仕組みづくり〜新設チーム発足からチームとプロダクト指針が見えてくるまでの 3ヶ月〜

Slide 2

Slide 2 text

Slide 3

Slide 3 text

今日話したいこと

Slide 4

Slide 4 text

主語を意識して「我々はどこに向かっているのか」を問う仕組みを作ろう

Slide 5

Slide 5 text

「我々」is … ？

Slide 6

Slide 6 text

(理想) それぞれの「我々」の主語は違えど、会社として向かうベクトルは線形上になるはず組織には様々な「我々」がある組織がどこに向かっているのか「我々」= 会社「我々」= 各事業「我々」= プロダクト「我々」= チーム, etc…

Slide 7

Slide 7 text

Slide 8

Slide 8 text

今日のお題主語を意識して「我々はどこにいるのか (Asis)/どこに向かうのか？ (toBe)」を問う仕組みを作ろう

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

はいチーズ！フォトについてインターネット写真販売サービス「はいチーズ！フォト」の大きな区分カメラマン撮影プラン (直販) 先生プラン撮影事業者(写真館) プラン自社のカメラマンが園のイベントで撮影保育園の先生が撮影撮影事業者が園のイベントで撮影はいチーズ！フォトにアップロードはいチーズ！フォトにアップロードはいチーズ！フォトにアップロード保護者が EC上で購入印刷・配送・etc…

Slide 12

Slide 12 text

はいチーズ！フォトについてインターネット写真販売サービス「はいチーズ！フォト」の大きな区分撮影事業者(写真館) プラン撮影事業者が園のイベントで撮影はいチーズ！フォトにアップロード保護者が EC上で購入印刷・配送・etc… 本日の話はここ

Slide 13

Slide 13 text

チーム状況 - 写真館向けサービスはあるが、専任チームが不在でシステムはほぼ踏み込めない状態だった - 今年、自分を含めEM/PdMが入ったことで、写真館向けの専任チームが発足 ~2024/4 MGR 1名 2チーム 15名程度 toB 領域のサプライチェーン全体を担う MGR 1名 PdM 1名 EM 1名撮影事業者向けシステムサプライチェーン前半運用・問い合わせサプライチェーン後半 2024/5~

Slide 14

Slide 14 text

© SEN CORPORATION 組織的な課題 ● 向き合うのは事業として非常にインパクトが高い領域 ● セールスや社内オペレーションが洗練されている一方で、プロダクト・システムとしての専任者はいないままに進んできている ● ビジネス↔プロダクトの連携指針が模索段階にあり、プロダクト開発の進め方として明確になっていない部分が多い ● システムの煩雑化、プロダクト方向性のための意思決定材料が圧倒的に足りていない状態

Slide 15

Slide 15 text

システム的な話 - 管理画面の種別が多く、種別ごとにレガシーなシステムから脱却している途中 - 写真館向けシステムはまだレガシーシステムに内包されており、様々なロジックと共存状態旧メインシステム保護者向け機能先生向け機能印刷会社向け機能写真館向け機能 etc… 新メイン API 各種ユーザ向けの基軸となる新API郡 (切り出し済) 先生向け管理画面 (切り出し済) 社内管理画面 (切り出し済) カメラマン管理画面 APIは順次 core 移行または各種システムごとに切り出す etc… 【TARGET】写真館向け管理画面 ethnam

Slide 16

Slide 16 text

PJTステータス - 新設チーム立ち上げに向け、JOIN時点は全員違うPJTに向き合っていた - 新設チーム最初のPJTは、管理画面のリプレイス After Before

Slide 17

Slide 17 text

© SEN CORPORATION JOIN時のつまづき ● 20年近く続く事業のシステムでステークホルダーが非常に広い ● 事業フェーズの転換期 ○ プロダクト初期はとにかくユーザ数を増やすことや売上を取ることが重要 ○ 今後は、プロダクトとしての中長期の方向性、プロダクトビジョンが求められていく ■ 特定ユーザのみに提供されている機能、ユーザ・社内オペレーションの特殊な運用ケースが多い ■ 可視化と精査、全体の認識を揃えないといけない ● プレイングマネージャーという役割上、腰を据えてキャッチアップともいかず、決めつつ進まないと間に合わない

Slide 18

Slide 18 text

Slide 19

Slide 19 text

まず何からすればいいのだろう、、、

Slide 20

Slide 20 text

書籍「プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける」より - プロジェクトを開始するときは、まず自分たちが何を知っているのかを明らかにします - その状況において真であること、つまり既知の知識から始めるのです Known Knowns (知っていると知っていること ) 事象として認識し、理解できていること Unknown Knowns (知っていると知らないこと ) 認知はできているが、事象の根拠がないこと Known Unknowns (知らないと知っていること ) 事象は認識しているが、理解できてないこと Unknown Unknowns (知らないことを知らないこと ) 事象もなく、認知もできていないこと事象として既知である未知である認知として既知である未知である知っていることを知っていかねばならない

Slide 21

Slide 21 text

© SEN CORPORATION 見えてきた、知らねばならないこと - 「私」はどこに向かえばいいのか？ - 私に対する期待の方向性はどこなのか - 「チーム」は何を成し遂げればいいのか？ - 目下のプロジェクトは、どこに向かっていくためのものなのか - 「プロダクト」はどんな世界を目指しているのか？ - 何をもって、機能の是非を考えねばならないのか - 「ユーザ」はどんな未来を描いていくのか？ - 解決したい世界線は、ユーザが描く世界線に向かっているのか我々はいまどこに？我々はどこへと向かう？

Slide 22

Slide 22 text

Slide 23

Slide 23 text

最初の「我々」 is …

Slide 24

Slide 24 text

自分

Slide 25

Slide 25 text

自分はどこに向かうべきなのか？をすり合わせる - 上長やチームメンバー、ビジネス側の望む期待値、意思決定の範囲を模索する - 愚直に色々見ていくやったこと上司/事業サイドとの週次1on1 メンバー初回1on1 - チーム課題や組織課題の掘り下げ - 変えたいこと、変えたくないことの認識合わせ営業資料/サポート向けマニュアルを漁る関係者のSlack ストーキング - プロダクト視点の仕様書はないので、見えるものから探していく - 過去の会話は有益な情報が多い

Slide 26

Slide 26 text

次の「我々」 is …

Slide 27

Slide 27 text

チーム

Slide 28

Slide 28 text

やったこと :チームガイドラインの作成 - チームの指針の再定義 - MTGの刷新、チームポリシーやコーディングガイドラインの定義チームのREADME Working Agreement - 「見ればJOINできる」の書 - チームの関連リンク・オンボーディング情報等 - 「チームの認識ズレをなくす」ための書 - チームの基本ルール、会議体や StoryPoint の定義など

Slide 29

Slide 29 text

やったこと :Scrum の導入 - 開発タスク管理をBacklog から Github Project へ - Iteration 制を導入し、Sprint Goal を決めてサイクルを回す to Github に移行して区別する - 事業サイドからの要望(Backlog) - 検討後にHowから決めるもの - 開発タスク(Github) - 実施するもの

Slide 30

Slide 30 text

やったこと : 振り返り/ Plannning の再定義 - 振り返り：文章を書くよりも議論の時間を優先したく、付箋で議論 - Plannning：作業日数から1日あたりに消化可能なポイントを算出振り返り - 文章でなく、要素で書く - 「気になる🌴」が多いものを議論 Plannning

Slide 31

Slide 31 text

やったこと : ADR(Architecture Decision Record) - チームの技術リードエンジニアに牽引頂き作成 - 技術の意思決定における課題、トレードオフや決定までの背景をまとめる

Slide 32

Slide 32 text

やったこと : monorepo 構成の決定 - ユーザ種別が多く、会社全体でのリポジトリ数が膨大 - 自分たちのスコープのシステムは1つに集約したく、monorepo を採用 . ├── Makefile ├── README.md ├── apps/ │ ├── {BFF} │ └── {Frontend} ├── services/ │ └── {Backend} ├── docker/ ├── openapi/ │ └── swagger.yaml ├── package.json ├── packages/ │ └── app-commons/ ├── pnpm-lock.yaml └── pnpm-workspace.yaml

Slide 33

Slide 33 text

● チームとしての定量的な計測ができるようになってきた ● システムを切り出したことで他チームへの依存なく進めやすい ● 新メンバーのオンボーディング基盤が整った ● 抜本的なシステム改善のためには DB改善が必須 ● そこに触れるには、全システムと連携しないといけない ● リプレイスは情報設計のみの改善で、BFF層でよしなに整形

Slide 34

Slide 34 text

次の「我々」 is …

Slide 35

Slide 35 text

プロダクト

Slide 36

Slide 36 text

やったこと：ユーザ要求仕様書のフォーマット作成 - 事業サイドからの仕様確認依頼をなくしたい - ユーザ目線のマスタとなる仕様書を組み、CS/マーケ/ビジネス/プロダクト間の認識誤差を防ぐ社内横断のデザイナーレビューやQAチーム、ビジネス連携に役立っている

Slide 37

Slide 37 text

やったこと：事業サイドからの Issue 方針改善 - システム側への依頼・相談・質問はすべて区別せずに投げていた - 粒度がバラバラで、対応判断をすべて開発チームが持つ負担が大きかった相談・質問改善要望不具合報告ビジネスマーケサポート社内オペ開発チームで判断不具合報告相談・質問改善要望即時対応 Product Backlog を作成 MGR/TLでフィルタリング After Before

Slide 38

Slide 38 text

やったこと： Product Backlog 作成 - Product Backlog の中で、Issue をWhy/What から事業サイドと認識を揃える - ビジネス優先度とシステムリプレイスを対比して対応判断

Slide 39

Slide 39 text

やったこと：事業サイドとの会議体整理 - 週次の定例をSprint Review とプロダクトバックログ会議で分離 - 現在の話と未来の話でMTGを分け、アジェンダの粒度を統一する (週次) 開発 ↔ 事業サイド定例 (隔週) Sprint Review (隔週) Product Backlog会議 - 未来のことに関する場 - 事前に事業部でフィルタリングしたIssueを上げる - 課題のWhat/Whyを掘り下げ、開発の有無を判断 - 現在のことに関する場 - Sprint の成果物を事業サイドに見せる - フィードバックを受け取る場所 - 議論の粒度、タイムラインがバラバラ - 実施する内容なのか、未定の内容なのかでメンバーに混乱が起きやすい

Slide 40

Slide 40 text

やったこと：イベントストーミング - (ビッグピクチャー) 事業サイドに見えている業務フローを可視化して時系列に並べる - 潜在的に属人化しているオペレーションの発見、開発↔事業の言語の誤差を揃える契約〜売上までの全体像を掘り起こし開発の知らないドメイン知識が顕在化する社内フローは洗練されているものの、ユーザ側の業務フロー理解がもっと必要

Slide 41

Slide 41 text

● プロダクト↔ビジネスでの連携基盤が整った ● 「本当にやるべきなのか？」を精査して議論する場ができた ● 「何を目指すのか？」をプロダクト ↔ビジネスで同じ向きで走れる ● あくまで基盤ができただけ(失敗談はこれから) ● プロダクト課題はまだほとんど潜在化している ● ユーザの業務理解が情報として全然足りていない

Slide 42

Slide 42 text

Slide 43

Slide 43 text

Slide 44

Slide 44 text

開発も現場に足を運ぼうユーザの生の業務を見よう

Slide 45

Slide 45 text

「我々はどこに向かっているのか？」は鮮度がある - 市場ニーズの変化、投資状況、競合他社の動向など様々な要因で変化していく - 「問い続けて見直す」ための仕組みづくりが必要現状理解「我々はいまどこにいるのか？」指針の決定「我々はどこに向かっているのか？」仮説検証「我々の向かう先は正しいのか？」発見と見直し「我々は間違っていたかもしれない」

Slide 46

Slide 46 text

- 知っていることは増やすが、「誰の」を意識しないとずれが生じる - 新設チームはやることがいっぱい。しかし、施策は「相手」を考えながら作っていこう主語を意識しつつ分かっていることを増やしていく Known Knowns (知っていると知っていること ) 事象として認識し、理解できていること Unknown Knowns (知っていると知らないこと ) 認知はできているが、事象の根拠がないこと Known Unknowns (知らないと知っていること ) 事象は認識しているが、理解できてないこと Unknown Unknowns (知らないことを知らないこと ) 事象もなく、認知もできていないこと事象として既知である未知である認知として既知である未知である「チーム」の話？「プロダクト」の話？「ユーザ」の話？「市場」の話？

Slide 47

Slide 47 text

Slide 48

Slide 48 text

主語を意識して「我々はどこに向かっているのか」を問う仕組みを作ろう