ちょき☆ぱたん お気に入り紹介 (chokipatan.com)
第１部 本
IT
システム開発のための見積りのきほん（佐藤大輔）
『図解まるわかり システム開発のための見積りのきほん』2025/9/10
佐藤 大輔 (著), 岡本 健 (著), 山口 貴也 (著)
（感想）
見積りを「実現可能なプロジェクト完遂のプラン案」と捉えて、その目的や背景から、具体的な手法、実務上のポイントやトラブル対策に至るまで、システム開発のための見積りの基本を幅広く解説してくれる入門書で、主な内容は次の通りです。
第1章 見積りの基本
第2章 見積りに必要なシステム開発の基礎知識
第3章 見積りの手法
第4章 見積りのチュートリアル
第5章 見積りの実務
第6章 見積り時に考えておくべきポイントとリスク
第7章 プロジェクト開始後の見積りと管理
＊
見開きで1つのテーマを取り上げて図解を交えて解説。末尾には「Point」も書いてあるので、簡単な復習もしやすいと思います。
「第1章 見積りの基本」では、「見積もりの流れ」として次の項目があげられていました。
１）要件定義：ユーザーの要件・要望の具体化・詳細化
２）概要設計：要件定義に基づき、大まかな機能の一覧やアーキテクチャなどをまとめた資料作成
３）見積り作成：フェーズごとにタスクを抽出して作業の見える化→作業量を予測・計測
……このうちの「要件定義」には……
・機能要件：プロジェクトの目的を達成するために必要な機能
・非機能要件：機能要件を実現するために必要な機能以外の要件（セキュリティ、パフォーマンス、ユーザビリティや可能性、保守性、信頼性、コストパフォーマンスなど）
……の２種類があります。
そして見積り時に考慮しなければならないこととしては……
・工数の基準は「人月」の単位が一般的で、1人月は1人の平均的なスキルを持つ開発者が1カ月にできる作業量
・ソフトウェアの規模の指標は機能数や画面数の他、テストケースの数やプログラムの行数、成果物の数や大きさ、クラスやメソッドの数などさまざまなものがある。
・原価には人件費や間接費、プロジェクトコストが含まれ、そこに粗利を加えたものが売価となる
・リスクの中で最も多く発生するのが、要件変更・仕様変更リスク
・プロジェクトにリスクは「必ず存在する」ので、さまざまな視点から抽出する必要がある
・抽出したリスクはプロジェクト全体で積極的に共有し・管理する
・タスクごとにバッファを積むのではなく、総工数など粒度の大きい単位から算出する
・バッファは仕様変更で10％、その他のリスクと合計して総工数の15～25％程度にする
……などが紹介されていました（一部の抜粋紹介です）。
＊
また「工期（納期）」の算出方法としては……
・何百のプロジェクトを検証した結果、平均的な工期は総工数の３乗根の2.7倍といわれている。さらに統計的に工期の圧縮限界は25％程度といわれている。
・工数を開発者の人数で割ることで工期を算出できるが、リソースはフェーズごとに違うので、計画はフェーズごとに立てる必要がある
……などのアドバイスがありました。
続く「第2章 見積りに必要なシステム開発の基礎知識」では、ITシステム開発の概要を学ぶことができます。例えば、そのごく一部を紹介すると……
・プロジェクト計画の基本的な考え方に「フェーズ」があり、フェーズには要件定義から概要（基本）設計、詳細設計・実装、テスト、リリース・運用などがある
・システム保守は大きなコスト負担を伴うので、DevOpsを用いて省力化・自動化する（開発に運用のサイクルを取り込み、シームレスに行うことで、最適な保守体制・環境を提供）
・見積もりを含むプロジェクト計画を作る際には、IDEなどの開発ツール群の使用を前提としよう（IDEや高機能のコードエディタ、AIを用いた効率化は必須のプロジェクト要件）
・コンテナやGitなどを使用した開発環境の自動化・効率化は現在のソフトウェア開発では広く用いられている
・外部システム連携は機能の数や複雑さ以上に、コミュニケーションコストや企業間の制約など工数を押し上げるので注意
＊
「第5章 見積りの実務」では、プロジェクト全体の流れについて「企画→提案依頼→要件定義・概要設計→見積り作成→発注・契約→設計・実装→テスト・検収→リリース→運用・保守と流れる」という概要の説明がありました。
また「多段階契約」について……
・多段階契約によって「見積りにかかるコスト」を別に負担することにより、開発側・ユーザー側双方のリスクを軽減できる
・多段階契約は概要設計を区切りとすることが多く、前工程は準委任契約、後工程を請負契約とすることが多い
「初期段階では、全体の工数の費用を正確に見積もることが難しいため、作業量に応じて報酬が発生する準委任契約が適しています。ここで、概要設計までを丁寧に進めることで、誤差の少ない見積りを作成します。
その後、作成した正確な見積りをもとに、残りの工程を請負契約でまとめて契約します。この段階では、工数や成果物が明確になっているため、いわゆる「モノ」に対する契約が成立します。これにより、前半は柔軟に、後半は確実にプロジェクトを進められるようになります。」
……なるほど。この契約方法はとても合理的だと思います。
さらに「保守の見積もり法」には次の２種があるそうです。
１）システム開発総額から割合で見積もる方法
（保守費用の割合は、責任範囲の広さによって5～20％程度まで変動する：5％は障害対応のみ、10％は原因の切り分けや初期調査も含む、20％はヘルプデスクの運営支援やネットワーク関連の対応まで含むなど）
２）月間保守に必要なリソースや工数を、ユーザーと合意して、月単位、年単位で契約する方法
＊
『図解まるわかり システム開発のための見積りのきほん』……見積りの基本から実務上のポイントまでを総合的に解説してくれる入門書で、見積りだけでなく、システム開発の流れについても概説があり、とても参考になりました。
ここで紹介した以外にも、「第6章 見積り時に考えておくべきポイントとリスク」では、「ブレは当たり前に存在するものとして受け入れ、そのうえで対応を考える方が結果的にリスクを小さくできます。」という前提のもと、ブレに対応しやすくする見積もり時の工夫や、実際にブレがでたときの対処の想定などの簡単なアドバイスもあります。
システムを開発するエンジニアの方や、システム開発プロジェクトに関わる事業部門の担当者、さらに開発を依頼するユーザーサイドの担当者の方も、知っておくと役に立つ情報が総合的に書いてあるので、とても参考になると思います。IT企業の社員教育にも役に立ちそうです。システム開発に関係のある仕事をしている方は、ぜひ読んでみてください☆
＊ ＊ ＊
なお社会や科学、IT関連の本は変化のスピードが速いので、購入する場合は、対象の本が最新版であることを確認してください。
Amazon商品リンク
興味のある方は、ここをクリックしてAmazonで実際の商品をご覧ください。（クリックすると商品ページが開くので、Amazonの商品を検索・購入できます。）
『システム開発のための見積りのきほん』