LASSIC Media らしくメディア

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

外部のエンジニアが書いたコードを、社内の誰がどこまで見ればよいのか分からない。レビューで出た指摘が直すべき不備なのか、見る人の好みなのかで、やり取りが何度も往復する——。外部エンジニアと一緒に開発を進める現場では、こうした食い違いが起こりがちです。外部エンジニアのコードレビューとは、外部エンジニアが関わるコードの変更を、社内のシステムに取り込む前に、書いた人とは別の人が読んで確かめることを指します。

反対に、外部エンジニアに技術レビューを頼み、社内で書いたコードや設計を見てもらう場面もあります。どちらの場合も、先に決めておくことはほぼ同じです。ただしレビューは万能ではなく、回数を重ねれば不具合がなくなるわけではありません。本記事では、外部エンジニアと開発を進めるマネージャーに向けて、レビューの基準、取り込みの条件、権限の渡し方、指摘の数え方、そして外部に頼むときに確認したい点を整理します。

外部エンジニアのコードレビューとは

外部エンジニアとのレビューには、2つの形があります。1つは、業務委託などで加わった外部エンジニアが書いたコードを、社内の担当者がレビューする形です。もう1つは、社内のコードや設計を、専門の知識を持つ外部エンジニアに見てもらう形です。後者は、技術レビューと呼ばれることもあります。

技術レビューとコードレビューは、見るものが違います。技術レビューは、使う技術の選び方やデータベースの表の分け方といった設計の判断を見ます。コードレビューは、1回ごとの変更差分（変更の前と後の違い）を読み、設計どおりに書かれているか、規約に沿っているかを確かめます。外部エンジニアと進める開発では、この2つを同じ人が兼ねることも、別々の人に頼むこともあります。

経済産業省の「システム管理基準」は、実装の管理活動の例として「実装結果のレビュー」を挙げ、情報システムの全ての構成要素が「設計を満足していることを示す裏付けを入手し、レビューする」としています。^*1 作ったものが設計書のとおりになっていることを、根拠を見て確かめるということです。コードレビューはこれを変更ごとに行います。契約の上でレビューをどう位置づけるかは「外部エンジニアの技術レビュー、契約で分ける検証と監査の違い」で扱っています。

何を基準に見るのか

最初に決めることは、レビューの基準です。基準が文書になっていないと、レビューする人はそれぞれの経験で判断します。その結果、外部エンジニアから見れば、同じような書き方が、ある人には通り、別の人には直すよう求められることになります。基準として渡すものは、設計書、コーディング規約（命名や書き方の決まり）、それにテストの結果の3つが中心です。

システム管理基準は、実装結果のレビューに続けて、実装の結果と、実装の際に発生した不具合およびその改善結果を記録し、改善の状況を追って確かめるよう求めています。^*1 コードレビューの指摘も、どの変更に対して何を指摘し、どう直したかを残しておくと、後から同じ誤りが繰り返されていないかを確かめられます。

セキュリティについては、デジタル庁の「政府情報システムにおけるセキュリティ・バイ・デザインガイドライン」（設計の段階からセキュリティ対策を組み込むための文書）が参考になります。実装の工程の要求事項として、脆弱性（攻撃に使われるおそれのある欠陥）を作り込まないようアプリケーションのセキュアコーディング（脆弱性を生まない書き方）が実施されていることを挙げ、チェックリストには、そのためのコーディング規約を策定しているかという項目があります。^*2 担当者ごとのミスやばらつきを防ぐため、セキュリティに関わるコードや設定は、テンプレートや自動化の機能を使って書くことが望ましいとも書かれています。

規約に書かれていない指摘は、「修正が必要な指摘」と「提案」に分けて伝えると、やり取りの往復が減ります。提案が何度も出る書き方は、次に規約へ追加するかどうかを社内で決めます。

取り込む前のレビューと承認

2つ目は、レビューをどの時点で必須にするかです。デジタル庁の技術レポート「CI/CDパイプラインにおけるセキュリティの留意点に関する技術レポート」は、CI/CD（コードの取り込みから本番への反映までを自動で進める仕組み）の運用について、ソースコードの変更差分を主たるブランチ（基準となるコードの系統）に取り込む際に、品質や信頼性が維持されるようルールを整備すべきだとしています。^*3

同じレポートは、そのルールの例として「別の関係者によるレビューや、上位者による承認を必須にする」ことを挙げ、自動で実行されるテストの結果を取り込みの条件にすることも一般的だとしています。本番環境に関わる重要なブランチには、複数の明示的な承認を求める構成にできることも示されています。^*3

本番環境への反映については、変更内容が適切で品質が確保されていることを証跡として保管することが重要で、レビューや承認を必須とすべきだとしています。^*3 外部エンジニアが書いた変更であれば、社内の担当者1人以上の承認と自動テストの合格を取り込みの条件にし、その記録をソースコード管理システムに残す、という形にしておくと進めやすくなります。

承認する人を1人に決めてしまうと、その人が休んだ日にはレビュー待ちの変更がたまります。承認できる社内の担当者を2人以上決めておき、どちらが見てもよい変更と、特定の担当者が見る変更を分けておきます。

外部エンジニアに渡す権限

3つ目は、コードの保管場所に対する権限です。同じ技術レポートは、ソースコード管理システムがSaaS（インターネット経由で使うサービス）の形をとることが多く、会社として契約した環境に、個人が作ったアカウントを招待してアクセス権限を付与することも珍しくないと述べています。個人のアカウントは私用の端末からも使えるため、パスワードなどの認証情報が盗まれると、ソースコードの改ざんなどにつながるおそれがあります。^*3

対策としては、個人アカウントの利用を禁止し、組織の利用者アカウントと完全に分けることが最も効果的とされています。招待を避けられない場合は、個人アカウントを組織の利用者アカウントに結び付け、会社のリポジトリ（コードの保管場所）には利用者アカウントからしか入れないようにする方法が示されています。^*3 外部エンジニアに渡すのは、担当する作業に必要なリポジトリの書き込み権限までにとどめます。

さらに、作業者に最小の権限しか与えないことや、変更に作業者の署名（誰が変更したかを示す電子的な印）を求めて、誰が変更したのかを確かめられるようにすることも挙げられています。^*3 レビューで承認した変更が、本当にその外部エンジニアの書いたものかを後から確かめられるようにするためです。参画の初日にアカウントを渡す手続きは「業務委託エンジニアの受け入れで決める5つの手続き」で扱っています。

指摘の数え方

4つ目は、レビューの指摘をどう数えるかです。IPA（情報処理推進機構）の「ソフトウェア開発分析データ集2022」は、プロジェクトのデータを集める際の定義として、レビュー指摘件数から、誤字・脱字などの編集上の軽微な問題の指摘、質問、改良提案を除外した件数を記入するよう定めています。^*4 指摘と質問、提案を分けて記録するという考え方は、外部エンジニアとのレビューにもそのまま使えます。

同じデータ集の業種編には、製作の工程（プログラムを書く工程）のレビュー指摘件数を、レビューにかけた作業時間1,000人時（1人が1時間働く量が1人時）あたりで示した表があります。中央値は、情報通信業が240.6件、金融・保険業が343.3件、製造業が1,857.0件です。^*5 製造業は情報通信業の約7.7倍になります。

集計したプロジェクトの数は、情報通信業が25件、金融・保険業が66件、製造業が17件です。情報通信業と製造業については、データ数が少ないので参考程度にするとIPAも書いています。^*5 業種によってこれだけ差が出る理由は示されていません。1件の指摘として何を数えるか、どこまで細かく見るかで、件数は大きく動くと考えておくべきでしょう。

そのため、指摘件数の多い少ないを、外部エンジニアの腕前の評価に直結させないようにします。件数を使うなら、同じチームの中で、同じ定義で数えた値を時期ごとに比べる程度にとどめます。規模や工数あたりの指摘件数の比べ方は「レビュー指摘件数の密度の基本、工数あたりと規模あたりで比べる」で扱っています。

外部エンジニアに技術レビューを頼むとき

社内にレビューできる人が少ないときは、外部エンジニアに技術レビューやコードレビューを頼むことになります。セキュリティ・バイ・デザインガイドラインは、セキュリティの対応方針の中で、開発や運用の工程で、開発した人以外が行う脆弱性診断やセキュリティレビューの方針を決め、必要な人員などを決定するよう示しています。^*2 どの工程で、誰に、何を見てもらうかを、開発を始める段階で決めておくということです。

同じガイドラインは、リスクを評価する担当は、開発者とは別の、セキュリティの専門知識を持つ人が務めるものとし、文書のレビューや脆弱性診断を行って推奨策を提言するとしています。^*2 書いた人とレビューする人を分けておくのは、自分の書いたコードの見落としに自分では気付きにくいためです。

外部エンジニアに頼むときは、見てもらうリポジトリと機能、基準にする設計書と規約、指摘の返し方（修正が必要な指摘と提案を分けるかどうか）、期限を依頼の時点で書いて渡します。指摘を受けて直すのは社内の担当者なのか、レビューした外部エンジニアなのかも決めておきます。最終的に取り込むかどうかの承認は、社内の担当者が行います。

つまずきやすい点

一つ目は、レビューの基準を口頭で伝えるだけで済ませてしまうことです。外部エンジニアは入れ替わることがあり、口頭の説明は次の人に引き継がれません。設計書と規約の置き場所を決め、参画した日に読んでもらうようにします。

二つ目は、レビューの時間を作業の見積もりに入れていないことです。外部エンジニアの変更を社内で見る時間も、外部エンジニアが指摘を直す時間も、見積もりに含めておかないと、レビューを急いで済ませることになりがちです。

三つ目は、指摘件数に目標を置くことです。先に見たとおり、件数は数え方によって大きく変わります。目標を置くと、細かな指摘を増やしたり、逆に指摘を控えたりする動きが出やすくなります。見るべきは件数よりも、修正が必要とした指摘が取り込みの前に直っているかどうかです。

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

外部エンジニアとのコードレビューと技術レビューを進めるうえで、確かめておきたい点は3つに整理できます。第一に、設計書と規約を基準として文書で渡し、指摘を「修正が必要な指摘」と「提案」に分けること。第二に、社内の担当者の承認と自動テストの合格を取り込みの条件にし、外部エンジニアの権限は担当する作業に必要なものまでにすること。第三に、指摘件数は定義をそろえて記録し、外部エンジニアの評価に直結させないことです。この3点を踏まえておけば、「レビューのやり取りが往復するばかりで、何が直れば取り込めるのか誰も分からない」という事態を避けやすくなります。レビューを担える人が社内に足りないときは、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：経済産業省「システム管理基準」（令和5年4月26日）（PDF）（https://www.meti.go.jp/policy/netsecurity/sys-kansa/sys-kanri-2023.pdf）。出典：Ⅱ.4 開発プロセス、Ⅱ.4.1 実装の管理活動の例（実装結果のレビュー、実装結果の記録と不具合の改善）を参照（2026年9月確認）
2. *2　参考：デジタル庁「DS-200 政府情報システムにおけるセキュリティ・バイ・デザインガイドライン」（2024年1月31日）（PDF）（https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/7e3e30b9/20240131_resources_standard_guidelines_guidelines_01.pdf）。出典：1)セキュリティリスク分析の重要なセキュリティ対策の考え方（第三者チェックの方針）、5)セキュリティ実装の要求事項と重要なセキュリティ対策の考え方、関係者の役割（セキュリティリスクアセッサー）、セキュリティ実装のチェックリストを参照（2026年9月確認）
3. *3　参考：デジタル庁「DS-202 CI/CDパイプラインにおけるセキュリティの留意点に関する技術レポート」（2024年3月29日）（PDF）（https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/33f31336/20240329_resources_standard_guidelines_guideline_01.pdf）。出典：3.2の2)ソースコード管理システム、そのリポジトリ及びブランチの保護、3)公私共用なユーザーアカウントの管理、4)作業内容と作業者の紐付き、3.3の2)ソースコード・成果物の信頼性の担保、3.4の3)デリバリ時の証跡を参照（2026年9月確認）
4. *4　参考：IPA「ソフトウェア開発分析データ集2022」本編（PDF）（https://www.ipa.go.jp/digital/software-survey/metrics/hjuojm000000c6it-att/000102171.pdf）。出典：A5.2.10 工数(コスト)のデータ項目「レビュー指摘件数」の定義（除外する指摘）を参照（2026年9月確認）
5. *5　参考：IPA「ソフトウェア開発分析データ集2022」業種編（情報通信業・金融・保険業・製造業）（PDF）（https://www.ipa.go.jp/digital/software-survey/metrics/metrics2022.html）。出典：情報通信業編（000102173.pdf）・金融・保険業編（000102172.pdf）・製造業編（000102174.pdf）の表4-2-1「工数あたりの製作レビュー指摘件数(全開発種別)」のN・中央値と、データ数が少ないので参考程度にするとの記述を参照。倍率は中央値から計算（2026年9月確認）

Tweet