Web001

# 概要 大手証券会社のアプリにおけるWeb API開発（実装）を担当いたしました。 証券アプリと連携するポイント機能の追加に伴い、関連する追加開発を実施いたしました。 具体的には、アプリを通じて株を購入する際に、クレジットカードなどのポイントを購入費用として充当できる機能の開発を行いました。 # 具体的な作業内容 - アプリから送信されるリクエスト内容と、データベースに保持されている情報を基に、株の購入費用にポイントを充当できる仕組みを実装しました。 - 実装したAPIの主な機能 - ポイントを充当可能とする条件をチェックする機能の実装 - 株の購入金額にポイントを充当する機能の実装 # 課題 ## 1. 作業内容の理解 案件特有の用語を理解することに苦慮いたしました。 また、設計書とコードにおける表記の揺れが多かったため、作業内容の理解に時間を要しました。 ## 2. 技術のキャッチアップ 1年間Laravelの開発経験を経て本案件に参加いたしましたが、カスタム例外処理やログレベルの設定など、未経験の作業が多くございました。また課題1を乗り越えるために時間を多く使ったため、キャッチアップしながらスケジュールに間に合わせることに苦労いたしました。 # 工夫したこと・成果 案件特有の用語が多く、作業をご説明いただいてもすぐに理解が難しい場面がございました。 そのため、設計書やコードを基に作業内容を確認し、担当SEの方に自分が理解した内容や不明点をご確認いただきました。設計書とコードには表記揺れや設計漏れが多く見受けられましたが、時間を惜しまず丁寧に確認作業を行ったことで、最終的に作業内容をしっかりと理解することができました。 技術をキャッチアップする際には、調べるタイミングや方法を工夫しました。不足している知識を一度に調べようとすると、方向性を誤り、スケジュールに間に合わなくなると判断したためです。品質を担保するために必要な技術は即座に調査し、理解が浅い部分や未解決の技術的課題については、自分専用のメモに記録し、移動時間などを活用して調査を進めました。まずは必要最低限の知識を把握することで、キャッチアップすべき内容を整理するよう努めました。 また、一人で抱え込まないよう意識しながらも、自ら挑戦する時間を設けました。与えられた日程をさらに細分化し、自力で進める作業のタイムリミットを設定することで、効率的にタスクを進めました。このアプローチにより、調査スキルの向上とタスクの遂行を両立することを目指して努力いたしました。 # 使用技術 - 言語: php - フレームワーク：laravel - 使用DB：SQL server - ログ確認：AWS Cloud Watch - その他：Docker # チーム構成 - MG：1人 - PM：1人 - SE：3人 - WEB PG ：2人 (担当) - Android PG：2人 (一部担当) - Swift PG：2人 - QA：2人

# 概要 - 証券アプリ内で表示するWebView画面の実装 - 要件はKotlin, Swiftで実装されているリストと（ほとんど）同じ仕様のリストをWebViewで実現すること - 担当はバックエンド側の実装とビュー側の実装修正 ## 具体的な機能 #### 1.WebView画面表示 - アプリからAPIを呼び出す - バックエンド側でアクセストークンや顧客情報を復号 - 上記の情報をもとにAPI(アプリ内で使用しているAPIと同じ)を実行 - 必要な情報を整形、フロントエンド(WebView画面)にデータを返却 - データをもとにリストを表示 #### 2.WebViewからAPIを実行 - 非同期処理（ajax）でAPIを実行し、リストを更新 ## フロー - 1. アプリからWebView画面表示URLを叩く - 2. サーバー側でAPIを５つ呼び出してデータを整形、ビューにデータを渡す - 3. 上記のパラメータからリストを２つ表示、リストから非同期処理でAPIを実行し、リストを更新できるようにする。 ## 課題 #### 1.短期間での開発 短期間で開発する必要があり、複数人で並行して実装を進めることになりました。その際に認識の齟齬が起きないようにプロジェクトをリードすることに苦労しました。 #### 2. 不具合の調査 - ブラウザやCurlコマンドを用いて画面表示した際はajaxを用いたAPIを実行できるが、アプリのWebView機能を用いて画面表示した際はAPIを実行できない課題があった。 ## 工夫したこと・成果 短期間かつ複数人で開発するにあたってIFの仕様を明確認にするべきと考えました。認識のすり合わせをチームメンバーで行ったのち、どこからどこへ向けて何のパラメータを渡すのか確認し作業をするようにしました。そうすることでアプリの実装、Veiw側の実装、APIの実装を並列して進めることができました。 プロジェクトを進める中で、不具合調査に苦労しました。 具体的には、ブラウザでの動作確認では正常に機能していたにもかかわらず、アプリのWebView機能を使用した際に正常に動作しない事象が発生しました。Web側で動作確認を行った結果、セッション情報が不足していることが原因でエラーが発生していると判明しましたが、その根本原因は特定できませんでした。 そこで、調査範囲を広げ、アプリ側の処理も確認したところ、クッキー情報を削除するコードが含まれていることが原因だと判明しました。実装者が踏襲した処理を十分に理解しないまま処理を実装していたことが要因でした。セッション情報を特定するセッションIDはアプリ側のクッキーに保存されますが、アプリ側の処理でクッキーをクリアしていました。原因がわかり何とかリリースに間に合わせることができました。 この経験から、プロジェクトをリードする立場として、自分の作業に問題がないかを確認するだけでなく、チーム全体が同じ認識を共有しているか確認する重要性を学びました。これからはリードされる側からリードする側に考え方をシフトしていく必要性があると痛感しました。

# 概要 - webサイトから製品の保証書を申請、審査、発行できるシステムを開発 - 申請する際は製品の購入者だけでなく、販売店舗が代理申請できる使用にする - 申請された内容を判定する際の管理画面の作成 # 主な機能 - 購入者が所持している書類をアップロードする機能 - アップロード画像内に含まれるQRコードを読み込む機能 - 申請内容のバリデーション - 申請内容を承認または否認にする機能 - 申請内容から保証書を作成、ダウンロードする機能 - 購入者に代わり販売店が代理ログインできる機能 ## 課題 初めて実装する内容が多く、課題解決の見通しを立てることに苦戦しました。特に、QRコードの作成やPDFファイルの生成に関する技術の記事が古く、最新の知識をキャッチアップするのに時間がかかったことが課題でした。 ## 工夫したこと・成果 タスクをさらに細分化することで効率的に対応しました。具体的には、実装すべき機能を小さな単位に分解し、それぞれに調査時間と開発時間を割り当ててタスクを管理しました。また、その進捗や内容をテックリードの先輩に報告し、認識のずれによる無駄な時間を減らすよう努めました。 調査の際には、シンプルなサンプルコードを書くことを心がけました。これにより、理解している点と曖昧な点を明確にし、初めて取り組む機能であっても期限内に実装することができました。コードを書く際には「理解しているつもり」にならないよう、一つひとつの処理を深く理解することの重要性を学びました。 この取り組みによって、技術的な課題を克服しながら、効率的なタスク管理と確実な実装を実現しました。

# 概要 - 証券アプリにて連携するポイントカードの追加の伴い、アプリで表示するリストを修正する - 具体的にはレイアウト修正と表示判定、データバインド等を修正した。 ## 課題 #### Kotlinの実装が未経験でだったこと - 自己学習にてコードを書いたことはあるものの、案件として初めての挑戦でした。 ## 工夫したこと・成果 新しい言語を学ぶ際に抑えるポイントを整理しました。 本案件に入るまでにPHP, JavaScriot(JQuery, Vue.js), CSSを経験しました。 その際に共通として抑えたポイントを整理して実装に入るようにしました。具体的にはアーキテクチャの理解とエントリーポイントを確認することを大切にしています。 どこから何が実行されているか、クラスの役割などを確認しました。また、検索して調べるだけでは理解が不十分なので、Laravelならどう書くかなど他の技術とも比べて一つ一つの処理を丁寧に理解するように努めました。 既存コードを読みコードを紐解くことで、案件特有の書き方も理解することができました。 ## この経験から得たこと 新しい技術のキャッチアップ方法として勉強の切り口を見つけることができた。

# 概要 - スポーツジムアプリの計測データを登録、取得するAPIの開発 - 社内案件のスタブ作成 ## 主な技術 - AWS - API Gateway - Lambda - DynamoDB - Cloud Watch - TypeScript # 詳細 計測データを登録・取得するAPIに対し、カラムの追加対応を行いました。 加えて、リクエストパラメータのバリデーションを追加・修正し、データ登録および取得処理の修正も実施しました。 また、複数プロジェクトのスタブをAWSとTypeScriptを用いて開発・運用しました。 ## 課題 Lamudbaに関する知識がほとんどなかったため、システム全体を理解することに苦労しました。 また、TypeScriptについては自己学習を経て手を挙げた案件でしたが、Laravelとの違いが大きく、特にAWSに関連するコードの理解に時間がかかりました。 ## 工夫したこと・成果 課題の多くがAWSに関する記述であると分かったため、まずはAWSの調査から始めました。 TypeScriptについては、関連書籍を読みながら既存のコードを解析し、理解を深めるよう努めました。 調査が進む中で、理解した内容や不明点を定期的に報告し、学びの方向性に不足がないかを確認した。 その結果、次に作業が振られた際には、細かな指示を受ける前に自発的に詳細設計や実装ができた。 この経験を通じて、新しい技術をキャッチアップする力と自信がついた。

# 外部連携用APIの設計・実装 ## 概要 - 外部システムとトークンを共有するためのAPIを設計した。 - 既存APIのセキュリティを見直し、より安全なAPIを設計した。 ## これまでの実績 - APIの実装、設計は経験があるものの、個人情報や金融関連の高い安全性の高いAPIの設計は未経験だった。 - 最低限のセキュリティを満たしているAPIや既存に習ったAPIの設計は経験がある状態だった。 ## 課題 - 安全性の高いAPI設計を行なったことがなく、セキュリティに関する知識が不足していたこと。 ## 行なったこと - これまで開発に携わった案件のAPIの設計を確認した。 - APIの設計や攻撃手法について書籍を呼んで勉強した。 - 早めに設計を上司や先輩に相談し、セキュリティに過不足ないか意見を伺った。 ## この経験から得たこと - 安全なAPI設計 - ステイトレス、ステイトフルの良し悪し - ヘッダーパラメータ、リクエストパラメータの種別 - デバックに関する知識 ## その他感想 APIの実装はこれまで経験してきたが、理解していないままの内容があった。 APIの設計の知識だけでなくデバック方法の知識も広がった。 この経験を通して別の角度（プログラミング）以外から勉強してみる重要性を学んだ。 設計の勉強もしつつ今後のキャリアに繋げていきたい。

#　外部APIのアクセス数を削減 ## プロジェクト概要 * 高頻度でアクセスする必要のないAPIのアクセス数を削減した。 ## 詳細 * レスポンス内容が一日毎に変更される外部APIを複数回リクエストしている状態。 * アプリの画面を開く際にAPIを実行しており、クライアントの運用費用が1億円以上かかっている状態だった。 * 運用費削減のため、外部APIは一日に一度だけ実行し、レスポンスをDBに保存。 * 2回目以降のアクセスはDBにあるデータをレスポンスとして使用することで外部への接続数を減らす。 ## 開発メンバーと役割 ### メンバー - マネージャー: 2 - PM: 1 - SE: 1 - PG: 2 　自分 + 未経験エンジニア - QA: 2 ### 役割 - PGのテックリード - 未経験エンジニアの指導役 ### 課題 #### 未経験エンジニアAさんの力を最大限引き出すこと 本案件には当初、ベテランエンジニアと私の二名で参画する予定でした。 しかし、ベテランエンジニアが参画できなくなったため、急遽未経験のエンジニアAさんの指導を併せて担当することとなりました。 限られた時間の中で、後輩の育成とAPI開発の両立を求められ、業務遂行に苦慮する場面があった。 #### 自身のスキルアップ これまで開発されてきたAPIを踏襲するのではなく、より拡張性・保守性の高いコードを考えるように依頼を受けた。 ### 工夫したこと・成果 #### 以下の二つを行うことでAさんの力を最大限引き出すことができた。 - 1. 作業の細分化 開発すべきAPIの数やその内容を精査しました。 分離できる作業の有無、優先的に開発すべき箇所、各APIの類似点の洗出しをおこないました。 - 2. Aさんへの作業説明とスキル確認 スキル確認と言いますと偉そうですが、想定外の問題が起きないように未確定事項を減らすことが重要だと考えました。 案件の説明を行ったのち、スクールにてAさんが学んだことを細分化した作業と照らし合わせスキルレベルを確認いたしました。 上記を行うことでAさんができること（マイグレーション作成など）を見つけ作業を依頼することができました。 Aさんが作業をしている間にAPIや共通処理の実装することでAさんに踏襲できるAPIを提供しつつ、作業も分離することができました。先に実装が完了した後は作業を巻き取るのではなく、一緒に考える形でサポートを行なった。 作業の細分化やスキルの確認を先に行なったことで開発を日程通りに進めつつ育成ができる状態を実現できました。 #### 拡張性・保守性の高い処理の実装を行うことができた まず初めにマネージャーが実装に関する勉強会を開催していたのでそれに参加し、改めて拡張性・保守性の高いコードとは何か学びました。OCPや単一責任の法則（SRP）などを教えていただき、これまでの経験と照らし合わせ、振り返るようにしました。 また、マネージャーへのレビュー頻度をこれまでより多くしました。共通処理も含め、API一つだけ実装した直後にレビューを行なってもらい、何度がご教示いただく機会を作りました。勉強会での知識獲得とレビューを繰り返すことで拡張性・保守性の高い処理を理解して実装することができた。 #### この経験から - 未決定事項を優先的に解消することの重要性を学んだ。 - 拡張性・保守性の高いコードを書けるように今後を意識して実装するとともに他のエンジニアの方への意見を聞く機会を増やしていきたい。

概要 PHP, Laravel, mysql, Dockerのアップデートを行い、 新規サーバーへリソースを移管するプロジェクト 変更点 サーバーソフトウェアOS: CentOS→almaLinux PHP: 7.5→8.2 Laravel: 6→12 mysql: 8.0→8.4 責任範囲 サーバー移管はサーバー管理する会社が担当 用意された新環境にアップデート後のリソースを移管する 課題 アップデートの調査の経験がなかった。 どの会社も対応していない作業があった。 ファイルの権限がサーバ管理会社によって変更されていた バージョンアップに伴いパッケージの互換性が合わなくなること 開発メンバーの変更 プロジェクトのアップデート対応を進める中で、先輩エンジニアやGitHub Copilotを活用しながら課題を解決しました。バージョンアップ後にSDKが仕様変更のため利用できなくなり、SDK呼び出し箇所を修正する必要が発生しました。関連ドキュメントが乏しい中、SDKの中身を解析し、信頼性の高い情報をCopilotに学習させることで必要な知見を得て対応しました。テスト完了後、公開準備を進めたところ、本番環境の権限設定が報告なく変更されていた問題に直面しました。検証環境との権限差異を解消するため、セキュリティ要件を見直し、適切な権限設定に調整することで解決しました。 また、環境切り替えの際には最新データを新環境に移行する必要があり、サーバー管理会社に依頼しましたが担当外と回答されました。本プロジェクトはサーバー管理会社主体で進行していたものの、データ移管の担当が明確化されていないことが判明しました。途中から案件を引き継いだこともあり、資料を確認し前担当者にも確認をとりましたが、自社の責任範囲に留まる内容のみ把握している状況でした。どの会社もデータ移行を担当作業外という認識でした。最終的にはデータ移行作業も対応し、プロジェクトを完了したものの、スケジュールには大幅な遅延が生じました。 開発メンバー PM 1人　（プロジェクト途中で退職） SE兼PG 1人　自分 QA 1人 振り返り ・バージョンを大幅にアップデートする際は、メジャーじゃないパッケージの互換性も考慮に入れて見積する必要があるとわかった。 ・ドキュメントが少ない場合はCopilotにSDKの中身を学習させることでより精度の高い情報に辿り着ける。別のバージョンの情報と混同しない情報が得られる。 ・サーバー移管を伴う場合は権限の変更は極力行わなず、別の期間で対応できないかキックオフ時に提案する。 ・別の会社の担当作業も確認し、必要な作業が漏れていないか確認する。