PM-Meetup-2_数値検証5週間の振り返り

Transcript

1. 1 数値検証5週間の振り返り 若手PMがやらかしたこと、できたこと
2. 2 自己紹介 基幹刷新の「本部発注」を担当する、若手PMです トライアルカンパニー 4年目／中山 竜誓（なかやま りゅうせい） 基幹システム刷新プロジェクトで、本部発注領域のリーダーとAI活用推進を担当 熊本県出身。23卒入社、IDPOSデータ分析システムのサポートを2年。 2025年1月から今の基幹刷新へ 最近、自分でDIYできる団地に引っ越したんですが、まだ何も手付かずです（笑）
3. 3 今日話すこと 数値検証5週間を、3つの切り口で振り返ります できた 5週間で何をやってきたか やらかし 5週間でやらかしていたこと 学び 振り返って気づいたこと
4. 4 数値検証 数値検証 ＝ そのデータを新基幹側で再現し、本番と突き合わせる作業 本部発注 ＝ 物流センター等への商品発注を本部で行う業務 ※ 100%問題なく登録できる状態にしないと、新基幹で登録できずセンター在庫が足りなくなり、欠品につながる恐れがある。 旧DB 抽出 システム へ投入 登録の 承認 / 却下 1日単位で 本番と突合 旧DBからの抽出〜登録承認/却下までを 3分間隔で自動実行（ジョブ化） 目標：登録成功率 100% ／ 全項目一致
5. 5 5週間の全体像 4つのフェーズで進んできた ① 立ち上げ ② STG安定化 ③ 連続して問題発生 ④ 改善
6. 6 ① 立ち上げ（DEV） 3 日 3/24〜3/26：DEV検証基盤を立ち上げ ※抽出が出来、登録ができる状態になるまで 前のフェーズから ゼロから検証環境を立ち上げる このフェーズでやったこと ・ジョブを置く環境選定、ジョブ実装、初回テストといった初期の立ち上げ ・3分／30分間隔の動的投入を実装 ・どの項目をいつ突き合わせるといった本番との突合方針を決定 次のフェーズへ DEV → STG に移行（環境差の検証へ）
7. 7 ② STGへ移行 0.77 % STG移行直後の登録成功率（出発点） 56 / 7,259 登録できた行数 前のフェーズから DEV基盤を STG に移行 （環境差や見えていなかった問題が顕在化） このフェーズでやったこと ・ログ・Traceを掘ることで、マスタ参照APIの設定欠落等の問題を特定 ・少データで早く検証 → 問題を早期に発見 ・生成AIが調べられるようにサービス名、方法等コンテキストを整理し、 調べる速度を上げた 次のフェーズへ 安定化しかけたところに様々な問題が連続発生
8. 8 ③ 連続して問題発生 36.6 % 4/27 の登録成功率 （初のSTG１日集計） 61.0% 4/27 失敗率／ 成功 36,688・失敗 61,184・スキップ 2,477 前のフェーズから STGで安定化しかけたところに、様々な問題が連続発生 起きたこと（原因） ・4/17 支援ツールBEエラー (OOM) ・4/21 loginすることが出来ない （KEDA + STGのDB24/7になっていない） ・4/25〜26 ジョブの停止(ジョブを置いているクラスタダウン) ・4/27 失敗率 61.0% に到達（他様々な問題が合わさりこんなことに） 自分の動き ・協力会社様と認識合わせ → 担当者を充てて対応 ・投入で発生したエラーを整理出来るものから開発者へ引き継ぎ ・ログ・Traceで要因を1つずつ特定 次のフェーズへ 見えるように出来る部分から順に潰す改善期へ
9. 9 ④ 改善期 87.36% 5/8 の登録成功率（5週間で最高） +50.7pt 4/27 36.6% から 5/8 87.36% への引き上げ 前のフェーズから 連続で発生した問題に対して１つずつ、見えるようにし対処した このフェーズでやったこと ・ジョブを置いたクラスタダウンの原因を特定 ・応急策でメモリ割当超過を改善 ・サービスそのものは安定してきて下記のような問題が見えてきた ・STGへのマスタデータ同期問題 ・誤った仕様の判明 ・１日で480回あるジョブの内、２回程原因不明の失敗が発生している 全体を俯瞰する 5週間の階段を俯瞰する
10. 10 全体俯瞰：登録成功率 １つずつ問題を潰していくことで、問題の見える層が変わっていった 36.6% 49.3% 69.3% 84.1% 87.4% 0 10 20 30 40 50 60 70 80 90 100 4/27 4/28 4/29 5/5 5/8
11. 11 問題の見える化 問題を見える化して、難所を1つずつ越えた 問題の見える化 ・失敗自動分類スキルでログを横断して調査 ・日次レポート生成スキルで投入&突き合わせ結果を共有 ・上記のようなスキルを呼ぶスキルで、報告用レポートを生成 ・3分間隔ジョブの結果をSlackへ通知し、１日の全体感が分かるように ※公開できるようにいくつか修正した図
12. 12 やらかし：報告・可視化 一番のやらかしは、「報告・可視化」だった システム 問題を見える化できた ログ・Trace、レポートスキルで 何が起きているか追えるようにし、 １つずつ対処していった できた 自分の仕事 上から見えなかった 進捗・問題・数値の報告と可視化を 速さを優先して後回しにした やらかし 速さと報告を、トレードオフにしてはいけなかった
13. 13 学び：見える化と判断材料 見える化できる状態を作ることが、PMの仕事の土台になる 見える化の精度をマネジメントする 「課題が増える」と「見える化が進む」は別物 環境が動いて初めて、掘り下げ可能な層がある → 例：環境が安定してから、その奥のマスタ同期・仕様の問題が見えてきた 判断材料の優先（AIとの付き合い方） 解決策の前に、まず1次情報（ログ・Trace）で原因を確かめる AIは集める／分類する／文書化を速くする ただし「何を見るべきか」を自分で整理できることが前提 → 例：Timeout の見立てを外し、1次情報に戻って再特定した
14. 14 若手PMとしての所感 速さと報告を、両立できる若手PMになりたい 一番のやらかしは 「周りから見えるようにする」を後回しにしたこと。