ID:73941さん

## プロジェクト概要 企業データベースサービス[アポトル](https://www.willgate.co.jp/apotoru/)の新規開発プロジェクトに参加しました。 既存チームメンバーが 2 人のところに途中から加わり、その後メンバーは最大 6 名まで増加しました。 新規事業であり「どのようなソリューションがユーザーの課題解決につながるか」もまだ明確でなかった中で、短いサイクルでの仮説検証を繰り返しながら作るものを定めていくスタイルでの開発でした。 ## 担当領域 フロントエンド、バックエンドの括りはなく開発メンバーとして参加し、以下を担当しました。 - PdM から共有された開発したい機能をもとに設計、実装、テスト、リリースまでを行う - ときには PdM 側に仕様やデザインについてのフィードバックや提案を行い、それらについて一緒に議論する - チームメンバー間のコードレビューや、開発フロー自体の改善を行う - システムのパフォーマンス改善のための、アーキテクチャレベルでの技術検証や設計を行う --- 以下、いくつかの取り組み内容をピックアップして説明していきます（特に断りがない限りチームの中で「私自身が行ったこと」の観点で書いています）。 1. Web ページクローリングの仕組みの構築 1. アプリケーション用の RDB のテーブル設計方針の策定 1. 検索機能のパフォーマンス改善（全文検索エンジンの導入） 1. フリートライアル機能の実装 1. チームでテストコードを書くための仕組みの構築 ## 取り組み内容 1「Web ページクローリングの仕組みの構築」 ### 取り組みの概要 事前に URL がリストアップされた Web ページのソース（HTML）を取得し保存する処理の実装とそれを動作させる仕組みを設計しました。 なお、クローリング対象の Web サイトは、事業責任者および自社の法務部門の確認を通したうえで決定しています。 ### 課題・問題点 - 対象の URL が約 90 万件あったこと - Web サイトの JavaScript によって動的に生成される要素も取得する必要があったこと ### 使用した技術 - Node.js - Puppeteer - AWS Lambda - Amazon SQS - Amazon S3 ### 工夫した点 約 90 万件あるクローリング対象を極力早く処理できることを目指しとしつつ、ジョブの管理を煩雑にさせたくなかったため、1 件ずつの処理は AWS Lambda 上で動作するシンプルなプログラムにし、それを Amazon SQS からキックする構成としました。 これにより処理のペースを AWS Lambda の同時実行数によって制御できるようにしたり、失敗した処理はデッドレターキューから取り出して再実行できるようにしたりできました。 また、この仕組みをチームで運用できるようにするために - 全体の構成や AWS Lambda、Amazon SQS の設定値などを意図とともにドキュメントに残した - Makefile を作成して Lambda にアップロードする zip ファイルを `make` コマンドだけで完結できるようにした ということも行いました。 ## 取り組み内容 2「アプリケーション用の RDB のテーブル設計方針の策定」 ### 取り組みの概要 ユーザーが利用する Web アプリケーションを構築するための RDB のテーブル設計方針を定め、初期のテーブル設計を行いました（スクレイピングによって収集したデータとは別）。 ### 課題・問題点 Web アプリケーションでは、複数の条件を組み合わせて企業の検索できる必要がありました。 元となるデータは「ある時点の特定のサイトからスクレイピングしたデータ」であるのに対して、検索項目の中には - 「ここ 1 年で従業員が増加した企業」など複数時点のデータを比較する必要があるもの - 複数の情報源から同種の情報を取得しており、最も信頼性の高いものを正とするもの など複数のデータから算出されるデータがありました。 ### 使用した技術 - MySQL - Amazon RDS ### 工夫した点 テーブルを事実のデータ（「どの情報源から、いつ、どの情報を取得した」等）と、それらから所定のロジックで算出される検索用のデータ（「ここ 1 年で従業員が増加した企業」等）を分けるようにし、いつでも事実のデータを元に検索用のデータを更新できるような設計にしました。 これにより、算出ロジックの変更や検索項目の増減等があっても「検索用のデータを更新する処理を実行さえすれば最新の仕様に追従できる」という状態をつくりました。 ただし、検索機能それ自体も RDB（MySQL）でナイーブに実装してしまったため、全文検索エンジンを導入（後述）するまでの間パフォーマンス上の問題を生み出してしまいました。 ## 取り組み内容 3「検索機能のパフォーマンス改善（全文検索エンジンの導入）」 ### 取り組みの概要 MySQL でナイーブに実装されていた検索機能について、全文検索エンジンを導入することでレスポンスタイムを 1/10 以下に改善しました。 私は - OpenSearch について調査、検証 - インデックス設計 - Amazon OpenSearch Service の構成設計（インフラチームと協力） を担当し、Web アプリケーションの検索ロジックを MySQL から OpenSearch に移植するのチーム内の別メンバーに担当してもらいました。 ### 課題・問題点 - 約 500 万レコードを複数の条件を自由に組み合わせて検索できる必要がある - 検索機能が MySQL でナイーブに実装されていたため、重い検索条件ではレスポンスタイムが 1 分近くになることがあった ### 使用した技術 - OpenSearch - Amazon OpenSearch Service ### 工夫した点 導入にあたっては以下の 2 つの観点で事前検証を行い、あとから導入を断念するようなことが起きないように気をつけました。 - 実際のユースケースと照らし合わせ、本当に OpenSearch を導入することでパフォーマンス改善できるのか - 既存の検索項目や検索条件を洗い出し、それらを OpenSearch の機能でカバーできるのか 上記の検証結果は具体的な操作手順も含めてドキュメント化し、アプリケーションのロジックを移植するチームメンバーがスムーズに移植作業に入れるように心がけました。 また、Amazon OpenSearch Service の構成設計において、公式ドキュメントで推奨される構成では要件に対して可用性やパフォーマンスが過剰であったため、影響範囲を吟味したうえで専用マスターノードを使用しない構成にすることでコストを削減しました。 ## 取り組み内容 4「フリートライアル機能の実装」 ### 取り組みの概要 「フォームからサインアップでき、そこから 2 週間限定で無料で利用できる」というフリートライアルの機能を、機能実装について PdM から打診があってからリリースまでを 1 週間半で行いました。 私を含めたチームメンバー 2 名で開発をし、私は主に - 要求ヒアリングおよび要件定義 - テーブル設計 - バックエンドのロジック実装 - テスト設計 を担当しました。 ### 課題・問題点 - 事業の営業戦略上できるだけ早くフリートライアル機能が必要だったこと - これまでフリートライアル機能について検討していたわけではなく、完全に 1 からの設計だったこと ### 使用した技術 - TypeScript - Next.js - Prisma - GraphQL - Apollo GraphQL ### 工夫した点 後の工程で実装に集中できるよう、最初の打診があった後に PdM 含めて物理的に会議室に集まりホワイトボードを使って要件のすり合わせを行いました。 この際、開発するスコープを最小限にするように調整しました（例えば、フリートライアルから有料アカウントへ転換する機能は最初のリリースに含めず、それができるまでは手動のデータ更新で対応する旨など）。 もう 1 人のチームメンバーと作業を分担するため、日次で固定の時間を押さえたうえでお互いの状況を確認しながら情報共有やタスクの巻取りができるようにしました。 スコープは最小限かつ急ぎではあったものの、テーブル設計は妥協すると後に大きな禍根を残すことになるので後の機能追加を見越した設計をしました。 （例） - ユーザーそのもの表すテーブルと認証情報（メールアドレスとパスワード）のテーブルを分ける - トライアルユーザーと有料アカウントのユーザー情報のテーブルは分ける この際、認証ライブラリに使用していた Auth.js（旧：NextAuth.js）のデフォルト機能では要件を満たせなかったため、CredentialsProvider などを独自実装しました。 ## 取り組み内容 5「チームでテストコードを書くための仕組みの構築」 ### 取り組みの概要 チームメンバーがテストコードを書けるように - テスティングフレームワーク（Jest）の導入 - 参考となるテストコードの実装 - CI（Git Actions）の整備 - チームメンバーへの呼びかけ、意識付け を行いました。 ### 課題・問題点 - 参加当初はテストコードが一切書かれていなかった - 条件が複雑になる検索ロジックにおいてデグレードが頻発していた ### 使用した技術 - Jest - GitHub Actions - Docker - Docker Compose ### 工夫した点 検索ロジックのテストは MySQL や OpenSearch へのアクセスをテストダブルに置き換えても有効なテストができないと考えたため、実際にそれらへアクセスするものとした。 この際、開発環境（Docker / Docker Compose を使用）において以下のように工夫しました。 - MySQL は書き込みが発生する可能性があるので、開発用のものとはコンテナを分けた - OpenSearch は（テストを書きたいロジックにおいては）読み込みのみなので開発環境用のものと同じコンテナを参照することとした - OpenSearch コンテナ自体がマシンリソースを多く消費するため複数起動させることを避けたかった

## プロジェクト概要 当時新規事業だった[ソーシャルセリングサービス](https://www.willgate.co.jp/socialselling/)に関して、役務提供内容の一部をプロダクト化する企画、検証をしました。 また、業務フローの効率化のために Google スプレッドシートと Google Apps Script を組み合わせた仕組みづくりや、簡単な LAMP 構成での社内のシステムの開発および運用保守をしました。 エンジニアとしては自分 1 人で始まり、その後チームメンバーは最大 4 名までになりました。 最終的に、全社として別の新規プロダクト開発にエンジニアリソースを割く判断がなされたため、「ソーシャルセリング」という括りでのプロダクト立ち上げは保留となりました。 しかしながら、検証の過程で作られたスプレッドシート + GAS の仕組みや社内システムは残り続け、2024 年 7 月現在の業務フローにも組み込まれ続けています。 ## 担当領域 立ち上げ当初はエンジニア 1 人チームとしてシステムの設計や実装、運用に関わる部分はすべて担当しました（ただし、インフラの機能については権限を分離している都合上、具体の作業内容に落とし込んだうえインフラチームに依頼して作業をしてもらう形）。 また、新規事業立ち上げのフェーズであったためエンジニアリング以外にも - ビジネスモデルや業務フローを理解したうえでのプロダクトの企画 - 開発内容をすり合わせるための事業責任者とのコミュニケーション - プロダクトを開発するとなったときにかかるコストと投資回収時期の試算 などを行っていました。 --- 以下、いくつかの取り組み内容をピックアップして説明していきます（特に断りがない限りチームの中で「私自身が行ったこと」の観点で書いています）。 1. SNS アカウントの情報補完するスクリプトの実装 1. 人物情報をもとに SNS アカウントを推定、収集する社内システムの開発 1. SNS 上のつながりを利用した（営業文脈の）相互紹介のプロダクト企画、検証 ## 取り組み内容 1「SNS アカウントの情報補完するスクリプトの実装」 ### 取り組みの概要 SNS のユーザー名などの所定の情報から、アカウントの詳細情報（例えば Twitter（現 X）のプロフィール情報やフォロワー情報など）を API 経由で取得して出力する仕組みを構築しました。 ### 課題・問題点 「ソーシャルセリング」は営業手法のひとつであり、サービス提供のフローにおいて（クライアントの）営業対象となる人の SNS アカウントを収集しそのアカウント詳細情報を補完する作業が存在していました。 そして、この作業を手動で行っていることで作業スピードがボトルネックになってしまうため、役務提供できる量に限界がありました。 ### 使用した技術 - JavaScript（bookmarklet） - Google スプレッドシート - Google Apps Script ### 工夫した点 検証段階ではシステムとして作り込むことなく、小さなコストで運用できるように作業者に bookmarklet を提供しました。 その後、他の業務フローと親和性の高い Google スプレッドシートと Google Apps Script を組み合わせた仕組みも構築し、提供しました。 Google Apps Script を使う（使っても問題にならない）理由のひとつには、この仕組みを複数人で同時に利用する可能性が低いことから、データの同時編集（スクリプトの同時実行）を防ぐようなロック機構が不要だったことが挙げられます。 ## 取り組み内容 2「人物情報をもとに SNS アカウントを推定、収集する社内システムの開発」 ### 取り組みの概要 人物の所属企業名、氏名、役職情報が入力として与えられ、その人物のものらしき（所属企業や役職を明らかにしている）SNS アカウントを、各種 SNS の API や Google 検索結果などを用いて推定するシステムを構築しました。 ### 課題・問題点 先述の「SNS アカウントの情報補完」と同様にソーシャルセリングサービスの役務提供フローで必要な作業でありながら、手動で行っていることで作業スピードがボトルネックになってしまう状況にありました。 ### 使用した技術 - PHP - Web アプリケーションを開発する用途 - Slim（Web アプリケーションフレームワーク） - Bootstrap - MySQL - Node.js - 非同期に実行されるジョブを開発する用途 ### 工夫した点 先述の「SNS アカウントの情報補完」とは異なり複数人が同時に利用する可能性があること、処理実行の順番待ちの概念があったことから Google Apps Script での提供は無理であると判断しました。 一方で - 仕組みそのものは単純なこと - コストを極力押さえたい状況であったこと - 社内システムでありそこまで高い信頼性が要求されなかったこと といった点から、LAMP 構成の簡単な Web アプリケーションを t3a.small の EC2 インスタンス 1 台の上で動かすという判断をしました。 このシステムは初期構築後も大小の機能追加や改善のための開発を行いました。 それらの優先度判断やリリース時期の調整は事業責任者と直接すり合わせていました。 ## 取り組み内容 3「SNS 上のつながりを利用した（営業文脈の）相互紹介のプロダクト企画、検証」 ### 取り組みの概要 ソーシャルセリングサービスの一環で「相互紹介」というメニュー（「1 つのクライアントが SNS 上でつながっている人を別の誰かに紹介する代わりに、そのクライアントが営業対象とするアカウントを紹介してもらう」という取り組み）があり、これに関連するプロダクトを創り出せないかの企画、検証を行いました。 この企画はチームメンバー全員に加え、エンジニア部門の管掌役員も交えて行ったものです。 ### 課題・問題点 - プロダクト化以前に「相互紹介」という取り組み自体が事業として成立するかの検証段階であったこと - 既存のオペレーション（コンサルタントの手によって相互紹介できそうなクライアントどうしをマッチングさせる）で、すでに相互紹介が滞るような事象が発生していたこと - 明確に「こういうプロダクトを作っていく」というビジョンがあった訳ではなく、そのときのサービスの状態から「どの部分をプロダクトにすることで価値を生み出せるか」「そもそも何かプロダクトを作ることに意義があるのか」を探るところからやる必要があったこと ### 工夫した点 物理的に会議室に集まってホワイトボードを使ったり、Miro（オンラインホワイトボードサービス）を使ったりして、認識のすり合わせやアイデアを出し合いました。 相互紹介のカスタマージャーニーマップを描いたり、相互紹介が滞ってしまう事象についてヒアリングを重ねたりすることで、プロダクト開発による価値創出の仮説を立て、プロダクトのデザイン案（ワイヤーフレーム）をチームメンバーで一斉に作成しました。 その際には「他者とのマッチングという行為に踏み出させる」「本来やりたくない作業を継続させる」という観点からマッチングアプリや健康管理アプリのデザインを参考にしました（これらはチームメンバー間で話し合いながら出てきたアイデアです）。

エンジニア採用活動の一環として、技術広報の機能を持つチームを立ち上げました。 詳細は以下の記事を参照していただけると幸いです。 [ウィルゲート技術広報としての活動を振り返る 2019](https://tech.willgate.co.jp/entry/2019/12/04/120000) 2022 年には初めて[技術カンファレンスに協賛するための予算を獲得し](https://tech.willgate.co.jp/entry/2022/03/30/120000)、以降は会社として継続的に PHP 系のカンファレンスにスポンサーを出し続けています。

## プロジェクト概要 自社の複数サービスから使われている、5 年以上稼働していた LAMP 構成の基幹システム（Web API）をサーバレス構成にリニューアルしました。 3 人の開発チームのチームリーダーという役割でプロジェクトを完遂しました。 詳細は以下の記事も参照していただけると幸いです。 [LAMP 構成のシステムが抱えていた問題を Amazon API Gateway + AWS Lambda のサーバレス構成にして解消した話]( https://tech.willgate.co.jp/entry/2020/03/10/173000) ## 取り組んだ課題 主に以下の課題に対してリニューアルによる改善を試みました。 - 利用量増加が見込まれているのに対して、スケールしにくい構成になっていた - エラーが発生した際の状況再現や原因究明が難しかった - 実装について、当初の設計の意図が失われてしまいなぜそうなっているのか分からなくなってしまっていた ## 取り組みの成果 - 予定されていた期間内、スコープ内でプロジェクトを完遂 - Go 言語の性質と CI を併用して開発コストを下げつつ品質を向上 - ログの可視化によりエラー発生時の原因究明、回復にかかる時間を改善 - 不要になっていた機能（API エンドポイント）を見定めて削除 - 他システムから利用される際の仕組みやルールを刷新してリソースの利用効率を改善

## プロジェクト概要 SEO 分析ツール [TACT SEO](https://tact-seo.com/) および、記事編集チーム構築サービス[エディトル](https://client.editoru.jp/)の新規開発。 チームメンバーは 3～6 人で、チームリーダーの下に付いて開発をしていました。 サービスのリリース後は機能開発と運用保守の両方をしていました。 ## 取り組んだ課題 いずれのプロダクトでも技術面でのチームをリードする役割を担い、単なる開発タスク以外にも - 開発のための共通部分の整備 - 実装、設計方針の策定 - コードレビューや設計相談によるチームメンバーのレベルアップ - インフラチームとの連携 などをしていました。 ## 取り組みの成果 - 2018 年に TACT SEO およびエディトルのリリース - 2024 年現在もサービスが継続しています - クリーンアーキテクチャの概念を取り入れ、社内エンジニアメンバーに伝搬 - 社内に事例の無かった Vue.js の導入 取り組み詳細は外部での発表資料も参照していただけると幸いです。 - [プロダクトに 1 から Vue.js を取り入れた話](https://speakerdeck.com/okashoi/how-to-introduce-vue-dot-js) - [チームで「きちんと」Laravel を使っていくための取り組み](https://speakerdeck.com/okashoi/efforts-to-utilize-laravel) - [Laravel × レイヤードアーキテクチャをやってみている話](https://speakerdeck.com/okashoi/trying-laravel-with-layered-architecture)

## プロジェクト概要 Salesforce の社内向けのカスタマイズ開発、運用保守を行いました。 チームメンバーは 2 人で、チームリーダーの下に付いて開発や運用保守をしていました。 ## 取り組んだ課題 私が開発に参加したタイミングでは、データ設計に不備があったり、リリースフローが決まっていなかったために障害が起こりやすい状況でした。 そこから徐々に改善を重ねていきました。 ## 取り組みの成果 - エンジニアが関わらない勝手なリリースによって品質が損なわれていた状況から、開発ルールやリリースフローを策定することで障害件数を低減 - 注文や納品、請求に関する処理フローのリニューアルを要件定義からリリースまで行い、冗長なオペレーションとデータを削減 - 後続で参加メンバーに向けて、Salesforce 自体の仕様や自社向けにカスタマイズした内容、開発手法についての引き継ぎ資料を作成

## プロジェクト概要 新卒として入社してから数年間にわたって担当した業務で、SEO 事業に関わる社内の営業やコンサルタントを支援するシステムの運用保守、機能追加開発を行いました（雑多ものであるため複数システムを 1 つのプロジェクトにまとめています）。 チームメンバーは 2～3 人で、チームリーダーの下に付いて開発や運用保守をしていました。 システムの規模は MySQL のテーブル数で高々数十程度という小規模なものばかりでした。 ## 取り組んだ課題 会社としても Git を導入したばかりの時期で、開発体制を徐々に整えながら開発業務を行っていました。 ## 取り組みの成果 - ドキュメントが少なかった既存システムのコードから仕様等を把握し、ドキュメントを整備 - 既存メンバーからの運用保守タスクの巻き取り - プルリクエストによるコードレビューの導入、定着 - デプロイ自動化のために Capistrano を導入し、Git リポジトリを正とする運用の定着