開発会社とソースコードをどう管理する？変更・確認・本番の版をそろえる

コードの保存・確認・本番反映を分ける

ソースコードは、システムの処理や表示を作る元の記述です。リポジトリは、コードと変更の履歴を保管する場所です。版は、その時点でどの内容を保存したかを特定するためのものです。発注側がコードの全行を読めなくても、どの依頼に対する変更で、何を確認したかは説明してもらえます。

図で見る問い：開発担当の手元に保存した変更を、発注側も同じ保管先で見られるでしょうか。保存する場所と、共有して見る相手に注目してください。

この節の解説図を原寸で見る

図の手元の保存と、関係者が開く保管先は、別に確かめる対象です。保存したという連絡を受けたら、発注側がどこで何を受け取り、今回の変更をどう特定するかを開発担当へ聞きます。この図だけで実際に閲覧できたとは判断しません。

保存したこと

変更した内容を、特定できる状態で記録したことです。保存先や含む変更が分かる記録を確認します。作業中のファイルがあることと、依頼した変更が記録されたことを分けます。

共有したこと

関係する人が、決めた保管先で必要な変更を受け取れる状態にしたことです。開発担当の手元へ保存しただけでは、発注側が同じ内容を見られるとは限りません。

確認したこと

技術的な差分の確認、動かした試験、発注側の業務確認は、それぞれ見る対象が違います。誰がどの版を何で確かめたかを対応させます。

本番へ反映したこと

実際の業務で使う場所へ変更を入れたことです。コードの保存やレビューが終わった記録だけでは、その場所へ反映され、業務を確かめたことにはなりません。

Gitという履歴管理の仕組みでは、選んだ内容の保存時点をコミットとして記録します。Pro Gitの変更記録の説明も、作業中の変更とコミットに含まれる内容を分けています。また、同書の遠隔リポジトリの説明では、手元の記録を共有先へ送ることや、受け取ることを区別しています。本稿では用語の整理に使い、Gitの操作をしただけで試験や本番反映が済むとは扱いません。

希望納期の列を加える、一つの依頼から始める

今回の変更は、受注一覧に希望納期の列を加えることです。期待する業務の動きは、営業が受注ごとの希望納期を一覧で見ることです。IT発注担当は、委託先の開発担当へ、この仕事と確認したい内容を伝えます。

図で見る問い：希望納期の列へ、どの情報を表示する案でしょうか。営業が見る列と、元になる情報の関係を見てください。

この節の解説図を原寸で見る

列の名前が決まっても、表示する元の情報や、納期がまだ決まっていない注文の扱いまでは決まりません。営業の担当と開発側へ、同じ受注のどの情報を使うか、未定の場合に何を表示する案かを尋ねます。図の空欄を実際の日付や、決定した表示形式で埋めないでください。

最初に、どの一覧のどこで見たいのか、何の情報を希望納期として使うのかを聞き合わせます。納期が決まっていない注文の表示や、既存の検索・並べ替えへの影響など、必要な条件が未決定なら、その質問も同じ変更依頼へ残します。この記事では実際の日付、列の位置、表示形式、空欄時の動きを決めていません。

開発側には、どの部分を変える予定か、ほかの表示や処理にも関係するかを説明してもらいます。発注側が列の追加を依頼したことだけを理由に、画面の一か所だけで変更が完結すると決めません。影響する箇所と、確認する業務の範囲を結び付けるためです。

変更に使う場所や架空データ、本番との接続を用意する段階なら、開発前の作業場所とデータの準備をそろえる方法を先に確認できます。ここでは、その場所でどの変更版を確かめ、本番へ入れる版とどう対応させるかへ進みます。

保管する場所と、発注側が見られる方法を決める

同じ受注一覧の改修について、次の二つの保管方法を検討します。どちらも提案で、実際の保管先はまだ未確認です。保管先の名前だけで優劣を決めず、誰が管理し、発注側が何を見られ、変更と記録をどう受け渡すかを比べます。

図で見る問い：保管する会社が変わると、発注側から何を確かめる必要があるでしょうか。二つの案の管理する場所と、閲覧・受渡しへの問いを近くで比べてください。

この節の解説図を原寸で見る

場所の案があっても、誰が管理し、発注側が何を見られるかは別に確認します。委託先の保管先を使う案では、作業中に見られる内容と、引渡しの対象・時点も聞きます。どちらの案も、図の線を実際の閲覧や受渡しが完了した記録にはしません。

両案に共通する変更方法の案は、委託先が変更用の枝へ保存することです。枝は、変更を分けて進めるための保管上のまとまりで、Gitではブランチと呼びます。確認方法の案は、取り込む前に担当者を決めて差分を確認することです。いずれも実施した記録ではありません。

閲覧できる説明と、実際に見た記録を分ける

両案の発注側が実際に閲覧した記録は未取得です。発注側の担当が、許可された方法で対象の保管先と変更記録を開けるかを確認します。招待が届いたことや、管理者が設定したという連絡だけを、その変更を閲覧できた結果にはしません。

GitLabの役割と権限の公式説明では、役割のほか、プロジェクトの条件や継承、個別の権限によって利用できる操作が変わります。自社が使うサービスの現在の設定で、閲覧・変更・取り込みなどの範囲を確かめてください。GitLabの役割名や表の印を、別のサービスでも同じ権限がある根拠にはしません。

コードを見られることと、契約上の権利を分ける

この例の契約上のコードの所有・利用の扱いは未確認です。閲覧権限があることや、サービス上で管理者の役割を持つことだけでは、その扱いは決まりません。必要な利用、受渡し、変更の条件を契約の担当と開発会社へ確認します。本稿は個別契約の解釈や権利の帰属を決めるものではありません。

保存・レビュー・試験・本番の版を対応させる

追いたいのは、「納期列の変更が、どの内容で確認され、本番へ進むのか」というつながりです。以下は今後の進め方で、この二案で実際に記録を取得した順番ではありません。

図で見る問い：同じ希望納期列の追加でも、開発側と営業は何を見て確認するのでしょうか。技術的な差分と、業務で見る一覧を分けて見てください。

この節の解説図を原寸で見る

開発側が読む差分と、営業が確かめる表示は、対象が違います。それぞれ誰が、どの変更や版で、何を確かめたかを結び付けます。営業が画面を読めたことを技術的なレビューにせず、レビューの記録だけを試験や本番反映の結果にも置き換えません。

ソースコードだけで、動くシステムのすべてが決まるとは限りません。使う部品や設定、データの構造などが関係する場合は、それらの変更も開発会社へ確認します。サーバー更新自体の影響を確かめる場合は、更新対象と業務操作に合わせて検証する方法が別の範囲です。コードの版が分かったことだけで、その検証まで済ませません。

図で、一変更と確認記録のつながりを見る

図で見る問い：希望納期の列を加える同じ依頼について、保存した変更、確認した対象、試験に入れた内容、本番へ入れる内容をたどれるでしょうか。保管先の二案と、各記録がまだ分かっていない箇所を見てください。

解説図を原寸で見る

保管する場所を選ぶだけでは、版の対応は埋まりません。発注側が見られる方法と、変更を保存した記録、誰が何を確認したかを開発担当へ聞きます。自社の保管先の案も、委託先の保管先の案も、実際の閲覧やレビューを確認したものではありません。

次は、試験版と本番へ入れる内容の説明を照合します。どの受注例を何の版で試したか、本番予定の内容に何が含まれるか、違いがあれば何を確認し直すかを聞きます。空欄や疑問符を、実行済み・一致・合格に置き換えません。

返答が足りないときは、対象と確認先を絞る

「管理されていますか」とだけ聞くより、どの依頼の、何の記録が必要かを示すと、開発会社が回答を用意しやすくなります。IT発注担当は質問の窓口になり、技術的な記録は開発側、業務の表示は営業の担当、権利や利用条件は自社の担当へつなぎます。

図で見る問い：足りない説明は、どの担当へ返すと判断できるでしょうか。版の記録、一覧の表示、権利や利用条件という質問の中身から、相談先を選んでください。

この節の解説図を原寸で見る

三つの担当を順番に回れば承認がそろう、という手順ではありません。版の記録は開発側、業務で必要な表示は営業の担当、権利や利用条件は自社の担当へつなぎます。実際の回答者が未定なら、IT発注担当から窓口へ確認し、質問と担当を同じ依頼へ残します。

• 保管先は分かったが、発注側が変更を見られない

  対象の保管先、必要な閲覧内容、使う担当、実際に開けなかった箇所を管理する人へ返します。閲覧できる方法や、確認に必要な資料の受渡しを相談し、確認できた範囲を残します。見られないことを「変更が存在しない」「権利がない」と断定せず、変更の中身を確認できないまま、反映を了承した扱いにもしません。

• 保存したと言われたが、どの版か分からない

  納期列の依頼と結び付く保存記録、含まれる変更、保管先を尋ねます。説明の日時だけでは内容を特定できない場合、開発担当に、その時点の変更を再び確認できる方法を示してもらいます。スクリーンショットや口頭説明を、保存されたコードの版の代わりにはしません。

• レビュー記録はあるが、試験版が分からない

  誰が見たどの差分かを残し、試験場所へ入れた内容との対応を聞きます。レビューで確認した範囲と、実際に動かして確かめる業務を分けます。取り込まれたことや、指摘が解決したという連絡だけを、希望納期を正しく見られた結果へ変えません。

• 試験した内容と、本番予定の内容が違う

  違う変更や設定、追加された内容と、その影響を開発担当へ示してもらいます。納期列と関係する表示や処理をどこまで再確認するかを相談し、対応が付くまで、その内容の反映判断を保留します。既に一致を確認できた別の説明まで無条件に捨てず、残る違いを具体化します。

別のサービスや実顧客データの扱いは、別に確認する

両案とも、他のサービスの権限を確かめた状態は未検証です。これは、そのサービスの権限がないと判定した値ではありません。コードを見られることから、本番サーバーや外部の接続先も操作できるとは補いません。今回の確認で必要なら、そのサービスを管理する人へ利用範囲を聞きます。

実顧客データの複製への了承は未確認です。試験版を確かめるために実データの複製が必要だと決めず、目的に合う架空受注で確認できるかを相談します。データの取扱いに回答が必要なら、社内の管理担当へ確認し、コードの保管や閲覧の了承と混ぜません。

修正が入ったら、版と確認範囲を更新する

返答や修正が来たら、元の依頼と確認記録へ戻って読みます。どの条件が新しく分かり、何の内容が変わり、前に確認した結果をどこまで使えるかを開発側と相談します。「直しました」という連絡だけで、別の版の結果を書き換えません。

図で見る問い：修正後の説明を受けたとき、前の記録をどう残し、どこを確認し直すでしょうか。以前の資料、新しい変更の説明、関係する確認対象の対応を見てください。

この節の解説図を原寸で見る

前の記録を残したうえで、何が変わり、どの確認に影響するかを開発側へ聞きます。例えば表示する元情報が変わったなら、一覧の表示や関係する処理をどの条件で確かめ直すかを相談します。古い結果を別の版の結果へ上書きせず、新しい説明と残る未確認を判断する人へ渡します。

1. 以前の内容と記録を残す。前の変更版、レビューの対象と指摘、試験の条件と結果を一組にします。新しい説明が届いても、前の結果が何の条件だったかを失わないようにします。
2. 変わった箇所と、取り込む内容を聞く。納期列の表示や元データ、関係する処理が変わったのかを説明してもらいます。別の変更をまとめた場合も、今回の依頼との関係を示してもらいます。
3. 必要な差分確認と試験をやり直す。技術的な確認は担当者が新しい対象を読み、業務の確認は合意した受注例と表示の期待に合わせます。前の内容と同じか、影響がないかは記録で確かめ、古い結果を自動で引き継ぎません。
4. 反映を判断する人へ、対応と未確認を渡す。依頼、保存した変更、確認した記録、試験した版、本番へ入れる内容、残る条件をまとめます。反映する作業の担当や、実施後に確かめる業務も相談し、記録を整理したことと、了承したことを分けます。

この仕事全体の実際の本番反映結果は未取得です。両案それぞれの実際の本番反映結果の記録も未取得です。実施の有無や、実施した場合の対象と結果を、記録する担当へ確認します。この記事の手順や図は、実際の反映を行った証拠にはしません。

まとめ：一つの変更を、保存から本番の判断まで追えるようにする

開発会社とソースコードを管理するときは、保管するサービス名だけで終えず、発注側の閲覧方法と、一変更の記録をそろえます。保存した版、技術的な差分確認、業務を試した版、本番へ入れる内容を対応させると、「確認済み」が何を指すかを聞けます。

自社と委託先の二つの保管案は、実施前の提案です。分からない版や閲覧方法、確認者を特定の質問へ変え、返答後は説明の版と再確認する範囲を更新してください。閲覧、契約上の権利、試験、本番反映は、それぞれ根拠を分けます。