ID:83648さん

## 概要 技術書・記事・個人開発で得た学習経験を、単なる読書記録ではなく「自分の技術が何から形作られているのか」を表す技術プロフィールとして可視化する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として技術的な関心や学習の軌跡を可視化するところまで進めたいと考えています。

## プロジェクト概要 社内オペレーター向け顧客情報検索システムの画面実装をSalesforceへ移管するにあたり、Salesforce画面と既存の顧客情報検索処理をつなぐJavaベースのREST API開発を担当しました。 ## 役割・体制 ### 自身のポジションと役割 - バックエンドエンジニアとして、Spring BootおよびSpring Frameworkを用いたAPI設計・コーディング・テスト・リリース後の確認を担当しました。 - 画面から取得した顧客IDや検索条件をJavaで処理し、基盤処理およびCOBOL検索システムへの値の変換と受け渡しを行うAPIの開発と検証を実施しました。 - 障害発生を防ぐため、入力値・変換値・連携先エラー時の挙動を整理し、単体テスト・結合テストで確認しました。 ### チーム規模と構成 - 自チームからはエンジニア3名で構成され、実装者は私一人でした。 - 他のAPI処理開発、基盤処理開発、画面開発は他3社様と自社の別1チームの系5チームでの協業体制のもと進められました。 ## 背景・課題 - 既存の顧客情報検索システムの画面実装をSalesforceに移管するにあたり、JavaでのREST API開発が必要となりました。 - チーム内にSpring MVC / REST API開発の有識者がいなかったため、Springの構成、REST連携、既存基盤処理との接続仕様を自ら調査しながら実装を進めました。 - チーム内でのREST連携の仕組みやAPIの設計方法に関する知見不足が、プロジェクト初期の障壁となりました。 - Salesforce、Java API、基盤処理、COBOL検索システムで項目定義や値の扱いが分かれており、仕様の解釈違いや値変換ミスが顧客情報の取得失敗や画面表示不整合につながる可能性がありました。 ## 実際の取り組み ### 開発環境 - Salesforce画面側から呼び出されるJava REST APIを実装し、API内で基盤処理が受け取れる形式へ値を変換したうえで、COBOL検索システム側の既存処理と連携しました。 - Gitでソースコードを管理し、JUnitによる単体テストで入力値チェックや異常系の挙動を確認しました。 - 開発ツールとしてMicrosoft TeamsのTeams Copilotを活用し、コード理解や調査内容整理、問題発生時の切り分けに利用しました。 ### 設計・改善内容 - コードの理解が困難な基盤処理の流れを詳細に解析し、データ形式の変換ロジックを明確化することで、COBOLシステムへの値渡しの信頼性を向上させました。 - アノテーション検証に必要なライブラリ不足があった際は、自分で調査し、特定のライブラリなしでも単体テストで入力値チェックの挙動を確認できるようにしました。 - チーム内での技術共有を活発化させるため、理解した内容や問題解決手法をドキュメント化し、ナレッジ共有を推進しました。 ### その他アピールポイント - Teams Copilotが社内で導入され始めた時期でしたが、当初は既存コードの理解や問題発生時の対策にそのまま使える回答が常に得られるわけではありませんでした。そのため、前提条件や知りたい観点を整理しながら壁打ちする使い方を試行錯誤しました。その過程で、AI技術（特にLLM）に関する知見を深めることができ、活用法をチームメンバーにも共有しました。業務理解や調査補助にAIを活用する選択肢を広げるきっかけになったと考えています。 ## 成果・価値 - 担当APIは障害発生なしに稼働し、基盤処理とCOBOL検索システムとの安定的な連携を実現しました。 - チーム内にSpring MVC / REST API開発の有識者がいない状況でしたが、自ら調査・検証しながら担当APIを実装・テスト・リリース後確認まで進めました。 - Salesforce、Java API、基盤処理、COBOL検索システム間で受け渡される項目や値変換ルールを整理したことで、結合テスト時に確認すべき観点を明確にできました。 - Teams Copilotを活用した既存コード理解や調査内容整理により、技術習得と問題切り分けの速度を上げ、プロジェクト推進の支援につなげました。

## プロジェクト概要 COBOL / Perlで実装されていた、契約者が対象契約の支払方法をクレジット払いへ変更する機能を、Java中心の構成へ移行する開発を担当しました。 カード情報の登録自体は外部サイトで行われるため、自システム側では対象契約の選択、外部サイト連携、戻り結果の受け取り、画面表示、後続処理への反映を担う構成でした。移行前後で利用者の操作結果や業務フローが変わらないよう、既存仕様を確認しながら実装・テストを進めました。 ## 役割・体制 ### 自身のポジションと役割 * バックエンドエンジニアとして、支払方法変更に関わるJava側の業務ロジックと画面処理を担当しました。 * JavaScript / HTML / CSSによる画面実装、Java側の入力チェック・外部サイト連携結果の制御、単体テスト・結合テストを担当しました。 * 他メンバーの実装に対するコードレビューも担当し、既存仕様との整合性や保守性の観点から確認しました。 ### チーム規模と構成 * 5名体制のチームで開発を行いました。 * 私は、支払方法変更に関わる画面処理とJava側の業務ロジックを担当しました。 ## 背景・課題 * 既存のCOBOL / Perl処理には、長年の運用で積み上がった条件分岐や業務ルールが含まれていました。 * 対象契約の選択から外部サイト連携、戻り結果の表示までが一連でつながるため、扱いを誤ると支払方法変更の失敗や画面表示不整合につながる可能性がありました。 * そのため、既存処理を単純にJavaへ置き換えるのではなく、移行前後で業務上の振る舞いが変わらないことを確認しながら進める必要がありました。 ## 実際の取り組み ### 開発環境 * Java、JavaScript、HTML、CSS、COBOL、Perl、SQLを使用しました。 * COBOL / Perlは、既存仕様を読み解くための参照元として確認しました。 ### 設計・改善内容 * 既存処理の入力条件、分岐、データ更新内容、外部サイト連携結果の扱いを確認し、Java側の業務ロジックとして実装しました。 * 変更可能 / 変更不可の条件や、外部サイトから戻った結果を画面側へどう返すかを整理し、Java側のチェック処理や表示制御に反映しました。 * テストでは、正常系だけでなく、変更不可、外部サイトからの戻り結果、既存処理との差分が出やすいケースを重点的に確認しました。 * コードレビューでは、既存仕様との整合性や、移行前後で業務上の振る舞いが変わらないかを確認しました。 ### その他アピールポイント * レガシーシステムをJavaへ移行する中で、既存コードを表面的に置き換えるだけでなく、業務上維持すべき振る舞いを確認しながら実装・テストしました。 ## 成果・価値 * COBOL / Perlで実装されていた支払方法変更機能を、Java中心の構成で動作する状態まで実装・テストしました。 * 対象契約の選択、外部サイト連携、戻り結果の表示までの一連の流れを確認し、移行前後で利用者の業務フローを変えずに支払方法変更を行える状態にしました。 * 既存仕様との差分が出やすい箇所を重点的に確認したことで、表示不整合や誤った契約への変更につながるリスクを抑えながら結合テストまで進めました。

## プロジェクト概要 保険系の社内サービス新規開発プロジェクトで、契約情報照会画面と支払い登録画面の開発を担当しました。 契約者本人が入力した情報をもとに契約情報を確認し、手続き対象の契約を選択したうえで、銀行情報を使った支払い方法の登録まで進めるための画面です。 ## 役割・体制 ### 自身のポジションと役割 * 契約情報照会画面と支払い登録画面について、詳細設計、Java側の処理実装、JavaScript / HTML / CSSによる画面実装、単体テスト、結合テストを担当しました。 * 画面で入力・選択された内容をJava側で受け取り、後続の登録処理へ正しく引き継ぐ部分を担当しました。 * SQLを用いて、契約情報や登録データの確認も行いました。 ### チーム規模と構成 * 約9名体制のチームで開発を行いました。 * 私は、契約情報照会から支払い登録までの画面処理とJava側の処理を担当しました。 ## 背景・課題 この機能では、契約者本人が画面上で入力・選択した内容を、後続の登録処理へ正しく引き継ぐことが重要でした。 契約情報の表示、対象契約の選択、銀行情報の入力、登録処理が一連でつながるため、画面上の状態とJava側で扱う値がずれると、誤った契約への登録や登録失敗につながる可能性がありました。 そのため、入力不足、選択漏れ、表示内容と登録処理の不整合が起きないように確認しながら進める必要がありました。 ## 実際の取り組み ### 開発環境 * Java * JavaScript * HTML / CSS * SQL ### 設計・実装内容 * 契約情報照会画面では、入力条件、表示項目、契約選択状態を確認し、選択した契約がJava側の処理に正しく渡るように実装しました。 * 支払い登録画面では、銀行情報の入力内容が登録処理に正しくつながるように、画面側の入力・表示制御とJava側の処理を確認しながら実装しました。 * テストでは、正常に登録できるケースだけでなく、入力不足、選択漏れ、表示内容と登録処理の不整合が起きやすいケースも確認しました。 ### その他アピールポイント * チーム配属初期のプロジェクトでしたが、複数人チームでの新規開発を通じて、画面入力、Java側の処理、DB確認、単体テスト、結合テストまで一通り担当しました。 * 画面を作るだけでなく、ユーザー操作が後続処理にどうつながるかを意識しながら実装しました。 ## 成果・価値 * 契約者本人が、契約情報の確認から支払い登録までを画面上で進められる機能を実装しました。 * 画面で入力・選択された内容がJava側の処理に正しく渡るように確認しながら実装し、誤登録や登録失敗につながるリスクを抑えました。 * 単体テスト・結合テストでは、正常系だけでなく、入力不足や選択状態の不整合が起きるケースも確認し、後続処理に誤った情報が渡らないようにしました。