本記事では、その中からデータベースエンジニア（DBA）を取り上げます。

SEの職種全体と、それぞれの役割の違いについては、次の記事で整理しています。

【システム開発入門】システムエンジニアの種類と仕事内容｜SIerのSEはどこまで担当するのか

システムエンジニアの種類と仕事内容を、PM、アプリ、AP基盤、インフラ、ネットワーク、DBに分けて解説。大手SIerで20年以上働いた筆者の経験から、SEのキャリアの広がりや求められるスキルも紹介します。

sys-univ.com

2026.07.27

データベースエンジニアとは

データベースエンジニアは、システムが扱うデータを安全に保存し、必要なときに正しく、十分な速度で利用できるデータベースを設計、構築、運用する職種です。

「データベースエンジニア」という言葉から、テーブル設計やデータモデリングを想像する人もいると思います。私が関わってきたSIerのプロジェクトでは、データベースの構築、性能管理、権限管理、監視、バックアップ、障害対応を担うDBA（データベース管理者）を指すことが一般的でした。

ここからは、長く担当してきたOracle DBAの実務を軸に、物理設計、構築、性能管理、セキュリティと監査、運用、復旧を見ていきます。製品ごとにアーキテクチャや実装方法は異なりますが、DBAに求められる基本的な役割と考え方には共通する部分があります。

DBAの中心的な役割は、論理的に整理されたデータモデルを、安定して稼働できる物理構成へ落とし込むことです。データベース製品をインストールして初期設定するだけではありません。アプリケーションが扱うデータ量、処理量、同時実行数、更新頻度、障害時の復旧要件を踏まえ、業務特性に合った物理構成と運用方式を設計します。

ここでいうデータモデルは、顧客、契約、申請、承認など、業務で扱う情報を整理し、どのような単位で管理するのかを定めたものです。この構造を設計する作業をデータモデリングと呼びます。業務要件やアプリケーションの処理と密接に関わるため、概念モデルや論理モデルの作成は、アプリケーション側が中心になることが多い領域です。

DBAも、完成したデータモデルを受け取るだけではありません。正規化の妥当性、テーブルや列の構成、主キーや外部キー、インデックス、データ量、検索や更新の特性を確認し、性能や運用の観点からレビューや助言を行います。

テーブル設計は、稼働後に変更すると、SQL、画面、バッチ、外部システムとの連携、データ移行、テストまで広い範囲へ影響します。将来のデータ増加や機能追加も見据え、物理設計へ進む前の段階からDBAが関わることが重要です。

主な担当領域は、大きく次のように分けられます。

構築と物理設計

• データベース製品と構成の選定

• インストールと初期設定

• 表領域、データファイル、ログ領域の設計

• 各種初期化パラメータの設計

性能と容量管理

• SQLと実行計画の分析

• インデックスや統計情報の管理

• 性能チューニング

• データ容量と増加量の見積もり

セキュリティと運用

• ユーザー、権限、ロールの設計

• 監査要件への対応

• 監視とログ管理

可用性とデータ保護

• 冗長化と障害時の切り替え

• バックアップとリカバリの設計

移行と製品管理

• システム移行（データ・環境・運用）

• バージョンアップや製品更改

• ライセンスと保守契約の管理

製品ごとに仕組みや用語は異なりますが、アプリケーションの特性を踏まえて構成を決め、稼働後も性能、セキュリティ、可用性、復旧を管理するという役割は共通しています。

アプリケーションの特性から物理構成を設計する

データベースの構築は、アプリケーションの処理内容を理解しなければ始められません。

どの程度のデータを登録し、どの時間帯に更新が集中するのか。長時間の検索、大量更新、夜間バッチなどがあるのか。アプリケーションの処理特性によって、必要なデータベース構成は変わります。

Oracleでは、REDOログのグループ数やサイズ、UNDO表領域の容量と保持期間、各表領域の初期容量や自動拡張の可否などを決めます。これらは、製品の標準値をそのまま採用すればよいものではありません。

更新量に対してREDOログが小さすぎれば、ログスイッチが頻発し、チェックポイント処理の負荷も高まります。次に使用するロググループのチェックポイントやアーカイブが完了していなければ、更新処理に待機が発生することもあります。

長時間の検索や大量更新に対してUNDO領域の容量や保持期間が不足すると、読み取り一貫性に必要な過去のデータを保持できません。ORA-01555（スナップショットが古すぎます）などによって、検索処理が失敗することもあります。

表領域の容量や拡張方法が不適切であれば、データの増加によって業務処理が停止する可能性があります。

容量の見積もりは、初期構築時だけの作業ではありません。どの表が月次や年次でどれだけ増えるのかをアプリケーションチームから引き出し、拡張の余地とストレージの追加時期まで計画に落とします。

DBAが押さえるべきシステム移行の三要素

システム移行というと、旧システムのデータを新システムへ移し替える作業を想像しがちです。実際の移行は、データ移行、環境移行、運用移行の三つで構成されます。DBAはデータ移行を中心に、環境移行と運用移行にも関わります。

データ移行では、移行対象、停止時間、移行方式、データ変換、移行後の確認方法を設計し、本番相当のデータ量でリハーサルを行います。移行後の統計情報が適切でなければ、データを正しく移せても、業務開始後に性能問題が発生することがあります。Oracle 19cへのバージョンアップでは、統計情報の更新を契機に実行計画が変化した事例もあり、移行後は主要なSQLの実行計画と性能まで確認する必要があります。

Oracle 19c更改後に実行計画が変わる――パーティション削除時の統計情報更新と影響調査漏れ

Oracle Database 19cへの更改後、DROP PARTITIONを契機に表統計の一部が更新され、実行計画とSQL性能が変化した事例を解説。AWRやPLAN_HASH_VALUEによる原因調査、統計情報の再収集、SQL Plan Baseline、更改時の影響調査と試験の観点を整理します。

sys-univ.com

2026.07.22

環境移行では、データベースを構築するだけでなく、tnsnames.oraや接続文字列、DNS名などを新環境へ切り替えます。運用移行では、監視、バックアップ、ログ収集、ジョブ、障害対応などを新環境でどのように実現するのかを決めます。バージョンや提供形態が変われば、従来の運用ツールやスクリプトがそのまま動くとは限りません。

データを移し替えただけでは、システム移行は完了しません。移行の全体像と、どこで失敗が起きやすいのかは、別の記事で整理します。

マネージドサービスでも設計は残る

マネージドサービスを利用する場合も、この考え方は変わりません。

RDSではパラメータグループを通じて設定を変更し、変更できる範囲は製品そのものより狭くなります。

標準値のまま構築してよいという意味ではありません。決められる範囲が限られた中で、業務特性に合う値を選ぶ作業が残ります。

クラウドサービスが引き受けるのは、データベース運用の一部です。どのような性能が必要なのか、障害時にどこまで業務を継続するのか、どの時点までデータを戻すのかといった判断まで、クラウド側が決めてくれるわけではありません。

RDS for Oracleへ移行すると、SYSDBA権限やOSへのアクセス、ストレージ管理、監査ログの扱いなど、オンプレミスで前提としていた運用をそのまま持ち込めない場面があります。具体的な設計ギャップと代替方法は、次の記事で詳しく整理しています。

RDS for Oracleを採用したら、オンプレ運用の前提が通用しなかった｜開発中に見えた設計ギャップと代替アプローチ

RDS for Oracleではオンプレ運用の前提が通用しない。Storage-Full、アーカイブログ、SSH不可など、開発中に見えた9つの設計ギャップと代替アプローチを整理します。

sys-univ.com

2026.07.12

データベースは構築後も変化し続ける

システム基盤との大きな違いの一つは、構築後も継続的な調整が必要になることです。

サーバーやOSは、構築時に適切な構成を決めれば、稼働後に設定を大きく変えずに運用できるケースもあります。

データベースでは、データ量や分布、利用者数、業務処理の内容が日々変化します。昨日まで高速だったSQLが、データの増加や統計情報、実行計画の変化によって突然遅くなることもあります。

一つのSQLを改善して終わりとは限りません。業務機能の追加やデータ量の増加によって別の処理が遅くなり、新たな実行計画の変化が発生します。

稼働後も監視、分析、改善を繰り返すのが、データベース運用の実態です。

性能問題はデータベースだけでは解決できない

性能問題が発生した場合、CPUやメモリの使用率を見るだけでは原因を特定できません。

遅いSQLを特定し、実行計画や待機状況を確認しながら、検索対象となるデータ量、結合順序、アクセスパス、統計情報、キャッシュの状態、I/O、ロック競合などを横断的に調べます。

同じSQLでも、必要なデータがメモリ上にあるか、ストレージから読み込むかによって処理時間は変わります。過去に生成された実行計画が再利用されるか、新しい実行計画が選ばれるかによっても、性能は大きく変化します。

性能問題をデータベースの設定だけで解決できるケースは、実際にはそれほど多くありません。

SQLや業務ロジックそのものに原因があれば、データベース側のパラメータを変更しても根本的な改善にはなりません。

改善策は、インデックスの追加や変更、統計情報の更新、必要に応じたSQLヒントの付与といったデータベース側の対応に限りません。SQLの書き換え、処理の分割、検索条件の見直し、データの持ち方の変更が必要になることもあります。

接続数やトランザクション管理に問題があれば、AP基盤チームへコネクションプールや共通処理の修正を依頼します。

CPUやストレージI/Oが不足していれば、システム基盤チームとリソース増強や構成変更を検討します。業務ルールを実装した共通部品が非効率であれば、アプリケーションチームの改修が欠かせません。

実際にあった例では、検索画面の入力にアンダースコアが含まれたことで、想定を大きく超えるデータが検索され、システムが高負荷になったことがありました。

当時使用していたOracleのリリースでは、全角の「＿」や「％」がLIKE検索のワイルドカードとして扱われることがあり、NULL以外のほぼ全件が検索対象となっていました。

サポートへの照会とバージョンごとの再現試験を重ねると、旧リリース向けにエスケープ処理を入れた場合、新しいリリースへアップグレードした後には逆にエラーになることも分かりました。

最終的には、バージョンが変わっても動作が変わらない書き方をSQLコーディング規約へ反映しました。

本来はアプリケーション側のSQL実装に関わる問題でも、データベースが最初に疑われ、DBAが製品仕様とSQLの両面から切り分け、再発防止まで取りまとめることがあります。

権限とロールはアプリケーションと切り離せない

権限とロールの設計も、アプリケーションとの調整が避けられない領域です。

既存システムを引き継いだとき、アプリケーションのスキーマにDBA相当のロールがそのまま付与されていたことがありました。

セキュリティ要件の観点で認められる状態ではなく、必要な権限だけを個別に付与する形へ絞り込むことになりました。

権限を外した結果、これまで動いていた処理が動かなくなりました。どの処理がどのオブジェクトへどう触れているのかを整理した資料はアプリケーションチームにも残っておらず、発生したエラーと処理を突き合わせながら、必要な権限を一つずつ特定していく作業になりました。

権限を細かく制限するほど、影響確認と試験にも相応の工数がかかります。

マネージドサービスでは、この制約がさらに強くなります。

RDS for OracleではSYSDBA権限そのものが提供されず、管理操作は用意されたパッケージ経由に限定されます。オンプレミスで当たり前に実行していた手順が使えない前提で、権限の設計と運用手順を組み立て直す必要があります。

監査ログは出せばよいわけではない

監査も、要件を満たす設定を入れれば終わりという作業ではありません。

とりあえず監査ログを出力する設定にしたところ、膨大な量のログが出力され、何を監査対象とするのかを決める作業の方が大変でした。

すべてのSQLを記録すれば、性能とストレージへ影響します。絞りすぎれば、問題が起きたときに誰が何をしたのか説明できません。

特定のテーブルへのアクセスだけを対象にするのか、更新だけでなく参照まで含めるのか、保持期間をどれだけにするのかを、業務要件と法令要件の両面から決めます。

個人情報や決済に関わるデータでは、誰がいつどのデータへ触れたのかを後から説明できることが求められます。

共通のアプリケーションユーザーで接続していれば、データベース側の記録だけでは実際の利用者までたどれません。

アプリケーションのログと突き合わせて追跡できる設計にするのか、クライアント識別情報をデータベースへ渡してもらうのかを、アプリケーションチームと事前に決めておく必要があります。

監視も、稼働状況を眺めるためのものではありません。

表領域の使用率と増加傾向、権限の変更、想定外の接続元、監査ログが想定どおり出力・保管されているかなど、業務が止まる前に気づくべき事象と、後から説明を求められる事象の両方を対象にします。

冗長化しても業務を継続できるとは限らない

データベースの可用性を高めるには、障害が発生してからデータを復旧するだけでなく、待機系へ切り替えて業務を継続できる構成も設計します。

オンプレミスではRACやData Guard、クラウドではRDSのMulti-AZなど、障害の範囲、許容停止時間、許容できるデータ損失、費用に応じて方式を選びます。

冗長化構成を用意しても、データベースが待機系へ切り替わるだけで業務を継続できるとは限りません。

アプリケーションの再接続、接続プールの回復、DNSキャッシュ、切り替え中に失敗した処理の扱いまで含め、システム全体の復旧動作を設計します。

私が担当したシステムでは、正常時の通信遅延を抑えるため、WebサーバーとAPサーバーをRDSのプライマリと同じAZ側へ寄せて稼働させていました。正常時の性能を優先しつつ、障害時にはRDSが別のAZへ切り替わることを前提とした構成です。

RDSが別のAZへフェイルオーバーすると、Web／APサーバーとデータベースの通信がAZをまたぐ場合があります。通信経路が変わればレイテンシーも変化し、データベースアクセスの多い業務では性能へ影響する可能性があります。

確認すべきなのは、フェイルオーバーが成功したかどうかだけではありません。RDSが反対側のAZへ切り替わった状態でも、オンライン処理の応答時間やバッチ処理時間が要件内に収まるのかを試験します。

通常時と同じ性能を維持できない場合には、あらかじめ定めた縮退運転の条件で業務を継続できることまで確認します。Web／APサーバーを別AZ側へ切り替える構成であれば、アプリケーションとデータベースを同じAZ側で動かせるかも検証対象です。

RDS Multi-AZで自動化されるのは、データベース側の待機系への切り替えです。その後にアプリケーションが正常に再接続し、性能要件や縮退要件を満たして業務を再開できるかは、利用者側で設計し、試験しなければなりません。

バックアップがあっても復旧できるとは限らない

データベースに障害が発生すれば、システム全体が停止したり、複数の業務が同時に利用できなくなったりする可能性があります。データの破損や消失が起きれば、サーバーを再起動するだけでは復旧できません。

重要なのは、どの時点まで戻すのかという要件を、事前にアプリケーションチームと合意しておくことです。

前日の夜間バックアップまで戻してよいのか、障害の直前まで戻す必要があるのか。直前まで戻す要件があるなら、アーカイブログモードで運用し、アーカイブログの出力先、退避方法、保持期間まで設計に含めます。

判断が難しいのは、夜間バッチの途中で障害が発生した場合です。

どのジョブまで完了していたのか、どこまで戻せば再実行できるのか、中途半端な状態で残ったデータをどう扱うのかは、データベース側だけでは決められません。

復旧の目標時間と、戻した後に業務をどの順番で再開するのかを含めて、アプリケーションチームと一緒に決めます。バックアップを取得しているだけでは不十分です。

データファイルが壊れた場合、誤って大量のデータを削除した場合、バッチの途中で停止した場合では、手順も所要時間も変わります。

ユースケースごとに、実際にリストアとリカバリを実施します。本当に戻るのか、目標時間内に終わるのか、戻した後にアプリケーションが正しく動くのかを、アプリケーションチームと合同で確認しておきます。

RDSの復元は元のインスタンスを巻き戻す処理ではない

マネージドサービスを利用する場合も、復旧方法を事前に決めておく必要があります。

RDSのポイントインタイムリカバリでは、バックアップ保持期間内の任意の時点へ復元できます。直近については制約があります。トランザクションログは通常5分間隔でAmazon S3へアップロードされるため、指定できる最新の復元時点は現在時刻より数分前になることがあります。実際に復元可能な最新時点は、LatestRestorableTimeで確認します。

注意が必要なのは、指定した時点の状態が新しいDBインスタンスとして作成され、元のインスタンスが巻き戻るわけではないことです。

復旧時間には、新しいインスタンスの作成だけでなく、DB接続先情報の変更やDNSの切り替え、接続確認に要する時間も含まれます。

アプリケーションがRDSのエンドポイントを直接参照するのか、DNS名で接続先を抽象化するのかを含め、切り替え方式を事前に設計しておかなければ、復旧目標時間には収まりません。

旧インスタンスをいつ削除するのか、切り戻せる状態をどこまで残すのかも決めておきます。また、復元できる単位にも制約があります。

この復元方式では、DBインスタンス全体が新しいインスタンスとして作成されます。既存のDBインスタンスを過去の状態へ戻したり、特定のテーブルだけを1時間前の状態へ戻したりする機能ではありません。

誤更新への対応では、復元した別インスタンスから対象データを抽出して取り込むなど、別の方式を組み合わせる必要があります。

データベース製品によって、アーキテクチャと設計上の判断は変わる

以上、Oracleを主な例として説明しました。

近年は、一つのシステムでも、業務データにはリレーショナルデータベース、ログや非定型データには別のデータストアを利用するなど、用途に応じて複数の製品を組み合わせる構成も増えています。

OSはAmazon LinuxからRed Hat Enterprise Linuxへ変わっても、プロセス、メモリ、ファイルシステム、権限管理など、基本的な仕組みや設計の考え方には共通する部分があります。データベースは、製品の種類が変わると設計思想そのものが大きく変わることがあります。

同じリレーショナルデータベースでも、Oracle、PostgreSQL、MySQLでは、運用機能、可用性構成、拡張方式、チューニングの考え方に違いがあります。OracleとMongoDBのようなドキュメント指向データベースであれば、データの持ち方、整合性の考え方、検索方法、拡張方式まで異なります。

製品が変わっても、DBAに求められる基本的な役割や考え方には共通する部分があります。変わるのは、その役割を実現するためのアーキテクチャ、機能、制約、管理方法です。

操作方法だけでなく、データモデルやトランザクション、可用性、性能設計の前提から学び直さなければならないこともあり、ここにDBAという職種の難しさがあります。

まとめ

DBAは、データベース製品を構築するだけの担当者ではありません。

アプリケーションの処理を理解して性能問題の原因を横断的に分析し、権限や監査の要件を業務と擦り合わせ、障害が起きてもデータを失わずに業務を再開できる状態を維持し続ける役割です。

構築が終わっても仕事は終わらず、性能問題や障害が起きれば、DBAが原因分析と関係チームの調整の中心に立ちます。

データ量が増えても必要な性能を保ち、稼働後もデータの安全性と業務継続を支える。その責任を担いながら、採用する製品や要件の変化に応じて知識を更新し、新しい設計思想へ適応し続けるところに、DBAの専門性があります。

関連記事

SEは一つの職種ではありません。アプリケーション、AP基盤、システム基盤・クラウド、ネットワーク、プロジェクト管理など、ほかの職種との違いは次の記事で整理しています。

システムエンジニアの種類と仕事内容｜SIerのSEはどこまで担当するのか

各職種についても、今後個別の記事で詳しく解説していきます。

私は大手SIerで20年以上、システム基盤を中心に、OS、ネットワーク、データベースの設計・構築から、大規模プロジェクトの統括まで経験してきました。

このページでは、私自身のキャリアを踏まえながら、システム開発に関わる代表的な職種と、SIerのSEが実際にどこまで担当するのかを整理します。

システムエンジニアになりたいと考えている人の中には、SEの仕事を「設計書を書き、プログラムを作る仕事」と捉えている人もいると思います。

実際のシステム開発では、プログラムを作るだけではシステムは完成しません。顧客の業務を整理して必要な機能を決め、サーバーやネットワークを構築し、データを安全に管理し、障害が発生しても業務を継続できる仕組みまで設計する必要があります。

これらを一人のエンジニアがすべて担当するわけではありません。プロジェクトマネージャー、アプリケーションエンジニア、AP基盤エンジニア、システム基盤エンジニア、ネットワークエンジニア、データベースエンジニアなど、異なる専門性を持つ人たちが役割を分担します。

実際のSIerでは、職種ごとの境界が明確に分かれているとは限りません。一つの技術領域からキャリアを始め、周辺領域へ担当範囲を広げ、最終的に複数の技術チームやプロジェクト全体を統括するSEもいます。

企業やプロジェクトによって、職種名、チーム名、担当範囲の分け方は異なります。この記事では便宜上「職種」と表現しますが、同じシステムエンジニアという肩書でも、実際の仕事内容は大きく異なります。

システム開発全体の流れについては、以下の記事で詳しく説明しています。

• 【前編】システム開発の流れを現場目線で理解する｜システム開発はプログラミングだけでは終わらない
• 【後編】システム開発の流れを現場目線で理解する｜要件定義・テスト・移行・運用保守のリアル

システム開発は複数の専門領域で成り立っている

システム開発では、利用者が操作する画面や帳票だけでなく、その裏側にあるサーバー、ネットワーク、データベース、認証、監視、バックアップなども設計します。

インターネット上で商品を購入できるショッピングサイトを例に考えてみましょう。

アプリケーションエンジニアは、商品検索、注文、決済、在庫確認といった業務機能を設計します。AP基盤エンジニアは、認証、ログ出力、例外処理、データベース接続など、複数の機能が共通して利用する仕組みを整備します。

システム基盤エンジニアは、アプリケーションを安定して動かすサーバーやクラウド環境を設計します。ネットワークエンジニアは、利用者や外部サービスと安全に通信できる構成を作ります。データベースエンジニアは、顧客情報や注文情報を正確かつ高速に読み書きできるようにします。

アプリケーション側が大量のデータを短時間で処理する前提を置いているのに、基盤側が小規模なサーバーしか用意していなければ、性能問題が発生します。データベース側が同時接続数を制限しているのに、アプリケーション側が大量の接続を生成すれば、処理の遅延や障害につながります。

システム開発では、各担当者が自分の専門領域を設計するだけでなく、他の領域と前提条件を合わせる必要があります。職種を理解するうえでも、個別の仕事内容だけではなく、他の職種とどのように接続しているかを見ることが重要です。

プロジェクトマネージャー

プロジェクトマネージャーは、プロジェクト全体を成立させる責任を持つ役割です。

一般的には、品質、コスト、納期を管理する仕事として説明されます。現場で求められるのは、進捗表を更新したり、会議を開催したりすることだけではありません。

システム開発では、日々さまざまな問題が発生します。要件が決まらない、製品仕様が想定と異なる、他システムとの接続条件が合わない、テストで不具合が多発する、必要な技術者を確保できないといった問題です。

プロジェクトマネージャーは、発生した問題を把握し、誰が、何を、いつまでに判断するのかを明確にします。担当者間で解決できない問題については、顧客、社内責任者、製品ベンダーなどを巻き込み、必要な意思決定を引き出します。

大規模なプロジェクトでは、プロジェクトマネージャー一人ですべてを管理できません。アプリケーション、システム基盤、移行、運用などのチームごとにリーダーを置き、各チームが抱えている課題やリスクを集約します。大手SIerの大規模案件では、一例として、プロジェクト全体を統括するPMを課長級、各チームを率いるリーダーを課長代理級が担い、その下に主任などの担当者を配置する体制もよく見られます。

プロジェクトマネージャーに必要なのは、すべての技術を自分で実装する能力ではありません。各分野の担当者が説明する内容を理解し、プロジェクト全体への影響を判断したうえで、何を優先するかを決める力が求められます。

技術的には正しい案であっても、予算、納期、要員、契約条件を踏まえると採用できない場合があります。反対に、費用を抑えるために必要な冗長化やテストを削れば、稼働後の障害リスクが高まります。プロジェクトマネージャーは、個別の技術判断を品質、コスト、納期の制約の中で成立させる役割でもあります。

大きな障害が発生した際には、原因を調査して復旧するだけでは終わりません。顧客に対して影響範囲、原因、復旧状況、再発防止策を説明し、必要に応じて組織を代表して謝罪することも、プロジェクトを統括する立場の仕事です。

こうした判断と責任を支えるのが、現場で積み上げた技術経験です。例えば、PMには次のような事項を評価する力が求められます。

• 担当者が提示した工数の妥当性
• 提案されたシステム構成の実現可能性
• 障害が発生した場合の影響範囲

こうした判断をPMが自分の言葉で行うには、少なくとも一つの技術領域で設計や障害対応を経験していることが大きな支えになります。SIerでは、担当者やチームリーダーとして専門性を積み上げた後、複数領域を統括するPMへ役割を広げていくキャリアが一般的です。

実際の更改プロジェクトで、各担当者がどのように関わるのかについては、以下の記事でも説明しています。

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

アプリケーションエンジニア

アプリケーションエンジニアは、利用者の業務をシステムの機能として実現する役割を担います。

画面や帳票を作るだけではなく、顧客がどのような業務を行い、どのようなルールで処理しているのかを理解する必要があります。

銀行の融資審査システムであれば、申込受付、本人確認、信用情報照会、審査、承認、契約といった業務の流れを理解しなければ設計できません。会計システムであれば、勘定科目、仕訳、決算処理などの知識が必要になります。公共分野であれば、法律や制度の理解が設計に直結します。

主な仕事には、次のようなものがあります。

• 業務要件の整理
• 画面、帳票、バッチ、APIの設計
• データベースへ登録する情報の整理
• プログラム開発
• 単体テスト、結合テスト
• 障害原因の調査
• 利用部門や他システム担当者との仕様調整

プロジェクトによっては、設計を担当する人とプログラミングを担当する人が分かれています。規模の小さい開発では、一人が要件確認からプログラミング、テストまで担当することもあります。

アプリケーションエンジニアにとってプログラミングは重要な技術です。それだけで仕事が完結するわけではありません。顧客の業務を理解し、曖昧な要望をシステムで実現できる仕様へ落とし込む力が必要です。

設計した機能がどの程度のデータを処理し、どのようなタイミングでデータベースや外部システムへ接続するのかも、システム基盤やデータベースの担当者へ伝えなければなりません。

アプリケーションの仕様は、アプリケーションチーム内だけで完結するものではありません。サーバー構成、ネットワーク帯域、データベース接続数、運用時間など、他の領域の設計条件にもなります。

AP基盤エンジニア

AP基盤とは、複数のアプリケーションを共通の方式で開発し、安定して動かすためのアプリケーション基盤を指します。AP基盤エンジニアは、個別の業務機能ではなく、複数の開発チームが共通して利用する仕組みや開発方式を設計します。

主な担当領域は次のとおりです。

• 認証、認可、ログ、例外処理などの共通機能
• データベース接続やトランザクション管理の共通方式
• Javaや.NETなどのアプリケーション実行方式
• Springなどのフレームワークの設計と利用ルール
• 共通ライブラリや部品の開発
• プログラムのビルド、テスト、配備を自動化する仕組み
• コーディング規約や開発標準の整備
• アプリケーション性能の分析
• 開発チームへの技術支援

例えば、100の画面を複数の開発チームで分担して作るシステムで、ログイン状態の確認や操作権限の判定を各開発者が個別に実装すれば、画面ごとに動作や品質が異なり、セキュリティ上の不備も生じやすくなります。

こうした処理をフレームワークや共通ライブラリとして整備すれば、各開発チームは同じ方式で実装できます。業務機能を担当する開発者は、認証やログ出力を一から作る必要がなくなり、業務ロジックの開発へ集中できます。

この役割は、アプリケーションとシステム基盤の接点でもあります。プロセス構成、データベース接続数、タイムアウト、メモリ利用、ログ出力、配備方法などを決めるには、プログラミングだけでなく、ミドルウェア、データベース、ネットワーク、性能、セキュリティまで理解する必要があります。

共通基盤の設計に問題があれば、その影響は多数のアプリケーションへ広がります。利用者からは見えにくい役割ですが、開発生産性、品質、性能、セキュリティを横断して支える重要な専門領域です。

経験を積むと、共通部品の設計にとどまらず、システム全体の技術方針や構成を決めるアプリケーションアーキテクトやITアーキテクトへ役割を広げることもできます。技術的な裁量と責任範囲が広い職種として、市場での評価も高い領域です。

システム基盤・クラウドエンジニア

システム基盤エンジニアは、アプリケーションを安定して動かすための土台を設計、構築します。

以前はサーバーエンジニアやインフラエンジニアと呼ばれることが多く、物理サーバー、OS、ストレージ、バックアップ装置などを担当していました。現在はAWS、Microsoft Azure、Google Cloudなどのクラウドサービスを利用する案件が増え、担当範囲も広がっています。

主な検討項目は次のとおりです。

• サーバーやクラウドサービスの構成
• CPU、メモリ、ディスク容量
• OSやミドルウェア
• 冗長化と障害時の切り替え
• バックアップとリストア
• 監視とログ管理
• セキュリティ
• 性能と拡張性
• 運用手順
• 災害対策

クラウドを利用すれば、サーバー機器を自社で購入する必要はなくなります。可用性、セキュリティ、性能、運用、コストまでクラウド事業者が自動的に設計してくれるわけではありません。

どのサービスをどのように組み合わせるのか、障害が発生した際にどの範囲まで自動復旧させるのか、データをどの地域へ保存するのかといった判断は、利用する企業と開発プロジェクト側に残ります。

システム基盤の仕事は、平常時にシステムが動くことだけを考える仕事ではありません。サーバーやネットワークの一部が故障しても業務を継続できる構成、障害が発生しても原因を調査できる監視とログ、誤操作や災害が発生してもデータを復旧できる仕組みまで設計します。

アプリケーションが必要とする処理量、データベースへの接続数、稼働時間、停止可能時間などを把握しなければ、適切な基盤構成は決められません。システム基盤は、アプリケーションや運用の条件を受け取って初めて設計できます。

ネットワークエンジニア

ネットワークエンジニアは、利用者、サーバー、クラウド、外部システムの間で、安全かつ安定して通信できる仕組みを設計します。

企業のシステムでは、単にインターネットへ接続できればよいわけではありません。

社内端末から業務システムへ接続する通信、データセンターとクラウドを結ぶ通信、外部企業とのシステム連携、運用担当者が管理画面へ接続する通信など、それぞれに異なる条件があります。

主な担当領域には、次のようなものがあります。

• LAN、WAN
• ルーティング
• DNS
• ファイアウォール
• ロードバランサ
• プロキシ
• VPN
• 閉域網
• クラウド接続
• 通信経路の冗長化
• ネットワーク監視

ネットワークの問題は、原因の切り分けが難しいことがあります。

画面が表示されないという事象だけでは、アプリケーションに不具合があるのか、サーバーが停止しているのか、DNSで名前解決できないのか、ファイアウォールで通信が遮断されているのか分かりません。

ネットワークエンジニアには、通信経路やパケットの状態を確認し、どこで通信が途切れているのかを特定する力が求められます。

クラウド環境でもネットワークの重要性は変わりません。画面上の操作でネットワークを構築できるようになった反面、ルーティングや名前解決の設計を誤れば、複数のシステムへ影響が広がります。

アプリケーションが接続する相手、通信量、利用するポート、暗号化方式、接続元の制限などを他の担当者と確認し、システム全体の通信条件を整合させる必要があります。

データベースエンジニア

データベースエンジニアは、システムが扱うデータを正確、安全かつ効率的に管理する役割を担います。

多くの業務システムでは、顧客、契約、商品、取引、会計などの情報をデータベースへ保存します。

データベースに障害が発生すると、画面が表示できないだけではなく、取引そのものを継続できなくなる場合があります。データが破損したり失われたりすれば、企業活動へ重大な影響を及ぼします。

主な仕事は次のとおりです。

構築と物理設計

• データベース製品と構成の選定

• テーブル、インデックス、表領域などの設計

• 初期設定と各種パラメータの設計

性能と容量管理

• SQLと実行計画の分析

• インデックスや統計情報の管理

• 性能チューニング

• データ容量と増加量の見積もり

セキュリティと運用

• ユーザー、権限、ロールの設計

• 監査要件への対応

• 監視とログ管理

可用性とデータ保護

• 冗長化と障害時の切り替え

• バックアップとリカバリ

移行と製品管理

• データ移行

• バージョンアップ

• ライセンスと保守契約の管理

Oracle Database、PostgreSQL、Microsoft SQL Serverなど、製品ごとに構造や機能が異なるため、特定のデータベース製品に深い知識を持つエンジニアも多くいます。

データベースエンジニアの仕事は、データベースをインストールして終わりではありません。

どのSQLに時間がかかっているのか、索引が適切に利用されているか、統計情報が実行計画へどのように影響しているか、障害時にどの時点までデータを復旧できるかといった点を継続的に確認します。

アプリケーションの性能問題に見えても、実際にはSQLやデータベース設計に原因がある場合があります。データベース側だけで改善できるとは限らず、アプリケーションの処理方式そのものを見直すこともあります。

アプリケーションエンジニアやAP基盤エンジニアと、SQL、接続方式、トランザクション、処理量などの前提を共有することが欠かせません。

ここではデータベースエンジニアの担当領域を概要として紹介しました。構成設計、性能チューニング、権限・監査、可用性、バックアップと復旧など、具体的な仕事内容と実務上の判断については、次の記事で詳しく説明しています。

【システム開発入門】データベースエンジニア（DBA）の仕事｜止めない、失わない、遅くさせない

データベースエンジニア（DBA）は何をする職種なのか。Oracle DBAの実務経験をもとに、物理設計・構築、性能と容量管理、権限・監査、監視、バックアップ、障害復旧、データ移行まで、構築後も続く仕事と責任をわかりやすく解説します。

sys-univ.com

2026.08.03

運用、セキュリティ、アーキテクトという役割

実際のプロジェクトには、ここまで説明した職種以外にもさまざまな役割があります。

運用エンジニアは、稼働後の監視、障害対応、定期作業、問い合わせ対応などを担当します。運用担当者が稼働後に考えればよい仕事ではありません。監視方法、バックアップ、障害時の連絡、復旧手順、定期作業などは、システム開発の段階から設計する必要があります。

セキュリティエンジニアは、認証、権限、脆弱性、ログ監視、インシデント対応などを専門的に検討します。セキュリティも一つの製品を導入して完了するものではなく、アプリケーション、システム基盤、ネットワーク、運用の各領域にまたがります。

システムアーキテクトは、個別製品の設定だけでなく、システム全体の構造や技術方針を設計します。複数のチームにまたがる技術的な整合性を取り、局所的には正しい設計が、システム全体の問題にならないようにします。

これらが独立した職種として置かれるか、他の担当者が兼務するかは、組織やプロジェクトの規模によって異なります。

小規模なシステムでは、一人がアプリケーション、データベース、クラウド、運用まで担当する場合があります。大規模なシステムでは、同じデータベース領域でも、性能、移行、運用などに担当が分かれることがあります。

職種名だけで仕事内容を判断するのではなく、実際にどの範囲まで担当するのかを確認することが重要です。

ここまでは、システム開発に関わる役割を職種ごとに分けて説明しました。実際のSIerのキャリアでは、これらの役割が一人の中で連続することがあります。ここからは、私自身の経験を例に、技術者がどのように担当範囲を広げていくのかを説明します。

SIerのSEは一つの職種に収まらない

私自身も、最初からプロジェクト全体を管理していたわけではありません。キャリアの出発点は、SolarisやLinuxを扱うインフラエンジニアでした。

OSを設計、構築するだけでなく、Ciscoの資格を取得し、比較的小規模なネットワーク設計も担当しました。当時は現在のクラウド環境とは異なり、物理的なサーバー機器を顧客のデータセンターへ納品し、ラックへ搭載するところまでSIer側で行う案件も数多くありました。

現在のクラウドでは、物理サーバーや電源設備はサービスの裏側に隠れ、利用者が直接意識する機会は減りました。当時のインフラエンジニアは、OSやミドルウェアだけでなく、機器を実際に稼働させるための物理設備まで、設計と構築の対象として扱っていました。

私も、サーバーの台数や消費電力からラックの電源容量を計算し、停電時にはUPSとUPS管理ソフト（PowerChute）を連携させて、OSやミドルウェアを安全に停止する方式を設計しました。

ハードウェアを納品する際には、設計書上の構成を考えるだけでは終わりません。サーバーをラックへ実際に搭載し、電源やネットワークケーブルを接続して、機器が起動するところまで確認します。

LANケーブルを配線するため、吸盤式のフロアリフターを使ってフリーアクセスフロアの床板を開け、床下へ潜ってケーブルを引き回したこともあります。現場では、この吸盤式の道具を「サッカー」と呼んでいました。作業を終えて床下から出ると、スーツが埃まみれになっていたものです。

現在では、こうした作業はデータセンター、施工、ファシリティなどの専門担当へ分業されることが多く、クラウド環境からキャリアを始めたエンジニアには馴染みのない光景かもしれません。

こうした経験を通じて、システムは画面上の設定やソフトウェアだけで動いているのではなく、電源、空調、ラック、ケーブル、機器といった物理的な土台の上で成立していることを理解しました。

その後、Oracle Databaseを大規模に利用するシステムを担当するようになり、データベースの設計、構築、性能チューニングまで行うようになりました。当時のOracle9i Platinum資格も取得し、DBAとして経験を積みました。

ここまでで約10年間です。

OS、ハードウェア、ネットワーク、電源設備、データベースを、それぞれ独立した製品知識として覚えたわけではありません。システムに障害が発生した際、どの層に原因があるのかを切り分け、各領域の設計がどのように影響し合うのかを、実際の構築や障害対応を通じて理解していきました。

例えば、処理が遅いという事象が発生しても、原因がサーバーのCPU不足とは限りません。ストレージのI/O、ネットワーク遅延、Oracleの実行計画、SQL、アプリケーションの処理方式など、複数の可能性があります。

一つの製品だけを見ていては、原因を特定できない障害もあります。異なる技術領域を経験することで、システム全体を一つの構造として見られるようになりました。

その後も肩書としてはシステム基盤を担当するエンジニアでしたが、仕事の中心は個別製品の設計や構築から、システム基盤全体の統括へ変わっていきました。

各技術チームの作業範囲を整理し、必要な要員と工数を見積もり、RFPや提案書を作成します。案件を受注してよいかを判断する社内会議では、技術的な実現性だけでなく、採算、要員確保、リスク、契約条件についても説明します。

入札案件では、幹部に対して案件の概要、顧客の要求、提案内容、受注方針、想定されるリスクを説明し、組織として入札へ参加するかどうかを判断できる材料を揃えます。

この段階になると、自分でOSやデータベースを構築する時間は減っていきますが、技術経験が不要になるわけではありません。

各担当者が提示した工数は妥当なのか、提案している構成に技術的な無理はないか、障害が発生した場合にどこまで影響が広がるのか、顧客の要求に対して過剰な構成や不足した構成になっていないかを判断するには、現場で積み上げた知識が必要です。

見積もりについても、単価と工数を集計するだけではありません。設計、構築、テスト、移行、運用準備に何人必要なのか、各チームの作業にどのような依存関係があるのか、どの部分に不確実性が残っているのかを理解しなければ、現実的な計画にはなりません。

システム開発費用がなぜ数億円規模になるのか、見積もりにどのような作業や費用が含まれるのかについては、以下の記事で詳しく解説しています。

【システム開発費用の内訳】なぜ数億円かかるのか｜クラウド更改の見積もり構造

SIerの管理職やプロジェクトマネージャーは、単に人や進捗を管理するだけの仕事ではありません。少なくとも大規模なシステム開発では、技術、費用、要員、契約、顧客との関係を結び付け、プロジェクトとして成立させる役割を担います。

すべてのSEが同じ経歴をたどるわけではありません。アプリケーションや業務領域を起点に、プロジェクト全体を統括する人もいます。ネットワーク、データベース、セキュリティなど、一つの領域を深く追求し続けるスペシャリストもいます。

一つの専門性を深く経験し、隣接する領域へ担当範囲を広げた結果として、複数の専門職をまとめる立場へ進むというキャリアは、SIerでは特殊なものではありません。

職種名だけを見れば、インフラエンジニア、ネットワークエンジニア、DBA、プロジェクトマネージャー、管理職と分かれます。実際のキャリアでは、それぞれが切り離されているのではなく、過去の技術経験を土台として連続しています。

SEになるためにプログラミングは必須なのか

SEを目指す人から、「プログラミングができなければSEになれないのか」と聞かれることがあります。

答えは、目指す領域によって異なります。

アプリケーションエンジニアやAP基盤エンジニアを目指すのであれば、プログラミングの知識は重要です。自分で大量のプログラムを書かない立場になったとしても、設計の妥当性を判断し、障害原因を調査するためにはコードを読める必要があります。

システム基盤、ネットワーク、データベースを担当する場合も、プログラムと無関係ではありません。

運用作業を自動化するスクリプト、データベースを操作するSQL、クラウド環境を構築するコードなどを扱います。現在は、サーバーやネットワークの構成をコードとして定義し、自動的に構築するIaC（Infrastructure as Code）も利用されています。システム基盤やネットワークを担当するSEにも、コードを読み書きする力が求められる場面は増えています。

すべてのSEが、日常的に業務アプリケーションのプログラムを書いているわけではありません。

顧客との要件調整、システム構成の設計、性能分析、障害対応、プロジェクト管理など、プログラミング以外の仕事も多くあります。

「SEになるためにプログラミングは不要」と言い切るのも、「SEは全員プログラマーである」と捉えるのも正確ではありません。自分が目指す領域で、どの程度のプログラミング知識が必要なのかを考えることが重要です。

SEの専門性は一つの領域から築く

システム開発には多くの専門領域があるため、最初からすべてを理解することはできません。

SEを目指すのであれば、まず一つの領域で基礎を身につけることが現実的です。

アプリケーションであれば、一つの業務機能について、設計、開発、テスト、障害対応まで経験します。システム基盤であれば、サーバーやクラウドサービスを構築するだけでなく、監視、バックアップ、性能確認、障害対応まで担当します。

一連の工程を経験すると、自分が設計した内容が、後続工程や他の担当者、稼働後の運用にどのような影響を与えるのかが見えるようになります。

専門性を身につけた後で、隣接する領域へ知識を広げます。

データベースエンジニアがアプリケーションの仕組みを理解すれば、SQL性能の問題をより正確に分析できます。システム基盤エンジニアがネットワークやデータベースを理解すれば、障害時の切り分けが速くなります。

プロジェクトマネージャーも、いずれかの技術領域や業務領域で現場経験を持っている方が、担当者の説明やリスクの大きさを理解しやすくなります。

周辺領域の知識を広げることと、自分の専門性を失うことは同じではありません。何でも少しずつ知っているだけでは、重大な判断を任されにくくなります。

まずは一つの領域で、設計、構築、テスト、障害対応まで責任を持てる水準を目指し、その専門性を軸に周辺領域との境界を理解できる範囲を広げていくことが、SEとして成長する一つの形です。

市場価値は技術を課題解決につなげる力で決まる

特定のクラウドサービスやデータベース製品に詳しいことは、エンジニアとして大きな強みになります。

製品の操作方法を知っているだけでは、システム開発の課題を解決できないことがあります。

顧客が達成したいことは何か、どのような制約があるのか、どの選択肢を採用すれば品質、コスト、納期のバランスを取れるのかを考えなければなりません。

例えば、性能問題に対してサーバーの台数を増やすことは、一つの解決策です。原因がSQLやアプリケーションの処理方式にあるなら、サーバーを増やしてもコストが上がるだけで、問題の根本は残ります。

ネットワーク障害に見える事象が、実際にはアプリケーションの接続管理やDNSの利用方式に起因していることもあります。一つの製品や担当領域だけで問題を捉えると、対策を誤る可能性があります。

市場価値の高いエンジニアは、知っている製品や技術をそのまま当てはめるのではなく、複数の選択肢を比較し、対象となるシステムに適した方法を選びます。

自分の頭の中だけに解決策を持っていても、プロジェクトは動きません。設計書や計画書として整理し、関係者へ説明し、複数のチームが同じ前提で実行できる状態を作る必要があります。

技術的な判断を、顧客、経営層、営業、契約担当者へ説明する場面では、専門用語を並べるだけでは伝わりません。技術上の問題が、費用、納期、業務継続、契約上の責任へどのような影響を与えるのかを説明する必要があります。

専門技術、業務理解、問題解決、説明、調整の力が組み合わさることで、担当できる範囲と責任が広がります。

まとめ

システム開発は、プログラムを作る人だけでは進められません。プロジェクトマネージャー、アプリケーション、AP基盤、システム基盤、ネットワーク、データベースなど、異なる専門性を持つエンジニアが前提条件を共有し、一つのシステムを作ります。

職種名は専門領域を理解するためには役立ちますが、実際のSIerのSEは一つの職種だけに収まるとは限りません。技術者として積み上げた経験を土台に、周辺領域、費用、要員、契約まで担当範囲を広げ、プロジェクト全体を統括する人もいます。

システム開発の目的は、最新技術を導入することでも、プログラムを書くことでもありません。顧客の業務上の課題を理解し、技術を使って実行可能な仕組みに変えられる人材が、現場で求められるシステムエンジニアです。

このnoteで発信していること

このnoteでは、大規模SIerの現場で経験してきたシステム基盤設計、クラウド移行、運用設計、Oracle Database、プロジェクト管理などを、若手SEやシステム開発に関心を持つ人にも理解できる形で整理しています。

成功事例だけを紹介するのではなく、設計時に見落としやすい点、プロジェクトで実際に発生したトラブル、その原因と再発防止まで含めて記録しています。

システム開発の全体像を知りたい方は、まず以下の記事からお読みください。

• 【前編】システム開発の流れを現場目線で理解する｜システム開発はプログラミングだけでは終わらない
• 【後編】システム開発の流れを現場目線で理解する｜要件定義・テスト・移行・運用保守のリアル
• 【システム開発とは何か】システム更改で学ぶ、プログラミングだけではない仕事の全体像
• 【システム開発費用の内訳】なぜ数億円かかるのか｜クラウド更改の見積もり構造

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

クラウド移行（AWSへのクラウドリフト）で起きる手戻り・コスト超過・納期遅延は、構築中ではなくPoC不足から始まります。Auto Scaling、EFS/EBS、RDS、監視、バックアップ、ライセンスなど10の設計リスクを現場目線で整理します。

sys-univ.com

2026.07.20

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

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

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

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

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

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

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

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

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

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

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

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

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

構築当時の担当者が異動や退職ですでにおらず、仕様を誰にも確認できないブラックボックスと化した処理も珍しくありません。設計書と実機の設定が食い違っていることもあります。この場合、実機の設定やログを一つずつ読み解きながら、動いているシステムの仕様を復元していく作業が発生します。

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

調査が必要なのは、現在の構成や運用だけではありません。更改によってOSやミドルウェアの挙動がどう変わるのか、その影響まで調べ切れていないと、本番稼働後の障害につながります。データベースの更改後に実行計画が変わって性能障害へ発展した事例など、クラウドリフトや更改で実際に起きたトラブルは、次のマガジンにまとめています。

クラウド移行でハマる、AWS設計・運用の落とし穴｜ナギ ＠ 氷河期SEの知見録｜note

AWSへのクラウド移行やDR設計で見落としやすい、設計・起動・再作成・運用の落とし穴を整理するマガジンです。 EC2、AMI、cloud-init、EC2Launch、Auto Scaling、EBS、CloudWatch Logs、S3、AWS Backupなどを題材に、「サーバは起動したのに使えない」「設定したはReadMore...

note.com

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

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

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

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

注意したいのは、長年運用されたデータベースには、過去の障害対応で手作業により修正されたデータや、現在の入力チェックでは登録できない古い形式のデータが残っていることです。移行リハーサルをきれいなテストデータだけで行うと、こうしたデータは本番移行の当日に初めてエラーになります。移行の確認には、本番相当のデータを使うことが欠かせません。私はシステム開発の現場で昭和「90年」となっているデータに遭遇したことがあります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

運用はなくならない

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

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

今回のA銀行のように、EC2を中心として既存システムをリホストする場合、主な責任の境界は次のようになります。

AWSはデータセンター設備や物理サーバー、仮想化基盤などを管理します。利用者側には、データ、アクセス権限、ネットワーク設定、ゲストOS、アプリケーションなどの管理が残ります。

RDSのようなマネージドサービスを利用する場合は、OSやデータベース基盤の一部もAWSが管理するため、利用者との責任の境界が変わります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

更改プロジェクトで発生する費用の内訳は、次の記事で解説しています。設計、開発、テスト、移行、プロジェクト管理、クラウド利用料、稼働後の継続費用まで、数億円の見積もりを例に整理しました。

【システム開発費用の内訳】なぜ数億円かかるのか｜クラウド更改の見積もり構造

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

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

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

後編はこちらです。

はじめに

SEを目指す人の多くは、最初に「まずはプログラミングを覚えないと」と考えます。

もちろん、それは間違いではありません。

Java、Python、JavaScript、SQLなどを理解できれば、アプリケーションがどう動いているのかをイメージしやすくなります。

実際、プログラミングはシステム開発において重要なスキルです。

ただし、SEの仕事はプログラミングだけでは終わりません。

現場に入ると、コードを書く前後に考えることが、想像以上に多いことに気づきます。

たとえば、Web画面に「申請する」というボタンを1つ作るだけでも、裏側では多くのことを考えています。

• 誰が申請できるのか
• 誰が承認するのか
• 申請データはどこに保存するのか
• 同時に多くの人がアクセスしても耐えられるのか
• サーバが1台壊れても業務を続けられるのか
• データはバックアップされているのか
• 障害が起きたときに誰が検知するのか
• 本番リリース時に旧システムからデータをどう移すのか
• 個人情報や機密情報をどう守るのか
• 本番稼働後、誰がどう運用するのか

利用者から見えるのは、画面やボタンや検索結果です。

しかし、その裏側には、サーバ、データベース、ネットワーク、セキュリティ、監視、バックアップ、運用設計、移行設計など、非常に多くの要素があります。

つまり、システム開発とは、単にプログラムを書く仕事ではありません。

業務を動かす仕組みを、アプリケーションとシステム基盤の両方から作り上げる仕事です。

この記事では、これからSEを目指す人、初級SEとして働き始めた人、またはシステム開発の全体像がつかめずに悩んでいる人に向けて、システム開発の見方を整理します。

一般的なアプリ開発の説明だけではなく、インフラエンジニア／システム基盤エンジニアの視点も交えながら説明します。

なぜなら、実際のシステムは、機能が動くだけでは不十分だからです。

システム開発とは、一言でいえば、業務上の目的を実現するための仕組みを作ることです。

ここで重要なのは、ITやプログラミングそのものが目的ではないということです。
企業がシステムを導入する理由は、もっと現実的です。

• 売上を増やしたい
• 業務を効率化したい
• 人手不足を補いたい
• ミスを減らしたい
• 顧客対応を早くしたい
• 情報漏えいを防ぎたい
• 古いシステムを安全に入れ替えたい
• 障害に強い仕組みにしたい
• 将来の利用者増加に耐えられるようにしたい

つまり、システム開発の目的は、企業や組織の活動をよりよくすること
です。

たとえば、社内の物品購入申請を考えてみます。
紙の申請書に記入し、上司にハンコをもらい、決裁者が承認し、担当部門が処理する。こうした業務があったとします。

これをシステム化すると、次のようになります。

• 担当者がWeb画面から購入申請を登録する
• 承認者にメールやチャットで通知が届く
• 承認者がリンクから内容を確認する
• 承認ボタンを押す
• 承認履歴が記録される
• 後から監査や確認ができる

ここまでは、よくある業務アプリケーションの説明です。
しかし、インフラエンジニアの視点では、さらに裏側を見ます。

この申請システムを本番で使うなら、次のようなことも考えなければなりません。

• 何人が同時にアクセスするのか
• 画面は何秒以内に表示されるべきか
• サーバが1台停止したら業務は止まるのか
• データベース障害時にどこまで復旧するのか
• 承認履歴は何年間保存するのか
• 夜間バッチは何時までに終わる必要があるのか
• ログはどこに出し、何日保存するのか
• 監視アラートは誰に通知するのか
• バックアップはいつ取得し、復旧確認はするのか
• 本番移行時に、旧システムの未承認データをどう扱うのか

これらは、利用者からは見えにくい部分です。
しかし、この見えにくい部分が弱いと、システムは本番で使えません。

画面がきれいでも、アクセス集中で遅くなる。
機能が正しくても、サーバ障害で止まる。
承認処理ができても、障害時に復旧できない。
データが登録できても、バックアップから戻せない。
運用手順がなければ、夜間障害で誰も対応できない。

こうなると、システムとしては失敗です。

だからこそ、システム開発では、機能だけでなく、非機能も重要になります。

「機能が動く」と「本番で使える」は違う

初心者SEが最初に理解すべき大事なことがあります。
それは、機能が動くことと、本番で使えることは違うということです。

たとえば、申請画面があり、申請ボタンを押すとデータが登録される。
これは「機能が動く」状態です。

しかし、本番で使えるかどうかは、さらに別の観点で確認する必要があります。

• 1人が使うと動くが、1,000人が同時にアクセスしても動くのか
• 画面表示に10秒かかっても業務上許されるのか
• DBサーバが停止した場合、何分で復旧できるのか
• 障害発生時に、どのデータまで戻せるのか
• 月末に申請が集中しても処理できるのか
• 夜間バッチが朝の業務開始前に終わるのか
• セキュリティパッチ適用時にサービスを止める必要があるのか
• 本番移行に失敗した場合、切り戻せるのか

こうした観点を考えるのが、システム基盤／インフラ領域の重要な仕事です。

特に「1人が使うと動くが、1,000人が同時にアクセスしても同じように動くのか」という観点は、実際の現場では非常に重要です。

たとえば、アプリケーションそのものは正常に動いていても、リリース直後に多数の端末やブラウザが一斉にアプリ資材をダウンロードし、配布元のWebサーバやネットワーク、メモリ、接続数を圧迫して業務影響が出ることがあります。

最近であれば、SPAのJavaScriptファイル、Electron系アプリの更新資材、コンテナ環境でのイメージpull、CDNキャッシュ切れ後のオリジン集中などでも、似た構図は起こり得ます。

通常の業務画面をJMeterで試験して問題がなくても、リリース直後の資材配布、リトライ、同時接続、キャッシュ設計、サーバ設定まで見ていなければ、本番で初めて問題が出ることがあります。

つまり、性能問題は単に「画面が速いか遅いか」だけではありません。

機能として動くことと、本番運用で耐えられることは違います。

このあたりは、「性能・サイジング」「非機能テスト」の回で、実際に現場で起きたトラブルの考え方も交えながら詳しく解説します。

非機能とは何か

ここで、「非機能」という言葉について簡単に説明します。
非機能とは、画面やボタンのように利用者から直接見える機能ではありません。

しかし、システムを本番で安心して使うために必要な品質のことです。
初心者向けに言えば、非機能とは、そのシステムが本番でちゃんと使えるかを決める条件です。

たとえば、次のようなものが非機能に含まれます。

• 処理速度
• 止まりにくさ
• 障害時の復旧
• バックアップ
• 監視
• セキュリティ
• 運用しやすさ
• 将来の拡張性
• 移行のしやすさ

利用者は、普段こうしたことをあまり意識しません。
しかし、本番でトラブルが起きると一気に表面化します。

「画面が遅い」
「システムが止まった」
「障害に気づくのが遅れた」
「バックアップから戻せない」
「移行したらデータが合わない」
「運用担当が手順書を見ても対応できない」

こうした問題は、プログラムの不具合だけで起きるわけではありません。

システム基盤、運用設計、移行設計、非機能要件の詰めが甘いことで起きることも多いです。

SEの仕事はプログラミングだけではない

SEという言葉は、とても広く使われています。

現場によっては、プログラマーに近い仕事をする人もいます。
お客様と要件を詰める人もいます。
プロジェクト全体を管理する人もいます。
サーバやネットワークを設計する人もいます。
データベースを専門にする人もいます。
運用設計や監視設計を担当する人もいます。

つまり、SEといっても、役割はかなり幅広いです。
システム開発には、たとえば次のような役割があります。

• 業務要件を整理する人
• 画面や機能を設計する人
• プログラムを書く人
• データベースを設計する人
• サーバ構成を設計する人
• ネットワークを設計する人
• 監視やバックアップを設計する人
• 性能テストを計画する人
• 障害復旧テストを行う人
• 本番移行を計画する人
• 稼働後の運用を設計する人

この中で、プログラミングは重要な一部です。

ただし、システム開発全体で見ると、プログラミング以外の仕事も非常に多いです。特に企業向けの業務システムでは、「作ったら終わり」ではありません。

何年も使われます。
利用者が増えます。
データも増えます。
法律や業務ルールも変わります。
障害対応も発生します。

セキュリティ対策も継続的に必要です。
そのため、システム開発では、最初から運用や保守まで見据えて設計する必要があります。

インフラエンジニア視点で見るシステム開発

インフラエンジニア、またはシステム基盤エンジニアは、システムの土台を作る役割です。

ただし、ここでいう土台とは、単にサーバを用意することではありません。
本番でシステムを安定して動かすために、次のようなことを考えます。

• 可用性：障害が起きても使い続けられるか
• 信頼性：壊れにくく、安定して動くか
• 性能：必要な処理速度を満たせるか
• 拡張性：利用者やデータが増えても対応できるか
• 運用性：監視、バックアップ、障害対応ができるか
• 保守性：変更やメンテナンスがしやすいか
• 移行性：旧システムから安全に切り替えられるか
• セキュリティ：不正アクセスや情報漏えいを防げるか

お客様は、画面や機能だけを求めているわけではありません。
本当は、こう思っています。

「業務時間中は止まらないでほしい」
「遅くて使えないのは困る」
「障害が起きたら早く復旧してほしい」
「データは失わないでほしい」
「個人情報は守ってほしい」
「運用担当者が対応できる仕組みにしてほしい」
「将来、利用者が増えても使い続けたい」

これらは、すべてシステム基盤の設計に関係します。
だからこそ、システム開発を理解するには、アプリケーションだけでなく、インフラ／基盤の視点が必要です。

システム開発の全体工程

ここからは、システム開発が現場でどのような順番で進むのかを見ていきます。システム開発は、かなり単純化すると次の流れで進みます。

プロジェクトごとに呼び方や細かい進め方は違いますが、まずは
「決める → 設計する → 作る → 確認する → 切り替える → 改善する」
という流れをつかめばOKです。

この図を見ると分かる通り、システム開発は「プログラミング（コーディングとコンポーネントの開発）」だけで完結しません。

多くの人は、システム開発というと「プログラミング」を思い浮かべます。

もちろん、プログラミングは重要です。

しかし実際には、その前に要件定義や設計があり、その後にテスト、移行、運用保守まで続きます。

つまり、システム開発とは、単にコードを書く仕事ではありません。

業務を動かす仕組みを、作って終わりではなく、本番で安定して使える状態まで持っていく仕事です。

この全体像を最初に理解しておくと、SEの仕事がかなり立体的に見えるようになります。

業務系システム開発の工程名に置き換えると、次のようになります。

初心者SEは、まずこの流れを頭に入れておくとよいです。

現場で資料名や会議名を聞いたときに、

「ああ、これは基本設計の話だな」
「これは基盤テストの話だな」
「これは移行工程の話だな」

と位置づけられるだけで、かなり理解しやすくなります。

システム開発では、いま自分がどの工程にいるのかを意識することが大切です。

要件定義の段階で話すべきこと。
設計の段階で決めるべきこと。
テストの段階で確認すべきこと。
移行の段階で慎重に見るべきこと。
運用保守で継続的に確認すべきこと。

それぞれの工程には役割があります。

この工程のつながりが見えるようになると、SEの仕事はかなり分かりやすくなります。

そして、システム開発はアプリ開発と基盤構築が並行して進みます。

システム開発は、アプリケーション開発だけで進むわけではありません。
画面や機能を作るアプリケーション開発と並行して、システム基盤の設計・構築・テストも進みます。
たとえば、申請ワークフローシステムを作る場合、アプリ側では次のようなことを考えます。

• 申請登録画面をどう作るか
• 承認ルートをどう判定するか
• 差戻しや再申請をどう扱うか
• 承認履歴をどう表示するか
• メール通知をどう送るか

一方、基盤側では次のようなことを考えます。

• Web/AP/DBサーバをどう構成するか
• サーバを冗長化するか
• ロードバランサを使うか
• DBをActive-Standby構成にするか
• バックアップを何時に取得するか
• 障害時に何分以内で復旧するか
• ログをどこに出すか
• 監視アラートを誰に通知するか
• セキュリティパッチをどう適用するか
• 本番移行時にどの順番で切り替えるか

利用者から見えるのは、主にアプリケーションです。
しかし、システムが本番で安定して動くかどうかは、基盤設計に大きく左右されます。

ここを理解していないと、システム開発を「画面と機能を作る仕事」だけだと誤解してしまいます。

実際には、システム開発は、アプリケーションとシステム基盤を組み合わせて、業務を動かす仕組みを作る仕事です。

ここまでで、システム開発が「プログラミングだけでは終わらない」ことは、かなり見えてきたと思います。

ここから先が、システム開発の本当の現場です。

RFPの曖昧な要件をどう具体化するのか。ログ保管期間ひとつで、なぜストレージコストが跳ねるのか。機能は動いているのに、なぜ運用テストで止まるのか。移行データに「存在しない日付」が入っていたら、どう扱うのか。

こうした話は、教科書的な説明だけではなかなか見えてきません。

後編では、各工程で初級SEがどこを見ればよいのか、現場の落とし穴を具体的に整理しています。

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

システム開発の見積書を見ると、総額が数億円になっていることがあります。

「プログラムを修正するだけなのに、なぜこれほど高いのか」

システム開発に関わった経験が少ないと、こう感じるかもしれません。

システム更改で必要になるのは、プログラムの設計や製造だけではありません。現行システムの調査、クラウド基盤の構築、データ移行、テスト、切替、プロジェクト管理など、多くの作業が発生します。

本記事では、架空のA銀行が実施するクラウド更改プロジェクトを例に、数億円の見積もりの内訳と、金額の妥当性を確認するための見方を解説します。

A銀行のクラウド更改で行う仕事の全体像は、次の記事で解説しています。

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

システム開発はプログラミングだけではありません。A銀行のクラウドリフトを例に、現行調査、基盤設計、データ移行、テスト、運用引継ぎ、ステークホルダーや責任共有モデルまで、初心者向けに解説します。

sys-univ.com

2026.07.17

見積金額には何が含まれているのか

システム更改の費用を理解するには、最初に「何を含む金額なのか」を確認する必要があります。

システムに関係する費用は、大きく次の3つに分けられます。

本記事では、ベンダーへ発注する①更改プロジェクトの初期費用と、稼働後に継続して発生する②本番稼働後の継続費用の両方を扱います。

発注元の社員がプロジェクトへ参加する人件費や、利用部門への説明、マニュアル整備、教育などの③発注元の内部費用は対象外とします。

見積金額だけを見るのではなく、対象範囲を確認することが重要です。

開発期間中にもクラウド利用料が発生する

今回のプロジェクト期間は1年間とします。

この1年間に利用する開発環境、テスト環境、新しい本番環境のAWS利用料は、更改プロジェクト費用に含めます。

新しい本番環境は、サービス開始日に初めて作るわけではありません。事前に構築し、総合テスト、性能テスト、障害テスト、運用テスト、移行リハーサルなどで使用します。

稼働後の運用期間を5年間とすると、新本番環境を利用する期間は実質的に約6年間になる場合があります。

• 更改期間の1年間：更改プロジェクト費用

• 稼働後の5年間：継続的な運用費用

AWS利用料は、プロジェクト開始時から本番規模の金額が一律に発生するとは限りません。環境の構築時期、サーバー台数、稼働時間、テスト工程に応じて段階的に増えていきます。

開発環境やテスト環境も、稼働後にすべて廃止するとは限りません。規模を縮小し、保守開発用の環境として残す場合は、稼働後のAWS利用料へ引き継がれます。

見積書では、どの環境を、いつからいつまで、誰の契約で利用するのかを確認する必要があります。

システム開発費用を構成する3つの要素

システム更改では、プログラムだけでなく、設計書、テスト仕様書、移行計画書、運用手順書など、多くの成果物を作成します。

システム開発費用は、こうした成果物を作成する人件費に加え、環境利用料や製品費など、主に次の3つの要素で構成されます。

1. 人が作業するための費用

2. プロジェクト期間中の環境利用料

3. 製品、回線、外部サービスの費用

ベンダーは、これらの費用を算定する際に、契約範囲内で発生し得る不確定要素も見積もりへ織り込みます。

1．人が作業するための費用

システム開発では、作業量を人月で表します。

1人月は、1人が1か月働く作業量です。

見積金額は、作業量に人月単価を掛けて計算します。

人月単価は、担当者の給与そのものではありません。

企業が技術者を雇用し、継続的にサービスを提供するには、給与以外にも次のような費用が必要です。

• 社会保険料や福利厚生費

• 採用費や教育費

• オフィスや業務設備の費用

• 管理部門や営業部門の費用

• プロジェクト管理費

• 会社として確保する利益

月130万円の人月単価であっても、担当者本人が月130万円を受け取っているわけではありません。

2．プロジェクト期間中の環境利用料

クラウド更改では、開発環境、テスト環境、新本番環境などのAWS利用料が発生します。

サーバーだけでなく、ストレージ、データベース、バックアップ、監視、ネットワーク通信なども費用の対象です。

利用する環境数やサーバー台数が増えれば、利用料も増加します。

3．製品、回線、外部サービスの費用

システムでは、AWS以外にも各種製品やサービスを利用します。

• データベース製品

• 監視製品

• ジョブ管理製品

• セキュリティ製品

• 専用回線

• 外部サービス接続

• 証明書

• 技術サポート

製品によっては、旧環境と新環境を並行稼働させる期間に、両方のライセンスが必要になることがあります。

Oracle Databaseなどのライセンスは、製品のエディション、構成、契約内容、利用方法によって扱いが異なります。移行期間中に追加契約が必要かどうかは、契約条件を個別に確認します。

見積もりに織り込まれるリスク分

プロジェクト開始前に、すべての問題を正確に把握することは困難です。

現行システムの資料が不足している、クラウド化に伴って古いプログラムがそのままでは動かない箇所が想定より多い、データ品質に問題があるといった事象が発生する可能性があります。

ベンダーは、契約範囲内で発生し得る不確定要素を見込み、各作業の工数やプロジェクト管理費などへリスク分を織り込むことがあります。

見積もり漏れ、生産性不足、契約範囲内で発生した追加対応などを、ベンダー側で処理するための内部的な費用です。

要件追加や仕様変更によって契約外の作業が必要になった場合は、リスク分で吸収する話ではありません。作業内容と影響を整理し、追加見積もりや変更契約として扱います。

3つの要素を費用項目へ細分化する

先ほど整理した3つの要素を、A銀行のクラウド更改プロジェクトで発生する費用項目へ細分化すると、次のような見積もりになります。

3億円のうち、2億5,500万円は、人が現行調査、設計、構築、改修、移行、テスト、引継ぎを行うための費用です。全体の85％を占めています。

残る費用は、プロジェクト期間中のAWS利用料と、製品、回線、外部サービスの費用です。各項目の見積金額には、契約範囲内で発生し得る不確定要素も織り込まれています。

この見積もりでは、アプリケーション対応費は5,000万円です。

全体の約17％に当たります。

残りの約83％は、基盤、テスト、移行、管理、環境利用料、製品費、運用引継ぎなどです。

システム開発費用の大部分が、プログラム製造以外の作業に使われていることが分かります。

アプリケーション担当者は何人いるのか

アプリケーション対応費5,000万円を、人月単価130万円で計算します。

プロジェクト期間を12か月とすると、1か月当たりの平均要員数は次のようになります。

平均すると、アプリケーション担当者は3人程度です。

ここでいう平均3.2人は、プロジェクト期間中に常に3人程度が作業するという意味ではありません。現行調査や設計の時期は少人数で進め、プログラム改修や単体テストの時期に要員を増やし、作業の完了に合わせて減らしていきます。

例として、38人月を次のように配置します。

この表を月別のグラフにすると、要員数が多い時期と少ない時期を把握できます。このような資料を、要員山積み表や要員山積み計画と呼びます。

要員山積み計画は、プロジェクト内部の進捗管理だけに使う資料ではありません。

すべての技術者をベンダーが自社内で確保できるとは限りません。協力会社へ作業を委託する場合は、この計画を基に必要な人数、スキル、参画時期、離任時期を調整します。

設計工程には、業務と現行システムを理解した技術者が必要です。改修工程では、対象言語やフレームワークの経験者を確保します。テスト工程では、検証や障害分析を担当できる技術者が求められます。

単に「3人を確保する」のではなく、どの工程に、どのスキルを持つ要員を、何人配置するのかを計画します。

3億円のプロジェクトと聞くと、数十人のプログラマーが1年間開発している姿を想像するかもしれません。実際には、アプリケーション改修を担当する人数は限られ、基盤、移行、テスト、運用、管理などの担当者が工程ごとに参加します。

アプリケーション対応費には、プログラム製造だけでなく、影響調査、設計、非互換箇所の修正、単体テストなども含まれます。純粋なコーディングに使われる工数は、38人月より少なくなります。

基盤、移行、テスト、運用、管理など、プログラミング以外の仕事を含む全体像は、冒頭で紹介した記事で詳しく解説しています。

稼働後も継続的な費用がかかる

更改プロジェクトが完了しても、システムに関する支払いが終わるわけではありません。

稼働後は、本番環境を動かすためのクラウド利用料に加え、監視、障害対応、問い合わせ対応、製品保守、パッチ適用、機能改善などの費用が継続的に発生します。

主な費用と作業内容は、次のとおりです。

運用保守費は、障害が発生したときだけ支払う費用ではありません。

24時間365日の対応を求める場合は、監視担当者が異常を検知し、一次切り分けを行ったうえで、必要に応じてアプリケーションや基盤を担当する技術者へ連絡します。実際の体制は、複数名による当番制や、監視部門から開発ベンダーへのエスカレーションで構成されます。

障害が発生していない時間も、連絡を受けられる体制を維持しなければなりません。開発ベンダーの保守要員1名分を毎月確保する契約であれば、人月単価130万円として年間1,560万円になります。

月次報告が契約に含まれる場合は、監視結果、障害件数、問い合わせ状況、作業実績、未解決課題、翌月予定などを集計し、報告書を作成します。障害が発生しなかった月にも、監視、定期確認、報告、会議などの作業が発生します。

パッチ対応も、メーカーから提供された修正プログラムを、そのまま本番環境へ適用する作業ではありません。

脆弱性や障害の内容を確認し、適用の必要性と緊急度を判断します。検証環境へ事前に適用し、アプリケーションや運用機能への影響を確認した後、本番作業の手順、停止時間、切り戻し方法を整理します。

メジャーバージョンアップでは、非互換機能の調査、アプリケーション改修、総合テストが必要になることもあります。通常の運用保守契約へ含めず、別プロジェクトとして見積もる場合もあります。

5年間の継続費用を考える

稼働後の費用は、システムの規模、構成、対応時間、保守範囲によって大きく変わります。

年間費用に一律の相場はありません。ここでは規模感をつかむための説明用モデルとして、今回の更改プロジェクト費用3億円に対し、年間10％の継続費用が発生すると仮定します。

年間の継続費用は3,000万円です。5年間では1億5,000万円となり、初期の更改プロジェクト費用3億円と合わせると、更改開始から稼働後5年間までにかかる総費用は4億5,000万円になります。

更改費用だけを見れば3億円ですが、5年間の運用まで含めると、さらにその半分に当たる1億5,000万円が必要です。システムの予算は、構築時の金額だけではなく、稼働後に発生する費用も含めて考えなければなりません。

年間3,000万円のうち、開発ベンダーの保守要員1名分を毎月確保すると、年間1,560万円です。試算では、残る1,440万円、月平均120万円の中で、AWS利用料、監視、製品保守、回線、外部サービス、パッチ対応などを賄うことになります。

この仮定では、保守要員だけで年間費用の半分を占めます。クラウド利用料や製品保守まで含めると、年間10％では不足する規模のシステムも十分にあり得ます。

この金額は、一般的な相場を示すものではありません。24時間365日の対応が不要なシステムや、問い合わせ件数が少ないシステムでは費用を抑えられます。高い可用性や短い復旧時間が求められ、外部接続や対象製品が多いシステムでは、年間10％を超えることもあります。

オンプレミスのメーカー製品では、アップグレード権などを含む保守契約が製品価格の一定割合で設定されることがあります。クラウド更改では、そこへAWS利用料、運用監視、開発ベンダーの保守体制などが加わります。外貨建てで契約する製品やサービスでは、為替変動も考慮する必要があります。

システム更改の費用を考える際は、初期の3億円だけで判断するのではなく、稼働後5年間に発生する費用を含めて捉える必要があります。契約者と費用負担者、対応時間、保守範囲、パッチやバージョンアップの扱いを、見積書や契約書で確認します。

見積書で確認すべき3つの根拠

見積金額が妥当かどうかを確認するには、総額だけを見ても判断できません。

更改プロジェクト費用だけでなく、稼働後のクラウド利用料や運用保守費についても、作業範囲、数量、算定根拠を確認する必要があります。

見積書では、次の3点を確認します。

1．何を実施するのか

最初に、見積金額に含まれる作業範囲を確認します。

「テスト一式」「基盤構築一式」「運用保守一式」とだけ記載されている場合、どこまで対応するのか分かりません。

テストであれば、対象工程、対象機能、実施回数、障害対応、再テストなどの範囲を確認します。

運用保守であれば、監視、障害対応、問い合わせ対応、定期作業、月次報告、パッチ対応のどこまで含むのかを確認します。

24時間365日の連絡体制を維持するのか、平日日中だけ対応するのかでも費用は変わります。パッチ対応についても、情報収集と適用要否の判断だけを行うのか、事前検証、本番適用、回帰テストまで含むのかを確認します。

契約書や見積書に書かれていない作業は、稼働後に追加費用となる可能性があります。

2．数量はいくつなのか

次に、費用の前提となる数量を確認します。

主な数量には、次のようなものがあります。

• 人月数・保守要員数

• サーバー台数

• 環境数

• テストケース数

• 移行対象データ量

• 外部接続数

• ライセンス数

• 対応時間

• パッチ対象製品数

• リリース・定期作業回数

「テスト環境3面」「サーバー20台」「外部接続10本」「保守要員1名分」「月次報告12回」のように数量が示されていれば、見積金額との関係を確認できます。

数量が書かれていない見積もりでは、金額が高いのか安いのかを判断できません。

3．なぜその数量になるのか

最後に、数量の算定根拠を確認します。

サーバー20台であれば、各サーバーの役割、冗長化構成、性能要件などが根拠になります。

外部接続10本であれば、接続先、通信方式、認証方式、試験方法などを確認します。

保守要員1名分であれば、問い合わせ対応、障害調査、定期作業、月次報告、待機時間など、どの作業を積み上げた結果なのかを確認します。

AWS利用料であれば、インスタンスの種類、稼働時間、ストレージ容量、バックアップ、データ転送、冗長化などの条件が根拠になります。

パッチ対応であれば、対象製品数、適用頻度、影響調査の範囲、検証環境の有無、本番停止時間、回帰テストの範囲などを確認します。

前提条件が変わったときに、どの数量が変わり、初期費用や年間費用へどの程度影響するのかまで説明できる見積もりが、実際のプロジェクトで使える見積もりです。

まとめ

システム開発費用は、プログラマーの人件費だけで構成されているわけではありません。

現行調査、プロジェクト管理、クラウド基盤、ネットワーク、製品、データ移行、テスト、切替、運用引継ぎなど、多くの作業と費用が含まれています。

今回の3億円の見積もりは、次の3つの要素で構成されています。

• 人が作業するための費用：2億5,500万円

• プロジェクト期間中の環境利用料：2,000万円

• 製品、回線、外部サービスの費用：2,500万円

各費用には、契約範囲内で発生し得る不確定要素も織り込まれています。

アプリケーション対応費は5,000万円で、全体の約17％です。人月単価を130万円とすると約38人月となり、1年間の平均要員数は約3.2人です。

平均3.2人は、1年間を通じて同じ人数が配置されるという意味ではありません。工程ごとの要員数を要員山積み計画で可視化し、社内や協力会社と必要な人数、スキル、参画時期、離任時期を調整します。

更改プロジェクトが完了した後も、クラウド利用料、運用保守費、製品保守費、回線費、外部サービス費、パッチ対応費、保守開発費が継続的に発生します。

今回の例で、稼働後の費用を更改プロジェクト費用の年10％と仮定すると、年間3,000万円、5年間で1億5,000万円です。更改から稼働後5年間までの総費用は4億5,000万円になります。

この金額は一般的な相場ではありません。保守要員1名分を毎月確保するだけでも、人月単価130万円なら年間1,560万円です。クラウド利用料、監視、製品保守、回線、外部サービスまで含めると、年間10％では不足するシステムもあります。

初期の更改費用だけを見て予算を判断すると、稼働後に必要な費用を見落とします。システムにかかる費用は、構築から運用終了までの総費用で捉える必要があります。

見積もりの説明責任とは、総額を提示することではありません。

何を実施するのか、数量はいくつなのか、なぜその数量になるのかを、金額と結び付けて説明することです。

システム開発費用を理解するには、「高いか安いか」だけでなく、その金額がどの作業、数量、契約条件から構成されているのかを見る必要があります。

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

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

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

RDS for Oracleでは、オンプレミスOracleと同じ方法でSYS.X$BHを直接参照できません。

対応する環境では、X$BHを基にしたSYS.RDS_X$BHビューを作成できます。ただし、X$固定表はOracle内部の非公開オブジェクトであり、本番環境で利用する場合は、非本番環境での検証やエンジンアップグレード後の確認が必要です。

一方、調査の目的が、

DBバッファキャッシュ上に、どのテーブルやインデックスのブロックがどの程度存在しているか確認する

ことであれば、Oracleが公開している動的パフォーマンスビューV$BHを利用できます。

V$BHはX$BHの完全な代替ではありません。LRU_FLAGやTCHなど、V$BHでは取得できない情報もあります。

しかし、オブジェクトごとのキャッシュブロック数や概算容量を把握する目的であれば、V$BHから必要な情報を取得できます。

本記事では、RDS for OracleでV$BHを使用してDBバッファキャッシュの内訳を調査するSQLと、結果を評価する際の注意点を解説します。

SYS.X$BHを直接参照できない理由と、SYS.RDS_X$BHを利用する際の条件については、以下の記事で整理しています。

【RDS for Oracle】オンプレの調査SQLが動かない｜X$BHを直接参照できない理由

RDS for OracleでSYS.X$BHを直接参照できない理由を解説。SYSDBA権限の制約、RDS_X$BHの作成方法、V$BHとの使い分けや運用上の注意点を整理します。

sys-univ.com

2026.07.13

V$BHで確認できる情報

V$BHは、SGA内に存在する各バッファの状態を表示する動的パフォーマンスビューです。

Oracle公式リファレンスでは、バッファの状態、データファイル番号、ブロック番号、データオブジェクト番号、表領域番号などを確認できるビューとして説明されています。

V$BHの列定義｜Oracle Databaseリファレンス

オブジェクト別のキャッシュ量を調査する際、主に利用する列は次のとおりです。

このうち、オブジェクトとの結合で中心になるのがOBJDです。

V$BH.OBJDをDBA_OBJECTS.DATA_OBJECT_IDと結合することで、バッファキャッシュ上のブロックが、どのテーブル、インデックス、パーティションに属しているかを確認できます。

OBJECT_IDではなくDATA_OBJECT_IDで結合する

V$BHとDBA_OBJECTSを結合する際、注意したいのが結合列です。

次のように、OBJECT_IDと結合したくなるかもしれません。

ON o.object_id = bh.objd

しかし、ここではOBJECT_IDではなく、DATA_OBJECT_IDを使用します。

ON o.data_object_id = bh.objd

OBJECT_IDは、データディクショナリ上でオブジェクトを識別する番号です。

一方、DATA_OBJECT_IDは、そのオブジェクトのデータを格納するセグメントに対応する番号です。

V$BH.OBJDが保持しているのは、バッファ内のブロックに対応するデータオブジェクト番号です。そのため、DBA_OBJECTS.DATA_OBJECT_IDと結合します。

Oracle公式のバッファキャッシュ調査SQLでも、次の条件が使われています。

o.data_object_id = bh.objd

この違いは、パーティション表や、TRUNCATE、MOVEなどによってセグメントが再作成されたオブジェクトを扱う場合に重要です。

オブジェクトの論理的な識別子であるOBJECT_IDが変わらなくても、物理的なセグメントに対応するDATA_OBJECT_IDが変化する場合があります。

バッファキャッシュ上のブロックを、実際のセグメントへ正しく関連付けるには、DATA_OBJECT_IDを使用する必要があります。

Oracle公式の基本SQL

OracleのPerformance Tuning Guideでは、バッファキャッシュ上に存在するオブジェクト別のブロック数を、次のようなSQLで確認しています。

SELECT
    o.object_name,
    COUNT(*) AS number_of_blocks
FROM
    dba_objects o,
    v$bh bh
WHERE
    o.data_object_id = bh.objd
    AND o.owner <> 'SYS'
GROUP BY
    o.object_name
ORDER BY
    COUNT(*);

このSQLは、V$BH.OBJDとDBA_OBJECTS.DATA_OBJECT_IDを結合し、オブジェクトごとのブロック数を集計するものです。

基本SQLと、バッファキャッシュの利用状況を調査する手順は、Oracle公式のチューニングガイドで確認できます。

Tuning the Database Buffer Cache｜Oracle Database Performance Tuning Guide

基本的な目的は、このSQLで達成できます。

ただし、実務で結果を確認する場合は、次の情報も表示したほうが分かりやすくなります。

• オブジェクトの所有者

• パーティション名

• オブジェクト種別

• 表領域名

• ブロックサイズ

• キャッシュ容量の概算値

これらを追加したSQLが次の例です。

オブジェクト別のキャッシュ容量を確認するSQL

SELECT
    o.owner,
    o.object_name,
    o.subobject_name,
    o.object_type,
    t.name AS tablespace_name,
    COUNT(*) AS cached_blocks,
    d.block_size,
    ROUND(
        COUNT(*) * d.block_size / 1024 / 1024,
        2
    ) AS cached_mb
FROM
    v$bh bh
    LEFT JOIN dba_objects o
        ON o.data_object_id = bh.objd
    LEFT JOIN v$tablespace t
        ON t.ts# = bh.ts#
    LEFT JOIN dba_tablespaces d
        ON d.tablespace_name = t.name
WHERE
    bh.status <> 'free'
GROUP BY
    o.owner,
    o.object_name,
    o.subobject_name,
    o.object_type,
    t.name,
    d.block_size
ORDER BY
    cached_mb DESC;

このSQLでは、V$BH上の使用中バッファを、データオブジェクトと表領域へ関連付けています。

結果は、概ね次のような形式になります。

この結果から、どのオブジェクトのブロックがバッファキャッシュ上で大きな割合を占めているかを確認できます。

SQLの各項目

OWNER

オブジェクトの所有者です。

異なるスキーマに同じオブジェクト名が存在する場合があるため、OBJECT_NAMEだけではなく、OWNERも表示します。

OBJECT_NAME

テーブルやインデックスなどのオブジェクト名です。

パーティション表やパーティションインデックスでは、同じOBJECT_NAMEに対して複数のセグメントが存在します。

SUBOBJECT_NAME

パーティション名またはサブパーティション名です。

これを表示しないと、どのパーティションのブロックがキャッシュされているか分からなくなります。

OBJECT_TYPE

オブジェクトの種類です。

主に次のような値が表示されます。

• TABLE

• INDEX

• TABLE PARTITION

• INDEX PARTITION

• TABLE SUBPARTITION

• INDEX SUBPARTITION

TABLESPACE_NAME

オブジェクトのブロックが属している表領域名です。

V$BH.TS#とV$TABLESPACE.TS#を結合して取得します。

CACHED_BLOCKS

バッファキャッシュ上に存在するブロック数です。

V$BHは基本的にバッファ単位で行を返すため、COUNT(*)によってオブジェクトごとのブロック数を集計します。

BLOCK_SIZE

表領域のブロックサイズです。

通常はデータベース標準のブロックサイズが使われますが、非標準ブロックサイズの表領域が存在する可能性もあります。

そのため、固定値として8192を掛けるのではなく、DBA_TABLESPACES.BLOCK_SIZEを使用します。

CACHED_MB

キャッシュされている概算容量です。

計算式は次のとおりです。

キャッシュブロック数 × ブロックサイズ

SQLでは、この値を1024で2回割り、MiB相当へ換算しています。

ただし、この値はオブジェクトの物理サイズではありません。

SQLを実行した時点で、バッファキャッシュ上に存在するブロック数を容量換算した値です。

LEFT JOINを使用する理由

V$BHとDBA_OBJECTS、表領域関連ビューの結合にはLEFT JOINを使用しています。

INNER JOINを使用すると、対応するオブジェクトや表領域情報を取得できなかったバッファが、結果から除外されます。

通常のユーザーテーブルやインデックスだけを確認する場合は、INNER JOINでも大部分の結果を取得できます。

しかし、バッファキャッシュには次のようなブロックが含まれる可能性があります。

• 一時セグメント

• Undo関連ブロック

• 内部管理用ブロック

• オブジェクトへ単純に関連付けられないバッファ

• 取得タイミングによってディクショナリと一致しない情報

そのため、まずはV$BH側の行を残し、オブジェクトや表領域へ関連付けられなかった行も確認できるようにしています。

OWNER、OBJECT_NAME、TABLESPACE_NAMEなどがNULLになった行が多い場合は、不要と判断して除外するのではなく、FILE#、BLOCK#、TS#、STATUSなどを追加して内容を確認します。

ユーザーオブジェクトだけを簡潔に確認したい場合は、INNER JOINへ変更しても構いません。

STATUSがfreeのバッファを除外する

今回のSQLでは、次の条件を指定しています。

WHERE bh.status <> 'free'

V$BH.STATUSには、バッファの状態が表示されます。

代表的な値は次のとおりです。

今回の目的は、現在キャッシュ上で使用されているブロックの集計です。そのため、未使用状態のfreeを除外しています。

障害解析やRAC関連の調査など、状態ごとの内訳が必要な場合は、STATUSをSELECT句とGROUP BY句へ追加して確認します。

キャッシュ量が多いオブジェクトは問題なのか

V$BHの結果を見ると、特定のテーブルやインデックスが大量のブロックを占めていることがあります。

しかし、

キャッシュ量が多い
＝不要なデータがキャッシュされている
＝チューニングが必要

とは限りません。

業務で継続的に参照されるテーブルであれば、多くのブロックがキャッシュされていることは自然です。

必要なブロックがバッファキャッシュに残っていれば、その後のSQLはストレージからの物理読み込みを減らせます。

問題になる可能性があるのは、例えば次のようなケースです。

• 利用頻度の低い大規模表が大量に読み込まれている

• 大規模バッチの後にオンライン処理の物理読み込みが増える

• フルスキャンが繰り返されている

• 想定していたインデックスが使用されていない

• 同じ大規模オブジェクトへ不要なアクセスが繰り返されている

• 必要なブロックが短時間でキャッシュから追い出されている

したがって、V$BHの結果だけで良否を判断してはいけません。

V$BHと一緒に確認する情報

SQLと実行計画

キャッシュ上で大きな割合を占めるオブジェクトを特定したら、そのオブジェクトへアクセスしているSQLを確認します。

• フルテーブルスキャンになっていないか

• パーティションプルーニングが機能しているか

• 想定以上の行やブロックを読み込んでいないか

• 同じ処理を不必要に繰り返していないか

キャッシュ量が多いという結果だけで、SQLに問題があるとは判断できません。実行計画と実行統計を組み合わせて評価します。

物理読み込みと待機イベント

AWRやStatspack、V$SYSSTATなどから、処理量に対して物理読み込みが増えていないかを確認します。

また、次のようなI/Oやバッファ関連の待機イベントも確認します。

• db file sequential read

• db file scattered read

• direct path read

• free buffer waits

• buffer busy waits

• read by other session

ただし、待機イベントが発生しているだけで、バッファキャッシュを増やすべきとは判断できません。

SQL、ストレージ性能、DBWRの書き出し、同時実行数など、複数の要因を確認する必要があります。

V$DB_CACHE_ADVICE

バッファキャッシュのサイズを変更した場合に、物理読み込みがどの程度変化すると推定されるかを確認するには、V$DB_CACHE_ADVICEを利用できます。

Oracle公式ドキュメントでは、複数の仮想的なキャッシュサイズに対する物理読み込み数やミス率の予測値を表示するビューとして説明されています。

ただし、これは実測値ではなく予測値です。

代表的な業務負荷が流れている状態で取得し、AWRや実際のレスポンスタイムと合わせて評価します。

V$BHの検索負荷に注意する

V$BHは、バッファキャッシュ内の各バッファに対応する行を保持しています。

バッファキャッシュが大きい環境では、V$BHの行数も多くなります。

そこへDBA_OBJECTSや表領域関連ビューを結合し、全件をGROUP BYすると、SQL自体がCPUやソート領域を使用します。

Oracle公式ドキュメントでも、全セグメントを対象にした集計は、バッファキャッシュのサイズによって多くのソート領域を必要とする場合があると説明されています。

本番環境で実行する場合は、次の点に注意します。

• 非本番環境で実行時間と負荷を確認する

• 業務ピークを避ける

• 必要に応じて対象スキーマを絞る

• 定期監視として短い間隔で実行しない

• 実行計画とTEMP使用量を確認する

参照SQLだから安全とは限りません。

データを更新しないSELECTであっても、大量の行を走査して集計するSQLは、データベースへ負荷を与えます。

非マスターユーザーから参照する場合

非マスターユーザーへV$BHの参照権限を付与する場合は、RDSの管理プロシージャgrant_sys_objectを使用します。

権限付与時には、シノニム名のV$BHではなく、基になるSYSオブジェクト名V_$BHを指定します。

BEGIN
    rdsadmin.rdsadmin_util.grant_sys_object(
        p_obj_name  => 'V_$BH',
        p_grantee   => 'MONITOR_USER',
        p_privilege => 'SELECT'
    );
END;
/

ただし、付与できるのは、マスターユーザー自身が保持している権限の範囲内です。

実行前に、対象環境でマスターユーザーからV$BHを参照できることを確認してください。

また、監視ユーザーへ権限を付与する場合は、必要なビューだけに限定し、広いカタログ参照権限を安易に付与しないほうが安全です。

X$BHとV$BHの違い

V$BHでオブジェクトごとのキャッシュ量を確認できますが、X$BHのすべての情報を取得できるわけではありません。

オブジェクト別のキャッシュブロック数や概算容量を確認したいのであれば、まずV$BHを検討できます。

一方、LRU_FLAGやTCHなどX$BH固有の情報が必要な場合や、Oracle Supportから固定表を使った調査を指示された場合は、対応環境でRDS_X$BHを作成する選択肢があります。

V$BHは調査の入口

V$BHが示すのは、SQLを実行した時点でバッファキャッシュ上に存在するブロックの状態です。直前に大規模バッチが実行されていれば、その処理で読み込まれたブロックが多く表示される可能性があります。

頻繁に利用されるオブジェクトであっても、DBインスタンスの再起動直後や業務開始前であれば、キャッシュブロック数は少なく表示されます。結果を評価する際は、まず取得タイミングを確認します。

• 代表的な業務負荷が実行されている時間帯か

• バッチ実行前か実行後か

• DBインスタンス再起動から十分な時間が経過しているか

必要に応じて複数の時間帯で結果を取得し、業務処理の実行状況やSQL統計、物理読み込み、待機イベントと対応付けて評価します。利用可能な機能やライセンス条件に応じて、AWR、Statspack、CloudWatch Database Insightsなども組み合わせます。

特定のオブジェクトが大量のバッファを使用しているという結果だけでは、キャッシュサイズの変更やSQLチューニングが必要とは判断できません。

調査では、既存SQLをそのまま再現することよりも、そのSQLで何を確認しようとしていたのかを整理することが重要です。オンプレミスで使用していたSYS.X$BHをRDS for Oracleから直接参照できない場合でも、目的がオブジェクト別のキャッシュブロック数を確認することであれば、公開された動的パフォーマンスビューであるV$BHを利用できます。

LRU_FLAGやTCHなど、X$BH固有の情報が必要な場合は、使用しているエンジンリリースと作成可能なビューを確認したうえで、SYS.RDS_X$BHの利用を検討します。X$表はOracle内部のシステムオブジェクトであるため、非本番環境で検証し、本番環境への導入はOracle Supportのガイダンスを踏まえて判断します。

V$BHは、性能問題の全体を説明するビューではありません。どのオブジェクトのブロックがバッファキャッシュ上に存在しているかを確認し、その後のSQL、実行計画、I/O、待機イベントの調査につなげる入口として位置づけます。

今回取り上げたX$BHの制約は、RDS for Oracleで変わる運用前提の一例です。SYSDBA権限、OSアクセス、物理ファイル操作、ログ取得、ストレージ管理についても、オンプレミスと同じ手順をそのまま使用できるとは限りません。

オンプレミスの操作を一対一で置き換えるのではなく、調査や運用の目的を整理し、RDSで提供される機能を使って手順を再構成する必要があります。

RDS for Oracleで変わる設計・運用上の前提と代替アプローチについては、以下の記事で整理しています。

RDS for Oracleを採用したら、オンプレ運用の前提が通用しなかった｜開発中に見えた設計ギャップと代替アプローチ

RDS for Oracleではオンプレ運用の前提が通用しない。Storage-Full、アーカイブログ、SSH不可など、開発中に見えた9つの設計ギャップと代替アプローチを整理します。

sys-univ.com

2026.07.12

まとめ

RDS for Oracleで、DBバッファキャッシュ上のオブジェクト別ブロック数を確認する場合は、V$BHを利用できます。

V$BH.OBJDは、DBA_OBJECTS.OBJECT_IDではなく、DATA_OBJECT_IDと結合します。

ON o.data_object_id = bh.objd

オブジェクト別のキャッシュ容量は、キャッシュブロック数と表領域のブロックサイズから概算できます。

キャッシュブロック数 × ブロックサイズ

V$BHはX$BHの完全な代替ではありませんが、どのオブジェクトのブロックがバッファキャッシュ上にどの程度存在しているかを確認する目的には利用できます。

キャッシュ量が多いオブジェクトが、直ちに性能問題の原因とは限りません。SQL、実行計画、物理読み込み、待機イベントなどの情報と対応付け、取得した時間帯の業務負荷も踏まえて評価する必要があります。

また、大規模なバッファキャッシュを全件集計するSQLは、相応のCPUやソート領域を使用する可能性があります。本番環境で実行する前に負荷を確認し、必要に応じて対象スキーマや表領域を絞ります。

オンプレミスの調査SQLをそのまま再現するのではなく、調査目的を起点に、RDSで利用可能な手段を組み合わせることが重要です。

大手SIerで20年以上、システム基盤SEとしてプロジェクトに参画してきました。その中で繰り返し遭遇してきたのが、運用設計の漏れや、処理方式設計との不整合を原因とするトラブルです。運用設計とは、本番稼働後に必要となる作業、判断基準、体制を整理し、それをシステムの処理方式や構成と結びつける設計です。

• 監視対象は定義されているのに、何を異常とみなすのか決まっていない。
• ログは出力されているのに、保持期間や削除方法が決まっていない。
• バックアップは取得しているのに、必要な時間内にリストアできるか確認されていない。
• ジョブネットは作られているのに、実行するスクリプトが存在しない。

こうした設計不備は、重大な障害の見逃しや復旧の遅れにつながります。システムを利用するお客様だけでなく、その先にいる利用者や社会へのサービス提供を損なう事態にもなりかねません。

それほど重要な設計領域であるにもかかわらず、運用設計は多くのプロジェクトで軽視されてきました。

なぜでしょうか。100のシステムがあれば、運用の形も100通りあります。運用・保守に関する確認観点を整理したフレームワークや標準はありますが、それをそのまま適用すれば運用設計が完成するわけではありません。サービス時間、業務日付、外部連携、夜間バッチ、監視、バックアップ、障害時の判断、運用体制は、システムごとに具体化する必要があります。非機能要件だけでなく、業務運用や組織の役割分担にもまたがるため、定形の設計書に集約しにくく、見える化しづらい設計領域だといえます。

もう一つ、情報の偏りという問題もあります。世の中の技術情報を見渡すと、logrotateの設定方法やクラウドサービスの使い方といった処理方式寄りの解説か、ITILに基づく管理プロセスといった組織・サービス管理寄りの解説か、そのどちらかに偏っています。現場のSEが本当に苦労するのは、その中間にある領域です。運用要件をどの仕組みで実現し、どの設定値、スクリプト、ジョブ、監視条件に落とし込むのか。ここを扱った情報は、驚くほど少ないのが実情です。

この記事では、システム基盤から見た運用設計を中心に、共通化しやすい検討項目を「運用設計書の目次サンプル」として示します。あわせて、運用設計が処理方式設計と切り離せない理由と、運用設計が要件定義から始まり、基本設計の段階で骨格が決まることを、現場の経験から整理します。

基本設計の段階で何を決めるべきかは、記事の最後で紹介する解説記事で体系的に扱っています。

実際にあった運用設計漏れによるトラブル

まず、運用設計漏れによって発生したトラブルの例を見てみます。

あるサーバでは、syslogファイルをローテーションしないまま、ログが出力され続けていました。このまま運用を続ければ、syslogファイルはパーティションの空き容量を消費し続けます。それがルート領域であれば、OSやミドルウェアが正常に動作できなくなり、ログインやプロセス起動にも支障が出る可能性があります。ログ管理設計の漏れがどのように障害へつながるのかを、図にすると次のとおりです。

ディスクの空き容量を監視していれば、容量が枯渇する前に検知できたかもしれません。ただ、これは監視だけの問題ではありません。空き容量の監視は、容量逼迫という状態を検知する仕組みです。根本原因は、ログの増加を前提に、保持、退避、圧縮、削除を設計していなかったことにあります。

ログ管理を運用設計項目として定義し、どのログを管理対象とするのか、何の目的で保存するのか、どの期間保持するのか、即時に参照できる必要があるのか、いつ外部領域へ退避するのか、いつ圧縮・削除するのか、誰が参照できるのかを決めていれば避けられたトラブルです。その運用設計を入力として、処理方式側では、logrotateを使うのかジョブで退避するのか、どのパーティションへ保存するのか、どれだけの容量が必要なのかを具体化します。

一見すると「検討していて当然」と思われる内容です。それでも、ログ管理を運用設計の対象として認識していないプロジェクトでは、実際に漏れます。

運用設計はいつやるのか｜要件定義から始まり基本設計で骨格が決まる

運用設計のプロセスを理解するには、システム開発全体の中での位置づけを押さえる必要があります。

ウォーターフォール型の開発プロセスは、要件定義、設計、製造、試験、移行、保守・運用という流れで説明されることが多いと思います。このモデルでは工程の最後に「保守・運用」が置かれているため、運用に関する検討もシステムが完成してから行えばよい、という誤解が生じます。

最後に置かれているのは、完成したシステムを実際に維持管理する運用工程です。そのシステムをどのように運用するのかを決める運用設計は、設計工程の中にあります。

運用設計を設計工程として扱わないプロジェクトでは、サービス開始直前になって検討不足が表面化します。ログがローテーションされない。バックアップはあるのに戻せない。ジョブは定義されているのに実行するスクリプトがない。監視アラートは出るのに一次対応者が決まっていない。夜間処理は終了したのに、業務を開始してよいか判断できない。私はそうした現場を数多く見てきました。

これらは、運用開始後に考える問題ではありません。工程初期から、処理方式とセットで具体化すべき設計事項です。

処理方式設計と運用設計は双方向でつながっている

ここからが、この記事で最も伝えたい内容です。運用設計で最も重要なのは、処理方式設計との接続です。運用設計は単独では成立せず、処理方式設計と対になって、初めて本番で運用できる設計になります。

処理方式設計とは、要件をどのような仕組みで実現するかを具体化する設計です。運用設計とは、その仕組みを実際の運用の中でどのように扱うかを具体化する設計です。この2つは別の設計領域ですが、完全に分けて考えることはできません。

ログ管理を例に考えます。運用設計側では、管理対象とするログ、利用目的、保持期間、参照要件、退避・削除方針、アクセス権限を決めます。「syslogを1か月保持する」と運用設計で決めたとします。この決定だけでは、1か月保持は実現できません。処理方式側で、日次と週次のどちらでローテーションするのか、Linuxのlogrotateで実現するのかジョブ管理製品で退避するのか、退避先ディレクトリをどこにするのか、圧縮するのか、外部のログ管理基盤へ転送するのか、必要なディスク容量はいくらか、容量逼迫をどの条件で検知するのかを設計する必要があります。運用設計の決定が、Linuxや監視製品、ログ管理製品の処理方式設計への入力になるわけです。

逆方向の流れもあります。Linux設計側でログの退避先を決めたなら、その情報は運用設計側へ伝えなければなりません。ログは、要件に応じてバックアップや外部保管の対象になります。退避先が運用設計側へ伝わっていなければ、バックアップ対象やログ収集対象から漏れる可能性があります。障害調査に必要なログが残っていない、という事態はこうして生まれます。

運用設計側が「何を、どれくらい、何の目的で管理したいのか」を決める。処理方式設計側が「それをどの仕組みで実現するのか」を決める。運用要件が処理方式に影響し、処理方式の制約が運用設計に戻ってくる。この関係は一方向の受け渡しではなく、レビューやウォークスルーを通じて、相互に入力とフィードバックを繰り返しながら固めていくものです。どちらを先に検討するかは状況によって異なりますが、運用設計者と処理方式設計者の間で認識齟齬を残さないことが重要です。

現場では、構築チームと運用準備チームが分かれ、ドキュメントも処理方式設計書と運用設計書に分断されることがあります。その結果、ログ保持期間を満たすためにどの設定と容量設計が必要なのか、という両者の紐付けが、設計者の頭の中にしか存在しない状態になりがちです。この紐付けを設計書、課題管理、レビューの仕組みで見える化できるかどうかが、運用設計の品質を左右します。

運用スクリプトは運用設計で横断的に洗い出す

処理方式設計と運用設計の双方向連携を示す例として、運用スクリプトを考えます。

バックアップ要件をジョブネットで実現するとします。ジョブネットには、バックアップ取得、ログ退避、世代削除、整合性確認、後処理といった個別ジョブが登録されます。それぞれのジョブでは、実行対象となるスクリプト、コマンド、プログラム、製品機能が必要です。

ここで問題になるのが、必要な実行部品を誰が洗い出すのかという点です。バックアップ方式だけを設計していると、バックアップ製品の設定は完了していても、ジョブから呼び出すスクリプトや終了判定処理が漏れることがあります。ジョブネットだけを設計していると、ジョブの箱は並んでいるのに、中で何を実行するのか決まっていないことがあります。運用で必要になるスクリプトや実行処理は、運用設計の中で横断的に洗い出す必要があります。

運用設計で横断的に洗い出すことと、運用設計担当がすべてのスクリプトを作成することは別です。バックアップスクリプトはバックアップ方式の担当、ログ退避スクリプトはログ管理方式の担当、ジョブ制御スクリプトはジョブ設計の担当、起動停止スクリプトはOS・ミドルウェアの担当というように、実際の設計、製造、単体試験は、その仕組みを設計した担当が行うのが基本です。

運用設計側で行うのは横断管理です。必要なスクリプトを一覧化し、用途、呼び出し元となるジョブ・手順・他スクリプト、関連する運用作業、作成担当、完成時期、単体試験の実施有無、後続テストでの確認方法を明確にします。そして、スクリプトの設計、製造、単体試験、ジョブ登録をWBSへ反映し、結合テスト、システムテスト、運用テストに間に合わせます。

この横断管理がないプロジェクトでは、個別の方式設計は完了しているのに、実際の運用に必要なスクリプトだけが作られていない、という事態が起こります。サービス開始直前になって発覚するスクリプト不足やジョブネットの実行エラーの多くは、この横断管理が不足した結果です。運用設計で必要な実行部品を早期に洗い出し、処理方式の担当へ返すことが重要です。

運用設計の全体像

システム運用とは、利用者へ提供しているサービスを安定して継続するために、システムを維持管理していく活動です。その運用を成立させるための設計が、運用設計です。全体像は、次の3つに分けて考えると理解しやすくなります。

業務運用設計は、業務機能や実際の業務作業と結びつく領域です。システム基盤運用設計は、サーバ、ネットワーク、ストレージ、ジョブ、監視、ログ、バックアップといった、システムを支える仕組みと強く結びつきます。全体運用設計は、ITILのプラクティスと重なる領域が多く、体制や責任分界、障害・変更管理、サービスレベル管理を扱います。この記事では、主にシステム基盤運用設計を対象とします。

なお、運用手順書一覧、運用スクリプト一覧、ジョブ一覧は、特定の区分だけに属するものではありません。3つの領域で必要になる成果物を横断的に洗い出し、作成担当と期限を管理する必要があります。

関連する工程に、運用テストがあります。運用テストでは、ここで設計した運用フロー、判断基準、承認フロー、復旧方法が実際に運用可能かを確認します。運用設計の品質が低ければ、運用テスト自体が成立しません。障害時の連絡先が分からない、問い合わせの受付方法が決まっていない、誰が業務開始可否を判断するのか分からない。こうした状態を、サービス開始後に残してはいけません。運用テストを含むテスト工程の考え方は、以下の記事で解説しています。

Vモデルは古くない｜設計とテストをつなぐ品質保証の考え方

Vモデルは古い開発手法の話ではなく、要件・設計で決めたことをテストで確認する品質保証の考え方です。バックアップ要件の具体例で各工程の対応関係を整理します。

sys-univ.com

2026.07.13

システム基盤運用設計書の目次サンプル

運用設計について調べている人が最も知りたいのは、運用設計書で検討すべき「項目」ではないでしょうか。以下に、システム基盤運用設計書の目次サンプルを示します。

この目次は、IPAの非機能要求グレードなどの確認観点を参考にしながら、実際のプロジェクトで扱いやすい運用作業単位に整理したものです。非機能要件の項目をそのまま設計書の章立てにしても、実際の運用作業との対応が見えにくいことがあります。プロジェクト参画経験から、システム運転、監視、ログ、バックアップ、起動停止といった、実際に発生する運用作業を目次の単位にすることで、検討漏れを減らせると考えています。表の「項目」は、運用設計書の章や節を組み立てる際のたたき台として使えます。

ただし、設計内容だけを書いて終わりではありません。各項目について、実施主体、実施契機・頻度、正常・異常の判断条件、承認者・判断者、入出力情報、運用フロー、必要な手順書、必要なスクリプト・ジョブ、処理方式設計への申し送りも、必要に応じて整理します。要件定義で合意した内容を、どの運用設計項目へ反映するのかを確認しながら進めることが重要です。

ここで挙げた項目は、一般的なシステムにおける最大公約数です。すべてのシステムに同じ項目を適用すればよいわけではありません。外部公開サービスであれば、DDoS対策やWAF運用が必要になるかもしれません。クラウドネイティブなシステムであれば、オートスケーリング、マネージドサービスのメンテナンス通知、クラウドコスト管理を追加することもあります。反対に、小規模なシステムでは、複数の項目を一つの章にまとめることもあります。

重要なのは、テンプレートにシステムを合わせることではありません。システム運用で発生する作業と判断を洗い出し、必要な項目を追加・統合することです。

ここで示した運用設計の項目は、基本設計の段階で方針が決まっていることが前提です。

運転スケジュール、監視、ログ、バックアップ、開局判定の方針を基本設計でどう決めるのか、基盤SEが見ている設計の全体像は、以下の記事で解説しています。

基本設計書の目次と、各章で作成すべき成果物を1つの表で対応させたExcelファイル付きです。運用設計書目次サンプルと2点セットで、設計書の抜け漏れ確認に使えます。

基本設計で決めること｜画面設計だけでは終わらない基盤SEの設計工程

基本設計は画面設計だけでは終わらない。ログ・バックアップ・ジョブ・監視など、本番運用を見据えた基盤設計の論点を、ファイルアップロードや夜間バッチの実例で整理します。

sys-univ.com

2026.06.20

運用設計は誰がやるのか｜4つの役割と責務分界

システムは構築して終わりではありません。想定した運用を実行できる状態で運用担当へ引き継いで、初めて開発プロジェクトの役割を果たしたといえます。運用設計では、作業内容だけでなく、誰が実施するのかを明確にする必要があります。

役割は契約形態や組織によって異なりますが、一般的には次のように整理できます。

同じ組織や担当者が複数の役割を兼ねる場合もあります。大切なのは、組織名ではなく責務を明確にすることです。監視アラートが発生したとき、誰が最初に確認するのか。原因調査は誰へ依頼するのか。業務影響は誰が判断するのか。処理を打ち切るかどうかを誰が承認するのか。ここが曖昧なままでは、連絡先一覧があっても運用は回りません。

また、すべての作業を自動化すればよいわけでもありません。頻度が低く、計画時間内に安全に実施できる作業であれば、手動運用を選ぶこともあります。ただし、手動で行う場合でも、実施者、実施時期、必要な権限、作業手順、正常性の確認方法、作業証跡、異常時の対応、承認・報告方法は設計する必要があります。自動化するか手動で残すかを、頻度、工数、リスク、ミスの影響、開発・保守コストから判断すること自体が、運用設計の重要な役割です。

まとめ｜運用設計は要件定義から始まっている

運用設計の目的は、システム利用者、運用担当、開発・保守担当、システムオーナーが、それぞれの役割を果たしながら、システムを安定して利用・維持できる状態をつくることです。

運用設計は、運用フェーズに入ってから考えるものではありません。要件定義からすでに始まっており、その骨格は基本設計の段階で決まります。運転スケジュール、ジョブ、監視、ログ、バックアップ・リストア、起動停止、開局・閉塞、運用日付、異常時運用、エスカレーション、運用スクリプト。これらの方針は、システム構成や処理方式とセットで具体化する必要があります。

運用設計側が、何をどのように運用したいかを決める。処理方式設計側が、それをどの仕組みで実現するかを決める。処理方式上の制約が分かれば、運用設計側が運用方法や判断基準を見直す。この双方向の関係を基本設計で押さえていなければ、詳細設計以降でどれだけ頑張っても、本番直前の「必要なスクリプトがない」「ジョブネットが動かない」「バックアップから戻せない」「アラート発生後の対応者がいない」「夜間処理後に業務を開始してよいか判断できない」は防げません。

運用設計は、運用担当へ仕事を押しつけるための設計ではありません。本番稼働後に発生する作業、判断、障害、変更を想定し、システムの仕組みとプロジェクト計画へ反映する設計であり、処理方式と運用設計をつなぎ、本番で運用できるシステムを設計することです。

開発工程全体の流れから確認したい方は、以下のシステム開発入門シリーズも参考にしてください。

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

Oracle DatabaseをオンプレミスからAmazon RDS for Oracleへ移行する際、確認すべきなのは、アプリケーションが正常に動作するかだけではありません。

性能調査、障害解析、ログ取得、セッション管理など、DBAが日常的に使用している調査手順が、RDS上でも同じように成立するかを確認する必要があります。

本記事で取り上げるのは、DBバッファキャッシュの利用状況を調査する際に使用されるX$BHです。

オンプレミスOracleで使用していたX$BH参照SQLを、RDS for Oracleのマスターユーザーで実行すると、次のエラーが発生します。

ORA-00942: table or view does not exist

Oracle Databaseという製品自体は同じです。

しかし、通常のRDS for OracleではSYSとしてログインできず、SYSDBA権限も使用できません。そのため、オンプレミスと同じ方法でSYS.X$BHを直接参照することはできません。

一方、現在のRDS for Oracleには、対応する環境でX$BHを基にしたSYS.RDS_X$BHビューを作成する仕組みがあります。

また、調査の目的によっては、Oracleが公開している動的パフォーマンスビューV$BHによって必要な情報を取得できます。

本記事では、RDS for OracleでSYS.X$BHを直接参照できない理由と、現在利用できる代替手段を整理します。

RDS for Oracleでは、X$BH以外にも、SYSDBA権限、OSアクセス、ストレージ操作、ログ取得など、オンプレミスの運用前提がそのまま通用しない場面があります。

RDS for Oracle全体の設計ギャップと代替アプローチについては、以下の記事で整理しています。

RDS for Oracleを採用したら、オンプレ運用の前提が通用しなかった｜開発中に見えた設計ギャップと代替アプローチ

RDS for Oracleではオンプレ運用の前提が通用しない。Storage-Full、アーカイブログ、SSH不可など、開発中に見えた9つの設計ギャップと代替アプローチを整理します。

sys-univ.com

2026.07.12

今回調べたいのはDBバッファキャッシュの内訳

Oracle DatabaseのSGAには、データブロックを保持するDBバッファキャッシュがあります。

SQLによって読み込まれたデータブロックをメモリ上に保持しておくことで、同じブロックが再び必要になった際に、ストレージから読み込む処理を減らせます。

更新されたブロックについても、即座にすべてがデータファイルへ書き込まれるわけではありません。更新済みのブロックはバッファキャッシュ上に保持され、DBWRによって適切なタイミングで書き出されます。

このように、DBバッファキャッシュはOracle DatabaseのI/O性能に大きく関係するメモリ領域です。

ただし、バッファキャッシュは大きければ大きいほどよい、というものではありません。

DBインスタンスで利用できるメモリには上限があります。SGAに多く割り当てれば、その分だけPGAやOS、RDSの管理プロセスが利用できるメモリは少なくなります。

例えば、アプリケーションの機能追加によって同時接続数や処理量が増え、PGAの総使用量が増える可能性があるとします。

DBインスタンス全体のメモリに余裕がなければ、PGAに必要なメモリを確保するため、SGAを縮小できるか検討することになります。

SGAには、DBバッファキャッシュのほかにも、共有プール、ラージプール、Javaプール、REDOログバッファなどがあります。

その中でDBバッファキャッシュの縮小余地を検討する場合、まず確認したいのが、

どのテーブルやインデックスのブロックが、バッファキャッシュ上にどの程度存在しているか

という内訳です。

オンプレミスではX$BHを参照できる

オンプレミスOracleでは、DBバッファキャッシュの内部状態を詳しく調べるために、X$BHを参照する方法があります。

X$BHは、一般的なアプリケーション表や通常のデータディクショナリビューではありません。

Oracleが内部的に管理しているバッファヘッダーの情報を参照するための固定表です。

どのデータオブジェクトのブロックがバッファキャッシュ上に存在するかだけでなく、LRU_FLAGやTCHなど、バッファの利用状況を分析するための詳細な情報も保持しています。

例えば、TCHはバッファへのアクセス状況を調べる際に利用される情報です。

Oracle公式ドキュメントでは、X$BH.TCHはバッファのタッチカウントとして説明されており、値が高いブロックはホットブロックの候補になるとされています。

一般的には、次のような流れで調査します。

1. SGAとPGAの使用状況を確認する

2. DBバッファキャッシュがSGA内で占める容量を確認する

3. X$BHとDBA_OBJECTSを結合する

4. オブジェクトごとのキャッシュブロック数を集計する

5. キャッシュ上で大きな割合を占めるテーブルやインデックスを確認する

6. SQL、実行計画、物理読み込みなどの情報と照合する

重要なのは、特定のオブジェクトが大量にキャッシュされているだけでは、直ちに問題とは判断できないことです。

業務で頻繁に参照されるテーブルであれば、多くのブロックがキャッシュされていること自体は正常です。物理読み込みを減らし、性能向上に寄与している可能性があります。

一方で、利用頻度の低い大規模バッチが大量のブロックを読み込み、オンライン処理で必要なブロックをキャッシュから押し出している場合には、SQLや実行計画を見直す余地があります。

そのため、X$BHの結果だけでチューニングの要否を判断するのではなく、AWR、Statspack、SQL統計、待機イベント、実行計画などと組み合わせて評価する必要があります。

同じSQLをRDSで実行するとORA-00942になる

オンプレミスで使用しているX$BH参照SQLを、そのままRDS for Oracleのマスターユーザーで実行すると、次のエラーが発生します。

ORA-00942: table or view does not exist

このエラーだけでは、対象オブジェクトが存在しないのか、実行ユーザーに参照権限がないのかを判別できません。

Oracleでは、存在する表やビューであっても、実行ユーザーに必要なアクセス権限がない場合、ORA-00942が返ることがあります。

そのため、最初に考えられるのは、マスターユーザーに対する権限不足です。

しかし、X$BHのようなX$固定表は、通常の表やビューと同じ方法で、RDSのマスターユーザーへ参照権限を追加できるオブジェクトではありません。

AWSの公式ドキュメントでは、SYS.X$固定表はSYSだけが直接アクセスできる内部システムオブジェクトとして扱われています。通常のRDS for OracleではSYSとしてログインできないため、マスターユーザーに通常のGRANTを追加し、オンプレミスと同じ参照方法を再現することはできません。

RDSのマスターユーザーはSYSDBAではない

RDS for OracleのDBインスタンスを作成すると、マスターユーザーにはDBA権限が付与されます。

ただし、オンプレミスでSYSDBA権限を持つユーザーと、完全に同じ操作ができるわけではありません。

通常のRDS for Oracleでは、利用者はSYS、SYSTEMなど、Oracleがあらかじめ用意している管理ユーザーを使用できません。また、マスターユーザーにSYSDBA権限を付与することもできません。

Amazon RDSはマネージドサービスです。

バックアップ、パッチ適用、障害復旧、基盤監視などの一部をAWSが管理する代わりに、利用者が実行できるデータベース管理操作には一定の制限があります。

そのため、マスターユーザーにDBA権限が与えられていても、すべてのシステム権限やOracle内部オブジェクトへのアクセスが許可されるわけではありません。

今回参照しようとしているX$BHは、SYSだけが直接アクセスできるOracle内部の固定表です。

オンプレミスでSYSまたはSYSDBA権限を持つユーザーから参照できていても、RDSのマスターユーザーから同じ名前で直接参照することはできません。

grant_sys_objectでも何でも参照できるわけではない

RDS for Oracleでは、SYSが所有する一部のオブジェクトについて、次のRDS管理パッケージを使用し、別のデータベースユーザーへ権限を付与できます。

rdsadmin.rdsadmin_util.grant_sys_object

例えば、SYSが所有するデータディクショナリビューやパッケージに対して、SELECT権限やEXECUTE権限を付与する際に利用します。

ただし、このプロシージャを使用すれば、すべてのSYSオブジェクトへ自由にアクセスできるわけではありません。

grant_sys_objectで付与できるのは、マスターユーザー自身がロールまたは直接付与によって保持している権限に限られます。

マスターユーザー自身が持っていない権限を、このプロシージャによって新たに作り出すことはできません。

したがって、マスターユーザー自身がSYS.X$BHを直接参照できない環境では、grant_sys_objectを使って他のユーザーへX$BHの参照権限を付与することもできません。

オンプレミスで使用しているSQLがRDSで実行できなかった場合、

権限が足りない
　↓
GRANTを追加する
　↓
解決する

という単純な流れでは解決できないことがあります。

RDSで許可されている機能の中から、調査目的を満たせる別のビューや、RDS固有の管理プロシージャを探す必要があります。

現在はSYS.RDS_X$BHを作成できる

現在のRDS for Oracleには、対象となるX$固定表を基に、SYS.RDS_X$ビューを作成する仕組みがあります。

対応環境では、次のプロシージャを実行することで、RDS_X$ビューの作成対象として認められているX$固定表を確認できます。

SELECT *
FROM TABLE(
    rdsadmin.rdsadmin_util.list_allowed_sys_x$_views
);

実際に利用する際は、対象環境でこのプロシージャを実行し、その時点の一覧にX$BHが含まれていることを確認します。

対象として表示された環境では、次のプロシージャによって、X$BHを基にしたRDS_X$ビューを作成できます。

EXEC rdsadmin.rdsadmin_util.create_sys_x$_view('X$BH');

作成されるビュー名は、元のX$固定表名にRDS_が付いた形式です。

SYS.RDS_X$BH

作成されたRDS_X$ビューに対しては、マスターユーザーへSELECT WITH GRANT OPTIONが付与されます。必要に応じて、マスターユーザーから別のデータベースユーザーへ参照権限を付与できます。

RDS_X$ビューを利用できる環境

AWSの公式ドキュメントでは、RDS_X$ビューを利用できる環境として、次の条件が示されています。

• 一度もアップグレードされていない既存DBインスタンスで、19cまたは21cの2023年10月以降の対象リリースを使用している

• 新規に作成したDBインスタンス

• エンジンをアップグレードした既存DBインスタンス

一度もアップグレードされていない既存インスタンスでは、19cは19.0.0.0.ru-2023-10.rur-2023-10.r1以降、21cは21.0.0.0.ru-2023-10.rur-2023-10.r1以降が対象として示されています。

ただし、利用条件や作成対象となるX$固定表は、今後変更される可能性があります。

実際に使用する際は、記事に記載されたバージョン情報だけで判断せず、次の2点を確認する必要があります。

• 最新のAWS公式ドキュメントを確認する

• 対象環境でlist_allowed_sys_x$_viewsを実行する

RDS_X$ビューを本番で使う場合の注意点

RDS_X$ビューを作成できるからといって、通常のデータディクショナリビューと同じ感覚で使用してよいわけではありません。

RDS_X$ビューの基になっているX$固定表は、Oracleの内部システムオブジェクトです。その構造や動作は、一般的な公開インターフェースとして保証されていません。

AWSは、特定のRDS_X$ビューを非本番環境で検証し、本番環境ではOracle Supportのガイダンスの下で作成することを推奨しています。

また、X$固定表の構造は、エンジンアップグレードの前後で同じであることが保証されていません。

RDS for Oracleでは、エンジンアップグレード時に既存のRDS_X$ビューが削除され、アップグレード後のX$固定表を基に再作成されます。その後、マスターユーザーにはSELECT WITH GRANT OPTIONが再び付与されます。

ただし、マスターユーザー以外のデータベースユーザーへ付与していた権限は、自動的には復元されません。アップグレード後に、必要なユーザーへ権限を再付与する必要があります。

RDS_X$ビューを監視や定期調査へ組み込む場合は、次の点を運用設計へ反映します。

• 対象のX$固定表が作成対象に含まれているか確認する

• 非本番環境でSQLの動作と負荷を検証する

• エンジンアップグレード後にビューの状態を確認する

• マスターユーザー以外へ付与した権限を再設定する

• アップグレード後も必要な列が存在するか確認する

• 列構造や挙動を公開仕様として前提にしない

RDS_X$BHを作成すれば、対象環境においてLRU_FLAGやTCHなど、V$BHでは確認できない情報を参照できる可能性があります。

ただし、X$固定表の列構造は公開仕様ではありません。特定の列が将来にわたって同じ形で存在することを前提にした監視や運用は避けるべきです。

X$BHを調査する3つの方法

RDS for OracleにおけるX$BHの扱いは、次のように整理できます。

したがって、現在のRDS for Oracleについては、次のように理解する必要があります。

通常のRDS for Oracleでは、SYS.X$BHを直接参照できない。ただし、対応環境ではSYS.RDS_X$BHを作成できる。

「SYS.X$BHを直接参照できないこと」と、「X$BHを基にした情報を一切取得できないこと」は同じではありません。

それでもV$BHを知っておく理由

ここで一つ疑問が出てきます。

RDS_X$BHを作成し、対象環境でLRU_FLAGやTCHなどの必要な列を参照できるのであれば、V$BHを使った代替調査は不要ではないか、という疑問です。

しかし、必ずしもそうとは限りません。

RDS_X$BHは、Oracle内部の非公開オブジェクトを基にしたビューです。

作成対象となるX$固定表や列構造、アップグレード後の互換性を、公開仕様として前提にすることはできません。

また、本番環境で利用する前に、非本番環境での検証やOracle Supportへの確認が推奨されています。

一方、V$BHはOracleの公式リファレンスに記載された動的パフォーマンスビューです。

V$BHからは、バッファの状態、ファイル番号、ブロック番号、データオブジェクト番号、表領域番号などを取得できます。

必要な参照権限を持つユーザーであれば、RDS_X$ビューを新たに作成せずに利用できます。

そのため、今回のように、

バッファキャッシュ上に、どのオブジェクトのブロックが何件存在するか確認したい

という目的であれば、まずV$BHで必要な情報を取得できるか検討するのが現実的です。

V$BHでは不足する情報があり、LRU_FLAGやTCHなどX$BH固有の情報が調査上どうしても必要になった場合に、RDS_X$BHの作成を検討するという順序が考えられます。

ただし、V$BHはX$BHの完全な代替ではありません。

V$BHから取得できる情報と取得できない情報を区別し、調査目的に応じて使い分ける必要があります。

同じOracleでも運用方法まで同じとは限らない

今回の事例で重要なのは、X$BHという一つの内部表を参照できるかどうかだけではありません。

RDS for Oracleでは、Oracle Databaseという同じエンジンを使用していても、管理権限や調査方法までオンプレミスと同じになるわけではありません。

移行前には、アプリケーションのSQLや接続方式だけでなく、次のようなDBA運用についても確認する必要があります。

• 性能問題が起きた際に必要な情報を取得できるか

• 障害解析で利用しているビューやパッケージを参照できるか

• SYSDBAを前提とした運用手順が残っていないか

• Oracle内部表に依存した監視や調査を行っていないか

• RDS固有のプロシージャで代替できるか

• 代替した場合に取得できなくなる情報はないか

• 本番環境で使用する前に非本番環境で検証できるか

• エンジンアップグレード後も同じ手順を利用できるか

• アップグレード時に再設定が必要な権限はないか

オンプレミスの運用手順書に記載されたSQLを、そのままRDSへ移植するだけでは不十分です。

重要なのは、既存のコマンドをそのまま再現することではありません。

そのSQLを何のために実行しているのかを整理し、RDSで利用可能な手段によって同じ調査目的を満たせるか検証することです。

今回の目的は、DBバッファキャッシュ上に存在するオブジェクトと、そのキャッシュブロック数を把握することでした。

この目的に限定すれば、Oracleが公開している動的パフォーマンスビューV$BHを使って調査する方法があります。

一方、V$BHでは、X$BHが持つすべての内部情報を確認できるわけではありません。LRU_FLAGやTCHなど、V$BHからは取得できない情報もあります。

V$BHを使ってオブジェクトごとのキャッシュ量を確認するSQLと、X$BHから置き換える際の注意点については、以下の記事で詳しく解説しています。

【RDS for Oracle】V$BHでバッファキャッシュの内訳を調査する｜X$BHの代替方法

RDS for OracleでV$BHを使い、オブジェクト別のバッファキャッシュ量を調査する方法を解説。DATA_OBJECT_IDを使ったSQL、X$BHとの違い、結果の見方と実行時の注意点を整理します。

sys-univ.com

2026.07.13

まとめ

通常のRDS for Oracleでは、SYSまたはSYSTEMとしてログインできず、SYSDBA権限も使用できません。

そのため、オンプレミスと同じ方法でSYS.X$BHを直接参照することはできません。

ただし、現在のRDS for Oracleでは、対応する環境であれば、次のプロシージャを使用してSYS.RDS_X$BHビューを作成できます。

EXEC rdsadmin.rdsadmin_util.create_sys_x$_view('X$BH');

したがって、RDS for OracleにおけるX$BHの利用については、次の3点を区別する必要があります。

• SYS.X$BHを直接参照できるか

• SYS.RDS_X$BHを作成できる環境か

• V$BHで調査目的を代替できるか

RDS_X$BHを利用できる環境であっても、X$固定表はOracle内部の非公開オブジェクトです。

本番環境へ導入する際は、非本番環境での検証、エンジンアップグレード後の確認、他ユーザーへの権限再付与などを考慮する必要があります。

RDS移行では、データベースエンジンが同じであっても、オンプレミスと同じDBA権限や調査方法が提供されるとは限りません。

アプリケーションの互換性だけでなく、性能調査や障害解析を含む運用手順についても、移行前のPoCで確認しておく必要があります。

Oracle Databaseを19cへ更改した後、最初の年次処理を終えた直後から、一部SQLの性能が急激に悪化し、夜間バッチの処理時間へ影響が及びました。

SQLもアプリケーションも変えていません。統計収集ジョブも実行していません。それにもかかわらず、実行計画だけが変わっていました。

原因は、Oracle 19cで追加された、パーティションメンテナンス時に統計情報が更新される仕様でした。従来から実施していたパーティション削除を契機として表統計の一部だけが更新され、実行計画が変化した結果、SQL性能が悪化していました。

この障害の本質は、Oracleの仕様そのものではありません。非互換情報の確認だけでは捉えられない「新機能による内部動作の変更」が、更改時の影響調査から漏れていたことです。同じ構図の見落としは、OracleでもAWSでもLinuxでも起こり得ます。

本記事では、この事例を題材に、原因調査で確認した証跡、対策の設計判断、更改プロジェクトとして追加すべき影響調査と試験の観点を整理します。

発端は更改後最初の年次処理だった

ある基幹システムでは、Oracle Databaseの更改後、最初の年次処理として保存期間を超えたデータをパーティション削除で整理していました。旧環境から長年継続している定期メンテナンスで、SQL、アプリケーション、運用手順のいずれにも性能へ影響するような変更は加えていません。

年次処理が終了した直後から、一部SQLの応答が悪化し始めました。

最初に疑ったのは、アプリケーション側の変更です。変更履歴を確認しても、性能劣化につながる修正は見つかりません。次に疑ったのは統計情報ですが、運用担当者が対象表へ統計収集を実行した記録もありませんでした。

処理内容もSQLも統計収集も、利用者側は何も変えていない。それでも更改後の環境では、SQLの性能特性だけが変わっていました。

この時点で、利用者側の変更を探す調査は行き詰まりました。残る可能性は、旧バージョンと19cの間で、Oracle内部の動作そのものが変わっていることです。調査の焦点を、アプリケーションからOracleの内部動作へ切り替えました。

Oracle 19cへの更改で顕在化した統計情報の更新

調査を進めた結果、パーティションメンテナンス時にOracleが統計情報を更新する動作が関係していることが分かりました。

この動作は、My Oracle Supportの次の文書でも、Oracle Database 19cにおけるパーティション表の統計情報変更として整理されています。

Partitioned Table Statistics Changed After Truncate Partition or Drop Partition Operation
MOS Doc ID 2970098.1

Oracle Database 19cのSQL Tuning Guideにも、パーティションメンテナンスに伴う統計情報の処理が「Online Statistics Gathering for Partition Maintenance Operations」として記載されています。

ここで区別しなければならないのは、すべてのパーティション操作で同じ統計収集処理が実行されるわけではないことです。

パーティションメンテナンスには、次のような操作があります。

• DROP PARTITION
• TRUNCATE PARTITION
• MOVE PARTITION
• MERGE PARTITION
• COALESCE PARTITION
• SPLIT PARTITION

MOVE PARTITIONやMERGE PARTITIONなど、データの移動やダイレクトパス書き込みを伴う処理では、操作内容に応じてオンライン統計収集が行われる場合があります。

本事例で問題となったDROP PARTITIONでは、DBMS_STATS.GATHER_TABLE_STATSに相当する全統計収集が実行されたわけではありません。パーティション削除に合わせて、グローバル表統計のNUM_ROWSやBLOCKSなどがOracle内部で更新されました。

運用担当者が統計収集ジョブを実行していなくても、統計情報の一部はパーティション操作によって変化します。

「統計情報を収集していない」という運用上の認識と、「統計情報が変化していない」というデータベース上の事実は同じではありません。

この違いを認識していなければ、性能劣化の調査でアプリケーション、SQL、負荷状況だけを追い続け、実行計画を変化させた統計情報の更新を見落とすことになります。

なぜデータを削除した後にSQLが遅くなるのか

この動作は旧環境では発生しておらず、19cへの更改後に初めて顕在化しました。

データを削除すれば処理対象が減るため、SQLも速くなるように思えます。

今回の事象では、パーティション削除後にSQL性能が悪化しました。

原因を理解するには、Oracleのオプティマイザが利用する統計情報を、表統計とカラム統計に分けて考える必要があります。

表統計には、表全体の規模を示す情報が含まれます。代表的な項目はNUM_ROWS、BLOCKS、AVG_ROW_LENです。

カラム統計には、列の値がどのように分布しているかを示す情報が含まれます。代表的な項目には、個別値数を示すNDV、LOW_VALUE、HIGH_VALUE、NULL数、ヒストグラムなどがあります。

DROP PARTITIONを実行すると、削除されたパーティションを反映して、表全体の行数やブロック数を示す統計が更新されます。カラム統計やヒストグラムまで、同じタイミングで整合した状態へ再収集されるわけではありません。

この状態では、オプティマイザが参照する統計情報に異なる時点の情報が混在します。

表統計は、パーティション削除後の表が以前より小さくなったことを示しています。カラム統計は、削除前の値分布を前提とした状態で残っています。

オプティマイザは、表統計とカラム統計を使って、検索条件へ該当する行数を推定します。両者の前提が一致していなければ、カーディナリティ推定が実際のデータ分布から外れる可能性があります。

カーディナリティ推定が変わると、索引を使うか全表走査を選ぶか、Nested LoopsとHash Joinのどちらを使うか、どの表を駆動表とするかといった判断も変わります。結合順序や並列実行の選択まで変化することがあります。

本件では、統計情報が更新されたという事実だけで性能が悪化したのではありません。

表統計の一部だけが更新され、既存のカラム統計との前提が一致しない状態が次回の統計収集まで残った結果、カーディナリティ推定が変化し、従来とは異なる実行計画が選択されました。

たとえば本件では、パーティション削除後にNUM_ROWSが大幅に減少した統計を基に、オプティマイザが従来とは異なるアクセスパスを選択したと推定されます。統計上は小さく見える表に対してIndex Range ScanよりFull Table Scanのコストが低いと判断されたり、結合方式がNested LoopsからHash Joinへ変わったりすることで、実業務データの実際の件数との乖離が性能劣化として現れます。

統計情報の更新は、常に性能改善を意味するものではありません。どの統計が、どの単位で、どの範囲まで更新されたのかを確認しなければ、オプティマイザが参照している情報の状態を正しく把握できません。

調査で確認した証跡

性能障害を説明するには、「パーティションを削除した」「統計情報が変わった」「SQLが遅くなった」という個別の事実だけでは十分ではありません。

重要なのは、それらの出来事が同じ時間軸で発生していることを確認することです。

今回の調査では、AWR、実行計画、統計情報の更新時刻を組み合わせ、原因と結果を時系列で整理しました。

AWRでSQL性能の変化を確認する

最初に確認したのは、AWRに記録されたSQL性能の変化です。

年次処理の終了後から対象SQLの負荷が増加しており、単純に実行回数が増えたのではなく、1回当たりの処理コストそのものが悪化していました。

主に確認した項目は次のとおりです。

• Elapsed Time
• CPU Time
• Buffer Gets
• Disk Reads
• Executions
• Rows Processed

これらは合計値だけでは判断できません。

たとえばElapsed Timeが増加していても、単純に実行回数が増えただけであれば異常とは言えません。

• 1実行当たりのElapsed Time
• 1実行当たりのBuffer Gets

まで確認し、SQLそのものの性能が変化したことを確認しました。

実行計画が変わっていないかを確認する

次に確認したのは実行計画です。

AWRやDBA_HIST_SQLSTAT、DBA_HIST_SQL_PLANを調査すると、対象SQLでは性能悪化前後でPLAN_HASH_VALUEが変化していました。

PLAN_HASH_VALUEが変わるということは、少なくともOracleが異なる実行計画を選択したことを意味します。

もちろん、PLAN_HASH_VALUEだけでは原因を断定できません。

実際には、

• アクセスパス
• 結合方式
• 結合順序
• 推定行数（Cardinality）
• 実際の処理行数

まで確認し、オプティマイザがどの判断を変更したのかを追跡しました。

統計情報はいつ変わったのか

最後に、統計情報そのものを確認しました。

DBA_TAB_STATISTICSを見ると、パーティション削除を実施した時刻を境に、対象表の統計情報が更新されていました。

確認した主な項目は次の三つです。

• NUM_ROWS
• BLOCKS
• LAST_ANALYZED

運用では統計収集ジョブを実行していないにもかかわらず、これらの値はパーティション削除のタイミングで変化していました。

さらに、DBA_TAB_COL_STATISTICSやヒストグラム関連ビューも確認したところ、カラム統計は従来の状態を保持していました。

• 表統計は更新されている
• カラム統計は更新されていない

という状態になっていたことが分かります。

この結果は、前章で説明した「表統計とカラム統計の前提が一致しない状態」が実際に発生していたことを裏付ける証拠となりました。

時系列で整理すると原因が見えてくる

今回の調査結果を時系列で整理すると、次の流れになります。

年次処理でDROP PARTITION
        ↓
Oracle内部で表統計の一部が更新
        ↓
表統計とカラム統計の前提が一致しない
        ↓
オプティマイザのカーディナリティ推定が変化
        ↓
実行計画が変更される
        ↓
PLAN_HASH_VALUEの変化として観測される
        ↓
Elapsed Time・Buffer Getsが増加

この流れは、一つのビューだけを見て導いたものではありません。

パーティション操作の実施時刻、統計情報の更新時刻、実行計画の変化、AWRに記録された性能指標を同じ時間軸へ並べることで、初めて因果関係を説明できます。

性能障害の調査では、「実行計画が変わった」「統計情報が更新された」という個別の事実だけを示しても説得力はありません。

複数の証跡を時系列で結び付けて初めて、性能劣化の原因を論理的に説明できます。

問題はOracleではなく影響調査の範囲だった

Oracleは仕様どおりに動作していました。

本件の問題は、パーティションメンテナンスに伴う統計情報の更新を、更改時の影響調査対象として認識できていなかったことです。

システム更改では、多くの場合、次のような項目を重点的に確認します。

• 非互換情報
• 廃止機能
• Deprecated機能
• 初期化パラメータの変更
• サポート終了機能
• 既知の不具合
• SQL構文やAPIの変更

これらは重要な確認項目です。

新機能については「追加機能だから既存システムには影響しないだろう」と判断され、調査対象から外れてしまうことがあります。

今回見落としていたのは、「従来のSQLが実行できなくなる非互換」ではありませんでした。

従来と同じSQLが正常終了したまま、Oracle内部の統計情報管理だけが変わる仕様変更です。

このような仕様変更は、機能試験だけでは見つかりません。

SQLは正常終了し、処理結果も正しく、エラーログも出力されません。

実行計画や統計情報まで確認して初めて、旧バージョンとの違いが見えてきます。

更改プロジェクトでは「新機能だから影響はない」と考えるのではなく、既存処理の内部動作を変える仕様変更はないかという観点で調査することが重要になります。

このような影響調査は、構築フェーズに入ってから始めるものではありません。クラウドリフトでは、PoCや基本設計の段階で「何を調査対象に含めるか」が品質を大きく左右します。

設計前に確認すべき観点は、次の記事で詳しく解説しています。

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

クラウド移行（AWSへのクラウドリフト）で起きる手戻り・コスト超過・納期遅延は、構築中ではなくPoC不足から始まります。Auto Scaling、EFS/EBS、RDS、監視、バックアップ、ライセンスなど10の設計リスクを現場目線で整理します。

sys-univ.com

2026.07.20

技術的な対策は一つではない

本件のような事象に対して、「統計情報の更新を止めればよい」と考えるのは適切ではありません。

問題は、パーティション削除そのものではなく、統計情報の状態が変化した結果として実行計画が変わることです。

更改設計では

• 統計情報をどのように管理するか
• 実行計画の変化をどこまで許容するか
• 運用でどこまで吸収するか

という三つの観点から設計する必要があります。

パーティションメンテナンス後に統計情報を再収集する

最も直接的な方法は、パーティション削除後にDBMS_STATS.GATHER_TABLE_STATSを実行し、表統計とカラム統計を同じ状態へ揃えることです。

今回の事象では、表統計だけが更新され、カラム統計との前提が一致しない状態が残ったことが実行計画変更の要因でした。

統計情報を再収集すれば、この不整合は解消されます。

統計情報を取得すれば必ず性能が改善するとは限りません。

表全体を再収集するのか、対象パーティションだけで十分なのか、インクリメンタル統計を利用するのかなど、システム特性に応じた設計は必要になります。

重要なのは、「統計情報が更新されたこと」ではなく、「統計情報の整合性をどのように維持するか」という観点で設計することです。

実行計画そのものを安定させる

統計情報を適切に管理しても、データ量や分布は時間とともに変化します。

業務影響が極めて大きいSQLについては、統計情報だけに依存せず、SQL Plan Baselineなどを利用して実行計画を管理する方法もあります。

SQL Plan Baselineは、統計情報の変化そのものを止める機能ではありません。

その代わり、十分に検証された実行計画を維持することで、予期しない計画変更による性能劣化を防ぐ役割を持ちます。

すべてのSQLを固定する運用は現実的ではありません。

長時間バッチや業務影響の大きいSQLなど、対象を限定して利用することが重要です。

Oracle内部動作を変更する方法もある

Oracleには、オンライン統計収集の動作そのものを抑止する方法も存在します。

SQL単位で抑止するのであれば、公式ドキュメントに記載されているNO_GATHER_OPTIMIZER_STATISTICSヒントが利用できます。影響範囲を特定のSQLへ限定できるため、対象処理が明確な場合には検討しやすい選択肢です。

データベース全体で抑止する方法としては、隠しパラメータである_optimizer_gather_stats_on_loadが公開されている技術情報でも言及されています。ただし、このパラメータはパーティションメンテナンス時の統計更新だけではなく、ダイレクトパスロード時を含むオンライン統計収集全体へ影響します。

隠しパラメータは、公開パラメータと同じ感覚で変更できるものではありません。バージョンやRelease Updateによって挙動が異なる可能性があり、適用の可否は自環境の構成を踏まえてOracle Supportへ確認した上で判断すべきです。

今回の事象だけを止めたつもりでも、別のバルクロード処理へ新たな影響を与えることも考えられます。抑止は最初に選ぶ対策ではなく、統計の再収集や実行計画の管理で解決できない場合の最後の選択肢として、影響範囲を十分に評価して使うべきものです。

更改設計として考えるべきこと

この事例で重要なのは、「どの対策が正しいか」を決めることではありません。

最適解はシステムによって異なることに対し、どのようなシステムでも共通する考え方があります。

パーティションメンテナンスによって統計情報が変化するのであれば、その変化を前提とした運用を設計することです。

統計情報を再収集するのか、SQL Plan Baselineで重要SQLを保護するのか、あるいはOracle内部動作まで変更するのか。

その判断は、性能要件、バッチ時間、データ量、運用体制まで含めたシステム設計として決めるべき事項です。

更改プロジェクトで追加すべき試験と運用

今回の教訓は、Oracleのチューニングだけでは終わりません。

本質的な問題は、更改プロジェクトの影響調査にありました。

多くの更改プロジェクトでは、オンライン処理や通常の日次バッチを中心に性能試験を実施します。

年次や月次にしか実行されない処理は、試験対象から外れることがあります。

パーティション削除や履歴データの整理、大量データのアーカイブなどは、その代表例です。

こうした処理は実行頻度が低いため、問題があっても更改直後には表面化しません。

今回のように、更改後最初の年次処理で初めて障害として顕在化することがあります。

更改試験では、本番データを完全に再現できないことも少なくありません。

その場合でも、DDLの実行、統計情報の変化、実行計画の変化までは十分検証できます。

さらに、更改後最初の年次処理や月次処理は通常運用として扱うのではなく、重点監視期間として計画しておくことが重要です。

SQLの実行時間だけを見るのではなく、PLAN_HASH_VALUE、統計情報の更新時刻、AWRの性能指標をあらかじめ比較できる状態にしておけば、異常が発生しても原因へたどり着くまでの時間を大幅に短縮できます。

性能障害は、発生してから調査を始めるよりも、比較するための基準値を更改前から残しておく方がはるかに効率的です。

PoCでは性能確認だけではなく、「更改後に何を比較するか」という観点で証跡を残しておくことが重要です。

PoCで確認すべき項目は、次の記事で詳しく整理しています。

【第2部・前編】クラウドリフトPoCで「動いた」は確認できた。しかし業務では使えなかった｜10の設計リスク① 可用性・性能・ストレージ・バックアップ・監視

PoCで「動いた」は確認できた。しかし構築フェーズで業務が回らなかった。可用性・性能・ストレージ・バックアップ・監視の5領域で、見落とすと手戻りになる設計リスクを整理します。

sys-univ.com

2026.06.19

非互換情報の外側にある変更を見る

この事例は、Oracle Databaseだけに当てはまる話ではありません。

システム基盤の更改では、新しいバージョンへ移行するたびに、ベンダーは性能、運用性、セキュリティ、自動化を目的として既定動作を見直しています。

たとえばAmazon RDSでは、エンジンのバージョンアップに伴って、デフォルトパラメータグループの既定値が変更されることがあります。アプリケーションを変更していなくても、データベース側の既定設定が変われば、性能や動作特性へ影響する可能性があります。

VMware vSphereでも同様です。バージョンアップに伴ってTLSの既定設定が変更され、従来は接続できていた外部システムとの通信へ影響した事例があります。システムが故障したわけではなく、製品側の既定動作が変わったことが原因でした。

Linuxでも、カーネル更新によってメモリ管理やネットワーク関連の既定動作が変更されることがあります。アプリケーションは従来どおり動作していても、OSの内部動作が変わることで性能特性が変化するケースは珍しくありません。

これらに共通しているのは、「何も変更していないのに動作が変わった」のではないという点です。

利用者は変更していなくても、ベンダーは変更しています。

更改プロジェクトでは、自分たちが修正したプログラムや設定だけに目が向きがちです。

実際には、ベンダーが変更した既定動作の方が、既存システムへ大きな影響を与えることがあります。

更改影響調査では「非互換情報」だけを見るのではなく、「既定動作は変わっていないか」という視点を同じ重みで持つ必要があります。

本記事のように、更改後に初めて表面化した仕様変更や設計上の見落としは少なくありません。

クラウドリフトやシステム更改で実際に発生したトラブル事例は、次のマガジンにまとめています。

クラウド移行でハマる、AWS設計・運用の落とし穴｜ナギ ＠ 氷河期SEの知見録｜note

AWSへのクラウド移行やDR設計で見落としやすい、設計・起動・再作成・運用の落とし穴を整理するマガジンです。 EC2、AMI、cloud-init、EC2Launch、Auto Scaling、EBS、CloudWatch Logs、S3、AWS Backupなどを題材に、「サーバは起動したのに使えない」「設定したはReadMore...

note.com

まとめ

今回の性能障害では、年次処理によるパーティション削除を契機として、Oracle内部で表統計の一部が更新されました。

表統計だけが新しい状態となり、カラム統計との前提が一致しない状態が残った結果、オプティマイザのカーディナリティ推定が変化し、実行計画も変わりました。その結果として、SQL性能が低下しました。

原因を特定できたのは、一つの情報だけを見て判断しなかったためです。

AWRで性能変化を確認し、PLAN_HASH_VALUEで実行計画の変化を追跡し、DBA_TAB_STATISTICSで統計情報の更新時刻を確認しました。それぞれを同じ時間軸へ並べることで、初めて原因と結果を論理的に説明できました。

Oracleは仕様どおりに動作していました。

問題だったのは、パーティション削除に伴う統計情報の更新という仕様変更が、更改時の影響調査対象になっていなかったことです。

更改プロジェクトで確認すべき対象は、非互換情報だけではありません。

新機能、デフォルト設定、バックグラウンド処理、内部アルゴリズムなど、既存システムへ影響を与える可能性のある仕様変更まで含めて評価する必要があります。

システム更改では、「正常終了した」ことだけでは十分とは言えません。

同じSQLが正常終了していても、実行計画や性能特性まで従来と同じとは限りません。

更改で本当に確認すべきなのは、プログラムが動くかではありません。

設計時に置いていた前提が、バージョンアップ後も成立しているかです。

システム更改の品質を左右するのは、コード変更量ではなく、前提条件の変化をどこまで洗い出せるかです。

参考資料

• Oracle Support, Partitioned Table Statistics Changed After Truncate Partition or Drop Partition Operation（MOS Doc ID 2970098.1）
• Oracle Database 19c SQL Tuning Guide（SQL Plan Management）
• Oracle Database 19c PL/SQL Packages and Types Reference（DBMS_STATS）
• Amazon RDS User Guide(DB parameter groups)
• VMware vSphere 8 Release Notes(Security and TLS changes)

クラウドリフトでは、こうしたことが実際に起こります。

クラウドリフトは、既存システムを大きく変更せずに移す、クラウド移行の代表的な方式です。PoCや事前検証が不十分なまま進めると、本番移行後だけでなく、構築中から問題が表面化します。

性能が出ない。別AZでEC2を起動したのに、OS内のルート情報が原因で通信できない。Auto ScalingでEC2は再作成されたのに、監視やジョブ実行対象として認識されない。EFSで共有ファイルを読み書きできたのに、複数サーバからのファイル更新や差し替えで想定外の挙動が出る。

こうしたトラブルは、現場では「個別の設定ミス」や「確認不足」として見えます。

しかし、プロジェクト全体で振り返ると、共通する原因が見えてきます。

クラウドリフトの失敗は、構築前に始まっている。

トラブルが表面化するのは、EC2にログインできなくなった時、RDSの制約に気づいた時、性能試験で想定したスループットが出なかった時です。

実際には、もっと前から始まっていることが多いです。PoCで確認すべきことを確認しないまま基本設計へ進む。クラウド上で成立するか分からない処理方式を、オンプレ時代の感覚で決める。AWSサービスの仕様、制約、課金体系、運用モデルを十分に確認しないまま、構築と試験へ進む。

その積み重ねが、クラウド移行の後工程で、一つひとつ障害として表面化します。

※この記事は、AWSへのクラウドリフトPoCについて整理する全3部作の第1部です。

これまでの記事では、クラウドリフトが必要になる背景や、AWS移行で起きやすい個別トラブルを扱ってきました。
今回からは、その個別トラブルを「PoCで事前に潰すべき設計リスク」として整理していきます。

• 第1部：技術トラブルがなぜ手戻り・コスト超過・納期遅延につながるのか、その「失敗の構造」を整理します
• 第2部：PoCで見るべき10の設計リスクを整理します
• 第3部：PoC結果を設計・試験・運用・見積へどう反映するかを整理します

この記事で分かること

クラウドリフトで発生するトラブルを、単なる個別事象としてではなく、PoC不足によって残った設計リスクとして整理します。ポイントは次の3つです。

• クラウドリフトのトラブルは、構築中に突然始まるわけではない
• 多くの場合、構築前に確認すべき設計リスクが残っている
• PoCは「試しに動かすこと」ではなく、後工程の手戻りを防ぐための設計判断材料である

なぜクラウドリフトの失敗が「構築前」に始まっているのかを、以下で説明します。

クラウドリフトのトラブルは「個別事象」に見える

クラウドリフトでは、さまざまなトラブルが発生します。

たとえば、これまでの記事でも以下のようなテーマを扱ってきました。

• アクセス・起動：AMIから起動したEC2でSSHログインできない
• AZ障害・復旧：別AZで起動したWindowsが、OS内のルート情報により通信できない
• 可用性：Auto ScalingでEC2は再作成されたが、業務復旧まで到達しない
• 運用・ログ：CloudWatch LogsのS3エクスポートが想定通り動かない
• バックアップ：AWS Backupの「5日保存」を「5営業日保存」と誤解する
• ストレージ：EBSは容量拡張は比較的容易だが、縮小には再作成とデータ移行が必要になる。EFS/EBSの使い分けで性能・復旧方式が変わる
• データベース：RDS for Oracleの制約により、オンプレOracleと同じ運用ができない
• 運用・共通：ジョブ管理や監視方式をクラウド移行後に見直す必要が出る
• ライセンス：Microsoft製品や商用製品は、技術的に動いても、AWS上での利用がライセンスやサポート条件上認められない場合がある
• クラウド責任分界：クラウドがストレージ障害を吸収しても、IaaS/SaaS境界の外側にあるOS領域は利用者側の責任。ログ肥大化によるOS領域枯渇が盲点になる

こうしたトラブルを一つひとつ見ると、個別の設定ミスや確認不足に見えます。

SSHの設定ミス。
OS内部のルート情報の見落とし。
cloud-init の理解不足。
バックアップ保持期間の確認不足。
ストレージ方式の選定ミス。
監視設計の漏れ。
ライセンス確認の遅れ。

もちろん、それぞれの直接原因はあります。

しかし、クラウドリフト案件として見た場合、これらを単なる個別ミスとして片付けてはいけません。

なぜなら、こうした問題の多くは、構築中に突然発生したのではなく、もっと前の段階で確認すべきことを確認しないまま進んだ結果だからです。

問題の本質はここにあります。

クラウドリフトで発生する個別トラブルの多くは、PoC不足による設計リスクの未解消として説明できる。

個別トラブルに見えるものの正体

クラウドリフトの怖さは、トラブルが発生した瞬間ではありません。

本当に怖いのは、その時点ではすでに設計、構築、試験、運用設計、見積、スケジュールが進んでおり、手戻りが大きくなっていることです。

たとえば、構築フェーズで以下のような問題が分かったとします。

• この運用はAWSではそのままできない
• このミドルウェアはAmazon Linuxでは動かない
• RDS for Oracleでは、オンプレOracleと同じチューニングができない
• EFSの性能では、業務処理のレイテンシ要件を満たせない
• 既存のジョブ管理製品をそのまま使うと、クラウド環境での運用に合わない
• サーバー上のExcel帳票生成が、ライセンスやサポート上の理由でそのまま使えない

この時点で設計を変えようとすると、影響はかなり大きくなります。

設計書を直すだけでは済みません。
構築手順も変わります。
パラメータシートも変わります。
試験項目も変わります。
運用手順も変わります。
顧客説明も必要になります。
場合によっては、見積とスケジュールも変わります。

これがクラウドリフトの手戻りです。

単なる技術トラブルではありません。
プロジェクト全体のQCDを崩す問題になります。

クラウドリフトで崩れるのは技術ではなくQCD

クラウドリフトで発生する問題は、最初は技術課題として見えます。

ログインできない。
通信できない。
性能が出ない。
バックアップが想定通りに戻せない。
監視がうまく飛ばない。
ライセンスが使えない。

しかし、プロジェクトとして見ると、それは技術課題だけでは終わりません。

実際には、次のような形でQCD全体に波及します。

• コスト超過
• スケジュール遅延
• 品質劣化
• 設計手戻り
• 試験やり直し
• 運用設計の再検討
• 顧客説明の増加
• プロジェクトメンバーの疲弊

特に危険なのは、性能、ストレージ、DB、運用方式に関する問題です。

これらは、設定値を少し変えれば解決するとは限りません。

たとえば、PoC不足により、EFSの性能が本番相当負荷で足りないと後から分かったとします。

その場合、単にスループット設定を上げれば済むかもしれません。
しかし、それでも性能目標に届かない場合は、ファイル配置や処理方式そのものを見直す必要が出ます。

EFSを使う前提だったものを、EC2＋EBS構成に変える。
共有ファイルの扱いを変える。
アプリケーションの処理方式を変える。
バックアップ方式を変える。
監視項目を変える。
障害時の復旧手順を変える。
性能試験シナリオを作り直す。

ここまで来ると、もはや一部設定の見直しではありません。

基本設計からの手戻りです。

さらにPM/PLの視点で見ると、影響は技術チームの中だけでは収まりません。

基本設計を直す。
詳細設計を直す。
構築手順を直す。
試験計画を見直す。
性能試験の前提を変える。
運用手順を作り直す。
顧客へ変更理由を説明する。
追加費用とスケジュール延伸を調整する。

この連鎖が発生します。

つまり、クラウドリフトの設計漏れは、技術課題として始まり、最後はQCD課題になります。

これを構築後や試験中に初めて認識するのは、かなり危険です。

AWSではオンプレの設計思想がそのまま通用しない

クラウドリフトは、オンプレのサーバをAWS上のEC2に置き換えるだけの作業ではありません。

ここを誤解すると、設計漏れが増えます。

オンプレ環境では、比較的自由に設計できたものが多くあります。

OS設定。
ミドルウェア設定。
ストレージ構成。
ネットワーク構成。
監視方式。
ジョブ管理。
バックアップ方式。
セキュリティ設定。
HA構成。
運用スクリプト。
商用製品の導入。
ライセンス運用。

もちろん、オンプレにも制約はあります。

しかし、オンプレではサーバ、ストレージ、ネットワーク機器、ミドルウェア、運用製品を組み合わせて、プロジェクト側でかなり細かく作り込めました。

一方、AWSでは違います。

AWSサービスの仕様があります。
マネージドサービスの制約があります。
課金体系があります。
メンテナンスの考え方があります。
責任共有モデルがあります。
IAM、Security Group、CloudWatch、RDS、EFS、EBS、S3など、AWS側の設計思想があります。

つまり、プラットフォームがAWSに変わる以上、『非機能要件の実現手段』は必ず変わります。

正確には、こうです。

オンプレで暗黙的に成立していた設計を、AWSのサービス仕様、制約、課金体系、運用モデルの上で再検証する必要がある。

ここをPoCで確認せずに進めると、後から詰まります。

たとえば、オンプレではサーバが固定されている前提で、監視やジョブ管理を設計していたかもしれません。

しかし、AWSではAuto Scalingや復旧方式によって、EC2が入れ替わる前提になる場合があります。

この時、EC2が起動すれば終わりではありません。

ホスト名はどうするのか。
DNS登録はどうするのか。
監視対象への登録はどうするのか。
ジョブ実行対象としてどう認識させるのか。
ログ出力先はどうするのか。
障害時の運用手順はどう変わるのか。

ここまで確認して初めて、業務復旧と言えます。

EC2が起動しただけでは、業務復旧ではありません。

また、クラウドリフトはクラウドネイティブ化とも違います。

クラウドリフトの目的は、多くの場合、既存システムを大きく作り替えることではありません。
オンプレで動いているシステムを、できるだけ低リスク、低コスト、短期間でクラウド上に移すことです。

そのため、既存の設計思想や運用方式をある程度踏襲することになります。

しかし、ここに難しさがあります。

既存設計を踏襲したい。
でも、AWSではそのまま実現できないことがある。
マネージドサービスを使えば楽になる部分もある。
しかし、既存運用と合わない部分もある。
クラウドネイティブに寄せすぎると、アプリ改修や運用変更が増える。
オンプレ方式を無理に残すと、クラウドの良さを活かせず、コストも運用も重くなる。

このバランスを見極める必要があります。

だからPoCが重要になります。

それでもクラウドリフトは避けにくい

クラウドリフトは難しい。
しかし、避け続けることも難しいのが現実です。

政府系・公共系では、クラウド・バイ・デフォルトの流れがあります。
民間企業でも、データセンター更改、ハードウェアEOL、OS・ミドルウェア保守切れ、オンプレ運用人材の不足、災害対策、拡張性確保、初期投資抑制といった理由から、クラウド利用を検討する場面が増えています。

だからこそ、効率よく、リスクを抑えて進める必要があります。

そのために必要なのは、大きく3つです。

1つ目は、実案件の事例を収集することです。
AWS公式ドキュメントを読むことは大切ですが、それだけでは、既存運用との衝突、ライセンス制約、性能特性、バックアップの戻し方といった落とし穴は見えにくいです。実際に起きたトラブルの事例から学ぶことが重要です。

2つ目は、質の高いPoCを実施することです。
「EC2上でアプリが起動した」で終わるPoCでは、設計リスクは潰せません。本番相当の負荷、障害時の復旧、監視、ジョブ、バックアップまで含めて検証シナリオに落とし込んで初めて、基本設計の判断材料になります。

3つ目は、リフト経験者を含めたチームを作ることです。
基盤SEだけでは業務影響を判断しきれず、業務SEだけではAWSの制約やストレージ、ネットワークの設計リスクを判断しきれません。クラウド有識者、既存システム有識者、業務・アプリ担当、インフラ基盤・処理方式担当を巻き込み、PoCで分かったことを設計、試験、運用、見積へ反映する体制が必要です。

PoCは「試しに動かすこと」ではない

ここまでの話を踏まえると、PoCの意味が少し変わって見えるはずです。

PoCと聞くと、「試しに作ってみる」「動くか確認する」というイメージを持つかもしれません。

もちろん、それも間違いではありません。

しかし、クラウドリフトにおけるPoCをそれだけで捉えると危険です。

PoCで確認するのは、AWSサービスが使えるかどうかだけではありません。

既存業務の処理方式、運用方式、復旧方式、名前解決、バックアップ、監視、ジョブ、ファイル更新方式、DB運用、ライセンス、コストが、クラウド上の構成で成立するか。

そこまで確認して初めて、PoCの結果を基本設計の判断材料にできます。

たとえば、次のような確認だけでは不十分です。

• EC2でアプリケーションが起動した
• EFSでファイルを読み書きできた
• RDSに接続できた
• CloudWatch Logsにログが出た
• AWS Backupのジョブが成功した

これらは大事な確認です。
ただし、それだけでは「業務で使える」とは言えません。

オンプレ時代の検証では、プロトタイプアプリケーションを作り、主要な処理を流して、基盤上でアプリケーションが動くことを確認する、という進め方もありました。

もちろん、それ自体が無意味だったわけではありません。
サーバ、OS、ミドルウェア、ネットワーク、ストレージの基本的な組み合わせを確認するうえでは、有効な検証です。

しかし、クラウドリフトでは、それだけでは足りません。

AWS上でアプリケーションが起動することと、クラウド上の構成で業務が安定して回ることは違います。

EC2が起動しても、ホスト名、DNS登録、監視、ジョブ実行対象、ログ収集先、ミドルウェア起動まで回らなければ、業務復旧とは言えません。

EFSでファイルを読み書きできても、本番相当のファイル数、ディレクトリ構造、排他制御、ファイル差し替え、バックアップ、リストアまで成立しなければ、業務で使えるとは言えません。

CloudWatch Logsにログが出ても、運用で必要なタイミングに確認できるのか、通知すべきアラームと通知抑止すべきメッセージを整理できるのか、試験工程へ監視観点を引き継げるのかを見なければ、運用設計にはつながりません。

バックアップジョブが成功しても、必要なデータを、必要な時間内に、整合性を保って戻せるとは限りません。

つまり、PoCで見るべきなのは、「AWS上でとりあえず動くか」だけではありません。

既存の機能要件・非機能要件・運用要件を、AWS上でどの方式なら現実的に満たせるのか。
既存設計を踏襲するのか。
マネージドサービスに置き換えるのか。
商用製品を継続するのか。
代替製品に変えるのか。
クラウドネイティブなサービスに寄せるのか。

この判断をするためにPoCがあります。

では、具体的に何を判断するのでしょうか。

その構成で基本設計に進んでよいのか。
その運用方式で本番後も回せるのか。
そのサービス仕様で既存要件を満たせるのか。
そのコストでプロジェクト計画に収まるのか。

こうした設計判断に使えるPoCでなければ、後工程の手戻りを防ぐことはできません。

クラウドリフトのPoCは、単なる動作確認ではありません。

基本設計に入る前に、クラウド上で成立する処理方式、構成方式、運用方式、復旧方式、コスト感を見極めるための設計リスク潰しです。

ここが最も重要です。

たとえば、以下のような確認は、単なる動作確認ではありません。

• RDS for Oracleで、既存DBの可用性・性能要件を満たせるか
• EFSで、共有ファイルの性能要件を満たせるか
• AWS Backupで、必要な世代管理とリストア要件を満たせるか
• CloudWatch中心の監視で、既存運用を置き換えられるか
• JP1を継続するのか、ZabbixやHinemosなどに置き換えるのか
• 既存のセキュリティポリシーをAWS上のIAMやSecurity Groupへどう落とすのか
• BYOLかMarketplaceかで、ライセンス費用やサポート条件はどう変わるのか
• RHELを継続するのか、Amazon Linuxへ寄せるのか
• その場合、既存ライブラリや運用スクリプトは動くのか
• 開発環境や試験環境の利用時間増加が、クラウド利用料にどれだけ影響するのか

これらはすべて、後工程で発覚すると危険な設計リスクです。

PoCで潰すべきなのは、こういう論点です。

なぜPoCで気づけなかったのか

クラウドリフトで怖いのは、AWSの機能を知らないことだけではありません。

もっと怖いのは、クラウドリフト固有のリスクを洗い出す機会が、プロジェクト計画の中に十分に組み込まれていないことです。

しかし、実際のプロジェクトではこれが簡単ではありません。

既存システムを、AWSの仕様、制約、課金体系、運用モデルの上に再配置する。

それがクラウドリフトです。

だから、PoCが必要になります。

ただし、PoCだけですべての設計リスクを見つけられるとは限りません。

事前にシナリオを立てても、実際には想定外の問題が出ます。

重要なのは、そこで出た問題を個別対応で終わらせないことです。

なぜ見落としたのか。
どの設計リスクに分類されるのか。
次の工程へ何を引き継ぐべきか。

ここまで整理して初めて、PoCは後工程の手戻りを防ぐ材料になります。

まとめ：失敗はPoC不足から始まる

クラウドリフトでは、オンプレで暗黙的に成立していた設計前提が、AWS上でもそのまま成立するとは限りません。

PoCは「試しに動かすこと」ではありません。
後工程で致命傷になる設計リスクを、構築前に見つけるための作業です。

特に、クラウドリフトPoCでは次のような観点を、単なる確認項目ではなく「手戻りを防ぐための設計リスク」として見ておく必要があります。

1. 可用性・信頼性
2. 性能・キャパシティ
3. ストレージ
4. バックアップ
5. 運用・監視
6. ジョブ管理・アプリ配布
7. セキュリティ・アクセス管理
8. ライセンス・製品サポート
9. DB・OS・ミドルウェア互換性
10. コスト・キャパシティ管理

これらは、確認項目を並べれば終わるものではありません。
後工程で発覚した時に、設計、試験、運用、見積へどう波及するのかまで見ておく必要があります。

クラウドリフトの失敗は、構築前に始まっている。

この10項目については、以下の記事で前編・後編に分けて整理しています。

続く第3部では、PoCの結果を「結果報告」で終わらせず、設計・試験・運用・見積へどう渡すかを整理します。