プロジェクト内容
|
今回は物語風に内容設定をしてみる。
ＳＩｅｒ Ｍ社
登場人物 Ａ課長、Ｂ主任、Ｃさん
ある引き合い案件のプロジェクトマネージャーの選定について、Ｂ主任がＡ課長に相談している場面。
Ｂ主任「Ｘ社から引き合いのあった「自社サイトのＣＯＩ (Community of Interest）の案件」ですが、営業のＰさんからの情報ではほぼ、当確です。誰に担当させましょう？Ｘ社との取引は始めてなんで、経験者がいいと思うのですが、Ｗｅｂサイト開発の主担当のＤ君はＹ社の案件で手一杯だし、Ｅ君もＷ社の案件で一杯です」
Ａ課長「どのくらいの規模なの」
Ｂ主任「せいぜい、３人で３〜４ヶ月といったところでしょう。技術的にもわが社で経験しているものですし、初めての取引先だという以外は、あまり心配要素はありません」
Ａ課長「Ｘ社ってどんな企業なんだ？」
Ｂ主任「外資の食品メーカです。エンタープライズのシステムはＩ社ががっちり抑えていて入り込む余地はありそうにないです、これからお付き合いを始めるとしても、Ｗｅｂ系で、日本だけのお付き合いまでだと思います」
Ａ課長「じゃあ、わざわざ、ＤやＥを担当させることはないじゃないか、３〜４年目の社員に、ＰＭの経験をさせるのを兼ねてやらせてはどうかね？誰か適当なのはいない？」
Ｂ主任「そうですね、ちょうどそのくらいの年代で、Ｗｅｂに詳しいのは、、、Ｃ君が適任ですね。彼は入社以来、ずっとＤ君の下で、Ｗｅｂサイトの開発に従事しているし、まあ、若い中では人望もあります。」
Ａ課長「そうだな、Ｃにしよう。まあ、多分、大丈夫だと思うが、念のために、Ｄにいざとなったら火消しをやってくれと頼んでおけよ」 |
| このプロジェクトの結末 |
Ｘ社の社内で、コミュニティの位置づけに対する意見がまとまらなかった。ある部門は自社製品の情報提供以外には、健康などの特定の問題に対する情報の提供にとどめるべきだというし、また、ある部門はもっと積極的にユーザの声を吸い上げるような仕組みが必要だと主張している。今回のＷｅｂ開発の直接の窓口になったシステム部門は、ただ、これらの部門の意見をすべて入れようとするだけで、どんどん、仕様が膨らんでいった。
プロジェクトマネージャーに指名されたＣさんは、彼らの言い分がよく分からず、結局、Ｘ社の言うがままの対応となり、プロジェクトは大幅な赤字を出し、赤字分はＭ社の負担となった。また、納期については、Ｘ社の了解は得られたものの、当初の４ヶ月を大幅に超え、６ヶ月を要した。 |
| 問題点 |
・ＰＭの選定が不適切
・ＰＭの選定者が現場を知らない |
| 処方箋 |
・プロジェクトの難易度評価基準の明確化
・プロジェクトの難易度に応じたＰＭ選定方法の確立 |
| 解説 |
最近ＣＯＩ (Community of Interest）の案件というのが増えてきている。一つのサイトの中に、インタレスト（興味）に応じたコミュニティを複数準備し、それによって、サイト全体への集客力を増そういう戦略に基づくものである。特に、ネットビジネスにおけるコミュニティスキルの重要性の認識はどんどん高まってきている。興味がある方は、最近、面白い本が出版されたので、ぜひ、お読みください。
ネットコミュニティビジネス入門―ネットビジネスの成功の鍵はコミュニティ・スキルの有無にあり
さて、今回の話はそのＣＯＩの話であるが、システム開発プロジェクトの難しさを何で図るかというのは難しい議論であるが、ＣＯＩの構築は技術的にはそんなに難しいものではないし、システムそのものも複雑なものではない。スケーラビリティを配慮したアーキテクチャーの設計と、ユーザビリティの設計が技術的なポイントであるが、そこをクリアすれば何とかなると考えてもよいだろう。プロジェクト規模（開発規模）も、基幹系のように大きなものではない。技術的に見た場合には、それだけのプロジェクトである。
今回のケースでは、プロジェクトの難しさを規模、技術、顧客だけで判断している。業務系のシステム開発では、ＢＰＲが入る場合も含めて一応、業務の常識的な流れというのは決まっており、また、経理であれば経理部門というように、関連する業務部門も限られている。それゆえに、開発規模、適用する技術、顧客要求の厳しさでプロジェクトの難しさを考えればおおよそあたっていた。
これに対して、ＣＯＩのようなＷｅｂ系のプロジェクトや、情報系のプロジェクトでは、まず、一つのシステムに関連する部門が多いケースが多い。特にＥＩＰ（Enterprise Information Portal）のようなポータルでは、システムの規模そのものは決して大きくないが、ＥＲＰ（Enterprise Resource Planning）並みの関連部門が出てくる。これらはプロジェクトにとってすべて「ステークホルダー」になる。ステークホルダーが多くなれば多くなるほど、プロジェクトの推進のための調整事項が増え、プロジェクトの難易度は高くなる。ステークホルダの多さは、規模の大きさ、あるいは、適用技術の難しさなどと較べて、勝るとも劣らないプロジェクトを難しくする要因である。
このようなリスクを回避しようと思えば、社内でプロジェクトの評価の基準を明確にし、その評価にあわせたＰＭの評価・選定の方法をルール化することが不可欠である。ただし、その際に注意すべきことは、短絡的に人事評価の仕組みと連動させないことである。その企業の現実の活動が、ビジョンや戦略と整合している理想的な場合を考えれば人事評価とＰＭの評価は連動していることが望ましい。しかし、現実にはそのようなビジネスが展開できている企業は珍しく、下手にやると、モラルの低下と、パフォーマンスの破綻を引き起こすだけである。 |
| ワンポイント |
プロジェクトの本質はステークホルダにあり |
| 参考文献： |
