Platform、育てる

Platform Product Engineer、プロダクトマネジメント/技術リード

Formula AIをプロダクトとして育てるポジションです。案件で得た解決策を、ほかの案件でも使えるFormula AIの共通基盤や開発手順に変えます。何を、なぜ、どの順番でつくるかを決め、上位アーキテクチャと品質基準を定め、本番の品質まで責任を持ちます。

想定年収
800万〜1,800万円
働き方
東京・新宿フルリモート勤務も可能
必須の経験
Java・C#・F#・TypeScriptなどでの本番ソフトウェア開発経験と、プロダクトマネジメントまたは技術リードの経験

※ 想定年収は固定残業手当を含む金額です。必須の経験は主なものを抜粋しています。

ミッション

Formula AIを使って、顧客の業務システムを速くつくるだけでなく、安全に変更し続けられる状態を実現する。

仕事の流れ

案件の知見を、次の案件で使える仕組みに

  1. 01案件の課題をつかむ

    FDEや顧客と、業務・既存システム・制約を整理する

  2. 02共通にする部分を見極める

    繰り返し必要になる部分を見極め、つくる順番を決める

  3. 03方針と受入れ条件を決める

    上位アーキテクチャ・技術選定・品質基準を決め、開発チームに依頼する

  4. 04深さを変えてレビューする

    DBのスキーママイグレーションは SQLまで確認、開発用ポータルの見た目ならコードは読まない

  5. 05リリースを判断し、再発を防ぐ

    品質を確かめて判断し、障害は原因を特定して共通基盤も直す

  6. 06複数の案件へ届ける

    共通基盤のアップデートを展開し、知見を次の案件の基準にする

次の案件へ

※ 案件の段階や状況によって、進み方は変わります。

ある1週間

仕事の種類

  • 共通基盤
  • 案件
  • レビュー・調整
  1. 月曜

    • 案件:案件担当者と、顧客の認証基盤との連携要件を整理
    • 共通基盤:ファイルをマルウェアスキャンする仕組みを改善
  2. 火曜

    • 共通基盤:アップデートを複数案件へ展開
    • レビュー・調整:開発チームと展開前の検証項目を整理
  3. 水曜

    • レビュー・調整:同僚が作成した認証基盤の変更のPRをレビュー
    • 案件:顧客からの技術的な質問への回答を、案件担当者と確認
  4. 木曜

    • 案件:案件担当のエンジニアと不具合を調査
    • 共通基盤:共通基盤を修正
  5. 金曜

    • レビュー・調整:CTOと、リリースに必要な作業を整理し、優先順位と担当を設定
    • 共通基盤:アップデートを案件へ取り込み
このポジションの、ある1週間の例です。実装は主に開発チームが担いますが、得意領域によっては、共通基盤の改善や修正に自ら手を動かすこともあります。中身は、案件の段階によって変わります。

一緒に働く人

Platform Product Engineer

CTO・経営

  • 共通基盤の設計・レビュー
  • 案件の優先順位
  • リリース判断
  • (経営へ)改善方針の説明

FDE案件担当のエンジニア

  • 業務仕様
  • 認証などの要件
  • 案件で起きた問題の調査と復旧

開発チーム

  • 実装の依頼
  • 検証結果の確認
  • 共通基盤の更新・業務シナリオに沿ったテストの移行
  • リリースまでの作業と担当の調整

顧客窓口の社内メンバー

  • 顧客の情報システム部門へ伝える構成・接続条件の整理

技術と環境

技術の層

フロントエンド
Svelte・TypeScript
バックエンド
Java・F#・.NET
データベース
PostgreSQL
開発・運用
GitHub Actions・Terraform
認証・認可
Logto(OIDC・SAML)
開発支援
AIコーディングエージェント
技術環境は顧客要件とプロダクトの成長に応じて見直します。

AIを前提にした進め方

コーディングから日々のルーティンワークまで、AIを使います。

設計判断をAIに任せる方法も考えています。

例:業務アプリのトランザクション境界が適切に引かれているかを調べるSkill(AIに渡す作業手順)づくり

重視すること

特定の技術の経験年数よりも、

  1. 目的と制約を整理し
  2. 技術方針と品質基準を定め
  3. 成果物をレビューしてきた経験

働き方

  • 東京・新宿のオフィス
  • フルリモート勤務も可能

フレックスタイム制

コアタイム10:00〜15:00

仕事の例

01

案件ごとの要望を、共通機能に育てる

取引先から

メール・添付書類

共通にする部分

共通機能

  • メール受信
  • 添付ファイル保存

各案件で実装する部分

何を読み取り、どの業務へつなげるか

  • 案件A
  • 案件B
  • 案件C
  • ほかの案件

取引先からメールで届く輸出関連書類を、業務システムへ自動で取り込みたいという要望がありました。メールとファイルを受け取る部分は共通にし、書類から何を読み取り、どの業務へつなげるかは、各案件で実装できる形にしています。一つの案件の業務を丸ごと共通化するのではなく、他の案件でも繰り返し必要になる部分を見極めて、再利用できる部品に育てた例です。

02

案件を止めない品質ゲート

AI Agent

設計書・コード

品質ゲート

決定論的なスクリプト、高速

反映

くり返し実行

一回の実装で、何回も実行される

Formula AIには、AI Agentが生成した設計書やコードを実際に反映して良いかを判断する「品質ゲート」という仕組みがあります。品質を担保する仕組みですが、見方を変えると設計や開発のブロッカーにもなります。一回の実装で何回も実行されるため、高速に結果を返すことを外せない要件とし、LLMによる推論ではなく、決定論的に実行できるスクリプトとして実装しました。

面白さと大変さ

面白さ

  1. 01知見を、仕組みに変える

    実際の案件で得た知見を、次の案件を進めやすくする仕組みに変える仕事です。何を作るべきか、どうAIの正しさを確かめるか、どう現場へ届けるかを考えたい人には、面白い仕事だと思います。

  2. 02正解がまだない

    AI Agentが出力する成果物を評価する仕組みには、まだベストプラクティスと言える型が存在しません。評価機構と品質ゲートは実際の案件で使われ始めましたが、正直なところ、うまく機能する場合もあれば、欠陥を見落としてしまうこともあります。あるべき姿をチームで考えながら改善を続けています。

大変さ

  1. 01速さと共通化の両立

    一つの案件を早く進めることと、複数案件で使える仕組みにすることの両立。

  2. 02変更がほかの案件に響く

    共通基盤を変えると、別の案件にも影響します。目の前の修正に加えて、影響範囲、更新手順、運用まで考えます。

  3. 03レビューの深さを選ぶ

    AI Agentを使って開発を行うと、人間のレビューがボトルネックになり、全てのコードを読めなくなります。とはいえ、リリースする機能に責任を持たなければならない事実は変わりません。

向いている人

  • 曖昧な問題を自分で調べ、整理していくことが好きな人
  • 業務とコードの間を行き来することを楽しめる人
  • 得た知見を、ほかの人が使える形で残せる人
  • AIの正しさをどう確かめるか、正解のない問いに向き合える人

入社時点で、すべての領域に精通している必要はありません。一方で、担当範囲が最初から区切られ、方向性がはっきり決まった環境を求める人には、向かないかもしれません。

まずは、カジュアル面談から。

選考は、お互いを知るカジュアル面談から始まります。
詳しい条件と給与の内訳は、求人票(HERP)にも掲載しています。