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

2024.7.23 SEN Developer Meetsup での登壇資料です。

https://sencorp.connpass.com/event/320573/

「我々はどこに向かっているのか」を問い続けるための仕組みづくり ~新設チーム発足からチームとプロダクト指針が見えてくるまでの3ヶ月~

Transcript

1. 千株式会社 2024.07.23 SEN Developer Meetsup @daitasu 「我々はどこに向かっているのか」 を問い続けるための仕組みづくり 〜新設チーム発足からチームとプロダクト指針が見えてくるまでの 3ヶ月〜
2. © SEN CORPORATION 名前： • 藤井 大祐 お仕事： • 千株式会社 ものづくり部 (2024/4/15 入社) ◦ ちょうど3ヶ月経ちました • フロントエンドが好きですが、最近はバックエンドや らインフラやら勉強してます • 現職ではEMやPdMの役割も持ちつつ開発実装をし てます • 恐竜が好き 自己紹介 @daitasu
3. 今日話したいこと
4. 主語を意識して 「我々はどこに向かっているのか」 を問う仕組みを作ろう
5. 「我々」is … ？
6. (理想) それぞれの「我々」の主語は違えど、会社として向かうベクトルは線形上になるはず 組織には様々な「我々」がある 組織がどこに 向かっているのか 「我々」= 会社 「我々」= 各事業 「我々」= プロダクト 「我々」= チーム, etc…
7. © SEN CORPORATION 問い • いま話している「我々」の主語 は揃っていますか？ ◦ 会社？プロダクト？部署？チーム？私？ • その「我々」全員の向かう先は揃っていますか？ • 向かう先は、会社や組織として向かう先へと繋がっていますか？
8. 今日のお題 主語を意識して 「我々はどこにいるのか (Asis)/どこに向かうのか？ (toBe)」 を問う仕組みを作ろう
9. © SEN CORPORATION 1. 事業の紹介と JOIN時の状態 2. 「我々はいまどこに」を観測する 3. 「我々はどこに向かっているのか？」に 向けて 目次
10. © SEN CORPORATION 1. 事業の紹介と JOIN時の状態 2. 「我々はいまどこに」を観測する 3. 「我々はどこに向かっているのか？」に 向けて 目次
11. はいチーズ！フォトについて インターネット写真販売サービス「はいチーズ！フォト」の大きな区分 カメラマン撮影プラン (直販) 先生プラン 撮影事業者(写真館) プラン 自社のカメラマンが 園のイベントで撮影 保育園の先生が 撮影 撮影事業者が 園のイベントで撮影 はいチーズ！フォト にアップロード はいチーズ！フォト にアップロード はいチーズ！フォト にアップロード 保護者が EC上で購入 印刷・配送・etc…
12. はいチーズ！フォトについて インターネット写真販売サービス「はいチーズ！フォト」の大きな区分 撮影事業者(写真館) プラン 撮影事業者が 園のイベントで撮影 はいチーズ！フォト にアップロード 保護者が EC上で購入 印刷・配送・etc… 本日の話はここ
13. チーム状況 - 写真館向けサービスはあるが、専任チームが不在でシステムはほぼ踏み込めない状態だった - 今年、自分を含めEM/PdMが入ったことで、写真館向けの専任チーム が発足 ~2024/4 MGR 1名 2チーム 15名程度 toB 領域のサプライチェーン全 体を担う MGR 1名 PdM 1名 EM 1名 撮影事業者向け システム サプライチェーン前半 運用・問い合わせ サプライチェーン後半 2024/5~
14. © SEN CORPORATION 組織的な課題 • 向き合うのは事業として非常にインパクトが高い領域 • セールスや社内オペレーションが洗練されている一方で、プロダクト・システムとし ての専任者はいないままに進んできている • ビジネス↔プロダクトの連携指針が模索段階にあり、プロダクト開発の進め方とし て明確になっていない部分 が多い • システムの煩雑化 、プロダクト方向性のための意思決定材料が圧倒的に足りて いない状態
15. システム的な話 - 管理画面の種別が多く、種別ごとにレガシーなシステムから脱却している途中 - 写真館向けシステムはまだレガシーシステムに内包されており、様々なロジックと共存状態 旧メインシステム 保護者向け機能 先生向け機能 印刷会社向け機能 写真館向け機能 etc… 新 メイン API 各種ユーザ向けの 基軸となる新API郡 (切り出し済) 先生向け管理画面 (切り出し済) 社内管理画面 (切り出し済) カメラマン管理画面 APIは順次 core 移行または 各種システムごとに切り出す etc… 【TARGET】 写真館向け管理画面 ethnam
16. PJTステータス - 新設チーム立ち上げに向け、JOIN時点は全員違うPJTに向き合っていた - 新設チーム最初のPJTは、管理画面のリプレイス After Before
17. © SEN CORPORATION JOIN時のつまづき • 20年近く続く事業のシステムでステークホルダーが非常に広い • 事業フェーズの転換期 ◦ プロダクト初期はとにかくユーザ数を増やすことや売上を取ることが重要 ◦ 今後は、プロダクトとしての中長期の方向性、プロダクトビジョンが求められていく ▪ 特定ユーザのみに提供されている機能、ユーザ・社内オペレーションの特殊な運用ケースが 多い ▪ 可視化と精査、全体の認識を揃えないといけない • プレイングマネージャーという役割上、腰を据えてキャッチアップともいかず、決め つつ進まないと間に合わない
18. © SEN CORPORATION JOIN時のつまづき • 20年近く続く事業のシステムでステークホルダーが非常に広い • 事業フェーズの転換期 ◦ プロダクト初期はとにかくユーザ数を増やすことや売上を取ることが重要 ◦ 今後は、プロダクトとしての中長期の方向性、プロダクトビジョンが求められていく ▪ 特定ユーザのみに提供されている機能、ユーザ・社内オペレーションの特殊な運用ケースが 多い ▪ 可視化と精査、全体の認識を揃えないといけない • プレイングマネージャーという役割上、腰を据えてキャッチアップともいかず、決め つつ進まないと間に合わない 事業の全体像 (の一部) 大盛
19. まず何からすればいいのだろう、、、
20. 書籍「プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける 」より - プロジェクトを開始するときは、まず自分たちが何を知っているのかを明らかにします - その状況において真であること、つまり既知の知識から始めるのです Known Knowns (知っていると知っていること ) 事象として認識し、理解できていること Unknown Knowns (知っていると知らないこと ) 認知はできているが、事象の根拠がないこと Known Unknowns (知らないと知っていること ) 事象は認識しているが、理解できてないこと Unknown Unknowns (知らないことを知らないこと ) 事象もなく、認知もできていないこと 事象として 既知である 未知である 認知 として 既知である 未知である 知っていることを 知っていかねばならない
21. © SEN CORPORATION 見えてきた、知らねばならないこと - 「私」はどこに向かえばいいのか？ - 私に対する期待の方向性はどこなのか - 「チーム」は何を成し遂げればいいのか？ - 目下のプロジェクトは、どこに向かっていくためのものなのか - 「プロダクト 」はどんな世界を目指しているのか？ - 何をもって、機能の是非を考えねばならないのか - 「ユーザ」はどんな未来を描いていくのか？ - 解決したい世界線は、ユーザが描く世界線に向かっているのか 我々は いまどこに？ 我々は どこへと向かう？
22. © SEN CORPORATION 1. 事業の紹介と JOIN時の状態 2. 「我々はいまどこに」を観測する 3. 「我々はどこに向かっているのか？」に 向けて 目次
23. 最初の「我々」 is …
24. 自分
25. 自分はどこに向かうべきなのか？をすり合わせる - 上長やチームメンバー、ビジネス側の望む期待値、意思決定の範囲を模索する - 愚直に色々見ていく やったこと 上司/事業サイド との週次1on1 メンバー 初回1on1 - チーム課題や組織課題の掘り下げ - 変えたいこと、変えたくないことの認識合わせ 営業資料/サポート向け マニュアルを漁る 関係者のSlack ストーキング - プロダクト視点の仕様書はないので、見えるものから探 していく - 過去の会話は有益な情報が多い
26. 次の「我々」 is …
27. チーム
28. やったこと :チームガイドラインの作成 - チームの指針の再定義 - MTGの刷新、チームポリシーやコーディングガイドラインの定義 チームのREADME Working Agreement - 「見ればJOINできる」の書 - チームの関連リンク・オンボーディング情報等 - 「チームの認識ズレをなくす」ための書 - チームの基本ルール、会議体や StoryPoint の定義など
29. やったこと :Scrum の導入 - 開発タスク管理をBacklog から Github Project へ - Iteration 制を導入し、Sprint Goal を決めてサイクルを回す to Github に移行して区別する - 事業サイドからの要望(Backlog) - 検討後にHowから決めるもの - 開発タスク(Github) - 実施するもの
30. やったこと : 振り返り/ Plannning の再定義 - 振り返り：文章を書くよりも議論の時間を優先したく、付箋で議論 - Plannning：作業日数から1日あたりに消化可能なポイント を算出 振り返り - 文章でなく、要素で書く - 「気になる🌴」が多いものを議論 Plannning
31. やったこと : ADR(Architecture Decision Record) - チームの技術リードエンジニアに牽引頂き作成 - 技術の意思決定における課題、トレードオフや決定までの背景をまとめる
32. やったこと : 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
33. • チームとしての定量的な計測がで きるようになってきた • システムを切り出したことで他チー ムへの依存なく進めやすい • 新メンバーのオンボーディング基盤 が整った • 抜本的なシステム改善のためには DB改善が必須 • そこに触れるには、全システムと連 携しないといけない • リプレイスは情報設計のみの改善 で、BFF層でよしなに整形
34. 次の「我々」 is …
35. プロダクト
36. やったこと：ユーザ要求仕様書のフォーマット作成 - 事業サイドからの仕様確認依頼をなくしたい - ユーザ目線のマスタとなる仕様書を組み、CS/マーケ/ビジネス/プロダクト間の認識誤差を防ぐ 社内横断のデザイナーレビューやQAチーム、ビジネス連携に役立っている
37. やったこと：事業サイドからの Issue 方針改善 - システム側への依頼・相談・質問はすべて区別せずに投げていた - 粒度がバラバラで、対応判断をすべて開発チームが持つ負担が大きかった 相談・質問 改善要望 不具合報告 ビジネス マーケ サポート 社内オペ 開発チーム で判断 不具合報告 相談・質問 改善要望 即時対応 Product Backlog を作成 MGR/TLで フィルタリング After Before
38. やったこと： Product Backlog 作成 - Product Backlog の中で、Issue をWhy/What から事業サイドと認識を揃える - ビジネス優先度とシステムリプレイスを対比して対応判断
39. やったこと：事業サイドとの会議体整理 - 週次の定例をSprint Review とプロダクトバックログ会議で分離 - 現在の話と未来の話でMTGを分け、アジェンダの粒度を統一する (週次) 開発 ↔ 事業サイド定例 (隔週) Sprint Review (隔週) Product Backlog会議 - 未来のことに関する場 - 事前に事業部でフィルタリングしたIssueを上 げる - 課題のWhat/Whyを掘り下げ、開発の有無を 判断 - 現在のことに関する場 - Sprint の成果物を事業サイドに見せる - フィードバックを受け取る場所 - 議論の粒度、タイムラインがバラバラ - 実施する内容なのか、未定の内容なのか でメンバーに混乱が起きやすい
40. やったこと：イベントストーミング - (ビッグピクチャー) 事業サイドに見えている業務フローを可視化して時系列に並べる - 潜在的に属人化しているオペレーションの発見、開発↔事業の言語の誤差を揃える 契約〜売上までの全体像を掘り起こし 開発の知らないドメイン知識が顕在化する 社内フローは洗練されているものの、 ユーザ側の業務フロー理解 がもっと必要
41. • プロダクト↔ビジネスでの連携基盤 が整った • 「本当にやるべきなのか？」を精査 して議論する場ができた • 「何を目指すのか？」をプロダクト ↔ビジネスで同じ向きで走れる • あくまで基盤ができただけ(失敗談 はこれから) • プロダクト課題はまだほとんど潜在 化している • ユーザの業務理解 が情報として全 然足りていない
42. © SEN CORPORATION 1. 事業の紹介と JOIN時の状態 2. 「我々はいまどこに」を観測する 3. 「我々はどこに向かっているのか？」に 向けて 目次
43. © SEN CORPORATION チームやプロダクト整備で見えてきたこと • 社内オペレーションの洗練度が高い一方で、ユーザ側の見えていない業務がま だまだありそう • システムが目指しているもの、セールスが目指しているもの、組織が目指してい るものなどが名言化できていない ユーザのセグメント分解とプロダクトビジョンの策定が急務
44. 開発も現場に足を運ぼう ユーザの生の業務を見よう
45. 「我々はどこに向かっているのか？」は鮮度がある - 市場ニーズの変化、投資状況、競合他社の動向など様々な要因で変化していく - 「問い続けて見直す」ための仕組みづくりが必要 現状理解 「我々はいまどこにいるのか？」 指針の決定 「我々はどこに向かっているのか？」 仮説検証 「我々の向かう先は正しいのか？」 発見と見直し 「我々は間違っていたかもしれない」
46. - 知っていることは増やす が、「誰の」を意識しないとずれが生じる - 新設チームはやることがいっぱい。しかし、施策は 「相手」を考えながら作っていこう 主語を意識しつつ分かっていることを増やしていく Known Knowns (知っていると知っていること ) 事象として認識し、理解できていること Unknown Knowns (知っていると知らないこと ) 認知はできているが、事象の根拠がないこと Known Unknowns (知らないと知っていること ) 事象は認識しているが、理解できてないこと Unknown Unknowns (知らないことを知らないこと ) 事象もなく、認知もできていないこと 事象として 既知である 未知である 認知 として 既知である 未知である 「チーム 」の 話？ 「プロダクト 」の 話？ 「ユーザ 」の 話？ 「市場」の 話？
47. © SEN CORPORATION 問い(最後にもう一度 ) • いま話している「我々」の主語 は揃っていますか？ ◦ 会社？プロダクト？部署？チーム？私？ • その「我々」全員の向かう先は揃っていますか？ • 向かう先は、会社や組織として向かう先へと繋がっていますか？
48. 主語を意識して 「我々はどこに向かっているのか」 を問う仕組みを作ろう