リリース頻度向上とテスト期間短縮の判断
従業員300名の物流会社F社は、15年前に構築した受注管理システム（年間保守費1,800万円）を更改する。現行は年2回のリリースで、変更のたびに2週間のテスト工程を置いている。新システムはクラウドのSaaSを採用し、四半期ごとのリリースを検討中である。現行では本番環境と検証環境の設定差異が原因の障害が過去2年で7件発生し、うち2件は顧客への請求金額の誤りだった。テスト項目書はExcelで管理され、内容を理解しているのは担当者2名だけで、リリース判定は部長の経験的判断で行われている。経営層からは「リリース頻度を上げ、テスト期間を2週間から5日に短縮せよ」との指示が出ている。回帰テストは手作業が中心で、自動化は請求計算の一部のみ。ベテラン担当者2名が来年度に定年を迎える。取引先約400社のうち120社はEDIで接続しており、項目変更には事前調整が必要である。
1. テスト期間を2週間から5日に短縮する場合、どのリスクが高まるか。許容できる条件と併せて述べよ。
Read the worked answer
短縮で真っ先に削られるのは、回帰テストの網羅、異常系・境界値の確認、そして障害発生時の原因切り分けの時間である。特に本番と検証環境の設定差異が過去2年で7件（うち請求誤り2件）の障害を起こしているため、環境差異に起因する不具合はテスト工程では検出できず、本番で初めて表面化する。請求金額の誤りは返金・謝罪・信用低下まで波及し、金銭影響が大きい。EDI接続120社は項目変更に事前調整が必要で、リリース後の修正が最も難しい領域である。 許容できる条件は4つ。①回帰テストが自動化され、5日で実行と判定が回る、②構成管理（IaC・構成ドリフト検出）により環境差異が解消済み、③請求計算とEDI連携は重点対象として別枠のテスト時間を確保、④カナリアリリースと切り戻し手順が検証済み。①〜④が揃わない状態での短縮は不可と判断すべきである。
2. リリース判定を部長の経験的判断から、再現性のある基準に置き換えるにはどう設計するか。
Read the worked answer
判定基準を「品質」「影響範囲」「準備」の3軸に分けて数値化する。
- 品質：テスト実行率・合格率に加え、未解決不具合を重大度別に上限設定する（例：重大度A＝0件、B＝3件以下かつ回避策あり）。合格率だけでは重大不具合の見落としを防げない。
- 影響範囲：変更機能の利用者数、金額影響、影響する外部インタフェース（EDI120社など）。影響が大きい変更は別枠の基準を設ける。
- 準備：切り戻し手順の確認、運用側への周知、監視項目の設定、問い合わせ窓口の体制。 加えて「誰が判定するか」を規程化し、変更管理委員会の承認を必須にする。経験的判断は排除せず、基準を満たさない場合の例外承認として理由と期限を記録する。判定結果と本番障害を半期ごとに突き合わせ、基準値そのものを見直す運用まで含めて設計する。
3. ベテラン2名の退職までに、属人化を解消する優先順位を示せ。
Read the worked answer
優先順位は「失われると復旧できない知識」から決める。
- 本番構成とリリース手順：環境構成図、切り戻し手順、監視の見方。完了条件は「別の担当者が1人でリリースを完遂できること」とし、実際にやらせて確認する。文書が存在することは完了条件にしない。
- 請求計算とEDI連携のテスト：影響が大きく変更が難しい領域から自動テスト化する。全項目書の移行は期間内に不可能なので、金額計算・締め処理・EDI連携を最優先にする。
- 障害対応記録の検索可能化：過去の障害について原因・対処・再発防止を残し、同じ事象が起きたときに辿れるようにする。
- 引き継ぎ期間の確保：3か月以上のペア作業を設定し、退職前に受け手が主体となって作業する期間を作る。 なお、テスト期間5日への短縮と自動化は同一の作業を二重に負う。自動化を先行させ、その成果をリリース頻度の根拠にする順序が現実的である。