danimal141's resume

Appearance

danimal141's resume ​

プロフィール ​

  • ID: @danimal141
  • 氏名： Hideaki Ishii
  • 生年月日： 1986/12/04
  • 出身地： 京都府
  • 居住地： 東京都
  • 最終学歴： 京都工芸繊維大学大学院 生体分子工学専攻（2012年3月卒業）

アカウント ​

職務経歴 ​

サマリ ​

株式会社Speeeにて、不動産DX領域の4事業（約20名のエンジニア組織）と開発基盤チーム（SRE・Platform Engineering）の開発責任者を務めています。事業責任者・リードエンジニアと連携し、開発投資計画の策定と実行、エンジニア採用、組織設計・評価制度の構築などを担当しています。

自身の責任を一言でいえば「エンジニア組織の総アウトプットを、事業のアウトカムへ最大限転換する仕組みを作ること」です。そのために開発投資の優先順位づけからチーム編成、採用要件の設計まで、技術と経営の接合面にあるテーマへ幅広く関わっています。実験的な技術検証や基盤領域（AWS EKS / ArgoCD / Terraform）は今も自ら手を動かし、意思決定に手触り感を持つことを大切にしています。

現職へは中途入社し、リードエンジニアとして新規事業の立ち上げを経験しました。急成長する事業を支えるためにチーム構造やソフトウェアアーキテクチャをどう進化させるかというテーマに正面から向き合い、その過程でエンジニアリングマネージャー、そして複数事業を横断する開発責任者へと役割を広げてきました。

強みは、事業責任者やBizメンバーとエンジニアの間に立ち、コンテキストを翻訳しながら意思決定を前に進めるような動き方です。開発組織の内側に閉じず、事業戦略や投資判断の言語で対話できることが、自分のエンジニアリングマネジメントの特徴だと考えています。

株式会社Speee（2020年9月〜) ​

事業本部の共通開発基盤の開発 / EM（2024年4月〜) ​

概要 ​
  • 所属する事業本部に10以上存在するWebプロダクト群やコラム（WordPress、Kinsta）を安定運用するための基盤（主にインフラ）があり、前任者から引き継ぐ形で、その基盤全般の運用保守を担当
  • ［チーム構成］エンジニア3名（引き継ぎ前は私含めて2名 → 私のみ → 他チームから兼務で2名増員）
担当した役割 ​
  • 開発基盤グループの責任者として、各プロダクトのスケールや新規プロダクト立ち上げも含め、各プロダクトを安定運用できる基盤を運用し続けること
課題 ​

引き継ぎにあたって、以下が主な課題でした。

  • 当時、マネコン上でAWSを触れる程度のインフラ経験しかなかった私が、AWS EKSやTerraformで作られた20万行を超える基盤のコードをキャッチアップして運用できるようにすること
  • それを引き継ぎ期間が2ヶ月しかない状況で、私自身が4つの事業の開発責任者を兼務しながら実現すること
成果 ​

結果として、これまでと同水準のQCDを実現できる新体制を構築し、新たな開発投資やコストカット施策も進められています。

そこに至るプロセスは以下のとおりです。

  • 開発時間の確保
    • 事業側の開発責任はメンバーと事業責任者に協力してもらい、MTGを削るなど一時的に自分の関与度を下げる
  • 継続的な学習
    • 「毎日1時間インフラのコードリーディングを行う」と決め、2ヶ月間その習慣を継続する
    • 各事業部からの開発依頼のうち、特に自分がイメージできていないものから率先して担当する
  • 体制構築
    • 並行で社内外スカウティングを行い、メンバーを2名確保する
    • そのメンバーのオンボーディングをスムーズに行うため、自身がキャッチアップしたことや担当した機能開発はすべてドキュメントに残しながら進める

また、これまでは開発基盤専任のメンバー中心でチームを構成していたため、「各事業の最新状況がわからず、事業成果に整合する成果定義や全体最適な基盤投資の意思決定が難しい」という問題がありました。

それに対し、私は事業部のEMも兼務しており各事業の状況を理解しているため、開発基盤として「どの時間軸で何に投資すべきか」を判断する勘所が歴代の基盤メンバーより働きます。そういった背景から、現在は開発基盤チームのTech PMのような機能も兼ね、事業状況に応じた横断的な開発投資計画の策定と実行を進めています。

不動産領域のプロダクト開発 / リードエンジニア・EM（2020年10月〜) ​

概要 ​
  • 新規事業立ち上げメンバーとして、不動産領域の新規プロダクト開発を担当
    • スクラム、アジャイルに近い開発スタイル
    • プロダクトチーム構成： エンジニア3〜5名、PM、事業責任者
  • その後EMになり、別新規事業の立ち上げや既存事業のEMを兼務する役割へ
担当した役割 ​

新規事業のリードエンジニア / EMとして、以下を担当しました。

  • 技術選定、設計、実装、リリース
  • PMメンバーと協力し、プロダクト開発計画の策定、オペレーション（課題定義、アクション、振り返り）マネジメント
  • エンジニア採用
  • エンジニアメンバーの成果定義、成果支援、評価
成果 ​

複数事業に関わっていますが、本項では私が立ち上げに深く関わった新規事業について記載します。

当該事業においては「事業を早く成立させ、グロースフェーズに乗せること」を最重要事項と捉え、以下を重視しました。

  • 事業のコア価値の開発にリソースを集中させること
    • ノンコアな機能開発は既存サービスを活用し、開発コストを最小化すること
    • コアとなるデータの取りこぼしがないような設計を実現すること
  • リッチなフロントエンド開発へ対応できるような構成にすること

具体的には、以下のような意思決定を行いました。

  • 認証・認可などプロダクトにおいて必要だがコア価値ではない機能はAuth0を採用し、極力開発に時間を割かないようにする
    • サービスのスケールを想定すると、一定ユーザ数を超えるとコストが大幅に上がることは織り込んだうえで、そこまではあえてAuth0を使うという判断
  • 良い意味で枯れており社内実績も豊富なRuby on Railsを採用し、徹底的にレールを活用することでコア価値の開発へ集中できるようにする
    • 「俺が考える最高のアーキテクチャ」のようなものを極力導入しないようにした
    • これまでRailsをメインで採用してきた開発組織だったという背景もあります（組織の資産を有効活用するため）
  • サービス特性的にリッチなユーザ体験を作ることが想定されていたため、フロントエンドはRailsではなくReact / TypeScriptに寄せた

また、将来の開発速度を落とさないために、常に短期と中長期の視点を持ちました。

  • 仮説検証段階ではなるべく捨てやすい構成でテーブルやモデルを作り、一定の検証期間を経て筋が悪いと判断した機能に関連する実装はどんどん捨てていく
  • MVPの骨子ができるまでは誰よりもコードを書いて主導し、そこから徐々にチーム内での開発量は半分程度に抑える。並行してエンジニア採用（週2〜3程度の面談、面接や新卒エンジニアインターンの企画・実行）を進め、将来のリード候補や新卒エンジニアの採用・育成にリソース配分をシフトする

その結果、立ち上げから約3ヶ月でベータ版リリースという速度感で事業の検証を進行できました。

現在は後任のリードエンジニアに役割を移譲し、EMとしてエンジニアメンバーの成果支援や、レポーティングをもとに共に問題解決をする形で当該事業に携わっています。

参考資料 ​

株式会社ニューロープ（2014年2月〜2020年9月） ​

スタートアップに創業メンバー（ソフトウェアエンジニア、執行役員）、1人目社員として参画し、主にファッション領域の課題解決のための自社プロダクト開発を担当しました。

創業から3〜4年ほどはCEO、CTO、私の3名による少数チームでPMFを目指していたため、バックエンド、フロントエンド、インフラ（AWS）、iOSアプリのすべての開発に携わりました。何度かピボットを重ね、自社AI（ファッション画像認識モデル）の開発が事業上最重要だと判断したタイミングで、CTOが画像認識モデルの開発、私がプロダクト開発全般とエンジニア採用・組織づくり全般に責任を持つよう役割分担しました。

エンジニア採用では海外エンジニアを採用するという意思決定を行い、公用語の英語化から母集団形成、スカウト、面接と見極め、採用後のオンボーディング設計、1on1の導入までを主導しました。

英語学習プロセスに関しては、以下をご一読いただけると幸いです。

明確なタイムリミットがあり、結果を出せないと会社が潰れるというプレッシャー下での開発経験から、多くのことを学びました。「いくら開発者体験を磨いても、いくらきれいなソフトウェア設計にこだわっても、顧客に使われなければ意味がない」という価値観はこの環境から醸成されたと考えています。

株式会社ポケラボ（2013年9月〜2014年1月） ​

自社ゲームタイトルのチームにフロントエンドエンジニアとして参画しました。既存のガワネイティブ部分のJavaScriptパフォーマンスチューニングや新規イベント関連の実装を主に担当しました。

株式会社モンスター・ラボ（2012年4月〜2013年8月） ​

クライアント先に常駐する形で、新規プロダクトチームのフロントエンドエンジニアとして参画しました。担当はマークアップ全般とフロントエンド（JavaScript / jQuery）開発です。ちょうど各社がスマホシフトを進めている時期で、Webメインのプロダクトにおいてレスポンシブデザインで良質なユーザ体験を作ることを求められました。

ウォーターフォールに近い開発スタイルで、リリースまでに約50ページのコーディングが必要でした。そのためベトナムのオフショアチーム（フロントエンドエンジニア3〜4名 + ブリッジエンジニア1名）の力を借りました。

日本語が話せるブリッジエンジニア経由で仕様の認識を揃えつつ、各エンジニアメンバーへの技術的なフィードバックはSkypeで直接英語コミュニケーションを取りながら行いました。新卒1年目で還元できるものは時間しかないと考え、「終電で帰り、誰よりも早く出社する」ことを徹底しました（今だと若干問題になりますが）。

結果として、計画と大きなズレもなくサービスをローンチでき、常駐先のクライアントから「ここまで期日やクオリティに対して妥協なく向き合ってくれたパートナーの方は初めてだ」と感謝を伝えていただきました。

私について ​

キャリアの大半をスタートアップや新規事業立ち上げの環境で過ごしてきたため、0→1開発やフルスタック・フルサイクルでユーザストーリー単位に責任を持つ働き方が得意です。逆に、人材が豊富で専門性を強く求められるような環境（例：バックエンドチームに所属してスペシャリティを発揮する働き方）では強みを発揮しにくいかもしれません。

技術のみを追求するよりも、事業や組織にも興味があるタイプです。ビジネスサイドのメンバーや事業責任者と議論したり、チームメンバーをサポートしたり、カジュアル面談で社外の方とお話しするのも好きです。最高のチームで文化祭前夜のような空気感で骨太な事業開発、プロダクト開発に向き合える環境が理想です。

技術スタックとしてはRailsとReact.js（TypeScript）の経験がもっとも深く、次いでGo、直近ではTerraformやAIエージェント開発にも取り組んでいます。必要があれば何でも学んで身につけますし、商談に同席したり、P/Lを読んで開発投資を考えたりもします。また、ブランクはありますが、開発のコンテキストであれば英語環境下でも問題なく働けます。

スキル ​

  • Ruby / Ruby on Rails
  • TypeScript / JavaScript
  • React.js / Next.js
  • Terraform
  • Kubernetes
  • Go
  • AWS / GCP（BigQuery）/ Azure（Entra ID）
  • 生成AI / AIエージェント開発
  • エンジニア採用
  • ピープルマネジメント
  • プロジェクトマネジメント

ストレングスファインダー ​

sf1sf2

16personalities ​

16per116per2

資格 ​

  • 基本情報技術者試験（2015年11月）

アウトプット ​

所属組織テックブログ ​

個人アウトプット ​

登壇 ​

Copyright © 2025 danimal141