CMS構築におけるプロジェクト管理について～コロナ禍におけるリモートワーク下で重視すべきこと～

要件定義は、お客様に風呂敷を広げてもらって、それをお客様の合意のもと畳んでいくフェーズで、プロジェクトの先行きを決定する最も大事なフェーズです。
CMSを導入してやりたいこと（＝業務要件）、また、CMSでどうやって実現していくか（＝システム要件。機能要件・非機能要件・移行要件・運用要件などにも分けられる）は、CMSというキーワードによって、その進め方をある程度、共通化することができます。
基本的な進め方の流れを「CMS要件定義プロセス」としてあらかじめ決めておき、個々の案件、管理するコンテンツ要件などに合わせて、進め方をカスタマイズしていきます。
何事も、ゼロベースから考えるより、前例やサンプルを元に考えるほうが安全だし確実、効率的というわけです。

レビューとは品質管理プロセスの一環で、成果物に対して「検証」することです。
食べログなどでレビューというと「評価」や「感想」ですが、プロジェクト管理上でのレビューとは、後々の不具合や課題にならないように「検証」すること。ウォーターフォール開発では次工程に入って良いかの妥当性の「検証」です。（食べログのレビューより「重い」イメージです）

レビュー管理プロセスとして決めることは以下の通り。

テストも品質管理プロセスの一環です。

テスト管理プロセスとして決めることは以下の通り。

「この仕様は設計上は曖昧だけど、テストで不具合として出せばいいや」という考えがあります。これはプロジェクト管理側としては是正してほしい考え方です。
プロジェクト上の問題は、後になるほど対応のコストがかかると言われています。設計を見直すのであれば、設計者とレビュアの工数だけで済みますが、テストフェーズの不具合として設計バグが見つかると、多くの「手戻り」コストが発生します。お客様の手元に渡った後、またサービスインした後に発覚すると、より多くのコストがかかってきます。
「検査」での発見に頼るのではなく、なるべく「予防」をすることが大事です。

「上長から追加の仕事を振られたので残業しないと終わらない。一方で上長に残業を削減せよと指示される」という「あるある」をよく聞きます。
PMからメンバーへの指示に関しても同じことを思う人が多いと思います。
まず「定時内に追加作業を行う工夫はできないか」を作業者本人と相談して検討することが第一です。その上で、QCDのどれを優先するかを考え、別の担当者をアサインするか、本人の稼働を上げて対応させるか、明日の作業に回すか、などの方針を決めます。
残業するかしないかの裁量権は、基本的にPMにあることを、PM自身も認識し、メンバーにも認識させることが大事です。

プロジェクトメンバーにとって「自分の行うべきタスクが分からない、不明確」なことは、大きなストレスになると思っています。また、タスクが曖昧な故に、蓋を開けたら何もできていませんでした、という事態に陥ることは、プロジェクトにとって大きな損失です。
WBSは、少なくとも次フェーズの分は詳細タスクに落とし込んでおくこと。目安としては、2ヶ月先まで詳細化しておけば安心、というのが私の考えです。
作業計画をきっちり立てれば、あとはそれに沿っているか、課題が無いかをチェックしていく。
またプロジェクトは生き物なので、最初に立てたWBSを臨機応変に修正すること。プロジェクトの大日程・マイルストーンに影響しない範囲であれば、個々のタスクは臨機応変に入れ替え・修正していくべきだと考えます。