LASSIC Media らしくメディア

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

動いている既存システムに機能を1つ加えたいが、社内に手の空いている開発者がいない。業務委託エンジニアに頼もうとしたところで、何を渡せば作業を始めてもらえるのか、終わったときに何を受け取れば次に困らないのかが決まっていない——。社外の技術者に既存システムの追加開発を頼む場面では、こうした迷いが起こりがちです。既存システムの追加開発とは、すでに稼働しているシステムに、新しい機能や画面、帳票、ほかのシステムとの連携などを加える開発を指します。

新しく作る開発と違い、手を入れる前から動いている仕組みと、それを使っている人がいます。そのため、渡す資料、作る前に確かめる影響、作った後に受け取る成果物を先に決めておくと、手戻りを減らせます。本記事では、開発の現場を預かるマネージャーに向けて、IPA（情報処理推進機構）の「共通フレーム2013」とデジタル庁の標準ガイドラインをもとに、追加開発の位置づけ、新規開発との違い、着手前に渡すもの、影響分析で決めること、分担の決め方、受け取るもの、つまずきやすい点を整理します。

既存システムの追加開発とは

IPAが2013年に公開した「共通フレーム2013」は、ソフトウェアの企画から開発、保守、廃棄までの作業を、発注する側と受注する側が同じ言葉で話せるようにまとめた枠組みです。その第3部のガイダンスは、システム開発プロセスを、新規開発だけでなく「保守に伴う開発」や旧システムからの移行に伴う開発にも用いるとしています。^*1 既存のシステムに手を入れる開発も、新規開発と同じ手順の枠組みで進める、という位置づけです。

一方、デジタル庁の「デジタル・ガバメント推進標準ガイドライン」（DS-100）は、国の情報システムの経費を分ける別紙で、整備経費を「新規開発、機能改修・追加、更改及びこれらに付随する環境の整備」に要する一時的な経費としています。アプリケーション保守経費は、機能を「仕様どおり正常な状態に保つ」ための改修や設定変更の経費として別に置いています。^*2 機能を加えることと、今の仕様を保つことを分けて扱う考え方です。

民間企業がこの区分に従う必要はありませんが、頼む側には役に立つ見方です。今の保守契約に機能の追加まで入っているかは契約によって違うため、頼む前に契約書で確かめておくと、作業の二重発注や引き受け手のいない作業を避けやすくなります。

新規開発と違うところ

1つ目の違いは、手を入れる前から基準になる状態があることです。共通フレームはこれをベースライン（合意のうえで確定させた成果物の版）と呼び、保守で修正するときの入力に挙げています。ベースラインには「システム方式の定義，修正履歴，ソースコードを含むことが望ましい」としています。^*1 追加開発は、この決まった土台から外れない形で加える作業です。

2つ目は、変更が今の利用者やほかのシステムに及ぶことです。共通フレームは、保守の作業を担う側は修正の前に、組織、現行システムと関連するシステムへ与える影響を明らかにするため、修正依頼を分析することが望ましいとしています。新しい機能を加えただけのつもりでも、共通のテーブルや画面の部品を変えれば、既存の機能の動きが変わることがあります。

3つ目は、設計書を直す作業が増えることです。DS-100は、保守を通じてソフトウェア製品などを改修又は更改する場合には「設計書の変更管理等、設計・開発時と同様の取組を行うものとする」としています。^*2 コードだけを変えて設計書をそのままにすると、次に誰かが追加開発をするときに、資料と実物が食い違った状態から始めることになります。

着手前に渡すもの

共通フレームは、修正の分析を始めるときの入力として、問題報告及び修正依頼、ベースライン、ソフトウェアリポジトリ（ソースコードなどを保管する場所）、システム文書を挙げています。システム文書には、構成状況の情報、機能要件、インタフェース要件などがあるとしています。^*1 業務委託エンジニアに渡すものに置き換えると、次の表のようになります。

資料が揃っていない場合の扱いにも、共通フレームは触れています。保守を契約する場合、保守に必要な文書は取得者（発注する側）から提供を受けるとし、文書がない場合は「その作成及び責任範囲を契約に含めることがある」としています。^*1 設計書が古い、あるいは無いと分かっているなら、それを隠さずに伝え、まず今の仕様を調べて書き起こす作業から頼むかどうかを決めます。

作業に使う環境も同じです。共通フレームは、保守に必要なシステムやソフトウェア製品は取得者から提供を受けるとしています。検証用の環境や試験用のデータを誰が用意するのかは、着手の前に決めておきます。

影響分析で決めること

作り始める前に、業務委託エンジニアに最初に頼みたいのが影響分析です。共通フレームは、修正の分析の出力として、影響分析、推奨された選択肢、承認された修正内容、更新された文書を挙げ、推奨する解決策を文書にして実現の承認を得るとしています。^*1 影響分析の中身として挙げているのは次の6項目です。

このうち発注側がとくに目を通したいのは、触る範囲です。どの画面、どのテーブル、どの連携先に手が入るのかが書かれていれば、社内のどの部署に確認が要るかが分かります。逆に、範囲の書かれていない見積りのまま作業を始めると、作り終えてから別の機能への影響に気づくことになりがちです。

選択肢を出してもらうときの決まりも要ります。共通フレームは、修正案の選択肢で用意する範囲を契約に定めるとよいとし、定めていない場合は「選択肢の提案を無制限に求められることがある」としています。^*1 「案は2つまで、それぞれに触る範囲と工数を添える」のように形を先に伝え、承認した案は日付と承認した人を添えて残します。

分担と変更の決まり

共通フレームは、修正依頼の文書化や問題の再現の確認を誰が担うかを、契約に書いておくよう勧めています。業務委託エンジニアに追加開発を頼むときに決めておきたいのは3つです。依頼書を書くのは社内の誰か、加えた機能が依頼どおりかを確かめるのは誰か、作業の途中で出てきた疑問に答えるのは誰か。とくに3つ目は、既存システムの仕様を知っている人が社内に1人しかいない場合に詰まりやすいところです。その人が答えられる曜日や時間帯を、着手の前に伝えておきます。

作業の途中で要件が増えることにも備えておきます。共通フレームは、要件の追加や変更は当初に取り決めた人、物、金、時間、環境などへの影響を伴うとし、予算の追加や機能の削減などを「事前にルール化する」としています。^*1 どの大きさの変更なら担当者の判断で受けてよいか、どこから先は改めて見積もるかを決めておくと、範囲が少しずつ広がるのを止めやすくなります。

ソースコードの版の扱いも分担を決めます。共通フレームは、構成管理（成果物の版と変更の記録を管理すること）を行うにあたって、保守者、運用者、利用者の役割分担を明確にするとよいとしています。本番に出す版を決めるのは誰か、業務委託エンジニアが書き込める範囲はどこまでかを、リポジトリの権限とあわせて決めておきます。

受け取るものと受け入れ

作業が終わったときに受け取るものも、共通フレームの出力が手がかりになります。修正の実施の出力として、更新されたテスト計画及びテスト手順、更新された文書、修正されたソースコード、テスト報告、計測指標を挙げ、更新された文書には修正履歴、詳細な分析報告、更新された要件などを含むことが望ましいとしています。^*1

既存の機能を確かめるテストは、追加開発でとくに抜けやすいところです。共通フレームは、ソフトウェア結合の成果に挙がる回帰戦略を、リグレッション戦略と同じ意味だとしています。変えていない部分が壊れていないかを、どこまで確かめるかの方針のことです。テスト計画の中にこの方針が書かれているかを、受け取るときに確かめます。

受け取ったら、受け入れの確認をします。共通フレームは、保守レビューと受け入れで、システムの修正と承認が正しく完了していることを確かめるとし、その出力に、受け入れられた修正を組み込んだ新ベースライン、却下された修正、受入れ報告などを挙げています。^*1 受け入れた時点のソースコードと設計書の組み合わせが、次の追加開発の出発点になります。どの版を受け入れ、何を見送ったのかを記録しておけば、次に頼む人にもそのまま渡せます。

つまずきやすい点

一つめは、依頼を口頭やチャットの一言で済ませてしまうことです。依頼の文面が残っていないと、影響分析で「依頼した内容が正しく読み取られているか」を確かめる手がかりがありません。短くてもよいので、加えたい機能と、それが要る理由を文章にして渡します。

二つめは、本番で動いている版と、渡したソースコードの版がずれていることです。リポジトリの最新の版が、そのまま本番で動いているとは限りません。本番に急ぎの修正を直接入れたまま、リポジトリに戻していないこともあります。渡す前に、本番に出ている版がどれかを確かめておくと、作業の土台の食い違いを防げます。

三つめは、受け入れの確認を後回しにすることです。受け入れの記録を残さないまま次の依頼を出すと、どの版を受け入れたのかが曖昧になり、追加開発を重ねるほど積み重なります。

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

業務委託エンジニアに既存システムの追加開発を頼む前に、加えたい機能、手が入りそうな範囲、渡せる資料の一覧を書き出しておきます。揃っていない資料も書いておきます。使っている言語やフレームワーク、触るシステムの規模が分かれば、既存のソースコードを読んで改修した経験のある人を探しやすくなります。

古い仕様書を引き継げる形に直す手順はレガシーの仕様書が古いときに引き継げる形へ直す4つの手順で扱っています。

前の開発会社が作ったプログラムに手を入れるときの著作権の確かめ方は業務委託エンジニアの既存システム改修で問われる著作権と許諾にまとめました。

設計から頼む場合の渡し方はフリーランス活用で上流工程の基本設計、渡すものと受け取るもので整理しています。

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

業務委託エンジニアに既存システムの追加開発を頼むうえで、確かめておきたい点は3つに整理できます。第一に、修正依頼と、本番で動いている版のソースコード・設計書・修正履歴を揃えて渡し、検証用の環境とデータを誰が用意するかを決めること。第二に、作り始める前に影響分析を出してもらい、触る範囲と工数を確かめ、承認した案を記録に残すこと。第三に、ソースコードと一緒に更新した設計書とテスト報告を受け取り、受け入れた版を次の出発点として記録することです。この3点を踏まえておけば、「機能は増えたのに、どこを変えたのか誰も説明できない」という事態を避けやすくなります。任せる作業に合う人の探し方に迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：IPA「共通フレーム2013」第3部 共通フレームとガイダンス（PDF）（https://www.ipa.go.jp/publish/qv6pgp000000107j-att/000062659.pdf）。出典：独立行政法人情報処理推進機構。第3部のガイダンスのうち、2.2.4.1（要件の追加や変更の事前のルール化）、2.3（保守に伴う開発）、2.4.6（回帰戦略）、2.6（保守プロセス）、2.6.1・2.6.1.1・2.6.1.4・2.6.1.5（保守の開始の準備と保守文書）、2.6.2と2.6.2.1〜2.6.2.4（問題把握及び修正分析）、2.6.3（修正の実施）、2.6.4（保守レビュー及び受入れ）を参照（確認日2026年10月2日）（2026年10月確認）
2. *2　参考：デジタル庁「DS-100 デジタル・ガバメント推進標準ガイドライン」（PDF）（https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/54d8725e/20260715_resources_standard_guidelines_guideline_01.pdf）。出典：2026年（令和8年）6月12日 デジタル社会推進会議幹事会決定。第3編第5章の非機能要件の定義 r)（保守に関する事項）、第3編第9章「運用及び保守の実施」の冒頭、別紙2「情報システムの経費区分」（整備経費・アプリケーション保守経費）を参照（確認日2026年10月2日）（2026年10月確認）
3. *3　参考：デジタル庁「標準ガイドライン群」（https://www.digital.go.jp/resources/standard_guidelines）。DS-100の現行版として上記のファイルが案内されていることの確認として（確認日2026年10月2日）（2026年10月確認）

Tweet