kmatsui058

# プロジェクト概要 - 転職エージェント向けの求人DBプラットフォームの機能開発 - アジャイル - 一週間スプリントのスクラム - 開発メンバーはスクラムマスター、プロダクトオーナー、開発者6名程度のチーム体制 - フロント環境はNuxtのサービス３つとNextのサービス1つ。APIサーバーはLaravel ＋MySQL - フロントのデプロイ先はCloud front、APIサーバーはECSで構成 - CI/CDはgithub actionsで実行 - インフラ管理はterraformを使用 - データ分析はmetabase・Google Analytics・Big queryを併用し、GDSを用意してビジネスチームに提供 # 取り組んだ内容 - APIのスキーマが管理されておらず、モデルデータがそのまま送られるなど日常茶飯事な状態になってしまっていたため、OASによるスキーマ管理と、typescript用のAPIクライアント生成等の環境を導入した - 求人の選考に関する情報を可視化するプロジェクトで、グラフ周りの実装を行った - 求人企業向けのアカウントを会社ごとではなく個人ごとに移行するプロジェクトで、サーバーサイドの各エンドポイントの実装変更、メール通知などの送信先の実装変更、フロント側の調整、顧客向け広報資料の作成、社内の関係部署からのヒヤリングと調整、社内関係者への機能オンボーディングなどを行った。設計は入社前にすでに行われていたのでそのあとの作業だけ行った。 - 転職エージェント向けの書類作成機能の進行と実装を行った。ユーザーヒヤリング、ワイヤー作成、プロトタイプ実装、プロトタイプ検証、本設計、本実装、顧客向け広報資料作成、社内オンボーディングなどを行った。 - プロダクトの開発初期の突貫工事で作られた部分の品質が著しく低く、ユーザー体験を大きく損なっていったため、プロダクトとしての当たり前品質の定義を行い、チームメンバーで認識をそろえた。その後既存機能について当たり前品質をクリアしているか調査し、改善点を挙げていく作業を行った。 - もともとプロダクトにSentryが導入されており、エラーのアラートが上がってくる状態にはなっていたが、それに対する対応をどうするかが決まっておらず、クリティカルな場合以外放置されてしまっているという状態があったため、チームとしてのSentry監視方法と対応方法

# プロジェクト概要 ・クライアント様の保有している各種情報資産と、クライアント、社内タスク等を総合的に管理するシステムの開発 ・フロントエンド部分の開発を全体的に担当。 ・自分が入る前にLaravel-mixを使用して開発がスタートしていたが、自分がフロント専業としてアサインすることになったのでフロント部分は分離して別途webpackでvueのSPAをlaravelのbladeに埋め込む形に変更した。 ・サーバーサイドとの連携はAxiosを用いて全面的にAPIを通してやることになったため、OpenAPIを利用。 ・2020年夏ごろからはプロジェクトのディレクターが休業に入ったため進行役も兼任。 # 取り組んだ内容 ・フロントエンド側開発環境の構築 ・フロント領域のコーディング ・APIスキーマの作成 ・OpenAPI generator等を使用してスキーマ定義からAxiosクライアント、TSの型定義ファイル、jsonschemaの定義を生成、Axiosのインターセプターを利用してAPIの実行時型チェックを実装する。 ・他フロントメンバーに単タスクをアサインして指導とコードレビュー ・社内進行、協力会社との調整、全体的なタスク管理 # 次に活かせる学び ・自分が入る前の段階で、SPAではなくMPA（エントリーポイントが複数のブレードに分割されている）状態でプロジェクトがスタートしてしまっていたのでそれを踏襲したが、MPAはコンポーネントが無駄に重複するのと、分割したとはいえ各ページのコンポーネントが肥大化してパフォーマンスが悪化したので、最初からNuxtなどを利用してSPAベースかつコンポーネントをDynamic importする形に早い段階で切り替えていたほうが良かった ・当初APIスキーマはサーバーサイドが担当するということで任せていたが、作業者が協調せずばらばらのスキーマを作ってしまって担当が変わった際に引継ぎがまともにできない状態になってしまっていた。なので途中からAPIの管理についてはこちらで主導することとしてOpenAPIに整理統合したが、切り替えコストがかなりかかってしまったので、プロジェクトが走り出す段階できっちりとOpenAPIにしろGraphQLにしろAPIの管理をどうするか決めておくべきだと思った。

# プロジェクト概要 クライアント様がホテルのお客様に対面でアンケートを取るためのアプリケーションのフロントエンド部分を担当した。 要件として ・iPadで使用 ・Apple storeに登録しない ・電波が届かないところでもアンケートをとれるようにする とのことだったので、Nuxt PWAでアプリケーションを構築、お客様の入力情報を保護するためCryptoAPIによるフロントサイドでのデータ暗号化とLocalStorageへの保存、CacheAPIを利用してアプリケーションを端末に保存する機能などを実装した。 # 取り組んだ内容 ・フロントエンド側開発環境の構築 ・フロント領域のコーディング ・APIスキーマの作成 ・クライアント様が、アンケートを取り終わった後送信する前に別サイトや別ファイルを開いてお客様に説明するフローを入れたいということで実際にテストしていただいたが、iPadのメモリ管理が厳しく、別タスクに移動した段階でPWA側のメモリが削除されてしまいアンケートを入力しなおさないとならないという問題が発生した。調査したところLocalStorageの内容は削除されていないようだったので入力内容をWebCryptoAPIで暗号化したうえで一時保存、セッション復帰の際にLocalStorageの状態を検証して直前の状態に戻るロジックを実装した。 ・多言語対応のための各種資料（言語設定、住所リスト）をパースしてデータを格納したtypescriptファイルを自動生成するts-node用のタスクを作成した。 ・jestの自動テスト環境を構築した。 # 次に活かせる学び ・iOS、特に１２以前はPWAの動作が非常に不安定で、実案件として使うのは無理がある感じだったが、幸運にもプロジェクト進行に伴いiOS13以降は比較的安定してきており、本プロジェクトのリリースするタイミングでは実用できるレベルまで安定していた。今後はAndroidだけでなくiOSもPWA対応を進めていって良いと思った。 ・クライアント様との間に一社デザイン会社が入っており、そこがCSSも担当していたが、その会社がfullpage.jsというライブラリを使用したいということでUIに取り込んできたが、このライブラリがiOSで正常に動作しておらず、不具合対応等のために膨大な時間を割かれた。最終的にライブラリを外して必要な機能だけtypescriptで０から書き直したところすぐに要件を満たす動作が実現できたので次からもそうしたい。 ・iOSのsafariはいわゆるsmooth scrollの類のライブラリを使用するとコンテンツの内容によってはフレームレートが非常に低下するという問題があった。CSSアニメーションでGPU支援を効かせればスムーズに動いていたので、極力JSはクラスの変更だけに努め、CSSアニメーションで済ませられないか検討する方が良いと思った。

# プロジェクト概要 ・多言語サイトが各々別デザイン別コードになっているせいで改修工数がかさんでいたので、デザインとコードを統合した ・PC/SP別ページだったものをレスポンシブに変更 ・SEO最適化 # 取り組んだ内容 ・改修要件のヒヤリングと技術検討 ・各種ドキュメントの作成：工数見積もり、要件定義 ・進行管理 ・開発環境構築 ・コーディング ・APIスキーマの作成 ・jQuery排除による動作の軽量化 ・GA及びサーチコンソールを使用してSEO改修の効果測定 ・HTMLべた書きしたものをサーバサイドエンジニアがPHPに書き直すという作業が全工程に入って作業効率が非常に悪かったため、NuxtSSGを利用してHTMLにSmarty用の変数を入れ込んでしまい、ブラウザでレンダリングする前に変数の内容を取得、Vueで変数の内容に再度置き換え直すという手法により、SSGで生成したファイルをそのままPHPのテンプレートエンジンに流し込んでブログを生成できるような仕組みを作った。（先方がCDNを利用していたため純粋なSSRは利用できなかった） ・既存ブログ記事を保ったままの改修となったので、改修前後で既存記事に崩れがでないか検証するため、Webdriverを操作してテストサーバーと本番サーバーでスクリーンショットを一括で自動撮影、差分箇所の集計を行うツールを作成した。Selenium用のサーバーを用意するのは費用面、速度面であわなかったので、Go言語で直接ローカルのwebdriverを操作する形で作成した。CPUのコア数に応じて並列処理させることで、8coreの最近のCPUであれば1時間で全テストが完了するところまで高速化することができた。 # 次に活かせる学び ・Go言語でのwebdriverの操作は、ライブラリがメンテされておらずちゃんと動かなかったり、文献が少なかったりと開発には非常に苦労させられたが、やはり並列処理の恩恵は大きく、パフォーマンス面では非常に強力だった。ただ、やはりwebdriverとの親和性という意味ではPythonの方が優れいていると感じる場面が多く、例えばPythonの処理自体を並列させるようなバッチを作ればパフォーマンス面でもそこまで劣らないものが作れるのではないかとも思った。