TECHLEAD& PM

SINCE 2012 — YOSUKE AMINO

他社のHTMLを書き換えるサイト最適化基盤の実装から始まり、いまは業務システムの技術統括を担当しています。数万人が使うシステムのフロントエンドのリードや、プロジェクトマネジメントの兼務も経験してきました。

実装者からリードへ、そしてプロジェクト全体の統括へ。ひとつの会社の中で役割を変えながら、扱う規模を広げてきました。

2012 現職に入社
5 掲載プロジェクト
100+ 品質基盤を展開したプロジェクト
24 最大チーム人数

担当期間とキャリアの変遷

2012 — 2015

エンジニア

プロキシ型サイト変換基盤の案件に新規開発から参画。HTML / JavaScript / CSS / XPath による実装を担当。

2016 — 2021

リードエンジニア

技術が製品側で確定した環境で、メンバー教育と進行管理を担当。6年間で30件以上の最適化プロジェクトに関わり、常時3〜4件を並行、最大5名をリードした。

2022 — NOW

テクニカルリーダー

スクラッチ開発へ移行し技術選定の裁量を持つ。案件規模に応じてPM兼務と技術専念を使い分けている。

プロジェクト

大手エンタメ・チケット販売事業者

スマートフォン向け
サイト構築

2012 – NOW / ENGINEER → LEAD

日本初のオンラインチケット販売サービスのスマートフォン向けサイトを担当。自社のプロキシ型変換基盤を用い、既存のPC向けサイトに手を加えることなくスマートフォン最適化を実現しました。販売開始時に負荷が瞬間集中する高トラフィック環境で、新規開発から14年以上、追加開発と保守運用を継続しています。

2,200万サービス会員数
8,500万年間発券枚数
14年担当継続
大手小売グループ

グループ横断
ECサイト改善

2017.12 – 2022.09 / LEAD ENGINEER

複数の事業会社を擁する大手小売グループにおいて、グループ横断でのECサイト改善を担当しました。統合ポータル・総合通販・食品宅配・百貨店・ベビー/マタニティ専門店という、業態の異なる5サイトが対象です。自社のクライアントサイド変換基盤を用い、企画立案から施策実施までを担い、いずれのサイトにも手を加えることなく外側から改善施策を積み上げました。

5対象サイト(5業態)
100+実施した改善施策
5リードした人数
大手コンビニエンスストアチェーン

棚割りシステム開発

2022.04 – 2024.07 / FE TECH LEAD

全国2万店舗の店舗スタッフと本部担当者が使う棚割り業務システム。画面数を絞った構成のため、限られた画面をいかに正確かつ効率的に使えるかが設計の要点でした。フロントエンド領域の技術選定を担当し、国をまたぐ分散チームをリードしました。

2万対象店舗
4万利用ユーザー
20画面数
不動産事業者

物件調査・契約書作成
Webシステム

2024.04 – 2025.09 / PM + TECH LEAD

紙と対面で行われていた物件調査記録と契約書作成業務のWeb化。デザイナー・ディレクター・営業を含む職種横断チームを統括し、開発フェーズに応じて要員数を調整しました。進行管理とQCDはプロジェクトリーダーへ委譲し、技術選定と全体方針の決定に注力しています。

87画面数
300想定同時ログイン
12チーム最大人数
中堅証券会社

金融アドバイザー向け
取引仲介システム

2024.10 – NOW / TECHNICAL LEAD

金融アドバイザーが顧客の証券取引仲介業務を行う業務システム。プロジェクトリーダー3名がそれぞれエンジニアを抱える縦割り体制に対し、ライン横断で技術を統括しています。直接の指揮系統にないエンジニアへ技術的な影響力を及ぼす役割で、扱う課題は特定領域ではなく全方位にわたります。

150画面数
1,000想定利用者
24チーム人数
CASE STUDY 01

エンドユーザー起点の
障害検知からの脱却

  1. PROBLEM

    変換対象は自社で制御できない他社サイトのHTML。元サイト側の構造変更で要素抽出が失敗すると表示崩れが起きますが、例外を伴わないため気づきにくく、検知経路はクライアントまたはエンドユーザーからの指摘のみでした。発覚まで数日を要していました。

    発生頻度は1案件あたり月1〜2回。月額課金制で契約案件数が増加傾向にあり、案件数に比例して緊急対応の総量が増え続ける構造にありました。

  2. APPROACH

    リードエンジニアとして裁量を得たことを機に、まず個人でSeleniumによる自動検知を実装。動作するものを用意した上で社内提案し、承認を経て自社サービスのオプションとして提供を開始しました。あわせてクライアントおよび元サイト運営側とリリーススケジュールを共有する連携体制を構築しています。

  3. OUTCOME

    発覚までの時間は数日から最大24時間へ短縮。発生自体の抑止は連携体制の側で対応し、技術による早期検知と体制による事前予防の二層構成としました。数十名規模のメンバーへ導入手順とテストケース作成方法を伝授し、累計100件以上のプロジェクトに採用されました。導入を希望した案件へ有償で提供し(現在は終了)、品質保証の手法として定着しました。運用はその後、後任へ引き継いでいます。

CASE STUDY 02

国をまたぐ分散チームでの開発リード

  1. PROBLEM

    棚割りシステムのフロントエンド開発を、自社のウクライナ現地法人のメンバー2名と、日本在住の外国籍メンバー1名を含む4名体制でリードしました。開発は1ヶ月ごとに実装する機能を定義して進めるアジャイル型で、仕様の受け渡しは最初の一度ではなく毎月発生します。拠点の間には時差があり、言語も異なります。仕様の認識のずれは、店舗スタッフが毎日使う画面の品質にそのまま跳ね返ります。

  2. APPROACH

    日本の夕方とウクライナの朝が重なる時間帯に日次ミーティングを置き、時差のある体制での同期点を確保しました。伝達手段は、内容の重要度で使い分けています。

    手段使う場面
    正式通訳(現地法人の日本人スタッフ)仕様など、認識のずれが品質に直結する内容
    日常翻訳ツールを介したテキスト通訳を挟むと速度が落ちる細かなやり取り
    補完図・チャート言語に依存しない伝達
  3. OUTCOME

    期間中、現地メンバーが拠点移動のため3ヶ月間離脱しましたが、日本側メンバーへの応援要請で体制を組み直し、1ヶ月ごとの開発サイクルを維持したまま全20画面を予定どおりリリースしました。言葉の壁をその都度しのぐのではなく、伝える内容に応じて手段を先に決めておく。この設計で、国をまたぐ体制を2年4ヶ月にわたって回しました。

使用技術の変遷

サーバー間の通信の変換から始まり、Webサイトをサーバー側とブラウザ側の2つの方法で変換する基盤を経て、2022年からはスクラッチ開発に移りました。スクラッチ開発では、担当範囲をフロントエンドからバックエンドへ広げています。

開発手法:1ヶ月のサイクルで実装する機能を定義して進めるアジャイル開発を経験しています。

時期方式技術
2012 以前サーバー間の通信を変換(ゲートウェイ)前職Perl
2012 – 現在サーバー側で変換(プロキシ型)チケット販売サイトSmartConvert / HTML / CSS / JavaScript / XPath
2016 – 2020品質保証の自動化最適化プロジェクト全体(現在は後任に引き継ぎ済み)Selenium
2017 – 2022ブラウザ側で変換(JavaScript型)小売グループEC改善flamingo / HTML / CSS / JavaScript / XPath
2022 – 現在スクラッチ開発棚割り・不動産・証券TypeScript / React / Next.js / Node.js / AWS

担当範囲の推移(スクラッチ開発)

案件担当範囲
棚割りシステムフロントエンド(インフラは専任者)
不動産業務システムフロントエンド(PMとして全体を統括)
証券取引仲介システムフロントエンド → 現在はバックエンドもNode.js / AWS(Cognito・ECR・EC2・App Runner・Route 53・ALB)
ABOUT

網野 洋佑

YOSUKE AMINO

Webエンジニア。新卒で入社したソフトウェア会社で、サーバーごとに異なる独自のプロトコルを変換して通信させるゲートウェイを2年半開発したのち、2012年に受託開発企業の i3DESIGN に入社しました。

i3DESIGN での最初の10年は、他社のWebサイトに手を加えずに外側から最適化する仕事でした。前職のゲートウェイも含め、既存のシステムの間や外側に立ち、壊さずに変換してつなぐことが、私のキャリアの出発点です。2022年からはスクラッチ開発に移り、技術選定を担う立場で、数万人規模のものを含む業務システムの開発に関わっています。小売の分野では、ECサイトと店舗の棚割り業務の両方を経験しました。

一般には技術を深めてからマネジメントへ進むと言われますが、私の順序は逆でした。技術が製品側で決まっている環境で、先に人と進行をリードする経験を積み、その後に技術選定の裁量が加わりました。決められた制約の中で人を動かして成果を出すことが、私の仕事の土台です。

課題を見つけたら、まず自分で動くものを作ってから組織に提案する。伝わりにくい相手には、伝える手段のほうを設計する。すべてを自分で抱えず、任せられるところは任せる。2つのケーススタディは、この進め方から生まれました。

CONTACT

面談のご相談や、掲載内容の詳しいお話はメールでご連絡ください。

contact@yosukeamino.com