「なぜあの案件はうまくいって、この案件は炎上するのか」
こう自問したことはないでしょうか。メンバーの能力差や顧客の難しさも、たしかに影響するでしょう。しかし、実は多くの場合、より根本的な問題として「案件ごとに進め方がバラバラで、ベテランの経験に頼り切っている」という状態が挙げられます。
10〜30名規模のIT受託会社でよく見られる光景があります。Aさんが担当した案件はスムーズに進み高い評価を得る一方、同じような規模の案件をBさんが担当すると品質トラブルが続出する。その差の原因を掘り下げると、Aさんは自然と要所要所でレビューを入れている一方、Bさんはそのタイミングを知らない、といったケースがほとんどです。
この記事では、担当者依存のプロジェクト管理から脱却するために、まず整えるべきPM標準プロセスの設計方法を解説します。「大企業がやること」と思いがちな標準化ですが、むしろ小規模のIT受託会社こそ早く整える必要があります。
なぜ小さな組織ほど標準化が急がれるか
「うちはまだそこまでの規模じゃない」と思うかもしれません。しかし、小規模組織ほど標準化のメリットが大きい理由があります。
ベテラン離脱リスクが致命的になる
20名規模の会社で5年以上の経験を持つPMが2〜3名いるとします。その中の1名が退職したとき、その人の「頭の中にあったプロセス」は丸ごと失われます。引き継ぎをしたとしても、暗黙知は文書で伝えきれません。ベテランの流儀を言語化しておくことは、会社のリスクヘッジそのものです。
採用・育成コストが下がる
標準プロセスが存在すれば、新しく入ったPMが「まず何をすべきか」を最短で理解できます。「先輩の仕事を見ながら覚えてもらう」期間が半分以下になることも珍しくありません。
顧客への信頼性が上がる
顧客から見ると、「この会社に頼むと毎回安定した品質で進めてもらえる」という安心感が重要です。担当者によって進め方が変わると、顧客は「次もうまくいくかわからない」という不安を持ち続けます。標準化はそれ自体がセールスポイントになります。
「完璧な標準化」を目指さないことが成功の鍵
標準化を検討した多くの組織が途中で止まってしまう理由の一つに、「PMBOKに準拠した完璧なプロセスを作ろうとする」点が挙げられます。ゼロから全プロセスを設計しようとすると、膨大な時間がかかり、現場から「使いにくい」「実態と合わない」という反発が起きます。
最小限の標準化に必要なのは、たった3点の合意です。
- フェーズゲート：案件をどの段階に分け、各フェーズの終わりに何を確認するか
- 主要成果物：各フェーズで必ず作るべきドキュメントは何か
- レビュータイミング：誰が、いつ、何を確認するか
この3点を決めるだけで、「案件によって進め方がバラバラ」という状態から大きく抜け出せます。
3点合意の具体的な設計方法
まずはフェーズゲートを決める
IT受託開発で最低限設けるべきフェーズは以下の4段階です。
| フェーズ | 主な活動 | ゲートで確認すること |
|---|---|---|
| 受注・計画 | 要件整理、WBS作成、体制確定 | スコープ・予算・体制の3点合意 |
| 開発・製造 | 設計・実装・テスト | 仕様変更の有無、品質状況 |
| 受入・検収 | 顧客テスト、不具合修正 | 受入基準の充足、残課題の確認 |
| クローズ | 引き渡し、振り返り | 顧客満足、社内知識の蓄積 |
すでに似たようなフローで動いている会社も多いはずです。それを「誰もが参照できる形で文書化する」だけでも大きな前進です。
次に各フェーズの主要成果物を決める
「このフェーズが終わったら何が出来上がっているべきか」を定義します。最低限以下の成果物を標準として持てていれば十分です。
- 受注・計画フェーズ：プロジェクト計画書（スコープ・体制・スケジュール・リスク）
- 開発フェーズ：週次進捗報告書、課題管理表
- 受入フェーズ：受入基準書、テスト結果報告書
- クローズフェーズ：振り返り記録（KPT等）
成果物のフォーマットは最初から完璧でなくて構いません。「何があれば次フェーズに進んでよいか」という判断基準の合意が目的です。
進捗管理の実務については進捗管理が形骸化する受託PMへ｜定例で詰まらない3ステップ実行フローでも詳しく解説しています。
最後にレビュータイミングと参加者を決める
「誰が見ればよいか」が曖昧なままでは、成果物を作っても形骸化します。最低限、以下のレビュー構造を定義してください。
- フェーズゲートレビュー：管理職（またはPMリード）＋担当PM。各フェーズ終了時に必ず実施
- 週次進捗確認：担当PM＋チームリード。課題・リスクの棚卸し
- 品質確認（リリース前）：品質責任者＋担当PM。受入基準との照合
このレビュー構造を先に決めておくことで、「誰かが見ているかどうか分からない」という状態がなくなります。担当PMは「次のレビューまでに何を揃えればよいか」が明確になり、行動が変わります。
既存の属人的プロセスを活かした標準化の進め方
いきなり新しいプロセスを導入しようとすると、現場から「今の仕事のやり方と違う」という抵抗が生まれます。まず「一番うまくいっているPMのやり方を言語化する」ことから始めるのがお勧めです。
社内で最もスムーズに案件を進められているPMにヒアリングし、「あなたが案件の最初にやっていることを教えてください」「フェーズが変わるときに何を確認していますか？」と聞くだけで、自然と組織の標準プロセスの原型が浮かび上がります。
これをたたき台として文書化し、他のPMとレビューします。この2ステップが、摩擦が少なく実態に沿った標準化の最短ルートです。
標準化の落とし穴：完成したら終わりではない
プロセスは作ったら終わりではなく、「使いながら更新する」ものです。標準化後に多くの組織が陥る失敗は、「完成したプロセスを変えてはいけない」という固定観念です。
最低限、以下のサイクルを回してください。
- 四半期に1回：「実際に使えているか」を確認する場を設ける
- 案件クローズ時：振り返りで気づいた改善点をプロセスに反映する
- 新しい案件タイプが増えたとき：既存プロセスの適用範囲を見直す
WBSの使い方と同様、プロセスも「作った後の運用」が本質です。WBSは作った後が重要｜進捗管理に使えるWBSと使えないWBSの違いでは、計画と運用の関係について詳しく解説しています。
まとめ：標準化は「完璧さ」より「合意形成」が重要
PM標準プロセスの整備で最も大切なのは、完璧なプロセスを作ることよりも、最低限の3点について組織内で合意形成を図ることです。
- フェーズゲート：案件の区切りと確認事項を全員で共通認識する
- 主要成果物：何が揃っていれば次に進んでよいかの基準を持つ
- レビュータイミング：誰が何を見るかを決め、見ない状態を作らない
「案件ごとに進め方が違う」「ベテランが抜けたら回らなくなる」という状態は、多くの場合この3点の合意がないことが根本原因です。まず最もうまくいっているPMのやり方を文書化するところから始めてみてください。
プロセス標準化を組織全体で進めたい方へ
テックエイドでは、IT受託会社のPM標準プロセス整備支援の相談を承っています。「何から始めればよいかわからない」「作ったプロセスが現場に定着しない」という段階からでも、御社の規模と状況に合わせた整備プランをご提案します。お気軽にご相談ください。