その好きな新緑の季節できすが、あっと言う間に過ぎてすぐに梅雨になるかと思うと今からちょっと鬱陶しい気持ちにもまります。わがままなもんです。
さて前回より、ＲＦＰを作成するプロジェクトについて考えています。本題に入る前に確認しておきたいのうは、ＲＦＰ作成プロジェクトの本質はキットＰＭが言うところの「プレ・プロジェクト」の一部であり、したがって、もう少し大きな視点で見ると「ＢＡ（ビジネスアナリシス）」の一部だということです。
何が言いたいのかというと、あるプロジェクトを成功させるための最大のカギは、何のためにそのプロジェクトが必要なのか「目的」を明らかにすることであり、それをステークホルダーが共有し、最適な方法論に沿った計画を立て、実施するということです。
というようにＲＦＰ作成とは、プロジェクトにとってとても重要な意味を持つプロセスになるということです。
前回は、ＲＦＰには２種類があるということを考えました。一つは、大雑把なプロジェクトのイメージだけを伝えて、サービスを提供するベンダーに実現のアイデアを提供してもらうというもの。もう一つは、プロジェクトでやりたいことをある程度詳細に伝えて、その構想を実現するための方法論をベンダーに提示してもらうというものでした。
どちらの場合でも、実際にプロジェクトを実行するとなると、詳細な要件定義を行う必要があることには変わりありません。つまりそのとても時間と工数が必要となるタイミングを、どこに持ってくるかという問題だけかもしれません。
違うのは、基本的な構想をベンダーの発想からスタートするのか、自社の考えでスタートするのかだということです。どちらを選ぶのかは、プロジェクトのオーナーとなる組織の構造や方針やビジネス環境に依存することになるでしょう。
また前者を選択したとしても、オーナー組織の方針や目的について、内部でかなり煮詰めた議論が必要なことは言うまでもありません。
上記のような考えを進めて行くと、ＲＦＰを作成する前準備としてＢＡ（ビジネスアナリシス）を組織の中で実施することが必要になることに気がつくはずです。
しかしながら日本の企業の仕組みでは、まだそこまでビジネスに関する論理性が成熟しているところはそれほど多くはないと、キットＰＭは感じています。
そうなると、ＲＦＰ作成プロジェクトは必然的にＢＡの作業がプロセスに内包されていることになり、それが決して簡単な作業作業ではないと言うことはご理解いただけると思います。
では、実際にＲＦＰ作成プロジェクトを進めるときの方法論について考えてみましょう。１つ目のパターンであれば、ＥＦＰ作成の前か後に経営コンサルタントを入れて組織の要求（ニーズ）を精査することが必要になります。
その作業が「前」であれば、その結果をＲＦＰで表現することになります。「後」であれば、その作業を要求事項としてＲＦＰに記述します。
２つ目のパターンでは、ＲＦＰに多くの情報を盛り込むことが必要になります。そのためＲＦＰを作成する作業そのものの負荷は、必然的に大きくなります。
負荷が大きくなるということは、それなりの体制と費用を掛け計画的に進めることが必要です。したがって、ＲＦＰ作成作業自体をプロジェクト化することはとても合理的な方針になります。
このときプロジェクトの構造として、ＲＦＰ作成プロジェクトを最終目的を達成するための本体プロジェクトのサブプロジェクトとして位置づけることも可能ですし、最終目的達成のプロジェクトとは切り離して実施することも可能です。
どちらを選択するかは予算措置の在り方によるのですが、最近では別プロジェクトとして切り離し、後続プロジェクトとしての本体プロジェクトの自由度を確保する意味で、分割することが多いように思います。時間経過による環境の変化を考えると、その方が合理的ですね。
次回はＲＦＰ作成の具体的なプロセスについて考えを進めて行くことにします。ご期待ください。