「前任者から引き継いだフォルダに、500件のファイルが入っていた」
大げさな話に聞こえるかもしれませんが、受託開発の現場ではよくあることです。要件定義書・設計書・議事録・メール・課題管理票・テスト結果……1年以上稼働しているプロジェクトであれば、それだけの資料が積み重なっています。
新任PMがここで間違えるのは「全部読もうとする」ことです。全部読もうとすると時間が溶けて、動き出しが遅れます。そして実際には半分以上の資料は「今の自分の仕事に関係がない」ものです。
この記事では、初月に何を読むべきで何を後回しにしてよいかを整理します。
資料を全部読むPMほど初動が遅れる
資料を丁寧に読み込んでから動こうとするのは誠実な姿勢ですが、PMとしては必ずしも正しくありません。
理由が2つあります。
1つ目は、プロジェクトは今も動いているということ。読んでいる間にも課題が積み上がり、顧客との連絡が滞り、メンバーは判断を待ち続けています。
2つ目は、古い資料は現在の状態を正しく反映していないことが多いということ。更新されていない設計書、決定が変わった後の議事録、キャンセルされた機能の仕様書——こうした資料を読んでも、現在の状態は分かりません。
読む順番を間違えると「昔の情報を元に判断してしまう」リスクもあります。
最初に読むべき資料
初月に最優先で確認すべきは「今の状態」を把握できる資料です。
1. 最新のWBSまたは進捗管理表
現在どこまで進んでいるか、どこが遅れているかを一番早く把握できる資料です。古いバージョンが複数ある場合は、最後に更新された日付のものを選んでください。
2. 直近1〜2ヶ月の議事録
直近の会議で何が決まり、何が保留になっているかを把握します。全期間の議事録は読まなくてよいです。直近に絞ることで「今の論点」が見えてきます。
3. 課題管理票（オープン中の課題のみ）
解決済みの課題を読む時間はありません。現在オープン中の課題だけに絞ってください。課題の内容・担当者・期限を確認するだけでも、何が止まっているかが分かります。
4. 顧客との直近のメールやチャット
顧客が今何を気にしているか、感情的にどういう状態かは、定型の議事録には出てきません。直近のやりとりを確認すると、顧客の温度感が分かります。
5. 契約書または契約概要（スコープと納期）
どこまで作ることが合意されているか、いつが納期かは必ず押さえます。特に途中参加の場合、口頭で伝わっていることと契約が違うケースがあるため、原文を確認するのが基本です。
後回しでよい資料
以下は「いつか読むべきだが初月に急がない」資料です。
要件定義書・基本設計書
現在の実装と合っていないことが多い。読むとしても「今困っている部分に関係する箇所だけ」で十分です。
テスト仕様書・過去のテスト結果
今テストフェーズでなければ後回しでよい。テストフェーズが近づいたときに確認します。
プロジェクト計画書（初期版）
当初の計画は変わっていることがほとんどです。現在の進捗と見比べる目的以外では、読む優先度は低いです。
メール・チャットの全履歴
2年前の意思決定の背景を最初から追う必要はありません。「なぜこの仕様になっているか分からない」という疑問が出たときに遡る使い方で十分です。
読む順番を間違えると起きるリスク
古い設計書から読んだせいで、すでに変更済みの仕様を正として動いてしまう——これが一番多い失敗です。現在の状態を把握してから過去の経緯を追う順番が正しいです。
また、全部読もうとして動き出しが遅れると、メンバーや顧客からは「PMが不在の状態」として受け取られます。資料を完全に理解してから動くのではなく、必要最低限を把握したらまず現れることが大事です。
初月の資料棚卸しテンプレート
引き継ぎを受けた日から1週間以内に、以下の整理をしておくと後の作業が楽になります。
| カテゴリ | ファイル名 | 最終更新日 | 今月確認が必要か |
|---|---|---|---|
| WBS | ○ | ||
| 直近議事録 | ○ | ||
| 課題管理票 | ○ | ||
| 顧客メール | ○ | ||
| 契約書 | ○ | ||
| 要件定義書 | 任意 | ||
| 設計書 | 任意 |
「任意」の資料は、疑問が出たときに参照するものとして分類しておけばよいです。
最初の1ヶ月で「作らなくてよい文書」を判断する
途中参加PMが最初の1ヶ月で最も避けるべき失敗は、「必要のない文書を一から作ること」です。既に存在する文書を確認せずに新しく作り始めると、二重管理が生まれ、チームの混乱につながります。
最初の1週間で「既存の文書は何か、どこにあるか」を把握することを最優先にしてください。既存の文書を把握した上で、「不足している文書」だけを作成する判断ができます。
文書の「オーナー」を明確にする
複数の文書が存在するプロジェクトでは、各文書の「オーナー（管理責任者）」が不明確になりやすいです。文書のオーナーが決まっていないと、更新が止まり、気づいたら古い情報のままになってしまいます。
途中参加PMとして最初の1ヶ月で行うべきことの一つは、主要文書のオーナーを確認・設定することです。「この文書は誰が更新する責任を持つか」を明確にすることで、文書管理が仕組みとして機能し始めます。
情報の「鮮度」を管理する習慣
プロジェクトの文書は作成日時と最終更新日時を必ず記録してください。古い情報が最新のものとして扱われることは、誤った判断の原因になります。
月1回、主要文書の「最終更新日時」を確認する習慣を持つことで、情報の鮮度を管理できます。3ヶ月以上更新されていない文書は、内容が現状を反映しているか確認し、必要に応じて更新または廃止してください。文書管理の仕組みを持つことが、長期プロジェクトの情報管理の品質を維持します。
文書をチームのコミュニケーションに活用する
作成した文書を「保管するだけ」にするのではなく、定例会議や個別ミーティングで積極的に参照する習慣を持ってください。文書を会議のたびに参照することで、チームの共通認識が維持され、「以前に合意したこと」を確認するコストが下がります。
定期的に文書を参照するチームは、議論の質が高くなります。「以前この文書で合意しましたが、この状況はどう扱いますか？」という問いかけが、的確な意思決定を促します。
「情報の一元化」がプロジェクトを救う
プロジェクトの情報が複数の場所に分散すると、「あの情報はどこだっけ」という検索コストが日常的に発生します。途中参加PMとして最初の1ヶ月でやるべきことの一つが、情報の一元化の仕組みを作ることです。
「プロジェクトに関する情報はここを見れば全てわかる」という場所（Notionのトップページ、SharePointのサイト、Confluenceのスペースなど）を1か所作り、チームに周知することで、情報の分散問題を解消できます。
文書のバージョン管理を最初から整える
文書のバージョン管理が整っていないプロジェクトでは、「どのファイルが最新か」という問題が頻繁に発生します。ファイル名に日付を付けることで最新版を管理するのが現実的ですが、「YYYYMMDD_文書名.xlsx」という命名規則を最初から設定することで、混乱を防げます。
クラウドストレージ（OneDriveやGoogle Drive）の「バージョン履歴」機能を使えば、ファイル名での管理が不要になります。ツールの機能を活用してバージョン管理の手間を減らし、最新版の特定を確実にする仕組みを最初から整えてください。
PM実務の全体像を学ぶ
途中参加PMが身につけるべき実務スキルは、以下の講座・パックで学べます。