ITエンジニア向け情報館

提案・受注

提案書の作成

案件を受注するときに、顧客に提案書を提出することもある。
その時のポイント。

提案書に記述する中心内容

提案の骨子、顧客へのメリットを中心に書く。
安心感、実現可能性、将来のメリットをイメージさせる内容にする。

顧客の課題の整理
（顧客の課題をしっかり認識して共有している、ということを伝える）
顧客の課題に対する解決方法と、その根拠
具体的な解決手法
その提案による顧客のメリット（顧客の負担軽減、コスト削減、売り上げアップ、経営課題の克服など）
考えられるリスクと、その対応方法

提案書に記述する補足内容

実現可能であることの具体的な根拠、提案の理解度を深めるための補足事項を盛り込む。

システム構成図
開発手法、プロジェクト管理方法
体制、スケジュール
過去の実績

「はじめに」ページの重要さ

「最初が肝心」ということで、簡潔に要点をまとめた文章を最初に見せる。
提案書の第一印象となるため、読みやすさ、デザインなどにも気を配る。

顧客が避けたいと思っていること

提案内容が、下記に該当する場合、顧客に対する印象が悪くなる。
この点は提案内容によって改善されることが望ましい。

現場の人たちの作業内容が変わる、作業量が増える
負担を感じるような、ランニングコストが発生する
時間のかかる作業が発生する

RFP

RFP作成からベンダー選定までの流れ
http://itpro.nikkeibp.co.jp/article/COLUMN/20091118/340736/

スケジュールの組み方
http://itpro.nikkeibp.co.jp/article/COLUMN/20091118/340738/

システム開発の効果測定

ITシステム開発が終了した後、果たして本当にITシステムの導入効果があったのか、費用対効果があったのかを、測定することは重要です。

システム開発の評価指標は、投資の計画時、実績の評価時の両方で同一でなければなりません。
開発の前と後で、評価基準が変わってしまうと、正しい評価ができなくなるからです。

また、IT部門とユーザー部門で共通に理解できる指標でなければなりません。
IT部門だけで理解できる指標では、IT部門の自己満足でしかなく、経営陣の理解も得られないためです。

システム開発が費用対効果の面で優れていると評価されれば、ベンダーにとっても次の受注につなげることもできるでしょう。逆に効果ないという結果になれば、なぜそのような結果となってしまったのか、反省点を認識し、次回以降の開発案件に活かしていくべきです。

発注側ユーザー企業の、受注側ベンダーに対する評価基準

RFPの理解度

RFPへの理解度を、ベンダーからの問い合わせ内容で評価する。
RFPの内容を正しく理解するために、具体的な質問を行うと、ユーザー企業は安心する。
しかしレベルの低い質問をすれば、逆に評価を落とすことになる。

RFPに記載の要件や条件に対する解決法を、わかりやすく記載していると、高い評価につながる。
逆にRFPで提示されている内容の一部しか提案書に盛り込めていない場合は、理解度が低いとみなされる。

ユーザー企業において、どのようなシステム開発プロジェクトが成功と見なされ、喜ばれるのかを知るべき。それと異なる観点でシステム開発の提案をしても、受け入れられない結果になる。

システム開発の目的の理解

システム開発の目的が何であり、それをどう実現するかを提案書に具体的にまとめていると、高評価。
どのようなシステムと連携すべきなのかを、見定める必要もある。

外部パッケージを利用する場合には、そのパッケージがどのようにして要件を満たしているのか、どのような機能で満たしてくれるのかをわかりやすく記載する。また、追加開発がどの程度必要なのかも明記する。

システムの柔軟性と拡張性

ユーザー企業のビジネスの変化・改革に対して、システムをどれほど柔軟に変更できるかを記載する。
採用する製品や技術の将来性も重要。パッケージのサポート体制が長期的に続くことや、今後もメジャーとなるであろう技術を採用していることをアピールする。
業界標準、国際標準の仕組みに準拠しているかどうかも意識するとよい。

保守や運用のしやすさも重要。保守・運用を少ない工数で実現できることを示せれば高評価。
独自開発の場合は、どのような仕組みで柔軟性を担保しているかも記載する。

ユーザー企業の開発標準、アーキテクチャ方針も把握しておく。
既存の標準やアーキテクチャから大きく外れた提案は、人的負担やコストの面でマイナス評価となる場合がある。

計画の具体性

開発だけでなくデータ移行作業や、ユーザー側で行うべき作業も網羅し、無理なく順序整合性のとれたスケジュールを提示する必要がある。
ユーザー企業にも作業が発生する場合には、その工数や必要性も記載する。
どのフェーズ・タイミングで、どのようなスキルを持つ要員を投入する予定かも書ければ、ユーザー企業は安心できる。

テストにかける工数が十分かどうかも、ユーザー企業は気にする点である。十分なテスト期間を確保したスケジュールを提示すべきである。

プロジェクトマネジメントの能力

どのような資質・能力を持つ人物がプロジェクトマネージャを務めるのかを、ユーザー企業は気にする。
プロジェクトマネージャ候補者の氏名、略歴、過去の成果などを記載するとよい。
プロジェクトマネジメントを実行する具体的な手法についても、述べておくとよい。
プロジェクトの構成メンバーの人数、スキル、投入のタイミングなど、プロジェクト体制をまとめておくと、プロジェクト立ち上がり後の状況をユーザー企業がイメージしやすくなる。
プロジェクトチームのバックアップ体制はどうなっているか。プロジェクトメンバーの外にいる上席者、会社としてのバックアップ体制まで記載してあれば、より信頼感が持てる内容となる。

過去の実績プロジェクトも示せるとよい。
ベンダー側がさらに協力会社を活用する場合は、その協力会社の特徴や予定される貢献度合いも記載する。

生産性を高める取り組みやツールがあれば、それも評価のポイントとなる。その取り組みやツールが、過去にどのような功績をあげたのかも書いておけば、より高い評価が得られる。

コストの妥当性

システム開発費だけでなく、システム稼働後の保守や運用にかかる費用（システムの稼働期間が明示されていればその期間、特に明示がなければ5年分の費用）も明示する。
開発内容に関して必須の部分と、ユーザー企業が選択するオプション部分に分けて提示をすると、よりコストに対して納得感のある提案ができる。

プレゼンテーション能力

限られた時間に、必要な情報を、ユーザー企業にわかりやすく説明する能力があることを示せれば高評価。
提案書を読めばわかる内容を、くどくどと説明するようではイマイチな評価に。
ユーザー企業の出席者全員分の資料を配布できたか、ユーザー企業が特に知りたいことを的確に説明できたか、質問には明確に回答できたか、発表時間など時間を守れるか、なども評価対象になる。

プロジェクトマネージャ候補者が自らプレゼンテーションを行うことで、この人に任せて大丈夫、という印象を与えられる。これから一緒に仕事をしていくにふさわしい人だ、という印象を与えること。
プロジェクトマネージャ候補者以外の人がプレゼンをすると、どんな人がプロジェクトを遂行するのか、という不安を与えてしまう。
また、プロジェクトマネージャの発表に対して、別の人が横から口を挟んでしまうと、目の前のプロジェクトマネージャの能力不足を印象付けてしまうので避けるべき。
自社のPRばかりするのもナンセンス。根拠なくできますと言ったり、信ぴょう性がかけると判断される印象を与えないこと。
自信なさそうな態度は厳禁。自信ある態度で発表に臨み、信頼感を与えること。

ユーザー企業の発注の仕組みの理解

発注権者、発注手順、発注のタイミングを把握しておく。
担当者が発注を予定しているなどと言っても、最終的に発注を決定する権限を持つ者が別の人であることもある。