SESの保守改修でリリースが重い理由｜影響範囲調査は半日〜1日かかった現場

数行の改修を頼まれただけなのに、コードを直す時間より、調べて、書類を作って、承認を待つ時間のほうがはるかに長い。SESの保守案件では、こうしたリリースの重さに戸惑う人が少なくありません。

私はSESエンジニアとして5年ほど、4社の現場を経験しました。3社目では金融系のWebサイトの保守改善を約1年半担当し、影響範囲の調査は1件あたり半日〜1日、証跡も多く、半年に1回は夜間リリースもありました。

今回は、SESの保守改修でリリースが重くなる構造と、軽くするために私がやった工夫を、実体験を交えてお伝えします。

目次

1. SESの保守改修でリリースが重い現場｜私の3社目はこんな環境でした
2. 3社目の保守改善期の概要
3. 重さの正体は3つの層に分かれていました
4. 影響範囲調査とは？やり方と、1件に半日〜1日かかる理由
5. 影響範囲調査とは、「変わってしまうもの」を先に洗い出すこと
6. 私が使っていた調査の手順
7. 1件に半日〜1日かかる3つの理由
8. 失敗談：3時間で切り上げて、リリースが2週間延びた
9. 重いのは調査だけではない｜証跡・ドキュメントの作成が多かった理由
10. 小規模な改修1件の作業時間の内訳
11. 保守改善期に作っていた書類
12. なぜここまで書類が増えるのか
13. リリース手順が重い｜申請から本番反映までの流れと、待ち時間の長さ
14. 小さな改修が本番に出るまでの流れ
15. 作業時間は3日、依頼から本番までは3週間
16. 緊急で出したいときは別の枠になる
17. 夜間リリースとは？半年に1回あった理由と当日の流れ
18. 夜間リリースになるのはどんなとき
19. 当日の時間割
20. 手順書の一行が抜けていた回
21. 夜間であることのコストとリスク
22. 保守改修のリリースを軽くするために、私がやった工夫
23. 調査：確認項目を作ったら、見落としの手戻りがなくなった
24. 証跡：前回の資料を雛形にして、書き直しを減らした
25. 申請：切り戻し手順を先に書く
26. 変えられなかったこと
27. 保守改修の案件に入る前に確認したいこと
28. 聞いておくと見通しが立つ項目
29. 重いことは悪いことではない
30. まとめ

SESの保守改修でリリースが重い現場｜私の3社目はこんな環境でした

リリースが重いといっても、現場によって中身は違います。先に、私が経験した3社目の保守改善の環境を整理し、そのうえで何が重かったのかを3つに分けて見ていきます。

3社目の保守改善期の概要

3社目は二次請けの現場で、金融系のWebサイト（見積もり・申し込み・マイページなど）を扱っていました。前半の約1年はデータ移行、後半の約1年半が保守改善で、この記事の舞台は後半です。

仕事の中身は、利用部門からの改修依頼への対応と、障害調査・不具合修正でした。フロントとサーバー側の両方を触り、依頼ごとに担当が割り振られます。設計・実装・テストを一人で完結させる依頼もあれば、チームで分担する依頼もありました。

依頼元の利用部門とやり取りするのは、連絡窓口のリーダーです。私が直接話す機会は少なく、疑問は窓口経由で確認します。コードレビューは毎回受けていて、フレームワークは古い作りのObjectWorksでした。

働き方は、残業が平均で月約20時間（最多でも40時間弱）、リモートは週1〜2日でVPNで自宅から接続する形です。

この記事で扱う現場の条件です。

重さの正体は3つの層に分かれていました

「リリースが重い」と一言でまとめていましたが、分けて考えるとはっきりします。私の現場では、次の3つが重なっていました。

この3つは、別々の問題に見えて、根っこが同じでした。一度本番に出したものを、間違っていたからといって簡単には戻せないということです。戻すコストが高いから、出す前の確認が厚くなります。

森崎修司氏がITmedia上のブログで書いていた内容は、この感覚と重なります。

保守開発では、既存の部分との整合を確認する作業が必要になり、新規開発とは生産性が異なる。

2009年の文章ですが、保守開発が「作る」より「既存と食い違わないか確かめる」比重の高い仕事だという点は、今の私の実感とそのまま合っています。

影響範囲調査とは？やり方と、1件に半日〜1日かかる理由

結論影響範囲調査は、改修で変わる範囲をコードを直す前に洗い出す作業です。時間がかかるのは、呼び出し関係を人が一つずつ追わないと、漏れがないとは言い切れないからです。

最初の層から見ていきます。ここでは、影響範囲調査が何をする作業なのかと、私が実際に使っていた手順、そして半日〜1日かかった理由を順に書きます。

影響範囲調査とは、「変わってしまうもの」を先に洗い出すこと

改修依頼は、たいてい一文で届きます。たとえば「見積もり画面の契約期間の入力チェックについて、上限の条件を変えてほしい」といった具合です。

直すコードは数行で済むことも珍しくありません。ところが、そのチェック処理を別の画面やAPIも使っていれば、頼まれていない場所の動きまで変わってしまいます。

影響範囲調査は、その「変わってしまうもの」をコードを直す前に洗い出し、テストする範囲に置き換える作業です。調査の結果が、そのままテスト範囲と、あとで書く申請書の影響範囲欄になります。

私が使っていた調査の手順

調査の進め方は、数をこなすうちに型になりました。依頼を受けてから、次の順で進めます。

1. 依頼を一文にする「何を、どう変えるか」を一文に書き直します。ここが曖昧だと、調べる範囲も決まりません。
2. 変更する部品から呼び出し元を逆引きするIDEの参照検索と全文検索で、変更する処理を呼んでいる箇所を洗い出します。
3. 画面以外の経路を見るAPI、バッチ、メール通知など、画面を通らずに同じ処理へ届く経路がないかを確認します。
4. DBの列とコード値の参照箇所を見る値の意味や桁数を変える依頼では、その列を読んでいる別の処理まで広がります。
5. 検索で拾えない呼び出しを目で追う画面IDや処理名が設定ファイルや文字列で書かれている箇所は、検索に出てきません。
6. 調査結果表にまとめる影響する場所・確認方法・テストの要否を一覧にして、レビュアーに先に見てもらいます。

5番目が、私の現場で一番時間を食った部分でした。呼び出し関係の一部を設定ファイルや文字列に持っている作りで、IDEの参照検索だけでは「ここで終わり」と言い切れなかったからです。

1件に半日〜1日かかる3つの理由

時間がかかった理由は、突き詰めると次の3つでした。

実際に調べた依頼の例を、時間とあわせて並べます。

「小さな依頼ほど調査が短い」とは限らない点が、この表の見どころです。直すコードが数行でも、共通部分に触れる依頼は、調べる範囲が広がります。

失敗談：3時間で切り上げて、リリースが2週間延びた

保守改善に入って7か月目、私は影響範囲の調査を甘く見て失敗しました。

依頼は、先ほど表に出した見積もり画面の入力チェック条件の変更です。画面側の修正は1か所だけだったので、「これは軽い」と判断し、調査を3時間で切り上げました。調査結果表には「影響画面：見積もり画面のみ」と書いて、レビューに出しました。

その方は、同じ現場に5年以上いる40代くらいの方でした。確認すると、指摘どおり、同じ部品を申し込み画面とマイページの契約内容変更画面も呼んでいました。

そこからが大変でした。調査結果表の書き直し、テスト範囲の追加、そしてすでに出していたリリース申請の取り下げと再申請です。次の審査に回ったため、本来は第2水曜だったリリースが、第4水曜までずれました。

この失敗から、調査の最後に「共通部品・API・バッチ・メール」を必ず見る確認項目を作りました。作り方は、後の章でまとめます。

重いのは調査だけではない｜証跡・ドキュメントの作成が多かった理由

次の層は、証跡とドキュメントです。ここでは、改修1件の作業時間が何にどれだけ使われていたのかを数字で示し、作る書類と、それが多くなる理由を整理します。

小規模な改修1件の作業時間の内訳

画面1つの入力チェック条件を変える、規模としては小さい改修1件を例に、当時の作業の感覚を振り返って内訳にしました。

小規模な改修1件の作業時間 約25.5時間の内訳

影響範囲調査 6.5h 設計書 3h 実装 2.5h テスト・証跡 6.5h レビュー 3h リリース書類 4h

• 影響範囲調査（6.5時間）とテスト・証跡（6.5時間）
• 設計書の更新（3時間）とレビュー対応（3時間）
• 実装（2.5時間）とリリース関連の書類（4時間）

実装が2.5時間なのに、全体では25.5時間かかっています。コードを直す時間は全体の約1割で、残りは調査・テスト・書類でした。

新規開発であれば、時間の中心は実装です。保守改修は、実装の外側にある作業のほうが主役になりやすい。この比率が頭に入っていないと、「数行の修正なのに、なぜ3日もかかるのか」という話になってしまいます。

保守改善期に作っていた書類

1件の改修ごとに、私が作っていた主なドキュメントと証跡は次のとおりです。

テスト証跡の取り方そのものは、別の記事に詳しく書きました。

単体テストの証跡で何枚撮るかなどの粒度は、4社目の実例で整理しています。

関連記事単体テストのエビデンスはExcelにスクショ？SES現場の取り方SESの客先常駐で単体テストのエビデンスとしてExcelにスクリーンショットを貼り続けた4社目の実体験から、なぜこの形式なのか、…

なぜここまで書類が増えるのか

書類が増える理由は、現場の趣味ではなく、リリースを管理する仕組みの側にあると私は見ています。私の現場で書類が増えていた背景は、次の3点に整理できます。

審査される側の私は、その材料を作る係でした。外部の解説と照らすと、この仕組みは私の現場に限った話ではなさそうです。

リリース管理を解説するベンダー記事では、リリースの可否を判断するGo/No-Go、問題があったときのロールバック（切り戻し）手順の用意、変更内容とチケットの紐付けが、要素として挙げられています（出典: crexgroupのリリース管理の解説（ベンダー記事））。私の現場の申請書は、これらをほぼそのまま書類にした形でした。

変更管理の側では、ITIL 4が変更を標準・通常・緊急の3つに分類するとされています。変更管理を解説するSplunkのベンダー記事では、変更諮問委員会（CAB）による審査が、変更の遅れにつながりうる点も指摘されています（出典: Splunkの変更管理の解説（ベンダー記事））。

リリース手順が重い｜申請から本番反映までの流れと、待ち時間の長さ

3つ目の層は、リリース手順そのものです。ここでは、私の現場で小さな改修が本番に出るまでの流れと、作業時間よりも待ち時間が長くなる理由を書きます。

小さな改修が本番に出るまでの流れ

依頼を受けてから本番に反映されるまでの流れは、次のようになっていました。

1. 依頼の受領連絡窓口のリーダーから
2. 調査・設計影響範囲を洗い出す
3. 実装・テスト単体・結合と証跡
4. レビューコードと証跡を毎回
5. リリース申請審査の2営業日前が〆切
6. 審査週1回、承認は3段
7. 本番反映と確認第2・第4水曜の枠

申請書は、保守チームのリーダー、客先側の窓口リーダー、リリース判定の審査と、3段階の承認を経て通ります。審査は週に1回で、定期のリリース枠は月2回、第2・第4水曜の日中でした。

つまり、1つの改修を出し損ねると、次の枠まで最大で2週間待つことになります。

作業時間は3日、依頼から本番までは3週間

先ほどの小規模な改修は、実作業が約25.5時間（3日強）でした。ところが、依頼を受けてから本番に反映されるまでは、私の感覚で3週間前後かかっています。

小規模な改修1件の、作業時間と経過期間の差です。感覚値ですが、差の大部分は待ち時間でした。

利用部門からは、「数行の修正なのに、どうして3週間もかかるのか」と窓口のリーダー経由で聞かれたことがあります。窓口のリーダーは、作業時間と待ち時間を分けて説明してくれていました。

私自身も、待ち時間の長さは仕組み上避けられないと感じていました。ただ、重さの正体は作業量よりも、待ちと手戻りの単価の高さです。冒頭の失敗談のとおり、手戻りが1回入るだけで、リリースが1枠分、つまり2週間後ろにずれます。

緊急で出したいときは別の枠になる

障害の修正は、定期枠を待てません。私の現場では、通常の流れとは別に「緊急扱い」の枠があり、保守チームのリーダーと窓口のリーダーの承認で、審査会を待たずに反映できました。

ただし、緊急にした分、事後の報告が重くなります。原因・影響・再発防止策をまとめた報告書を、反映の後に出さなければなりません。急いで出した修正こそ、後から書類で説明する仕組みでした。

前述のITILの3分類でいう、標準・通常・緊急の考え方に近いと理解しています。ただし、現場がITILに準拠していたかどうかは、私は確認していません。

夜間リリースとは？半年に1回あった理由と当日の流れ

結論夜間リリースとは、利用者が少ない時間帯に本番へ反映する作業のことです。私の現場では、サイト停止を伴う変更のときだけ、半年に1回ほどありました。

ここまでは日中の定期リリースの話でした。ここからは、夜間リリースがなぜ必要なのか、当日はどんな流れだったのか、そして夜間であることのコストを書きます。

夜間リリースになるのはどんなとき

通常の改修は、サイトを止めずに日中の枠で反映できます。夜間になるのは、サイトの停止やDBの構造変更を伴い、利用者が使えない時間を作らざるを得ない変更のときです。

私の保守改善期は約1年半で、夜間リリースは3回ありました。頻度は半年に1回ほどで、月2回の枠で出ていた日中のリリースとは別の話です。

当日の時間割

3回の中で、一番標準的だった回の時間割を示します。作業はVPNで自宅から接続し、客先の運用担当者と通話をつないだまま進めました。当日の日中の勤務の扱いは現場や時期の規程次第なので、ここでは夜の流れだけを載せます。

作業者と確認者が二人一組になり、手順書を読み上げながら進めるのが決まりでした。一人が作業し、もう一人が手順書と照らし合わせて確認する形で、ミスを減らすための仕組みです。

手順書の一行が抜けていた回

2回目の夜間リリースでは、小さなトラブルがありました。反映後の動作確認で、画面の文言が更新前のまま表示されたのです。

キャッシュを削除すると、文言は正しく表示されました。復旧までに25分ほどかかりましたが、切り戻しの期限には間に合いました。

終わった後に手順書へ追記し、次回からはリハーサルの確認項目にも入れました。移行期にも手順書の漏れはありましたが、夜間リリースでも同じことが起きる、というのが私の実感です。

データ移行の本番切り替えで同じ種類のトラブルがどう起きたかは、別の記事に書きました。

関連記事SESのデータ移行案件はきつい？本番切り替え24時間、リハーサルと切り戻しの実際SESのデータ移行案件はきついのか。リハーサルと本番切り替えの実施を約1年担当した体験から、24時間以上の切り替え当日の流れ、リ…

夜間であることのコストとリスク

夜間のリリースには、手順の重さとは別に、夜であること自体のコストがあります。深夜メンテナンスのコストとリスクを扱ったエンジニアの発表資料もあります（出典: SpeakerDeckの深夜メンテナンスに関する発表資料）。

私の実感でも、夜は判断の精度が落ちます。23時を過ぎると、手順書の読み間違いを自分で疑う余裕が減っていきました。二人一組の確認は、この疲れを補う意味もあったのだと思います。

夜間の作業時間は残業として申告し、3社目の残業は実費で支給されました。呼び出しや夜間対応の手当・労務の考え方は、別の記事にまとめています。

関連記事SESのオンコール・夜間呼び出しに手当は出る？待機手当・残業代・断れるかを整理SESの保守案件でオンコール待機や夜間・休日の呼び出しがあるとき、待機手当や残業代は出るのか。対応した時間の割増、待機時間が労働…

保守改修のリリースを軽くするために、私がやった工夫

重さの原因が分かっても、仕組みそのものは二次請けのメンバーには変えられません。それでも、自分の作業の範囲で軽くできた部分はありました。ここでは、効果があった工夫と、変えられなかったことを分けて書きます。

調査：確認項目を作ったら、見落としの手戻りがなくなった

前述の失敗の後、影響範囲の調査に使うチェック項目をExcelで作りました。中身は、共通部品、API、バッチ、メール通知、設定ファイル側の呼び出し、DBの列の参照、の6項目程度です。

効果は、調査時間が減ったことではありません。時間は1割ほど減った程度で、半日〜1日という水準は変わりませんでした。変わったのは、手戻りです。それ以降の約11か月は、影響範囲の見落としで申請を出し直したことは一度もありませんでした。

調査の時間を削るのではなく、見落としを減らして手戻りを避けるほうが、トータルでは軽くなります。

証跡：前回の資料を雛形にして、書き直しを減らした

証跡と書類は、ゼロから作らないことが一番効きました。直近で通った同種の改修の資料をコピーし、変更箇所だけを書き換える形にします。

リリース申請書の「切り戻し手順」と「影響範囲」は、型がほぼ決まっていました。雛形を整えただけで、リリース関連の書類は、体感で1時間前後は短くなっています。

申請：切り戻し手順を先に書く

意外に効いたのが、実装より先に切り戻し手順を書くことでした。「戻すとしたらどうするか」を最初に考えると、DBの変更を伴うかなど、改修の危うい部分が早く見えます。

切り戻しが難しい改修だと分かれば、設計の段階で、段階的に出す方法や影響を小さくする方法を相談できます。

変えられなかったこと

正直に書くと、変えられなかったことも多くあります。審査の頻度、承認の段数、リリース枠の回数は、客先と上位会社が決めたもので、私の立場から提案する余地はありませんでした。

証跡の様式についても同じです。様式を変えるには、客先の承認が必要でした。これは、同じ二次請けの立場だった4社目のテスト証跡の取り方で感じたことと共通しています。

3社目で身につけた「影響範囲の調査の型」と「リリース手順・証跡の作り方」は、4社目の現場で、今も役立っています。ただ、重い仕組みから自力で抜け出せたわけではなく、重い仕組みの中で手戻りを減らす型を持てたというのが、正確な言い方です。

保守案件で身につくスキルの全体像は、4社目の話を軸に別の記事へまとめています。

関連記事SESの保守案件・保守運用はスキルがつかない？改修9か月で身についたことと抜け出し方SESの保守案件はスキルがつかないのか。社内向け業務システムの保守・改修に9か月ほどいる現役エンジニアが、身についたこと・積みに…

保守改修の案件に入る前に確認したいこと

結論リリースの重さは、入る前に聞けば分かる部分が多いです。頻度・承認の段数・夜間の有無・調査工数の扱いの4点は、面談か参画直後に確認できます。

ここまでの話を、案件選びや参画直後の確認に使える形に変えます。保守改修の案件は、同じ「保守」でも、リリースの重さが現場ごとに大きく違うからです。

聞いておくと見通しが立つ項目

特に4つ目の、調査時間の扱いは見落とされがちです。私の現場では、依頼を受けた際、リーダーが最初から「影響範囲の調査に半日〜1日」を工数に含めて回答していました。

そのおかげで、「なぜ数行の修正に3日かかるのか」と利用部門に聞かれても、説明できる根拠がありました。調査時間を見積もりに含めない現場では、メンバーが自分の時間を削って調査し、見落としが増える傾向があると感じます。

関連記事SESで工数見積もりを任されたら｜根拠の出し方と、ズレそうなときの報告の型SESで工数見積もりを任されたときの進め方を、保守改善での初見積りの失敗から整理します。根拠の出し方、影響範囲調査の切り出し方、…

重いことは悪いことではない

ここまで読むと、リリースが重い現場は避けたほうがよい、という印象になるかもしれません。私はそうは考えていません。

重い手順は、金融系のサイトのように、間違いが利用者の契約や金銭に直結する現場では、必要な防御です。実際に、私は手順が厚い現場だったから、影響範囲の調査や切り戻しの考え方を型として身につけられました。

避けたほうがよいのは、重さに見合った説明も工数の配慮もない現場です。重さの理由が分かり、かかる時間を見積もりに載せられる現場なら、スキルとして残るものも多いと思います。

まとめ

SESの保守改修でリリースが重くなるのは、一度出したものを簡単に戻せないからです。そのため、出す前の確認が、調査・証跡・申請という3つの層に分かれて厚くなります。

私が一番伝えたいのは、重さの正体は作業の量ではなく、待ちと手戻りの単価の高さだということです。時間を削る工夫より、見落としを減らして手戻りを避ける工夫のほうが、トータルでは効きました。

これから保守改修の案件に入る方は、頻度・承認の段数・夜間の有無・調査工数の扱いを、面談か参画直後に聞いてみてください。すでに重い現場にいる方は、まず今月の依頼を1件選び、調査・テスト・書類・待ちに何時間かかったかを書き出してみると、自分の現場の重さの内訳が見えてきます。