プロジェクトをやっていると、こんな会話がよく発生します。
- 「最新版ってどれでしたっけ？」
- 「それ、誰と決めた話ですか？」
- 「認識がズレてました」
そのたびに、ドキュメントやチャット、メールをあさり、情報のありかを探しにいく。
この「情報探し」にかかる工数は、決して小さくありません。プロジェクトの個別作業には紐づかないものの、ちりつもでじわじわ効いてくる工数の損失です。
本当は、
「情報をちゃんと集約しないといけないよな」
「管理方法を見直さないとまずいよな」
と感じている。でも、なかなか手がつけられない。そんなPMも多いのではないでしょうか。
手を打ちたいと思いつつも、
- 何を管理すればいいのか分からない
- どう管理すればいいのかイメージできない
という状態のままプロジェクトは進んでいく。そして、気づいたときには情報だけが散らかっている。あるあるですよね。。
その解決のために行うのが情報管理です。やることは、プロジェクト関係者の誰もが、等しく正しい情報にアクセスできる状態を作ること。
この記事では、そのための情報管理の方法を解説します。
この記事でわかること
- プロジェクトにおける情報管理の重要性
- 情報管理として管理すべき情報の種類
- ドキュメントとコミュニケーション管理の方法
情報管理の必要性：なぜ「管理」が必要なのか?
情報管理の目的は、情報をきれいに整理することではありません。
大事なのは、プロジェクトをスムーズに前に進めるための「状態」を作ることです。情報管理の目的は、大きく次の２つです。
- 関係者全員が 「同じ前提・同じ理解」で動ける状態を作ること
- コストを最小化すること
ということで、順番に見ていきましょう。
1. 関係者全員が「同じ前提・同じ理解」で動ける状態を作ること
プロジェクトには、開発チーム、企画チーム、ベンダー、事業部など、立場や役割の異なるメンバーが関わります。
もし、それぞれが異なる情報源を参照していると、どうなるでしょうか？
- 仕様の解釈がズレる
- 前提条件が揃っていない
- 「そんな話は聞いていない」が発生する
なんか想像できますよね…。こうなると、メンバー間で認識齟齬がある状態で行動することになってしまいます。プロジェクトは意思決定の連続です。その意思決定を認識がズレたままなされると、プロジェクトのQCDにとっては致命的です。品質は悪化し、手戻りにより遅延し、その分コストもかかります。
そして、それらの多くは、各自が等しく正しい情報にアクセスできていないこと、さらにいうとそのための構造設計ができていないことが原因です。（だから、正しい情報を確認しあうための認識合わせMTGにたくさん工数が使われるんですよね）
PMの管理には進捗管理や課題管理もありますが、そもそも正しい情報が揃っていないとそれらの管理は機能しません。つまり、情報管理こそその他の管理の前提とも言える、プロジェクトの基盤なのです。
2. コストの最小化
もう一つの目的は、コストの最小化です。
ここで言うコストとは、お金の話というよりは、工数のことです。これを、情報管理を行うことで最小化することがもう一つの目的です。
例えば、次のようなものです。
- 情報探索コスト（どこにあるか探す時間）
- 説明コスト（同じ話を何度も説明する時間）
- 確認コスト（最新版や前提を確認する時間）
- 認識齟齬による手直しコスト（手戻りの作業）
要件定義などの具体的な作業には紐づかないけれど、地味にかかってくる工数たちです。作業に紐づかないからこそ、PMとしても管理しにくい嫌な工数ですよね。
これらの工数は、情報が整理されていない、認識が揃っていないなど、情報が適切に管理されていないことで発生しているものです。
だから、情報管理を行っていくことで最小化を図っていきます。
特に関係者が多かったり、要件が複雑なプロジェクトほど情報管理の重要性は高まります。
情報管理で管理する対象
情報管理といっても、対象はそれほど多くありません。大きく分けると、管理するものは次の2つです。
- ストック情報：ドキュメント（残す情報）
- フロー情報：コミュニケーション（流れる情報）
プロジェクトでは、さまざまな情報を扱いますが、大体この２つで分類できます。ストック情報はいわゆる成果物、フロー情報は成果物を作るための過程でやり取りされる情報のようなイメージです。
ということで、ここからはそれぞれの情報をどう管理していけばいいかを解説します。
ドキュメント管理（ストック）
ドキュメント管理とは、ドキュメントの保管場所を決め、常に「最新版がどれか分かる状態」を維持することです。
ここでいうドキュメントは、議事録、企画書、要件定義書、仕様書などです。
ここで重要なのは、ただわかりやすい場所に保管することだけではなく、誰もが迷わず正しい情報にたどり着ける状態を保つことです。
この状態を実現するために、最低限押さえる要件は3つあります。
-
一元管理 ：「ここ以外にはない」と言える場所を決めること。同じファイルが複数の場所に存在すると、それだけで混乱が生まれます
-
共同編集 ：同時にみんなでアクセスして編集できること。ローカルでしか編集できないと差分が生まれる原因になります
-
バージョン管理 ：ツールでバージョン管理ができること。いちいちファイル名でバージョンを管理しなくて良い状態を作ります
コミュニケーション管理（フロー）
一方で、コミュニケーション管理とは、プロジェクト内で行われる情報のやり取りの場を作り、関係者が同じ情報を追えるように管理することです。
プロジェクトでは、さまざまなコミュニケーションが発生します。議論、質問、連絡、相談、調整、決議などなど。
こうした流れる情報を、どこで、どのように共有するかを設計します。
ここで重要なのは、みんなが等しく情報の流れが追える状態を作ることです。
そのために必要な要件は、主に次の2つです。
-
統一：ツールを一本化すること。メールとチャットを併用するなど、情報が分散する設計にすると、検索性が下がり、確認コストが増大します。
-
オープン：チーム全員が見える場所でやり取りを行うこと。個別チャットやメールでの意思決定は、後から参照できず、「聞いていない」というトラブルを生みます
ドキュメント管理の手順
まずは、ドキュメント管理がうまくいっていない状態を考えてみます。
- どこにあるか分からない
- どれが正か分からない
- 更新されなくなる
プロジェクトでは「あるある」ですよね…。それに対して、目指す状態はシンプルです。
- すぐに見つかる
- 正しいものだけがある
- 常に更新されている
では、その状態をどう作るか。順番に解説します。
① 格納場所を決める
最初にやることはこれです！
ドキュメントの格納場所を決めること。
すごく簡単なようで、意外と曖昧なまま進んでいるプロジェクトは少なくありません。格納場所が決まってないために、誰かのローカルにファイルがあったり、ベンダがファイルを溜め込むなんてことも、よくあります。
プロジェクトでは、議事録、企画書、要件定義書、設計書など、多くのドキュメントを扱います。何をどこに置くのかを設計せずにプロジェクトを動かすと、自然と分散してしまうものです。
格納場所を決めていくには、まずは格納場所の候補を洗い出します。例えば、こんな感じです。
- 社内ファイルサーバ
- クラウドストレージ（Box、Google Drive など）
- リポジトリ（Git、SVN など）
- Wiki（Confluence、Loop など）
プロジェクトや会社の状況を踏まえて、候補をリストアップしてみてください。ここで最も重要な判断軸は、関係者全員が簡単にアクセスできるかどうかです。
一部の人しかアクセスできない場所を選ぶと、「共有用に別フォルダを作る」という対応が発生します。その瞬間に二重管理が始まり、やがて崩壊するので要注意！
次に検討するのは、「用途ごとに分けたほうが良いか」です。
例えば、次のようなものはメインの格納場所とは分離することを検討します。
- 社外秘情報（権限制御が必要なもの）
- ソースコードや詳細設計（Gitなどで管理する方が効率的なもの）
- TIPSや軽量な情報共有（Wikiの方が適しているもの）
すべてを一箇所に詰め込むのではなく、目的ごとに適切な場所を選ぶことが重要です。
まとめると、次の順番で考えると整理しやすくなります。
- 格納場所の候補を洗い出す
- 全員がアクセス可能な場所を選ぶ
- 必要に応じて用途別のサブ格納場所を設ける
② 運用ルールを作る
格納場所が決まったら、次は運用ルールです。
多くの人が参加するプロジェクトでは、「決めただけ」では守られません。だからこそ、明文化して共有することが重要です。
最低限決めておくことは、次の2つです。
- ドキュメントごとの格納場所
- バージョン管理の方法
まず、どのドキュメントをどこに置くかを一覧化します。これが曖昧だと、要件定義書が複数の場所に保存される、といった事態が発生します。プロジェクト計画書やキックオフの資料などに記載しておくのがおすすめです。
もちろん「要件定義書はここ」などと細かい単位で設計すると管理が煩雑ですし、メンバーからしてもめんどくさいルールでしかありません。なので、次のようにドキュメントをある程度カテゴライズして、そのカテゴリごとに保管場所を決めると良いです。
次に、バージョン管理のルールです。
原則として、バージョン管理はツールに任せましょう！そして、ファイル名でのバージョン管理は絶対に禁止します。
ちなみに、かつては次のような運用が一般的でした。
- 要件定義書_v3_final.xlsx
- 要件定義書_最終_修正版.xlsx
この運用は、似た名前のファイルを量産し、「どれが最新か分からない」状態を生むので非常に危険です。人がバージョンを管理する設計は、必ず破綻するのでやめましょう。
最新版が常に一つだけある。という状態を目指し、その状態をキープし続けることが重要です。
ということで、ルールとしては次の3点を徹底します。
- 最新版は常に1つ
- 過去版はツールの履歴に任せる
- ファイル名でバージョン管理しない
コミュニケーション管理の手順
コミュニケーションも、うまく設計しないとすぐに崩れます。
まずは、うまくいっていない状態を考えてみましょう。
- 情報がいろいろな場所に点在している
- 探し当てるのに時間がかかる
- 人によって見えている情報が違う
プロジェクトでは、これも「あるある」ですよね。というか日常でもよくあることですよね。
コミュニケーション管理で目指す状態は次の通りです。
- 必要なやり取りにすぐアクセスできる
- 情報の流れが一本化されている
- 関係者が同じ情報を共有できている
では、そのための手順を解説します。
① 共通のコミュニケーション場所を作る
最初にやることは、全員がアクセスできる共通の場を用意することです。ドキュメント管理と似てますね。
メインのツールは、チャットベースのものが適しています。例えば、こういったものです。
- Teams の Team
- Slack の ワークスペース
重要なのは、「ここでのやり取りは、関係者全員が見られる」という状態を作ることです。
メールの場合、宛先に入っている人しか内容を確認できません。一方、チャットツールであれば、関係者を全員参加させることで、同じ情報にアクセスできる状態を作れます。
さらに、用途ごとにチャネルを分けることで、情報の追いやすさが大きく変わります。例えば、次のようにフェーズごとにチャネルを分けるなどです。
- 00_全体管理
- 01_企画・要件定義
- 02_設計
- 03_開発
- 04_テスト
- 05_UAT
- 06_リリース
こうやってコミュニケーションの場を作ってあげることで、次のような利点があります。
- 話題が流れにくくなる
- 後から経緯を追いやすくなる
コミュニケーション管理では、ルールよりも先に「場づくり」が重要です。まずは情報が集まる場所を作ることが出発点になります。
② 運用ルールを作る
共通の場を作っただけでは、情報は自然に整理されません。場があっても、抜け道があれば情報は分散します。
そのため、最低限の運用ルールを決めて、可視化・周知していきます。まずは、次の３つをルールとして定めるのがおすすめです。
- メールでのコミュニケーションは原則禁止
- 個別チャットでのやり取りは原則禁止
- 会議チャットでのやり取りは原則禁止
まず、プロジェクト内部のコミュニケーションはチャットに一本化します。メールは原則として外部とのやり取りに限定します。
メールを併用すると、
- どこを探せばいいのか分からない
- CC漏れが起きる
- 情報が検索しづらい
といった問題が発生します。Microsoft製品を使っている場合は、OutlookとTeamsのどっちに情報があるか探すのだけでも手間だし、工数がかかりますよね。そして、メールだと長くなりがちで可読性も悪いです。
次に、個別チャット（1対1やクローズドなグループチャット）でのやり取りも禁止します。
せっかく全員が共有できる場を用意しても、クローズドな場所でコミュニケーションが行われていては意味がありません。やり取りは、必ずオープンなチャネルで行うことを徹底します。
といっても、必ず個別チャットでのやり取りは発生しますので、見つけ次第注意していく感じになります。
さらに注意したいのが、会議チャットの扱いです。
Web会議中のチャットは便利ですが、そのまま継続的なやり取りに使うと、会議参加者しか見られないクローズドな場所になってしまいます。さらに、プロジェクトではたくさんの会議が行われます。その都度、会議チャットが立ち上がるので、情報がどんどん散乱していきます。
会議チャットは会議中のみとし、継続的なやり取りは正式なチャネルに移す。めんどくさいですが、これを行うだけでも情報は集約されていきます。
情報管理は「設計」だけでは足りない！
ここまでで、ドキュメント管理とコミュニケーション管理の手順を解説してきました。
格納場所を決め、ルールを明文化し、場を整える。
ここまでできれば、情報管理は完成したように見えます。
しかし、実際のプロジェクトでは必ず乱れます。100%、情報は散乱していきます。こんな感じに。
- 別の場所に保存される
- 個別チャットで話が進む
- ルールが守られない
これはどのプロジェクトでもそうです。いろんな人が関わるプロジェクトでは、起こって当然。
ここで重要なのは、情報管理は設計したら終わりと捉えないこと。設計した後のフォローが大事なのです！
管理 ＝ 設計 ＋ 運営
情報管理は、
- 設計（構造を決めること）
- 運営（崩れたときに立て直すこと）
の両方が揃って初めて機能します。
例えば、
- 個別チャットで意思決定が行われたら、オープンな場に戻す
- 別の場所に保存された資料があれば、正しい場所へ移す
- 守られにくいルールがあれば、構造を見直す
こうした小さな修正を積み重ねることが大事です。プロジェクトのメンバーはみんな忙しいです。個々がそれぞれのタスクを一生懸命にこなしています。だからこそ、PMがこういった管理を担当し、みんなが働きやすい情報環境を作っていくのです。
ルールは守らせるものではなく、機能させるもの
ルールを厳しくすれば、確かに秩序は保てそうに思えます。しかし、現実はそう上手くいきません。
過度に締め付けるとメンバーは疲弊します。モチベーションも下がります。要は、ルールを守るということは、めんどくさいのです。めんどくさいから、その場の一番楽な選択をしがちです。そして、その選択がルールを破っているケースが多いのです。残念ながら。
なので、大切なのは、ルールを守らせることではなく、情報管理を機能させることです。
そのためには、次のような対応が大切です。
- 情報管理の必要性を説明する
- 必要に応じてルールを調整する
- 例外が出ても基本構造は崩さない
まずは、このめんどくさい管理がなぜ重要なのか？をメンバーにしっかり説明しましょう。押し付けるだけでは人は動きません！
そして、ルールが守られないのであれば、ルールを疑いましょう。現実に即していない、厳しすぎるルールになっていませんか？
プロジェクトやメンバーの状況を考慮して、柔軟にルールを変えていくことも、時には必要です。
最後に、基本構造は崩さないということも併せて重要です。適切にルール変更するのは良いですが、譲れない部分は変えてはいけません。例えば、共有場所を複数に増やしたり、メールでのコミュニケーションを許可したりなどです。
情報管理で扱う「情報」というのは、常に流動的です。だからこそ管理が難しい。でも、諦めずに管理し続けることが、プロジェクトの安定化には欠かせません！
まとめ
この記事では、プロジェクトで情報が散らからないために、PMが行う情報管理の考え方と手順を解説してきました。
改めて、情報管理の目的を振り返ってみましょう。
情報管理の目的
- 関係者全員が 「同じ前提・同じ理解」で動ける状態を作ること
- 情報探索・説明・確認・手戻りといった 認識コストを最小化すること
この目的を実現するために、PMはドキュメント管理とコミュニケーション管理を行なっていきます。そして、忘れてはいけないのが、
管理 ＝ 設計 ＋ 運営
であるということです。
ルールは必ず乱れます。例外も必ず発生します。
そのたびに立て直し、必要であれば構造そのものを見直す。この「設計し、運営し、改善し続ける」姿勢があってこそ、情報管理は機能します。
この情報管理はプロジェクトが終了するまで続きます。特に運営し続けるのは本当に大変です。
でも、間違った情報は間違った結果を生み出します。QCDに大きなインパクトをもたらします。だからこそ、関係者全員がいつも正しい情報にアクセスできるよう、管理し続けることがプロジェクトの成功には欠かせないのです。
NGパターン：失敗しやすいポイント
最後に、情報管理が崩れやすい典型パターンを共有します。
どれも現場ではよくある光景です。「見たことがある」と思ったら、早めに手を打つサインです。
NG① 同じ名前のドキュメントが乱立する
プロジェクト中盤、要件定義も佳境に入った頃に起きがちなパターンです。
要件定義書が複数存在している。しかも、ファイル名は微妙に違うというケースです。こんな感じで。
- 要件定義書_v3.pptx
- 要件定義書_最終.pptx
- 要件定義書_ベンダー提出用.pptx
原因はシンプル。バージョン管理をファイル名で行っているからです。
オンラインストレージ（Box や Google Drive など）には履歴管理機能があります。それにもかかわらず、ファイル名で版数を管理すると、似た名前のファイルが量産されます。
最初は小さな違和感でも、プロジェクトが進むほど混乱は拡大します。古い版をもとに作業が進み、後から差分調整が発生する。最終的にその調整コストを引き受けるのはPMです。
旧来のファイルサーバ運用に慣れているメンバーがいると、この状態は自然に発生しがち。
だからこそ、
- バージョン管理はツールに任せる
- ファイル名でのバージョン管理は禁止する
というルールを明確にし、守られてなければ早めに是正することが重要です。放置すればするほど、修復コストは大きくなります。
NG② 個別チャットが常態化する
定例会で、自分の知らない前提の話が出てくる。
経緯をたどると、メンバー間の個別チャットで話が進んでいた、みたいなケース。
これも非常に多いパターンです。
- 会議チャットでそのまま議論が続く
- 急ぎだからと個別チャットで決めてしまう
一つひとつは小さなことですが、積み重なると情報はとっ散らかっていきます。
その結果、
- 必要な人が必要な情報にアクセスできない
- 情報探索のコストが増える
- 認識のズレが生まれる
そして、その調整のためにPMの工数が削られていきます。
対策はシンプルです。
- 意思決定は必ず共通の場で行う
- 会議後のやり取りは正式なチャネルへ移す
- 個別チャットは補助連絡に限定する
ここも口酸っぱく伝えていくことになりますが、大事なことです！
NG③ ルールだけ作って運用されない
運用ルールを決めることは重要です。しかし、決めただけでは機能しません。
忙しいときやトラブル時には、
- とりあえずチャットで済ませる
- とりあえず手元に保存する
といった行動が自然に発生します。あるあるですよね。だからこそ、ルールは「守られない前提」で設計する必要があります。
PMの役割は、ルールを押し付けることではなく、
- 実際に機能しているかを確認する
- 逸脱があれば立て直す
- 構造に問題があれば見直す
という運営を続けることです。
繰り返しですが、情報管理は、一度決めたら終わりではありません。設計し、運営し、改善し続けるものです。泥臭く続けていくことが、大事な管理です！
関連記事