ID:66730さん

# プロジェクト概要 ## 目的・背景 会員情報登録・変更の導線のUI/UXの向上を図ること、レガシーな技術を刷新することを目的としたプロジェクトです。 ## 役割 フロントエンドとバックエンドの開発で、チームは5人ほどでした。チーム内ではプロジェクトのリーダーとして主にフロントエンドの開発に従事しました。 ## 使用技術 フロントエンドは、TypeScript、React.js、Next.jsで開発を進めて、デザインツールはFigmaを使いました。バックエンドはPerlでした。DBMSはMySQLで、プロキシサーバーとしてNginxを採用していました。 # 取り組んだ課題 途中からの参画でしたが、仕様に不明確な点が多く、特に会員情報の変更の導線に関して変更点が多くありました。そのため、顧客と綿密に会話を重ねながら仕様を見直して、プログラムの設計を変更しながら進めました。 ## 会員パターンついて 会員変更については、会員のパターンが多くあることが課題でした。会員種別が無料会員、有料会員、クーポン利用会員、アプリ利用会員で、会員の状態を含めると15パターンあり、今後も変更が必要になることが予想されるため、TypeScriptの型定義で１箇所で管理できるように工夫しました。 ## 課金登録のフロー 課金手段はクレジットカード、キャリア決済、クーポン利用など多様にありました。また、会員のパターンとして支払状況による分岐が必要でした。条件分岐が複雑化したり、1つのファイルが肥大化する傾向にあったため、コードの可読性、処理の再利用性に留意して責務を適切に分けるように進めました。 # 取り組みの成果 リリース後は大きな不具合は見られず落ち着いた運用を行うことができています。また、仕様変更が行われることが度々ありましたが、素早い対応が可能でした。可読性、再利用性、責務など基本的なことに留意したプログラムの作成に努めたことや、使用に関して顧客と会話を重ねたことが要因かと思います。 技術的には、SEOに配慮する必要のない動線であるため、Next.jsのSSGを利用しており、動的に変化するパスも可能な限り事前に設定するようにしています。そのため、素早く画面を表示することができています。また、グローバルな状態管理（Context API）を使って、ブラウザの「戻る」や「進む」の操作をおこなった際にも入力したデータが復元されるようにしています。

# プロジェクト概要 ## 目的・背景 モニター上でプロセス間通信の監視を行っていたが、既存のDatadog上のダッシュボード内で図で表示したりアラートを発出するように設定することで、監視の運用の効率化を行うために開発を行いました。 モニター上で表示される情報を再現するために、監視を行うサーバー（HTTP通信）から取得するプロセス間通信の情報と配置されたcsvファイルから取得する監視対象の情報を結合してDatadogへ送信するデータを生成する必要がありました。 ## チーム チームは3人ほどで前任から引き継ぐ形でした。プログラムの開発は1人で行いました。 ## 使用技術・開発環境 プログラムはGolangで開発し、サーバーとの結合は本番環境で行いました。 # 取り組んだ課題 ## 設計の改善 前任から引き継いだため、既に設計は行われていましたが、既存のシステムを参考に、必要な情報を表示するように設計を見直して顧客に提案を行いました。その際には、資料を作成し、Datadogの仕様の説明を行いつつ費用対効果を強調して提示しました。提案には合意いただいて、その設計に基づいてプログラムの変更を行いました。 ## プログラムの改善 csvファイルの読み込みのためにフォーマットを変換する必要がありましたが、それを手動で行うようになっていたため、ファイルパスの指定のみで必要な情報を抽出できるように改善しました。 # 取り組みの成果 Datadog上で管理できるようになったことで、どこからでも素早く確認できるようになったことで顧客にも満足していただけました。 技術的には、開発効率が良い点がメリットであると感じました。静的型付け言語であるため不整合が起きづらく、コンパイル時には型や使用していない記述に関して警告されるため不具合を未然に防ぐことができました。また、多様なライブラリが標準で備わっており、ライブラリのソースも分かりやすく理解の助けになりました。ビルド時には、OSの環境を選択して素早く行うことができて良かったです。

# プロジェクト概要 ## 目的・背景 オンプレミスなサーバーからGCPへ移行するプロジェクトがあり、その一環としてモバイルアプリの設定が記述されたファイルの一部をGCSに移行することとなりました。 ## チーム チームは2人で、ほとんど1人で開発を行いました。 ## 使用技術・開発環境 移行する対象は静的な資材のみで、xmlファイルとjsonファイルでした。それらをGithub Actionsを使ってGCSに自動デプロイすることが必要でした。また、デプロイ先は既存サーバーとGCPで、それぞれ開発環境と検証環境と本番環境がありました。プロキシサーバーとしてNginxを使っていました。 # 取り組んだ課題 ## リポジトリの構成の見直し 各環境に応じてデプロイするファイルが異なることや既存のサーバにデプロイする必要もあったことから、各サーバーに応じたディレクトリの配下に各環境に応じたディレクトリを作成し、その配下にファイルを配置するように変更しました。また、コードの整形や形式のチェックを行うようにeslintやprettierを導入しました。 ## CI/CDの構築 Github Actionsで実装を行いました。コードの整形や形式のチェックを行うコマンドを自動で実行するようにして、各環境に対応したブランチにマージしたときにGCSへデプロイするようにしました。デプロイは環境ごとに対象のプロジェクトが異なるため、基本的なスクリプトを再利用できるように1つのファイルにまとめて、各環境ごとのファイルから呼び出して設定を読み込むだけで実行可能な構成としました。 ## Nginxの設定 Nginxを使ったサーバーでリバースプロキシを行なっています。新たにキャッシュの設定やGCSへのリバースプロキシの設定を行いました。 # 取り組みの成果 GCPへの移行の先駆けとして取り組んだプロジェクトであったため、Github Actionsで用いた構成は他のGCPへの移行のプロジェクトでも採用されました。また、ファイルに変更があった場合でも統一感のあるコードで見やすくなり、GCSへのデプロイは素早く行うことができるようになりました。

# プロジェクト概要 ## 目的・背景 女性を対象にWeb制作やWeb開発に関する技術を学ぶ教材をオリジナルのプラットフォームで提供するサービスを新規に開発するプロジェクトであり、初めは教材を作成する側で参画しました。その後、フロントエンド開発を行なってほしいとの依頼があり、0から開発を進めました。 ## チーム フロントエンド2人、バックエンド2人で始まりました。その後、フロントエンドは私1人で開発を進めることになりました。 ## 使用技術・開発環境 フロントエンドはTypeScript、React.js、Next.js、SWR、Chakra UIで開発し、ホスティング先はAWS Amplifyでした。バックエンドはPHP、Larabelで開発し、デプロイ先はEC2でした。DBMSはMySQLで、RDSを利用していました。 # 取り組んだ課題 ## ユーザビリティの向上 Figmaでデザインがありましたが、具体的な操作に関してはあまり決まっていませんでした。そのため、メッセージの内容や表示などを見直して、ユーザーが現在の状態を理解しやすくなるように提案を行いメンバーと検討を行いました。 ## アクセシビリティへの配慮 基本的にキーボード操作で完結するように実装しました。また、運営からの要望により目や耳にハンデを持つ方も利用しやすいように各種属性値を設定したり、フォントサイズは相対値としました。 ## 設計 ディレクトリは、機能、共通のパーツ、ページ、リクエスト、モック、リクエストの設定、スタイルの設定で分類しました。機能に分類されるディレクトリでは、ページ単位でディレクトリを作成し、その中で細かく機能を分けてディレクトリを作成しました。コンポーネントは、機能と密接に関係するUIと機能に関するロジックで分けて作成しました。 修正や機能追加を行いやすくすることを目指しました。適切な粒度で責務を切り分けることで最小限の変更で完結すると考えていました。また、ページ単位でディレクトリを作成することで見通しの良いコードになると考えました。 ## パフォーマンスの向上 動画の再生では多くのリクエストが生じるため、状態の変更が多くなります。そのため、なるべくuseStateやuseEffectの利用は避けたり、積極的にメモ化を行いました。目安としては、LighthouseのPerformanceで90以上の高スコアの獲得を目指しました。