システム開発に欠かせない見積もり前提条件について

160件のシェア(すこし話題の記事)

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは!おおはしりきたけです!今日はシステム開発に欠かせない見積もり前提条件について書きたいと思います。

■はじめに

弊社では、受託開発を多くやっております。受託開発は、最初のスタートが重要です。私見ですが最初のスタートで成功確率の80%は決まっているといっても過言ではないと思っております。そのくらいスタートというのは大切だと思っております。エンジニアの方々の中には、営業さんが「あとはヨロシクッ!」と言って金額しか決まっていないプロジェクトを経験し苦い思いをした方も多いのではないでしょうか。弊社では、そのような事が起こらないよう営業さんとは密な連携を取りプロジェクトが成功可能かという判断をし、成功可能なプロジェクトに対し開始するということを行っています。その作業の中でも特に重要なのは、見積もりの前提条件です。

 ■なぜ前提条件が必要か

見積もりを出すときの流れは大まかにいうと以下のように流れることが多いと思います。

見積もりを行うときには、何かしらの前提を想定して見積もりを行っていると思いますが、上記の図の流れの中でエンジニアの方が工数のみを伝えてしまい、前提条件がエンジニアの方の頭の中にしかない状態で見積もりが提出されてしまうことがあります。ほとんどのシステム開発は見積もり時に明確に要件が決まっていることが少なく、要件のあいまいな部分などが肥大していき案件が炎上してしまうということもあります。そのようなことを避けるため、仮の要件での前提が開発を進めていくうえでの前提条件というのをしっかりと明記しお客様と確認する必要があります。当たり前のことだから明記しなくて良いということはありません。必ず明記しましょう。「~して当たり前だと思った」といった議論にならないためにも、しっかりと前提条件を洗い出していきましょう。

■決めておくべき前提条件

1.見積もり範囲について

今回見積もっているシステムの対象範囲はどこなのかを明記しましょう。ソフトウェア、ハードウェア、ミドルウェアのどこが対象になるのか。大きなシステムになってくると連携しているシステム等もあると思います。この機能は違うベンダーということもありますので、どの機能が見積もり対象なのかも明記しましょう。

2.見積もり対象外範囲について

1の見積もり範囲で記述しているから不要でしょ?と思う方もいると思いますが、あいまいな部分をなくしていくためには、見積もりの対象外の項目もしっかりと記述しておきましょう。システムの開発範囲については、文字では伝わりづらいため、システム構成図などを作成しておくとわかりやすいです。システム構成図には載らない作業(例えばユーザ教育やデータ移行など)についてもやる、やらないを明記しておきましょう。

3.使用技術

言語であれば、JavaなのかRubyなのか、クラウドを使うのであれば、AWSなのかAzureなのかなど大きなものから、Javaならどのフレームワークを使うのか、AWSならどのようなサービスを使うのかなどを明記しておきましょう。以下にWebアプリでの例を挙げます。

【例】
今回のシステム開発に対し、以下の技術を使用する前提です。
 開発言語(Server):Java(1.7)
 フレームワーク:Play framework2.0 beta
 開発言語(UI):HTML5、CSS3、javascript
 フレームワーク:jQuery(1.4)
 クラウドサービス:AmazonWebService
 利用サービス:EC2(OS:AmazonLinux 32Bit InstanceType:Small)
         :S3
         :RDS(mysql)
 APサーバー:Tomcat(7.0)

見積もり時点で細かい部分まで決められないよ!と思う方もいると思いますが、あくまで見積もり時の前提です。プロジェクト開始後に根本の技術が変更にならないよう、使用技術についてもできるだけ細かく記述しておきましょう。

4.開発プロセス

ウォーターフォール、アジャイル、反復型など、システム開発では、開発プロセスも色々と増えてきております。開発プロセスに何を採用し、どのような進め方をするかも決めておきましょう。

5.プロジェクト期間

1人月の作業でも、1ヶ月で行うか10ヶ月行うかによって期間は全然変わってきます。プロジェクト開始、終了そしてお客様の受け入れ時期含めて期間の前提を書いておきましょう。

【例】
・本見積もりでのプロジェクト期間は、2012年2月1日~2012年6月29日までを想定しております。開始時期が遅延した場合は、貴社と協議の上再度スケジュールの調整及び別途費用見積もりが必要となります。
・お客様の受入期間は2012年6月11日~22日までの2週間を想定しております。
・プロジェクト全体スケジュールは、2012年1月10日時点での想定であり、プロジェクトの進捗状況に応じて、見直しが発生した場合には、貴社と協議の上、再度スケジュールの調整および別途費用見積もりが必要となります。

6.要件

見積もり段階での要件というのは明確でないことが多いです。要件が明確でないものに関しては、機能に対し前提を考えて書いておきましょう。また、開発会社が複数ある場合、相手側の要件が決まっていないなどもありえます。以下に要件についての例を挙げます。

【例】
・〇〇機能については、□□のAPIを利用することを想定しております。
・本システムについて、新たな要件および機能の追加・変更が発生する場合は、貴社と協議の上、再度スケジュール調整及び別途費用見積もりが必要になります。
・貴社、または他の開発会社様の作業遅延により、調整作業の開始時期が変更となる場合は、貴社と協議の上、再度スケジュールの調整及び別途費用見積もりが必要となります。

7.プロジェクトの運営方法

プロジェクトの進捗管理、推進は誰が行うのか?提供してもらう資料はいつまでに必要なのか、意思決定はどのように行われるのかなどプロジェクトを運営していくうえでの前提条件というのも必要です。以下に例を挙げます。

【例】
・プロジェクトの計画策定、推進、進捗管理については貴社と弊社で行うこととします。
・弊社に提供していただく情報については、弊社が指定した期日までにご提供いただくこととさせていただきます。
・方針に関する意思決定や解決を求められているプロジェクトの課題は、プロジェクトチームによって1日以内に解決することとさせていただきます。
・要件や、プログラム仕様を決定するといった作業において、意思決定者が不明確であったり、決定済み事項を覆すといった状況が発生した場合、スケジュール通りのプロジェクト運営が不可能になります。そのような状況を避けるためにも、意思決定者や意思決定機関を明確に設けていただくことをお願いいたします。

8.インフラ/開発機

開発環境やネットワーク環境についても、構築するのか?購入するのか?借用するのか?などしっかり決めておきましょう。借りる予定だったミドルウェアが借りられず数百万で購入することになってしまったなんてことの無いように、しっかり決めておきましょう。以下に例を挙げます。

【例】
・弊社内で開発作業を行っている間は、弊社内の仮想サーバーに環境を構築し、テストを行います。
・弊社内で開発作業中は、○○サービスとの連携についてはスタブを使用してテストを行います。
・総合テストにおけるネットワーク環境については、貴社より提供されることを前提とさせていただきます。

9.テスト

テストという作業に対して何を行うか、またテストパターンはどのくらい行っていくかをしっかり決めないとテストという作業はすぐ工数が膨らんでいきます。Webシステムや、モバイル系の案件などは、OS、ブラウザ、端末などの組み合わせによっていくらでもパターンを増やすことができます。その場合バージョンも明確に記載しておきましょう。最近のブラウザはすぐバージョンアップするので、開発期間中にアップデートされるということはざらにあります。テストなどは想定のパターンを考えておいた方が良いです。以下にテスト作業についてとテストのパターンについての前提条件を挙げます。

【例:テスト作業】
・今回のテストでは以下のテスト作業を想定しています。
 ・単体テスト
 ・結合テスト
 ・総合テスト
 ・負荷テスト
 ・セキュリティテスト
・単体テストでは、XUnitを使用し、カバレッジの計測を行います。
・単体テストでは、エビデンスの取得、テスト結果報告書の作成は行いません。
【例:テストパターン】
以下の環境に対し、テストを行います。
・OS
 ・Windows7 64bit
 ・WindowsXP SP2 32bit
 ・Mac OS 10.7
・ブラウザ
 ・IE9
 ・Chorome 17

10.納品物

ほとんどの受託開発では、納品物があります。プロジェクト終了時に「あれ?この資料作ってないの?」といったことにならないよう、納品する成果物、また成果物の粒度についても前提を決めておきましょう。「基本設計書」や「詳細設計書」など粒度があいまいな記述はせずに、「シーケンス図」「クラス図」といった設計書の内容をイメージできるレベルまで想定できるようにしておきましょう。

■まとめ

弊社でもここまでの上記の前提条件を全て記述するということは、多くはありません。特に6の要件や、7のプロジェクト運営については、文書を見ると固くて嫌な感じですが、お客様と開発者側お互いがあいまいな部分を減らしていくためにも、発注者、発注側の担当者、営業、エンジニア、管理者がしっかりと前提条件を認識しプロジェクトを開始することが大切だと思います。最後に、ここまで前提条件は重要だと書かせていただきました。確かに前提条件は重要です。しかし前提条件よりもお客様との信頼関係をしっかり構築してからプロジェクトをスタートする方が何倍も重要だと思っています。