ID:63889さん

# プロジェクト概要 - 男女のマッチングサービスの追加開発 - 受託開発でクライアントからの要望を聞いて見積もりを出して開発をしていた。 - 中規模プロジェクト # 担当した役割 - クライアントとの提案、見積もり、およびバックエンドからフロントまでを担当しました。開発ドキュメントが全くない状態でソースコードからアプリケーションの構成を把握して、クライアントの機能要件を満たす開発、リリースを行なっていました。 # 主要機能 - 課金処理 - リアルタイムチャット - いいね、足跡 - 通知(メール、LINE) - ランキング - ユーザー検索周り …etc # 技術スタック - フロントエンド : Vue.js, JavaScript, Sass - バックエンド : PHP/Laravel , Node.js - インフラ : AWS(EC2, RDS, Cloud Front, S3, Cloud Watch), Docker - その他 : MySQL, Firebase Authentication, Firestore # チーム構成 - バックエンドエンジニア 1 ~ 2名 - ディレクター 1名 # 出したバリュー(取り組み) ## 引き継いだソースコードから仕様理解・要件定義・画面設計を抽出 ### 課題 - 引き継ぎ開発であったが、開発に関する情報が全くなく、要件や仕様、デザインの詳細が不明でした。開発状況が不透明であったので、クライアントとの開発やリリース方針については議論が難航していた。 - ソースコードは冗長的な箇所が多く、今後の拡張性のことを考えて設計やソースコードを改修する必要性があった。 ### 改善・工夫したこと - ソースコードを頼りに、スプレッドシートで機能一覧と画面一覧をまとめて、サービスの要件と仕様を共有した。その結果、開発進捗が共有できてクライアントとの開発方針の議論が進んでいった。 - ソースコードは処理を別ファイルに切り分けたり、コンポーネントで共通化にしたりと今後の開発のことを考慮して設計・開発をした。 ## 画面UI/UXを意識した実装と改善 ### 課題 - 追加開発でHTML要素の「opt-group」を使ってグループ毎のデータ取得を実装しているときに、既存のライブラリではうまく`UI/UXの仕様を満たせない`課題があった。 ### 改善・工夫したこと - vueのライブラリ「Element-UI」を使って、他のページでも使っているプルダウンメニューのUIに合わせることができた。また、グループ毎にデータが入っていることを直感的に見やすくした。 - スマホユーザーが多いので、項目をタッチする範囲を広げたりと使いやすさを改善した。 - フロント側だけでデータ取得するのは難しかったので、バックエンドでデータをリレーションさせてからデータ取得して、フロントに渡すことによって、HTML要素のopt-groupとうまくデータの連携が出来る様に実装ができた。 ## セキュリティ改善 ### 課題 - 既存の実装では、ユーザー同士のチャットの内容などが格納されている`Firestore` に誰もがアクセスできる状態で、極めてセキュリティが低い状態であった。 ### 改善・工夫したこと - `Firestore`のアクセスに対して、firebase authenticationを使用して、firebaseに適切なセキュリティルールを設定し、該当するユーザーのみがデータにアクセスできるように改善した。 # 開発で工夫したこと - API開発をするときは、バックエンドでデータをある程度整形してからフロントに渡すようにしていました。フロント側で無理やり作ってしまうと可読性が悪くなってしまうので、できるだけバックエンドで整形してからフロント側で渡すようにした結果、フロント側のコードが読みやすくなった。 - このプロジェクトは元々はMVCパターンを使っていましたが、FatControllerになっていたので、ソースコードの一部分をInterface、Service層を使って処理をわけるようにした。その結果、直感的に機能毎の処理がわかるようになったのと、今後の新規機能開発がやり易くなった。 - 提案で複数パターンがある場合は代替案を出してメリットデメリットや要望に応えるように調整した。 - 開発が確定したら、Backlogなどでスケジュール管理、notionで要件定義や仕様などドキュメント作成をした。仕様が確定したらなるべく早く言語化して整理してまとめる工夫をした。 - 開発メンバーやPMがプロジェクトに入れるスキーマが少なく、クライアントとの会議、追加開発の要望の提案、見積もりなど1人でやることが多くあった。1人でこれらのことをやると抜け漏れが発生するので、徹底的にクライアントに確認をとる、notionなどのドキュメントにまとめるなどをした。その結果、ほとんど遅延なく、認識齟齬が発生しないで開発を進めることができた。

## 節電ポイントの申請サイト開発 ### プロジェクト概要 - 節電ポイントの申請フォームの開発 - 申請画面と管理画面の作成 - 受託開発サービス ### 担当した役割 - PLから振られたタスクを開発していました。バックエンドとフロントエンドの開発を担当しました。担当した機能開発をはじめ、ドキュメントの作成、テストコードの作成、先を見据えての開発を意識して実装しました。 ### 主要機能 - 申請フォームの作成 - ステータス機能 - ロック解除のon・off機能 ### 技術スタック - フロントエンド : JavaScript、TypeScript、Vue.js - バックエンド: PHP8.0、Laravel8、 - インフラ: AWS、Docker、CircleCI - その他: MySQL, PHPUnit、Backlog、notion ### チーム構成 - ディレクター 2人 - PL 1名 - バックエンドエンジニア 6人 - フロントエンドエンジニア 1人 - QA 1人 ## 出したバリュー(実績) ### チーム開発のメンバーとして積極的に行動した ### 課題 - このプロジェクトはスピードを意識した開発をやっていたので、どうやったらチーム開発貢献ができるか悩んでいた。 - チームのメンバーのほとんどがリモートワークだったので非同期のコミュニケーションだけではどうしても伝わりにくいところがあった。 ### 改善・工夫したこと - タスクを早く終わらせたら次のタスクを振ってもらうように、どんどん手を上げた。仕様での認識齟齬が発生しないようにslackや会議でディレクターに確認して実装を進めていった - 機能のリリース前や急ぎのバグ対応が起こった時はSlackのハドルを繋ぎながら状況確認を伝えていった結果、非同期のコミュニケーションの時に比べて時間がかからないで実装やリリースができた。 ### 自分からフロントエンドのタスクを積極的にやっていき、フロントのコードレビューも任されるようになった。 ### 課題 - フロントエンドの専任の開発者がいたが、人数が少なく割り振られたタスクが多く消化するのに時間がかかっていたため負担が大きくなっていた。 - フロントができるエンジニアが少ないので自分でも手を上げればできるチャンスがあった。 ### 改善・工夫したこと - 自分もフロントのタスクができるように業務外でフロントの学習をして、vueの`Composition API`や`TypeScript`の学習して少しでも貢献できるように頑張った。 - フロントの開発を進めやすくするためにESLintを導入したり、フロントのエンジニア専任の方とコード規約のやり方についてなど会議で話し合ったりと保守性を考慮して開発を進めることができた。 - フロントエンドのコードレビューをして実務を通してフロントのコードが大分読めるようになった。 ### 開発で工夫したこと - バックエンドの機能実装の時はできるだけテストコードを書くようにした。テストはPHPUnitを使い、Featureテストで`画面遷移テスト`、`データベーステスト`、`認証テスト`を書いて実装した。 - また、同じ処理を書かないように`setUpメソッド`を使い`DRY原則`に従ってコードの保守性を意識して実装しました - 開発者のメンバーが多いため、プルリクでレビューする時間がかかっていたので、できるだけ時間を取らせないためにプルリクは詳細まで記入したり、スクショ画像で画面の修正箇所を分かりやすく指摘したりとできるだけ相手の時間を奪わない開発体制を維持できるように工夫しました。

# プロジェクト概要 - マンション管理を一元化する大規模データを扱うツールの開発・運用を行なっている - 大規模プロジェクト # 担当した役割 - バックエンドとフロントエンドを両方を担当。追加開発から保守運用を行いました。 # 技術スタック - フロントエンド : Vue.js, JavaScript, Sass - バックエンド : PHP/Laravel , Auth0 - インフラ : AWS(ECS, RDS, Cloud Front, S3, Cloud Watch Redis, Lamda) , Docker Circle CI # 主要機能 - 発注、支払い、請求の月次・年次の管理 - 収支計算 - 部屋管理 - 駐車場などの共同部管理 - 理事会の役職管理 # チーム構成 - PM 1名 - ディレクター1名 - バックエンドエンジニア 3名(自分) - iOSエンジニア 1名 - Androidエンジニア 1名 ## 出したバリュー(取り組み) ### iOS、Androidアプリとの連携 ### 課題 - WEB, iOS, Android版のアプリが存在するが、開発の仕様についてWEB側とアプリ側、さらにアプリの中でもiOSやAndroidのメンバーでも認識が異なることが多々あり、コードレビューや動作確認後に手戻りが発生するケースが散見されていた。 ### 改善・工夫したこと - 手戻りが多く、認識の不一致ががあったため、ミーティングを増やして合意が取れた内容(仕様書やプルリク)などを充実させ、オンラインでコミュニケーションを徹底的にやった。結果、認識齟齬が発生しないで手戻りが減少した。 ## 大規模なソースコードと仕様の理解 ### 課題 - 前任者がいなくなってしまうことがあり、1ヶ月で引き継ぎを行い、今後実装するにあたって抜け漏れがないようにソースコードを読み解きかつ、仕様を理解する必要があった。 ### 改善・工夫したこと - 実装する前に、主要な機能と影響範囲はどれくらいかを検討して実装を進めた。処理フローがわかりにくいところは、フローチャートに書き起こしてロジック周り、動作の流れを確認した。また、毎週メンバー同士でミーティングを開き、仕様についてや気になることを共有して知識を深めていった。その結果、実装の抜け漏れがなく納期前に納品することができた。 ## バックエンドとフロントエンドの連携開発 ### 課題 - バリデーション機能でフロントのモーダルメッセージを使うか、バックエンドだけでバリデーションエラーメッセージを表示させるかで仕様を満たすのに悩むことがあった。 ### 改善・工夫したこと - 無駄コードは極力書かないように、まずは既存で使えるコードを見つけて流用できないかをチェックした。その結果、追加でフロントの実装はしないで、バックエンドのみの実装だけで仕様通りに開発ができた。大規模なプロジェクトなので実装するときは使い回しができるか？、影響範囲は考慮されているか？を考えて実装した。 # 開発で工夫したこと プロジェクトの規模は大きく、修正や機能追加でも影響範囲が大きいのでPRでは、みんなで回しあって確認、レビューを徹底的にやった。その結果、ソースの可読性が上がった。 退会APIを実装したときに、影響範囲が他にもないかを確認しながら実装した。認証周りにミドルウェアの影響範囲があったのでそこを考慮して実装した。

### **プロジェクト概要** - 与信審査のシステム開発 - 受託開発でスクラムでポイントを割り振って開発 ### **担当した役割** - メンバーとしてジョイン。 - フロントエンドからバックエンドまでのタスクを担当 ### **主要機能** - 与信の申請フォーム - JspreadSheetを使ってExcelのimportとexport機能 - 与信スコア機能 ### **技術スタック** - フロントエンド : TypeScript, Vue.js, Vuetify, Nuxt.js - バックエンド : Node.js Express、TypeORM - インフラ : AWS(EC2, RDS, Cloud Front, S3, Cloud Watch), Docker - その他 : MySQL, Github Actions ### **チーム構成** - エンジニア 4名 - スクラムマスター 1名 - PM 1名 ### **出したバリュー(取り組み)** ### 冗長的なコードをリファクタリングしつつ、追加機能開発をした ### **課題** - このプロジェクトはリリースを急いでいたこともあり、所々、冗長的なコードが見られた。 ### **改善・工夫したこと** - ベタ書きで実装していた箇所を変数にまとめて、foreachやmapでソースコードの量を減らして可読性を上げたり、マジックナンバーがよく使われていたので、ファイルに切り出して定数として管理してマジックナンバーは使わないように実装 ## ドキュメントツールに仕様を全部まとめた ### **課題** - slackでやりとりが長くなってしまい、決まった仕様がスレッドに埋もれてしまって、後で見返した時に探すのが大変だった。 ### **改善・工夫したこと** - 仕様やデザインなどのほとんどはドキュメントにまとめて一元化して、あとで仕様を確認しやすくなった。 - ドキュメントツールのなかには、オンボードやデータベース、テーブル形式など視覚的に見やすいドキュメントを心がけることによって視認性が良いドキュメントを作っていくことができた。 ### **開発で工夫したこと** - 仕様がなかなか決まらないことがあったので、都度クライアントとすり合わせをして抜けがないように実装をした。 - UIでなかなか仕様通りに達成できない時は代替案を出して、改善できないかを相談した。

※個人開発です。 Next.jsとmicroCMSで技術ブログ開発 <経験> ・要件定義、フロントエンドの設計、開発 ・Next.js + TypeScriptにおけるシステムの開発、テスト ・Figmaを使ってデザインカンプの作成 <経験> ・Next.jsの開発 ・App rouer構成を使った開発 ・microCMS使ったコンテンツ管理APIを使用 ・Github Actionsを使ったCI化 ・Jestを使ったテストコード化 ■github ソースコード https://github.com/masahiro96848/zerone_blog ■URL https://zerone-blog.vercel.app/ <コメント> ・App routerはどういったものかを触りたかったのでmicroCMSと連携して実装してみた ・直近のプロジェクトではvue.jsをメインに使っていたのでReact、Next.jsにも興味が出てきた。

# 自社サービスのAI広告のAdTech開発 ### **プロジェクト概要** - 自社システムの開発 - 主にクリエイターが使うサービスを自社内で開発 ### **担当した役割** - メンバーとしてジョイン。 - 主にフロントエンドがメインでバックエンドも実装 - UI/UX設計からリーダーやビズサイドとコミュニケーションを取りながら開発 ### **主要機能** - AI予測機能 - AI予測機能を使ってスコア化 - 一覧検索機能 - ブックマーク機能 - Ad制作機能 ### **技術スタック** - フロントエンド : TypeScript, Vue.js, Vuetify、 - バックエンド : golang、echo, - インフラ : GCP(Big Query, Cloud SQL, Cloud Build, Cloud Cdn) - その他 : MySQL, Github Actions ### **チーム構成** - MLopsエンジニア 5名 - バックエンド兼リーダー 1名 - フロントエンド 4名 - 事業責任者 1名 ### **出したバリュー(取り組み)** ### 実装するタスクが本当に必要かを検討した ### **課題** - 開発コストがかかる上、本当にその機能が必要なのか問題があった。 - 機能はブックマーク機能で、他のページにも実装されている機能だった。しかし実装する機能は他のページで使っているブックマーク機能とはデータの扱い方が違っていて、状態管理から見直す必要があった。 - 状態管理を修正すると、他で使われているブックマーク機能にも影響を与えてしまい、開発コストが大きくなってしまうことが問題であった。 ### **改善・工夫したこと** - タスクの調査や実装の段階で、改めて開発リーダーに相談してその機能が本当に必要かどうか？開発コストや影響範囲を踏まえて説明した。 - その結果、このタスクはpendingになり、優先度が高いタスク、ユーザーが求めている機能、バグ修正タスクなど、やるべきタスクを消化するようになりました。