まずは東北地方太平洋沖地震で被災された方々には、心からお見舞いを申し上げるとともに、救助を待っている方々の一刻も早い救出をお祈りしております。
さてIT化の構想・企画段階における“why”、“what”、“how”のプロセスを経ることでシステム企画書が完成することを、直近3回のメルマガにてお伝えしました。システム企画書に対し決裁権限者の合意が得られれば、いよいよプロジェクト開始のスタートラインに立つことができます。
ただシステム企画書をもとに、いきなりプロジェクトを実施できるわけではありません。通常は、システム企画書をもとにRFP(Request For Proposal)を作成し、システムの設計・開発を委託するパートナーを選定しつつ、今回実施するプロジェクトに対するプロジェクト計画書を作成します。そしてその計画に対し、ステークホルダーの合意が得られた時点で、プロジェクトは実施できることになります。
まずシステムの設計・開発を委託するパートナーを選定する場合は、次のような項目を明記した、RFPを作成する必要があります。
1. 趣旨
1.1 背景と目的
1.2 解決したい課題
1.3 期待される効果
1.4 前提・制約事項
2.提案依頼事項
2.1 対象とする範囲
2.2要求事項
2.2.1 機能面の要求
2.2.2 インフラ・技術面の要求
2.2.3 品質面の要求
2.2.4 マネジメント面の要求、等
2.3 納期・スケジュール
2.4 体制と役割分担
2.5 作業環境
2.6 納品物件
3.契約事項
3.1 契約形態
3.2 検収・支払方法
3.3 権利の帰属
3.4 瑕疵担保責任
3.5 機密保持義務
4.提案の手順
4.1 提案書に記述する内容
4.2 提案書の提出期限
4.3 提出先
4.4 提出物
4.5 質問の受付
なぜRFPを作成するのかというと、次の目的を達成するために行います。
上記パートナーの選定をしつつ、プロジェクト計画書を作成します。この計画書に盛り込むべき事項の多くは、システム企画書の中に含まれています。
十分な粒度で検討されたシステム企画書をもとに作成する場合は、プロジェクト開始後に着手する要件定義工程を進めるために必要な、詳細なスケジュールや具体的な体制、また品質管理の基準などを追加することで完成します。しかし多くのシステム企画書は、十分な粒度で検討できていないことが現状です。よってシステム企画書の検討が不十分であると思われる点は、システム企画書を作成した責任者に内容を確認するとともに、プロジェクト計画書の中でその内容を具体化、もしくは具体化するためのタスクや体制を組み込みます。ただシステム企画書に書かれている方向性に反するような事実が顕在化した場合は、システム企画書を見直すなどの対応が理想的です。
さらによりプロジェクト進め方がより具体化してきたところで、今回のプロジェクトにおけるリスクとその予防策を洗い出します。そしてその予防策を、スケジュール、体制、会議体などのコミュニケーションルールに反映します。その理由は、リスクは洗い出ししただけでは意味は無いためです。予防策をプロジェクト計画の中に具体的に組み込んでおくことで、リスクの予防策を個別に意識することなく、プロジェクトの計画に従い実行することで、自然と予防策も実行できるようになります。
あとはプロジェクト計画書に書かれた内容に従い、プロジェクトを実行してゆきます。ただプロジェクト計画書の内容は、一度決めたから絶対に変更してはならないというものではありません。もし内容を見直す必要が生じた場合は、プロジェクト計画書に定めた「変更管理ルール」に従い、プロジェクト計画書を見直します。
さて今回で「PM+BAの実践講座」に関するメルマガは終了いたします。昨年5月より連載をさせていただき、多くの方々にご愛読いただき、また数々のコメントをいただきました。この場を借りて厚く御礼申し上げます。
PM(プロジェクトマネジメント)は、情報処理技術者試験のプロジェクトマネージャやPMBOKの普及もあり、考え方や取り組み方はだいぶ周知されてきたと実感しております。しかしプロジェクトを成功に導くために必要な、「そもそもこのプロジェクトは何のために行うのか?」を発注者側で決める“IT構想・企画”は、定義やプロセスの整備も未成熟です。
今回「PM+BAの実践講座」として連載させていただいたことが、皆さまの仕事に少しでも参考にしていただける点があれば幸いです。