<aside> 💡
これは RFP のテンプレート例である (組織や案件の種類によって異なるだろう).
セクション名に続いて, 囲みでそのセクションに書くべき内容, 注意事項などを記述している.
</aside>
<aside> 💡
表題, 著者名, 年月日などを書く
</aside>
<aside> 💡
この案件の目的を簡潔明瞭に, 一文程度で書く.
</aside>
<aside> 💡
達成したいことを箇条書きにして, 簡潔に書く.
基本的には, 実現する機能ではなく, 完成時に達成すべき状態, ユーザや発注者に提供される価値として記述する.
できるだけ優先順位をつける. 例えば (MoSCoW ルール),
<aside> 💡
案件に関わる対象の状況を箇条書きで具体的に (数値なども用いて) 書く.
例えば, ユーザ数, 規模, など案件に関連して, 役に立つと思われる情報を提供する.
</aside>
<aside> 💡
案件に対応する現在の業務の進め方を書く.
書き方としては, 例えば以下のような方法がある.
<aside> 💡
案件の終了後の望ましい業務の進め方を書く.
書き方については, 上記「as-is ビジネス・プロセス」と同様.
ただし, as-is とは異なり, 以下の支援を受けることが望ましい (発注側の案をそのまま押し通すことがないように)
<aside> 💡
実現に当たって, リスクを低減するために漸増的 (インクリメンタル) に行う場合には, そのステップを (発注側の視点で) 箇条書きで書く.
ただし, これは選定候補ベンダ側から技術的な理由などによって改定希望が出るかもしれない.
ステップごとに達成されるべき目標を明示する.
漸増的に行わない場合には, このセクションはなくて良い.
</aside>
<aside> 💡
案件終了後に, どのような効果が現れることを期待するかを, 具体的に箇条書きで書く.
これは, 上記「達成したいこと」をさらに詳細化, 具体化, 数値化したものになるはずである.
</aside>
<aside> 💡
依頼したい工程, 依頼しない工程を, 必要ならば理由と共に書く.
多くの場合, 以下のような工程がある.