yuyyyy

# 職務要約 既存サービスの改修・新規サービスの設計・実装を行う。 主にサーバ側にてAPI実装（swagger・rspec含む）を行う。 # 概要 　［規模］10名前後 　［役職］バックエンドエンジニア 　［ポイント] 0ベースからのシステム設計＆環境構築＆開発を一人で行う # 身についた知識・スキル - NestJSによる実装 - 複数サービスの連携 - PlaceAPIによる地図情報の操作 - SvelteKitによる実装 # 職務詳細と工夫したこと ### 伝わりやすいドキュメント管理やコード実装 多国籍メンバーが在籍しており、かつ、メンバーの入れ替わりも比較的多い環境でした。 そのため、情報共有や残すドキュメント、実装コードやコメントなどにおいて、認識の齟齬が発生しにくいよう・理解しやすいよう努めました。 具体的な一例としては、複雑なロジックやコンポーネントはより多くの人が理解しやすいようなるべく実装をシンプルにし、lintツールによる整備を徹底することで、保守性を向上しました。 どうしてもシンプルにしきれない部分や仕様上どうしてもわかりにくい所は別途仕様や実装背景などを積極的にコメントやドキュメント化しました。 また、ISSUEやPRも第３者が見ても状況がわかりやすいよう、「How」だけでなく「Why」を残す事を徹底しました。 ### 会社全体のスキルセットと今後の方向性を鑑みた技術選定やシステム設計 新しいアプリケーションを０ベースで実装を任された際、技術選定に悩みました。 自分のスキルセットや流行・会社全体の開発メンバーのスキルセット等を鑑みて、 この会社において管理がしやすく長期的に運用しやすいよう選定し、実装しました。 当初単一のAPIアプリケーションとしてrailsで実装していましたが、 社内に多種多様なアプリケーションが存在しており、 深く状況を確認すると将来的に機能の一部は他アプリケーションからも呼ばれる可能性が見えてきました。 そのため、単一アプリケーションではなく、「旅程アプリとしてのみのアプリケーション」と「他アプリケーションとの連携も考慮される部分」と切り分けるシステム構成にする事を提案し、採用されました。 その切り分けたアプリケーションの方を、今後TSに寄せていきたいという会社側の希望に則り、NestJSを採用する事にしました。 また、仕様的にDBはGraphQLが良さそうと選択肢に上がりましたが、会社全体的に若手エンジニアが多く、GraphQLの実績も無く、他アプリケーションとの連携も当分先になりそうとの事から、実装速度や保守性を考慮してRDBMSを選定しました。 ### SvelteKitによる管理ツールの提案と実装 管理業務として地図スポットの画像を収集する事を他の作業部隊と連携して行っていました。 その管理業務がgoogleドライブに画像をまず保存して、それをエンジニアが入稿処理を行うという形で手間がかかっていました。 そのため、作業部隊の方が直接入稿処理を行えるよう、管理ツールを作成しました。 その機能自体とても喜んでいただけましたし、 小さな管理ツールだったために少しチャレンジできると思い、許可を頂き未経験のSvelteKITを用いて実装しました。 このように、積極的により良い提案を行い、常に状況把握しつつスキルアップを意識して取り組んでおります。

# プロジェクト詳細 主に楽天市場の店舗さん向けの販促ツールを提供するサービスの開発。 商品やカテゴリ等の各種ページにランキング情報や期間で切り替えるバナー、PCページからスマホ用ページを作成するツール等の多種多様な販促ツールを提供するサービス。 そのバージョン１がCakePHPで書かれていたものを、Laravelにリプレイスするプロジェクト。 # 詳細作業 ## 初期環境構築 新しい開発環境を作る上で、 - 外注者等新しい人でもすぐ環境を構築できるか - API連携のある別システムも含めて問題なく動作できるか 等を考慮して、開発環境とAWS上のステージング・本番環境を構築した。 ## AWS環境の工夫 楽天サーバへの接続が日本IPからしか受け付けないという特殊仕様のため、AWS上の環境は全てNATで日本IPに変換するようにした。（１サーバ１日本IPと結びつけてしまうと、サーバ台数分日本IPを取得する必要があり、オートスケーリングに対応できないため、NATを利用） ## JSフレームワークの選定＆Vue.jsの適応 元々jqueryで書かれていたものに対して規模が大きくなってきたため、jsフレームワークを適応することを提案。 複数のフレームワークを社内メンバーのスキルや導入コスト・運用コスト等を考慮し、Vue.jsを選択。 初期導入も含めて行う。 Vue.jsの知見を持つものがおらず、jquery脳だったので概念から学び、他メンバーに横展開を行う。 ## コーディング規約の導入＆リファクタリング指揮 元々知識の豊富なメンバーがおらず、修正に修正が重ねられ、属人的で複雑なコードになっていた。 それに対して、他メンバーが理解しやすいよう、修正コストが下がるよう、 コーディング規約に則り、仕様も把握しやすい実装になるよう導いていった。 具体的には、PHPMDやCodePHP_SnifferをsiderによりPR単位に指摘されるように導入したり、 毎回のレビューでわかりにくい点や複雑なロジックを指摘し、改善していった。 工夫した点としては、実装者は結局人間であるため、闇雲に指摘するのでなく相手をきちんと見るということ。 一度身に付いた実装方法をすぐ変更して修正するか、頑固に今までの書き方に拘るかは人によって異なる。 そのため、なぜこのような書き方が必要なのか、なぜそのような書き方だとわかりにくいのかを相手の技術や仕様への理解度にに合わせて説明したり、軌道修正を段階的に適応したり、一方的に決めつけるのでなく相手の意思や判断を尊重して指摘したりと、 相手の人間性を尊重しつつ着実にストレスが少なく着実に前に進んでいくよう工夫をした。 # どのような機能を作ったのか ## 受賞ランキングバナー作成機能 楽天市場ではデイリーランキングやリアルタイムランキングがあり、その受賞結果の画像を店舗ページに販促ツールとして設置するニーズがある。 ただ受賞したかどうかを探し、販促画像を作成するのはとても手間なため、それらを自動化する機能を実装。 受賞結果を自動で収集し、リスト表示。 任意の結果を用意したサイズから選んで販促画像をシステム側で作成する。 工夫した点としては、ランキング結果は非常に多くなる場合があるため、 読み込みを非同期で段階的に行い、 ソートもフロントだけで完結させてソートのたびに通信が発生しないようにして操作性を下げないようにした。

# プロジェクト概要 WEB広告の結果をinputとし、機械学習等を用いて効果測定を行い、 次の広告の適切な設定値をoutputするシステム。 なお、このプロジェクトはこの期間に所属していた会社での業務ではなく、 個人で受けた案件である。 # 詳細作業 ## システム全体のインフラ設計 要件定義を確認し、本システムにおいて適切なシステム設計を行った。 （アウトプットはシステム構成図） 工夫した点としては、 - システムが常時稼働する必要が無いこと - コスト面の優先度が高いこと などから通常のインスタンスではなくlambdaを用い、デプロイも運用を考慮してコマンドベースで行えるよう設計した。 ## アプリケーションの初期構築 flaskはrailsのようにデフォルトのディレクトリ構造が無いため、 実装開発を考慮して独自にディレクトリ構造を策定し、 loggerやexception周り、ORMもファイル分割を行い、規模拡大に耐え得る構成で作成した。 本プロジェクトは自分が長く入り続けるわけではないのは決まっていたので、 自分がいなくてもちゃんと開発運用が続けられるよう、コメントやREADMEもしっかりと残していった。 ## カバレッジの網羅＋テストコードの整理 実装優先にしていたためカバレッジが網羅できておらず、 他の方が想定と異なるtestの組み方をしていて複雑化していたので、 カバレッジの網羅とテストコードの整理を行った。 他の方が組まれていたテストがテスト同士密結合になっており、実装を修正した際のテストの修正が非常に困難となっていたため、 疎結合として分解し、修正も容易となるよう調整していった。 ただ、完全に分解して書き直すにはコストがかかりすぎると判断し、適度な所で切り上げ、 それ以上被害が広がらないようにだけ考慮し、理想と現実の折り合いを付けていった。

# プロジェクト概要 女性のための就活・転職相談としてユーザ同士をマッチングし、 やりとりを促すサービス。 途中まで開発が進んでいたがその時の実装者による開発が進まなくなってしまったため、 開発をバトンタッチし、リリース・運用まで受け持つ。 なお、このプロジェクトはこの期間に所属していた会社での業務ではなく、 個人で受けた案件である。 実装は基本自分一人で進め、デザイナーにデザインはサポートしてもらう。 # 詳細作業 ## 要件定義・詳細設計 どこまでができていてどこからができていないのか、 最終的にどんなイメージかを確認し、設計を進めていった。 依頼者も資金的に余裕のある方ではなかったので、追加したい機能とコスト感・工数を都度比較検討し、 互いに納得する仕様を設計し、進めていった。 リリースが伸び伸びになっていた事もあり、「早くリリースしたい」という点の優先度が高かったため、 とりあえずリリースできるミニマムの形の設計と理想形の設計を行い、段階的にリリースするようスケジュールに落とし込んでいった。 ## 実装方針変更への対応 リリース後、ユーザの反応によって実装の変更が入る事がちょくちょく発生していた。 結果的にうまくいった点ではあるが、最初の実装の段階で依頼者の思いを理解し、 変更の可能性をある程度考慮して変更に耐えられるよう疎結合で実装していた。 そのおかげもあってか変更があってもスムーズに変更していくことができた。 システム全体としても修正によってツギハギだらけの複雑化させることなく、属人化させずにシンプルでわかりやすいコードを維持することができた。 # どのような機能を作ったのか ## チャット＆ビデオチャット機能 互いに承認したユーザ間でリアルタイムチャットができる機能。 また、互いに希望があればビデオチャットもできるよう実装。 ビデオチャットは外部サービスを埋め込む形とし、低コストで実装。 リアルタイムチャットができるようrailsのAction Cableを使用。 LINEなどの見慣れたUIになるようイメージを合わせ、既読機能も付与。