目次
- どの開発現場でも必要なPM業務と成果物の一覧
- プロジェクト計画書の内容を途中参画者に説明すること
- 新規参画者メンバーに対して実施が漏れやすいもの
- ガントチャートの代替
- 進捗報告書は怒られない程度の品質で良い
- 議事録は作ろう
- 課題管理表でTodoを徹底管理することが炎上しないコツ
- テスト観点と項目は生成AIに相談したほうがよい
- 開発指示書を知ろう
- マニュアル作成についてはこの記事では省略します
- 最後に
①どの開発現場でも必要なPM業務と成果物の一覧
最低でも以下の成果物が必要になります。この記事では作成する際のコツを書いています。
| No. | PM業務 | 必須成果物 |
|---|---|---|
| 1 | プロジェクト管理 | プロジェクト計画書、WBSとガントチャート、進捗報告書、議事録 |
| 2 | 工数管理 | 勤務表、予算管理表 |
| 3 | 成果物の品質管理 | 各種設計書、コード、マニュアル、テスト結果 |
| 4 | ベンダー管理 | 見積書、契約書、工数見積、作業指示書 |
| 5 | 調整・会議 | 議事録 |
| 6 | 問題解決 | 課題管理表 |
②プロジェクト計画書の内容を途中参画者に説明すること
プロジェクト責任者がプロジェクト計画の承認を得るための書類です。
短期間の案件では変更が反映されない場合が多く、知らなくても問題ない内容も多いため、現状を説明するプレゼン資料は別途PowerPointで作成されることが一般的です。
大手日本企業では書式の構造が厳格なExcelで作られることが多いですが、スピード感が求められる現場ではPowerPointで作成されることもあります。
プロジェクトの途中参画者が知るべき内容は以下のとおりです。準備すれば15分ほどで口頭説明できます。
| メンバーの把握事項 | 説明 |
|---|---|
| 1. プロジェクト概要とスコープ | プロジェクトの意義を説明する |
| 2. プロジェクト組織図 | チーム体制と自分のチームメンバーを把握する |
| 3. 各メンバーの役割と責任範囲 | 相談相手や報告先を把握する |
| 4. WBS（タスク一覧） | 全体の流れと自分の関係性を把握する |
| 5. 自分がこれから作る成果物 | アウトプットを把握する |
| 6. 出席する会議 | 出席する会議の内容と参加者の把握 |
| 7. 使う主なツール | Jira／Slack／Notionなどの社内ツールの説明 |
| 8. 注意事項 | NG行動を言語化 ※プロジェクト計画書に記載がない場合が多い ※別途セキュリティ講習を用意している場合がある |
ほとんどの現場では説明が不十分です。
資料を使わずにホワイトボードだけで説明することも多く、情報不足になります。
メンバーとして参画する場合は自分から確認する姿勢が必要です。
知っておいた方がいいが確認が漏れがちなもの
| 項目 | 説明 |
|---|---|
| よく関わる人の業務内容 | 直下3人ぐらいの業務内容しか把握していないマネージャーやリーダーもいます。メンバーが自分で確認する必要があります。 |
| 座席表 | 用意が無い場合は自分で簡単に作成しましょう。実際に自分で書いた方が記憶に定着しやすいという声もあります。 |
| 注意事項 | スーツ必須、生成AIの使用可否、ブラウザ翻訳・ツールの使用、外部メール送信ルールなど |
| 定期報告のルール | 日次／週次／勤怠トラブルの報告ルールと書式について把握しましょう。 |
| 資料の保管場所 | Google Drive, SharePoint, Boxなどの構成、アクセス権限、作業ファイルの保管先なども確認が必要です。 |
| タスク発生の流れ | どこをウォッチすればいいか、最低限確認しておきましょう。 |
③新規参画者メンバーに対して実施が漏れやすいもの
これはマネージャーの職務怠慢とも言えますが、ほとんどの現場で何かしらの漏れが発生します。
参画前に完璧に整えておけば、初動の生産性に大きなインパクトを与えます。
以下のようなチェックリスト形式の表をカスタマイズして使うことで、漏れを防げます。
前の項で紹介した「メンバーの把握事項」もこの一覧に加えておくと便利です。
特に「適用日数」には、申請からどれくらいで利用可能になるのかを事前に調べて記入しておくのが重要です。
| 実施事項 | 申請済 | 実施済みの確認 | 動作確認 | 適用日数 |
|---|---|---|---|---|
| ADアカウント発行 | ||||
| MS365などで特別なライセンスの付与 | ||||
| 社内システムのアカウント発行 | ||||
| Teamsなどチャットの招待 | ||||
| 会議の招待 | ||||
| ツールの申請 | ||||
| ファイルサーバーへのアクセス権限 | ||||
| 開発環境へのアクセス権限 | ||||
| 最初に着手してもらう業務 | ||||
| WBSやタスクメンバーの登録 | ||||
| オンラインでやり取りする関係者への紹介 | ||||
| 現場に慣れるまでのフォローアップの予定を立てる | ||||
| メールのグループ追加 |
理想は、社内情報システム部がテンプレートを用意し、全社的に運用する仕組みです。
このような体制が整っていれば、
- 全社での最適化
- 高品質な表の維持
- 情報のリアルタイム化
といったメリットがあります。
ですが、実際にこの運用ができている企業は極めて少ないのが現状です。
この記事を読んでくださった方が、「これが当たり前」な環境を作っていってほしいと願っています。
④ガントチャートの代替
WBSとガントチャートはプロジェクト計画書の一部ですが、進行中にリアルタイムで修正される性質のため、実務上は別の成果物として扱うことが多いです。
なお、現場では「WBS」と言うだけでガントチャートを含むことがほとんどです。
ガントチャートの主な用途：
- クライアントや上層部への報告資料
- スケジュールの進捗可視化
進捗管理は、ガントチャート以外の手段でも問題ありません。以下は、代替可能な形式の一覧です。
| 表の種類 | 概要 |
|---|---|
| タイムラインビュー | 作業の時系列を可視化し、進捗状況や担当者、開始・終了時期を直感的に把握できる。NotionやAsanaなどのツールで活用される。 |
| ロードマップ | プロジェクト全体のフェーズを俯瞰的に示す横棒形式の表。戦略的な流れを経営層に共有するのに適している。 |
| マイルストーン表 | 重要な納期・成果物を一覧化し、予定日・実績日・ステータスなどで進捗とリスクを可視化できる。 |
これらの表はExcelで作ることも可能ですし、Trello、Jira、Backlogなどのツールにも類似機能があります。
⑤進捗報告書は怒られない程度の品質で良い
進捗報告書は上層部やクライアント向けの資料であり、成果物そのものの品質には影響を与えません。
そのため、以下の3点が簡潔に伝わっていれば十分です。
- プロジェクトが計画通りに進んでいるか
- 課題やリスクに対処できそうか
- 完了予定を数字で説明できているか
書式については会社ごとにテンプレートがあると思うので、ここでは省略します。
大事なのは、「内容を把握しやすく、誤解を生まないレベルの品質であれば問題ない」ということです。
⑥議事録は作ろう
理想的な会議運営の流れは以下のとおりです。
※補足：課題管理表に沿って進行する会議の場合、アジェンダや議事録を省略できる場合もあります。
会議の理想的な進め方：
- アジェンダの作成
-
会議作成（招集）
- アジェンダを添付、または概要欄に記載
- 必須参加者／任意参加者を明確にする
-
アジェンダに沿った進行
- 議題が難しい場合は録画を推奨
- 所定の場所に議事録を格納
議事録が存在しない場合、それはマネージャーの職務怠慢です。
個人的には「アジェンダを加工して議事録とする形式」が最も実用的だと考えています。
議事録の目的は、以下のような情報格差のリスクを減らすことです：
- 会議を欠席した人への共有
- メモが取れなかった人のため
- 聞き逃し・理解不足へのフォロー
- 自分の担当外だと思って気にしてなかったが、実は重要だった場合への備え
つまり、「誰もが情報を見逃さないようにする保険」なのです。
また、録画があっても議事録がある方が圧倒的に早く把握できます。
すべての会議に議事録を残す文化を作ることが、プロジェクト成功の一歩です。
⑦課題管理表でTodoを徹底管理することが炎上しないコツ
課題管理表は、プロジェクト炎上を防ぐ最重要ドキュメントのひとつです。
以下は、よくある項目と、実務上おすすめする構成の一覧です。
| No. | 必須 | 項目名 | 説明 |
|---|---|---|---|
| 1 | 〇 | 管理番号 | JiraやBacklogのチケット番号、Teamsのスレッドなどと連携すると便利。連番は非推奨。 |
| 2 | 〇 | タイトル | 課題名。Jiraなどと一致させると二重管理にならずスマート。 |
| 3 | 〇 | 課題の種類 |
バグ タスクなど、2〜3種に分類。細かすぎると運用が破綻します。 |
| 4 | 〇 | 課題と対応方針 | 課題内容と対応案をセットで記述。 |
| 〇 | 対応結果 | Todo、予定日／実施日、完了内容などを記載。 | |
| 5 | 〇 | 担当者 | 課題責任者、および実施者。複数人の場合は明記。 |
| 6 | 〇 | 状態 |
未対応 対応中 完了 保留など。 |
| 7 | × | 優先度 | 実用性が低い。優先度は状況次第で意味を持たなくなる。Todoごとの期日管理の方が重要。 |
| 8 | × | 開始日 | 原則不要。課題発生日はTodoの内容で把握できるため。 |
| 9 | △ | 期限日 | Todoごとの期日を優先するべきだが、最終期限として参考程度に持つのはあり。 |
| 10 | △ | 備考 | URL、報告書リンク、背景メモなど、自由記入欄。 |
| 11 | × | 見積時間（h） | 必須ではないが、リソース見積もり用途では活用可能。 |
| 12 | × | 実績時間（h） | 時間管理を細かくしたい場合に使用。ただし大半の現場では使われない。 |
🔥 注意点：多くの現場では、工程をすべて課題管理表に落とし込んでいません。
これが炎上の温床になりがちです。
課題管理表に全工程を落とすメリット：
- 全体の進行度合いが見える
- PERT図的な進行管理が可能になる
- ボトルネック工程の可視化
PERT図の基本的な考え方
PERT図は、プロジェクトのタスクを「順序」と「依存関係」で表したものです。
⑧テスト観点と項目は生成AIに相談したほうがよい
例えば、Webアプリにおける総合テスト仕様書作成の際に、以下のように命令してください。
「Webアプリ開発におけるテスト観点を、以下の4つのカテゴリに分けて、それぞれ箇条書きで列挙してください。説明は不要です。カテゴリは (1) アプリ自体、(2) サーバーやネットワークなどの環境、(3) ユーザーインターフェース（UI）、(4) セキュリティ です。」
どんな現場でもテスト項目は偏っているので、人間が見落としていた観点も含めてリストアップできているはずです。
命令文には、[AWS環境のPHPアプリで、リアルタイムなグラフ表示と商品購買機能がある。]など、前提条件を入れるとカスタマイズされた回答が確認できます。
⑨開発指示書を知ろう
ベンダーへの作業指示では以下の内容を伝達する必要があります。
| 項目名 | 補足説明 |
|---|---|
| 開発対象 | - |
| 概要と背景 | - |
| 詳細仕様 | 要件、画面設計、処理ロジック、データ仕様、エラーハンドリングなど |
| 成果物の定義 | ソースコード、テスト結果、ドキュメントの有無など |
| テスト観点 | 納品前のテスト、受入テスト、テストデータの条件 |
| 納期とその理由 | - |
| 環境 | 使用言語、FW、ライブラリ、OS、DBのバージョンなど |
| 注意点・制約事項 | 既存システムへの影響、セキュリティ制約、命名規約、実装ポリシーなど |
| 添付資料（任意） | ER図、画面モック、既存機能仕様書、操作フローなど |
しかし、スピードを重視して上記のように完璧な作業指示書を毎回出している現場は稀です。そのため、作業指示書の基礎を知る機会は意外と少ないです。
外注の開発会社やプログラマーなどと良好なコミュニケーションをするために、以下の点を意識してください。
・開発指示書を作り方について基礎知識をつける
・この指示で伝わるかメンバーに聞いてみる
開発会社への作業指示があいまいな現場では以下の問題が発生します。
・開発会社がバッファを設定して工数と予算が増える
・開発会社からのヒアリングが発生して着手が遅れる
・意図しない開発結果となり手戻りが発生する
開発指示のレベルが上がると、外注や社内メンバーと良好なコミュニケーションを築くことができます。
⑩マニュアル作成についてはこの記事では省略します
ほとんどのマニュアルは、運用チームに必要なものです。開発チーム用のマニュアルも存在しますが、改めて記事にしたほうがいいと思うので省略します。
開発段階での注意点ですが、マニュアル作成をプロジェクト企画段階の予算に組み込むことを忘れないでください。
マニュアルはプロジェクトの後半に完成するものです。新規システム開発案件では、環境構築の手順書について、忘れやすいと思います。
⑪最後に
最低限必要な仕事を徹底することで、質の高いコミュニケーションになります。
プロジェクトに余裕ができれば、信頼されます。
基礎ができたら自分流のマネージメントを研究してください。
タイトルの日付は、私が最後にPMをした日にしました。