LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

外部エンジニアが出してきた設計書やコードを見る場を、契約には何と書けばよいのでしょうか。「レビュー」の一語では誰が出て何を持ってくるのかが決まらず、当日に相手の資料とこちらが見たいものがずれます。

枠組みがあります。IPA（独立行政法人情報処理推進機構）の「共通フレーム2013」です。*1 規格そのものではなく、ソフトウェアの作り方を定めた国際規格に合わせて作業を並べた手引で、関わる人々が同じ言葉で話すことができる共通の枠組みを提供している、とIPAは説明します。*2 参照したのは第3部です。*1

断りが2つあります。1つは、技術レビューという語が資料に出てこないことです。*1 この記事では技術レビューを、成果物の中身を技術の観点から見る場の意味で使います。2つめは、IPAが2021年に共通フレーム2013の改訂を行わないと決めており、ISO/IEC/IEEE 12207:2017（JIS X 0160:2021）には整合しなくなる、と説明していることです。*2 ただし、ソフトウェアに閉じた範囲で従来どおり企画、開発、運用を行う場合においては不都合は生じない、ともあります。*2

見る作業は3つの名前に分かれている

この記事では、成果物や行われた作業を対象に、条件に合うかを確かめるものを「見る作業」と呼びます。この決め方はこの記事のものです。

資料は作業をプロセスという単位で並べます。支援プロセスは、開発そのものではなく開発を支える作業の区分で、7つが置かれています。文書化管理、品質保証、検証、妥当性確認、共同レビュー、監査、問題解決です。*1

このうち3つは上の基準に当てはまりません。文書化管理は、作成する文書の種類を決め、名称や文書コードを付与して識別できるようにし、最新版を識別するための管理を行うものです。*1 品質保証は、不必要な評価作業や有害な重複作業を排除するため関連するプロセスを調整するものです。*1 問題解決は、問題が発見された時点で問題記録票が起票され、プロジェクト期間を通じて管理保存されるものです。*1 順に文書の扱い、見る作業の置き方、見つかった後の処理です。

妥当性確認も候補から外しました。資料は、意図された用途に対応したかを見るものとし、そこでいう用途とは利用者の視点に立った用途に適合したという意味だ、としています。*1 ただし第3部でこのプロセスに付いたガイダンスは、この用途の説明だけです。誰が行うかも、いつ行うかも書かれていないため、契約に書いても中身が決まりません。この判断はこの記事のものです。

残る3つが検証、共同レビュー、監査です。この3つには、誰が行うか、何を見るか、いつ行うかのどれかに記述があります。

取得者は発注する側、供給者は請け負う側で、外部エンジニアに任せる場面では自社が取得者にあたります。

検証は対象ごとに突き合わせる相手が決まっている

3つのうち何を見るかが細かいのが検証です。資料は4.3.2の下に対象ごとの項を立て、対象は契約、プロセス、要件、設計、結合の5つです。*1

うち4つには、何をもとに行うかが書かれています。要件の検証はシステム要件定義書やソフトウェア要件定義書など、設計の検証はシステム設計仕様書やソフトウェア設計仕様書など、結合の検証はソフトウェア設計仕様書などをもとに行う、という形です。*1 結合は別々に作った部分を組み合わせることで、これはこの記事での言い換えです。

契約の検証だけは見る側と見られる側が入れ替わります。もとにするのは提案依頼書又は見積依頼書などで、発注する側が条件を示して提案を求める文書です。見られるのは、供給者から提出された提案書又は見積書などです。*1 供給者が提案書の提出前に行うこともある、ともあります。*1

残るプロセスの検証には、もとにする文書がありません。プロセスとは、決めた手順どおりに作業が行われたかです。資料はここで、そのとおりに実施したことの確認が事後では困難な作業については検証の方法を事前に考慮しておくべきだとし、コーディング規約を守っているかどうかは作成したコードを見ることによって確認できるが、デザインレビュー（設計の内容をその場で見て指摘する場）の実施方法が規定されていても、記録の方法によってはそのとおりに実施したことが確認できない場合がある、と書いています。*1

この例がコードの1か所めです。第3部の支援プロセスの節（4.1から4.7）で、作ったコードを指して「コード」と書いているのは2か所です。文書コードのような別の意味の語は数えていません。2か所めは結合の検証で、結合されたソフトウェアが正規に構成管理されている検証済みのコードで構成されていることも確かめるべきである、とされています。*1 構成管理は、どの版がどれかを決めて管理することです。ただし監査の対象は成果物と活動の両方とされ、*1 コードを除くとは書かれていません。数えたのは語の箇所で、コードを見る場が2つだという意味ではありません。この数え方はこの記事のものです。

なお4.3.2には、この5つのほかに4.3.2.5という項があります。*1 「標準」「規約」「規定」の意味の違いを述べたもので、対象ではないため並びからは外しました。これはこの記事の扱いです。

共同レビューと監査の条件

資料は共同レビューを、取得者と供給者間の公式な、契約上定められたやり取りのための枠組みを規定するものとしています。*1 契約に定められた手順に従い、各段階での成果物の内容や進捗状況に関して同意を得る場であり、管理面と技術面の両方からなり、契約期間中開催されます。*1

評価の材料として4.5に挙がっているのは、プロジェクト進捗状況報告書や工程管理表等です。*1 設計仕様書やコードは挙がっていません。この不在は第3部の4.5を読んで確かめたもので、資料が「見ない」と書いているわけではありません。

監査には立場の条件が付きます。組織内部の監査者が監査を行う場合には、監査対象となる組織から独立した別の組織に所属している必要があるとされ、過去に開発の活動に携わった製品に対する監査を避ける必要がある、とも書かれています。*1 外部の第三者に監査を委託してもよい、ともあります。*1

時期の書き方も違います。監査の目的が果たせるような時期に実施する必要があるとされ、作業が手順どおりに行われていることの確認は作業が完了してしまってからでは不可能な場合もある、とあります。*1

つまずきやすい難所

引っかかる点を2つ挙げます。発注する側が契約の前に手を打てるものです。

1つめは、場として終わる作業は実施を後から示しにくい点です。コードは残るので見れば確認できますが、デザインレビューは記録の方法によっては確認できない場合がある、とされています。*1

2つめは、設計の検証に誰を入れるかです。資料は、設計の検証には必要に応じて特定の領域の専門家を含めるべきだとし、ハードウェアと密接に絡むようなソフトウェアの設計の検証にはハードウェアの専門家を含めるとよい、と例を挙げています。*1 どの領域が要るかは契約の前に決めます。これはこの記事の読み方です。

外注時に決めておきたい点

契約の前に決める点を3つ挙げます。この3つはこの記事のもので、資料が契約条項を示すわけではありません。

1つめは、契約に書く名前を3つから選ぶことです。文書と突き合わせたいなら検証、二者で同意を取りたいなら共同レビュー、独立した立場から見たいなら監査。この対応づけはこの記事のものです。

2つめは、表で空いているところを自分で埋めることです。検証なら、資料は契約の検証以外の実施者を書いていないので、誰が見るのかを契約側で決めます。監査なら内部に頼むのか外部に委託するのかを決めます。

3つめは、監査を入れるなら相手の手が要ると見込むことです。資料は、監査を受ける側が監査のための場所、設備及びツールを提供したり、監査者がインタビューできるように開発者の予定を調整する場合がある、としています。*1 監査者が行う調査は6つ挙がっており、*1 うち監査のためのレビュー又はテストを実施して調査する、製品を使用して調査するの2つは相手の作業が増えます。この見方はこの記事のものです。

契約終了時に決める項目は、別の記事「SES契約終了で決める6項目」で整理しました。

まとめ：契約に書く名前を3つから選ぶ

読み取れることは3つです。第一に、支援プロセス7つのうち、成果物や行われた作業を対象にして条件に合っているかを確かめるものは、検証、共同レビュー、監査の3つです。妥当性確認は第3部のガイダンスが用途の説明だけなので外しました。この絞り込みはこの記事で行いました。第二に、検証は対象が契約、プロセス、要件、設計、結合の5つに分かれ、うち4つにもとにする文書が挙げられています。第三に、監査には、組織内部の監査者が監査を行う場合には監査対象となる組織から独立した別の組織に所属している必要があるという条件が付きます。以上から、契約に書く名前をこの3つから選んでおくことを提案します。ただし検証の実施者のように資料が書いていないところは残ります。この提案はこの記事のものです。

よくある質問

出典

1. *1　参考：IPA「共通フレーム2013」第3部 共通フレームとガイダンス（PDF）（https://www.ipa.go.jp/publish/qv6pgp000000107j-att/000062659.pdf）。出典：独立行政法人情報処理推進機構「共通フレーム2013」第3部（全42ページ）。支援プロセスの構成（文書化管理・品質保証・検証・妥当性確認・共同レビュー・監査・問題解決）と、4.1文書化管理・4.2品質保証・4.7問題解決の各ガイダンス、4.3検証プロセスのガイダンス（4.3.2.1契約・4.3.2.2プロセス・4.3.2.3要件・4.3.2.4設計・4.3.2.6結合の各検証ともとにする文書、コーディング規約とデザインレビューの記録の例、結合されたソフトウェアの確認、設計の検証への専門家の参加）、4.4妥当性確認のガイダンス、4.5共同レビュープロセスのガイダンス（取得者と供給者間の公式な契約上定められたやり取りの枠組み、管理面と技術面の両方、契約期間中の開催、社内の二者間への適用とSLAの例、進捗状況報告書等による評価）、4.6監査プロセスのガイダンス（成果物と活動の両方が対象、組織内部の監査者の独立性の条件、外部委託、監査の時期、監査者が行う6つの調査、監査を受ける側の協力）の一次情報として（2026年9月確認）
2. *2　参考：IPA「国際規格/JIS 改訂に対応する『共通フレーム』の利用について」（2021年9月1日）（https://www.ipa.go.jp/publish/qv6pgp000000107j-att/000093137.pdf）。共通フレームが関わる人々に同じ言葉で話すことができる共通の枠組みを提供するものであること、共通フレーム2013の改訂を行わないこととしたためISO/IEC/IEEE 12207:2017（JIS X 0160:2021）には整合しなくなること、ソフトウェアに閉じた範囲で従来どおり企画・開発・運用を行う場合は不都合が生じないとされていることの一次情報として（2026年9月確認）

Tweet