ID:72432さん

# プロジェクトの背景や目的 学習塾のクライアントはサービスができる前は、生徒35,000名の進路指導の情報をエクセルで管理し、生徒が実際に進んだ進路は電話を用いて情報を集めていた。進路の情報の管理自体が大変であることと、生徒がどこに進学したのかのデータが正しいデータではないことが課題にあった。そこで塾の講師がこのサービスを用い生徒とともに志望校を管理し、35,000名の合格実績を確実なデータにすることを目的にこのサービスは作られた。 # プロダクト機能概要 - 認証/認可機能 - 大学検索機能 - 大学情報詳細表示機能 - マイリスト機能 - 志望校の大学登録/編集/削除機能 - 志望校の入試日程のカレンダー表示機能 # 使用技術 | 項目 | 技術| | -----| -----| | フロントエンド | TypeScript,React,Jest | | バックエンド | Kotlin, SpringBoot, Kotest | | DB | MySQL| | インフラストラクチャ| Docker, AWS(RDS, S3, Lamda, DynamoDB, EC2, ECR, Cloud Watch) # チーム規模 10名(フロントエンド: 4名、バックエンド: 3名、インフラ: 2名、PM: 1名) 役割: 開発メンバー # 担当領域 - 1年目: フロントエンド担当 - コンポーネントの作成 - マイリストの登録機能の作成 - 詳細画面の絞り込み機能の作成 - カレンダーのライブラリの選定 - Jestでの単体,結合テストの作成 - テストの速度改善 - 2年目: フロントエンド/バックエンド担当 - 既存の機能の不具合修正 - 詳細検索機能の検索条件の追加 - 詳細画面の情報追加(2ヵ年表示など) - Kotestでの単体,結合テストの作成 - Jestでの単体,結合テストの作成 # プロジェクト課題 クライアントがサービスを作成したことがない方々のため、要求されている事項が詳細まで決められていない中で大きな課題が2つ存在しました。 1. **詳細が詰められていない中での開発** - サービスで用いるデータ自体は別クライアントが蓄積しているデータであったため、弊社のエンジニアが実データとクライアントの要求を照らし合わせて、実現可能性や仕様に抜け漏れがないかを考えながら開発を行う必要があった - UI/UXを考えながら開発を行い、ユーザー(生徒)にとって使いやすいものになるように提案を行いながら開発をする必要があった 2. **提供データの複雑性** - データの中には、提供先が提示しているデータの説明と違うものが存在したり、イレギュラーなデータが存在したため、データに合わせた対応が必要であった - 提供されているデータは常に最新データのみで、クライアントは過去の入試結果を蓄積して出したいという要望があったため、本サービスでデータを蓄積するようにする必要があった。 - データの更新時期なども項目によって時期が違うため、更新時期に対応してデータの取得方法を工夫する必要があった # 担当内容 ## マイリストの登録機能の実装 ### 課題 1. **大学に対して学部~コースまでが膨大なツリー構造になっている** - 1つの大学に対して、複数の学部、学科、専攻、コースがあり、さらに同じコースでも複数の試験があるため、編集時のマイリストの取得を実現するには工夫する必要がある 2. **生徒が進学した後はマイリストを修正しない要望** - マイリストの生徒の進学した先を後から修正できないようにしなくてはいけない 3. **クライアント側の詳細な要望がない** - マイリストの編集時の制御についての要望がないが、ユーザー(生徒)の使いやすさを考えて工夫する必要がある ## 解決策・工夫点 1. **APIの設計** - 編集時に選択項目のプルダウンを選択する度に、APIを叩くことにした - マイリストの編集APIで各項目の返却値が以下のようにした - 配列の中身が複数の場合は選択できる項目としてプルダウンで表示 - 配列の中身が単数の場合は、すでに保存されている項目のため、そのまま取得した値をテキストとして表示 - 配列の中身がない場合は非活性の未選択のプルダウンを表示 - **工夫点** - 膨大なツリー構造になっているため、選択肢を選択するたびにAPIを呼ぶようにした。 - 一度保存した内容は再度編集できないようにしたいという要望があったため、編集時に保存されている内容かどうかを判断できる設計にした。 2. **編集時の制御の提案** - マイリストの出願ステータスをユーザー(生徒)が選択し、保存した場合は、そのデータだけ削除できないように制御した - 編集中に試験名を選んだ際に保存されているマイリストの重複制御,編集中のデータ内での重複制御を行う - 編集時に親の要素を変更した場合は、選んでいた全ての子の要素は「未選択」にする - 編集した要素があるのに、他のページやブラウザを閉じようとした際にアラートを出す - **工夫点** - 編集時の制御についてクライアントからの要望が無かったが、ユーザー(生徒)が使いやすいマイリストにするために上記の重複・削除制御や挙動を行うように提案した - 提案内容を受け、必要であることを理解していただき、実装を行った # 成果 本サービスの開発を通して、以下の4つの成果を得た。 1.**正確な進路のデータの蓄積** - 生徒**35,000名**の進路を正確なデータとして蓄積。 2. **安定したリリース** - ユーザー(生徒)が使いやすいものを追求して開発をしていたため、2年間でユーザー(生徒)からの問い合わせが1~2件しかない。 3. **売上1億円達成** - 2年間で大きなリリースは3回終わり、**9,000万の売上**を出すことができた。クライアント満足度が高いことによって、**現在も約1,000万の追加発注**を受けている。 4. **開発だけでなく要件定義から関われるようなメンバーになる** - 本サービスに0→1の段階から現在までと長く関わることで、立場が少しずつ変わっていくことができた。当初は1メンバーとして関わっていたが、要件定義や詳細設計に携わっていくことができるようになった。

# プロジェクトの背景や目的 よりエンタメサービスを使っているユーザーに還元するために、元々あったポイントの運用を新しくしたいという要望があった。そこで今まで無かったランクシステムを取り入れ、ポイントの計算の仕方も変更するためにランク/ポイント基盤を作成することになった。 # プロダクト機能概要 - S3に置かれた各サービスの購買データやサブスク登録データ、ユーザーのデータのCSVからランク/ポイントを計算しデータベースに保存するバッチの作成 - ポイント履歴取得/所持ポイント数取得/ランク取得APIの作成 - ランクごとのユーザーCSVを作成し、S3に保存 # 使用技術 | 項目 | 技術| | -----| -----| | バックエンド | Kotlin, SpringBoot, Kotest | | DB | MySQL, Redis| | インフラストラクチャ| Docker, AWS(RDS, S3, EC2, ECR, SQS, Step Functions) | # チーム規模 6名(バックエンド: 3名、インフラ: 2名、PM: 1名) 役割: 開発メンバー # 担当領域 - 定例会に必要な資料の作成 - お客様に資料を用いて課題点を説明 - ユビキタス言語表の作成 - Kotlin,SpringBootでの環境構築 - Redis,Kotestの設定 - ローカルデータベース構築 - APIの作成/Basic認証の実装 - 結合試験のテストケースの作成 - 結合試験を行い,不具合修正 # プロジェクト課題 1. **複数の別サービスからのデータを精査して必要なデータを調査** - ポイントを付与する対象のサービスが6つあり、それぞれが別の会社が作成しているサービスであるため、共有されるデータの形式が様々であるため、クライアントが要求する単位でのポイント付与にはどのデータが必要かを調査し、選択する必要があった。 2. **ポイントやローンチの要件の変更が多い** - ポイントをどの単位で付与するかや、いつサービスをローンチするかなどの要件が決まるのが遅かったり、決まった後に何度も変更があった。 3. **伝えられたデータとの差異が存在** - クライアントからのポイントの計算に必要な実際のデータの共有に時間がかかり、さらに伝えられていた通りのデータでないことがあった。 4. **手動ポイント付与の考慮** - ユーザーからの問い合わせでポイントを付与することも多いため、手動でのポイントの付与を行う仕組みを作成する必要があった。 # 担当内容 ## 結合試験のテストケースの作成 ### 課題 1. **3つのAPIと5つのバッチのテストケースが作成されていなかった** - 要件通りに実装できているかの確認ができていない状態で開発が進んでいた。 - データ取り込み、ポイント付与バッチはそれぞれの6つサービスごとにデータの形が違うため、それぞれのテストケースを作成する必要があった。 - 手動でのポイント付与もサービスごとにそれぞれのテストケースを作成する必要があった。 ### 解決策・工夫点 1. **全てのAPIとバッチのテストケースを作成** - コードとシーケンス図を元に188項目のテストケースを作成 - 工夫点 - APIのテストケースでは返却値を記載し、バッチではバッチ実行前と実行後のデータベースの結果を記載するようにした ### 成果 テストケースを作成すると、以下の技術的課題が出てきた。 1. **元々の設計では一部ポイントの付与ができないことが判明** - サブスク系の連携されているデータが元々伝えられていたデータでは無かったため、クライアントが提示していた単位でのポイントの付与ができないことが判明 2. **想定通りの動きができていないことが判明** - 手動でのポイント付与をする際のデータ取り込みの考慮漏れが判明 - StepFunctionsやバッチが実行されない問題が判明 - 会員数が300万人を超えるとユーザーのCSVをS3に置く対応がエラーが出て実施できないことが判明 これらの課題をリリース前に判明することができたため、以下のことが達成できました。 1. **リリース時に大幅な不具合はなくリリースすることができた** - 特に1の判明は、当初の設計時では発見することはできない内容のため、テスト行ったことで提供されるデータについて修正が必要なことが判明し、再度設計し直して提供データと基盤共に修正することになった。 2. **今後のテストケースの運用方法の参考になることが決定** - 属人化を防ぐために実行結果などを記載していたため、他の人がテストを行う場合でも問題なく行うことができた - 今後は私が作成したこの様式で他の案件でもテストケースを作成していくことも決まった # プロジェクトの成果 本サービスの開発を通して、以下の6つの成果を得た。 1. **470万人のユーザーのポイント/ランクを新しいルールの中で管理することができるようになった** 2. **リリース前に大幅な改修が必要なことに気がつき、リリース後に大幅な修正がなかった** 3. **今回のリリースで3500万の売り上げを出すことができ、次回の追加発注も受けている** 4. **Kotlin、Spring Bootでの0→1の環境構築を担当し、実施することができた** 5. **APIを0→1で作成することができた** 6. **APIとバッチの実装のテストケースを作成や不具合修正などを行ったため、APIとバッチの全体の実装の理解を深めることができた**

# プロジェクトの背景や目的 過去のプロダクトは、弊社のAWSアカウント1つで全てのサービスのAWSリソースを管理していた。コスト管理が全てのAWSリソースでできていなかったり、コスト削減を今まで行なっていなかったため、コストの可視化とコスト削減を行うために発足した社内プロジェクトである。 # チーム規模 5名 役割: コスト削減メンバー 社内公募で応募してチームに参加 # 担当領域 - AWS弊社担当者とのMTG - コスト削減方法の調査 - 現在のコスト,状況の調査 - タグ付けルールの見直し,社内での周知 - タグがついていないAWSリソースへのタグ付け - 不必要なAWSリソースの削除 - EC2インスタンス削除候補/常に稼働が必要でないものの洗い出し - EC2インスタンスの削除候補をバックアップ取得/削除 - AMIの削除候補を洗い出し/削除 - EBSのタイプをgp2からgp3に変更 - EBSの削除候補洗い出し/削除 - S3の削除候補洗い出し/削除 - VPCの削除候補洗い出し/削除 # 担当内容 ## コスト可視化のためのルール作成 ### 課題 1. **1つのアカウントで複数のサービスのAWSリソースが存在しているため、それぞれのサービスのコストを可視化する必要があった** 2. **タグをつけるルールがあったが、周知されておらずタグがついていないAWSリソースがたくさんあった** ### 取り組み 1. 現状のタグルールで問題ないか再度精査し、ルールの修正を行った。 2. 現状の案件のタグマスタ表を作成した。 3. 全体でAWSリソースのタグルールとタグをつけることを周知した。 ### 結果 1. **各案件のコストがより精度が高く可視化することができた** 2. **タグがついていないAWSリソースにタグをつけることができた** 3. **今後新しく作成されたAWSリソースにタグをつけるルールを周知し、マスタを作成したことで、メンバー全員がAWSリソースにタグをつけることができるようになった** ## コスト削減 ### 課題 1. **今まで一度もコスト削減がされておらず、コスト削減の方法など弊社での今まで実施した内容などは無かった** 2. **10年前からのAWSリソースなどが存在しており、社内のドキュメントに情報がないものもたくさんあった** 3. **AWSに詳しいメンバーが少なかったため、それぞれで調査しながら進めていく必要があった** ### 取り組み より大きいコスト削減を行うために、Cost Explorerを用いてAWSリソースごとに弊社のコストが大きい順に並べ、それぞれのコスト削減方法を調査した。以下のAWSリソースの一覧を作成した。 - EC2インスタンス - AMI - EBS - S3 - VPC それぞれのAWSリソースに担当者をつけ、全体で周知し以下のように分類した。 - 削除可能 - バックアップ必要/不必要 - 削除不可能 - 手動起動可能 - 常に稼働 分類後は削除、停止、バックアップ取得、タイプの変更などを行いました。 ### 結果 この取り組みの結果、**月のコストが10%削減**することができ、削除し忘れていたAWSリソースが判明しました。

# プロジェクトの背景や目的 弊社では毎年エイプリルフールの企画を社員で企画~実施までを行なっている。様々な人に弊社を知ってもらい、一緒に仕事をしたいと思っていただくことを目的に実施している。 # 使用技術 | 項目 | 技術| | -----| -----| | フロントエンド | TypeScript, React, p5.js | # チーム規模 5名(フロントエンド: 4名、デザイナー: 1名) 役割: プロジェクトリーダー兼開発メンバー 社内公募で応募してチームに参加 # 担当領域 - 企画案作成,進捗確認,チケット作成,チケット割り振り - 既存の弊社のHPをエイプルフールの内容にするため開発 - p5.jsを用いてお問い合わせボタンを押すと砂が落ちるように機能を追加 - AIによる画像生成ツールにて画像の作成,画像の編集,動画撮影 # 対応内容 ## 課題 何をしても良いという自由度の中から、今年何を行うかをメンバーと共に考え、計画し実装を行った。 他の案件と両立しながらの実施と1ヶ月で企画~開発までを行い、仮完成をして欲しいという要望があった。また私自身が初めてリーダーとしてプロジェクトを動かすこととなった。 ## 取り組み 実際には支社はできないが、今年度弊社は地方の社員がとても増えたことから、様々な地方に社員が居ても隔たりなく開発ができていることを伝えらるようなエイプリルフールの企画にすることにしました。そこで鳥取に支社を作成したという内容で弊社のHPをリニューアルすることになりました。 実際に弊社での福利厚生の取り組みを鳥取支社用にアレンジしてAIで画像を生成したり、採用ページを鳥取支社用にアレンジして追加しました。弊社の会社のトップページが以前は画像だったのですが、動画に変更しました。お問い合わせボタンをp5.jsを用いて砂が落ちるように機能を追加する開発も行いました。 また、リーダーとして、企画から携わりタスクの分割や、タスクの割り振りなども行いました。 ## 結果 1. **1ヶ月でリーダーとして企画立案から開発完了まで進めることができた** 2. **エイプリルフールが終わった後も鳥取支社の内容以外の動画は、そのまま弊社のHPのトップに採用されています** ## 作成物 - [お知らせブログ](https://www.claves.co.jp/blog/2024-04-01-%E9%B3%A5%E5%8F%96%E7%A0%82%E4%B8%98%E3%81%AB%E6%96%B0%E3%81%97%E3%81%84%E3%82%AA%E3%83%95%E3%82%A3%E3%82%B9%E3%81%8C%E3%81%A7%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F%EF%BC%81/) - [エイプリルフール用採用ページ](https://www.claves.co.jp/recruit/tottoriengineer/) - [ネタバレページ](https://www.claves.co.jp/2024-april-fools/spoiler-page/)

# プロジェクトの背景や目的 EC・モール在庫の一元化により販売機会ロスの改善と在庫管理コスト削減を目的に中間システム導入プロジェクトが開始された。認証・会員・ポイント・バーコードDB・POS購買連携の機能、注文・在庫・お気に入りなどに関する機能などがprismatixとShopifyを用いてすでにリリースされている。外部サービス展開のためprismatixの利用をしていくために、連携開発が行われていた。 # プロダクト機能概要 - 認証機能 - 会員情報機能 - ランク・ポイント機能 - バーコードDB・POS購買連携機能 - 注文機能 - 在庫機能 - お気に入り機能 # 使用技術 | 項目 | 技術| | -----| -----| | バックエンド | Kotlin, SpringBoot, Kotest | | フロントエンド| TypeScript, React | | DB | MySQL | | インフラストラクチャ| Shopify, prismatix | # チーム規模 3名 役割: 開発メンバー # 担当領域 - 新規会員登録やパスワード再設定ができないなどのユーザーからのお問い合わせに対して調査,解消 - 本番DBの操作 - prismatix・ShopifyのAPI操作 - 住所情報をShopify側に寄せる対応のフロントエンド開発 - 既存テストの修正 # 担当内容 ## 技術的課題 Shopifyとprismatix連携開発していたため、どちらかの不具合や過去のデータ移行時の不要なデータ、イレギュラーデータによるデータの不整合が原因でユーザーからのお問い合わせ対応が発生していた。そのためお問い合わせ内容を元に本番環境のDBやprismatix・ShopifyのAPI操作を行う必要があった。 ## 取り組み ユーザーからのお問い合わせ内容に応じて、以下のような対応行っていた。 - メールのサプレッションリストの解除 - ユーザー作成 - パスワード再設定 - ユーザーの退会・アカウントロックの解除 ## 結果 本サービスのお問いわせ対応を行って以下のような3つの成果を得ることができた。 1. 既存のリリースされたサービスのキャッチアップを行い、追加開発ができるようになった。 2. 問い合わせがあった内容から原因を追求し、解消することができるようになった。 3. 本番環境のDB、prismatix・ShopifyのAPI操作ができるようになった。

# プロジェクトの背景や目的 クラアント様のサービスを利用している高校教員に継続的にサービスを利用してもらうためのポータルサイトを作成。 # プロダクト機能概要 - 認証/認可機能 - マイページ機能 - お知らせ機能 - コンテンツ表示機能 - 電子カタログ - 記事 - 動画 - セミナー申込機能 - アンケート機能 - お問い合わせ機能 - 管理機能 - 学校管理 - DM配信管理 - ユーザー管理 - お知らせ管理 - コンテンツ管理 - セミナー管理 - アンケート管理 - 問い合わせ管理 - 通知バー管理 # 使用技術 | 項目 | 技術| | -----| -----| | バックエンド | PHP | | フロントエンド| JavaScript | | インフラストラクチャ| Docker, Wordpress | # チーム規模 4名(フルスタック: 4名、フロントエンド: 1名、PM: 1名、デザイナー: 1名) 役割: 開発メンバー # 担当領域 - 議事録を元に画面一覧、画面遷移図、機能一覧の叩き台を作成 →こちらを用いてクライアントと必要な画面、機能などをPMが決めた。 - リンクをクリックするたびにリロードするように修正 - スタイル修正 - トップページ - コンテンツ一覧 - ヘッダー - フッター - ログイン画面 - 新規会員登録画面 - パスワード再設定 - コンテンツ詳細画面 # プロジェクト課題 1. クライアントがデザインへの要求が高いため、開発してすぐに確認が入る状態であり、1px単位での修正が必要であった。 2. リリース期日に対してぎりぎりの開発であったために、スタイルの確認に手が回っていなかった。 3. リリース1ヶ月前に不具合修正が最大時200個ほどあった。 4. Wordpressでの大幅なカスタムをしての開発経験が弊社で誰もいなかった。 5. 元々この案件の開発にはアサインされていなかったが、急遽不具合が多く人手が足りないため、1ヶ月だけアサインされた。 # 対応内容 ## 時間的余裕がない中でのスタイルの修正 ### 課題 上記の課題があり、さらに時間的余裕が無い中でキャッチアップと環境構築を行いながらの開発になった。不具合の数がとても多かったため、メンバー全員が余裕が無かったため、クライアントから上げられている不具合だけでなく、気がついた不具合は即時的に上げる必要もあった。また、不具合の中で優先度を適宜PMに確認して開発していく必要もあった。その中で以下の技術的課題が出てきた。 1. デザイナーが作成しているデザインを元に、スタイルが当てられているが全ての画面幅でどのようになるのかが考慮されていないスタイルの当て方であった。 2. positionで指定されているスタイルが多く、SafariとGoogle Chromeでスタイルの違いが目立った。 3. CSSの共通化があまり洗練されておらず、共通化の必要のないスタイルが当たっていた。 4. Wordpressで多くのプラグインを用いてカスタムして開発していたため、Wordoressのプラグインによるスタイルが当たっていることもあり、要件に満たしていない場合はプラグインのスタイルを打ち消してスタイルを記載する必要があった。 ### 取り組み 時間的余裕が無かったため、スタイルを修正しながら見つけた不具合があれば、その不具合のチケットを作成しPMに適宜報告をしていた。毎日のstand upでスタイル修正の優先度が認識とずれていないか、新しく優先度の高いものは無いか確認していた。 クライアントがデザイン通りにして欲しいという要望がかなり高く、デザイン通りのスタイルにして欲しいという要望があった。しかしデザイナーが作成しているそれぞれの画面は全ての画面幅を網羅していないため、どの部分を固定にするべきか判断が難しかった。そのような場合は、できる範囲の提案を複数PMに提案して、クライアントに確認し開発を行っていた。 また上記の技術的課題を解決するために以下の取り組みを行った。 1. 要素の外側の余白を固定するようなスタイルの提案と修正を行った。 2. 共通化すべきでないスタイルは開発時にリファクタを行った。 3. positionで指定されているスタイルは要素の外側の余白を固定するようなスタイルに修正した。 ## ヘッダーのユーザー名のスタイル ### 課題 ログインするとヘッダーにユーザー名を表示しているが、ユーザー名が長くなった場合の考慮が何もされていなく、クライアントとも議論していない状態であった。 ### 取り組み PMにユーザーの文字数が多い場合にどのような要望があるかクライアントに確認していただくと、以下の要望があった。 - ボタンの形は変えない - 文字は改行しない - 画面幅に合わせてボタンの最大幅と文字の大きさを固定し、そこに収まらない場合は文字の大きさを小さくしていく この要望に合うように文字の幅が画面幅に沿ったボタンの最大幅を超えたら、文字の大きさが小さくなるようにJavaScriptで実装した。 # プロジェクトの結果 本サービスの開発を通して、以下の4つの成果を得た。 1. リリースまでに全ての不具合を完了させ、リリースすることができた。 2. 今回のリリースで2300万の売り上げを出すことができ、現在も約240万の追加発注を受けている。 3. 弊社としてデザイナーが入った開発を初めてリリースすることができた。 4. Wordpressをカスタムして開発した初めての案件をリリースすることができた。