プログラミングなどの作業はベンダが請負ますので、ベンダ内部でプロジェクト管理をしていますが、そのプロジェクトに遅れが出ると困るのは発注者です。また、発注者が担当している作業もあります。それで、双方が出席する進捗会議を頻繁に開催する必要があります。それには、発注者側でもプロジェクトを管理する必要があります。
ここでは、ケーススタディにより、発注者、特に経営者や利用部門がプロジェクトマネジメントの重要性を認識する必要があることを示します。
ケーススタディ（自社カード発行のケース）
- Ａ社は、顧客情報の把握、顧客の固定化が戦略的に重要だと認識して、自社カードを発行することを決定し、顧客や小売店に○○年○月からサービスを開始することを公表しました。
自社カード発行システムの開発が承認され、ベンダを決定し、費用、納期などの契約をして、Ａ社とベンダによるプロジェクトチームが編成されました。
- ところが、Ａ社の企画部門や営業部門などの意見がなかなかまとまりません。このままではサービス開始に間に合わないので、ベンダはここまでにあげられた要件を基にして、見切り発車でシステム開発を開始しました。
- 営業部門では加入者や取扱店の獲得活動を開始したのですが、思ったように進みません。顧客が申込書での個人情報記入欄の記入や、魅力的な特典がないことに不満を持っていることが原因だとされ、クレジットに不可欠な項目だけにして、多様な特典オプションをつけることにしました。取扱店には多様な情報提供をするとか、仕切価格を下げるなどのサービスをすることにしました。
- しかも、それらの交渉にあたった営業部員が、ベンダの担当者に直接依頼して、両社の責任者がそれを知らないこともありました。ベンダはスケジュールがやや遅れていたが、内部努力でカバーできると思いＡ社に伝えませんでした。Ａ社は請負契約をしたのだから、ベンダに任せておけばよいと思い、進捗会議を開きませんでした。
- そのうちに、スケジュールの遅れは深刻な状態になりました。ベンダは、納期延期を提案したのですが、公表したものを変更するのは信用に関わると却下されました。それで、やむを得ずテスト不十分なままに実施に踏み切ったのですが、実施後トラブルが頻発し、大きな問題になりました。しかも、申込書の簡素化により当初計画した顧客情報は得られませんでした。
- この間に費用も問題になりました。責任者の知らない仕様変更が大きな金額になっていたのです。営業部員やベンダ担当者は、費用のことには関心を持っていませんでしたし、まして文書にはしていません。「いった／いわなかった」の水かけ論になってしまいました。
- システム開発の予算をはるかにオーバーしてしまいました。悪い品質のまま実施して大きなトラブルを起こしました。・・・
プロジェクトマネジメントの重要性
このケースを分析すると、次の欠点・対策があげられます。このようなことを解決するのがプロジェクトマネジメントなのです。
- 情報系活動と非情報系活動
カード発行システムを構築する活動を情報系活動、そのシステムに要求する事項の決定や加入者・加盟店との折衝などの活動を非情報系活動とします。非情報系活動が、このプロジェクトの成否に大きく影響を与えているのです。とかく「システム」がつくと情報系活動だとされることが多いのですが、マネジメントの重点はむしろ非情報系活動にあるのだと認識してください。
- 事前の手順計画
このようなトラブルは多いのです。その最大の原因は、サービス開始公表やシステム開発着手以前に要件が確定していなかったことです。要件をまとめるには予期したよりもはるかに時間がかかるのです。顧客情報の把握、顧客の固定化が重要であることは、急に思いつくようなものではなく、かなり以前から問題視されていたはずです。また、顧客や取扱店の反応は、同様なケースからある程度予見できていたはずです。作業手順が間違っていたのです。
- 要求窓口の一本化
仕様追加などでトラブルを起こす原因の一つに、発注者とベンダの担当者間で依頼をして、それが責任者に伝わっていないことがあります。それを防止するために、発注者とベンダが窓口の担当者を決めて、それ以外のルートでの依頼や引受を禁止することが重要です。
「頼んだ／頼まれていない」というトラブルもあります。それを避けるために、すべての打ち合わせ内容を文書化する必要があります。また、それが無償なのか有償になるのかを明確にするために、双方の責任者が押印するなどの手続きが必要です。
- リスク管理
いかに綿密に計画しても思わぬトラブルが発生します。それが、費用を増加させ、納期を遅らせ、品質低下の原因になります。おそらくこのケースでは、ベンダとの契約での見積金額が予算計上されていたのでしょうが、リスクを考慮して適切な額を上乗せしておく必要があります。また、上乗せした金額で開発するかどうかの意思決定をする必要があります。
- 進捗会議（コミュニケーション）
トラブルの種を早期に発見して対処することが必要です。顧客や取扱店の要求について、早期に気づけばシステム開発着手を遅らせて手戻りをある程度防げたはずです。担当者への直接依頼などは最初に報告されれば直ちに対応できたはずです。いかに請負契約だといっても、プロジェクトを成功させるためには緊密なコミュニケーションを図ることが必要なのです。
ベンダは、このようなプロジェクトを多く経験している専門家なのですから、これらのトラブルが起こらないようにする責任があります。しかし、ここでのトラブルの主原因は、システム構築そのものの問題ではなく、発注側、特に非情報系活動を行う部門がプロジェクトマネジメントを理解していないことにあります。
プロジェクトマネジメントは関係者が共通する認識があって成立するのですから、経営者や利用部門がプロジェクトマネジメントの知識を持つことが望まれます。
プロジェクトマネジメントの進め方やそれに必要な知識体系に関する国際標準に、ＰＭＢＯＫ（The guide to the Project Management Body of Knowledge：プロジェクトマネジメントの基礎知識体系）があります（「プロジェクトマネジメントとＰＭＢＯＫ」）。ＰＭＢＯＫは、ベンダやＩＴではよく知られていますが、経営者や利用部門では名前すら知られていないのではないでしょうか。