ID:53687さん

<h2>旅行会社向けチケット管理システムの新規開発【2024年4月〜2024年12月】</h2> <h3>職種・役割・担当工程・チーム規模</h3> * 職種：バックエンドエンジニア / フロントエンドエンジニア * 役割：メンバー * 担当工程：デザイン / 設計 / 開発環境整備 / 画面作成 / 実装 / テスト / 運用・保守 / * チーム規模：8人 * 業務委託として参加し、外部会社の方と実施した。 <h3>プロジェクト概要</h3> 関西万博に向けて販売されるチケットの管理を旅行会社で行うため、社内管理システムとして新規の開発を行った。 <h3>実績</h3> * 開発環境の構築、SVNの使い方、コーディング規約が現場で決まっておらず、人員拡大のタイミングで入る新規参入者が困惑して業務に支障が出ていたため、ドキュメントを作成し情報に格差がないように対応。 * 0→1の新規開発だったため、フロントエンドを担当。 * 画面作成では帳票系の出力画面、ログイン画面の画面設計と実装を行った。 * 特にJavaScript, JQueryに関しては業務で担当することが少なかったがキャッチアップし改修タスク、動的処理を担当した。 * 処理機能の基本設計書の作成と改修 * フェーズが新しくなる時に新規機能として実装される時に要件を聞き、既存機能とにている設計書があればそれを叩き台にするなどで基本設計書の作成を行った。 * 他メンバーの実装機能レビュー時に、実際の動作と設計書の内容とで異なる部分があった時に設計書が間違っていた場合、確認をとり設計書の内容を改修した。 * ログイン機能の新規実装 * Laravelの認証サービスを使い画面作成、機能実装を担当。 * 社員IDとパスワードでログインするのが要件だったが、Laravelではメールアドレスとパスワードを想定したログインを採用しているためそこのカスタマイズを調べて工夫して実装を行った。 * バッチ処理の実装 * SFTPサーバーに配置した顧客データのCSVファイルをDBテーブルに取り込むためバッチ処理を複数実装。 * バッチ作成が複数あることを想定し、CSVファイルの展開〜読み込み加工しやすくするために配列データに変換することを使いまわせるように共通化した。 * 帳票出力処理機能・CSVファイル出力機能 * 過去にPDFを出力する機能を実装していた経験を買われ、帳票とCSVファイルの出力機能を複数実装。 * パフォーマンスチューニングで既に実装されていたCSVファイル出力機能の改修を行なった。 <h3>課題</h3> * 他メンバーが実装していた既存機能のCSVファイル出力機能で出力件数の上限が5万件で、その上限を無くすために処理時間を測定していたところ極端なパフォーマンス低下、バグが見られた。 * 30万件以上の在庫チケットのデータが登録されている場合、一覧全てをCSVデータに変換しファイルとして出力するときに<b>10分以上レスポンスが返ってこない。</b> * ファイル出力完了に時間がかかりすぎてタイムアウトが発生し通信が切断される。 * メモリが足りなくなり、エラーが発生していたため設定ファイルに追記しないといけないほどだった。 * 3タブで同時実行を行うとステージング環境のサーバーが落ちてしまい、再起動が必要になるほどCPU負荷がかかっていた。(`top`コマンドで確認したところ100%CPU負荷がかかっていた) 元の原因をそのままにしていたらキリがないため朝のミーティングで相談を行い、修正が必要だとチームメンバーと相談して改修することが決定。 * 既存の処理でどこがボトルネックになっているのかを確認するために実行時のメモリ消費量(`memory_get_usage()`を使用)、処理時間の計測(`hrtime()`を使用)を行った。 * `foreach()`で1行ずつCSVデータを配列にしてデータを加工する処理を行っていたためそこで時間がかかっていたことが発覚。 * ファイル出力としては`PHPでfpassthuru()`を使用しており、CSVデータをファイルに書き終えてからやっと出力をしていたためメモリが足りなくなっていたことが判明。 * そしてレスポンスが遅くなり、接続が切られていたため出力処理が完了せずに終了していた。 * chromeで動作検証を行っていたところ接続が切られた後に自動でリロード処理が走ってしまい複数回処理が走りサーバーに負荷がかかっていたためサーバーが落ちる原因になっていた。 <h3>工夫</h3> * 大量のデータを扱うためLaravelの`foreach()`でデータを加工するのではなく、<b>`chunk()`で1000件ずつ処理を実行するように修正した。</b> * Laravelの`streamDownload()`を使用して、<b>クライアントに送るレスポンスを途切れさせずにストリーミングのデータとして返すように修正。</b> <h3>成果</h3> * 30万件の在庫チケット一覧のCSVファイル出力を<b>約5分に縮小させサーバーが落ちる心配もなくなり複数同時の出力が可能になった。</b> * ストリームダウンロードのおかげでファイル出力が開始されていることが可視化され利用者が使いやすくなった。

<h2>FWに穴あけを実施する社内システムのリプレイス業務・機能修正【2023年11月〜2024年3月】</h2> <h3>職種・役割・担当工程・チーム規模</h3> * 職種：バックエンドエンジニア * 役割：メンバー * 担当工程： 軽微な画面仕様書修正 / 実装 / テスト / 運用・保守 * チーム規模：5人 * 派遣として参加し、外部の会社の方と実施した。 <h3>プロジェクト概要</h3> 社内のFWに穴開け設定を行うシステムをMySQLからPostgreSQLに移行、PHPのバージョンを上げるver. 5からver. 7に移行するために影響箇所の改修、機能実装を行った。 <h3>実績</h3> * 冗長なコード等確認して上長に相談しつつ移行時に改修を行なった。 * smtp認証のメール送信処理の実装を行った。 * 初のフルリモートだったが、teamsのメッセージでこまめな進捗報告、バグの改修・確認については自主的に対応することを発言し信頼を得てコミュニケーションが取りづらくならないようにしていた。 * 未経験の技術のキャッチアップ等 * PostgreSQL * 自己学習を行い、実践をして1週間でMySQLからPostgreSQLの移行を行えるようにキャッチアップを行った。 <h3>課題</h3> * リプレイス業務前にコードを確認していたところ生のままSQL文が書かれている箇所を発見。 * SQLインジェクションの危険性があったため修正の必要性があると考えた。 <h3>工夫</h3> * リプレイス後に、上長に相談を行い許可を得てからリファクタリングを行い、バインドするように改修を行なった。 <h3>成果</h3> * リプレイス後にアラートが発生することなく期待した更新・登録処理ができていることが確認できた。

<h2>自社サービスの飲食店・店舗情報WEBサービスの機能改修業務・社内システムの新規開発・運用保守【2022年2月〜2023年9月】</h2> <h3>職種・役割・担当工程・チーム規模</h3> * 職種：バックエンドエンジニア * 役割：メンバー * 担当工程：設計（DB設計、API設計） / 実装 / テスト / 運用・保守 * チーム規模：10人 <h3>プロジェクト概要</h3> 自社サービスの飲食店・店舗情報WEBサービスの既存機能でアラートが発生している部分の改修業務と、自社サービスの新規リニューアルに伴い社内で使用する決済管理システムの開発を行なった。 <h3>実績</h3> * 飲食店・店舗情報WEBサービスの既存機能の改修 * コメント掲載時のお知らせやキャンペーン、店舗予約時等で利用者に送信するメール配信の方法として、クラウドメール配信サービスのSendGridに移行する時にAPIを使用し実装を担当した。 * アラート検知した障害の対応を行なった。 * 社内で利用する決済管理システムの実装 * マネージャーと2人で設計と実装を行い、Laravelの経験者が私のみだったためプルリクエスト時のレビューでは効率的なコードの書き方の提案を自発的に行っていた。 * DB設計 * 業務では未経験だったDB設計は個人で学習しキャッチアップを行い、設計した。 * confluence記載の要件を元に情報を整理しテーブルとカラムの洗い出しを行い、テーブルとカラムを1度形にしてDB設計に詳しい先輩にレビューを依頼して正規化のヒントをもらうなどを行い設計を行った。 * メンバーが少なくて口頭・メッセージで環境構築方法について話していて属人化していたため内容を記載。 * REST API設計 * リクエストURLやHTTPメソッドの選定、クエリパラメータの値、レスポンス形式の設定等を行ないドキュメント化した。 * フロントエンドチーム担当の方と連携をとり、バックエンドチーム側だけがわかっている状態にならないように情報共有を行なった。 * 未経験の技術のキャッチアップ等 * バグ改修業務時にログの確認を行うときに使用するツールが業務で未経験だったため、自主的に学習して確認方法をキャッチアップし、改修業務に活かした。 * Datadog * ログ監視。1日で使用方法を学び、日々使用していくことでキャッチアップした。 * AWS （CloudWatch Logs、EC2） * ログ監視。1日で使用方法を学び、日々使用していくことでキャッチアップした。 <h4>課題①：障害対応</h4> * 他部署が使用する既存機能の管理画面の操作で、別ページにアクセスしたときに準備していたエラー画面が表示されない現象があった。 <h4>工夫</h4> * Jiraでチケットを受け取り業務を進める方法は未経験だったため、先輩に確認を取りつつ実践した。 * 発生時にSlackでアラートが検知できるようになっているため、そこからエラー内容とリファラを確認し原因を確認。 * <b>自社サービスで利用する社内の社員が使用する管理画面であること、リファラが参照元なしの状態だったことから直接URLのクエリパラメータを変更してアクセスしたときに打ち間違えが発生したことから起きた現象</b>だと判断。 * 準備した404 Not Foundの画面にリダイレクトさせるために管理画面の既存機能部分でステータスコードが適切に返せていなかったためそこの修正を行ないプルリクエスト、レビューを受けてからGitLab CI/CDを使いリリースを行なった。 <h4>成果</h4> * アラートの原因になったURLに直接アクセスしたところ、準備した404 Not Foundにリダイレクトしてアラートが鳴らないよう状態になったことが確認できた。 <h4>課題②：メール送信機能の改修(PHPでの送信からSendGridの移行)</h4> * メール内容については他部署が内容を考えており、新しいメールを送信したい時や内容を修正して反映させたい時に、メールテンプレートはコードに記載されているため開発部に依頼してコード修正を依頼しないといけない手間が発生していた。 * 開発部メンバー内でメール内容修正のタスク対応を行わないといけないためどちらの部署ともに手間がかかっていた * お知らせメールのキャンペーンの反応(添付URLからアクセスしたかの確認)、コメント掲載の連絡メールが到達できているかわかりにくく他部署が分析できない状態だった。 <h4>工夫</h4> * チーム内ミーティングで話し合いクラウドメール配信サービスのSendGridに移行することとなったため、SendGridのAPIを利用し対応を行った。 <h4>成果</h4> * ほぼ確認が不可能だったメール到達率の可視化ができるようになった。 * 開発者以外もSendGridの管理画面からメールテンプレートで内容を修正できるようになり業務の分担ができて各々の作業が滞らない状態になった。 * 開発部は送信処理の実装、メールIDの管理のみでメール内容の管理をする必要がなくなった。

<h2>金融業務向け社内システムの改修業務【2021年11月〜2022年1月】</h2> <h3>職種・役割・担当工程・チーム規模</h3> * 職種：バックエンドエンジニア * 役割：メンバー * 担当工程：実装 / テスト * チーム規模：3人 * 派遣業務として参加。(SES) <h3>プロジェクト概要</h3> 社内で使用する稟議書の承認依頼を行うシステムに機能改修を行なった。 <h3>実績</h3> * 初の派遣先での業務で信頼を得るために、こまめな報告と進捗連絡、実装期日の宣言を行ったことで自社から1人増員することができた。 * 機能改修したものについてはドキュメント化し、情報共有できるようにしていた。

<h2>客先面談の面談報告書をWeb上で閲覧できる社内システム【2020年10月〜2021年10月】</h2> 2020年10月〜2021年4月の間に研修を行い、社内のシステム開発業務にアサインされることとなった。 <h3>職種・役割・担当工程・チーム規模</h3> * 職種：バックエンドエンジニア * 役割：メンバー * 担当工程：設計(修正担当) / 実装 / テスト * チーム規模：3人 * 元はマネージャーのみ担当しており、途中から参加となった。 <h3>プロジェクト概要</h3> 誰がどこに行って面談をしたか業務担当者からどんなことを聞かれたかについて、いちいち聞かないといけなかったため社内での業務効率ツールとして実装。 <h3>実績</h3> * 研修を行ってから初めてチームとして社内システムを作成する役割として携わり、開発の流れ〜チームレビューを実際に体験することで理解した。 * コードレビューを通して、バージョン管理ツールの流れを掴んだ。 * 下記のCRUD機能を実装した。 * 社員情報と顧客情報の登録機能 * 社員情報と顧客情報の編集機能 * 社員情報と顧客情報の削除機能 * 面談内容の新規登録 * 面談内容の編集 * 面談内容の削除機能 * MVCモデルの設計パターンをもとにして実装する基礎を身につけた。 <h3>課題</h3> * レビュー時に基本的な規約が決まっていなかったためレビュー時にコードが読みづらく解読するのに時間がかかり、レビューや改修を行うときに1時間ほどかかっていた。 * これについてはメンバー同士が他の人のコードを読むのに慣れていなかったこともある。 * 適切な改行、半角スペースが開いていないこと、コメントの記載がないことが読みづらくなぜそこの処理が書かれているのかの解読が困難であった。 <h3>工夫</h3> * ミーティング時に書籍：リーダブルコードを参考に何を目的にして処理を行なっているかのコメントの記載、コメント直前は改行を開けること、インデントと半角スペースを適切に入れること(プラグインの導入)などを規約としてドキュメントでまとめて共有を行なった。 * <b>チーム開発をする上でコードは自分だけがわかっているだけでは不十分であり、数ヶ月後の自分や他メンバーが参入した時に可読性を上げておくことが効率的に業務を進むことができるため誰が参入しても確認できるようにした。<b> <h3>成果</h3> * 自分も含め他メンバーがレビュー時に解読する時にかかる時間が20~30分まで短縮することができた。 * 規約に記載した内容をレビュー時にツッコミすることがなくなった。