LASSIC Media らしくメディア

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

外部の人材に開発を手伝ってもらいながら、少しずつ社員だけで回せる体制に移したい。ところが、関わる人ごとにコードの書き方もレビューの通し方も違い、誰かが抜けるたびに作業が止まる——。外部人材活用で内製化を進める現場では、こうした悩みがよく聞かれます。ここでいう開発標準とは、コーディング規約、レビューの手順、ブランチの運用、ドキュメントの書き方など、誰が書いても同じ形の成果物になるように決めておく開発の決まりごとを指します。

開発標準を社内で持っておけば、外部の人が入れ替わっても作り方は会社に残ります。ただし決めるだけでは守られず、確かめ方まで決めておく必要があります。本記事では、開発の現場を預かるマネージャーに向けて、デジタル庁の標準ガイドライン解説書とアジャイル開発実践ガイドブックを手がかりに、開発標準に入れるもの、誰が決めて持つのか、外部人材に見せる時期、守られているかの確かめ方、ドキュメントの範囲、外部人材が抜けるときの引き継ぎを整理します。

内製化で開発標準が要る理由

外部人材と社員が同じコードに手を入れる開発では、書き方の違いがそのまま読みにくさになります。外部人材活用の期間が長いと、そのあいだに書かれたコードは、関わった人それぞれの流儀で積み上がっていきます。内製化の段階で社員が引き取るとき、まず書き方の違いを読み解くところから始めることになり、引き取りに時間がかかります。

手がかりになるのが、デジタル庁の「デジタル・ガバメント推進標準ガイドライン解説書（DS-110）」です。国の行政機関が情報システムを整備するときの進め方を解説した文書で、2026年6月12日に改定されています。設計・開発の引継ぎの項では、整備後の「事業者変更のリスクを最小限に抑えつつ」運用できるよう、設計書や作業経緯、残存課題を引き継がせるとしています。^*1 担い手が替わっても仕事が続くように、作り方の決まりと記録を発注する側が持っておくという考え方です。

外部人材から社員へ開発を移す内製化も、担い手が替わるという点では同じ形をしています。開発標準は内製化の終わりに作るものではなく、外部人材が加わる時点で置いておくものです。後から決めると、それまでに書かれたコードを標準に合わせて直す手間が別に生まれます。

開発標準に入れるもの

解説書は、調達の仕様書で事業者に「準拠することが前提となる文書、標準等」を示すよう求め、その例に「プロジェクト標準」を挙げています。^*1 アプリケーションの開発や保守を効率的に進めるためにプログラミング等のルールを定めた標準のことで、標準コーディング規約、セキュアコーディング規約（脆弱性を作り込まないための書き方の決まり）、データやデータ項目の命名規約が並んでいます。

民間の開発で外部人材と共有するなら、この3つに作業の進め方の決まりを加えると、日々の作業で迷う場面が減ります。下の表のうち、ブランチ運用、レビューの手順、ドキュメントの書き方は解説書の例示ではなく、本記事で加えた項目です。

最初からすべてをそろえる必要はありません。今あるコードで実際に使っている書き方を書き出し、人によって意見が分かれやすいところから文書にしていくと、外部人材にも社員にも受け入れられやすくなります。

誰が決め、誰が持つのか

開発標準の持ち主は社内に置きます。外部人材は経験が豊富なことが多く、規約の下書きを頼むと早く形になります。ただ、下書きを書いた人が抜けたあとに、どの決まりをなぜ置いたのかを社員が説明できなければ、標準は誰も変えられないまま古くなっていきます。

そこで、下書きは外部人材に頼んでも、採るかどうかの判断と、決まりを変えるときの承認は社員が担うようにします。変更の理由は、変更の記録に一行でも残してもらいます。内製化が進んだあとで「この決まりは何のためにあるのか」を調べられるようにするためです。

デジタル庁の「アジャイル開発実践ガイドブック（DS-121）」は、進め方や狙いを「本ガイドブックのとおりとする」という周知で済ませず、プロジェクトごとに定義するよう勧めています。^*2 開発標準も同じで、公開されている規約や他社の例をそのまま渡すより、自社のコードと体制に合わせて言葉にしたほうが、守る側が理由を理解できます。

外部人材に見せる時期と範囲

解説書は、事業者が閲覧できる資料の例として、プロジェクト標準（標準コーディング規約、セキュアコーディング規約、データやデータ項目の命名規約等）を挙げ、既存の情報システムの設計書や過去の受注者の検討資料、作業報告書と並べています。^*1 提案や見積もりの前に、守ってほしい決まりを見せておくという扱いです。

外部人材活用でも、開発標準は参画が決まってからではなく、契約や作業範囲を話し合う段階で見せておくと、その決まりで作業できる人かどうかを互いに確かめられます。参画してから初めて規約を知ると、最初のレビューで同じ種類の指摘が重なり、立ち上がりが遅れがちです。

一方で解説書は、閲覧させるときの注意として、誓約書を提出させること、閲覧場所を執務室とは区切られた会議室等に限ることなども挙げています。^*1 開発標準のうちセキュリティの決まりに社内のシステム構成が書かれているなら、参画前に見せる部分と、参画後に見せる部分を分けておきます。

守られているかの確かめ方

決めた標準が守られているかは、確かめ方まで決めておかないと分かりません。解説書は、再委託（受託した会社がさらに別の会社へ作業を任せること）を認める場合の条件として、ルールの遵守や成果物の確認方法を求めるとし、その例に「標準コーディング規約遵守の確認、ソースコードの検査、現場での抜き打ち調査等」を挙げて、実施主体、手順、方法まで求めるとしています。^*1

外部人材と社員が一緒に開発する場面に置き換えると、決めておくことは3つです。1つ目は、誰が確かめるか。社員が確かめる側に回れば、それ自体が内製化の練習になります。2つ目は、どの手順で確かめるか。書式や命名のように機械で判定できる決まりは静的解析ツール（プログラムを動かさずにコードを調べる道具）や自動の整形に任せ、人のレビューは設計の判断を見ることに時間を使います。3つ目は、守られていなかったときの扱いです。差し戻すのか、次の変更でまとめて直すのかを決めておきます。

レビューの指摘の分け方や、取り込む前の承認の流れは外部エンジニアのコードレビューと技術レビューの違いと進め方で扱っています。

チームの約束事との分け方

開発標準と混ざりやすいのが、チームの中の約束事です。DS-121は、チーム活動を円滑にするための「チームメンバー同士の約束事」をワーキング・アグリーメントと呼び、開発を始めてからも進め方の認識のずれは生まれるものと考えて、必要なルールや守るべき原則をチームの中で決めてよいとしています。^*2

たとえば、レビューの依頼にはその日のうちに反応する、打ち合わせを入れない時間帯を設ける、といった決まりはチームの約束事です。顔ぶれが変われば見直してよいものです。一方、コードの書き方や命名、本流に取り込む条件は、チームが替わっても残したい決まりなので開発標準に入れます。両者を同じ文書に混ぜると、外部人材が入れ替わるたびに標準まで書き換えられ、社員に残すべき決まりが揺らぎます。

ドキュメントはどこまで書くか

ドキュメントの書き方も開発標準に入れておきたい項目ですが、すべてを文書にすると書く手間が開発を圧迫します。DS-121は、保守工程で参照される機会があまりなく、ソースコードでも代替できるプログラムの詳細設計書などは省く姿勢がある一方、システム全体の構成図や基本設計、ERD（データどうしの関係を表した図）やエンティティの定義、システム境界のインターフェースなどの文書化は、運用・保守や改修にしばしば役立つとしています。^*2

内製化を見据えるなら、社員が引き取ったあとに読み返すものを優先して書きます。コードを読めば分かることよりも、なぜその設計にしたのか、ほかのシステムとどうつながっているのかといった、コードからは読み取れない情報です。書く場所と形式も標準で決めておくと、外部人材が抜けたあとに資料を探し回らずに済みます。

外部人材が抜けるときの引き継ぎ

解説書は、設計・開発から運用・保守へ引き継ぐ資料の例に、「標準コーディング規約等プログラミング等のルールを定めた標準に関する資料」を、設計書やテスト計画書と並べて挙げています。^*1 ソースコード一式についても、コメントは原則として日本語または英語に限定することとしています。^*1 引き継ぐ側が読める言葉で書いてもらうところまでを、引継ぎの条件に入れている形です。

引継ぎの前には、引き継ぐ資料、時期、方法を明確にして関係者で合意し、引継ぎ期間のうちに受け手の習熟度を確認するとしています。^*1 外部人材が抜けるときも、開発標準が最新の状態になっているか、現場で口頭のまま加わった決まりが文書に入っているかを、契約が終わる前に確かめます。社員が標準どおりに一つの変更を最後まで進められれば、引き取れたと判断する目安になります。

何を社員に移すのかの全体は外部人材活用から内製化へ、技術移転で社員に移すものと確かめ方で整理しています。

まとめ：開発標準で確かめておきたい3つの点

外部人材活用で内製化を進めるうえで、開発標準について確かめておきたい点は3つに整理できます。第一に、開発標準を外部人材が加わる時点で社内に置き、下書きを頼んでも採否と変更の承認は社員が担うこと。第二に、規約と命名の決まりに加えてブランチ運用やレビューの手順を入れ、誰がどの手順で確かめるかまで決めること。第三に、外部人材が抜ける前に標準が最新かを確かめ、社員が標準どおりに作業を進められるかで引き取れたかを判断することです。この3点を踏まえておけば、「外部の人が抜けたら、コードの書き方の理由を誰も説明できなかった」という事態を避けやすくなります。標準を一緒に作り、守れる人の探し方に迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：デジタル庁「DS-110 デジタル・ガバメント推進標準ガイドライン解説書」（2026年6月12日改定、PDF）（https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/50952dae/20260715_resources_standard_guidelines_guideline_03.pdf）。出典：第3編第6章2.のうち「カ 作業の実施に当たっての遵守事項」の表6-7（[2]遵守する法令等のうち、その他文書、標準への準拠）、「ケ 再委託に関する事項」の表6-10（[1]再委託の制限及び再委託を認める場合の条件）、「サ 附属文書」の表6-11（[3]事業者が閲覧できる資料一覧表、[4]閲覧要領）と、第3編第7章9.「引継ぎ」の趣旨・解説(1)、表7-6（引継ぎ作業項目）、表7-7（引継ぎ資料の例）を参照（確認日2026年10月6日）（2026年10月確認）
2. *2　参考：デジタル庁「DS-121 アジャイル開発実践ガイドブック」（PDF）（https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/150a60b4/20220422_resources_standard_guidelines_guidebook_01.pdf）。出典：2021年3月30日決定（内閣官房情報通信技術（IT）総合戦略室）、2021年5月10日改定。3.3の3)「当該プロジェクトでの開発方針を定める」、5)「チームでワーキング・アグリーメントを決めていく」、4.1の1)「各種ドキュメントについて」を参照（確認日2026年10月6日）（2026年10月確認）
3. *3　参考：デジタル庁「標準ガイドライン群」（https://www.digital.go.jp/resources/standard_guidelines）。出典：DS-110・DS-121が標準ガイドライン群として公開されていることの確認として（確認日2026年10月6日）（2026年10月確認）

Tweet