Upgrade to Pro — share decks privately, control downloads, hide ads and more …

同じ画面を見て、違うものを見ていた

Sponsored · Your Podcast. Everywhere. Effortlessly. Share. Educate. Inspire. Entertain. You do you. We'll handle the rest. →
Avatar for Ryota Kabe Ryota Kabe
May 18, 2026
5

 同じ画面を見て、違うものを見ていた

「「支援」を止めない技術。虎ラボ | CAMPFIRE 開発の裏側をLT会!第二回」でLTした資料です。

https://connpass.com/event/388522/

Avatar for Ryota Kabe

Ryota Kabe

May 18, 2026

Transcript

  1. ① 自己紹介 マスター到達記念に 新しいアケコンを買いました 嘉部亮太 / Kabe Ryota X: @_waaaaall,

    GitHub: @waaaaall 株式会社CAMPFIRE(2021年11月~) プロダクト開発U/DX開発G 社内事業部の業務改善 趣味 音楽(ライブによく行く、年50現場ぐらい) 最近の流行りはスト6(ベガ/C.ヴァイパー)、鮭を焼く 本日のスライドは Markdown by Me / Rendered by Claude でお送りします 同じ画面を見て、違うものを見ていた 2 / 16
  2. ③ CAMPFIRE広告への関わり方 - 販売管理 内部データ基盤 🔥 CAMPFIRE 本体 🗄 BigQuery

    📊 Spreadsheet/GA ( 運⽤・数値集計など) 📢 広告媒体 🔧 外部SaaS( 取引データ) 販売管理の運用や数値集計などの改善 広告の申し込みや取引データは 外部SaaS(主に事業部が管理) 同じ画面を見て、違うものを見ていた 5 / 16
  3. ④ 現場の状況 販売管理チーム、開発・マーケ・経理・情シス…… 複数事業部が混ざる 事業部主導で運用が回っている現場 に、開発として参加 関わり始めて約1年、ドキュメントが少ない 開発依頼/調査は各方面/様々な場所から飛んでくる 定例では タスクA、チャンネルでは

    タスクB。定例の場では B の状況を踏まえずに A の進捗確認 改善せねば…… 共通バックログ 設置: 依頼元を問わず全体タスクを見える化 印象 プロダクト開発と違い、言葉のニュアンス が伝わりづらい、コミュニケーションに苦労 同じ画面を見て、違うものを見ていた 6 / 16
  4. ⑤ 取引データの同期エラー CAMPFIRE本体 と 外部SaaS の間で取引データを同期するバッチが project_id が不整合 でエラー なぜ発生するのか

    広告の申し込みフォーム(外部SaaS)で project_id を 手入力 する必要があって打ち間違いが発生する このままでは取引データを 取り込めない 同じ画面を見て、違うものを見ていた 8 / 16
  5. ⑥ 外部SaaSのデータ不整合、事業部に データ修正を依頼 する 課題① すぐには対応されない。待ちの間、毎時実行・対象「直近3時間の取引」 最低3時間は連続通知 課題② 対応が遅れると通知が止まってしまう、且つ月1~2回の発生なので都度対応でお茶を濁す… →

    恒久対応に繋がりにくい 課題③ バッチエラー通知は開発部全体に届く 外部SaaS起因のエラーなのに、プロダクトのエラーとして開発部全体に通知が飛んでしまう 別チームが拾ってメンションしてくれる場面も やむなく 開発判断でデータを直接修正 することも 同じ画面を見て、違うものを見ていた 9 / 16
  6. ⑦ 開発と事業部の両体制を正式フローとして提案したが…… 正しい project_id を 開発が断定するのはリスクがある → 事業部の確認が必要 申込時にユーザーが入力した内容は安易に変えてはいけない →

    一定保持が必要 という事業部の線引き これまで通り 事業部主導で進めてもらうこと に 同じ画面を見て、違うものを見ていた 10 / 16
  7. ⑧ 対応完了の認識ズレ 審査OK 審査NG ( 例: project_id 不整合) 📝 広告申し込み

    🗂 取引データ作成 🔍 審査フロー ✅ 取引データ有効 ( 審査ステータス: 受注確認) ❌ 取引データ却下 ( 審査ステータス: NG NG 理由: プロジェクトID 間 違い) 「対応完了」報告は 「審査の結果、NGに該当する取引データを却下しましたよ」 という意味 取引データには 審査ステータス が存在 取引データが却下されても project_id は修正されないままなので、エラーは引き続き発生し、同期もされない 同じ画面を見て、違うものを見ていた 12 / 16
  8. ⑨ 同じ画面を見て、違うものを見ていた 開発の認識 事業部の認識 エラーの原因 project_id が間違っている project_id 不整合の取引データがある 対応の意味合い

    project_id を正しい値に修正する 審査して取引を却下する どちらも間違っていなかった、ただすり合わせができていなかった 同じ画面を見て、違うものを見ていた 13 / 16
  9. ⑨ 恒久対応 審査が却下され、審査ステータスが審査NG や project_idが不整合 の取引データは project_id を nil にして

    取り込むように調整 修正自体はシンプルなのに 辿り着くまでが長かった 同じ画面を見て、違うものを見ていた 14 / 16
  10. ⑪ まとめ 思い込みが認識のズレを生んだ 「外部SaaSのデータが不整合」という前提で動いていた 不整合のデータは取り込まない設計 Project と 取引データ が間違って紐づくリスクを防ぐため 見えていなかったケース

    「審査NG かつ project_id 不整合」という状態の取引データが存在する 不整合ではなく、考慮漏れ だった このパターンの取引が取り込まれていないこと自体、開発は気づいていなかった 早めに対話してよかった 一時対応として、通知の宛先を開発 → 事業部へ変更するという方針もあった もし変更してたら、事業部が審査NGで対応済みなのに 通知が鳴り止まない という状況に 先に事業部と認識を合わせたことで、このすれ違いを回避できた 同じ画面を見て、違うものを見ていた 15 / 16