ID:70504さん

# プロジェクト概要 学校管理画面のリプレイス バックエンドもフロントエンドもRailsで書かれている、かつ、コードの見通しが悪くメンテナンスがしにくい状態だったため。 ### チーム情報 ・プロジェクトマネージャー：1名 ・フロントエンド： 3名（フリーランス） ・バックエンド：3名 ### 担当業務 ・GraphQLでのAPI開発（query、mutation） ・画面作成 ・フロントエンドの進捗管理 ・コードレビュー ### 習得スキル ・GraphQL（graphql-ruby , Hasura） ・Ruby on Rails ・Vue3（Nuxt3） ・Apollo CLient ・キャッシュ管理 ### 作業内容 ・コードから仕様を読み解き、仕様の整理をしながらAPI作成 ・N+1が起きないようにLoaderを使用してパフォーマンスを意識したAPIの作成 ・graphql-rubyのドキュメントを読み、土台を一から作成。 ・Apollo Clientのキャッシュの管理 ・フリーランス3名の進捗管理とPRのコードレビューを担当。 Notionで作業を細かくチケット化し、一週間を1スプリントとして、チケットを振り分けて進捗管理を行った。 ・JsonCsvを使ったCSV出力処理。 ・Rails側で実装されている既存機能を使える部分は使って工数削減を行った。（納期が近かったため） PDF出力などはフロント側で生成するのではなく、Rails側で既にPDF出力用のtemplateがあったので、Rails側でPDF化したデータをフロント側に渡してダウンロードする流れにした。 フロント側でPDF生成することも考えたが、PDFの改ページ時にCSSが効かない問題が発生したため。 ### コメント プロジェクト立ち上げ当初は、「学校」、「学生」、「事務局」、「企業」の４画面全てをフルリニューアルとしてリリースする予定で、Hasuraを使用してAPI開発を約半年程していたが、予算、納期の関係で断念し、「学校」画面だけをリリースすることになりgraphql-rubyに転換した。（Hasuraを使用するにはDBをMySQLからPostgreSQLに変更する必要があり、分割リリースが出来ないため。） Prizmaを採用しようかという話もあったが、稼働中のDBがリレーションが貼られていなかったり、アンチパターンが多発していたため（フルリニューアルではDB設計から直す予定だった）、Prizmaを使用できるような状態ではなかったため断念。 上記の一件で担当していたマネージャーがこのプロジェクトから外れ、新たなマネージャーが担当することになったが、フロントの方まで手が回っていなかったので、バックエンドAPIを作りながらフロントのフォローをしていたところ、フロントの進捗管理を担当することになった。 ### 反省点 初めて作業振り分けや、進捗管理を担当。 序盤は大雑把に作業を振り分けしていたが、フリーランスの方はドメイン知識が浅いこともあり認識が合っていない場合が多く、作り直しが多々発生してしまった。仕様をしっかり説明し、認識のすり合わせが必須であることを痛感した。

# プロジェクト概要 既存アプリ（WebView）をFlutterにリプレイス。 アプリエンジニアがいないため、言語を絞り保守運用コストの削減をするため。 ### チーム情報 ・プロジェクトマネージャー：1名 ・開発： 1名 ### 担当業務 ・Java、Kotlinで構成されているアプリ（WebView）をFlutterで統一。 ・アップデートリリース（AppStore、GooglePlay） ・リリース手順書の作成 ### 習得スキル ・Flutter ・アプリのリリース作業 ・アプリ独自機能の実装（Push通知、ファイルダウンロード、ログイン情報の保存、アプリレビュー） ### 作業内容 ・flutter_inappwebviewを使用し、Java、Kotlinで構成されているアプリ（WebView）をFlutterで統一（JavaもKotlinも触ったことがなかったが、実際にアプリの挙動を見ながら既存コードを読み解き、仕様を理解することに努めた） ・TestFlightを使用したテスト作業 ・Firebase Cloud Messagingを使ったPush通知 ・flutter_secure_storageを使用してログイン情報の保存 ・「App Store」、「Google Play」へのアップデート 既存アプリのリプレイスはアプリIDを引き継いでアップデート。 ・起動回数に応じてアプリのレビュー依頼を表示。（今後の改善では、「求人への応募」などのポジティブアクションをしたときにレビュー依頼するようにしたい）

# プロジェクト概要 バックエンド開発 ### チーム情報 ・プロジェクトマネージャー：1名 ・バックエンド：2名 ・フロントエンド：1名 ### 担当業務 ・実装 ・仕様書作成 ・要件定義 ・新機能開発 ・API開発 ・バグ対応 ### 習得スキル ・Ruby、Ruby on Rails，SQL ・他部署との連携 ・コーディング技術、DBの構造 ・テーブル設計 ### 意識した点 ・要求をヒアリング→要件定義→ドキュメント作成→実装までの流れを経験。 オファー機能の仕様変更時、案出し〜実装まで。また外部公開APIの開発も行った。エンドポイント、ヘッダーに必要な値、返却値のデータ型をJson Schemaで学校へ公開。 ・DB設計のアンチパターンの理解（非スカラ値、ダブルミーニング、単一参照テーブル） ・N＋１改善（eager_load、preload） ・他部署と連携し、バグを解消。 ・バグ発生時の報告チケットのテンプレートを作成。 セキュリティランク、期待する結果、優先度、発生状況（ユーザー情報や環境）など、エンジニアが欲しい情報を提示（なぜその情報が欲しいのかも説明）し、解消速度の向上、開発側と現場側の認識のズレを解消。

# プロジェクト概要 フロントエンド開発 ### チーム情報 ・プロジェクトマネージャー：1名 ・フロントエンド： 2名 ・バックエンド：2名 ### 担当業務 ・デザインカンプ（Adobe XD ）からのコーディング ・RSCSS規約を基にCSSを全て改修 ・UI/UXの改善 ・HTMLタグの選定 ・新機能開発 ### 習得スキル ・Vue.js、Nuxt.js、Pug ・コーディング技術、フレームワーク理解 ・バックエンドエンジニア、デザイナーとのコミュニケーション ・CSSの設計 ### 意識した点 初のフロントエンド業務だったので、使用ツールの理解から始めた。 既存コードやドキュメントを参考にPug、Vue.js，Nuxt.jsの基本、SPA、SSRの違いを理解。HTMLを作成する際に全てdivタグを使うのではなく、sectionやarticleなど、適切なタグを使用することを意識した。 CSSでは、importantが多用されており優先順位が分かりづらかったため、RSCSS規約を基にCSSを全て改修。その結果、importtantを使用するのはUIフレームワークの上書きをする場合のみになった。 レスポンシブ対応として、ブレイクポイント毎にCSSを変化させ、スマホ、タブレット、PCにも対応した。 vee-validateというバリデーションライブラリを使用し、バリデーションエラーが発生すると、エラー箇所までスクロールするという機能の作成。この機能はエンジニア転職後、初めてメンバーの助けを借りず自分で一から最後まで作成した機能なので記憶に残っている。 デザインカンプを元にコーディングする方法や、デザイナーとのコミュニケーションも積極的に行った。（デザインではこうなっているが、この方が使いやすいのではないか？など。）

# プロジェクト概要 E2Eテストの作成 ### チーム情報 ・プロジェクトマネージャー：1名 ・テストチーム： 2名 ### 担当業務 ・テストシナリオの作成 ・コーディング（250本のテスト作成。2人で450本。） ### 習得スキル ・JavaScript、TypeScript ・TestCafe ・エンジニアとしてのコミュニケーション ### 意識した点 ・初のエンジニア業務ということで、不明点があれば曖昧にせず、必ず質問し理解した上で進めることを心がけた。 ・公式ドキュメント、github issueから解決するフローの習得 ・テスト作成しながら、自社サービスの全体像を理解するよう努めた。