1．導入予算の検討

◆作業の概要、目的、タイミング

開発規模（機能数、画面数、難易度など）に応じて、企画案を導入した場合の予算を見積もる。

• 初期コスト（開発コスト）だけでなく、場合によっては運用コストも考える。

予算を顧客と調整する。必要に応じて、システムの内容を調整する。

◆事前に必要なもの、情報

この作業の前段階として以下の作業を行い、また、作業に必要な情報として以下のものや情報等を用意しておく。

◆具体的な作業項目、手順

費用の算出手順（一般的な積み上げ計算の場合）

1. 開発範囲と開発工程全体に対して、「何を作るか」「 どんな作業が発生するか」 をできるだけ細かく洗い出す。
   （各工程毎／各機能毎／各画面毎など）
2. それぞれの作成物に対していくらかかるか、それぞれの作業に対していくらかかるか、を算定する。
3. 全体を合計する。

見積のやり方にはいろいろあり、絶対的なものはない。業界全体の研究課題でもある。

開発費用の算出

• 単位の「人日（にんにち）」：
  １人の技術者が、１日の作業で作成可能な作業量、工数。
  一般的に、20人日＝1人月（いちにんげつ）として計算する。ある程度の規模のシステム開発になれば、開発の全体工数が数人月になる。
  規模が大きいものは、数十人月～数百人月にもなることもある（開発総額は、数千万円～数億円にもなることがある）。
• 1画面の作成であっても、単純なものと複雑なもの、1画面内の項目が少ないものと多いものなどがある。
  複数画面を作る場合でも、同じようなレイアウト・機能のものを作ればいい場合と、各画面で全く違うレイアウト・機能のものを作る場合とでは、手間が違う。
  ランク付けをしたり、基準値を設けて、そことの比較で重み付けを変えたりして作成費用に差を付けることがある。
• Webなどの場合、提供された素材を使えばいい場合もあれば、素材の作成も含めて請け負う場合もある。
  素材の作成も含む時の見積は、素材作成を別項目として単価と数量を割り当てることもあれば、作成素材を含むページの重み付けを重くすることもある。
• 複雑な機能や特殊な機能を含む場合は、別言語で作成することもある。
  見積上は、そういった機能作成を別項目とすることもあれば、機能を含む画面の重み付けを重くすることもある。

開発以外の諸作業・諸費用（例）

• データ入力：
  システムの運用に必要なデータの入力。データ１件あたり○円、として請け負うことがある。
• 環境構築：
  ユーザ側にIT知識が少なかったり、人手を割けなかったりする場合、システムの稼動に必要なハード／ソフト／ネットワークなどの購入・手続き代行、インストール、設定などを請け負うことがある。
• 導入サポート：
  新システムのインストールや設定、導入教育などがある。
• 保守：
  ユーザのシステム導入後、トラブル対応やバージョンアップなどがある。
• システム開発とあわせてこれらのことも一括して請け負う場合、これらのことも作業項目として挙げ、費用を割り当てることがある。
  また、全く別の見積書として作成・提示することもある。

見積書は、いきなり正式書類として出す必要はない。まずは「概算」として、メモ程度の資料を出して反応を見る。  
調整後ほぼOKとなった段階で正式書類とし、先方の正式な決裁をあおぐ。 ⇒ 正式な提案へ  

費用の折り合いがつかない場合の調整手段  
ユーザとして「○円までしか出せない」という経営的・業務的事情がある。  
それと、開発側から出した費用見積が合わないことがある（というか、最初の段階ではまず合わない）。  
ユーザの要望を聞きながら、随時調整していく必要がある。

• 必要な機能を絞り込み、今回開発分を縮小する。段階的な開発を検討し、「１次分はここまで、２次分はここまで」などとする。
• ユーザの要求を聞き、過去の開発資産を流用するなどして開発効率を極力上げる。
  （ただしこれは調整の有無にかかわらず、プロジェクトとして常にやらないといけないこと。）
• 体制を増やす。
• とにかくがんばる。

◆正式な見積書の主な項目（参考）

概算レベルではまだこれらの書類化は必要なく、確認程度でよいが、  
正式な見積書にする時は、主に以下の項目の記載が必要になる。

• 発行日：この見積書の発行日。
• システム名：この見積書が対象とするシステム名。
• 開発言語：このシステム開発で使用する言語。
• 作業工程：この見積範囲内で対応する作業工程。
• 作業期間：このシステム開発業務の作業期間。
• 納期：納品物件の納品日、引渡し日。
• 納品物件：成果物として顧客に納める物。
• 検収条件：検収の期日、手順など。
• 契約形態：この見積書が対象とする業務の契約形態。
• 支払条件：費用の支払日、手順など。

• （見積金額の明細）

  • 「指定の納期に、指定の納品物件を納める」ことに対して、代金をいただける。
  • 検収：
    納品物件をチェックし、指定されたモノや機能がきちんとそろっていることを確認すること。
    検収は、顧客にやってもらう。検収終了後には顧客から検収書を発行してもらい、
    それを受領してはじめて請求書を発行できる。
  • 一括請負、受託：
    一連の開発業務を一括で受注し、最終的な成果物にたいして代金をいただく形式。
    開発プロジェクトの管理・運営は、原則として請け負った側が行う。

◆成果物、最終イメージ、作業例

この作業で以下の成果物を出す。または完成イメージの状態にする。それをこの後の作業につなげる。

◆作業上のポイント、注意点

見積に挙げた費目は、それぞれ「何をどこまでする作業か」を具体的に説明できるようにしておく。

• それに対して金額を設定しているので、見合わないものは受け入れられない。

顧客に受け入れられなければ仕事が取れないので、値引きも考える。

• ただし、あまり値引きすると原価割れを起こすので、最低ゆずれないラインを決めておく。

◆その他

費用と内容のバランスで、顧客は「導入するか／しないか」を判断する。

• 費用が安くても、内容が薄かったり信頼性がなかったりすれば、費用の高いものを選ぶこともある。
• 機能範囲と費用の組合せについて、いくつかのパターンを用意し、顧客に選んでもらったり調整してもらってもいい。

システムのある機能について「それを完成させるためには、どんな細かい作業が発生するか」という洗い出しは、  
知識や経験がないと、なかなか難しい。  
また、システム開発のある作業について「その作業には、何時間／何日くらいかかるか」という想定も、同様。

• 研修レベルではピンとこないことも多いが、「そういった洗い出し作業／工数算出が必要となる」ということを覚えておくこと。

見積は本来、営業、プロジェクトマネージャー、上級ＳＥレベルの仕事。  
新人がすぐにこういった作業にたずさわることは、ほとんどない。  
ただし、仕事を取るため、プロジェクトを運営するためには、こういった作業が必要になることを意識しておく。

• （プロジェクト全体ではなくても）個人レベルの作業項目洗い出しなどは、すぐにでも必要になる感覚。
  「○○を作るには、どんな細かい作業が必要になるか」をひとつひとつ覚えていくこと。

Copyright © Xincor miXell Co., Ltd. All rights reserved