Yui

## サービスの概要 - 訪日外国人向けのマッチングサービス - 日本人に日本旅行のプランを組んでもらえる - 日本人は有料でプランを作成することができ、それを訪日外国人が買うことができる ## 機能 - チャット機能 - 決済機能 - ホテル予約機能（agoraのAPI利用） - プラン作成機能 ## 言語＆フレームワークなど - Ruby on Rails - Ajax通信 - HTML, CSS ## 役割 新規事業立ち上げとして、CEOの方と二人で開発をしました。 人数が少なかったので、デザイン、要件定義、開発まで全て行いました。 リリース後は広報も担当し、ユーザーの要望を確認しながら機能改善を行いました。 ## チャット機能の構成に関して チャット機能は各ユーザーが、プラン作成者に対してDMをして疑問点などを解消するために実装しました。 RoRのMVCを利用して作成しました。 ## 決済機能に関して 決済機能はstripeのAPIを選定しました。 stripeを選んだ理由は、ユーザーがstripeのアカウントがなくても支払ができるという点で、ユーザーに煩らしい思いをさせることなく、決済に進んでもらえると考えたからです。 また、[ドキュメント](https://stripe.com/docs/api)も充実しており読みやすく、決済機能の実装は初めてでしたが問題なく実装できました。 ## 開発環境のDocker化 当初は開発環境をローカルで動かしていましたが、今後新しいメンバーが入るときのために、開発環境をDockerで立て直しました。 サーバーはherokuで立ており、developブランチにマージされたものは開発環境に、masterブランチにマージされたものは本番環境に自動デプロイが走るようにCIを組んで環境を整えました。 ## ホテル予約機能に関して アフィリエイトでも収益をあげるために、ホテル予約システムを導入しました。 agoraのAPIを利用した理由としては、比較的アフィリエイト収入がよく（当時で2%でした）adoraのサイトに飛ばす必要なく予約まで行うことができたからです。 booking.comのアフィリエイト用APIも検討しましたが、システム上どうしても予約時にはbooking.comのサイトに飛ばさないといけないため、UI面を考えると厳しく、agoraを使うことにしました。 ## agoraのAPIを利用して自動で記事を作成する 上記のアフィリエイト収入のため、PV率アップをして、大量の記事を作成する必要がありました。ただ、新しいライターを雇う余裕もないプロジェクトだったため、agoraのAPIを利用して、自動でタイトルと画像、本文にスタイルを当てて作成するようにしました。 ホテル情報の紹介のようなページでしたが、約2000件ほど作成できたので、PV率は月1,000pvほどだったところから3,000pvに上がりました。 ## 企画からローンチまでのスケジュール 企画から1ヶ月で要件定義と設計を行い、その後の3ヶ月で開発、その後は4ヶ月ほど運営、保守、改善を行いました。

## サービスの概要 - 店舗の監視カメラから利用客の密集具合を検出し、表示する - カメラは既設の監視カメラを使うため、低コストで導入できる ## 機能 - 映像分析 - AIによる密集具合の検出 - 検出後は可視化し、色わけしてダッシュボードに表示 （私が関わったのは最後のダッシュボードに表示部分だけです。） ## 言語＆フレームワークなど - Laravel - Azure - React - Next.js ## 役割 既存のサービスのフロントエンド部分のレイアウトとAPIをアップデートするために参画しました。依頼が来た時点で主な機能はできていましたが、依頼元にフロントエンドをまともに書くことのできる人材がおらず、フロントエンド部分でより細かいUIを実装することができないため、参画することなりました。フロントエンドの人数は私一人でした。 ## クラス型コンポーネント+propsの構成から関数型コンポーネント+hooksへの書き換え 参画した時点でコードを確認すると、ロジック部分と表示部分が一つのファイルにまとめて書かれており、Reactの良さというのを全く活かせていませんでした。 また、クラス型コンポーネントの構成だと、共通のロジックをコンポーネント間で再利用するのは難しく、毎回同じような処理を書く必要があります。さらに、componentDidMountやcomponentWillUnmountなどの細かく分けられた状態を完璧に理解するのは難しく、その後経験の浅い人がアサインされた場合にメンテナンスがしにくくなります。 その点、hooksを利用してロジック部分はできる限り共通化して外部に書き出し、ビュー部分ではインポートして使うようにすることで、あとから入った人でも見やすくメンテナンスがしやすくなります。 また、hooksの中のuseMemoやuseEffectなどで依存関係をもたせることで、より最小の差分のみを変化させることができ、レンダリングコストを少なくすることができます。もちろんこれはクラス型コンポーネントでも可能ですが、hooksを利用したほうがより直感的でわかりやすいです。 そのため、少し手間ではあったのですが、私がプロジェクトから抜けたときのことを考え、クラス型コンポーネント+propsで一つのファイルにベタ書きされていたものを、関数型コンポーネント+hooksへの書き換え、さらにファイル構成を、コンポーネント単位で切り分けて、ロジック部分はカスタムフックを管理するhooksフォルダを作り、ファイル名を見ただけで構成が理解できるようにリファクタリングを行いました。 結果的にこのリファクタリングは大正解で、どうしても私一人の作業量では足りない部分が出てきた際に止むを得ず社内のReactを少しだけ触ったことがある程度の人が参画することになったのですが、コンポーネントでの分離が完全にできていたので、作業の切り分けがしやすかったです。 また、ロジック部分は私がほとんど作ったカスタムフックを利用するだけで良かったので、そこまで経験値によって差がでることもなく、ある程度整頓されたコードを納品することができました。 ## Next.jsの導入 新しく使うAPIがセキュリティ面担保のため、SSRでしかアクセス許可されていませんでした。そのため、Next.jsを使う必要があり、上記のリファクタリング後のコードはNext.jsに置き換えました。APIにアクセスしないといけないのはページを表示した際にデータを取得するためだけだったので、getInitialProps内でAPIに接続しました。 ## 開発環境と本番環境の切り分け 本番環境ではAzureを使って運用されていましたが、残念ながら社内（私が所属していたSES企業）ではAWSで開発環境を作成する方針が決まっていました。 そこで、EC2上に開発環境を立ち上げて社内用の開発環境としました。また、先方に共有する際に、環境構築も必要になる可能性を考慮して、簡単に環境を共有できるようにDocker化も行いました。

## 概要 - バーチャルオフィスでコミュニケーションをとれるサービス ## プレスリリース - https://prtimes.jp/main/html/rd/p/000000001.000076293.html ## 機能 - チャット機能 - オフィス移動機能 - 通話機能 - ステータスのリアルタイム更新 ## 言語＆フレームワーク - バックエンド..Golang - RPC..gRPC - フロントエンド..React+TypeScript - 通話機能はAmazon Chimeを利用 ## 役割 フロントエンド担当として、他のフロントエンドメンバー2名と一緒に開発を進めました。主にチャットサービス部分の実装とステータスのリアルタイム更新部分実装を担当しました。機能ごとに開発者を分けてアサインし、実装後は他の開発者が相互レビューを行う形で実装を進めていました。 ## gRPCの選定に関して 今回、gRPCを利用したのは通信速度が非常に高速だったのと、protoを使うことでフロントエンド側、バックエンド側両方に型を自動生成することができ、フロントエンド・バックエンド間の連携のずれを防ぐことができるからです。どうしてもバックエンド側のバージョンが上がった際にフロントエンド側の型の修正などを忘れてしまったりしますが、protoファイルをsubmoduleに入れてコードを自動生成するだけで、修正を忘れている部分があれば自動でエラーを吐くようになるので、コンパイル前に気がつくことができ、非常に便利でした。通信速度も非常に高速だったので、今回のようなチャット機能やステータスのリアルタイム更新などでは重宝しました。 protoに関しても、殆どはバックエンドの方が書くようになっていたのですが、proto自体難しくはないので、必要な返却値などがあれば、フロントエンド側からprotoディレクトリに対してプルリクエストを送って要求することもできました。 ## チャット機能に関して ユーザーはフロアボードを開いて、チャットをすることができます。リアルタイムで得たチャットに関してはstream処理で探知し、表示をするようにしました。 以下の手順で実装しています。 ①フロアボードを閉じている間に新しいメッセージを探知した場合 通知の赤丸のみをフロアボードアイコンに付与する。メッセージに関してはフロアボードを開くタイミングでgRPCが叩かれるため、メッセージの更新はReact側では行う必要がない。 ②フロアボードを開いている最中に新しいメッセージを探知した場合 フロアボードを開くタイミングでメッセージをgetするため、新しいメッセージが飛んできた場合はReact側で状態を変える必要がある。メッセージ探知の度にuseEffectが動くようにして、その中でuseStateを使って状態を更新して表示しました。 ③メッセージIDが同じ場合は更新しない ②の方法だと、まれに同時時刻に大量のメッセージを探知した際、二重、三重でメッセージが更新されてしまいます。そのため、メッセージと一緒に飛んでくるIDでメッセージリストを検索し、メッセージリスト内にすでに同じIDがあれば何もせずにreturnだけするという処理を加えました。 ## react-queryの導入 今回、構成上フロアボードを開く度にgRPCを叩く必要が出てくるので毎回新しいデータからスタートすると一瞬ですが画面にちらつきが生じます。 そこで react-queryを導入してキャッシュ利用可能にすることで、初めてデータを取得する場合のみデータが表示されるまでにローディングアニメーションを出し、それ以外の場合ではキャッシュのデータを表示することで無駄な画面のちらつきをなくしました。

## 概要 - 訪日外国人向けECサイト ## 機能 - 商品をキーワードで検索 - 商品購入 - お気に入り機能 - マイページ ## 言語＆フレームワーク - バックエンド..Ruby on Rails - フロントエンド..Next.js+TypeScript - インフラ...heroku（APIのホスティング）, fastly + amplify（フロントエンドのホスティング） ## 役割 開発リーダーとして要件定義から開発・レビューまで基本的に全タスクを見ていました。 具体的には、バックエンドのAPIのリクエスト・レスポンスの仕様に関してOpenAPIのyamlファイルを作成してバックエンド・フロントエンド双方の合意が取れた状態で開発をすすめるようにしたり、フロントエンドに関しては、開発だけでなくタスク分割をして開発者にアサインしたりレビューを行いました。 開発メンバーとは週に一度1on1をして、技術的な相談にのりながらスプリント内でタスクが完了するようにマネジメントもしていました。 ## Gatsbyを使った静的サイトの構成からNext.jsオンリーの構成にリプレイス このプロジェクトの中で最も注力したのは全体の構成のリプレイスです。 元々、Next.js 9系の頃からプロジェクトがあったということもあり、その当時はNext.jsにSSGの機能がなかったのでSSGのためにGatsbyを使って全ページを生成して、s3で静的ページとしてホスティングをしていました。この実装自体はページ速度の向上に非常に役にたったのですが、その分商品情報のページも予め生成してしまうため、売り切れなどの情報がリアルタイムで反映されないという問題が発生してしまいました。また、多言語化に関しても4言語行っておりましたが、各言語ごとにホスティングしており、ホスティング先が4つあるという状況でした。当然ビルドも4言語分走るので、ビルドするだけでも30分程度時間がかかり、開発体験としては決して良いものではありませんでした。 そこで、Next.jsの機能自体にSSGが備わったということと、多言語化に関しても一つのホスティング先で複数振り分けできるようになったということ、商品情報に関してはできるだけリアルタイムの情報を出したい、全体的にリファクタリングをする必要があるという思いから、以下の構成に変更することを決めました。 - 商品情報部分はISRで短めにrevalidateを設定することで、ページの表示速度はSSGオンリーの場合と大差なくしつつもデータは自動でキャッシュを更新するようにする - 多言語化に関してはNext.jsのi18n-routingを利用することで一つのホスティング先で複数言語が確認できるようにする - APIを接続している部分では積極的にSWRを利用してデータの表示速度を早くする - グローバルな状態管理に関してはSWRのキャッシュを利用するカスタムフックを作って利用し、他に依存先を作らないようにする - 商品画像に関してLambdaEdgeとCloudFrontを利用してs3にアップロードされたらLambdaEdgeを通じて画像の圧縮を行いCloudFrontにキャッシュとして残すようにする。画像を取得する際はs3を直接見るのではなく、CloudFrontから取得をすることで、画像の取得速度をあげる。 また、関数の命名ルールやディレクトリ構成・ファイル名などでもルールが特になく、各自が様々なルールで書いていたという状態だったので、チームメンバーとMTGをしつつルールを決めて、ルールに則るようにhusky、eslint、stylelintを活用して自動でチェックが入るようにしました。 このリプレイスに関しては、リポジトリ自体を変更するという大掛かりなものになりましたが、結果としてビルド時間は1/10になり、商品情報に関してもほとんどリアルタイムのものが確認できるようになったのでユーザー体験・開発体験ともに良くなる結果となりました。 ## SSRではなくISRを採用した理由 当然、データのリアルタイム性に重きを置くのであればSSR（あるいはCSR）を採用するべきでした。 ただ、今回のケースだとリアルタイム性も重要ですが、それ以上にページの描画速度も必要でした。というのも、ECサイトというのは、様々な商品ページを見られることが多いので、どれだけ各商品ページが早く描画できるのかということはUX改善において欠かせないポイントだからです。 作っていたサイトがオークションサイトのように強整合性が求められるものであればまた別なのですが、今回の場合は管理者も一日に数回商品情報を更新するかどうかという程度で、また、ユーザーが商品をカートに追加する時点でもその商品を購入できるかどうかのAPIを叩いてリアルタイムで再度確認ができるということもあり、結果整合性で十分だということになったので、ISRを利用することにしました。 ## SWRの利用 特に力を入れたのはSWRの利用です。 予めデータを取得できる場合は前述の通りISRでビルド時にデータを取得しておけば良いのですが、アクセスキーを使ってデータを取得するような場合は、CSRでデータを取得せざるを得ません。ただし、毎回APIを叩いて取得しているとユーザーメニューボタンを押すときなどで毎回ローディング状態になりUXとしてはよくありません。 そこで、変動があまりないもののよく叩かれるAPIに関してはCSRで叩く場合に関してはSWRを積極的に使うようにして、キャッシュを利用してデータの描画速度を早めました。 もちろん、CSRをするのであればリアルタイム性というのは譲れないポイントになるので、変動があった場合には明示的にMutateを行い、データのリアルタイム性の担保も忘れないようにします。 グローバルな状態管理に関してもSWRを利用しています。 その理由は、他に依存関係を作りたくないということが一番大きな理由です。もちろん状態管理のためのライブラリは多数優れたものがあるのですが、特定のライブラリに依存してしまうと将来的にそのライブラリが廃止や最新のNext.jsのバージョンに追従しないとなった場合に変更が大変です。そこで今回は状態管理のために新しいライブラリをインポートすることはせず、キャッシュ戦略として利用していたSWRを少し工夫して状態管理ライブラリとしても利用することにしました。 依存関係を作らないだけならreduxでも良かったのですが、Providerが複数個存在すると見にくくなるので、ここではSWRを利用しています。 ## CloudFront & LambdaEdge で画像をリサイズする 画像の最適化も大きな課題でした。サイズ問題だけならnext/imageで十分なのですが、s3は物理的にクライアントから呼ぶ際に距離が遠いのでどうしても取得自体に時間がかかってしまいます。そこで、CloudFront & LambdaEdgeを利用して画像をリサイズしつつキャッシュを保存することにしました。 具体的にはhttps://aws.amazon.com/blogs/networking-and-content-delivery/resizing-images-with-amazon-cloudfront-lambdaedge-aws-cdn-blog/ で紹介されていることをそのまま行っただけですが、CloudFrontのキャッシュを利用することで、かなり早く画像を取得することができました。