⼿作業で⾒えた運⽤の痛みを、使われるダッシュボードに変えた話

Transcript

1. 手作業で見えた運用の痛みを、使われるダッシュボードに変えた話 2026/5/18 めぐろLT #36 「オペレーションに立ち向かった話」@ 麻布台
2. クロタカ@chronoll エンジニア2 年目 / Web メディア関連のプロダクトを担当 登壇練習中！ Next.js / TypeScript / Go / AI エージェント 会社の所在地 六本木一丁目 自宅の所在地 目黒駅から10 分くらい めぐろLT 初参加です！よろしくお願いします！ 資料の広報確認が間に合わなかったので所属会社は直接聞い てください🧑‍🍳
3. 今日話すこと 自分自身がつらい手動オペレーションを抱えたことで、 より良いダッシュボードとして昇華できた体験談と振り返り
4. 新施策のPoC 、でもダッシュボードはまだない コンテンツ案を自動生成してみる施策→確認・修正・公開の管理が必要 PoC 段階で、本格運用されるか分からない 最初からダッシュボードを作り込むには工数リスクがあった →まずは自分が手作業でこれらのフローを回す形に
5. 実際に行っていたオペレーション
6. 実際に行っていたオペレーション
7. 実際に行っていたオペレーション
8. 実際に行っていたオペレーション
9. ダッシュボード化→PdM が1 画面のみで運用 既存の開発同様、API 作成・画面実装の工数を確保して実施
10. 単なるダッシュボード開発よりも高い評価を受けた PdM からの評価ポイント 他の画面より使いやすいこと 欲しい情報が欲しい順番で見える 他のダッシュボード画面のUI に縛られず見やすさに特化している 上記のクオリティを通常の工数内で実現でき、期待以上だった ダッシュボード（社内管理画面）の使いやすさや改善はプロダクトより軽視されがち その中で、
11. では、どうしてうまくいったのか？
12. 自分が作業者だったから、要件の裏側に気づけた ❶ 仕様書をもとに、こちらから改善案を提案 仕様書・要望 作業者として見えた改善余地 提案したこと 公開日時が見たい 本当に欲しいのは最終編集日時も含めた確認ではないか 日時情報の出し方を見直す 一覧したい コンテンツ単位より紐づいた情報の羅列の方が確認しやすいのではないか 一覧の粒度や表示単位を検討 ステータスを見たい もっと細分化してフィルターできた方が楽ではないか ステータス細分化・フィルター導線を検討 詳細情報を見たい 本当に判断に必要な順で並んでいるべきではないか 詳細画面の情報配置を見直す ❷判断しやすい順番で、情報と操作を並べた PdM が実際に見る順番で、本文・関連情報・プレビューを並べた 修正保存・公開可否・並び替えを同じ流れの中に配置 コンテンツチェックに必要なサイトへの導線を追加
13. 自分が作業者だったから、要件の裏側に気づけた 単なる「仕様書通り」では実現できなかった 書いてある要件を満たすことと、運用で使いやすいことは同じではない なぜ気づけたのか？ SQL 抽出の過程で必要な情報・仕様への理解が深まる 仕様を見たときに「実際にはこう見えた方が楽では？」と想像しやすかった PdM との確認・修正のコミュニケーションを通じて意図や悩みが見えた →手動オペの過程は無駄じゃなかった！
14. 作業者に近づくと、要件の裏側が見えてくる 実際に難しければ「近くで観察」 「行動をトレース」が一番近道 →深く飛び込むことで手戻りの少ない、最適な改善になるかも！ 意識するポイント例 何を見て何を判断しているか どのタイミングで別の画面や情報を閲覧しているか どの単位・粒度で情報を捉えているのか 繰り返しの動作はないか 運用上我慢している箇所は本当にないか 作業担当者そのものとして運用してみるのが理想だが。 。
15. おまけで考えたこと オペレーション改善は、社内ダッシュボードから始められるかも 後回しになりがちだが、重要な判断や確認、公開管理が集まっている 利用者が不便を感じていても、そもそも依頼して良いものかわからない場合も 今は手を伸ばしやすい AI コーディングエージェントで実装・理解・改善のコストは下がってきている 以前なら後回しだった改善にも着手しやすい
16. ご清聴ありがとうございました！