cokejunkie8191

# プロジェクト概要 ## 目的、背景 - 越境ECシステムの運用保守、および機能改修 ## 担当した役割 - フロントエンドエンジニア - バックエンドエンジニア - 開発環境の改善など # 取り組んだ課題 - 開発環境の改善に積極的に取り組んだ。具体的な取り組みとしてはフロントエンドの開発環境にDockerを導入し、VSCodeのRemoteConteinersを使って拡張機能やコード整形のルールなどが開発者で統一できる仕組みを構築した。また、ローカル開発環境の構築を簡素化したことで、環境構築の手間を大幅に削減した。 - 決済プラットフォームの新規導入時にUI改修を担当したが、一度目のリリースで重大な不具合が発覚したため再設計が必要となった際に積極的に設計に関わった。バックエンド、フロントエンドの観点で工数や実現の難易度などの観点から複数の案を掲示し、それぞれのメリット、デメリットもまとめた上で提案を行い、バックエンド担当エンジニアとコミュニケーションを密に取りながら開発を行い、再リリースし、安定稼働に大きく貢献した。 - フロントエンドのエラーが発生した際にSlackに通知する仕組みは元々あったが、分析がしやすいように業務の隙間時間を使ってエラーごとの発生頻度を可視化するツールをGASとGoogleDataPortalを使って構築した。その結果、発生しているエラーの確認作業に毎日30分程度掛かっていたものを3分程度に短縮することができた。また、発生頻度の高いエラーがいつから発生しているか？という点の確認も容易になり、エラー対応の優先付けを効率良く行えるよう改善した。 - シェルスクリプトを書いて運用保守や開発の効率を上げる小さな改善に日々取り組んだ。具体例は以下を参照。 - 複数台のサーバーに散らばっている決済のログからエラーが発生している箇所を出力する - 10台を超えるインスタンスのストレージ容量を1度に取得する - ローカルのコードを開発環境にアップロードする - 手順が複雑化していたフロントビルドをスクリプトを実行するだけで行う

# プロジェクト概要 ## 目的、背景 - サブシステムごとに独立していた管理画面の統合 - 禁制品フィルターシステム、メール配信システム、レビュー管理システムのAPI化 # 担当した役割 - Dockerを使ったローカル開発環境の仕組み作り - フロントエンドをSPAで実現するための共通基盤の実装 - ユーザー管理機能の開発 - 禁制品フィルターシステムのAPI開発 # 取り組んだ課題 - SPAでの開発は今まで社内では前例がなく他の開発メンバーはフロントエンドの経験が少なかったが、これまでの開発経験を活かして開発をリードし、以下に取り組んだ。 - フロントエンド - 各入力項目の共通コンポーネントを作成し、バリデーション表示の仕組みを共通化 - http通信の汎用的なエラーハンドリングの実装を行い、冗長な記述を不要とした - storeを導入し、アプリケーションの状態管理の簡素化を実現した - モックAPIを導入し、フロントエンドとバックエンドの分業体制を可能にした - バックエンド - 実装を担当したAPIにテストコードを書き、品質向上に貢献した - 元々サブシステムはすべてPHPで実装されていたものの、サブシステムごとに使用しているFWがバラバラだったためすべてLaravelに統一し、元々は無かったローカル開発環境の整備も1から整備を行なった。PHPでもブレークポイントを置いてデバッグできるよう、XDebugの設定を行ったことで開発効率を向上させることができた。

# プロジェクト概要 ## 目的、背景 - 重機のレンタルを行っている会社向けの業務システム - 貸出前後の商品を専用のAndroid端末で撮影し、商品の傷や汚れなどの状態を管理 - 商品の貸出履歴や帳票印刷などの管理機能をWebアプリケーションとして実装 ## 規模感 初期開発で10人月程度、以降は年に1人月程度の改修 ## チーム構成 PM: 1名 PG: 1~2名 ## 担当した役割 - 初期開発ではWebの管理機能の開発、アプリを含めたテストや環境構築を担当 - 改修ではAndroidアプリの改修も担当 - サーバーの環境構築も担当 # 取り組んだ課題 - Web側の技術選定も任されたプロジェクトだったので、バックエンドのFWに当時流行りつつあったLaravelを選定。この時点でバックエンドの開発経験がほぼなく、Laravelの日本語の情報も少ない状況だったが、英語のドキュメントを積極的に読み進め、理解を深めながら要件を満たすことができた。 - JavaScriptでの開発経験はプロジェクト参画時点でほぼ皆無だったが、以前に経験していたWPFの知識を活かすことはできないか？という観点でMVVMアーキテクチャのKnockout.jsをフロントエンドのFWに選定。知名度はあまり高くないマニアックなFWだったがデータバインドなどの記法がWPFにかなり近かったため、慣れないJavaScriptでの開発でも低い学習コストで開発を進めることができた。また、ドラッグアンドドロップで写真の並べ替えを行う機能など、ユーザーフレンドリーな機能も提案し自ら実装を行なった。 - 画像をDBでバイナリデータとして保持していたが、当初の想定よりも遥かにデータ量が多かったため、ストレージが枯渇しかけるトラブルに何度か直面した。サーバーをGMOクラウド上に建てていたが、ストレージの上限が決まっていて上限いっぱいでも枯渇しかけていたため、複数のストレージを組み合わせて論理ボリュームを構成するというアプローチを採用した。作業を行う前にvagrant上で建てた検証環境で繰り返し検証を行なったことで、本番環境での作業もトラブルなく対応でき、仕様の限界を超えたストレージを構築した。(最終的にDBの領域として2.5TBくらいまで拡張を行った)

# プロジェクト概要 ## 目的、背景 - スキャンされた保険申込時の書類を管理するためのシステム - Windowsアプリケーションから証券番号などのメタ情報を書類に登録し、アップロードを行う - アップロードした書類はWebアプリケーションから閲覧可能 ## 規模感 初期開発で20人月程度、以降は1年で1人月程度の機能改修 ## チーム構成 PM: 1名 PG: 1~3名 ## 担当した役割 - 開発リーダーとして開発メンバーのフォローをしつつ、自身でも開発を担当 - Windowsアプリケーション、バックエンドともに開発を担当 - サーバーの環境構築を担当 - 保守や機能改修も担当 # 取り組んだ課題 - 保険関連の書類の性質上、個人情報が表示されているものが多く、Webアプリケーションでは「閲覧と書類の印刷のみを可能にし、ファイル保存はできないようにしてほしい」という要件が求められた。それを実現するために印刷ダイアログを表示せずにダイレクトにプリンタに印刷をするという方針で実装することになったものの、類似の事例がいくら調べても見つからなかったが、調べていく中でPDFにJavaScriptを埋め込むことができるということを知り、「印刷する前にPDFを生成し、そのPDFにJavaScriptを埋め込めば印刷ダイアログを制御できるのでは？」という発想に至り、自ら実装を行い問題解決に至った。 - データ連携をしていない他の業務システムとのデータの突き合わせを行い、結果をCSV出力するという機能があり高頻度で改修依頼が来ていたが、テストするためのデータ作成手順が煩雑で完全に属人化してしまっていたため、テストコードを作成し、誰でも簡単に改修、検証が行えるように改善した。 - 開発当初は複数名で1台のサーバーで開発を行っていたため、サーバー上のソースにコンフリクトが発生するなどの問題が発生することが多かった。それを解決するためにはローカルの開発環境が必要と考え、vagrantを自ら学習し、各自がローカルの開発環境で開発を行えるように現場環境の改善に取り組んだ。

# プロジェクト概要 ## 目的、背景 保険代理店で顧客の将来必要となる資金(生活費、教育費、住宅費など)をシミュレーションし、その結果から万が一の事態に備えるにはどのような保険が最適であるか？を提案するためのシステムの新規開発 ## 規模感 初期開発で100人月、その後数年は年間50人月程度の改修 ## チーム構成 PM: 1名 PL: 1名 PG: 3~5名 (時期により変動) ## 担当した役割 初期開発ではプログラミング、テストを担当し、その後はPLとして上流工程や開発メンバーの進捗管理なども担当 # 取り組んだ課題 - 特定の操作を行ったときにモーダルウィンドウで要求された操作を行わずに先に進めてしまうというバグがあり、それが原因で不整合データができてしまうという不具合が発生していた。標準のモーダルウィンドウを使用していては回避できないバグだったため、見た目を標準のものに限りなく似せた形でモーダルウィンドウを自前で実装するというアプローチでユーザーへの影響を極力小さくした上で不具合の解消を行なった。 - グラフィカルなUIを求められたためWindowsフォームでは実現が難しくWPFが選定された。ニッチな技術のため苦労が絶えなかったが、Web検索や数少ない書籍で情報収集を行い、実装を行う際も何度も試行錯誤を重ねながら課題解決に尽力した。 - 自分より歳上で経験豊富な社外のエンジニアが多く在籍するプロジェクトであったため、PL担当時は指示を出す際に気を使うことが多く苦労したが、丁寧なコミュニケーションを心掛け、技術的な課題が発生した場合もできるだけ時間を掛けて問題解決案を議論し、円滑にプロジェクトを推進することができた。

# プロジェクト概要 ## 目的、背景 - 毎年行われる社外の研究活動 - 会員となっている会社の社員が集まり、興味のあるテーマを選択して研究活動に取り組む - 当時感心の高かった機械学習の運用に関するテーマ(MLOps)を選択 ## 担当した役割 AWSのサービスを使ったWeb上での画像認識システムの構築のプログラミングを担当 # 取り組んだ課題 - MLOpsというテーマに従い、どのようにすれば機械学習プロジェクトを効率良く運用できるか？という方向性で議論を重ね、学習データやパラメータを変えて再学習を行い、現在稼働しているモデルよりも高い精度のモデルが生成できた場合に稼働中のモデルを置き換える形でデプロイを行う機能を実装した。 - モデルを生成するための学習を行う機能、精度の検証を行う機能、稼働中のモデルとの精度の比較を行う機能をLambdaで実装し、StepFunctionsで各機能を繋ぎ合わせることで実現することができた。 - 運用面を考慮して、生成したモデルの精度やデプロイが行われたかなどをSlackに通知する機能の実装も行なった。 - フロント部分のソースコードのリポジトリにプッシュされると自動でデプロイされる機能もCodeCommitを使って実現した。 - 機械学習、Python、AWS、使用した技術はいずれも使用した経験がなかったが、プライベートの時間で学習を重ねて理解を深め、前述の機能をほぼ一人で実装することができた。