ID:84710さん

プロジェクト概要 金融系業務システムの保守・改善開発プロジェクトに参画しています。 Windows Server／Microsoft SQL Server環境で稼働するシステムを対象に、COBOL2002（日立）を使用した機能追加・改修を担当しています。 顧客要望に基づく新規機能の追加や、不要となったシステム定義の削除など、規模の異なる複数の改修案件に携わっています。 案件によっては数週間程度で設計からテストまで完了するものから、年単位で進行するものまであり、現在は基本設計・詳細設計・製造（実装）・テストケース作成・テスト実施・出荷まで、一連の開発工程を担当しています。 * 言語： COBOL2002（日立） * OS： Windows / Windows Server * DB： Microsoft SQL Server * 期間： 2025年11月〜現在 取り組み①：既存の残高照会機能への新規契約ルート追加 【課題・担当範囲】 既存の残高照会機能に対し、特定のサービスコードで照会が行われた際に、新たに追加する契約ルートへ処理を分岐させる機能改修を担当しました。 新規フラグの定義追加に加え、メインコントローラー、サブルーチン、複数の定義など、約5箇所にまたがって変更が発生する比較的大規模な改修で、設計からテスト・出荷まで約半年を想定する案件でした。 また、本案件は私自身にとって、これまで経験する機会の少なかった設計・製造工程を本格的に一人で担当する初めての案件でもありました。 【調査・実装方針の検討】 製造工程から担当したため、まず同様の条件で改修を実施していた他行の既存実装を調査し、今回の対応で変更が必要となる箇所の洗い出しから開始しました。 基本的には、 1. 新たな契約ルートを判定するためのフラグを定義 2. 特定のサービスコードによる残高照会を判定 3. 条件に合致した場合、新たに追加した契約ルートへ処理を分岐 4. それに合わせてメインコントローラー・サブルーチンを改修 という流れで設計・実装を行いました。 一方で、対象システムには他行とは異なる個別改造が存在していたため、既存の実装をそのまま流用することはできませんでした。 そのため、 * 他行と共通して利用できる処理 * 対象システム固有の既存処理 * 新規契約ルート追加に伴い変更が必要となる処理 * 変更によって既存機能へ影響する可能性がある箇所 を切り分けながら、実装方針を検討しました。 結果として、他行の実装を参考にできた部分が約3割、対象システム固有の仕様を踏まえて自身で実装方法を検討した部分が約7割となり、既存実装を単純に横展開するのではなく、対象システムの仕様を理解したうえで設計・実装する必要がありました。 【設計・製造で工夫したこと】 初めて本格的に設計・製造を担当する案件だったため、分からないことをその都度周囲へ質問するのではなく、まず自身で既存ソースや関連資料を調査し、処理内容を理解して仮説を立てたうえで、必要な部分を有識者へ確認することを意識しました。 既存ソースの調査では、社内規定でソースコードの利用が許可されているMicrosoft Copilotも活用しました。 Copilotを既存ソースの理解や処理整理の補助として利用し、 * 現在の処理がどのような目的で実装されているのか * どの条件によって処理が分岐しているのか * 今回の変更によってどこに影響が及ぶ可能性があるのか を整理したうえで、自分自身でもソースコードや関連資料を確認しました。 そのうえで、ソースコードからは判断できない対象システム固有の業務知識や、実装方針について判断に迷う部分のみチームリーダーへ相談しました。 「技術的に自身で調査・解決できる内容」と「現場固有の知識が必要な内容」を切り分けてから質問することで、質問に割く時間を抑えながら、自身の理解を深めることを意識しました。 また、詳細設計書についても、実装者本人にしか理解できない内容にならないよう、今後実装経験の少ないメンバーが担当した場合でも、設計書から処理内容や変更意図を読み解ける粒度で記載することを心掛けました。 【テスト設計】 実装後は、自身でテストケースの作成・テスト実施まで担当しました。 同様の改修を実施した他行のテスト内容を参考にしつつ、対象システム固有の改造内容を踏まえ、 * 新たに追加した契約ルートへ正しく処理が分岐すること * 追加・変更した機能が仕様通り動作すること * 今回の変更によって既存機能へ意図しない影響が発生していないこと を確認できるよう、改造確認と無影響確認の双方を網羅する約60ケースのテストケースを設計・実施しました。 【成果・得られた経験】 設計・製造・テストを通じて大きな手戻りなく工程を進め、チームリーダーが当初想定していたスケジュールより約1か月前倒しで出荷まで完了することができました。 本案件で使用した言語はCOBOL2002ですが、自身にとって特に大きな経験となったのは言語そのものではなく、既存システムを調査して仕様を理解し、変更箇所・影響範囲を整理したうえで、設計・製造・テスト・出荷まで一連の開発工程を自身の担当として完遂したことです。 これまで本格的な経験の少なかった設計・製造工程について、既存実装を参考にしながらも、対象システム固有の仕様については自身で実装方法を検討し、必要に応じてチームリーダーからアドバイスを受けながら完成まで進める経験を積むことができました。 また、AIを調査・理解の補助として活用し、自分で解決できる技術的な問題と現場固有の知識が必要な問題を切り分けてから相談することで、自身の理解を深めながら効率的に開発を進める方法を身につけました。 取り組み②：属人化していた業務知識・作業手順のドキュメント化 【課題】 プロジェクトへ参画して業務を進める中で、システムや作業手順に関する知識の一部が個人の経験に依存しており、必要な情報を得るために特定のメンバーへ確認しなければならない場面があることに課題を感じました。 また、既存のマニュアルについても、現在の運用とは異なる古い情報が残っているものがあり、資料を参照しても現在の正しい手順を判断しにくいケースがありました。 【考えたこと】 特定のメンバーへの質問を前提とした状態では、質問する側・回答する側の双方に負担がかかるだけでなく、今後担当者が変更になった場合に知識が引き継がれない可能性があると考えました。 自身も参画当初、既存資料だけでは判断できず周囲へ確認する場面があったことから、自分が業務を通して得た知識を個人の経験として留めるのではなく、次に同じ業務を担当する人が利用できる情報として残すことが必要だと考えました。 【取り組み・工夫】 業務を進める中で新たに確認した作業手順や知識について整理し、マニュアルを5本新規作成しました。 同時に既存マニュアルについても実際の業務手順と照らし合わせ、 * 現在の運用と異なっている内容 * 情報が不足している箇所 * 初めて作業するメンバーには理解しにくい記載 などを確認し、既存マニュアル10本を現行の業務・運用に合わせて改訂しました。 単純に自分が理解できる情報を記録するのではなく、初めてその作業を担当するメンバーでも利用できることを意識して内容を整理し、整備した資料はチーム内へ共有しました。 【他チームとの連携改善】 また、業務上関係する他チームとの繋がりが薄く、必要な情報を得るまでに時間がかかることも課題の一つでした。 システム全体に関係する情報を自身のチーム内だけで完結させることは難しいため、自身から他チームのメンバーへ積極的にコミュニケーションを取り、必要な情報を相互に共有できる関係を構築することを意識しました。 不明点が発生した際だけ連絡するのではなく、業務上得られた情報についても必要に応じて共有することで、チームをまたいで情報を確認しやすい環境づくりに取り組みました。 【成果】 マニュアルについては、新規5本の作成・既存10本の改訂を行い、チームメンバー4名が共通の情報として参照できる状態を整えました。 これにより、自身が業務を通して得た知識を個人の中だけに留めず、チーム内で継続して利用できる形として残すことができました。 また、他チームとも積極的にコミュニケーションを取ることで、必要な情報を確認・共有しやすい関係づくりにも繋げることができました。 この経験から、開発業務では自身の担当範囲を完了させるだけでなく、得られた知識をチームの資産として残すことや、周囲と連携してチーム全体が業務を進めやすい状態をつくることも重要であると学びました。 このプロジェクトを通して得たこと 本プロジェクトでは、これまで本格的に経験する機会の少なかった設計・製造工程からテスト・出荷までを一貫して担当する経験を積むことができました。 特に、既存システムのソースや類似実装を調査し、対象システム固有の仕様との差分を整理したうえで、自身で実装方針を考えて開発する経験は、エンジニアとして大きな成長につながったと感じています。 また、技術面だけでなく、業務知識の属人化というチームの課題に対しても、自らマニュアルの新規作成・改訂や他チームとの連携に取り組みました。 今後はこの経験を活かし、使用する言語や技術が変わった場合でも、既存システムを理解し、課題や影響範囲を整理したうえで、設計から実装・テストまで主体的に進められるエンジニアとして経験を積んでいきたいと考えています。

プロジェクト概要 IT系研修事業会社が利用する既存の学習管理システム（LMS）の機能追加・改修を行う受託開発プロジェクトに参画しました。 Java／Spring Bootを中心としたWebアプリケーション開発に携わり、既存システムに対する新規機能・画面の追加および既存機能の改修を担当しました。 6名体制のチームで、基本設計の内容をもとにした画面レイアウト設計・API設計などの詳細設計から、Java／Spring Bootによる実装、テスト仕様書の作成、単体テストまで一連の工程を経験しました。 特に、研修生・講師・企業担当者という3種類のユーザーが同一URLへアクセスした際に、ログインしているユーザーの情報に応じて異なる内容を表示する機能の開発に携わりました。 担当業務 * 新規画面の画面レイアウト設計書作成 * API設計書の新規作成 * Java／Spring Bootを使用したWebアプリケーション実装 * Thymeleafを使用した画面表示・表示制御 * JavaScriptを使用した機能実装 * HTML／CSSによる画面実装 * MyBatisによるDBアクセス・SQLマッピング * 既存Controller・画面の改修 * テスト仕様書の作成 * 単体テストの実施 * チームメンバーの実装支援 開発環境・技術 * 言語： Java、JavaScript、HTML、CSS * FW： Spring Boot、MyBatis、Thymeleaf * DB： PostgreSQL * IDE： STS * バージョン管理： TortoiseGit * その他： A5M2、Redmine * チーム規模： 6名 * 期間： 2025年7月〜2025年8月 取り組み：ユーザー種別に応じた日報機能の新規開発・改修 【課題・要件】 研修生・講師・企業担当者が利用する学習管理システムにおいて、同一URLへアクセスした場合でも、ログインしているユーザー種別に応じて異なる内容を表示する機能の開発を担当しました。 担当した日報機能では、 * 研修生による日報の提出 * 提出済み日報の編集 * 日報の一覧表示 * 講師アカウントでアクセスした場合のフィードバック欄表示 などが必要でした。 特に、研修生・講師・企業担当者の3種類のユーザーが同じ画面へアクセスする一方で、それぞれ表示すべき内容や利用可能な機能が異なるため、セッション情報からユーザー種別を判定し、同一URL上で適切な画面内容を出し分けることが実装上のポイントとなりました。 【設計・実装方針の検討】 基本設計の段階で、追加・改修が必要となる機能の大枠は整理されていたため、その内容をもとに既存のControllerやDB関連の設計書などを確認し、具体的にどのような処理・画面が必要になるのかを詳細化しました。 既存機能の改修だけでなく新規追加する画面・処理もあったため、新規画面については画面レイアウト設計書とAPI設計書を一から作成しました。 設計内容をもとに実装方法を検討し、要件を満たすコードを作成したうえでチームリーダーのレビューを受け、指摘内容を反映しながら実装を進めました。 【実装上の課題と工夫】 特に難しかったのが、Thymeleafとセッション情報を利用したユーザー種別ごとの表示制御でした。 同じURLへアクセスしていても、 * 研修生 * 講師 * 企業担当者 によって画面上に表示する情報や利用できる機能を変更する必要がありました。 自身にとってこのような実装は初めてだったため、当初はセッション情報とThymeleafによる画面制御の流れを理解することに苦戦しました。 そこで、既存のControllerや画面実装、関連する設計内容を確認しながら、**「どのタイミングでユーザーを判定するのか」「Controllerから画面へどの情報を渡す必要があるのか」「画面側でどの条件によって表示を切り替えるのか」**を整理しながら実装しました。 不明点についてはチームメンバーやチームリーダーと認識を合わせ、レビューやアドバイスを受けながら修正を重ねることで、最終的には自身で実装を完了しました。 AIの利用も認められていましたが、設計書等の入力は禁止されていたため社内ルールを遵守し、具体的な設計情報を入力するのではなく、Java／Spring Boot等のコーディング方法を検討する際の補助として限定的に活用しました。 【実装内容】 日報機能を中心に、新規実装として、 * Controller：1つ * Mapper：1つ * 画面：2つ を作成しました。 さらに既存機能との連携を行うため、 * 既存Controller：1つ * 既存画面：1つ についても改修を実施しました。 新規機能だけを独立して作るのではなく、既存システムの構成や処理を確認しながら、新規機能と既存機能が正しく連携できるよう実装しました。 【テスト設計・実施】 実装後は、自身でテスト仕様書を作成し、単体テストまで担当しました。 日報機能については、 * 正常系 * 異常系 * 無影響確認 * 閾値確認 の観点から、約30ケースのテストケースを作成しました。 新規機能が要件通り動作することだけでなく、今回の改修によって既存機能へ意図しない影響が発生していないことも確認できるようテストを設計しました。 各ケースを実施し、画面のハードコピーを取得して期待結果と実際の動作を確認しました。 【成果】 自身が担当した機能については、予定されていた納期より約1週間前倒しで設計・実装・テストまで完了することができました。 担当作業の完了後は、残った期間を自身の作業余力として抱えるのではなく、進捗状況を確認しながら他のチームメンバーが担当する実装の補助にも入り、チーム全体のスケジュールが遅延しないよう支援しました。 本案件を通じて、研修で学習していたJava／Springの知識を実際の受託開発プロジェクトで使用し、既存システムの仕様を確認しながら、詳細設計、新規Controller・Mapper・画面の実装、既存機能との連携、テスト設計・実施まで一連の開発工程を経験することができました。 特に、当初は理解に苦戦したThymeleafとセッション情報を利用した表示制御についても、既存実装の調査やチームメンバーとの認識合わせを行いながら、自身で実装を完成させることができました。 また、自身の担当範囲だけを見るのではなく、担当作業を前倒しで完了した後に他メンバーを支援することで、個人の進捗だけでなくチーム全体の納期を意識して開発を進める経験にもつながりました。

プロジェクト概要 某IT企業の新入社員51名を対象とした、約3か月間の技術研修にサブ講師として参画しました。 本研修では、プログラミング、ネットワーク、AWSなどの基礎学習からスタートし、最終的に受講生自身がチームでAWSを利用したサーバーレスWebアプリケーションを開発できる状態を目標としていました。 研修前半では、Python、JavaScript、HTML／CSS等のプログラミング学習に加え、サーバー実機を使用したネットワーク学習やAWSの各サービスについての研修を実施しました。 研修後半では、それまでに学習した内容を組み合わせ、受講生がチームとなってサーバーレスWebアプリケーションを開発する実践形式の研修を実施しました。 AWS上でのアプリケーション開発だけでなく、AWS CodeBuild、AWS CodeDeploy等を利用したCI/CDも取り入れ、実際の開発現場を意識したカリキュラムとなっていました。 講師7名（メイン講師3名・サブ講師4名）の体制で、私は主に技術的な質問への対応、個別フォロー、補講、週報添削、口頭報告へのフィードバックなどを担当しました。 担当業務 * 講義中の技術的な質問・エラーへの対応 * プログラミング・ネットワーク・AWSに関する学習支援 * 受講生の理解度に応じた個別フォロー * 業後の補講対応 * ネットワーク・AWSに関する補助教材の作成 * 経験者向け追加課題の準備 * サーバーレスWebアプリケーション開発の技術支援 * 週報の添削・フィードバック * 口頭報告に対するフィードバック * 他講師との受講生の進捗・課題共有 技術・環境 * AWS * AWS CodeBuild * AWS CodeDeploy * Python * JavaScript * HTML／CSS * Linux * GitHub * Docker * SQLite * Visual Studio Code * サーバー実機を使用したネットワーク学習 * CI/CD 体制 * 受講生：51名 * 講師：7名（メイン講師3名・サブ講師4名） 期間 2025年3月〜2025年6月 取り組み：経験値の異なる51名に対する研修レベルの調整 【課題】 本研修で特に課題となったのが、51名の受講生間でITに関する事前知識・経験に大きな差があったことです。 情報系の学校を卒業している受講生からは「内容が簡単」という意見がある一方、IT未経験の受講生からは「難しくて理解が追いつかない」という意見があり、全員に同じ内容・同じペースで研修を行うだけでは、それぞれに十分な学習機会を提供することが難しい状況でした。 特にネットワークとAWSについては、プログラミングとは異なる概念の理解も必要になるため、未経験の受講生を中心につまずくケースが多く見られました。 【考えたこと・アプローチ】 研修全体の進行を維持しながら51名全員の学習を支援するためには、全員に同じ説明を追加するのではなく、それぞれの経験・理解度に応じて支援方法を変える必要があると考えました。 そこで、 * 経験者には、通常のカリキュラムより一段階進んだ追加課題を提供する * 未経験者には、理解できていないポイントを確認したうえで個別に補講する * 複数の受講生が共通してつまずいている内容については、補助教材として整理して共有する という3つの方法を組み合わせて対応しました。 【経験者への対応】 情報系の学校を卒業しているなど、既に一定のIT知識を持つ受講生については、通常の研修内容だけでは学習内容が不足するケースがありました。 そこで、通常のカリキュラムを早く終えてもらうだけではなく、より実際の開発現場を意識した追加問題・課題を用意しました。 受講生全体の研修ペースを維持しながら、既に知識を持っている受講生についても研修期間を有効に活用し、さらに技術を伸ばせる状態をつくることを意識しました。 【未経験者への対応】 一方、IT未経験の受講生については、通常の講義だけでは理解が追いつかないケースがあったため、業後に毎日4〜5名程度、約1時間の補講を実施しました。 補講では単純に講義内容を繰り返すのではなく、 * どの段階まで理解できているのか * どの用語・概念から理解できなくなっているのか * 実際の操作と学習した知識がどのようにつながっているのか を確認し、受講生ごとにつまずいているポイントを整理したうえで説明することを意識しました。 特にネットワークとAWSについては複数の受講生が共通してつまずいていたため、個別に同じ説明を繰り返すだけでは効率的ではないと考えました。 そこで、ネットワークとAWSについて、それぞれ概要や重要なポイントを整理した補助レジュメを作成しました。 講義中の説明や補講だけに依存せず、受講生自身が後から内容を振り返り、理解できなかった部分を確認できるようにすることで、個別フォローと自主学習の双方を支援しました。 AWSを利用したサーバーレスWebアプリケーション開発研修 研修後半では、それまでに学習したプログラミング、ネットワーク、AWSの知識を組み合わせ、受講生がチームとなってサーバーレスWebアプリケーションを開発する実践形式の研修を実施しました。 単一のAWSサービスについて学習するだけではなく、複数のサービスを組み合わせてアプリケーションを構築し、さらにAWS CodeBuild、AWS CodeDeploy等を利用したCI/CDも取り入れることで、実際の開発現場を意識した開発を経験してもらうことを目的としていました。 この段階では、それまで個別に学習していたプログラミング、ネットワーク、AWSの知識を組み合わせる必要があるため、受講生からの質問内容もより複雑になりました。 質問対応では単純に操作方法や正解を伝えるのではなく、 「どの処理までは正常に動いているのか」 「どのサービス・設定から想定と異なる状態になっているのか」 「ネットワーク・アプリケーション・AWSのどこに原因があるのか」 を一緒に整理しながら、問題となっている箇所を切り分けることを意識しました。 また、最終的には受講生自身で開発を進められる状態を目標としていたため、可能な限り答えそのものを提示するのではなく、原因を特定するための考え方や確認すべきポイントを伝えるよう心掛けました。 【成果】 受講生それぞれの経験・理解度に応じて、追加課題、個別補講、補助教材の作成などを組み合わせて支援した結果、51名全員が途中で脱落することなく約3か月間の研修を修了し、それぞれの現場へ配属されました。 特に未経験者への支援では、毎日4〜5名程度への補講を継続しながら、共通してつまずきやすかったネットワーク・AWSについては補助教材として知識を整理することで、個別の質問対応だけに依存しない学習支援にも取り組みました。 本案件を通じて、技術的な内容を理解して説明するだけでなく、相手がどこでつまずいているのかを把握し、その原因に応じてアプローチを変えることの重要性を学びました。 また、複数人から同じ質問が発生した場合には、個別対応を繰り返すだけでなく、共通する課題を特定して資料化することで、一度得た知識を再利用可能な形に整理し、チーム全体へ共有する考え方を身につけました。 【その後のキャリアへのつながり】 本研修でAWSの各サービスやサーバーレスアーキテクチャ、CI/CDについて学習し、受講生の開発を支援したことをきっかけに、AWSを活用したシステム開発やクラウド技術そのものに興味を持つようになりました。 その後の配属先ではAWSを直接利用する機会がない環境が続いていますが、業務で使用する技術だけに自身の学習範囲を限定するのではなく、今後のエンジニアとしての技術領域を広げるため、業務外でもAWSの学習を継続しています。 その一環として、 * AWS Certified Cloud Practitioner（CLF）取得 * AWS Certified Solutions Architect - Associate（SAA）取得 * AWS Certified Developer - Associate（DVA）取得に向けて学習中 と、段階的にAWSに関する知識を深めています。 また、その後の実務ではJava／Spring BootによるWebアプリケーション開発を経験し、現在は金融系システムにおいて基本設計・詳細設計から製造、テスト、出荷まで一連の開発工程を担当しています。 今後は、これまで実務で培ってきたWebアプリケーション開発や設計・製造の経験と、継続して学習してきたAWSの知識を組み合わせ、Javaを軸としたクラウド環境でのバックエンド開発にも携われるエンジニアを目指しています。

プロジェクト概要 保険系システムのDB更改に伴う次期環境へのデータ移行・動作確認プロジェクトに参画しました。 既存環境から次期環境へデータを移行したうえで、保険契約に関する各機能が従来と同様に問題なく動作することを確認する大規模なテスト案件です。 6名体制（チームリーダー1名・テスト実行者5名）のチームで、別チームが作成したテスト仕様書をもとに、ブラックボックステスト、結合テスト（IT）、シナリオテスト（ST）、性能測定など、複数工程のテストを担当しました。 本案件は自身にとってITエンジニアとして初めて参画した実案件であり、初めてCOBOLで構築された業務システムに触れるとともに、システム開発における品質管理や不具合の切り分けについて実務を通して学ぶ機会となりました。 担当業務 * ブラックボックステスト * 結合テスト（IT） * シナリオテスト（ST） * 性能測定テスト * テストエビデンスの取得 * 不具合発生時の一次切り分け * チームリーダーへの報告 * 関連ドキュメントの更新 * テスト手順書の新規作成 * COBOLのソースコード・文法に関する自主学習、資料作成 テスト実績 * ブラックボックステスト：30件以上 * 結合テスト（IT）：30件以上 * シナリオテスト（ST）：30件以上 * 性能測定：60件以上 開発環境・技術 * OS： Windows * 言語： COBOL * DB： Oracle * ツール： HardCopy、TortoiseSVN、Tera Term 体制 * チームリーダー：1名 * テスト実行者：5名 期間 2024年9月〜2025年2月 取り組み①：DB更改に伴う次期環境での品質確認 【課題】 本案件では、既存環境から次期環境へデータを移行したうえで、従来利用していた保険系システムの各機能が問題なく動作することを確認する必要がありました。 DB更改というシステム全体に影響する変更であったため、画面上で操作できることだけではなく、移行前後で想定外の挙動が発生していないかを細かく確認し、テスト結果を正確なエビデンスとして残すことが重要でした。 また、テストを実施するステージング環境はネットワークから隔離された環境となっており、実機を直接操作してテストを行う必要がありました。 そのため、通常の業務環境と比較してリアルタイムでの情報共有が難しく、テストの進捗状況や発生した事象について、チーム内で綿密に連携する必要がありました。 【テスト実施で意識したこと】 別チームが作成したテスト仕様書をもとにテストを実施し、期待結果と実際の動作を照合するとともに、後から第三者が確認してもテスト結果を判断できるよう、必要なエビデンスを漏れなく取得することを意識しました。 また、仕様上は問題がないように見える場合でも、実際にシステムを操作していて少しでも挙動に違和感があった場合には、そのままテストを進めず原因を確認するようにしていました。 一方で、確認した事象をすべてそのまま他チームへ問い合わせると、テスト実施者側の操作ミスなどによって不要な問い合わせを発生させてしまう可能性があります。 そのため、期待値と異なる結果が発生した場合には、 1. まず自身の操作・テスト手順に誤りがないかを再確認 2. 同じ条件で再度テストを実施 3. 別のチームメンバーにも同条件で操作してもらい、再現性を確認 4. 再現性が確認できた場合にチームリーダーへ報告 5. 必要に応じて別チームへ問い合わせ という流れで一次切り分けを行いました。 自身の操作ミスなのか、環境・データ・システム側で発生している問題なのかを可能な範囲で切り分けてから報告することで、不要な問い合わせを発生させず、問題のある事象を正確にエスカレーションすることを心掛けました。 【不具合の検知・切り分け】 実際の保険契約画面を操作するテストでは、 * 操作途中で処理が停止する * 発生条件を満たす操作を行っても、想定している画面へ遷移しない といった事象を検知しました。 期待結果との差異を確認した際には、前述の手順に沿って自身の操作を再確認し、別メンバーにも同条件でテストを実施してもらうことで再現性を確認しました。 そのうえでチームリーダーへ報告し、関連チームへ確認を行った結果、テーブル情報の入れ替え先に相違があったことが原因であると判明しました。 この経験から、テストでは単純にテストケースを「OK／NG」で消化するだけではなく、小さな違和感を見逃さず、再現性を確認し、原因調査に必要な情報を整理して報告することが品質確保につながると学びました。 取り組み②：性能測定テスト DB更改後の次期環境において、システムの機能面だけでなく、利用時の性能に問題が発生していないことを確認するため、性能測定テストも担当しました。 実際に各画面を操作して画面遷移に要する時間を測定し、定められた期待値を満たしているかを確認しました。 性能測定については60件以上を担当し、機能が正しく動作することだけではなく、利用者が実際にシステムを操作する際の処理性能も品質の一部として確認する経験を積みました。 取り組み③：制約・待ち時間を利用した自主学習とドキュメント整備 【課題】 本案件では、DB移行や環境準備など複数のチームが関係しており、前工程を担当する別チームで遅延が発生すると、ステージング環境が占有され、自チームが予定していたテストを開始できないことがありました。 その結果、テストを実施できる期間が後ろ倒しとなり、自チームのスケジュールが逼迫するなど、状況に応じたイレギュラーな対応が必要となりました。 また、自身にとって初めての実案件であり、COBOLもそれまで扱った経験がなかったため、参画当初はシステム内部でどのような処理が行われているのかを理解することにも苦戦しました。 さらに、セキュリティ対策のため業務PCはインターネットへ接続されておらず、AI等の外部サービスを業務上の調査に利用することもできない環境でした。 【考えたこと・取り組み】 環境の都合でテストを進められない時間についても、そのまま待機時間とするのではなく、今後のテストや業務理解につながる時間として活用することを意識しました。 特に、それまで経験のなかったCOBOLについては、既存のソースコードや利用可能な資料を読みながら処理を確認し、自身で文法や処理内容を整理した資料を作成しました。 AI等を利用できない環境だったからこそ、既存ソースを一つずつ読み解き、 * 使用されている構文が何を意味するのか * どのような順序で処理されているのか * テストで行っている操作が内部処理とどのようにつながっているのか を自分自身で調査・整理することを意識しました。 また、後続の作業者が同じテストを実施する際に手順を確認しやすくなるよう、テスト手順書の新規作成にも取り組みました。 テストを進められない時間を、技術理解やドキュメント整備に充てることで、後続作業につながる成果物を残しながら自身の知識も蓄積しました。 【成果・得られた経験】 本案件では、ブラックボックステスト・結合テスト・シナリオテスト・性能測定を合わせて多数のテストを経験し、DB更改後の次期環境における品質確認に携わりました。 特に、期待結果と異なる挙動を発見した際に、すぐに問い合わせるのではなく、自身の操作確認 → 再実施 → 他メンバーによる再現確認 → リーダーへの報告という形で一次切り分けを行うことで、問題を整理したうえでエスカレーションする考え方を身につけました。 また、インターネットやAIを業務上の調査に利用できない環境で、初めて触れるCOBOLの既存ソースや資料を自身で読み解いた経験から、未知の技術であっても、既存の情報を一つずつ整理しながら理解していく力を身につけることができました。 本案件は自身にとって初めての実案件であり、ここで身につけた**「期待値だけを見るのではなく、違和感を見逃さない」「問題発生時には再現性を確認して切り分ける」「テスト結果を第三者が確認できる形で残す」**という品質に対する考え方は、その後の開発案件にも活かされています。 その後のJava／Spring Boot案件では自身で正常系・異常系・閾値・無影響確認を含むテストケースを設計・実施し、現在の金融系開発案件では設計・製造だけでなく、改造確認・無影響確認を含むテスト設計から出荷まで担当するようになりました。 本案件で「作成されたテストケースを正確に実施する側」として品質管理の基礎を学んだ経験が、その後、自身で実装した機能に対して必要なテスト観点を考え、品質を担保する側へ担当範囲を広げていく土台になったと考えています。