制作現場向け「Backlog状況共有支援UI」の情報設計・PoC開発

要点

  • Backlog APIを活用した朝会支援UIのPoC設計・実装
  • 要注目案件・更新停滞・次アクション不足を可視化
  • 「管理」ではなく「認識共有」に特化した情報設計を実施
担当領域
企画・要件整理
期間
2026年5月

案件背景

Backlog上に分散した課題・コメント・更新状況をもとに、ディレクターチーム向けの「支援UI」を企画・設計・実装。
制作現場で発生していた「認識共有不足」「次アクション不明」「確認負荷の偏り」を、Backlogをマスタとした観測レイヤーとして整理・可視化した。

PoCとして運用を開始した結果、Backlog標準画面では把握しづらいメンバー負荷や案件状況を直感的に把握できる点が評価され、事業部全体への正式展開・横展開が決定した。

課題

  • Backlog上で案件状態や優先確認事項が埋もれやすかった
  • 朝会時に「今日どこを確認するべきか」が整理されておらず、口頭確認に依存していた
  • ディレクターごとの確認負荷や案件の停滞状況を把握しづらかった
  • Backlogの運用ルール(課題名・コメント記載方法)がチームごとに異なり、第三者が状況を把握しづらかった

やったこと

  • Backlog APIを利用した支援UIを企画・設計・実装
  • 要注目・注意・待機状態など、案件状態を観測するための状態定義を設計
  • 担当者ごとの「今日の確認事項」を優先表示するUIへ再設計
  • Netlify・GitHub Actionsを利用し、定期的にBacklog情報を取得・公開する運用基盤を構築
  • コメント記法・命名規則など、Backlog運用改善も含めた要件整理・仕様策定を実施
  • Netlify上へパスワード付き公開を行い、実案件でのPoC運用を実施

実現したこと

  • 定例ミーティング時に「どこを確認するべきか」を短時間で把握できる状態を実現
  • Backlogを置き換えることなく、認識共有を支援する観測レイヤーを構築
  • 実案件データをもとに、情報設計・観測ロジックを改善しながら運用を検証
  • Backlog標準画面では把握しづらいメンバー負荷や案件状況を可視化
  • 事業部標準ツールとして正式採用され、全案件への横展開が決定

設計のポイント

「管理」ではなく「認識共有」に特化した情報設計

完了率や工数ではなく、「今安全に進められるか」「状況共有できているか」を中心に観測するUIとして設計。

朝会用途へ特化したUIに再構成

詳細分析画面ではなく、「今日誰が何を確認するべきか」を5分で把握できる支援UIへ整理・再設計。

ビジュアル

参考画面
参考画面

よくなったこと

制作現場で発生していた「認識共有不足」や「確認負荷の偏り」を解消するため、Backlog APIを活用した支援UIを企画・設計・実装。「管理」ではなく「観測・認識共有」に特化した情報設計により、ディレクターチームが短時間で優先確認事項や担当者ごとの負荷を把握できる状態を実現した。PoC運用を経て事業部内で評価され、Backlog運用改善と合わせて事業部標準ツールとして正式採用・横展開が決定した。

補足

  • Backlog API連携による案件観測ツールを企画・設計・実装
  • Netlify・GitHub Actionsによる定期更新基盤を構築
  • Netlify上でパスワード付き公開を行い、実案件での運用検証を実施
  • 要注目案件・更新停滞・担当者負荷・次アクション不足を可視化
  • Backlog運用ルール(コメント記法・命名規則)の整理・標準化を推進
  • PoC運用後、事業部標準ツールとして正式採用・全案件への横展開が決定
  • GitHubリポジトリを社内へ共有し、社内エンジニアと共同で改善できる体制を構築

Mimu Fujiwara

フリーランスのテクニカルPM/Webディレクター。 Webサイトのリニューアルや改善の相談を受ける中で、「本当に解決したいこと」と「依頼内容」が少しずれている場面によく出会います。 依頼されたものをそのまま作る前に、目的や課題、運用状況を整理し、「何を作るべきか」から一緒に考える立場で関わっています。 WordPressやHubSpotなどのCMS案件を中心に、要件整理・情報設計・技術調整・運用改善までを横断して支援。公開して終わりではなく、その後も無理なく運用・改善できる状態をつくることを大切にしています。