ソースコード診断の見積条件｜費用を比べる前に確認すること

ソースコード診断の見積書を比べるとき、コード量だけで条件をそろえようとすると、対象モジュール、使用言語、依存関係、確認の深さ、提供条件の違いを見落とします。同じリポジトリに見えても、どの範囲をどの目的で確認するかによって依頼の前提が変わります。

結論から言うと、ソースコード診断の見積は、対象モジュール・使用言語・依存関係・確認の深さが一致してから比較します。各見積書の費目を、対象表、確認条件表、報告・再確認表の同じ欄へ写し、前提差を質問として残します。

この記事では、コードの範囲、確認の深さ、提供・報告・修正の条件をそろえる方法を整理します。見積書の合計ではなく、どのモジュールと条件を比較しているかを社内で共有しましょう。

本記事で分かること

• 対象モジュール・言語・依存関係のそろえ方
• 確認の深さと報告条件の整理
• 提供範囲と閲覧条件の確認
• 見積書を同じ条件表で比べる手順

結論：コードの見積条件をそろえる（早見表）

ソースコード診断の見積は、対象モジュール・使用言語・依存関係・確認の深さが一致してから比較します。対象外、提供条件、修正後の確認を別の欄にし、見積書の記載を同じ順番で読みます。

対象範囲をそろえる

行数だけでなく、モジュールと依存関係を記録します。各見積書に渡す対象表には、対象モジュール、関連情報、除外範囲、変更予定を分けて記載します。

対象モジュール

対象モジュールは、開発上の名称だけでなく、どの業務機能や画面に関係するかを記載します。申込み、管理、外部連携などの役割を添えると、開発担当以外の関係者も対象を確認しやすくなります。対象に含める理由、管理者、確認する版を対応付けます。

対象モジュールが複数ある場合は、同じ行にまとめず、機能ごとに分けます。関連があっても、別の管理者がいる、変更予定が異なる、今回の目的と関係しない場合は、対象外として理由を残します。見積書の対象表現と自社の対象表を照合します。

使用言語と依存関係

使用言語と依存関係は、対象モジュールと切り離さずに整理します。どのモジュールにどの関連情報があるか、誰が管理し、どこまで提供できるかを対象表に記載します。すべてを一括で渡す前提にせず、確認に必要な範囲と提供条件を分けます。

外部ライブラリや別のチームが管理する要素がある場合は、自社だけで対象に含めません。管理者、契約上の窓口、閲覧できる条件を確認し、対象外にする場合は理由を残します。関連情報の扱いが見積書ごとに異なる場合は、同じ条件として比べず質問します。

除外範囲

除外範囲には、別のリポジトリ、外部サービス、承諾を確認中の領域、今回の目的と関係しない機能などを記載します。除外した理由と、どの変更があれば見直すかを残すと、報告書を読む際に今回確認していない範囲を共有できます。

手動診断とツール診断の違いを参照し、対象、確認方法、成果物を同じ仕様表で整理します。対象外を空欄にせず、見積書に含まれる範囲との違いを比較表に残します。条件が変わった場合は、対象表と見積書の前提を更新します。

確認の深さをそろえる

自動的な確認と人によるレビューの比率を同じ条件で比べます。確認したい観点、報告書の記載粒度、修正後の確認を、各見積書で同じ欄にそろえます。

確認観点

確認観点は、対象モジュールの役割と発注目的に対応付けます。コードを提供することだけで、すべての機能を同じ条件で確認する依頼にはなりません。どの業務機能、連携、設定に関係するかを整理し、報告書で確認したい対象の記載を決めます。

見積書に確認観点が書かれている場合は、自社の対象表のどの行に関係するかを照合します。書かれていない場合は、対象と目的を示して質問します。回答を比較表に記録すれば、方式の呼び方が違っても、どの条件を比較しているかを社内で説明できます。

報告書の粒度

報告書では、対象モジュール、対象外、確認した版、関連する条件が追えるかを確認します。開発担当が対応に使う情報と、管理・調達の担当が説明に使う情報では、必要な粒度が異なる場合があります。受け取る担当と共有先を先に決めます。

対象と報告の対応が分かると、変更があった場合にどの範囲を見直すかを判断しやすくなります。報告書の見栄えだけで比較せず、対象表の行ごとに必要な記載があるかを確認します。対象外の扱いも、同じ条件表で比較します。

修正確認の範囲

修正確認では、どのモジュール、版、関連する機能を確認するかを決めます。修正担当と確認担当が異なる場合は、作業の窓口と完了を確認する担当を対応表に記載します。修正予定が別の変更に入る場合は、対象表と変更予定を更新します。

脆弱性診断の費用構造を参照し、対象、確認の深さ、成果物、再確認を同じ比較表で確認します。修正後の確認を発注時の条件に含めると、報告を受けた後の判断を進めやすくなります。

見積書を同じ条件に直して比べる

見積書に書かれた対象と条件を、社内の対象表・確認条件表・報告条件表の同じ欄へ写します。各社の記載順が異なっても、比較表の順番を変えずに前提差を質問します。

対象を同じ表へ写す

最初に、各見積書に書かれた対象モジュール、使用言語、依存関係、除外範囲を対象表へ写します。一行に複数の条件が書かれている場合も、対象の軸ごとに分けます。含まれるか分からない構成要素は、同じ条件として扱わず質問事項にします。

対象表の各行に、業務上の役割、管理者、確認する版、提供条件を対応付けます。これにより、見積書の表現が異なっていても、同じ範囲を扱っているかを確認できます。変更予定がある場合は、対象表と見積書の前提を更新します。

条件差を質問する

提供する情報、閲覧権限、確認観点、報告書、修正確認の条件に差がある場合は、比較表の該当欄ごとに質問します。質問は、どの前提で回答されているかを確認するために行います。回答を受けたら、対象表と条件表の関係する行を更新します。

追加情報を渡す場合は、すべての依頼先に同じ情報を共有します。片方だけに詳細な対象表を渡すと、比較表の前提が変わります。質問と回答の履歴を残すことで、社内説明で条件差と判断理由を追いやすくなります。

社内説明に残す

社内説明には、対象モジュール、提供条件、確認の深さ、報告、再確認、未確認事項、判断した担当を記載します。見積書の合計を中心にせず、どの依頼がどの条件を含むかを対象表から説明します。対象外と確認中の範囲も共有します。

セキュリティ診断の発注ガイドを参考に、目的、対象、期限、社内の担当をそろえます。判断後に条件が変わった場合は、何が変わり、誰が影響を確認したかを記録します。比較表を更新すれば、次の見積依頼にも同じ条件を使えます。

まとめ

ソースコード診断の見積は、対象モジュール、使用言語、依存関係、確認の深さ、提供・報告・再確認の条件を同じ表でそろえて比べます。見積書の費目を対象・確認・報告・再確認の欄へ写し、条件差を質問として残すことで、社内の判断を共有しやすくなります。

コード診断の見積条件は、手動診断とツール診断の違いと、費用の記事一覧から確認できます。