ID:54620さん

# 所属 株式会社LIFULL # 概要 指定された商品を契約している会員向けに、その契約した商品に紐づいた物件のみを掲載した物件一覧を開発 https://www.homes.co.jp/mansion/chuko/special-theme/price-change/tokyo/list/ # 体制 - 企画職 1名 - テックリード 1名 - エンジニア 3名 - デザイナー 1名 # 担当 テックリード # 詳細 ## 背景 - 会員が退会しないよう、契約した商品に付随する機能を拡充することが求められた。また、不動産業界の繁忙期に合わせてリリースする必要があった。 - 既存の物件一覧を基に、新たな物件一覧ページを作成。 - 既存の物件一覧には、リニューアル前後の2バージョンが存在し、どちらを選んでも実装は可能だったが、リニューアル後の物件一覧はCVR（コンバージョン率）が低く、一時的に閉鎖されていた。ただし、この環境を流用して新しい物件一覧を作成することはできた。 - リニューアル前の物件一覧のソースコードは多くの領域と双方向に依存していたため、今回の実装で利用すると不要な機能が付随する可能性があった。一方で、リニューアル後の物件一覧は機能が少ないため、影響範囲を小さくできると考え、こちらを踏襲することとした。 ## 進め方と工夫 - 企画職の代わりに仕様書を作成 - デザインが必要な部分を洗い出し、デザイナーに作成を依頼。 - 必要な URL のパスを洗い出し、担当者に分担。 - SRP（Single Responsibility Principle）に基づき、6エリア × 4物件種別 = 24ページを作成。 - 共通部分を先に実装し、各ページを並行して分担実装。 - 重要なロジックはユニットテストで担保し、信頼性を確保。全ページの疎通確認には E2E テストを使用。手動テストは最小限にとどめ、効率化を図った。 ## 結果 - コード量は 75,000 行に達したが、実装後は障害が発生せず、順調に運用された - 実装量が多く、スケジュールに影響が出る可能性があったため、人員を増員して対応。 - 途中からの増員にもスムーズに対応できるよう、迷う可能性のある箇所を事前に実装し、共有。 - ベトナム人エンジニア 2 名に英語で実装指示書を作成し、作業を分担した。

# 所属 株式会社LIFULL # 概要 Home'sに掲載されている中古物件領域の会員が月額で利用できる商品を開発。物件ページに自社制作の動画を掲載できる機能を追加。 # 開発期間 - 1ヶ月目 β版をリリースし、PMFを測る - 2〜4ヶ月目 本リリース - 5〜8ヶ月目 追加機能リリース # 体制 - 企画職 2名 - テックリード 1名 - エンジニア 6名 - デザイナー 1名 # 担当 - テックリード - 全体システム・運用設計 - プロジェクト進捗管理 - アプリケーションのバックエンド側開発 - インフラ、フロント含むコードレビュー - テスト計画 - リリース計画 - DBスキーマ更新、依存関係のあるリポジトリなど # 詳細 ## 背景 - 売上を向上させるため、中古物件領域の会員向けに月額利用商品を新規開発することが決定された。 - 画像コンテンツは既に充実していたため、新たに動画コンテンツを追加することになった。 - 不動産業界の繁忙期に合わせたリリースが求められ、納期が厳格に設定された。 ## プロジェクトの全体管理とリーダーシップ - 会員向け画面、エンドユーザー画面、社内向け画面に関わる機能を担当。各アプリケーションは独立していたため、開発リーダーとして設計、エンジニアの配置、リリース順序、テスト計画を行った。 - 納期の2週間前に、すべての機能のリリースを完了させた。 ## 動画アップロード機構の構築 - 社内には動画アップロード機構が存在せず、インフラの構築が必要となった。 - 一般的な方法でバックエンドから動画ファイルをS3にアップロードする設計を検討したが、WAFの帯域を圧迫する懸念があったため、フロントエンドから直接S3にアップロードする設計に変更した。 - 動画の最適化を行い容量を圧縮するため、S3にアップロードされた動画を検知し、AWS Elemental MediaConvertで動画を最適化し、通信量と保存容量を節約。 ## ドキュメント作成と関係者との調整 - 社内の関係者が多かったため、今後の賃貸や新築領域への展開を見据え、どの職種の社員が見ても理解できるドキュメントを作成し、プロジェクトの進捗と設計を共有した。 ## 成果 - この新機能の導入により、会員向け商品の売上が月額1,000万円の増加を達成。年間売上にすると1億円以上の増加となり、事業成長に大きく貢献した。 ## その他 - 不動産業界のため、1~3月は繁忙期。繁忙期中にリリースすることがマストだったが、遅延せずリリースを完遂。 - この期間週休3日制を利用していたため、週4日の勤務で達成している

# 所属 株式会社LIFULL # 概要 LIFULL HOME'Sにおける複数の領域（賃貸、中古、マイページ等）の基盤刷新とマイクロサービス化に伴い、ABテスト機構が移植されていない状況が続いていた。マイクロサービスごとにABテスト機構を個別に開発することは、保守コストが高くなるため、全てのマイクロサービスで共通して利用できるnpmパッケージを開発し、コスト削減と運用効率の向上を目指した。 # 体制 - プロジェクトマネジャー兼テックリード 1名 - エンジニア 2名 # 担当 - プロジェクトマネジャー - テックリード # 詳細 ## 実装背景 - 元々LIFULL HOME'Sのソースコードには賃貸、中古、新築などの複数の領域が含まれており、近年その各領域がマイクロサービス化されたが、ABテスト機構は移植されていなかった。そのため、市場学習スピードが低下していた状態だった。 - ABテスト機構を移植するにあたり、全てのマイクロサービスで利用可能な形にし、既存の使いづらい点を解消することを目指した。 ## 既存のABテストの問題 - 設定ファイルがアプリケーション内にあり、デプロイが必要 - ABテストの設定ファイルがアプリケーション内にあり、設定変更や削除を行うたびにデプロイフローを通さなければならない状況だった。また、設定ファイルが1つに集約されていたため、コンフリクトが発生しやすくなっていた。 - アプリケーションへの強い依存 - 新規のABテストを開始するために実装ミスがあると、ページ全体が500エラーを引き起こす可能性があった。 - 均等に振り分けがされない可能性 - 既存のロジックではリクエストごとに確率で振り分けが行われるため、偏りが生じやすい問題があった。 ## 工夫点 - 設定ファイルの独立化 - 設定ファイルを別リポジトリで管理し、設定の追加・変更・削除時にはプルリクエストを作成し、マージすることでS3にアップロードされる仕組みを構築した。この仕組みにより、設定ファイルの管理が容易になり、コンフリクトも減少した。 - 依存の少ない機能 - packageとして提供したことで、利用側に使い方を任せることができ、ABテストのロジックで失敗してもエラーが起きないようにハンドリングしやすくなった。 - 偏りの起きにくいロジックに変更 - ABテストの振り分けロジックを見直し、`SHA256` の特性を活用して、より均等に振り分けが行われるように改善した。 ## 役割 - 企画・要件定義 - 各領域のエンジニアおよびプランナーと連携し、現状のABテスト機構における使いづらい点をヒアリング。その上で、実装工数が大きくならない範囲で問題を解消できる要件を策定した。 - 設計 - システム構成を大まかに設計し、各担当を決定。 - 実装 - npm packageの開発を担当しつつ、設定ファイルの管理システムのコードレビューも行う - リリース・運用 - 開発したnpm packageを実際に1つのアプリケーションにインストールし、ABテストの振り分けが均等に行われるかを確認するAAテストを実施。 ## 成果 - 既存のABテストに比べ、挑戦パターンの採用、中止、再挑戦のケースにおいて1~2日程度の工数削減となった - 取り組みをブログで公開 - https://www.lifull.blog/entry/2024/03/29/173000

# 所属 株式会社LIFULL # 概要 既存のRubyで作られたレガシーなBFF（Backend For Frontend）をTypeScript製のBFFにリプレイス # 体制 エンジニア 1名 # 詳細 ## 背景とリプレイスの経緯 - 既存BFFはRubyのSinatraフレームワークを使って作られており、シンプルな作りが特徴だったが、プロダクトのドメイン知識が複雑で、コードが煩雑化していった。似たようなメソッドが乱立し、メソッド間の依存関係も不明瞭になっていた。 - 10年近くリファクタリングが行われず、技術的負債が蓄積されたため、新規BFFにリプレイスすることが決まった。 - 複雑なドメイン知識を効率的に表現するため、クリーンアーキテクチャとドメイン駆動設計（DDD）を採用。 - フロントエンドとの言語統一や、コンパイル時に早期にエラーを検出できるメリット、型定義の柔軟さから、TypeScriptを選定。 ## 移行手順と実施内容 - フロントエンド側で利用されているエンドポイントが多いため、それらを1つずつ順番に移行するアプローチを取った。 - 新規BFFでエンドポイントを作成後、フロントエンド側でリクエスト先を新しいエンドポイントに変更することで、1つのエンドポイントの移行が完了する流れ。 ## 実装と工夫点 - Rubyで表現されていたロジックをTypeScriptに書き直すだけでなく、より効率の良い書き方にリファクタリングすることも同時に行なった。 - クリーンアーキテクチャの方針に沿って、コードの可読性と保守性を高める実装を実施。 - クリーンアーキテクチャを理解しているメンバーが少なかったため、実装前に勉強会を開催してチーム全体の理解を深め、その後実装タスクを割り振りながらコーチングを行った。

# 所属 オープンワーク株式会社 # 概要 web版で実装された機能をネイティブアプリに実装するため、iOSおよびAndroidアプリが呼び出すREST APIの設計・開発を担当 # 体制 企画職 1名 テックリード 3名（web, iOS, Android） エンジニア 6名 デザイナー 1名 # 担当 テックリード（エンジニアリングマネジャー） # 詳細 ## 開発体制 ネイティブアプリから利用されるREST APIの設計・開発を行い、web版で実装された機能をネイティブアプリに後追いで実装した。開発体制はiOS、Android、web APIの3つのスクラムチームから成るスクラムオブスクラム形式で進行した。 ## 役割 web APIチームのスクラムマスターとして、スクラムプロセスの運営を担当。また、web APIチームのエンジニアのメンバーマネジメントも兼務した。 ## 設計 社内勉強会で学んだクリーンアーキテクチャとDDDを実践し、現場に適した最適な設計を目指した。メンバーと議論しながら設計を進め、プロジェクトの要求に最も適したアーキテクチャを構築した。

# 所属 オープンワーク株式会社 # 概要 toCプロダクトに追加する新規コンテンツ（推定平均年収）の開発 # 体制 - PM 1名 - 開発リーダー 1名 - エンジニア 1名 - デザイナー 1名 - アナリスト 1名 # 担当 開発リーダー # 詳細 ## システム構成 バッチサーバーでDBからデータを読み取り、計算を実施。その結果をDBに保存し、保存されたデータをアプリケーション側で読み取って画面に描画する仕組みを構築した。 ## 技術選定 データサイエンティストが構築した推定年収ロジックを実現するため、Pythonを採用。画面描画に関しては動的に変更できるグラフの実現を検討したが、保守コストを考慮して要件を見直し、CSSのみで実現できる形に変更した。 ## 動作環境の整備 Pythonが動作する環境が社内に存在しなかったため、新規のバッチサーバーをECSで構築した。 ## 実装順の調整 仕様確定の遅延と、リリース後のプロモーション展開が確定していたことから単納期となった。仕様決定中にアプリケーション側ではプロトタイプ的に実装を進め、仕様確定後に実装完了を早める形にした。アプリケーション側の実装が早めに完了したため、バッチサーバー側の実装を協力して進め、納期に間に合わせることができた。 ※下記はプロモーションの一部 https://newspicks.com/news/5434914/body/

# 所属 オープンワーク株式会社 # 概要 toBプロダクトの開発リーダーとして、プロジェクト管理から実装、技術指導まで幅広く担当。 # 体制 - PM 1名 - 開発リーダー 1名 - エンジニア 4名 - デザイナー 1名 # 担当 開発リーダー # 詳細 ## プロジェクト管理 入社後すぐに開発リーダーを担当し、PdMと協力してプロジェクト管理を行った。プロジェクト内の全エンジニアの開発タスクを把握し、大まかな工数見積もりを実施。タスク・スケジュール管理ツールの選定と導入も行い、プロジェクトの進行を効率的に管理した。 ## 仕様決定・設計 PdMが作成した仮の仕様書に基づき、実現可能性や工数感を踏まえて最終仕様を決定。開発工数と保守性のバランスを考慮し、実装方針や開発体制を決定した。 ## 実装 既存実装はjQueryで作られていたが、フロントエンドの刷新が進んでいたため、新規実装はVue.jsを選択して行った。 また、売上実績に関わるデータを取り扱っていたため、DBへの書き込みだけでなく、Salesforceへの並行書き込みも実施した。 ## 技術指導 日常的にコードレビューを通じて技術指導を行い、エンジニア全体の技術力向上を目的とした定期的な勉強会も開催した。

# 所属 アライドアーキテクツ株式会社 # 概要 既存プロダクトの機能を他社のオウンドサイト上でも展開できるサービスを開発 # 体制 ビジネス職 2名 エンジニアリングマネジャー 1名 エンジニア 5名 デザイナー 1名 # 担当 エンジニア # 詳細 ## 技術選定 新規プロダクトのため、エンジニア内で技術選定から始めた。 バックエンドはPHP経験者が多かったため、言語はPHPを選択。フレームワークはプライベートで触った結果、実装しやすいと判断しLaravelを選択。 フロントエンドは当時流行していたSPAに対応しやすくするため、Vue.jsを採用。 開発環境としては、当時開発者が増えたことを考慮し、Dockerを選択した。 ## 実装範囲 toBおよびtoCの画面開発が必要で、実装規模はtoB:toCが3:7の比率だった。 エンジニアは7名で、スケジュールがタイトだったため、私自身の挑戦も兼ねてtoBの画面を1人で担当した。 ## コミュニケーション 日本のオフィスには2名のエンジニアがいたが、その他の5名はベトナム人エンジニアであり、共通語は英語だった。実装関連のコミュニケーションをテキストベースの英語で行い、チーム間で円滑に情報共有を行なった。