【システム開発とは何か】システム更改で学ぶ、プログラミングだけではない仕事の全体像

システム開発と聞くと、新しいサービスや業務システムを作り、エンジニアがプログラムを書く仕事を想像する人が多いのではないでしょうか。

企業のシステム開発プロジェクトは、大きく分けると、新しいシステムを一から作る「新規開発」と、すでに稼働しているシステムを次の環境へ引き継ぐ「システム更改」があります。

SIerで多くのシステム開発を経験してきましたが、プロジェクトの多くは新規開発ではなく更改です。

新しい業務機能をほとんど作らないプロジェクトでも、数億円規模の予算が組まれ、数十人の関係者が参加し、完了まで1年以上かかることがあります。プログラムを書く以外に、何にそれほどの時間と費用がかかっているのでしょうか。

今回は、A銀行の融資審査システムをAWSへ移行するクラウドリフトを例に、システム更改の現場で何が行われているのかを見ていきます。現行調査、データ移行、テスト、運用引継ぎ、そしてステークホルダー間の調整という構造は、多くのシステム更改に共通するものです。

システム開発全体の工程や、機能要件・非機能要件の基本的な考え方は、次の記事で説明しています。あわせて読むと、個々の作業がプロジェクト全体のどこに位置するのかを理解しやすくなります。

【前編】システム開発の流れを現場目線で理解する｜システム開発はプログラミングだけでは終わらない

【後編】システム開発の流れを現場目線で理解する｜要件定義・テスト・移行・運用保守のリアル

なぜシステムを更改しなければならないのか

A銀行の融資審査システムは、データセンター内に設置されたサーバーで稼働しています。企業が自ら調達・管理するサーバーやネットワーク機器を使ってシステムを構築・運用する形態を、オンプレミスと呼びます。

このサーバーが、2年後にメーカーの保守終了時期を迎えます。現場ではEOSLなどと呼ばれます。OSやデータベースなどのソフトウェアも、順次サポートが終了する予定です。

保守が終了した製品を使い続けると、故障時に交換部品を調達できなかったり、脆弱性が発見されても修正プログラムが提供されなかったりする可能性があります。銀行システムとして長期的に使い続けることは難しく、通常は期限を迎える前に更改が必要になります。

従来であれば、新しい物理サーバーを購入し、データセンター内に次期システムを構築する方法が有力でした。今回のA銀行は、機器を買い直すのではなく、AWSへの移行を選択します。

既存システムの構成や機能を大きく変えず、稼働場所をオンプレミスからクラウドへ移す方式を、リホストと呼びます。一般にはクラウドリフトと呼ばれることも多い移行方式です。

A銀行は移行期限を優先し、現在の融資審査機能を大きく変えずにAWS上で安定稼働させるため、サーバーの移行はリホストを基本としつつ、保守終了を迎えるOSやミドルウェアはあわせてバージョンアップする方針を選びました。

実際の更改案件でも、一つの方式だけですべてを移すとは限らず、システムや製品ごとに複数の方式を組み合わせます。

クラウド移行には、OSやミドルウェアの構成を一部見直すリプラットフォーム、アプリケーションの構造そのものを作り替えるリアーキテクチャ、外部事業者が提供する業務サービスへ置き換えるSaaS移行などの選択肢もあります。

「同じ機能を移すだけ」でも作業は減らない

業務機能を変えないのであれば、現在のサーバーをそのままクラウドへコピーすればよいと思うかもしれません。

実際には、オンプレミスとクラウドでは、サーバー、ネットワーク、セキュリティ、障害対策、バックアップ、監視、料金体系など、設計・運用上の前提が多くの点で異なります。アプリケーションをほとんど修正しないクラウドリフトであっても、コピーして終わりにはできません。

クラウドリフトの開発ポイントは以下の記事で解説しています。

【第1部】クラウドリフトの失敗は構築前に始まっている｜PoC不足が手戻り・コスト超過・納期遅延を招く理由

A銀行のプロジェクトでは、主に次の作業が発生します。

このうち、プログラミングに該当するのは、アプリケーション対応の一部です。

OSやミドルウェアのバージョンアップによって動かなくなった箇所を修正する、いわゆる非互換対応が中心で、新しい業務機能を大量に作るわけではありません。

更改プロジェクト全体から見れば、プログラム修正は数多くある作業の一つにすぎないのです。

最初の壁は「現在のシステムを知ること」

更改で最初に必要になるのは、現在動いているシステムを正確に把握することです。

当たり前に聞こえるかもしれませんが、ここが一番の難所だと私は考えています。

A銀行の融資審査システムには、画面へのアクセスを受け付けるWebサーバー、アプリケーションを動かすAPサーバー、データを管理するDBサーバーがあります。

それだけではありません。顧客情報を管理する別システム、信用情報機関との接続、行内の認証システム、帳票出力、メール送信、夜間に決められた処理をまとめて実行するバッチ処理など、多数の仕組みと連携しています。

サーバーの一覧だけを見て移行計画を立てると、こうした依存関係を見落とします。

アプリケーションは正常に起動しているのに、外部システムとの通信が許可されておらず審査が完了しない。サーバーの移行には成功したのに、ファイルの受け渡し時刻がずれ、翌朝の業務に必要なデータが取り込まれない。どちらも現場で実際に起きる話です。

現行調査では、機器やソフトウェアの一覧に加えて、誰がいつ使っているのか、どのシステムとどのような方式で通信しているのか、毎日・毎月・年度末に動く処理は何か、障害発生時に何時間以内で復旧する必要があるのか、データを何年間保存するのかといった情報まで確認します。

長く動いているシステムほど、設計書に書かれていない運用や、担当者だけが知っている作業が眠っています。

私の経験でも、現行調査の抜けは、移行直前の仕様追加やサービス開始後の障害に直結します。更改プロジェクトの品質は、この地味な調査工程でほぼ決まると言ってよいくらいです。

移行とテストは「正しさを証明する」工程

更改では、現在のデータベースに保存されている顧客情報や審査情報を新しい環境へ移します。

ここで大事なのは、データをコピーできたという事実だけでは、移行成功と判断できないことです。

移行前後でデータ件数が一致しているか、文字化けや桁落ちがないか、審査履歴が正しい顧客にひも付いているか、移行作業中に更新されたデータが欠落していないかを確認します。

銀行システムを長時間停止できない場合は、事前にデータの大部分を転送し、切り替え当日に更新分だけを反映する方式も検討します。

移行に失敗した場合に旧システムへ戻す切り戻し計画も、原則として必要です。

切り替え作業を進めると、新環境で入力されたデータや外部システムへ送信した情報が発生し、単純には旧環境へ戻せなくなる時点があります。どの時点まで切り戻せるのかを明確にし、それ以降に問題が発生した場合の復旧方針も決めておかなければなりません。

切り替えに向けては、どの確認項目が未達なら切り戻すのか、何時までに判断するのかを事前に定めます。判断基準がないまま当日を迎えると、問題が起きた際に意思決定が遅れ、業務への影響を広げます。

テストの観点は後編で説明した内容と重なりますが、更改には特有の視点があります。

新規開発では、新しく定めた要件どおりに動くかという確認の比重が高くなります。更改のテストで軸になるのは、現行環境と新環境で同じ処理を流し、業務として同等の結果になるかを突き合わせる現新比較です。

日付、処理時刻、採番された番号など、意図的に結果が変わる部分については、あらかじめ差分として整理しておきます。

正常時の処理結果だけでなく、障害発生時の切り替え、バックアップからの復元、運用手順に沿った対応まで確認して、初めて本番利用へ進めます。

ステークホルダー：誰がプロジェクトを動かしているのか

更改プロジェクトには、多くの組織が参加します。

プロジェクトに影響を与える人や組織、プロジェクトの結果から影響を受ける人や組織を、ステークホルダーと呼びます。

A銀行のプロジェクトでは、主に次のステークホルダーが関係します。

実際のプロジェクトでは、外部接続先、製品ベンダー、コンサルティング会社、監査部門などがさらに加わります。

ここで押さえてほしいのは、各担当が自分の作業を完了させても、プロジェクト全体が成功するとは限らないことです。

アプリケーション担当がプログラム修正を終えても、クラウド・基盤担当との認識が合っていなければ、外部システムへ接続できません。基盤担当がバックアップを設定しても、業務部門が必要とする保存期間を把握していなければ、業務要件を満たせません。

こうした組織間の隙間を埋めるのが、プロジェクトマネージャーの仕事です。

データ移行方式を一つ決める場合でも、業務部門からシステムを停止できる時間を確認し、アプリケーション担当から停止中の処理を確認します。基盤担当からはデータ転送に必要な時間を、運用担当からは切り替え後の監視体制を確認し、全体として成立する計画に組み上げます。

プロジェクトマネージャーは、すべての事項を自分で決裁する立場ではありません。

各分野の技術的な論点を理解し、未決定事項を放置せず、判断者を明確にして必要な判断を引き出し、決定事項をプロジェクト計画へ反映していく役割です。

大規模更改の成否は、この力量に大きく左右されます。

クラウドリフトで誤解しやすい3つのこと

最後に、クラウドリフトについて現場でよく見る誤解を3つだけ挙げておきます。

運用はなくならない

クラウドでは、物理サーバーやデータセンター設備の管理をクラウド事業者が担います。利用企業の責任がゼロになるわけではありません。

AWSは、クラウド事業者と利用者がそれぞれ管理する範囲を責任共有モデルとして整理しています。

EC2を使ったリホストでは、データ、アクセス権限、ネットワーク設定、ゲストOS、アプリケーションなどの管理が利用者側に残ります。RDSのようなマネージドサービスを利用する場合は、AWSが管理する範囲が広がり、利用者との責任の境界も変わります。

クラウド事業者が基盤を安全に運用していても、利用者側が管理者権限を広く付与しすぎていれば、不正アクセスの危険は残ります。

移せば安くなるわけではない

クラウドでは、サーバーの稼働時間、ストレージ、バックアップ、ログ、データ転送、監視、サポートなどに費用が発生します。

オンプレミスと同じ台数、同じ性能のサーバーを24時間動かすだけでは、期待したコスト削減にならないケースを私は何度も見てきました。

コスト最適化は、移行時に一度行えば終わる作業ではありません。稼働後も利用状況を確認し、過剰な性能、使われていない環境、不要なデータなどを継続的に見直します。

リフトだけではデジタルトランスフォーメーション（DX）にならない

稼働場所を変えただけでは、業務や顧客価値の変革までは起きません。

クラウドリフトの価値は、老朽化設備への対応だけではなく、物理機器の調達や保守から離れ、将来クラウドに適した構成へ段階的に作り替えるための基盤を整えられることにあります。

その基盤を利用して、業務の自動化、データ活用、サービス改善、開発速度の向上などを実現することで、DXへつながります。

クラウドへの移行自体を目的にせず、クラウドを利用して何を改善するのかを先に決める必要があります。

システム更改とは、サービスを次の環境へ引き継ぐこと

A銀行のプロジェクトでは、新しい業務機能をほとんど作りません。

それでも、現在のシステムを調査し、クラウド基盤を設計し、アプリケーションを対応させ、データを移行します。テストによって正しさを証明し、多数の関係者と切り替え日程や判断基準を調整します。

システム更改とは、古いサーバーを新しいサーバーへ交換するだけの作業ではありません。

現在提供しているサービスを、安全かつ確実に次の環境へ引き継ぐプロジェクトです。

システム開発がプログラミングだけではないことが、更改という実例を通じて見えてきたのではないでしょうか

プロジェクトを成功させるには、個別の技術に加えて、業務とシステムの関係を理解し、複数のステークホルダーをつなぎ、必要な判断を積み重ねる力が求められます。

次回は、このような更改プロジェクトにどのような費用が発生するのかを説明します。クラウド利用料だけでなく、設計、開発、テスト、移行、プロジェクト管理といったシステム開発コストの内訳を具体的に見ていきます。

システム開発入門シリーズ

【前編】システム開発の流れを現場目線で理解する｜システム開発はプログラミングだけでは終わらない

【後編】システム開発の流れを現場目線で理解する｜要件定義・テスト・移行・運用保守のリアル