ソースコード診断とは｜動的診断との役割と発注前の確認事項

ソースコード診断を検討すると、「コードを渡せばシステム全体を確認できる」と考えやすくなります。しかし、対象モジュール、依存関係、設定、確認目的を決めないまま依頼すると、何を確認したかと何を対象外にしたかを説明しにくくなります。

結論から言うと、ソースコード診断は、対象モジュール・確認目的・提供条件を決めてから比較します。稼働中の挙動を確認する動的診断とは、確認できる観点と成果物が異なるため、どちらを使うか、併用するかを目的から整理します。

発注準備では、提供できる範囲、閲覧権限、報告書の記載粒度、修正後の確認を先に確認します。コードの取扱いと診断の対象を一つの表で整理すると、開発・運用・調達の担当が同じ前提で判断できます。

本記事で分かること

• ソースコード診断で対象にする範囲
• 動的診断との役割の違い
• コード提供時に確認する条件
• 報告後の修正と再確認の進め方

結論：対象モジュールと確認目的を先に決める（早見表）

ソースコード診断では、リポジトリ全体か一部かを曖昧にせず、対象モジュール・確認目的・提供条件を一つの表にします。対象外にする範囲と理由も残しておくと、報告書の読み方や追加確認の判断がしやすくなります。

ソースコード診断で確認する範囲

リポジトリ全体か一部かを曖昧にしません。対象となる機能、関連する設定、確認から除外する範囲を分け、依頼先がどの範囲を確認する前提かを見積書で照合します。

対象モジュール

対象モジュールは、開発上の名称だけでなく、どの業務機能や利用者の操作に関係するかを記録します。たとえば申込み、管理、外部連携などの役割が分かれば、開発担当以外の関係者も対象の位置付けを確認できます。対象に含める理由と、管理する担当を対応付けます。

対象を決める際は、現時点のコード構成だけでなく、診断中に大きな変更が予定されているかを確認します。改修途中の部分を含めるか、別の版で確認するかを発注前に決め、見積の前提に記載します。名称が近いモジュールを一括にせず、確認したい目的に沿って分けます。

依存関係と設定

関連するライブラリや設定は、対象モジュールの説明に関わる情報です。すべてを同じ方法で提供するのではなく、確認に必要な範囲、提供できる方法、確認の窓口を整理します。設定に関する情報は、誰が管理し、どの環境に関係するかも記録します。

外部サービスや別のチームが管理する要素がある場合は、自社だけで提供範囲を決めません。管理者、契約上の窓口、閲覧できる条件を確認します。提供できない情報がある場合は、対象外として扱うのか、別の確認方法を検討するのかを発注前に関係者で判断します。

除外範囲

除外範囲は、今回確認しない部分を明確にするための情報です。別のリポジトリ、外部サービス、管理者の承諾が確認できない部分などを列挙し、除外した理由を残します。除外したことを隠すのではなく、対象範囲の前提として報告書と見積書で確認できる形にします。

将来の変更で除外範囲を見直す場合に備え、見直すきっかけも記録します。たとえば機能の統合、管理者の変更、外部連携の追加があったときに、対象表を更新する担当を決めます。除外範囲を先に整理しておくと、診断後に未確認の領域が判明した際にも対応を検討しやすくなります。

動的診断との役割を分ける

コードの確認と稼働中の挙動確認は、目的と成果物が異なります。どちらか一方を自動的に代替とせず、何を確認したいのか、どの対象を説明したいのかから役割を分けます。

確認できる観点

ソースコード診断は、合意した対象モジュールや関連情報を確認するための方法です。動的診断は、稼働する画面や機能、利用者が触れる経路を確認するための方法です。どちらが広いかを一般化するより、今回の目的と対象に対して何を確認したいかを一文で定義します。

手動診断とツール診断の違いも参照し、確認方法の名称だけで依頼内容を決めないようにします。依頼先へは、対象、確認したい観点、成果物に記載してほしい内容を伝え、見積書の条件と一致しているかを確認します。

併用時の依頼順

コードの確認と稼働中の挙動確認を併用する場合は、どの対象をどちらで確認するかを先に整理します。二つの依頼を別々に進める場合も、対象モジュールと画面・機能の対応関係を残し、結果を照合する担当を決めます。重複する範囲と、片方だけで確認する範囲を明確にします。

依頼の順番は、開発の状況、公開予定、対象の安定度、修正の担当に合わせて決めます。実施日だけを先に決めるのではなく、対象を確定する時点、報告を受ける時点、修正を確認する時点を予定に入れます。変更が起きた場合は、どの診断の対象表を更新するかを共有します。

結果の照合方法

報告書を受け取ったら、対象モジュールと対象画面・機能の対応を確認します。結果を同じ一覧に貼り付けるのではなく、どの対象で確認した内容か、対象外だった内容かを分けます。修正担当が複数いる場合は、担当と確認する範囲を対応付けます。

セキュリティ診断の発注ガイドを参考に、対象、成果物、再確認の条件を同じ仕様表にまとめます。二つの結果に差があった場合は、どの対象と条件の違いによるものかを整理し、追加確認が必要かを関係者で判断します。

提供・報告・修正の条件

秘密情報の取扱いと修正確認の範囲を契約前に確認します。コードを提供する方法、閲覧権限、報告書の記載粒度、修正後の確認を、対象表とは別に条件表へ整理します。

提供方法と閲覧権限

コードを提供する場合は、対象モジュールごとに、誰が提供を承認し、どの方法で閲覧できるようにするかを確認します。利用できる期間、通常の質問窓口、判断が必要な場合の連絡先も整理します。提供する情報と提供しない情報を分け、管理者の確認を経てから準備します。

秘密情報や個人情報を含む可能性がある場合は、社内の取扱いルールと契約上の確認事項に沿って進めます。依頼先に渡す情報を増やすことが目的ではなく、合意した対象を確認するために必要な範囲を決めることが重要です。未確認の提供条件は、見積の前提として確定させません。

報告書の記載粒度

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

対象外にした理由や、確認に使った版が報告書で追えると、後で変更があった場合に見直す範囲を判断できます。内容を受け取ったら、発注時の対象表と照合し、対象の認識が違っていないかを確認します。追加の質問は、対象と目的に結び付けて整理します。

修正後の確認

修正後の確認では、どの指摘に関係するモジュールを確認するか、どの版を対象にするか、結果をどのように受け取るかを決めます。修正担当と確認担当が異なる場合は、完了の連絡を誰が受けるかも整理します。追加の変更があれば、当初の対象との違いを残します。

Webアプリ診断の対象範囲を参照し、コードの変更が画面・機能・認証後の範囲にどう関係するかを確認します。修正後の確認を発注時の条件に含めると、報告から次の作業へつなげやすくなります。

まとめ

ソースコード診断では、対象モジュール、確認目的、提供条件、除外範囲を先に整理します。動的診断と併用する場合も、対象と成果物を分け、報告書・修正・再確認の担当を対応付けることが重要です。

ソースコード診断に関する整理は、手動診断とツール診断の違いと、お役立ち記事一覧から確認できます。