LASSIC Media らしくメディア

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

外部エンジニアが作った設計書やコードを確かめる場を設けたいが、契約に何と書けばよいのか分からない。「レビュー」とだけ書いておいたら、当日に相手が持ってきた資料と、こちらが見たかったものが違っていた——。外部エンジニアに開発を任せる現場では、こうした食い違いが起こりがちです。外部エンジニアの技術レビューとは、社外のエンジニアが作った成果物の中身を、技術の観点から確かめる場を指します。

何を確かめるのかを決める手がかりになるのが、IPA（独立行政法人情報処理推進機構）の「共通フレーム2013」です。成果物を確かめる作業を検証・共同レビュー・監査に分け、誰が行うか、何を見るか、いつ行うかを区分ごとに書いています。ただし万能ではなく、誰が行うかが一部にしか書かれていない区分もあります。本記事では、外部エンジニアに開発を任せる発注側の担当者に向けて、3つの区分の違い、つまずきやすい点、そして外部に委託するときに確認したい点を整理します。

外部エンジニアの技術レビューとは

共通フレーム2013は、ソフトウェアの作り方を定めた国際規格に合わせて、開発の作業を並べた手引です。規格そのものではありません。IPAは、関わる人々が同じ言葉で話すことができる共通の枠組みを提供するものだと説明しています。^*2 発注する側と外部エンジニアとで「レビュー」の意味が食い違いそうなときは、この手引の言葉にそろえておくと、話し合いが進めやすくなります。

ただし、技術レビューという語は、この手引の第3部「共通フレームとガイダンス」には出てきません。本記事では、成果物の中身を技術の観点から確かめる場という意味で、この語を使います。手引の中でこれにあたるのは、開発を支える作業をまとめた「支援プロセス」のうち、検証、共同レビュー、監査の3つです。技術レビューを契約に書くときに、このどれを指すのかを決めておけば、当日に誰が出席し、何を持ってくるのかがはっきりします。

手引では、発注する側を取得者、請け負う側を供給者と呼びます。外部エンジニアに開発を任せる場面では、自社が取得者、外部エンジニアの側が供給者にあたります。以下でも、この2つの語を使って説明します。

支援プロセスとは

支援プロセスは、開発そのものではなく、開発を支える作業の区分です。文書化管理、品質保証、検証、妥当性確認、共同レビュー、監査、問題解決の7つが置かれています。このうち、成果物や行われた作業を対象に、条件に合っているかを確かめるのは、検証、共同レビュー、監査の3つです。残る4つは、確かめる作業を支える側の区分です。

文書化管理は、作る文書の種類を決め、名称や番号を付けて見分けられるようにし、最新版を管理する作業です。品質保証は、評価作業のむだや重なりを省くために、関連する作業を調整するものとされています。問題解決は、問題が見つかった時点で問題記録票を作り、プロジェクトの期間を通じて管理し保存するものです。^*1

妥当性確認は、意図された用途に合っているかを、利用者の視点から確かめるものです。ただ、第3部でこの区分に付いた説明は、ここでいう用途とは何かという説明だけで、誰が行うかも、いつ行うかも書かれていません。契約に「妥当性確認」とだけ書いても中身が決まりにくいため、本記事では検証、共同レビュー、監査の3つを扱います。3つについて手引が書いていることを、次の表にまとめました。

検証とは

検証は、3つの中で何を見るかがいちばん細かく書かれている区分です。対象は契約、プロセス、要件、設計、結合の5つに分かれ、このうち4つには、何をもとに確かめるかが挙げられています。要件の検証はシステム要件定義書やソフトウェア要件定義書など、設計の検証はシステム設計仕様書やソフトウェア設計仕様書など、結合の検証はソフトウェア設計仕様書などをもとに行います。^*1

結合とは、別々に作った部分を組み合わせることです。結合の検証では、組み合わせたソフトウェアが、正規に構成管理（どの版がどれかを決めて管理すること）された検証済みのコードでできているかも確かめるべきだとされています。^*1 外部エンジニアが納めたコードについて言えば、どの版を組み合わせたのかを確かめる作業にあたります。

契約の検証だけは、確かめる相手が成果物ではなく、供給者から出された提案書や見積書などになります。もとにするのは、発注する側が条件を示して提案を求める提案依頼書や見積依頼書などです。^*1 実施者については、取得者が行うとされる一方、供給者が提案書を出す前に行うこともあると書かれています。

プロセスの検証は、決めた手順どおりに作業が行われたかを確かめるもので、もとにする文書は挙げられていません。手引は、手順どおりに行ったことを後から確かめにくい作業については、検証の方法を前もって考えておくべきだとしています。コーディング規約（プログラムの書き方の決まり）を守っているかは、作ったコードを見れば確かめられます。一方で、デザインレビュー（設計の内容を集まって確かめる場）は、実施の方法が決まっていても、記録の仕方によっては実施したことを確かめられない場合がある、とされています。^*1

共同レビューとは

共同レビューは、取得者と供給者の間の公式な、契約上定められたやり取りのための枠組みとされています。契約に定めた手順に従って、各段階での成果物の内容や進捗状況について同意を得る場で、管理面と技術面の両方を扱い、契約の期間中に開かれます。^*1 発注する側と外部エンジニアの二者が合意する場である点が、検証や監査との違いです。

評価の材料として挙がっているのは、プロジェクト進捗状況報告書や工程管理表などです。^*1技術面も含む場とされているので、設計の中身まで話し合いたいときは、どの成果物を持ち寄るのかを契約に書き添えておくと、当日の食い違いを避けやすくなります。

監査とは

監査の対象は、成果物と活動の両方です。検証や共同レビューと違うのは、誰が行うかに条件が付く点です。組織内部の監査者が監査を行う場合には、監査対象となる組織から独立した別の組織に所属している必要があるとされています。外部の第三者に監査を委託してもよい、とも書かれています。^*1 開発を進めている部署の人がそのまま監査を担う形は、この条件に合いません。

時期については、監査の目的が果たせるような時期に実施する必要があるとされています。作業が手順どおりに行われていることの確認は、作業が完了してしまってからでは不可能な場合もある、ともあります。開発が終わってからまとめて監査を入れる予定なら、手順を確かめたい作業がいつ行われるのかを先に見ておきます。

つまずきやすい点

一つ目は、打ち合わせのように記録が残りにくい作業について、行ったことを後から示せないことです。コードは残りますが、デザインレビューは、記録の仕方によっては、行ったことを後から確かめられない場合があります。外部エンジニアと設計の打ち合わせをするなら、誰が出席し、何を指摘し、どう直すことにしたかをどこに残すのかを、契約の前に決めておきます。

二つ目は、設計の検証に誰を加えるかを決めていないことです。手引は、設計の検証には必要に応じて特定の領域の専門家を含めるべきだとし、ハードウェアと密接に絡むようなソフトウェアの設計の検証には、ハードウェアの専門家を含めるとよいという例を挙げています。^*1 自社に詳しい人がいない領域があるなら、その領域を見られる人に、検証の場に加わってもらう段取りが必要です。

三つ目は、検証を契約に書いたのに、誰が確かめるのかが空いたままになることです。手引が実施者を書いているのは契約の検証だけで、要件や設計の検証を誰が行うかは第3部に書かれていません。自社の担当者が見るのか、外部エンジニアの側で確かめて結果を報告してもらうのかを、契約の段階で決めておきます。

外部に委託するときに確認しておきたい点

まず、技術レビューとして契約に書く区分を、3つの中から選びます。成果物を設計書などの文書と突き合わせたいなら検証、発注する側と外部エンジニアの二者で内容と進み方に合意したいなら共同レビュー、開発に関わっていない立場から見てもらいたいなら監査、という選び方ができます。

次に、選んだ区分で手引が書いていない部分を、自社で決めて契約に書き入れます。検証なら、誰が確かめるのかと、何の文書をもとにするのか。共同レビューなら、進捗状況の資料に加えて、どの成果物を持ち寄るのか。監査なら、社内の独立した部署に頼むのか、外部の第三者に委託するのか。表で空いているところが、契約で決める項目です。

最後に、監査を入れるなら、外部エンジニアの側の協力が要ることを見込んでおきます。手引は、監査を受ける側が監査のための場所、設備及びツールを提供したり、監査者がインタビューできるように開発者の予定を調整したりする場合がある、としています。^*1 監査者が行う調査は6つ挙がっており、そのうち監査のためのレビューやテストを実施する調査と、製品を使う調査の2つは、受ける側の作業も増えやすい調査です。

なお、契約が終わるときに決めておく項目は、「SES契約終了で決める6項目」で整理しています。

まとめ：技術レビューで確かめておきたい3つの点

外部エンジニアの技術レビューを契約に書くうえで、確かめておきたい点は3つに整理できます。第一に、技術レビューを検証、共同レビュー、監査のどれとして行うのかを決めること。第二に、選んだ区分について、誰が行うか、何を見るか、いつ行うかのうち手引が書いていない部分を、自社で決めて契約に書き入れること。第三に、デザインレビューのようにその場で終わる作業は、何をどこに記録するのかを前もって決めておくことです。この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共同レビュープロセスのガイダンス（取得者と供給者間の公式な契約上定められたやり取りの枠組み、管理面と技術面の両方、契約期間中の開催、進捗状況報告書等による評価）、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