Ivan DolgovTech Lead / Full-Stack Engineer

複雑なWebシステムを、要件定義とアーキテクチャから本番運用まで設計し、形にします。

Webシステム · アーキテクチャ · クラウド · 企業システム

現職
テックリード — 次世代WMS株式会社フレームワークス（大和ハウスグループ）
経験年数
5年以上
拠点
東京JST (UTC+9)
言語
  • ネイティブ
  • ビジネスレベル（JLPT N1）
  • ビジネスレベル
状況
個別のコンサルティング・業務委託のご相談を承ります。東京からのリモート、または海外チームとの協働。
FIG. 1システムのライフサイクルのどこを担当してきたか、そしてそれを示すプロジェクト。

  1. 要件定義

    システムが何をすべきかをクライアントと定義し、文書化する

    P04

  2. アーキテクチャ

    技術方針を決め、リスクの高い部分を先に検証する

    P01P02

  3. 実装

    クライアント、サービス、インフラを構築する

    P02P03P04

  4. リリース

    コードレビュー、開発標準の整備、リリースの実行

    P02P03

  5. 運用

    動かし続ける：パフォーマンス、マイグレーション、本番サポート

    P03P04

主な実績

新しいプロジェクトから順に並べています。ケーススタディでは判断の理由まで、概要では公開できる役割・担当範囲・システムの事実のみを記載しています。

P01進行中

次世代WMS

次世代倉庫管理システム（WMS）の技術計画とアーキテクチャ。担当範囲はアプリケーション各層、クラウド、セキュリティ、倉庫制御システムとの連携にまたがります。

役割
テックリード
所属
株式会社フレームワークス（大和ハウスグループ）
期間
2026/09–現在 · 2か月
概要を読む

  1. A1アプリケーション

    • フロントエンド
    • バックエンド

  2. A2プラットフォーム

    • クラウド
    • セキュリティ

  3. A3連携

    • WMS/WCS連携

  4. A4技術ガバナンス

    • 技術選定
    • アーキテクチャ標準
    • 開発ガイドライン
    • アーキテクチャ決定
    • 技術PoC
技術的な責任範囲を示した図です。システムアーキテクチャそのものではなくスコープの範囲図であり、アーキテクチャは非公開です。

P02完了

AIチャットゲームプラットフォーム

コンシューマー向けAIチャットゲームプラットフォームの新規立ち上げ。20名のクロスファンクショナルなチームで、プロジェクトリード兼フルスタックエンジニアとして主導しました。

役割
プロジェクトリード / フルスタックエンジニア
所属
株式会社Ikigai
期間
2025/07–2026/05 · 11か月
体制
20名のクロスファンクショナルチーム
ケーススタディを読む

  1. L1クライアント

    • React
    • TypeScript
    • Vite
    • TanStack

  2. L2ID基盤 · 独自ドメイン

    • Keycloak

  3. L3APIと実行環境

    • API Gateway
    • Lambda
    • Go

  4. L4データ · 共通

    • PostgreSQL

  5. L5インフラのコード化

    • Terraform
リクエストの経路を上から下に示した図です。サインインは独自ドメイン上のKeycloakサーバーを経由します。これは、構想していた複数アプリケーション群の共通入口として想定されていたものです。簡略化した再構成であり、本番のアーキテクチャ図ではありません。

P03完了

梱包業界向けSaaS

梱包業界向けに本番稼働しているWebおよびモバイルのSaaSでのフルスタック開発。データ量の増加によって、すべての顧客で応答性が低下していた状況でした。

役割
フルスタックエンジニア
所属
長島梱包株式会社
期間
2024/12–2025/12 · 1年1か月
体制
約10名
ケーススタディを読む

  1. L1クライアント

    • React
    • Next.js
    • React Native
    • Expo

  2. L2API · GraphQL

    • AWS AppSync

  3. L3重い処理

    • Lambda

  4. L4データとストレージ

    • DynamoDB
    • S3

  5. L5プラットフォーム · リポジトリごと

    • AWS Amplify
1つの共通のAWSバックエンドの上に、Webとモバイルのクライアントが載る構成です。私自身の説明をもとにした再構成であり、本番のアーキテクチャ図ではありません。

P04完了

受託開発プロジェクト

5業種にわたる5件の受託プロジェクト。2か月のコーポレートサイトを一貫して主導した案件から、約40名体制の保険システムまで。Web開発、CRM、エンタープライズ領域のバックエンド開発を担当しました。

役割
ソフトウェアエンジニア / プロジェクトリード
所属
FLARETECH株式会社（旧Marvel株式会社）
期間
2023/03–2025/05 · 2年3か月
体制
プロジェクトにより5〜40名
概要を読む

  1. S1要件

    • クライアント折衝
    • 要件定義
    • ドキュメント作成

  2. S2実装

    • React
    • Next.js
    • Java/Spring
    • PHP/Laravel

  3. S3デプロイ

    • AWSへのデプロイ

  4. S4運用

    • 本番運用サポート
    • SEOと運用改善
これらのプロジェクトで私が担当した工程です。どの工程を担ったかはプロジェクトによって異なり、小規模な案件では4つすべて、最大規模の案件では中間の2つだけでした。

すべての実績経歴の全体

担当領域と根拠

印は、その責任範囲を実際に担当したプロジェクトを示します。印がないのは能力がないという意味ではなく、ここでは示していないという意味です。

担当領域P01P02P03P04
要件定義とクライアント折衝システムが何をすべきかをクライアントと定義し、文書化する
アーキテクチャと技術選定技術計画と技術選定の判断
プロジェクト推進開発チームの計画と調整
フロントエンド開発Webおよびモバイルのクライアント開発
バックエンドとAPIサーバーサイドのサービスとAPI
クラウドインフラAWS上のインフラ構築とデプロイ
認証とセキュリティ認証・認可・セキュリティをアーキテクチャの一部として扱う
システム連携WMS／WCS連携の設計
開発標準とコードレビュー開発ガイドライン、アーキテクチャ標準、コードレビュー
リリースと本番サポート変更を本番へ届け、そこで支え続ける

仕事の原則

  1. P-01

    決定は、チームが見つけられる場所に残す

    アーキテクチャの決定、ガイドライン、標準は文書に残します。一度決めたことを、レビューのたびに議論し直さずに済むからです。

    実例：アーキテクチャ標準化、開発ガイドライン、アーキテクチャ決定 — 次世代WMS。

  2. P-02

    リスクの高い選択は、小さく作って先に確かめる

    技術や連携に不確実さがあるとき、範囲を区切ったPoC（技術検証）は、本番で制約に気づくより安く済みます。

    実例：技術PoC — 次世代WMSおよび梱包業界向けSaaS。

  3. P-03

    コードレビューは、欠陥を見つけるだけでなく標準を広める場

    レビューは、外部メンバーを含めたチーム全体で、決めごとが共通の実践に変わる場所です。

    実例：コードレビューと開発標準 — AIチャットゲームプラットフォーム。レビューと外部開発者の支援 — 梱包業界向けSaaS。

  4. P-04

    要件定義もエンジニアリングの仕事

    クライアントや現場が何を必要としているかを明確にすることは、システム設計の一部であり、設計の前に終わらせる引き継ぎ作業ではありません。

    実例：要件定義とクライアント折衝 — Flaretechのクライアント案件およびフリーランス業務。