PMプロの知恵コーナー
先号　　　次号

ゼネラルなプロ (13)

向後　忠明　[プロフィール]　：11月号
　前月号では調達、主に引合書(RFP)の概要とその作成されるまでの手順および入札者側の動きについての話をしてきました。
　また、請負企業に発行し提案書を依頼する場合と請負企業が各業者や協力会社に発行する場合の2つのケースの違いについても述べてきました。
　特に、IT産業においては発注者である事業者(オウナー)側のITにかかわる知見が希薄なためIT開発請負企業に対して「何をどうしてもらいたいかと言った要件定義」すなわち引合書の内容が明確でないままITシステムの開発を要求するケースが多いようです。
　前月号でも言いましたがＩＴ業界の発注者の力が強く、極端な言い方をすると発注者のいいなりになっているケースが多いとのことです。
　このことは少し古い話になりますが日経BP社の「日系コンピューター」でも“日本のシステム開発プロジェクトは4件のうち3件も失敗している”とも言われています。
　この原因は「要件定義の不明確な点とプロジェクトマネジメントの拙劣さ」ともいわれています。最近ではこの問題は少しずつは改善されてはいるようですが、まだまだのようです。
　この原因はやはり発注者側にプロジェクト全体を構想し、その中で「IT関連システムに求めるものが何か？」をまとめ、そしてその企画を開発にまで関与できる人材としての“ゼネラルなプロ”が不足していることによります。すなわち、上流段階を担う人と開発段階を担う人が異なりうまくその間がバトンタッチできていないことが原因の一つになっているようです。
　その結果、対象となるITシステムに求める要件定義を含むRFPも明確化できないことにつながっています。
　何故このために“ゼネラルなプロ”が必要なのかは賢明な読者諸君はこれまでの“ゼネラルなプロ(1)から(12)”の説明で理解されていると思います。
　特に、ITシステムはオウナー企業の経営や業務にかかわる改善/効率化そして製品の高効率化と言った重要な要件が含まれるので、かなり企業のハイレベルの関与が必要となる場合が多いです。そのためには経営戦略、営業戦略、そして将来のシステム化構想までを考えたものでなければなりません。
　RFPの作成はIT技術の知識だけではなく
① プロジェクト遂行に当たっての方針設定
② 将来構想および経営または業務への効果
③ プロジェクト条件設定(範囲、スケジュール、予算)
④ プロジェクトで求める要件(技術、品質、既存システム状況)
⑤ 業務量に対応した組織と体制
⑥ プロジェクト要件と対応可能業者の選定
⑦ 契約条件等々
を考慮しながら作成する必要がある。

　また、IT請負企業を使ってプロジェクトを遂行するためにも、細分化されたIT専門家を使って全体システムをまとめていくことも必要となります。
　しかし、残念ながらオウナー企業はITビジネスを専門とするわけではないため、上記に示した内容の業務をすべてまとめることの人材は育っていないのが現状です。
　このように要件定義が定まらないままの状況ではプロジェクト発注とそれを受ける受注者であるIT請負会社との間の溝はいつまでも改善されません。

　　これが、IT業界の現状です。

　オウナー企業側のこのような事情を鑑み、国としても何らかの対応をしなければとの思いから、　(独)情報処理推進機構(IPA)は情報システムユーザースキル標準「UISS」を2006年6月に作成し、オウナー企業側の情報システムの企画、構築、運用等の機能の最適配置や、携わる人材の育成を目指しています。
　しかし、ここでもオウナー企業側に相変わらずビジネスストラジスト、ISストラジスト、プログラムマネジャー、プロジェクトマネジャ、ISスペシャリスト、アップリケーションデザイナー等々の各専門家の育成を求めています。
　筆者の経験からみても、このように専門を分ける必要もなく、これらを一括してまとめてITシステムをオウナー企業側から見る人材として“ゼネラルなプロ”一人がいれば十分と思っています。
　オウナー企業側にはITシステムを運用している技術者もいるし、自社の業務内容も熟知した経営企画に従事している人も、そして契約にも強い法務関係の人材もいます。それでも人材が足りなければ外部から一時的に必要に応じて派遣依頼すればよいでしょう。
　このような人材を“ゼネラルなプロ”の配下として配置し、プログラムまたはプロジェクトをオウナー企業側からの立場でマネージメントすれは十分と思っています。
　このような体制で引合者(RFP)を作成し、その後のIT請負企業からの提案書の評価、交渉、契約、そして実行面でのマネージメントを行えば何ら問題ないと考えます。
　このように“ゼネラルなプロ”の存在がIT業界ばかりではなく、他の業界においてこれから新たな企画や開発事業を計画しているオウナー側(事業者側)の悩みを解決してくれることになるでしょう。
　しかし、読者諸君には以下のように思っている人もいるでしょう。
　「筆者はIT業界の実情もわからずに簡単に物事を考えてはいませんか？そのような人がいたら教えてください」
　そして、
　「筆者がいつもプロジェクトマネジメントの先駆者と言っているプラントエンジニアリング系の会社にそのような“ゼネラルなプロ”は存在するのか？」
　答えは、
　｢分野を越えてプロジェクトをマネージできる人材は少ないでしょう。しかし、IT業界について言えば、ITシステムプロジェクトに興味を持ち、各種のプロジェクトにおいてプロジェクトマネジメント経験を持った人材ならIT関連の新たな企画や開発案件への対応は可能だと思います。｣
　と言うことができます。
　例えば、PMAJにハイクラスプロジェクトマネージャ「PMR」に関する資格試験があります。
　筆者はこの試験の一部に関与していますが、この試験内容は幅広い業界の知識や自分の分野での幅広い多くの実績も必要としているのでこの人材の中には上記の条件をクリアーできる人もいると思います。
　「そうは言っても、必要な人材はすぐに育つわけではなく、この状態ではIT業界の開発プロジェクトはいつまでも同じ状態が続くことになるのではと言う危惧を持つ読者諸君もいるでしょう。
　「引合者(FRP)も作れず、これまで通りの要件定義の無いプロジェクト発注となりますが、それではどうしたら良いのでしょう！」
　その場合は、筆者の経験ではありますが、契約のやり方で対処可能です。　日本の多くの開発プロジェクトの多くは一括契約(ランプサム)です。
海外では、特に要件が明確でない場合は日本のような膠着的な契約の仕方は余りしません。すなわち、要件の状況によっては出来高ベースの実費精算方式やコストプラス方式と言った契約手法を使います。
　オウナー企業側から見ると
「予算の設定も必要であることから、全体金額がわからないと困る」
　と言った意見もあると思います。
　この場合は、要件設定をIT請負業者またはコンサルタントに、実費清算ベースにて、オウナー側がやるべき仕事の一部をお願いします。そして、要件が設定されたら、引合書(RFP)を作成し、一括契約にて発注することも可能です。
　これなら、比較的少額にて要件設定を行い、以降の基本設計を含めた作業を一括発注しても正確なコストでそして大きな変更もなくプロジェクトを進めることができます。

　しかし、いずれにしても引合書(RFP)の作成は必要となります。以下にITプロジェクトを対象とした引合書(RFP)に記載すべき項目の一例を参考に示します。

1.提案の手引き(入札注意事項)
1.1プロジェクト概要
 ・背景/経緯
 ・目的/方針
 ・解決したい課題
 ・狙いとする効果
 ・予算
1.2参加資格
1.3参加資格条件
 ・組織
 ・実績、技術、技術者の資格、
1.4手順と日程
 ・引合書の構成
 ・手順とスケジュール
 ・RFPの説明会細目
 ・問い合わせと窓口
1.5提案書の作成都提出方法
 ・提案書のスタイルおよび各種規定(形体/形式)
 ・代替案の提出指示
 ・見積有効期間		  ・PJ実施線表の形態その提出指示
 ・見積価格の表示形態と提出様式の指示
 ・PJ体制、役割分担、作業場所の提出指示
 ・PJ遂行手順書の提出指示
 ・プロジェクト遂行上の要件
1.5選定基準
 ・提案書の評価、決定ルール

2．提案内容要件
2.1システム要件
 ・システム全体概要およびコンセプト
 ・PJ範囲・業務の詳細
 ・システム構成/ネットワーク構成
 ・運用要件/性能要件/保守要件/システム品質要件/SLA/セキュリティー
2.2システム移行要件
 ・移行対象/役割分担/期間、時間に関する要件
2.3支援要件(トレーニング／マニュアル作成
2.4契約事項
　ここまでの説明でオウナー企業側に立つ人達のやるべき内容および方法の片鱗をつかむことができたと思います。
　しかし、引合書(RFP)の内容は上記にて示したようにプロジェクトに関連した多岐にわたる知識と経験が必要となるので、現状では引合書(RFP)作成には多くの経験を持つプロフェッショナルにお願いすることになるでしょう。
　また、IT開発請負企業側も対下請けに発注する際にも引合書(RFP)の作成が必要となるので同じことが言えます。しかしオウナー企業に比較し、IT開発請負企業の方が引合書(RFP)作成の機会に恵まれていることと、IT専門技術者も潤沢であることから、オウナー企業よりは熟練しています。
　ここで筆者も思うのですが、やはりIT開発関連プロジェクトの企画/構想はオウナー企業にお願いすることとし、それを受けて、契約条件に従ってIT開発請負企業がオウナー側に立って、ITシステム開発に必要な要件定義までを請負うことが現状に合ったやり方と思っています。

　これまでIT関連プロジェクトを対象に説明してきましたが、他の業界においても技術および業務的要件が異なるだけで、引合書(RFP)の内容やプロジェクトの進め方でそれほど大きな違いはありません。　また、引合書(RFP)作成および引合の手順についてもオウナー企業の対請負企業への引合と請負企業の対業者へのそれも、それほど大きな違いはありません、
　「習うより、慣れろ！」ですので一度は引合書(RFP)の作成に挑戦し、その内容および手順を先月および今月号の内容に沿ってやってみてはどうでしょうか？

　来月は調達行為の中でも最も重要な「契約」についての話をしていこうと思います。
契約の条文は前例としていろいろあると思いますがプロジェクトの性格を見て作成する必要があります。しかし、まずは定型的な内容を理解してからと言うことになります。
　筆者として推薦できる資料としてはENAA(エンジニアリング振興協会)の国際標準契約書がありますのでそちらを参考にすると良いでしょう。
ページトップに戻る