【提案評価その4】プロジェクト計画「②開発手法」をどう読み解くか？|情シスコンサルティング株式会社

2022

5/22

ベンダー提案書におけるプロジェクト計画の評価項目は、主に6点あります。

① スケジュール
② 開発手法
③ 移行計画
④ プロジェクトマネージャー
⑤ プロジェクト体制
⑥ ユーザー教育

そのうちの、「② 開発手法」について解説します。

そのシステムの特性を生かした開発手法となっているかを確認します。

パッケージであれば、既にシステムが存在するはずなので、それを生かした進め方の提案となっているべきです。

実際にシステムを動かしながら「要件定義」や「フィット＆ギャップ分析」を進めたり、早いタイミングでプロトタイプ環境を開放したり、ユーザーが動かした結果をフィードバックする仕組みがあったりします。

この「早期にシステムを触ってもらう」というのは、スクラッチ開発ではできない芸当です。逆にパッケージをもっているのにウォーターフォール開発の「机上論」で進めようとするなら、パッケージの完成度に自信がない現れと考えてよいでしょう。

ちなみに、そのようなベンダーには、常套句があります。「御社の業務に“柔軟”に対応するために、カスタマイズでフィットさせます」です。パッケージベンダーとしてプライドがあるなら「ウチのパッケージが正しいので、ウチに合わせてください」くらいは、言ってほしいものです。

一方で、スクラッチ開発の場合も、一昔前と比べてはるかに進歩しています。

スクラッチの弱点は、「期間とコスト」が大幅にかかること。昔は、全ての選択肢がスクラッチだったので、問題ありませんでした。その中での「相対比較」をすればよかった。しかし、今はパッケージと比較される時代です。

そのため、現在はスクラッチといえど、全てをイチから作るようなことはありません。共通部品としてAPIを活用したり、特定の領域はパッケージを組み合わせたりして、「期間とコスト」という難題に対応しようとします。

現在、大手のクラウド環境（IaaS）には、開発するための各種サービスやライブラリが豊富にあります。それらをいかに活用できるかも、ベンダーの力量と経験にかかっています。それらを使いこなせる人材を抱えているかどうかも、確認ポイントとなります。

さらに費用を抑えるために、オープンソフトウェアの活用、オフショアの活用、開発やテストの自動化、保守のリモート化や自動化など、いろいろな工夫が考えられます。

これらの引き出しの多さも、ベンダーの経験値がモノをいいます。

クラウドの特性を生かしたアーキテクチャの提案も、ベンダーで差がつきます。

コンテナ方式で処理速度とセキュリティを確保する、サーバーレスでリソース最適化やサーバー管理コストを削減する、などの「技術メリット」を生かした提案も、魅力的です。

スクラッチ開発は、パッケージ以上に、最新技術に明るいか、引き出しは豊富かどうか、つまりベンダーの「力量」が問われます。そのため、評価ウェイトを大きくとり、重点的に確認していく必要があります。

開発手法は抽象的な記載が多く、とても評価しにくい項目です。しかしベンダーの力量が現れる部分でもあります。

・パッケージ導入は、パッケージの特性を生かした進め方となっているか

・スクラッチ開発は、ベンダーの経験や引き出しの多さが反映されているか

提案書で読み取るのは限界があります。そのため、後日開催のプレゼンテーションでプロジェクトマネージャーに具体的なイメージを確認していきましょう。

PREV ALL NEXT