トップページ>プロジェクト管理>仕様変更を防ぐには？
前置き
1.企画・検討
仕様変更を先に防ぐ
商品の特徴を把握できているか？
かけるコストと狙うべき目標地点を定める。
2.計画
仕様変更を先に防ぐ
開発対象に技術的に実現難易度の高いものはあるか？
仕様変更時には、営業担当もしくは顧客側の意見に近い人物の合意を得る。
仕様変更を出すタイミングを制御する
機能や操作UIが狙い通りであることを確認できるタイミングはあるか？
3.開発・評価
仕様変更を先に防ぐ
仕様変更の繰り返しを防ぐ
仕様変更の目的・意図を明確か？
営業関係者との合意の有無を確認する。
小さな変更でもステークスホルダーに触ってもらう機会を作る。
仕様変更発生に制限をかける
仕様変更の受け入れ可能なスケジュールを提示する。
作業可能な工数を明確にする。
変更にかかるコスト、変更による影響を明確化する。
仕様変更の影響を軽くする
代替案を検討する
前置き 
ソフトウェア開発では仕様変更は必ずどこかで発生する。
仕様変更の発生と対処そのものは、より良いものを開発するには必要な要素だが、
大半は先に検討していれば計画時に考慮できているものが多いと考える。
発生そのものを少なくする、発生時期を制御する、発生した後の影響を抑えるといった観点で、
仕様変更に対処する方法を考えていく。
仕様変更を防ぐことについて、誰がどの役割の人間に対して働きかける内容か、
実体験をもとにまとめていく。
仕様変更の発生と対処そのものは、より良いものを開発するには必要な要素だが、
大半は先に検討していれば計画時に考慮できているものが多いと考える。
発生そのものを少なくする、発生時期を制御する、発生した後の影響を抑えるといった観点で、
仕様変更に対処する方法を考えていく。
仕様変更を防ぐことについて、誰がどの役割の人間に対して働きかける内容か、
実体験をもとにまとめていく。
1.企画・検討
仕様変更を先に防ぐ
商品の特徴を把握できているか？
営業との意見交換、要望の吸い上げ。
競合に勝てるポイントを抑える。
ターゲットとなる客層・特徴を抑える。
→上記をステークスホルダー間で共有する
競合に勝てるポイントを抑える。
ターゲットとなる客層・特徴を抑える。
→上記をステークスホルダー間で共有する
かけるコストと狙うべき目標地点を定める。
そもそも仕様変更を受けるべきプロジェクトかどうかを決める。
商品特性上、コストをかけずに開発したい、とにかく期間を短くしたい、などの狙いがある。
最も優先順位の高い要求事項を洗い出し、仕様変更そのものを受け付けない前提を立てることも必要。
商品特性上、コストをかけずに開発したい、とにかく期間を短くしたい、などの狙いがある。
最も優先順位の高い要求事項を洗い出し、仕様変更そのものを受け付けない前提を立てることも必要。
2.計画
仕様変更を先に防ぐ
開発対象に技術的に実現難易度の高いものはあるか？
誰が、いつ、どの範囲で実現性の検証をおこなうかを決める。
事前に洗い出せた制約事項が後に残ってしまうことがないようにする。
事前に洗い出せた制約事項が後に残ってしまうことがないようにする。
仕様変更時には、営業担当もしくは顧客側の意見に近い人物の合意を得る。
担当者に閉じた仕様変更を発生させないようにする。
より顧客目線に近い仕様を取り入れるようにする。
より顧客目線に近い仕様を取り入れるようにする。
仕様変更を出すタイミングを制御する
機能や操作UIが狙い通りであることを確認できるタイミングはあるか？
開発途中のリリーススケジュールを策定する。
どのリリースで何の機能が出来上がるかを明確にする。
リリース毎にステークスホルダーに確認してもらう期間を取る。
→開発プロセスの定義にも関わる。環境面(メンバー、情報共有方法、利用ツール、etc)の検討にも影響。
どのリリースで何の機能が出来上がるかを明確にする。
リリース毎にステークスホルダーに確認してもらう期間を取る。
→開発プロセスの定義にも関わる。環境面(メンバー、情報共有方法、利用ツール、etc)の検討にも影響。
3.開発・評価
仕様変更を先に防ぐ
仕様書の読み込み時間を確保し、不明点の洗い出しを先におこなう。
→当たり前だけど、まともま仕様書が作成されることがなかったり、
進めながら定義していくプロジェクトも多々ある。
情報の残し方、作り方を定義し、合意を得ることが大事。
ステークスホルダー間での共有内容・意識・狙いをメンバーにも浸透させる
→早期に仕様矛盾、不備、改善の発信につなげられるだけの情報を共有する。
→当たり前だけど、まともま仕様書が作成されることがなかったり、
進めながら定義していくプロジェクトも多々ある。
情報の残し方、作り方を定義し、合意を得ることが大事。
ステークスホルダー間での共有内容・意識・狙いをメンバーにも浸透させる
→早期に仕様矛盾、不備、改善の発信につなげられるだけの情報を共有する。
仕様変更の繰り返しを防ぐ
仕様変更の目的・意図を明確か？
こちらから問いかけることで、本当に顧客目線で必要なものかどうかを見直す。
→特定のステークスホルダーの想いだけで生まれる変更もある。
それが理にかなうものなのか、精査する機会が必要。
→特定のステークスホルダーの想いだけで生まれる変更もある。
それが理にかなうものなのか、精査する機会が必要。
営業関係者との合意の有無を確認する。
ステークスホルダー同士での合意のものなのかを確認する。
→承認ルートを確定させておくべき。
→承認ルートを確定させておくべき。
小さな変更でもステークスホルダーに触ってもらう機会を作る。
仕様変更を受け入れたとしても、それが望みどおりのものなのかは確認が必要。
仕様変更発生に制限をかける
仕様変更の受け入れ可能なスケジュールを提示する。
前向きに対処できる期間を明示することで、その時期に向けて先に検討してもらう。
作業可能な工数を明確にする。
仕様変更と引き換えに他の何かを削る、もしくは別の制約条件をかける、などの、
天秤にかける情報を開示する。
→こちらの余力を見せることは、相手によっては逆効果にもなるので注意。
時間が空けば、本当に必要でないものでも追加したくなるケースもある。
天秤にかける情報を開示する。
→こちらの余力を見せることは、相手によっては逆効果にもなるので注意。
時間が空けば、本当に必要でないものでも追加したくなるケースもある。
変更にかかるコスト、変更による影響を明確化する。
変更がかけるコストにみあったメリットがあるかを明確にし、再度実現すべきかどうかの問いかけを行う。
仕様変更の影響を軽くする
代替案を検討する
目的を満たすためのほかの方法がないかを提案する。
コストメリットがあり、かつ不安要素の少ない方法が提示できればベスト。
→現実的には難しい。次の機会があるのであれば、VerUpで対応などの手段も可能。
コストメリットがあり、かつ不安要素の少ない方法が提示できればベスト。
→現実的には難しい。次の機会があるのであれば、VerUpで対応などの手段も可能。
コメントをかく