プロジェクト情報が散らばる問題をどう解決するか

プロジェクトが進むにつれ、

• Backlog
• スプレッドシート
• Slack
• 設計書
• 画面一覧
• 機能一覧
• 議事録

…と、情報がいろいろな場所に散らばっていきます。

その結果、現場で頻発するのがこういう状況です。

• 「Backlogとスプシの内容が違う」
• 「画面一覧と機能一覧が合ってない」
• 「Slackの話と設計が違う」
• 「結局どれが最新版？」
• 「前の会議で何が決まったっけ？」

どれも“情報が散らばっていること”が根本原因です。

この記事では、私がPMとして実務で行っている“情報の集約方法” をまとめています。

1. 情報が散らばると何が起きるか（現場あるある）

プロジェクトの混乱は、ほとんどが「認識のズレ」から生まれます。
情報が散らばっていると、

• 仕様が複数バージョンできる
• メンバーごとに違う前提で作業が進む
• 誰かだけが“正しい情報”を持っている状態になる
• 手戻りが増える
• 引き継ぎできない
• 新メンバーがキャッチアップできない

という問題が起きます。
情報集約は、プロジェクトの安定に直結します。

2. “一元化”の基本原則

まず「正の情報源」を決める

私が現場で最初に決めるのはこれです。
“最終的にどこを見れば正しいのか”を一つに決める

原則1：ツールごとに役割をはっきりさせる

例（実際の現場で使っているもの）

• Backlog … タスク・課題・決定事項の“正”
• スプシ … 一覧性が必要なもの（画面一覧・機能一覧）
• 設計書 … 仕様の最終形
• Slack … 議論と速報
• 議事録 … 会議の公式記録

これらが混ざると一気に破綻します。

原則2：更新ルールを決める

• Backlogに登録されていない仕様は“決定”ではない
• Slackの議論だけで決めない
• 設計書の更新は担当者を固定
• スプシは“整理用”だが最終版はBacklogで管理
• 画面一覧と機能一覧は常に整合させる

役割と更新ルールを決めるだけで、情報は散らばらなくなります。

原則3：議論する場所と、情報を残す場所を分ける

• Slack → 議論
• Backlog → 決定事項
• 設計書 → 確定仕様

Slackのまま終わると、“仕様がSlackログに埋まる”という最悪の状態が起きます。

3. 現場で実際にやっている具体的な運用

■ Backlog

• 課題・仕様変更・バグは必ずチケット化
• 決まったことは全て Backlog に記録
• Slackで決まった内容も必ずチケットへ反映
• 「Backlogに無ければ決まっていない」という運用

■ スプレッドシート
一覧性が必要な情報はスプシが便利。

• 画面一覧
• 機能一覧
• API一覧
• パラメータ整理

ただし、スプシは“整理のための中間成果物”であって最終版ではないのがポイント。
正式決定はBacklog・設計書側に寄せます。

■ 設計書（システム設計、画面設計など）

• 決定した仕様の最終形
• 不要なバージョン違いは作らない
• ファイル更新は責任者を固定
• “どれが最新版か”を明確にする

■ Slack

• 議論・相談・アイデア共有
• 決まったことはBacklogへ転記
• 全員が見れる場所での会話を推奨（DMでクローズしない）

■ 議事録

• 毎回ミーティングの最後に“決まったこと”を確認
• 次アクションと担当者もその場で合意
• 内部MTGと外部MTGで分けて管理

4. 情報集約のために必ずやっていること

① 決まった内容は必ずBacklogへ集約

「Slackで言ってた話」ではなく“チケットに書かれたものが正”になる。

② スプシと画面一覧・機能一覧は常に整合

• 画面一覧の機能ID
• 機能一覧との紐づけ
• API仕様との整合性

このあたりがズレると、後々手戻りが一気に増える。

③ バージョン違いを作らない

よくあるのが

• 画面設計書_ver3
• 画面設計書_ver3_鈴木修正
• 画面設計書_ver3（修正版）

のような地獄状態。
→ 最新版は常に一つ にする運用が必須。

④ 決まった内容に優先度をつける

これは地味に効果が高い。

優先度の例：

1. 設計書（最終決定）
2. Backlog（決定事項）
3. 会議の議事録
4. SlackLog
5. 口頭

“口頭 → Slack → 公式化 → Backlog → 設計へ反映”
という流れにすると事故が減る。

5. 若手PMやエンジニアがハマりやすいポイント

• Slackで決まった気になって終わる
• Backlogを更新せずローカル情報を持つ
• スプシが“正”になり、Backlogと食い違い始める
• 設計書が複数バージョンになる
• DMや個別会話で勝手に仕様が変わる
• 画面一覧と機能一覧がズレたまま進行する

どれも現場では本当に多い。

6. 情報が一元化されるとプロジェクトは安定する

情報の“正”が明確になったプロジェクトは、

• 認識ズレが激減する
• 手戻りが減る
• スケジュールが安定する
• PMが説明しやすくなる
• 新メンバーがすぐキャッチアップできる
• トラブル時も原因をすぐ追える

特に、大規模PJや長期開発で効果が大きい。

まとめ

• 情報源を一本化（Single Source of Truth）
• 各ツールの役割を明確化
• Backlogを“決定事項の正”にする
• スプシは整理用、設計書は最終版
• Slackの議論は必ずBacklogへ反映
• バージョン違いを作らない
• 認識ズレを最小にすることがプロジェクト安定の鍵

情報が整うと、プロジェクトの品質と進行スピードが一気に上がります。