どんなシステムでもバージョン管理されているのが一般的。
システムはより使いやすくよりセクシー(？)に、常にバージョンアップされていくのが昔から続いている不変の理です。
業務システムでもゲームアプリでも質の良いバージョンアップや時代に合ったバージョンアップを続けることでユーザの心を惹き、長年愛されるシステムとなります。人気のあるシステム／アプリにする為にはバージョンアップにこそ力を注ぐべきです。
システム開発におけるバージョンアップとは？
本題に入る前に、バージョンアップという言葉の定義に触れておきたいと思います。
バージョンアップとは主に「ソフトウェアやハードウェアにおいて、新しい機能の追加やバグの修正、仕様の変更などにより改良や改善が加えられ機能が強化されること。」です。また、バージョンアップの中にも下記のような大きな種類に分類されます。
・メジャーバージョンアップ
大きな変更が伴うアップデート。大きな新機能が追加された場合や、UIなどが大幅に変更されていたり、フレームワークが変わった場合などに該当することが多いです。
・マイナーバージョンアップ
小さな仕様の変更やちょっとした機能追加、不具合の修正など細かい要件変更などの場合に該当します。
システムの多くはバージョンアップ時に備え、バージョン情報があります。
多いのは数字ですね。
メジャーアップデート：1.00 → 2.00
マイナーアップデート：1.00 → 1.01 or 1.10
また、一口にバージョンアップと言っても、システムによってその頻度や方法は様々です。筆者が所属する会社はSIベンダーである為、あるパッケージに対してユーザ要望のカスタマイズをして導入していたり、パッケージ自体をどんどん機能改善してバージョンアップすることが多いです。
今回のブログではとある業務パッケージに対してカスタマイズが施されているシステムをバージョンアップすることを前提として、執筆していきます。
バージョンアップ開発の計画工程
今回、例として取り上げるバージョンアップは「以前カスタマイズしてユーザに導入した業務パッケージのバージョンアップ」です。SIベンダーはパッケージベンダーと提携しており、各ユーザ要件に合わせてカスタマイズを実施し導入しています。パッケージのバージョンが上がった場合は、その新バージョンに対して再度カスタマイズを実施するイメージとなります。
まずは計画ですが、いくつか準備する必要があります。
・現行バージョンと新バージョンの機能差異（機能管理）
パッケージにカスタマイズしている場合、バージョンの確認が必要になります。
例えば、システムをカスタマイズして導入したのが10年前だとしましょう。
その間、パッケージ側では様々なバージョンアップが行われているはずです。
その内容を把握しないことにはバージョンアップの方針を決められません。
パッケージ側のバージョンアップとカスマイズ内容がバッティングしていたり、開発方法が変更されていることがあります。
これらを把握しなければ、開発スコープを正確に捉えることができません。
【OBPMを利用した機能管理】
・バージョンアップ範囲(スコープ管理)
これはバージョンアップ開発に限ったことではありませんが、とても重要な事です。範囲を明確にしなければ納期もコストも計画出来ません。
・外部システム連携の把握(スコープ管理)
パッケージをバージョンアップすることで、データベースの内容が変更されると外部システムとの連携に何かしらの不具合が発生します。外部システムとのトラブルの場合、他社ベンダーが管理していることも多く、プロジェクトが進めば進むほどリカバリが難しくなりリスクが上がります。
まずは、バージョンアップ対象のシステムと連携している全システムの構成が、認識しているものとあっているか確認する必要があります。
【OBPMを利用したスコープ管理】
・新バージョンのソースコードの理解（リスク・課題管理）
筆者は以前大型案件のバージョンアップで痛い目を見たことがありました。
パッケージ側で用意されていた共通APIの仕組みが大きく代わり、カスタマイズ・アドオンしていた機能から利用していた共通APIが一切合切動かなくなり、泣く泣く全て手動で変更したことがありました。
事前にソースコードの内容を把握していれば、共通API分の費用も別途見積に含める事ができたハズでしたが、それを怠ってしまったため記載したようなトラブルを招いてしまいました。
・サードパーティツールの把握（リスク・課題管理）
パッケージの機能にサードパーティ製のツールが利用されていることがあります。
帳票ツール、分析ツール、ファイル出力ツール等々。こちらも製品によって様々ですがバージョンアップ後の構成にサードパーティ製のツールが対応しているか確認する必要がありこれを怠ると共通APIで記述したトラブル同様、痛い目を見ることになります。
【OBPMを利用したリスク管理】
【OBPMを利用した課題管理】
弊社のプロジェクト管理ツール「SI Object Browser PM(=OBPM)」では、上記のような複数の機能を用いてプロジェクト管理することが可能です。
バージョンアップ開発の製造工程
実際の開発工程を見ていきましょう。筆者が実際にバージョンアッププロジェクトを運営した際の開発の流れは下記でした。
①基本設計、詳細設計
設計フェーズは通常のカスマイズ開発とそう変わりません。計画工程で調査した内容を元に実際の設計に落としていきます。ただ、パッケージ側のバージョンアップの影響で、以前のカスタマイズ内容と同様に出来ない場合があります。
例えば機能のレイアウトが変わっている場合は、画面設計をイチから考える必要がありますし、画面上のイベントが増えている場合はそれを加味して機能フローを考える必要があります。
その為、以前の設計書から単純にカスタマイズ部を転記する方法はとらず、イチから設計し直すことも多々発生します。
②データベース移行ツール作成
プログラムの前に移行ツール作成するの？と思われる方も多いと思いますが、先に
移行ツールを作成することに大きなメリットがあります。それは単体テスト時です。
プログラム作成の際には当然それにあわせた新しいデータベース構成を開発端末や
サーバに用意すると思いますが、それを先に全て作成しておき開発する環境に適応しておくことで、後々の不整合を未然に防ぐことが出来ます。
仮にプログラマ自身が開発している範囲のデータベース構造が最新化されていたとしても、そのデータに紐づく別機能のデータベース構造が古いまま開発を進めてしまうと、本来開発タイミングで気付けるハズの不整合が結合テスト実施まで見つからない事が多いです。
データベース構造に大きな変更が無い場合は、製造・単体テストと同時変更で実施しても問題ありませんが、可能な限りデータベースを固めてしまうことが重要です。また、想定ボリュームでの移行時間の計測もこのタイミングで実施するのが良いでしょう。
③プログラム開発、単体テスト
プログラムを開発する前には必ず開発する端末やサーバのデータベース構造、共通API、開発元となるソースが最新化されていることを確認します。
手戻りの多い上記が最新化されていれば後々のトラブルを十分防ぐことが出来るハズです。
④結合テスト、総合テスト
基幹システムでの開発では必ずと言っていいほど、上流工程で業務フローを作成しますのでシステム導入タイミングで作成した業務フローがあればそれをベースにテスト仕様書を作成するのが手っ取り早いと思います。業務フローが無い場合は、ユーザに確認して業務フローを作成するところから始めましょう。
総合テストタイミングでは実際運用する実機でのテストを実施するこが多いハズなのでこのタイミングでもう一度移行時間の計測も実施しましょう。
バージョンアップ開発における筆者の持論ですが、バージョンアップ前の動作とバージョンアップ後の動作を比較し、「バージョンアップで変更された以外の箇所が全て同一であること」を確認する方法が一番効率良く、手っ取り早いと思っています。
例えばバージョンアップ後の動作で予期せぬエラーが発生したとしましょう。通常の開発ではエラーの原因を特定することから始めますが、仮にバージョンアップ前の動作でも同じ操作、同じタイミング、同じデータエントリで同様のエラーが発生したとしたら、それはエラーでは無く「仕様」になるからです。
※もちろん契約内容によっては修正する必要はありますし、修正するほうが良いシステムになりますね。
バージョンアップ開発の導入工程
最後は導入フェーズです。作成した新しいバージョンのプログラムをサーバに構築し、データを移行してサービスインします。
ここで気をつけるべき点の多くは通常のカスタマイズプロジェクトと同様です。大きく異なるのは移行データの規模です。
システム導入時には既存システムから数カ月分ないし数年分のデータを移行することが多いですが、バージョンアップ開発プロジェクトでは、既存データをそのまま丸ごと移行することも多いです。
10年以上運用しているシステムのバージョンアップ開発では、このデータ移行フェーズに大きな時間を要する場合があります。しかも移行期間(システム切り替え時間)は短い事が多い為、移行プログラム作成時に計測した値、総合テスト時に計測した値からサービスインのタイミングで予測される移行件数を算出し、より正確な移行計画を作成しておく必要があります。
単純にデータベースをバックアップして新環境へ復元するだけの移行であれば、対して問題になりませんが複雑なシステムであればあるほどバージョンアップ内容も複雑化する為、綿密な移行計画が必要になってきます。
最後に
以上で「カスタマイズ開発とどう違う？バージョンアップ開発とは」を終わります。バージョンアップ開発は意外と簡単に捉えられるケースが多いのでは？という思いから、過去の体験談を元に今回のブログを執筆致しました。
カスタマイズ開発とは違った点でのリスクや気付きなど感じていただければ幸いです。最後まで読んで頂きありがとうございました。
プロジェクト管理全般について詳しくまとめた資料もご用意していますので、ぜひご活用ください。
