ID:83648さん

## 概要 社内オペレーター向け顧客情報システムにおいて、Salesforceを起点に顧客情報を取得するJava APIの開発を担当しました。 Salesforceから受け取った顧客IDや検索条件をJava APIで検証し、既存基幹処理が受け取れる形式に変換したうえで連携し、取得結果を画面表示用のレスポンスとして返却する処理を実装しました。 ## 担当範囲 詳細設計、Java APIの実装、画面側との接続確認、単体テスト、結合テストを担当しました。 具体的には、リクエスト／レスポンス項目の整理、既存基幹処理へ渡す値のマッピング、取得結果の返却処理、異常系を含むテスト観点の洗い出しを行いました。 ## 使用技術 - **Java**：顧客情報取得APIのリクエスト処理、入力値チェック、値の変換、レスポンス返却処理で使用 - **Salesforce**：顧客照会の入力起点として、Java APIへ連携される項目や検索条件を確認 - **既存基幹処理**：顧客情報の取得元として、Java APIから渡す項目定義や前提条件を確認 ## どんな機能を開発したか 社内オペレーターがSalesforce画面から顧客情報を照会した際に、Java APIを通じて既存基幹処理から最新の顧客情報を取得し、画面側へ返却する機能を開発しました。 Salesforceから受け取った顧客IDや検索条件をJava API側で検証し、既存基幹処理が受け取れる形式に変換したうえで連携しました。また、取得した顧客情報を画面表示に必要なレスポンス形式へマッピングしました。 ## 課題と工夫 Salesforce、Java API、既存基幹処理で項目定義や値の扱いが分かれており、仕様の解釈違いによる連携不整合が起きる可能性がありました。 そのため、Salesforceから受け取る値、Java APIで変換する値、既存基幹処理へ渡す値、画面側に返す値を整理しながら実装しました。 また、正常系だけでなく、必須項目不足、想定外の値、連携先エラーなどの異常系も考慮し、単体テスト・結合テストで確認しました。 ## 成果 Salesforce画面からJava APIを経由して既存基幹処理の顧客情報を取得し、社内オペレーターが画面上で顧客情報を確認できる状態まで実装・テストしました。 Salesforce側から受け取る項目、Java API内で扱う値、既存基幹処理へ渡す値、画面側へ返すレスポンス項目を整理しながら開発したことで、結合テスト時に確認すべき観点を明確にできました。 また、項目の受け渡しや値の変換ルールを事前に確認していたため、連携先との認識違いが起きやすい箇所を早い段階で洗い出し、修正・確認しながら進められました。 ## 学んだこと API開発ではJava側の処理を書くことに加えて、連携元・API・連携先・画面表示まで含めたデータの流れを追い、責務分担や異常系を確認しながら実装する力が必要だと実感しました。

## 概要 COBOL / Perlで実装されていたクレジット決済システムを、Java中心の構成へ移行する開発を担当しました。 この機能は、利用者がクレジット決済を登録するための画面・業務処理です。入力内容の不備や既存データとの不整合があると、決済登録の失敗や後続処理への影響につながる可能性がありました。 そのため、単に既存処理をJavaへ置き換えるのではなく、既存の決済業務フローを維持したまま、Java側で同等の振る舞いになるように実装・テストしました。 ## チーム体制・担当範囲 5名体制のチームで開発を行いました。 私は、クレジット決済登録に関わる画面処理とJava側の業務ロジックについて、詳細設計、実装、単体テスト、結合テストを担当しました。 画面側は JavaScript / HTML / CSS を用いて入力・表示・操作まわりを実装し、Java側では入力チェック、登録処理、エラー時の制御を担当しました。 既存のCOBOL / Perl処理については、移行前の仕様を読み解くための参照元として確認しました。 ## どんな機能を開発したか クレジット決済の登録画面と、登録処理に関わる業務ロジックを開発しました。 画面側では、利用者が入力・選択した内容をJava側へ渡す処理を実装しました。 Java側では、受け取った入力内容に対してチェックを行い、登録可能な場合は決済登録処理へつなげ、入力不備や登録不可の場合は既存業務フローに沿った結果を返すように制御しました。 この機能では、利用者が画面上で入力した情報をもとにクレジット決済登録を行うため、入力チェックや登録不可時の制御が不十分だと、誤登録や登録失敗、既存データとの不整合につながる可能性がありました。 ## 課題 既存のCOBOL / Perl処理には、長年の運用で積み上がった条件分岐や業務ルールが含まれていました。 特に、以下の点を確認する必要がありました。 - どの入力条件で、どのチェック処理に入るのか - どの条件で登録可能 / 登録不可になるのか - 入力不備や異常系の場合、画面側にどの結果を返すのか - 既存データとの整合性をどう保つのか - 移行前後で、利用者や業務側に影響が出ないか 決済機能のため、正常に登録できることだけでなく、誤登録や既存データとの不整合を防ぐことも重要でした。 ## 自分が行ったこと・工夫 既存のCOBOL / Perl処理を確認し、入力条件、分岐、データ更新内容、エラー時の扱いを読み解きながら、Java側の業務ロジックとして実装しました。 工夫した点は、既存処理をそのままJavaへ写すのではなく、入力条件・更新内容・例外時の挙動を整理してから実装したことです。 理由は、移行前後で業務上の振る舞いが変わると、利用者の操作結果や後続処理に影響が出る可能性があったためです。そのため、既存処理の分岐を確認する際は、「この条件では何を防いでいるのか」「登録可能 / 登録不可の判断はどこで行われているのか」「エラー時に画面側へ何を返すべきか」を確認しながら進めました。 たとえば、登録可能なケースだけでなく、入力不備、登録不可、既存データとの不整合が起きやすいケースを確認し、Java側のチェック処理やエラー時の返却内容に反映しました。 テストでは、正常に登録できるケースに加えて、入力不備、登録できないケース、既存処理との差分が出やすいケースを重点的に確認しました。 ## 使用技術 - **Java**：移行後の業務ロジック、入力チェック、登録処理、エラー時の制御で使用 - **JavaScript / HTML / CSS**：クレジット決済登録画面の入力・表示・操作まわりの実装で使用 - **COBOL / Perl**：既存仕様を読み解くための参照元として使用 - **SQL**：登録データ、既存データ、テスト結果の確認で使用 ## 成果 COBOL / Perlで実装されていたクレジット決済登録処理を、Java中心の構成で動作する状態まで実装・テストしました。 既存処理の入力条件、分岐、データ更新内容、エラー時の扱いを確認しながら実装したことで、移行前後で利用者の業務フローを変えずにクレジット決済登録を行える状態にしました。 また、正常系だけでなく、入力不備や登録不可となるケースも確認したことで、誤登録や既存データとの不整合につながるリスクを抑えながら結合テストまで進められました。 数値で示せる成果はありませんが、既存仕様との差分を抑えながら、クレジット決済登録機能をJava中心の構成へ移行し、利用者が移行前と同じ流れで登録できる状態にしたことが成果です。 ## 学んだこと レガシーシステムをJavaへ移行する際は、既存コードを表面的に置き換えるだけではなく、業務上どの振る舞いを維持する必要があるのかを理解することが重要だと学びました。 特に決済領域では、正常に登録できることだけでなく、入力不備、登録不可、既存データとの整合性、異常系の扱いを確認しながら実装・テストする必要があると感じました。

## 概要 保険系の社内サービス新規開発プロジェクトで、契約情報照会画面と支払い登録画面の開発を担当しました。 この機能は、契約者本人が入力した情報をもとに自身の契約情報を確認し、手続き対象となる契約を選択したうえで、銀行情報を使った支払い方法の登録まで進めるための画面です。 ## チーム体制・担当範囲 約9名体制のチームで開発を行いました。 私は、契約情報照会画面と支払い登録画面について、詳細設計、Java側の処理実装、JavaScript / HTML / CSSによる画面実装、単体テスト、結合テストを担当しました。 ## どんな機能を開発したか 契約情報照会画面では、契約者が入力した情報をもとに契約情報を取得・表示し、後続手続きの対象となる契約を選択できるようにしました。 支払い登録画面では、選択された契約に対して、銀行情報をもとに支払い方法を登録するための画面処理とJava側の処理を実装しました。 画面で入力・選択された内容をJava側で受け取り、後続の登録処理へ正しく引き継ぐ部分を担当しました。 ## 課題 この機能では、契約者本人が画面上で入力・選択した内容が、後続の登録処理に正しく引き継がれることが重要でした。 特に、以下の点を確認しながら進める必要がありました。 - 入力された情報から正しい契約情報を表示できるか - 契約者が選択した契約が後続処理に正しく渡るか - 銀行情報の入力内容が登録処理に正しく反映されるか - 入力不足や選択漏れがあった場合に、想定外の登録につながらないか - 画面表示項目とJava側で扱う項目にずれがないか 契約情報の選択や支払い登録に関わる画面のため、画面上の入力・選択状態が後続処理とずれると、誤った契約への登録や登録失敗につながる可能性がありました。 ## 自分が行ったこと・工夫 実装時は、画面を作るだけでなく、契約者の操作から後続処理までの流れを確認しながら進めました。 契約情報照会画面では、入力条件、表示項目、契約選択状態を確認し、選択した契約がJava側の処理に正しく渡るように実装しました。 支払い登録画面では、銀行情報の入力内容が登録処理に正しくつながるように、画面側の入力・表示制御とJava側の処理を確認しながら実装しました。 工夫した点は、正常に登録できるケースだけでなく、入力不足、選択漏れ、表示内容と登録処理の不整合が起きやすいケースを先に確認し、単体テスト・結合テストの観点に入れたことです。 これにより、画面上の操作とJava側の処理がずれたまま後続処理へ進まないように意識しました。 ## 使用技術 - **Java**：契約情報照会、契約選択後の処理、支払い登録に関わるサーバー側処理で使用 - **JavaScript**：画面上の入力・選択・表示制御で使用 - **HTML / CSS**：契約情報照会画面、支払い登録画面の画面実装で使用 - **SQL**：契約情報や登録データの確認で使用 ## 成果 契約者本人が、契約情報の確認から支払い登録までを画面上で進められる機能を実装しました。 画面で入力・選択された内容がJava側の処理に正しく渡るように確認しながら実装したことで、契約選択や支払い登録時の入力不備・選択漏れによる誤登録や登録失敗を防ぎやすい画面処理にできました。 また、単体テスト・結合テストでは、正常系だけでなく、入力不足や選択状態の不整合が起きるケースも確認し、後続処理に誤った情報が渡らないようにしました。 ## 学んだこと チーム配属初期のプロジェクトでしたが、複数人チームでの新規開発を通じて、画面入力、Java側の処理、DBのデータ確認、単体テスト・結合テストまで一通り経験しました。 この案件で、画面を作るだけでなく、ユーザー操作が後続処理にどうつながるかを考えながら実装することの重要性を学びました。

## 概要 技術書・記事・個人開発で得た学習経験を、単なる読書記録ではなく「自分の技術が何から形作られているのか」を表す技術プロフィールとして可視化するWebアプリを個人開発しています。 現在は Spring Boot / PostgreSQL / Flyway を使い、バックエンドAPIとDB設計を中心に実装しています。 ## 担当範囲 個人開発のため、要件整理、DB設計、API設計、実装、テスト、README / docs 整備まで自分で行っています。 現時点では、Resource登録API、Resource一覧取得API、Resource作成時のProgress自動作成、DBマイグレーション、Service層テストまで実装しています。 今後は、ResourceSection、SectionStudyStatus、StudyMemo、LearningSession、LevelHistoryを順に実装予定です。 ## どんな機能を開発しているか SteerLogでは、学習した本・記事・動画・実装経験などを Resource として登録し、それに対する進捗状態や学習証跡を管理できるようにします。 Resource登録APIは、学習対象を一元管理し、後から学習の根拠を追えるようにするための機能です。たとえば、技術書・記事・動画・実装タスクを登録し、それぞれに対して進捗や振り返り記録を紐づけられるようにする想定です。 また、Resource作成時には Progress を同時に作成することで、学習対象だけが存在して進捗情報がない状態を防ぐ設計にしています。これにより、登録直後から学習状態を管理でき、Resource と Progress の不整合が起きにくくなります。 将来的には、学習履歴・振り返り記録・技術タグ・成果物との関係を集約し、Galaxy API（仮称）として個人の技術プロフィールを可視化する構想です。 ## 課題 学習記録をただ保存するだけでは、技術プロフィールとしての根拠になりにくいと考えました。 たとえば、学習対象、現在の進捗、振り返り記録、レベル到達履歴、プロフィール表示用の集約データを同じ考え方で扱ってしまうと、後から「どの記録が強みや関心の根拠になっているのか」が分かりづらくなります。 そのため、現在の学習状態、履歴、証跡、可視化用の集約データを分けて扱う必要があると考えました。 ## 自分が行ったこと・工夫 DB設計では、学習対象を表す Resource と、現在の進捗状態を表す Progress を分けました。 Resource は「何を学ぶか」を管理し、Progress は「その学習対象が今どの状態か」を管理します。これにより、学習対象そのものの情報と、ユーザーごとの進捗状態が混ざらないようにしています。 また、Resource作成時にはProgressを同時に作成する設計にしました。理由は、Resourceだけが作成されてProgressが存在しない状態になると、一覧取得や詳細取得時に進捗状態を扱いづらくなるためです。Resource作成とProgress作成は同一トランザクションで扱い、途中で失敗した場合に片方だけが残らないようにしています。 削除については、Resourceは deleted_at による論理削除を採用しています。将来的に学習履歴やプロフィール表示と紐づくデータになるため、物理削除で証跡が失われるよりも、非表示状態として扱える設計の方が適していると判断しました。 READMEやdocsには、プロダクト思想、MVPスコープ、DB設計、API設計、レベル管理ルール、LearningSession設計を整理しています。実装だけでなく、なぜその設計にしたのかを後から説明できるようにすることを意識しています。 ## 使用技術 - **Java / Spring Boot**：REST API、Controller、Service、Repository層の実装で使用 - **PostgreSQL**：Resource、Progressなどの学習状態管理データの保存先として使用 - **Flyway**：resources / progresses テーブルのDBマイグレーション管理で使用 - **JUnit**：Resource作成時にProgressも作成されること、一覧取得時にProgressを紐づけて返すことのService層テストで使用 - **Docker Compose**：ローカル開発用のPostgreSQL起動に使用 - **GitHub**：実装履歴、README、設計ドキュメント管理で使用 ## 成果 現時点では、Resource登録API、Resource一覧取得API、Resource作成時のProgress自動作成、DBマイグレーション、Service層テストまで実装しています。 Resource登録からProgress作成までを同一トランザクションで扱うことで、学習対象と進捗状態が不整合にならない構成にしました。 また、README / docs を整備し、DB構造やAPI設計、今後実装するLearningSessionやLevelHistoryの考え方を後から追える状態にしています。まだ完成品ではありませんが、単なるCRUDではなく、学習状態・履歴・証跡・可視化用データを分けて扱うバックエンド設計として進めています。 ## 今後実装したいこと 次に、ResourceSection、SectionStudyStatus、StudyMemoを実装し、学習対象を章・節単位で管理できるようにする予定です。 その後、LearningSession / LearningSessionRecord / LevelHistoryを追加し、振り返りや想起の記録を学習証跡として保存できるようにします。 最終的には、これらの証跡を集約して、Galaxy APIとして技術的な関心や学習の軌跡を可視化するところまで進めたいと考えています。