ユーザー企業がソリューションプロバイダから提案書を受け取り評価する際に、7つの視点がある。今回はそのうち、「計画の妥当性」と、ソリューションプロバイダが提案の中で最も強調すべき「プロジェクト遂行能力」について説明したい。
ソリューションプロバイダの提案書に記載している開発スケジュールは、ユーザー企業にとって比較評価しやすいところである。そして「計画の妥当性」の観点から評価すると、十分に検討して作成しているとは思えない提案書が多い。とりあえず、開発着手日とユーザー企業のシステム稼働開始希望日をスケジュール表にプロットし、各工程の作業比率や期間比率から着手日と稼働開始日の間を埋めているところが多い。
要件定義と基本（概要）設計、基本設計と詳細設計の各工程は基本的には重なってはならないはずで、前の工程での定義や仕様が確定し、ユーザーの検証を受けた上で、次の工程に進まなければならない（図1）。多くの場合、要件定義工程のみでいったん契約を区切るため、基本設計工程とのダブリは生じないはずだが、まれに重複を発見したりする。
 |
| 図1●望ましい開発スケジュール [画像のクリックで拡大表示] |
また、要件定義工程は十分な作業期間をとるべきである。ユーザー企業の業務内容の理解や現行システムの理解にはかなりの時間がかかり、要件の確認にも時間を費やす。ユーザー企業も意思決定に時間がかかることも多いので、配慮が必要である。
筆者が選定にかかわったソリューションプロバイダは、総合評価が高かったため受注することができたが、要件定義工程が競合よりもはるかに短かった。選考会で指摘した際には大丈夫とのことであったが、作業が始まると結局、競合の提案と同じ期間を要してしまい、ユーザー企業に迷惑をかけた。ソリューションプロバイダは各工程での作業内容をボリューム的に再確認するとともに、自社のペースで作業ができるものと、ユーザー企業のペースで作業を進めなければならないものとがあることを、もっと認識すべきだろう。
基本設計と詳細設計、詳細設計と開発、開発とテスト工程は一部期間を重複させることは可能ではあるが、どの部分が問題なく並行して作業できるかを十分判断した上で重複期間を設けるべきであろう。特に基本設計は完了するまでに、データベースやテーブルなどの変更が数多く発生することから、その完了を待って詳細設計を開始することが望ましい。
現行システムが存在し、データ移行が必要な場合、スケジュールが十分ではないことが多い。データ移行に当たっては、現行システムの調査・分析が必要である。また、新システムにデータを移す際にも、各種変換作業や編集処理などが必要になる。場合によっては現行システムのデータの重複や欠落、エラーなどを修復する必要もあり、ユーザー企業にデータを再入力し直してもらうことも必要かもしれない。
ソリューションプロバイダは受注後、必要になったら検討するつもりであるのかもしれないが、ユーザー企業にとっては非常に重要な作業である。筆者は提案書の評価をするたびに、ソリューションプロバイダとユーザー企業の認識の差に驚かされる。しかもソリューションプロバイダは、データ移行の多くの部分をユーザー企業側で作業するものと決めつけているところがある。実際には、詳細の作業スケジュールを作成する中で、データ移行の分担を明確にする必要がある。提案書の段階では、たとえユーザー企業主体の作業であれ、十分検討してスケジュール上に表現すべきである。ユーザー企業に作業してもらうつもりであれば、それを明確に表記しておくべきであろう。多くのユーザー企業が、データ移行についてソリューションプロバイダに相当な期待をかけているからである。
このほか、テスト期間と並行稼働期間の妥当性も評価の対象である。リスクヘッジとしてテスト期間を膨らませている提案書もあるが、ユーザー企業が分かってしまう場合が多いので要注意である。並行稼働させるかどうか、どのくらいの期間実施するかも重要な要素。競合と差異化できる提案書を作成したいのであれば、こうしたことにも配慮が必要である。
データ移行や並行稼働については、ソリューションプロバイダだけでは決められない要素が非常に多い。やはりユーザー企業から情報を入手する必要がある。ユーザー企業に質問を入れたり、ヒアリングを実施したりすることにより、競合をしのぐ提案書を作成することが可能になるのである。
プロジェクト遂行能力のかなめはPMの資質
次に「プロジェクト遂行能力」であるが、ITRはソリューションプロバイダ選定の際に、このプロジェクト遂行能力に大きな比重を置くべきだと考えており、ユーザー企業もその重要性を認識し始めている。プロジェクト遂行能力の中でも特に重要なのが、プロジェクトマネジャー（PM）候補者の資質である。提案書には必ずPM候補者を明記してもらい、そのPM候補者にプレゼンを行ってもらう必要がある。
PMの資質の中でも、筆者が最も重視するのがコミュニケーション能力であり、この能力がプロジェクトの成否の鍵を握っていると考えている。PMの大きな役割は下とのコミュニケーションだけでなく、上や横、斜めといった幅広いコミュニケーションが必要になる。コミュニケーション能力には、単なる会話能力だけではなく、相手の有言無言の様々な情報発信を感知したり、裏を読み取ったりする能力も含まれる。
ソリューションプロバイダによっては、提案段階ではPM候補者名を出さず、能力面での保証をするところもあるが、能力と資質は異なっており、こうした場合には筆者は減点することにしている。ソリューションプロバイダも優秀なPM不足に頭を痛めていると思うが、ユーザー企業から「○○さんに是非PMをお願いしたい」と指名されるほどの人材を育成していただきたい。それが結果として、ソリューションプロバイダに高収益をもたらすことになると信じる。
ユーザー企業では、まだそこまでする企業は少ないが、著者の場合、提案書の体制図を基にPM候補者を会社としてどれだけバックアップする仕組みがあるか、どういったバックアップが行われるかといったことも確認するようにしている（図2）。優秀でプロジェクトを完全に任せられるPMは限られている以上、PMに大きなプロジェクトを任せっきりにするようなソリューションプロバイダを選定することはできない。
 |
| 図2●望ましいプロジェクト体制図の例。バックアップの仕組みなどが明確である |
一般的なプロジェクト体制では、PMの下に複数のチームを置くことが多い。その場合、それぞれのチームのリーダーの役割と候補者の経験、メンバーの構成（予定）、全体のバランスも確認している。単価の高い部課長クラスをプロジェクト管理チームのメンバーとしてアサインした頭でっかちな体制の提案を見ることがあるが、役割分担が不明確であり無駄な動きや混乱を招くことが多い。このような体制の場合には、その目的や理由をプレゼンの場などで確認している。
PMの過去の実績は重要な評価ポイントに
ソリューションプロバイダの生産性/品質向上施策も重要な評価ポイントである。各社とも開発基準や品質管理基準などを持っているが、実践しているプロジェクトは意外に少ない。管理が徹底しておらず、宝の持ち腐れになってしまっているのである。筆者が評価する際には、これらの基準が明確に定義されているか、それを徹底する仕組みがあるか、PM候補者にそれを実践する能力があるか、といった点で見る。
例えば、詳細設計などでユーザーに提示するドキュメントに、作成者名欄、査閲者名欄、承認者名欄があっても空欄のまま、あるいは作成者欄にソリューションプロバイダの社名が入っただけのドキュメントを目にすることがある。そうしたドキュメントを検査してみると、ソリューションプロバイダ内での検証がなされないまま、ユーザー企業に提示され、ユーザー企業にバグ探しをさせていることがある。こうした基本ができていないようなソリューションプロバイダに、安心して高額なプロジェクトを任せられるだろうか。ソリューションプロバイダの自覚が必要である。
開発・導入実績も、ユーザー企業にとって関心が高い評価項目である。同じ業種、同じ業務で実績が多いということは、それだけソリューションプロバイダにノウハウが蓄積されていると期待できるからである。筆者は、PM候補者などのメンバーが過去どのようなプロジェクトでどのような役割を果たしたのかも確認するようしている。
PM候補者に不安を抱いた場合には、過去のプロジェクトの評価を聞くために、そのプロジェクトのユーザー企業の担当者を紹介してもらうこともある。ソリューションプロバイダとしては、実際に経験のある人をアサインし、それをユーザー企業にしっかり伝えることにより、ユーザー企業の安心感を大幅に高めることができるだろう。また、ユーザー企業に求める体制や留意事項を、明確に伝えることも効果的である。
次回は、「コストの妥当性」と「プレゼンテーション」などの視点について紹介したい。
|
