• 基本情報
• 職務要約
• 技術スタック
• 自己PR
• 今後やりたいこと
• 職務経歴

これまで株式会社BuySell Technologiesにて、約4年間にわたりフルスタックエンジニアとして、Google Cloud、Go、GraphQL、React を中心に、インフラ・バックエンド・フロントエンドの開発に従事。

リユース特化のOMS開発では、プロジェクトマネージャー兼テックリードとして技術選定や開発プロセスの整備を推進し、開発効率向上に貢献。PdMと協力し、ユーザー視点を重視した開発を実践。

今後は、技術戦略やプロダクト戦略にも関与し、よりレイヤーの高い意思決定に携わりたいと考えている。

「なぜやるか」を常に考え、ユーザーに価値を提供することを重視して開発を行っている。 技術が好きでエンジニアリングに携わり続けたいという思いはあるが、それ以上にユーザーの課題を解決したいという気持ちが強い。 実際に、開発業務を一時的に離れ、ユーザーインタビューや要件定義などのPdM業務に専念した期間もある。 プロダクトを推進するために必要なことは、役割にとらわれず何でも実行してきた。

チームの課題を発見し、解決するリード力を持っている。 リーダーやプロジェクトマネージャーとして、チーム全体を俯瞰し、課題を見つけ解決することに取り組んできた。 チームが抱えている優先度の高い課題に対しては、メンバーを巻き込みながら、チーム全体で解決策を考え、実行することを主導してきた。

また、チームに関する意思決定を数多く行ってきた。 意思決定の際には、目的を明確にし、判断軸とトレードオフを整理することを心掛けている。

仕様理解力の高さ、キャッチアップ力、概念整理の速さを強みとし、個人としてのアウトプット量も多い。 プロジェクトマネジメントや採用といった開発以外の業務も行いながら、以下のような成果を維持している。

事業やプロダクトの方向性を決めるような、大きな意思決定を行えるようになりたいと考えている。 視座を上げる必要があると感じており、機会があれば技術戦略やプロダクト戦略に関わる業務にも携わりたい。 そのため、規模の大きい会社よりも、ワンプロダクトの会社や規模が小さめな会社で、責任を持ってプロダクトの成長に深く関与できる環境を希望している。

より上位のレイヤーで意思決定を行うためには、技術力と引き出しの多さが必要であると考えている。 現時点では、技術の幅や深さが十分ではないと感じているため、今とは異なるドメイン領域での開発や、高難易度の課題解決に取り組むことで技術力を高めていきたい。

複数のECサイトへの出品・受注業務を一元管理するWebアプリケーションの開発。 複数のECサイトへの出品や受注管理を他社SaaSで行っていたが、パフォーマンスが低さや不具合の多さから、事業のスケールを阻害していたため、内製で開発を行うことになった。 自社だけの利用ではなく、将来的にSaaSとして外部に提供していくことも考慮して設計・実装を行った。

長期プロジェクトのため、下記のようにフェーズを分割し、それぞれのフェーズごとに記載

1. Phase2: リリース~
2. Phase1: プロジェクト再定義~リリース
3. Phase0: プロジェクト発足~プロジェクト再定義

リユース特化のOMS（Order Management System）のリリース以降のフェーズ。

プロダクトがリリースされ、ユーザーからのフィードバックを受け、新たな機能の追加や既存機能の改善を行った。 アラートの対応やチーム体制の変更など、運用フェーズに合わせてプロジェクトの進行を行った。

• プロジェクトマネジメント
  • スケジュール管理
• バックエンド
  • 技術選定
  • DB設計
  • 機能実装
• フロントエンド
  • 技術選定
  • コンポーネント設計
  • 機能実装

上場企業であるため、Jiraの運用には監査対応を考慮する必要があった。一方で、迅速かつ柔軟な開発を実現するためには、開発効率を損なわない工夫も欠かせなかった。 この課題に対して、自動化の活用やワークフローの整備を進めることで、監査要件を満たしつつ、開発のしやすさを維持する体制を構築した。 これにより、運用の効率化と開発チームの負担軽減を両立させた。

リユース特化のOMS（Order Management System）の開発のプロジェクト再定義~リリースのフェーズ。

プロジェクトの再定義が行われたため、設計の見直しや開発体制の整備を行った。 外部APIの仕様変更やメンバーの増減による開発体制の変更など、プロジェクトの進行において様々な課題が発生したが、その都度臨機応変に対応し、全てのマイルストーンを達成しながらスケジュール通りにリリースに至った。

• プロジェクトマネジメント
  • ユーザーストーリーマッピングの作成
  • スケジュール管理
• バックエンド
  • 技術選定
  • DB設計
  • 機能実装
• フロントエンド
  • 技術選定
  • コンポーネント設計
  • 機能実装

PdMと共にユーザーヒアリングや業務見学を実施し、得られた知見を活用して、よりユーザーに寄り添った開発を行った。 ユーザーストーリーマッピングや業務フロー図の作成、スコープ調整など、PdM業務の一部も担当した。 これにより、プロダクトのビジョンや仕様を深く理解し、高速かつ中長期的な視点を踏まえた設計・実装が可能となった。

チームにフロントエンドエンジニアが私のみで、私の作業時間が確保できず、フロントエンドの開発が滞ってしまうことがあった。 その際に、モブプロ・勉強会の開催や、開発体制の整備を行うことで、私以外のメンバーでもフロントエンドの開発が行えるようになった。 具体的な取り組みに関しては、下記を参照。

自分だけが頑張るのをやめて、フルスタックなチームを作る

私のチームではスクラムを導入しており、スプリントごとにスプリントゴールに向けた開発を行っていた。 しかし、想定外のタスクが発生したり、メンバーの減員があったことで、スケジュールに遅れが生じていた。 そこで、スコープの調整と開発体制の変更を行った。

スコープ調整では、PdMと協働して機能の優先度を見直しを行いながら、機能の削減や代替案の提示を行った。 機能ではなく、ユーザーが実現したい価値にフォーカスした削減案や代替案を提示することで、ユーザーとの合意をとりながらスコープを調整した。 また、理想仕様では開発に時間がかかるが、暫定仕様であれば短期間でリリースできる場合もあったため、その場合は暫定仕様で実装し、後から理想仕様に変更することも行った。

開発体制の変更においては、スクラムイベントを一時的に中断して開発時間を捻出し、各メンバーに個別のタスクを割り当てることでキャッチアップコストを削減した。 それにより、属人化やエンゲージメントの低下などの懸念があったが、それらはトレードオフとして受け入れ、 それらを行う決断をした。

これらの取り組みにより、全てのマイルストーンを達成しながら、スケジュール通りにリリースに至った。

ユーザーが自由に商品に対して項目や選択肢を定義でき、それを使った複雑かつ高速な検索が求められていた。 この要件を満たすため、商品の可変属性データはPostgreSQLでEAV（Entity-Attribute-Value）を用いて管理し、そのデータをElasticsearchに同期して検索を行う方式を採用した。

テナントによって保持する項目が異なるため、物理カラムを持つDB設計では柔軟性が足りなかった。 そのため、PostgreSQLを採用するにしても、EAV（Entity-Attribute-Value）やJSONカラムなどの方式を採用する必要があったが、どちらの場合も効率的なインデックスを作成するのが難しく、実際に検索速度の調査を行なった結果も踏まえて、RDBでは検索性能が求めるレベルに達しないと判断した。 NoSQLの検討も行ったが、Phase0でPostgreSQLを使用して実装されている箇所が多く存在し、変更が容易ではなかったため、NoSQLは採用しないこととした。

PostgreSQLでのデータの保持方法については、JSONカラムとEAVのいずれを採用するか検討した結果、EAVを採用した。 JSONカラムでは外部キー制約を設定できないのに対し、EAVは設計次第で外部キー制約を設定することが可能である。 さらに、別の機能要件やElasticsearchへの連携を考慮した結果、値を配列で保持する形式の方が実装が容易であると判断したためである。

この設計により、既存サービスと比較して、検索速度を1/10程度にすることができた。

プロダクトの性質上、外部APIとの連携が非常に多く、それらを効率的に実装する必要があった。 連携先によって、インターフェースは様々で、REST API、GraphQL、SOAPなどが混在していた。 そこで、外部APIの呼び出し部分は、OpenAPI Generatorとgenqlientを用いて自動生成することで、開発フローを統一し、開発効率を向上させた。

3年間に及ぶ新規プロダクト開発の技術選定の振り返り-OpenAPI Generator/genqlient

開発が進むにつれて、モックやテストデータのセットアップが複雑であることや、記法が統一されていないことなど、バックエンドの自動テストに関連する複数の課題が顕著になり、それにより開発効率が低下していた。 そこで、バックエンドの自動テストの整備を行い、開発効率の向上を図った。 具体的な取り組みに関しては下記を参照。

Goでテストをしやすくするためにやったこと

GoのTestifyを使って独立したサブテストを実現する

Goのジェネリクスを使って、テーブル駆動テスト(TDT)に統一性を持たせる

開発効率の向上や属人化の防止を目的として、フロントエンドの構成を整備した。 ルールを設けたり明文化することは重要だが、ルールの認知漏れや認識齟齬がどうしても発生してしまう。 そのため、自動生成ツールを整備やCIへの組み込みなど、可能な限り仕組み化・自動化を意識して整備を行った。 具体的な取り組みに関しては下記を参照。

開発効率を上げるためのモダンなフロントエンド構成

MUIをベースにしたデザインシステムの構築

graphql-eslintを使用してGraphQLの命名規則を強制するカスタムルールを作る

MUI v5とReact Hook Form（RHF） v7を用いたフォーム実装で、設計ルールが整備されておらず、複雑でメンテナンスしづらい課題があった。 これを解決するため、フォームコンポーネントを「Viewコンポーネント」と「Controllerコンポーネント」に分ける設計方針を採用した。 Viewは見た目に特化し、ControllerはRHFとViewの連携を担当するコンポーネントとして、それぞれの責務を明確にした。 また、可能な場合は非制御コンポーネントとして連携する方針を採用し、パフォーマンスの向上を図った。 これにより、フォームコンポーネントの設計が整理され、メンテナンス性と汎用性が向上した。

MUI v5 とReact Hook Form v7 を連携させる際の設計と実装例の紹介

リユース特化のOMS（Order Management System）の開発のプロジェクト発足~プロジェクト再定義のフェーズ。

プロジェクト立ち上げのフェーズのため、主に技術選定や開発環境の整備を行った。 機能の実装もいくつか行ったが、1年程開発を行ったところで、プロジェクトの見直しが行われた。 将来的なSaaS化を見据えた時に、プロダクトのビジョンが明確でなかったことや、現状の設計が適切でないことが判明し、プロジェクトの再定義を行うことになった。

• プロジェクトマネジメント
  • 要件定義
  • 詳細仕様作成
  • スケジュール管理
• バックエンド
  • 技術選定
  • CI・CD構築
  • DB設計
  • 機能実装
• フロントエンド
  • 技術選定
  • CI・CD構築
  • コンポーネント設計
  • 機能実装

バックエンド・フロントエンド両方の技術選定に携わった。 主要な技術選定の背景や振り返りについては下記を参照。

3年間に及ぶ新規プロダクト開発の技術選定の振り返り

もし今からGraphQLを採用するなら

チームリーダーとして、スクラムの導入や開発生産性向上のための取り組みを主導した。 具体的には、KPIとしてPR作成数を設定し、KPIを達成するための施策をスプリントごとに検討・実施を行った。

具体的な取り組みに関しては、下記を参照。

生産性が上がり続けるチームを作るための第一歩

インターン時代に参画していたプロジェクトでは、OpenAPIのファイルが肥大化しており、全体像の把握が困難であったりファイルを開くのに時間がかかるといった問題があった。 その反省を踏まえ、今回のプロジェクトではOpenAPIの分割を行い、それぞれのファイルを小さく保つことで、全体像の把握が容易になるように設計した。

治安のいいOpenAPIの開発環境を作る

リユース事業の出品業務における商品撮影アプリのフルリプレイスプロジェクト。

撮影が完了したものから順次出品していくという業務フローであったため、撮影効率が出品効率並びに売り上げに影響していた。そのため撮影効率向上のために業務フロー自体の見直しを行うことになったが、既存アプリが特定の業務フローのみにしか対応していない仕様であったので既存アプリのままでは業務フローの変更が行えない状況であった。 また既存アプリではパフォーマンス・保守性がともに低く、将来的なことも考えた結果、リプレイスするに至った。

3ヶ月で開発~テストまで行い、リリースに至った。 既存アプリからのリプレイスを完遂し、業務時間を20%削減することに成功した。

• バックエンド
  • 技術選定
  • CI・CD構築
  • DB設計
  • 機能実装
• iOS
  • 機能実装

小規模なサービスであったため、低コストで運用できるLambda + DynamoDBを用いたサーバーレスアーキテクチャを採用した。 デプロイフレームワークにAWS SAMを採用し、CircleCIを用いてCI・CDを構築した。

デプロイフレームワークとしてServerlessFrameworkも候補に上がった。 そのため、AWS SAMとServerlessFrameworkをそれぞれ用いて、ローカルでの開発環境の整備からデプロイまでを試行し、比較検討を行った。 その結果、主にローカルでの開発が行いやすい点を重視して、AWS SAMを採用した。

AWS SAM + OpenAPI(Swagger) + Golang でサーバーレスなAPIを構築する

AWS Step Functionsを用いて画像の生データを別のS3にコピーし、出品管理サービスのFTPサーバーへアップロードするバッチ処理を実装した。 Lambda単体の責務は小さくし、実行順序はStep Functionsで管理することで、Lambda同士を疎結合にし保守性が高くなるように設計した。

この構成にしたことで、リリース後に連携先を増やすことがあったが、その際も既存のLambdaに手を加えることなく、新規Lambdaの実装とStep Functionsの設定のみで対応できた。

新卒向け1dayサマーインターンシップの運営を担当した。 コンテンツの企画、インターン生の選考、課題の作成、当日の運営まで、全てのフェーズを一貫して手掛けた。

コンテンツには、動的項目のフォームの設計と実装を採用し、実際の業務に近い内容を選定した。 難易度は高めであったが、事前に作業リポジトリを綿密に準備し、課題の理解を助けるための資料を用意するなど、サポートを徹底した。 その結果、参加者平均で5段階中4.8という非常に高い満足度評価を得ることができ、サマーインターンシップ経由で内定に至った学生も複数名輩出することができた。

エンジニアの採用活動を担当した。 新卒採用・中途採用で、それぞれ下記のような業務を行った。

新卒採用

• サマーインターンシップの運営
• 逆求人イベントへの参加
• 面接
• アトラクト面談
• 内定者インターンのメンター

中途採用

• スカウト送付
• カジュアル面談
• 面接
• アトラクト面談

新卒エンジニア向けのオンボーディング課題が存在していたものの、社内の技術スタックが変化したにも関わらず課題が更新されていなかった。 そこで、新しい技術スタックに合わせたオンボーディング課題を企画・作成し、新卒エンジニアの育成に貢献した。

課題は、実務を行う上で必要なスキルを体系的に学べるように設計。 さらに、模範回答を用意することで、新卒エンジニアへのフィードバックプロセスを効率化し、レビュワーの負担を大幅に軽減した。 これにより、教育の質と効率を両立させる仕組みを構築した。