Lock in $30 Savings on PRO—Offer Ends Soon! ⏳

「我々はどこに向かっているのか」を問い続けるための仕組みづくり / Establishing ...

daitasu
July 23, 2024

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

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

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

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

daitasu

July 23, 2024
Tweet

More Decks by daitasu

Other Decks in Technology

Transcript

  1. © SEN CORPORATION 名前: • 藤井 大祐 お仕事: • 千株式会社

    ものづくり部 (2024/4/15 入社) ◦ ちょうど3ヶ月経ちました • フロントエンドが好きですが、最近はバックエンドや らインフラやら勉強してます • 現職ではEMやPdMの役割も持ちつつ開発実装をし てます • 恐竜が好き 自己紹介 @daitasu
  2. © SEN CORPORATION 問い • いま話している「我々」の主語 は揃っていますか? ◦ 会社?プロダクト?部署?チーム?私? •

    その「我々」全員の向かう先は揃っていますか? • 向かう先は、会社や組織として向かう先へと繋がっていますか?
  3. はいチーズ!フォトについて インターネット写真販売サービス「はいチーズ!フォト」の大きな区分 カメラマン撮影プラン (直販) 先生プラン 撮影事業者(写真館) プラン 自社のカメラマンが 園のイベントで撮影 保育園の先生が

    撮影 撮影事業者が 園のイベントで撮影 はいチーズ!フォト にアップロード はいチーズ!フォト にアップロード はいチーズ!フォト にアップロード 保護者が EC上で購入 印刷・配送・etc…
  4. チーム状況 - 写真館向けサービスはあるが、専任チームが不在でシステムはほぼ踏み込めない状態だった - 今年、自分を含めEM/PdMが入ったことで、写真館向けの専任チーム が発足 ~2024/4 MGR 1名 2チーム

    15名程度 toB 領域のサプライチェーン全 体を担う MGR 1名 PdM 1名 EM 1名 撮影事業者向け システム サプライチェーン前半 運用・問い合わせ サプライチェーン後半 2024/5~
  5. © SEN CORPORATION 組織的な課題 • 向き合うのは事業として非常にインパクトが高い領域 • セールスや社内オペレーションが洗練されている一方で、プロダクト・システムとし ての専任者はいないままに進んできている •

    ビジネス↔プロダクトの連携指針が模索段階にあり、プロダクト開発の進め方とし て明確になっていない部分 が多い • システムの煩雑化 、プロダクト方向性のための意思決定材料が圧倒的に足りて いない状態
  6. システム的な話 - 管理画面の種別が多く、種別ごとにレガシーなシステムから脱却している途中 - 写真館向けシステムはまだレガシーシステムに内包されており、様々なロジックと共存状態 旧メインシステム 保護者向け機能 先生向け機能 印刷会社向け機能 写真館向け機能

    etc… 新 メイン API 各種ユーザ向けの 基軸となる新API郡 (切り出し済) 先生向け管理画面 (切り出し済) 社内管理画面 (切り出し済) カメラマン管理画面 APIは順次 core 移行または 各種システムごとに切り出す etc… 【TARGET】 写真館向け管理画面 ethnam
  7. © SEN CORPORATION JOIN時のつまづき • 20年近く続く事業のシステムでステークホルダーが非常に広い • 事業フェーズの転換期 ◦ プロダクト初期はとにかくユーザ数を増やすことや売上を取ることが重要

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

    ◦ 今後は、プロダクトとしての中長期の方向性、プロダクトビジョンが求められていく ▪ 特定ユーザのみに提供されている機能、ユーザ・社内オペレーションの特殊な運用ケースが 多い ▪ 可視化と精査、全体の認識を揃えないといけない • プレイングマネージャーという役割上、腰を据えてキャッチアップともいかず、決め つつ進まないと間に合わない 事業の全体像 (の一部) 大盛
  9. 書籍「プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける 」より - プロジェクトを開始するときは、まず自分たちが何を知っているのかを明らかにします - その状況において真であること、つまり既知の知識から始めるのです Known Knowns (知っていると知っていること

    ) 事象として認識し、理解できていること Unknown Knowns (知っていると知らないこと ) 認知はできているが、事象の根拠がないこと Known Unknowns (知らないと知っていること ) 事象は認識しているが、理解できてないこと Unknown Unknowns (知らないことを知らないこと ) 事象もなく、認知もできていないこと 事象として 既知である 未知である 認知 として 既知である 未知である 知っていることを 知っていかねばならない
  10. © SEN CORPORATION 見えてきた、知らねばならないこと - 「私」はどこに向かえばいいのか? - 私に対する期待の方向性はどこなのか - 「チーム」は何を成し遂げればいいのか?

    - 目下のプロジェクトは、どこに向かっていくためのものなのか - 「プロダクト 」はどんな世界を目指しているのか? - 何をもって、機能の是非を考えねばならないのか - 「ユーザ」はどんな未来を描いていくのか? - 解決したい世界線は、ユーザが描く世界線に向かっているのか 我々は いまどこに? 我々は どこへと向かう?
  11. 自分はどこに向かうべきなのか?をすり合わせる - 上長やチームメンバー、ビジネス側の望む期待値、意思決定の範囲を模索する - 愚直に色々見ていく やったこと 上司/事業サイド との週次1on1 メンバー 初回1on1

    - チーム課題や組織課題の掘り下げ - 変えたいこと、変えたくないことの認識合わせ 営業資料/サポート向け マニュアルを漁る 関係者のSlack ストーキング - プロダクト視点の仕様書はないので、見えるものから探 していく - 過去の会話は有益な情報が多い
  12. やったこと :チームガイドラインの作成 - チームの指針の再定義 - MTGの刷新、チームポリシーやコーディングガイドラインの定義 チームのREADME Working Agreement -

    「見ればJOINできる」の書 - チームの関連リンク・オンボーディング情報等 - 「チームの認識ズレをなくす」ための書 - チームの基本ルール、会議体や StoryPoint の定義など
  13. やったこと :Scrum の導入 - 開発タスク管理をBacklog から Github Project へ -

    Iteration 制を導入し、Sprint Goal を決めてサイクルを回す to Github に移行して区別する - 事業サイドからの要望(Backlog) - 検討後にHowから決めるもの - 開発タスク(Github) - 実施するもの
  14. やったこと : 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
  15. • チームとしての定量的な計測がで きるようになってきた • システムを切り出したことで他チー ムへの依存なく進めやすい • 新メンバーのオンボーディング基盤 が整った •

    抜本的なシステム改善のためには DB改善が必須 • そこに触れるには、全システムと連 携しないといけない • リプレイスは情報設計のみの改善 で、BFF層でよしなに整形
  16. やったこと:事業サイドからの Issue 方針改善 - システム側への依頼・相談・質問はすべて区別せずに投げていた - 粒度がバラバラで、対応判断をすべて開発チームが持つ負担が大きかった 相談・質問 改善要望 不具合報告

    ビジネス マーケ サポート 社内オペ 開発チーム で判断 不具合報告 相談・質問 改善要望 即時対応 Product Backlog を作成 MGR/TLで フィルタリング After Before
  17. やったこと:事業サイドとの会議体整理 - 週次の定例をSprint Review とプロダクトバックログ会議で分離 - 現在の話と未来の話でMTGを分け、アジェンダの粒度を統一する (週次) 開発 ↔

    事業サイド定例 (隔週) Sprint Review (隔週) Product Backlog会議 - 未来のことに関する場 - 事前に事業部でフィルタリングしたIssueを上 げる - 課題のWhat/Whyを掘り下げ、開発の有無を 判断 - 現在のことに関する場 - Sprint の成果物を事業サイドに見せる - フィードバックを受け取る場所 - 議論の粒度、タイムラインがバラバラ - 実施する内容なのか、未定の内容なのか でメンバーに混乱が起きやすい
  18. • プロダクト↔ビジネスでの連携基盤 が整った • 「本当にやるべきなのか?」を精査 して議論する場ができた • 「何を目指すのか?」をプロダクト ↔ビジネスで同じ向きで走れる •

    あくまで基盤ができただけ(失敗談 はこれから) • プロダクト課題はまだほとんど潜在 化している • ユーザの業務理解 が情報として全 然足りていない
  19. - 知っていることは増やす が、「誰の」を意識しないとずれが生じる - 新設チームはやることがいっぱい。しかし、施策は 「相手」を考えながら作っていこう 主語を意識しつつ分かっていることを増やしていく Known Knowns (知っていると知っていること

    ) 事象として認識し、理解できていること Unknown Knowns (知っていると知らないこと ) 認知はできているが、事象の根拠がないこと Known Unknowns (知らないと知っていること ) 事象は認識しているが、理解できてないこと Unknown Unknowns (知らないことを知らないこと ) 事象もなく、認知もできていないこと 事象として 既知である 未知である 認知 として 既知である 未知である 「チーム 」の 話? 「プロダクト 」の 話? 「ユーザ 」の 話? 「市場」の 話?
  20. © SEN CORPORATION 問い(最後にもう一度 ) • いま話している「我々」の主語 は揃っていますか? ◦ 会社?プロダクト?部署?チーム?私?

    • その「我々」全員の向かう先は揃っていますか? • 向かう先は、会社や組織として向かう先へと繋がっていますか?