開発・保守の現場では、技術用語を知っているだけでは対応できない場面が少なくありません。障害が発生したときに何から確認するのか、どのログを見るのか、SQLをどこまで慎重に扱うのか。こうした判断の積み重ねが、仕事の速さと品質を大きく左右します。
新人SEや若手SEのうちは、「分からないことが多すぎて、どこから手を付ければよいか分からない」と感じるのも自然なことです。私自身、銀行システムの開発・保守に25年以上関わってきましたが、現場や技術が変わっても、仕事の土台となる考え方には共通点があると感じています。
この記事では、現場で役立つ開発・保守の基本を、次の5分野に整理して紹介します。
- 障害対応：初動、影響範囲、再発防止
- ログ活用：WebLogic、Oracle、APサーバ
- SQL：SELECT、UPDATE、実行計画
- 設計書：読み方、更新方法、差分確認
- テスト：観点、エビデンス、品質改善
すべてを一度に覚える必要はありません。まずは全体像をつかみ、目の前の仕事に関係するテーマから確認してみてください。
1. 障害対応｜速さだけでなく、正確さを意識する
障害対応で大切なのは、急いで復旧させることだけではありません。状況を正しく把握し、影響を広げず、関係者が判断できる情報をそろえる必要があります。慌てて設定変更や再起動をすると、原因を追うための情報を失うこともあります。
初動｜最初に事実と時系列を押さえる
障害対応の初動では、推測よりも事実を集めます。検知時刻、発生している事象、利用者への影響、直前の変更、確認済みの内容を時系列で記録しましょう。「いつから」「どこで」「何が」「どの程度」起きているかが分かるだけでも、次の調査を進めやすくなります。
また、作業前の状態を残すことも重要です。画面、ログ、プロセス状態、接続状況などを保存してから復旧作業に入ると、後の原因分析に役立ちます。初動では、影響拡大の防止、証跡の確保、関係者への第一報を優先します。
影響範囲｜技術面と業務面の両方から確認する
一つのエラーが、システム全体の障害とは限りません。特定の利用者だけか、特定の機能だけか、オンラインとバッチの両方に影響するか、データ不整合が発生していないかを切り分けます。
影響範囲は、サーバやアプリケーションといった技術面だけでなく、業務が継続できるかという視点でも整理します。たとえば「画面でエラーが出る」という報告だけでなく、「振込受付ができない」「一部利用者のみ再操作が必要」と表現できると、関係者が優先度を判断しやすくなります。
再発防止｜個人の注意ではなく、仕組みに落とし込む
障害が復旧したら、原因と再発防止策を整理します。ただし、「次回から気を付ける」「確認を徹底する」だけでは、同じ問題が繰り返される可能性があります。
直接原因だけでなく、なぜ事前に検知できなかったのか、設計・レビュー・テスト・運用手順のどこに改善余地があったのかまで確認しましょう。チェックの自動化、監視の追加、手順書の改善、レビュー観点への追加など、誰が担当しても実行できる仕組みに変えることが再発防止のポイントです。
障害対応の基本：復旧を急ぎながらも、「事実」「影響」「証跡」を残す。復旧後は、個人の注意ではなく仕組みを改善する。
2. ログ活用｜エラーの前後とシステム間のつながりを見る
ログは、システムで起きたことを確認するための重要な手掛かりです。ただし、エラーメッセージだけを検索しても、原因にたどり着けないことがあります。時刻、処理の流れ、関連するサーバやデータベースをつなげて見ることが大切です。
WebLogic｜対象サーバと処理の流れを特定する
WebLogicを利用する環境では、管理サーバ、管理対象サーバ、アプリケーションなど、複数のログを確認する場面があります。まず、どのサーバでエラーが発生したか、発生時刻はいつか、同じ時間帯に警告や接続エラーが出ていないかを確認します。
スタックトレースの末尾だけで判断せず、最初に出た例外や、その直前の処理も確認しましょう。ログローテーションによって対象時刻のログが別ファイルに移っている場合もあるため、ファイル名と保存期間も事前に把握しておくと安心です。
Oracle｜ORAエラーとデータベースの状態を結び付ける
Oracleの調査では、ORAエラーの番号だけでなく、発生時のSQL、セッション、ロック、接続状況などを組み合わせて確認します。アラートログ、リスナーログ、アプリケーション側のDB接続エラーは、同じ時間軸で見ることが重要です。
たとえば、アプリケーションにはタイムアウトが記録されていても、原因がSQLの長時間実行なのか、ロック待ちなのか、接続数の上限なのかで対応は変わります。エラーコードを調べて終わりにせず、発生時のデータベース状態まで確認する習慣を付けましょう。
APサーバ｜一つのログだけで結論を出さない
APサーバのログには、リクエストの受付、業務処理、外部接続、例外などが記録されます。調査するときは、利用者の操作時刻やリクエストID、セッションIDなどを手掛かりに、Webサーバ、APサーバ、データベースのログを横断して確認します。
サーバごとに時刻設定やログ出力形式が異なると、処理の前後関係を誤って判断することがあります。ログの保存場所、時刻、文字コード、ローテーション、検索に使える識別子を平常時に整理しておくと、障害時の調査が速くなります。
ログ活用の基本：一つのエラー行ではなく、直前から直後までを見る。さらに、Web・AP・DBを同じ時間軸でつなげる。
3. SQL｜正しく取得し、安全に更新し、根拠を持って改善する
SQLは、調査、データ補正、性能改善など、多くの場面で利用します。便利な一方で、本番環境での実行はシステム負荷やデータ破損につながる可能性があります。SELECT、UPDATE、実行計画の基本を分けて押さえましょう。
SELECT｜取得結果と負荷の両方を確認する
SELECTはデータを更新しないため安全に見えますが、大量データの全件検索や複雑な結合は、データベースに大きな負荷を掛けることがあります。最初は対象期間やキーを絞り、少ない件数で条件が正しいことを確認します。
必要な列だけを取得する、WHERE条件を確認する、想定件数を持つといった基本が重要です。結果が取得できたかだけでなく、「なぜこの件数になるのか」を説明できる状態を目指しましょう。
UPDATE｜更新前のSELECTと復旧方法を準備する
UPDATEを実行するときは、同じWHERE条件のSELECTで対象データと件数を事前に確認します。更新前データの退避、トランザクションの扱い、COMMITのタイミング、誤更新時の戻し方まで決めてから作業します。
特に本番作業では、実行者と確認者を分け、SQL、対象件数、作業時刻、実行結果を記録することが大切です。WHERE句のないUPDATEはもちろん、条件の指定ミスも重大な影響につながります。「実行できるSQL」ではなく、安全に確認・復旧できるSQLとして準備しましょう。
実行計画｜遅い理由を推測ではなく根拠で確認する
SQLの性能問題では、実行計画からテーブルへのアクセス方法、結合順序、インデックスの利用状況、見積件数を確認します。SQLを書き換えれば必ず速くなるわけではありません。統計情報やデータ件数、検索条件によって、適切な実行方法は変わります。
まずは、どの処理に時間が掛かっているかを特定し、実行計画と実績の差を見ます。そのうえで、SQL、インデックス、統計情報、処理方式のどこを改善するか判断します。
SQLの基本：SELECTでも負荷を意識する。UPDATEは事前確認と復旧方法をセットにする。性能は実行計画を根拠に判断する。
4. 設計書｜読む、直す、差分を確認する
設計書は、開発時に作成して終わる資料ではありません。仕様確認、影響調査、テスト、障害対応、引き継ぎなど、保守のさまざまな場面で使われます。実際のシステムと設計書の内容がずれていると、誤った判断の原因になります。
読み方｜目的と処理のつながりを意識する
設計書を読むときは、細かな項目から入るのではなく、まず機能の目的、利用者、入力、処理、出力を確認します。その後、画面、API、バッチ、テーブル、外部システムなどの関連資料をたどると、全体像をつかみやすくなります。
正常系だけでなく、入力エラー、接続失敗、再実行、タイムアウトなどの例外時にどう動くかも重要です。分からない箇所には印を付け、資料間の矛盾なのか、自分の理解不足なのかを切り分けながら読み進めましょう。
更新方法｜変更理由と関連資料を残す
設計書を更新するときは、修正箇所だけでなく、変更理由と影響する資料を確認します。画面項目を一つ追加しただけでも、入力チェック、テーブル、インターフェース、テスト仕様書などに影響することがあります。
変更履歴、版数、更新日、更新者を記録し、関連資料との整合性を保ちます。文章を追加するだけでなく、古い記載が残っていないか、用語や名称が統一されているかも確認しましょう。
差分確認｜変更した箇所と、変わってはいけない箇所を見る
設計書の差分確認では、変更箇所が正しいことに加え、意図しない変更が混ざっていないことを確認します。差分ツールは便利ですが、表の行ずれ、図の変更、書式だけの差分などは見落としやすいため注意が必要です。
変更前後のファイルを比較し、追加・変更・削除の理由を説明できる状態にします。PDF化した最終版でも、改ページ、文字切れ、図の崩れ、リンク切れがないか確認すると、成果物の品質が安定します。
設計書の基本：全体から詳細へ読み、変更理由と関連資料をそろえ、最後に意図しない差分がないことを確認する。
5. テスト｜件数ではなく、リスクを減らす
テストの目的は、決められた件数を消化することではありません。変更によって起こり得る問題を想定し、リリース前に見つけることです。テスト観点、エビデンス、品質改善を一つの流れとして考えましょう。
観点｜変更内容とリスクから考える
テスト観点には、正常系、異常系、境界値、権限、同時実行、再実行、タイムアウト、他機能への影響などがあります。ただし、すべての機能で同じ観点を並べればよいわけではありません。
どこを変更したか、何が壊れる可能性があるか、障害が起きた場合の影響が大きいかを考え、優先順位を付けます。過去障害や類似機能の不具合も、実践的なテスト観点になります。
エビデンス｜第三者が結果を判断できる形にする
テストエビデンスは、実施したことを証明するだけの画面コピーではありません。実施条件、入力値、期待結果、実際の結果、実施日時、環境が分かり、第三者が合否を判断できる必要があります。
画面結果だけでなく、必要に応じてログ、データベース、出力ファイルも確認します。エラーになったケースも、想定したエラーであることが分かる証跡を残しましょう。後から説明できるエビデンスは、レビューの効率化にもつながります。
品質改善｜不具合の傾向を次の工程へ生かす
品質改善では、不具合件数の増減だけでなく、どの工程で作り込み、どの工程で検出されたかを確認します。同じ種類の不具合が続いているなら、設計、レビュー、テスト観点、手順のいずれかに改善余地があります。
テストで見つかった問題を修正して終わりにせず、チェックリストやレビュー観点へ反映します。早い工程で問題を見つけられるようになると、修正コストを抑えながら品質を上げられます。
テストの基本：変更とリスクから観点を考え、第三者が判断できるエビデンスを残し、不具合の傾向を次の改善につなげる。
現場で迷ったときに確認したい5つのこと
開発・保守の仕事では、経験を重ねても判断に迷うことがあります。そのようなときは、次の5点に戻って確認してみてください。
- 障害対応：事実、影響、時系列、証跡を整理できているか
- ログ活用：一つのログだけでなく、前後と関連システムを確認したか
- SQL：対象件数、負荷、更新前確認、復旧方法を考えたか
- 設計書：変更理由と関連資料の整合性を確認したか
- テスト：変更によるリスクを観点とエビデンスに反映したか
この5点を習慣にすると、分からない状況でも「次に何を確認すればよいか」を考えやすくなります。
今日から始められる小さな実践
- 障害対応用に、発生時刻・事象・影響・確認結果を記録するメモの型を作る
- 担当システムの主要ログについて、保存場所と確認方法を一覧にする
- UPDATEを作成したら、同じ条件の確認用SELECTもセットで用意する
- 設計書を更新したら、変更前後の差分を自分で確認してからレビューに出す
- テスト項目ごとに、期待結果を先に書いてから実施する
どれも大きな仕組みは必要ありません。まず一つ取り入れ、仕事の中で使いながら自分の型にしていくことが大切です。
シリーズ記事一覧
本シリーズでは、この記事で紹介したテーマを、現場で使える形に掘り下げていきます。
- 障害対応：初動／影響範囲／再発防止（詳細記事は準備中）
- ログ活用：WebLogic／Oracle／APサーバ（詳細記事は準備中）
- SQL：SELECT／UPDATE／実行計画（詳細記事は準備中）
- 設計書：読み方／更新方法／差分確認（詳細記事は準備中）
- テスト：観点／エビデンス／品質改善（詳細記事は準備中）
まとめ｜基本を自分の判断軸に変えていこう
現場で役立つ開発・保守の基本は、特別なテクニックではなく、確認すべきことを一つずつ積み上げることです。
- 障害対応では、事実・影響・証跡を整理する
- ログは、エラーの前後とシステム間のつながりを見る
- SQLは、結果だけでなく安全性と負荷を考える
- 設計書は、読む・更新する・差分を確認するまでをセットにする
- テストは、件数ではなくリスクを減らすために行う
最初から一人ですべてを判断する必要はありません。確認した事実と自分の考えを整理したうえで、先輩やリーダーに相談することも大切な仕事です。本シリーズを、日々の業務で迷ったときに戻れる基礎資料として活用していただければと思います。
コメント