ID:67454さん

## プロジェクト概要 自社で展開している複数のサービスをリニューアルしながら、基盤を統合するプロジェクト ### 目的、背景 古くなりつつある既存サービスをリニューアルするため 複数サービスに分かれているデータを一元管理するため ### 規模感、チーム構成、担当した役割 ビジネス側 10 ~ 15名 プログラマ 10 ~ 15名 リニューアルするページを実装すること。 クライアントが操作するページのUI(フロントエンド) と、クライアントに見せるデータの取得や操作(バックエンド) を実装していました。 リニューアルするページに使用する共通UIを実装すること。 複数のページで共通するUIの部品(共通コンポーネント)を実装していました。 ### 使用技術や開発環境等 フロントエンド - プログラミング言語: TypeScript - Webフレームワーク: Next.js - UIライブラリ: React - CSS: Tailwind CSS - form: react-hook-form, Zod バックエンド - プログラミング言語: TypeScript - Webサーバ: Apollo Server - GraphQL Schema: Nexus.js - ORM: Prisma.js - DB: PostgreSQL - Docker インフラ - Cloud Run - Cloud SQL 開発環境 - Mac - Visual Studio Code ## 取り組んだ課題 プロダクトのシステムにない、「料金表ページ」について、クライアントが操作するページのUI(フロントエンド) と、クライアントに見せるデータの取得や操作(バックエンド) を実装しました。 ### どんな課題だったのか クライアントが、予算と相談しながら予算に合った料金と最適なオプションプランの条件を設定できるように、新しくページを作ること ### 技術的なアプローチや工夫した点 工夫した点は、元々料金表の計算ページは、自社の公開されていない Spread Sheet にしかないので、新しく DB に入れるオプションデータの種類を選定することと、クライアントにテーブル形式で料金を表示する操作性です。 クライアントが、ページにあるオプションデータのフォームの内容を変えると、それに応じた料金テーブルも自動的に変化します。 技術的なアプローチは、クライアントのキーボードでの入力だけでなく、チェックボックスやセレクトボックス、タブ、テーブルのセルでクリック入力でも、react-hook-form, Zod を使って、フォームデータの変更と検証と API 呼び出しができるようにしました。 これによって、送信ボタンを押さないで、料金テーブルも自動的に変化する仕組みを実現しました。 ## 取り組みの成果 取り組みの成果は、未経験であったが全く新しい技術を使いながら、要件定義から実装までの一連の流れを機能開発できるようになったことです。 元々、React でページのUI開発をするフロントエンドエンジニアとして入社しました。 現在1社目、2年目です。 初めは、React で共通コンポーネントののUI部分を中心に業務をしていました。機能開発の一部である要件定義やバックエンドのAPI開発が出来なかったからです。入社後に勉強し、データの取得や操作をするバックエンドのAPI 開発も業務で挑戦しました。知らなかった技術であった Nexus.js や Prisma のキャッチアップを行い、それを業務にどのように生かすのかを試行錯誤する日々でした。要望のUIから、必要なデータを洗い出し、APIの設計と要件を定義しました。 初めて挑戦した機能開発である、お知らせ一覧ページは印象に残っています。 今でこそ、小さな機能でシンプルな内容ですが、どのように要件を定義すればいいのか、UI と API と DB 全てをプロジェクトのどこに記述するのか、と多くのことを考えながら実装したので、とてもハードなタスクでした。 お知らせページのUI を確認し ビジネス側と意見を交換することで、「お知らせの一覧を取得できること」、「お知らせの内容は、id, タイトル、リンク、日付、未読状態であること」、「未読を表現すること」、「お知らせをクリックすると、お知らせ詳細に移動すること」、「お知らせをクリックすると、既読になること」と、1つずつ要件を設定しました。 ここから、必要になる API を設定しました。お知らせ一覧 query, 既読 mutation の API です。DBに保存するデータを相談しながら、それぞれの input と output を設計しました。 以下のように実装していきました。 まずは DB についてです。Prisma を使用し、お知らせに必要な内容(フィールド)を DB に追加しました。他の人の実装を参考にしながら、プロジェクトのディレクトリのどこに書けばいいのかを類推しながら進めました。Prisma の公式ドキュメントで勉強した内容が役に立ち、ホッとしたのを覚えています。DB クライアントを使うことで、DB にお知らせのフィールドが追加されたのを確認できました。 次に API についてです。Nexus.js (nexus-prisma) を使用し、お知らせ一覧 の API を query に追加しました。こちらも、Nexus.js の公式ドキュメントで勉強した内容と他の人の実装を参考にしながら、プロジェクトのディレクトリのどこに書けばいいのかを類推しながら進めました。この段階で一度、実装の方向性として正しいのかを確認してもらいました。 その後は UI についてです。Next.js(React, TypeScript) を使用し、GraphQL の query で「お知らせの一覧」を取得し、「未読」付きの「お知らせの一覧」UIを作成しました。GraphQL でデータの繋ぎ込み部分は他の人のを参考にしましたが、サクッとページ実装しました。 最後に、Pull Request としてマージした新規機能(新規ページ)を、ビジネス側の人と、参考のUIと要件を満たしたのかをステージング環境で検証しました。UIについてちょっとした修正はありましたが、2度目に完成しました。 最初こそシンプルなお知らせ一覧ページでしたが、お知らせ詳細ページや、プロジェクト編集ページ、ゆくゆくとして、上述した料金表ページと少しずつ難しい機能を開発できるようになりました。 未経験であったが全く新しい技術を使いながら、要件定義から実装までの一連の流れを機能開発することが、取り組みで出来るようになったことです。

## プロジェクト概要 既存プロダクトで発生したエラーログのバグを修正 ### 目的、背景 既存プロダクトを問題なく使えるようにするため ### 規模感、チーム構成、担当した役割 ビジネス側 2 ~ 5名 プログラマ 2 ~ 5名 現在運用されている既存プロダクトで発生したエラーログが出ているので、エラー原因を特定すること。 複数の解決策の中から、工数とインパクトのバランスが良い解決方法を意見交換し、エラー修正をすること。 ### 使用技術や開発環境等 フロントエンド - プログラミング言語: TypeScript バックエンド - プログラミング言語: TypeScript - Webサーバ: Ruby on Rails - Docker インフラ - AWS EC2 - AWS CloudWatch 開発環境 - Mac - Visual Studio Code ## 取り組んだ課題 現在運用されている既存プロダクトのエラーログの修正。 ### どんな課題だったのか エラーの内容は、詳細URLを要求するが、エラーログのパラメータを調査するとプロフィールURL になっている。 ### 技術的なアプローチや工夫した点 工夫した点は、以下の2点です。 1点目は、「詳細URLを要求するが、エラーログのパラメータを調査するとプロフィールURL」であることを特定したことです。 Slackに通知されたエラーログから、詳細のエラーログ(スタックトレース)を見つけ、Web アプリケーションの処理と比較することでエラーの原因を特定しました。 Cloud Watch の使い方を勉強し、具体的なエラー箇所を大量のログの中から特定しました。エラーのスタックトレースから Rails のアプリケーション処理を調査し、要求する URL 形式が 詳細ページのURLであるが、実際に送られた URL 形式が プロフィールページのURLであると発見しました。 2点目は、特定したエラー原因から解決策を考えて、工数とインパクトのバランスが良い解決策を議論し、実装をすることです。 今回は、工数の小さい「クライアントの操作するページに、詳細ページのURL の入手方法と、プレースホルダーでサンプルURL を提示する」解決策と、工数が大きく、クライアントが今までのように登録できなくなり変化がある「クライアントが間違ったURLを指定した時にエラーを検知できるように、操作するページとデータの取得や操作するサーバにエラー検証をするバリデーション処理を追加する」解決策の2つありました。 相談したところ、ページでURLを指定する説明が分かりやくなるので、まずは工数の小さい解決策をリリースしてこのエラーが少なくなるかを経過観察しようとなりました。 ## 取り組みの成果 取り組みの成果は、プログラミング的な解決策だけでなく、様々なやり方を組み合わせて、限られたエンジニアのリソースを配分することです。 個人開発も含め、今まで可能なら技術的にエラーが発生しないように、より完璧に修正するように開発をしてきました。 ただ業務の中では、日々新しい要求や改善、新規開発が出てきます。 その数は際限がありません。しかも新規開発と異なり、保守はプラスの価値を生まず、マイナスを0にする業務です。 ですので、間違った状態とならない完璧だが工数の大きな修正をする前に、エラーの数が減る小さな修正で経過観察できないかといったアプローチを学びました。大きな修正の場合、デグレと呼ばれる今まで動いていた部分がエラーになることが発生したり、そもそも修正にそこまで時間が取れなかったり、と様々な課題があるためです。 保守運用の取り組みで得た成果は、業務を進めるにあたって、プログラム的な解決策だけでなく、運用手順でカバーする、より詳細な説明を追加する、重要でないのでその工程を削除する、エラーの数が少ないので、次エラーが発生するまで何もしない決定をする、といった複合的な解決アプローチがあり、相談しながら決定することです。