新規事業向けシステム開発の要件定義の極意 Part5【システム化の範囲を定める】〜【データ量を予測する】
前回まではシステム開発のパートナー候補の探し方から、提案の評価方法までについて解説してきました。提案の評価について、見積書は別途説明しますとしていましたので、今回はその続きです。
この投稿をご覧いただいているということは、システム開発の見積書がお手元に届いたか、あるいは、これから入手予定の方だと思います。
- システム開発の見積もり自体不慣れなのに、3社に依頼したら、三者三様で提示され、その見方がよく分からない。
- システム開発の見積書をどう評価すべきか分からない。
そのようにお困りの方はいらっしゃるかと思います。
何せ、決まった書式があるわけではありませんし、ましてや他社の見積書を見る機会などありませんから見積を提出する側も不慣れな時は、試行錯誤して作っていたものです。
この投稿をご覧頂きますとシステム開発の見積書の見方と評価ポイントがご理解頂けますのでぜひ最後までご覧ください!
なお今回の解説は、新規にシステム開発や、アプリ開発をする時に受け取る見積書を前提としています。パッケージ、クラウドサービスはまた異なりますのでこの解説の対象ではありません。予めご了承ください。
このコラムの内容は動画で公開しています。
Youtube版「こんな見積書はNG!見積書はここを見よう」Youtube版はこちらをご覧ください。
システム開発の見積書の見方
見慣れない商品やサービスの見積書がよく分からない。というのは、システム開発に限ったことではありませんよね?
例えば、エアコンの見積書ひとつとっても
- 本体
- 既設エアコン撤去搬出処分費
- フロンガス回収および破壊処理
- 既設冷媒配管耐圧検査
- 室外機搬入据付
- 室内機搬入取付工事費
- 養生費
- 諸経費
ネットで検索したものを一部、工事の素人目線だとなんとなくわかるけど・・・というレベルの項目が列挙されています。
これが、システム開発となると、見慣れない人に取っては何が正しいのか分からないだろうと思いますので、システム開発における見積書の見方と比較・評価ポイントについて説明します。
まず、大前提として知っておきたいこと。これはご想像通りかもしれませんが、システム開発はほぼ人件費です。見積書の大部分は、どんな作業にどれくらいの人件費がかかるのか、という考え方が基本となっています。それでは具体的にシステム開発の見積書に並ぶ項目について説明をします。
システム開発の見積書に並ぶ項目はこのような物があります。
要件定義 、画面デザイン 、画面コーディング 、設計、開発、 テスト 、サーバ設定 、データ移行 、プロジェクト管理費、ドキュメント作成 、成果物 、 ○○代行
また、明細項目に対しての金額計算には以下のような項目があります。
単価、工数、金額
ではそれぞれの項目について、順に解説します。
なお、どの項目もそうなのですが、見積もりを作成する会社によって表現が異なる、あるいは作業内容が異なる場合もあります。もし、これから上げる項目以外のものが出てきて、その内容が不明な場合、メールにお問い合わせ頂ければ回答いたしますので、ぜひご質問ください。簡単なご相談は無料でお答えしますので、ご心配なく。
要件定義
要件定義とは、システムやアプリ開発を行う際、まず最初に行うものですが、簡単に言うと、どんなシステムを作るのかということを具体化する工程です。機能についての要件がイメージしやすいのですが、例えば会員登録機能であるならば、どんな項目を登録する、登録後は確認メールが送られる、ということを一つ一つ決めていく作業です。
画面デザイン
ページデザイン、UI/UXデザインという表現をされることもあります。その名の通り画面のデザイン作業であり、画面のレイアウトを決めたり、どのボタンをクリックすると、どうなるか。例えば、確認画面へ進む、ということを決める作業です。
コーディング
画面コーディング、ページコーディング、HTMLコーディングとも表現されることがあります。これは、WEBで動くシステムの場合に必要な作業であり、画面デザインをブラウザで再現できるよう、コード化を行う作業です。
設計
単に設計とまとめることもあれば、基本設計、詳細設計、外部設計、内部設計、インフラ設計のように、個別に表現されることもあります。要件定義で決定した内容について、データをどう保持するのか、各機能はどうやってデータを取得して、画面に表示するのかなどについての設計作業を行うものです。
開発
プログラミング、製造などと表現されますが、設計内容に基づいてプログラミングを行うことです。ここに単体テストというプログラムを書いて、そのプログラムが動作するかをテストする作業も含むこともあります。
テスト
ひとまとめにテストとしてしまいましたが。単体テスト、結合テスト、総合テスト、システムテスト、受入テスト、負荷テストのように、細分化された表現になることも多々あります。その名の通り、作ったシステムが仕様通り・要件通りに動くかを確認する作業です。
サーバ設定
環境構築と表現することもあります。開発したプログラムを動かすためには、プログラムを動作させるためのソフトウエアをサーバ、つまり、コンピュータにインストールして様々な設定を行う必要があり、この作業を言います。
データ移行
これは、新しく開発するシステムだと少ないかもしれませんが、既にエクセルで会員情報を保持していたり、システムを作り直すという場合には、いままで使用していたデータを新システムへ移さなければなりません。もちろん、移さないという選択肢もありますが、いまのデータを有効利用するために移すことでしょう。その作業のことを言います。
プロジェクト管理費
進行管理費というケースもあるようです。例えば1人、2人で開発するくらいの小さなシステムでは必要性は低いと思いますが、規模が大きくなると関わるエンジニアも増えて来ます。単に人数だけの問題ではありませんが、プロジェクトを円滑に回すための作業で、具体的には開発するシステムの要件、これを納期、予算、開発要員など限られた条件の中で実現するための計画・実行を行うものです。
ドキュメント作成
仕様書作成、設計書作成、テスト計画書作成と言われることもあります。ここについては、先に説明した要件定義や設計などの工程で同時に行われるもので、それら工程の金額に含めてしかるべきと考えてますが、時に別項目で出してくる企業もあるため、説明しました。
成果物
納品物に同義です。システム開発を行った際に作成した各種設計書、サーバ環境設計書、プログラムソースコード、テスト仕様書、テスト結果、などです。ここは、これまでに説明した作業で作成したもので、何をお客様へ納品するのかを記載しているところであるため、金額が入ることはありません。
○○代行
様々な代行が考えられますので、○○と表現しています。その名の通り、システム開発を依頼する側がやるべき手続きなどを、代わりに行うための手数料に相当します。例えば、どこかのクラウドサーバを借りる時、ドメインの取得、アプリならばApple Developer 、Program、Google Play デベロッパーアカウントへの登録などの作業代行です。
続きまして、明細項目に対しての金額計算に出てくる項目です。
単価
単金という書き方も見たことがあります。開発に関わるエンジニアなどの、1カ月あたりの金額です。単価は1日、1時間で表現されることもあります。
工数
数量と書く場合もあります。これには単位があり、人月、人日がポピュラーで、小規模システムなら、時間という場合もあります。
金額
単価×工数が金額です。その明細に記載されている作業に対する金額となります。
比較・評価ポイント
システム開発見積もりの各項目について、ある程度でもご理解頂けましたでしょうか。続いて、比較・評価ポイントについてご説明します。
さて、その前に大切な点を2点、説明しておきます。それは、見積もり作成依頼方法と金額の妥当性についてです。
①見積もり作成依頼方法
見積書を比較するに当たっては、どのような形で見積書の作成を依頼したのか、という点です。提案依頼書、あるいはそれ相当のものを提示、あるいは、開発したいシステムについて、できる限り細かく要望を伝えるなどしたうえで、出てきた見積書でしょうか?または、概算、ざっくりでいいからどの程度かかりそうか金額が知りたいので出してほしい、そんな依頼をしたのか?さらに、保守・運用にかかる見積もりも依頼済みなのか。
これらの前提によっても評価できるかどうかが変わります。これから解説する比較・評価ポイントは、提案依頼書あるいはそれ相当のものを提示して、保守も含めて見積依頼をしたという前提に基づいて説明します。
②金額の妥当性
見積もりの明細や、総額。これらの金額が妥当なのかどうかはこの場で説明できません。なぜなら、作ろうとしているシステムによって変わるからです。ネットを検索されてご覧になったことがあるかもしれませんが、システムの相場感として金額が書かれているサイトもあります。
しかし、あれを鵜呑みにしてよいかと言う点については疑問です。もちろん、私なりの相場感もありますけれど、建築を例にすると、家を建てると言って平屋なのか、木造なのか鉄筋なのか、広さはどれくらいかのように、様々な条件が絡み合って算出されるものであり、システム開発も同様ですので、今回は控えさせて頂きます。
では改めて、比較・評価ポイントについて説明します。
ポイントはこの5つです。
①開発・保守、両方の見積書
②見積書の明細の妥当性
③見積の有効期限
④見積に対する値引き額
⑤保守サービスの内容
では順に説明します。
①開発・保守、両方の見積書
これは単純な話し、開発時にかかる費用と、開発後にかかる費用の両方が明確になっているか、ということです。
実際にあった話しなのですが、「開発はするけど保守はしません。」というITベンダーがありました。システム開発について、知識が浅い方であれば、何となくそれでもいいかと思ってしまう場合も少なからずあるかもしれませんが、これは絶対にいけません。
開発した会社が保守サービスを提供しないなどあり得ません。
例えば、家を建てて引き渡したらさようなら。だった場合・・・
雨が降ってきたら、あちらこちらで雨漏りする。それでも、「作って引き渡したのだから、うちは知りません」という状態に近いものです。
実際は、これは瑕疵責任なので全く同じではないですが、そのようなニュアンスだと思ってください。
②見積書の明細の妥当性
この説明をするため、システムの見積書3つの"あるある"をご紹介します。
・一式一行タイプ
見積もりをやる気がない、つまり仕事を受けたくない。または、見積もることができない場合に、手抜きのような見積もりが出されることがあります。
これは、当然NGです。
しかし、念のため、詳細な見積がほしいということは伝えてください。
もしかすると、こちらから出した資料が不十分であったため、こうせざるを得なかったという回答があるかもしれません。もっとも、そのような理由ならば先に言ってくるとは思います。
・投入するエンジニアで見積もるタイプ
これも、アバウトではありますが、合わせてスケジュールも提示され、この期間にSEを何人、この期間にプログラマを何人投入するので、それぞれ何人月かかります。という説明が添えられるはずです。
見積もる側にとって、提案依頼書の精度からするとこれが精一杯ということもある話しですから、こちらもまた、見積もりを詳細化できないかという話はしてみましょう。
・明細まで記載してあるタイプ
理想的見積です。どの工程、どの機能にいくらかかるかが明確ですので、複数社が同様に見積もってくれているならば工程単位、機能単位で見積金額を比較することが可能になります。
③見積の有効期限
これは単純なのですが、見積書を発行した日から極端に短くないかを見ます。例えば、見積書発行日から1週間後が期限だとすると、なぜそんなに短いかを確認してください。受注を急ぎたい理由があるかもしれません。
早く受注して納品しないと資金繰りが困る。
営業担当者の成績がかかっているので、今月中にねじ込みたい。等々。
見積もり金額がどれくらいかにせよ、検討には時間もかかりますし、1週間やそこらで決められることは少ないでしょうから、発注を急がせるような相手は要注意です。少なくとも1ヵ月の有効期間があってしかるべきです。
④見積に対する値引き額
値引きがあるからと単純に喜んではいけません。値引きにも、値引く理由があるからです。
千万単位、百万単位の見積もりで、万円・千円を切り捨てる。それ位ならよくあることです。
しかし、10%以上も値引いているとするとどうでしょう。最初から、値引き分を上積みした金額であると疑ってかかっていいと思います。あるいは、見積期限同様、早く受注したい裏の理由があるかもしれません。
または、過去にニュースにもなったことがある、1円入札のように契約さえしてしまえば、その後の保守・運用、追加開発で元を取ろうとする考えかもしれません。値引き額が大きいなら、値引きができる理由も確認しましょう。
⑤保守サービスの内容
保守サービスは通常、月額料金で表示されますが、単に「保守サービス」月5万円だと比較のしようがありません。保守サービスの内容が同等であって、他と比較できます。
主な保守内容はこのようなものです。
・ソフトウエアアップデート、セキュリティパッチ適用
・テクニカルサポート、質問対応
・データバックアップ
・サーバ管理
・不具合対応、障害対応、あるいはバグ対応
・機能追加
・ソース管理
・開発環境維持費
・ドキュメント管理
ちなみに、保守料金は開発金額の5~15パーセントと言われてますので、その範囲内なのかも確認しましょう。先に説明したサービス内容によって金額は変わりますので、単純比較はできません。
以上の5つのポイントについて、各社の見積もりを見てください。
そして、不明な点はしっかりと確認しましょう。
ここで注意事項が一つあります。
要件定義の完了前の場合、見積書は概算見積書として提出されることがあります。
それは、作るシステムを定義する「要件定義」が完了しないことには、見積の精度を高めることができないからです。また、要件定義完了前だと、要件定義の工程のみ見積金額が出され、設計以降の工程は要件定義完了後として提示されることもありますが、それは割と一般的なことです。
まとめ
見積書を比較するだけでも、システムの専門用語を最低限知らなくてはならないですし、書式がバラバラなものを比較、評価するというのは思った以上に大変な作業です。
また、金額も大きいでしょうから、なおさら責任重大なことでしょう。
ただ、忘れないで頂きたいのは、見積書は開発パートナーを決定する唯一の条件ではないということ。提案書と合わせて比較するための、評価項目の一つであるということはしっかりと胸に刻んでください。
再度になりますが、もし「この投稿に登場しなかった見積もり明細が出てきた」というような場合、遠慮なくメールにてご質問ください。簡単なご相談は無料でお答えしますので、ご心配なく。