システムの見積もり

はじめに

これは、システムの受注の際に何をよりどころに、何を見積もっているのかを自分なりにまとめたものです。
残念ながら基本日本の技術者は時間売りです。
なので、その作業にどれだけ時間がかかるかで見積もります。
（これだと、優秀な技術者ほど安くなっちゃうけど仕方ない）

見積もりの際に漏れないようにした備忘録でもあります。
各社それぞれの指針があり正解はありません。
項目の言葉の定義も違うかもしれません。

なお、これはあくまで開発にかかわる作業を見積もったもので、工数見積もりとなる。
その後金額をどのように提示するかは営業活動となる為金額には言及しない。

備忘録的なものなのでぼちぼち更新していきます。

見積もり項目（＋見積もり時にすること）

()書きされているものは見積もり時に行う作業を記載しています
見積を作る際の必須作業なので備忘録です。

• (事前作業)
  • 見積もり前提の明確化
  • お客さんに請求できるコストと出来ないコストの切り分け
• 設計
  • 解析作業
    • 要件追加の場合は影響調査
    • 業務解析 ※総合試験に影響
    • プロトタイプ作成
  • 論理設計作業
  • 物理設計作業
    • 機能設計
    • データ設計
      • 項目設計
      • ERD
      • DFD
• インターフェース設計
  • 他システムとのAPIやデータ連携
• 開発
  • 画面開発
  • バッチ開発
  • レポート開発
  • 単体試験
• 環境
  • 環境設計
  • 環境構築
  • 証明書
  • クラウド
• リリース作業
• 試験
  • 総合試験
  • 結合試験
  • 受入試験（サポート）
  • 性能試験（負荷試験を含む）
  • セキュリティ診断
• 移行作業
  • 環境移行
  • データ移行
  • 移行計画
  • 移行設計
  • 移行テスト
  • 移行リハーサル
• 性能設計
• 付帯作業等
  • 管理工数
  • 開発設備
• 打合せ
  • 交通費等
  • 会議室などの施設費等
• 納品
  • 納品物のとりまとめ
  • 社内検収
• 運用費
• 保守費
• (事後作業）
  • ドキュメントの整合性
    • 案件名タイトルなどが一貫しているか
    • ドキュメント間の関係が保たれているか
      ※別紙参照などの別紙が明確にわかるようになっているか
    • 最終的に印刷物で提出などを求められるので印刷した際に以下の様な事がないか確認
      • 見切れ
      • 別紙であれば印刷時にわかるように
        ヘッダに別紙名が確認できるようにしておく
      • ページ番号ずれなど
• (追加開発時の注意事項)

環境

環境構築は誰が環境を運用後管理していくのかで、設計主体が変わることもあり、どこまで開発サイドで関わるかを事前に確認する必要あり。
IT部門を持たない顧客の場合すべてを開発で行ってもらえることを前提としている場合が多く、顧客の体制も考え相談する必要がある。

環境設計

環境構築

証明書

• 証明書の管理を相手方が行うのか？（契約も含め相手方で行う場合は不要）
• 請負側で手配を行う場合はその手続きなどにかかわる費用を計上
• 証明書のインストールなどを行う場合は作業費を計上できるか確認
  基本的には作業が発生しその結果に責任が伴うため計上すべきと考える
  →環境構築費で計上
• 証明書発行費用(初回)は初期開発費に含めるべきか
  →契約が前提であれば運用費、保守費などの範疇で行うべきかを確認

証明書は発行タイミングを確認すること
本番稼働直前に行う場合は、発行までの日数を考慮したスケジューリングが必要
証明書の入れ替えは定期的に行う必要がありその作業を今後どのように行うかの確認は必要
→運用や、保守契約を結ばない場合は

交通費等

会議室などの施設費等

運用費

保守人は異なるものだが顧客によっては一緒に考えられていることも多いです。
IT部門を持つ顧客であれば運用はIT部門で行うとなることも多い。

システムの稼働をどう保証するかによってもかなりの幅で前後します。
例えば24時間365日稼働のシステムで即対応が必須となると、ずっと24時間対応できる要員を配置する必要がある（かなりの大規模システムでもなければ無いが）。

忘れがちだが、実際の稼働とは別に報告書作成が必要となります。
報告書の作成頻度内容の粒度などによって時間は変化するためその点の確認も必要となる。

保守費

クラウド

追加開発時の注意事項

• 項目の追加などがある場合
  • 項目の追加（登録画面への追加）だけか？
    • そのテーブルから一覧出力している個所に追加しなくてもよいか
    • そのテーブルの情報を外部にインターフェースしていないか
• 見出しラベルの変更
  • 本当にその個所だけか？
    • 同一ラベルを使用している、画面、帳票、インターフェース(CSVタイトル等)はないか

さいごに

実際に見積もりの工程を考えると、要件が明確でないと各所にリスクが含まれてきます。
リスクをどれだけとるかという事は、曖昧な分だけ幅が大きくなり要件定義の重要性が際立ちます。
場合によってはリスクが大きすぎて、正確な見積もりができず、リスクを見誤れば開発側は赤字となります。
また、さいしょにで記述した通り基本的に技術者は時間売りです。
という事は見積りの内容でスケジュールが建てられます。
結果、発注側も必要な時期までにシステムが出来上がらないなどの不利益をこうむります。
このリスク分で発生した要件時に無かった項目を再見積もりしようとすると、トラブるケースが多いのも困ったものです。
故に、発注側にはRFPや要求定義書を明確にしてもらう必要があり。
双方合意の要件定義書を作成したうえで見積もりが理想です。