今回は、田辺さん（仮名）からの悩みです。
田辺さん 33歳／設計部のエンジニア
うちの会社では、企画と設計、製造を別部門で行っているのですが、どうしても企画部門の力が強くなってしまいます。外部からの受注案件に比べて、社内のプロジェクトは最初から仕様があいまいで、さらに変更要求も多く、そのタイミングもさまざまです。
はっきりしないままずるずると仕事が進み、気が付くと仕様が変更になっていることが多いのです。
そうなると、当初のスケジュールは厳しくなる一方で、追いつめられた挙句、納期遅延になることもあります。どうしたらいいのでしょうか。
回答
なるほど、仕様がずるずると変化していくのは困りものですね。
本件では、２つ大きな問題があるように感じます。
- 仕様変更の承認手続き
- 変更の権限者
「１．仕様変更の承認手続き」については、受注案件である程度うまくいっているのであれば、同じことを社内プロジェクトでも適用する必要があります。
まずは、社内プロジェクトであっても、依頼者は顧客であると考えるのです。
一番肝心な手続きは、文章化です。
変更要求、変更承認、そして変更した場合のインパクト（影響）をしっかりと文章化していくのです。
いただいた内容だと仕様変更の結果、スケジュールにしわ寄せがいっているようですが、スケジュールの変更もインパクト（影響）のひとつです。
変更要求があれば、スケジュールに対するインパクト（影響）も含めて、その変更を実施するかどうかを判断するようにしなければなりません。
次に「２．変更の権限者」の問題です。
どうも企画部門の意向が強く働いているようですが、スケジュールにも響くような仕様変更であれば、プロジェクト全体の責任者（プロジェクトオーナー、スポンサー）の承認が必要です。
企画、設計といった部門の利害を超えて、「全体を統括する責任者」＝「変更の権限者」が承認するようにシステムを変更する必要があります。
加えて、判断のもとになるインパクト（影響）の調査には、リスクも含めてください。
しかるべき責任者が、スケジュールやリスクも含めたインパクト（影響）を承知した上で承認するのであれば、実行する方も納得できるでしょう。
これらの変更を円滑に行うためには、プロジェクト開始にあたり、仕様の変更手続きをどうするかという「変更管理システム」を作成し、関係者と共有しておくことが有効です。
「変更管理システム」の主な要件は次の３つです。
- 変更要求に関する文章のフォーム：インパクト（影響）分析の項目を含む
- 変更の範囲に応じた権限者：会議体の場合もある
- 変更をトレースできるしくみ：記録
「仕様変更は社内社外を問わず、変更管理システムに基づいて実施する」
ぜひお試しください。
