プロジェクト内容
|
Ｘ社はオフィス家具メーカであるが、最近ではオリジナルブランドのＰＣのパターンオーダー販売（カスタマイズ販売）も展開している。今回、オフィス家具についてもパターンオーダー販売を行うことになり、注文用のＷｅｂシステムの開発にかかった。その仕様調整の場面。システム開発はＷｅｂ系を得意にしているＹ社に発注。
そのシステムの仕様フィックスの場面。
登場人物 Ａさん Ｙ社のプロジェクトマネージャー
Ｌさん Ｘ社のプロジェクトマネージャー（情報部門）
Ｍさん Ｘ社のプロジェクトメンバー（家具部門Ａの担当者）
Ｎさん Ｘ社のプロジェクトメンバー（ＰＣ部門Ｂの担当社）
Ａさん（一通り、ドキュメントに基づき、提案仕様の説明）
Ｌさん「Ａさんの方から、システムの機能の提案がありましたが、この内容で問題ありませんか？」
Ｍさん「家具の受注に関しては、先日のお話したことがきちんと反映されていて、この仕様で問題なくできそうです」
Ｎさん「ＰＣの方は、この内容では少し、不十分ですね。前も申し上げたとおり、顧客は他社との比較を重視しますので、他社比較の機能をつけてほしいですね」
Ａさん「インターネットで代表的なＰＣメーカのＷｅｂカタログにアクセスするだけでは不十分ですか？」
Ｎさん「ユーザにしてみれば、どの機種が競合機種かも分からないだろうし、やはり、当社の製品と他社の競合製品とのスペック比較表を提示する機能がほしいですね」
Ａさん「分かりました、その機能については、追加する方向で検討します」
Ｍさん「他社との比較ということであれば、我々の商品でもあった方がいいかな。我々の商品の場合、デザインと価格が勝負なので、いろいろな角度からの写真やイラストで比較できるといいですね」
Ａさん「そうですね、その方がユーザにとってはありがたいでしょうね。ところで、この辺の機能を追加ということになれば、予算と納期を少し、ご検討頂きたいところなのですが、如何でしょうか？」
Ｌさん「予算は検討の余地がありますが、カットオーバーはカスタム家具の受注開始に間に合うことが必須なので、動かすのは難しいですね」
Ａさん「分かりました、予算さえ、押さえていただければ、何とかしましょう。比較機能の具体的な仕様はこちらで検討しますので、Ｍさん、Ｎさんは、どこのどのような機種と競合の設定をするかを検討して、次回の打ち合わせのときに教えてください。」 |
| このプロジェクトの結末 |
予算は増額されたものの、ＰＣ、家具とも、パターンオーダー対応するという以外の製品コンセプトが不明確で、Ｍさん、Ｎさんとも、競合製品をどのメーカのどのＰＣや家具に設定すればよいか分からず、製品コンセプトの設定にまで逆戻りし、手間取った。このため、Ｘ社側の作業の遅れにより、カットオーバーの時期が遅れ、Ｙ社はＸ社にペナルティを支払うことになった。 |
| 問題点 |
・スコープ変更を自分たちの問題としてだけ捉えている |
| 処方箋 |
・ＷＢＳによるスコープの共有
・スコープに影響を与えるものは、当事者であるという意識の徹底
・計画段階におけるスコープ変更の手続きのルール化 |
| 解説 |
ＳＩｅｒのプロジェクトマネージャーがプロジェクトを見るときには、ついつい、自社のことだけ、つまり、作ることだけに目が行く。したがって、プロジェクトマネージャーは、まず、追加作業に必要な予算を確保し、要員のめどをつけ、納期の交渉にかかる。最悪、今回のＡさんの判断のようにお金で片付く問題に落とそうとする傾向がある。
しかし、このケースのようにユーザ側から追加仕様が出てきたときには、注意をすべきである。プロジェクトマネージャーとして忘れてはならないことは、アプリケーション開発はパッケージを作るような作業とは異なり、顧客との協同事業であるということである。したがって、リスクを洗い出すときに、真っ先に考えなくてはならないのは、顧客側の対応である。今回のケースでも一番大きなリスクは予算のオーバーではなく、ユーザ側の対応である。特に、今回のようにシステムの開発を外部のＳＩｅｒにすべて依頼する際には、仕様追加が自分たちの作業の増量になることを忘れがちである。当事者意識がないためである。ここを見落とすと、今回のように仕様変更を受けたのはよいが、結局、納期どおりにできなかったということになる。
本質的な問題の解決方法は、Ｌさんがそのことに気づき、ＭさんやＮさんに仕様決定の前にそれを明示することである。しかし、これが現実には意外と難しい。というのは、Ｌさんもシステム開発にどういう作業が必要かということを知っておく必要があるからだ。
今回のようなプロジェクトの場合、現実的な解決方法はＹ社のＷＢＳの中にＸ社の作業もすべて含めて、Ａさんが一元的に管理していくという方法であろう。ただし、このやり方の難しさは、ＡさんにはＭさん、Ｎさんに依頼することはできても、命令することはできない。したがって、結局はＭさんやＮさんのペースになってしまうリスクはぬぐえない。 このようなリスクを回避する方法としては、Ａさんが、Ｘ社側のプロジェクトのプロジェクトオフィスの機能を引き受け、Ｌさんをうまく立てながら、実質的にＸ社側のプロジェクトを仕切っていくことがもっとも現実的である。また、案件規模によっては、トップ同士の政治的なレベルで開発を図り、プロジェクトのガバナンスをＹ社側に取り込んでしまうという方法もある。
もう少し、大きく捉えれば、仕様変更を受ける際に、目的を再確認した方がよかった。もし、目的を再確認していれば、その時点で、具体的に競合にどのようなものがあるのかという検討は避けることができなくなり、仕様変更決定の前に、問題点が露見していたと考えられる。 |
| ワンポイント |
スコープ管理はみんなの責任！ |
| 参考文献： |
