PMとしてリモート案件への参画を検討するとき、真っ先に気になるのは進捗の追い方かもしれません。ですが実際に消耗するのは、リスクや変更が起きた瞬間に「誰に、どう伝えればよいか」が決まっていないときです。標準的なプロジェクト管理の指針には、こうした決め方をあらかじめ文書に書いておく前提が置かれています。この記事では、参画前に確かめておきたい「決め方」の中身を、指針の記載に沿って整理します。

1. PMの案件で、進捗表より先に見るもの

進捗を追う仕事に見えて、詰まるのは「決められない」とき

PM・PLとしてリモート案件に入るとき、真っ先に整えたくなるのはガントチャートや進捗管理表かもしれません。ただ実際に手が止まるのは、進捗の遅れそのものより「これは誰に報告すればよいのか」「この変更は誰の判断で決まるのか」が分からない瞬間です。決め方が曖昧なまま走り出すと、担当者はその都度誰かに相談し、判断が遅れ、結果として進捗表の数字だけが赤くなっていきます。参画前に確かめておきたいのは進捗の追い方よりも、決め方がどこまで用意されているかのほうです。

標準ガイドラインには、管理の側にも計画を作る前提がある

この「決め方を先に用意する」という発想は、個人の心がけの話ではありません。デジタル庁が示す標準ガイドラインでは、管理を担う側が作業の抜け漏れや遅延を防ぐために、年間の活動計画を作成し、周知することが前提として置かれています¹。つまり管理する側にも、あらかじめ計画を立てておく責任がある、という前提です。この標準ガイドラインは政府情報システムの整備・管理について定められたもので、民間の案件にそのまま適用されるわけではありません。ただ「決め方を先に文書へ書いておく」という形が明文で示されている資料は限られるので、自分が入る案件でどこまで書かれているかを測る目安として読めます。参画するPM・PLの立場から見れば、この計画が実際にどこまで作られているかが、案件の見え方を左右する最初のポイントになります。

図の作成：Remogu編集部。デジタル庁「デジタル・ガバメント推進標準ガイドライン」の記載事項を整理したもので、統計データではありません

2. 上げ先が決まっていると、悪い知らせが早く動く

リスクは「顕在時に、どこに、何を伝えるか」を先に書く

標準ガイドラインのリスク管理では、リスクが顕在化した際の報告先や報告する内容、リスクの管理手法などをあらかじめ記載することが求められています²。「何かまずいことが起きたら、まずここに、こう伝える」という道筋が、事が起きる前から用意されている形です。この道筋が無い案件では、リスクに気づいた本人が「誰に伝えればよいか」を探す時間そのものが、対応の遅れにつながります。

課題は「発生時に、どこに、何を伝えるか」を先に書く

課題管理についても同じ発想があります。課題が発生したときの報告先や報告内容、課題の管理手法などを記載することが求められており³、リスクと同様に「誰が拾うか」を事前に決めておく前提です。参画前の面談では、この2つの記載が実際にあるかどうかを尋ねてみましょう。「リスクや課題が出たとき、どなたに、どのタイミングで共有すればよいですか」という質問一つで、決め方が用意されている案件かどうかは見えてきます。曖昧な返答しか返ってこない場合は、参画後にその場を自分で作る心構えが必要になる、というサインです。

上げ先が決まっているかどうかで、参画後の動き方は変わる

同じ「リスクが起きた」という出来事でも、上げ先が事前に決まっている案件と、その都度探す案件とでは、対応にかかる時間も、参画する側の心理的な負担もまったく違ってきます。前者は起きた瞬間に定められた相手へ伝えるだけで動き出せますが、後者は「誰に伝えるか」を自分で判断してから動くことになり、判断のたびに時間と気力を使います。参画前にこの違いを具体的な形で比較しておくと、面談で何を尋ねればよいかが見えやすくなります。

観点	上げ先が決まっている場合	決まっていない場合
リスクへの対応	気づいた瞬間に定められた相手へ報告し、対応が始まる	まず「誰に伝えるか」を考えるところから始まる
課題の扱われ方	担当と対応の期限が決まりやすい	宙に浮きやすく、対応が後回しになりやすい
対応までの時間	事前の道筋どおりに動くため短くなりやすい	相談先を探す分だけ長くなりやすい
参画者の負担	判断の責任を一人で抱えずに済む	「これは自分の判断で伝えてよいのか」を毎回迷う

3. 変更は起きる前提で、手順の側を先に決める

変更管理は「対象・手順・管理手法」を書く対象として置かれている

プロジェクトが進む中で仕様や範囲の変更が生まれるのは、特別な事態ではなく前提です。標準ガイドラインの変更管理では、進捗により発生する変更について、管理の対象、変更の手順、管理手法などを記載することが求められています⁴。つまり「変更が来たらどう扱うか」は、変更が実際に来る前に決めておく項目として位置づけられています。手順が無いまま変更を受けると、その都度「これは誰が決めるのか」を関係者に確認するところから始まり、進捗表よりも先に人間関係の調整で時間が溶けていきます。

変更の可否を、その場の力関係で決めない形にする

手順が文書に無い案件でよく起きるのは、声の大きい関係者の要望が、そのまま変更として通ってしまう状態です。逆に手順が決まっている案件では、変更の申し出がまず記録され、影響範囲の確認を経てから可否が判断されます。力関係で決めるよりも、手順で決めるほうが、参画するPM・PLにとって板挟みになりにくい形です。面談で「仕様変更が出たとき、どの手順を通りますか」と尋ねれば、この案件が力関係で決めているのか、手順で決めているのかが分かります。

図の作成：Remogu編集部。デジタル庁「デジタル・ガバメント推進標準ガイドライン」の記載事項を整理したもので、統計データではありません

4. 「終わったことにする」を防ぐ完了判定

工程ごとに完了判定を挟むという設計

標準ガイドラインの工程管理では、工程ごとに管理手法や完了判定の基準などを記載し、次の工程に進む際には工程ごとに完了判定を実施することが求められています⁷。「終わったつもり」で次の工程に進んでしまうと、後になって前工程の抜け漏れが発覚し、手戻りが発生します。完了判定という区切りを挟むことは、この手戻りを早い段階で見つける仕組みです。

要件定義の不十分さは、後工程の遅延として跳ね返る

中でも要件定義の工程は重い意味を持ちます。標準ガイドラインでは、要件定義がプロジェクトの目標達成にとって重要な工程であり、これが不十分なときには計画の遅延や、情報システムの機能・性能が要求水準に満たない事態などが起きる可能性が高まることが示されています⁶。つまり遅延の芽は、進捗管理を丁寧に行う段階よりも前、要件定義の段階に埋め込まれていることが多いということです。参画時にこの工程がどこまで固まっているかを確かめることは、進捗表を眺めるより先に効いてきます。

工程の入口と出口で確かめること

完了判定は工程の出口だけでなく、入口の状態にも大きく左右されます。前の工程が固まっていない状態のまま次の工程に入ると、出口でつまずくことはほぼ避けられません。参画前には、それぞれの工程で「何が揃っていれば入れるか」「何が揃っていれば出られるか」を、この記載に沿って尋ねてみましょう。工程ごとの入口と出口を具体的に比較すると、完了判定が形だけのものか、実際に機能しているものかが見えてきます。

工程	入口で確かめること	出口で確かめること
要件定義	対象範囲と関係者の合意が取れているか	要求水準と完了判定の基準が文書になっているか
設計	要件定義の内容が引き継がれているか	設計内容の完了判定を誰が行うか決まっているか
開発・テスト	設計書に基づいて着手できる状態か	テストの合格基準と判定者が決まっているか
移行・引き継ぎ	前工程の完了判定が済んでいるか	保存する記録と引き継ぎ先が決まっているか

図の作成：Remogu編集部。デジタル庁「デジタル・ガバメント推進標準ガイドライン」の記載事項を整理したもので、統計データではありません

5. 進め方を変えても、決め方は要る

アジャイルでも、変更管理に基づく見直しを想定した計画を立てる

進め方をアジャイルに変えれば、決め方を用意する手間が要らなくなるわけではありません。標準ガイドラインでは、アジャイルを導入する場合であっても、変更管理に基づいて既に作成された設計書や要件定義の内容を見直すことを想定した計画を立てることが求められています⁸。反復して作るという進め方の違いはあっても、変更が来たときにどう扱うかという決め方そのものは、別の形で必要になるということです。進め方の選択よりも、決め方が用意されているかを確かめる姿勢のほうが変わりません。

記録に残す物と保存期間まで決めておくと、引き継ぎの形が決まる

記録管理では、プロジェクトの実施中に作成する文書やデータについて、保存期間や保存期間が満了したときの措置などを記載することが求められています⁵。何を、どれだけの期間残すかが決まっていれば、参画期間が終わったあとに何を渡せばよいかで悩む場面は減ります。管理の側が年間の活動計画を作成し周知するという前提¹も含めて、記録・計画・完了判定はひとつながりの仕組みとして機能します。掛け持ちで複数の案件に関わる場合や、次の案件へ移るタイミングでも、この記載があるかどうかで引き継ぎにかかる負担は変わってきます。

参画前に確かめる5つの記述

ここまでの内容を、参画前の面談で尋ねる形にまとめます。面談の時間は限られているので、5つの記述それぞれについて「あるか、ないか」「あるなら誰が持っているか」を尋ねるだけでも、案件の決め方がどこまで用意されているかが具体的に見えてきます。次の案件を選ぶときにも、同じ5項目を基準にして比較すれば、参画してから慌てる場面を減らせます。

確かめる項目	尋ねる内容の例
リスクの上げ先	リスクが起きたとき、最初に誰へ、どんな内容で伝えるか
課題の上げ先	課題が出たとき、誰が担当し、どこまでの期限で扱うか
変更の手順	仕様変更の申し出から反映まで、どの順番で進むか
完了判定の基準	工程ごとに何をもって完了とし、誰が判定するか
記録の保存期間	作成した文書やデータを、いつまで、誰が保管するか

図の作成：Remogu編集部。デジタル庁「デジタル・ガバメント推進標準ガイドライン」の記載事項を整理したもので、統計データではありません

6. まとめ

進捗表を整える前に確かめておきたいのは、リスクと課題の上げ先、変更の手順、完了判定の基準、記録の保存期間という5つの記載です。これらは標準ガイドラインが管理の側に求めている項目であり、進め方をウォーターフォールにしてもアジャイルにしても、形を変えて必要になります。参画前の面談でこの5つを言葉にして尋ねられるかどうかが、参画後に「決められない」状態へ陥るかどうかの分かれ目になります。

Remoguでは、案件の90%以上がフルリモート可能です⁹。リモートで参画する以上、廊下で立ち話をして決め方を確認する、という機会は元々ありません。だからこそ、この5つの記載があるかどうかを参画前の面談で言葉にして確かめることが、進捗表を整える以上に効いてきます。

まず気になる案件のページを開き、記載されている管理の体制に目を通してみましょう。そのうえで、自分の経験に合う条件かどうかを判断する材料として、登録して詳細な案件情報に触れてみることをおすすめします。「登録してから探す」のではなく「登録して条件を確かめる」という順番であれば、判断を急がずに進められます。決め方が整っている案件かどうかは、進捗表を見る前に、参画前の一言で確かめられます。

7. よくある質問

決め方が何も書かれていない案件は、参画を見送ったほうがよいか

何も書かれていない状態が、そのまま案件の良し悪しを決めるわけではありません。参画したあとに、リスクや課題の上げ先、変更の手順を自分たちで作っていく余地がある案件もあります。判断の材料になるのは、「書かれていない」ことを伝えたときに、相手がその場で決める姿勢を見せるかどうかです。決める姿勢が見えない場合は、参画後も同じ状態が続くと考えて差し支えありません。

参画前の面談で、どこまで踏み込んで尋ねてよいか

リスクや課題の上げ先、変更の手順、完了判定の基準、記録の保存期間は、いずれも管理の骨組みに関わる質問であり、遠慮なく尋ねて差し支えない内容です。これらは特定の個人を評価する質問ではなく、案件の仕組みを確認する質問だからです。「教えてもらえないと困る」ではなく、「決め方を一緒に整える前提で伺いたい」という聞き方にすると、印象を損なわずに確認できます。

アジャイルの案件でも、同じ確認は要るか

要ります。進め方が反復型になっても、変更をどう扱うかという決め方は形を変えて必要になります⁸。「アジャイルだから決め方は要らない」のではなく、「アジャイルの進め方に合わせた決め方があるか」を尋ねる形になります。反復のたびに設計や要件を見直す前提があるからこそ、見直しの手順そのものを事前に確かめておく意味は、むしろ大きくなります。

管理者としての実務経験の年数がまだ少なくても、PMの案件に参画できるか

年数だけで参画できるかどうかが決まるわけではありません。実際に問われやすいのは、決め方が整っていない場面で、自分から仕組みを提案できるかどうかです。年数が少ない場合は、まず決め方が比較的整っている案件を選び、上げ先や手順の運用を実地で経験することが、次の参画につながる土台になります。まず登録し、自分の経験に近い条件の案件情報に触れてみることから始めてみましょう。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 デジタル庁「デジタル・ガバメント推進標準ガイドライン」第2編第2章 組織体制／PMOの機能（2026年6月12日）
＊2 デジタル庁「デジタル・ガバメント推進標準ガイドライン」プロジェクト管理要領の記載内容（オ リスク管理）（2026年6月12日）
＊3 デジタル庁「デジタル・ガバメント推進標準ガイドライン」プロジェクト管理要領の記載内容（カ 課題管理）（2026年6月12日）
＊4 デジタル庁「デジタル・ガバメント推進標準ガイドライン」プロジェクト管理要領の記載内容（キ 変更管理）（2026年6月12日）
＊5 デジタル庁「デジタル・ガバメント推進標準ガイドライン」プロジェクト管理要領の記載内容（ケ 記録管理）（2026年6月12日）
＊6 デジタル庁「デジタル・ガバメント推進標準ガイドライン」第3編 ITマネジメント／要件定義（2026年6月12日）
＊7 デジタル庁「デジタル・ガバメント推進標準ガイドライン」第3編第7章 設計・開発／設計・開発実施要領（ウ 工程管理）（2026年6月12日）
＊8 デジタル庁「デジタル・ガバメント推進標準ガイドライン」第3編第7章 設計・開発／開発手法（2026年6月12日）
＊9 Remoguサイト公開情報（フルリモート可能案件の割合）