目次
はじめに
本稿では、バージョン管理が不十分であったためにアプリケーションでデグレードが発生した経験をもとに、トラブルの防止策について述べています。
バージョン管理が不適切であると、会社の信用を失う可能性があり、それ以上に顧客や関係者にご迷惑をおかけしてしまいます。
二度と同じような問題が発生しないよう、ここでは具体的な事例を元に解説し、読者の皆さまの参考になれば幸いです。
※記載内容は、関係者のプライバシー保護のため一部修正を加えています。
背景
大手SIerの開発チーム（10名程）にサブリーダーとして着任しました。
以前、PMOアシスタントとして関わった別プロジェクトで、ベンダ開発のアプリがバージョン管理の不備によりデグレードを起こし、炎上する事態を目の当たりにしていました。
そのため、バージョン管理の重要性を痛感しており、着任早々に新任の開発リーダーに相談を持ちかけました。
しかし、リーダーからは「今までデグレードを起こしたことがないから大丈夫」という返答があり、バージョン管理の必要性を認識してもらえませんでした。
当時の開発体制は、内製開発部分は新任リーダーが前任者から引き継ぎ、ベンダ開発部分は私が担当することになりました。
内製開発部分のソースコードは、前任リーダーが忙しさを理由にバージョン管理システムに最新化していなかったため、新任リーダーが改めて最新ソースを整備することになりました。
私自身も、内製開発部分のバージョン管理体制の確立を提案しましたが、「現場に入ってまだ2ヶ月程度で、勝手なことをすると混乱を招く可能性がある」と判断し、今回は見送ることにしました。
ベンダ開発分のバージョン管理方法
まずは、前例のないベンダ開発部分のバージョン管理体制を構築するため、ベンダ企業に現状のバージョン管理方法についてヒアリングを行いました。
その結果、ベンダ企業では、改修前後のソースコードをテキスト比較し、その結果を納品物に含める形でバージョン管理を行っていることが分かりました。
そこで、ベンダ企業から提出されたテキスト比較結果を元に、自社側でも改修内容をダブルチェックすることで、バージョン管理の精度を高めることにしました。
内製分でデグレード発生
経緯
そして悪夢は起こりました。
内製開発部分でリリース翌日に、前回リリース時と同様のデグレードが発生したとの連絡を顧客から受けたのです。
この時、私は初めて、前回リリース時にも内製開発部分でデグレードが発生していた事実を知りました。
緊急リリースが翌日に迫る中、チーム総出でデグレードの原因調査と修正作業を行いました。
具体的には、最新ソースの取得、ソースコードのマージ、デグレード発生箇所の特定と修正、修正箇所の重点的なテストなどを、徹夜で行いました。
なんとか翌日のリリース判定会議に間に合い、リリース作業を完了させることができましたが、顧客やエンドユーザーの方々に多大なご迷惑をおかけし、会社への信頼を失墜させてしまう結果となりました。
原因
このデグレード発生の原因を、自分なりに分析した結果、以下の３点が挙げられます。
- 原因１： 前任リーダーが業務の都合上、前回改修時点での最新ソースをバージョン管理ソフトにアップデートしていなかった。
- 原因２： 最新のソースコードを集める作業を一人の担当者が行なっており、その作業内容が適切に実施されているか、別の担当者がチェックする体制が整っていなかった。
- 原因３： 受入テストでデグレードが発生していたにも関わらず、顧客側も改修点のみを確認しており、デグレード発生の観点での確認が漏れてしまっていた。
また、直接的な原因ではありませんが、新任リーダーの「今までデグレードを起こしたことがない」という発言について、裏付けを取ることなく鵜呑みにしてしまったことも、今回の事態を招いた一因だと感じています。
もし、前回リリース時にデグレードが発生していた事実を把握できていれば、チーム全体でバージョン管理の重要性を認識し、適切な対策を講じることができたかもしれません。
内製分のバージョン管理方法
今回のデグレード発生を受けて、内製開発部分のバージョン管理体制を早急に確立する必要性を痛感しました。
幸い、開発マシンのリリース用フォルダには過去リリース分のソースコードが全て残っており、このデータを元にバージョン管理システムの内容を最新化しました。
さらに、以下の内容を盛り込んだバージョン管理手順書を作成し、有識者や上席のレビューを経て、正式に運用を開始しました。
- 開発前にバージョン管理ソフトから最新ソースを取り出す手順書
- 開発後にバージョン管理ソフトに最新ソースをアップデートする手順書
- 上記2つの手順が適切に行われたかについてのチェックを、内部向けリリース判定資料の項目に含める
また、手順書には作業者と確認者のチェック欄を設け、ダブルチェックを徹底することで、人為的なミスを防止する仕組みを構築しました。
さらに、最新ソースの移動にツールを作成し、作業の効率化とミスの削減を図りました。
後日談
これらの対策を講じた結果、次回のリリース時には問題なくリリースを完了することができました。
デグレード発生原因として挙げた原因１と原因２については、上記の内製分のバージョン管理方法によって対策済みでしたが、原因３については、顧客側の管理部から経験豊富な担当者をアサインしてもらい、テスト管理体制を強化していただきました。
まとめ
今回の経験を通して、バージョン管理の失敗は、広範囲に渡り多大な迷惑をかけることを痛感しました。
また、バージョン管理体制の構築・運用には、多少の工数がかかっても、徹底して取り組む必要があると改めて実感しました。
具体的には、以下の３点を常に意識することが重要です。
- バージョン管理の作業方法は適切に計画され、実施されているか、上位者が定期的にチェックする体制を構築する
- バージョン管理の作業は、作業者と確認者を分けてダブルチェックを行う体制を構築する
- 経験豊富な人の意見であっても、鵜呑みにせず、第三者に確認するなどして、裏付けを取るようにする
これらの教訓を活かし、今一度、自身の開発現場におけるバージョン管理体制を見直し、改善すべき点があれば、早急に取り組みましょう。
バージョン管理の不徹底によるデグレード発生が無くなる事を切に願います。