Platform、育てる
Platform Product Engineer、プロダクトマネジメント/技術リード
Formula AIをプロダクトとして育てるポジションです。案件で得た解決策を、ほかの案件でも使えるFormula AIの共通基盤や開発手順に変えます。何を、なぜ、どの順番でつくるかを決め、上位アーキテクチャと品質基準を定め、本番の品質まで責任を持ちます。
- 想定年収
- 800万〜1,800万円
- 働き方
- 東京・新宿フルリモート勤務も可能
- 必須の経験
- Java・C#・F#・TypeScriptなどでの本番ソフトウェア開発経験と、プロダクトマネジメントまたは技術リードの経験
※ 想定年収は固定残業手当を含む金額です。必須の経験は主なものを抜粋しています。
ミッション
Formula AIを使って、顧客の業務システムを速くつくるだけでなく、安全に変更し続けられる状態を実現する。
仕事の流れ
案件の知見を、次の案件で使える仕組みに
-
01案件の課題をつかむ
FDEや顧客と、業務・既存システム・制約を整理する
-
02共通にする部分を見極める
繰り返し必要になる部分を見極め、つくる順番を決める
-
03方針と受入れ条件を決める
上位アーキテクチャ・技術選定・品質基準を決め、開発チームに依頼する
-
04深さを変えてレビューする
DBのスキーママイグレーションは SQLまで確認、開発用ポータルの見た目ならコードは読まない
-
05リリースを判断し、再発を防ぐ
品質を確かめて判断し、障害は原因を特定して共通基盤も直す
-
06複数の案件へ届ける
共通基盤のアップデートを展開し、知見を次の案件の基準にする
次の案件へ
ある1週間
仕事の種類
- 共通基盤
- 案件
- レビュー・調整
-
月曜
- 案件:案件担当者と、顧客の認証基盤との連携要件を整理
- 共通基盤:ファイルをマルウェア
スキャンする 仕組みを改善
-
火曜
- 共通基盤:アップデートを複数案件へ展開
- レビュー・調整:開発チームと展開前の検証項目を整理
-
水曜
- レビュー・調整:同僚が作成した認証基盤の変更のPRをレビュー
- 案件:顧客からの技術的な質問への回答を、案件担当者と確認
-
木曜
- 案件:案件担当のエンジニアと不具合を調査
- 共通基盤:共通基盤を修正
-
金曜
- レビュー・調整:CTOと、リリースに必要な作業を整理し、優先順位と担当を設定
- 共通基盤:アップデートを案件へ取り込み
一緒に働く人
Platform Product Engineer
CTO・経営
- 共通基盤の設計・レビュー
- 案件の優先順位
- リリース判断
- (経営へ)改善方針の説明
FDE案件担当のエンジニア
- 業務仕様
- 認証などの要件
- 案件で起きた問題の調査と復旧
開発チーム
- 実装の依頼
- 検証結果の確認
- 共通基盤の更新・業務シナリオに沿ったテストの移行
- リリースまでの作業と担当の調整
顧客窓口の社内メンバー
- 顧客の情報システム部門へ伝える構成・接続条件の整理
技術と環境
技術の層
- フロントエンド
- Svelte・TypeScript
- バックエンド
- Java・F#・.NET
- データベース
- PostgreSQL
- 開発・運用
- GitHub Actions・Terraform
- 認証・認可
- Logto(OIDC・SAML)
- 開発支援
- AIコーディングエージェント
AIを前提にした進め方
コーディングから
設計判断を
例:
重視すること
特定の
- 目的と
制約を 整理し - 技術方針と
品質基準を 定め - 成果物を
レビューしてきた 経験
働き方
- 東京・新宿のオフィス
- フルリモート勤務も可能
フレックスタイム制
コアタイム10:00〜15:00
仕事の例
01
案件ごとの要望を、共通機能に育てる
取引先から
メール・添付書類
共通にする部分
共通機能
- メール受信
- 添付ファイル保存
各案件で実装する部分
何を読み取り、どの業務へつなげるか
- 案件A
- 案件B
- 案件C
- ほかの案件
取引先からメールで届く輸出関連書類を、業務システムへ自動で取り込みたいという要望がありました。メールとファイルを受け取る部分は共通にし、書類から何を読み取り、どの業務へつなげるかは、各案件で実装できる形にしています。一つの案件の業務を丸ごと共通化するのではなく、他の案件でも繰り返し必要になる部分を見極めて、再利用できる部品に育てた例です。
02
案件を止めない品質ゲート
AI Agent
設計書・コード
品質ゲート
決定論的なスクリプト、高速
反映
くり返し実行
一回の実装で、何回も実行される
Formula AIには、AI Agentが生成した設計書やコードを実際に反映して良いかを判断する「品質ゲート」という仕組みがあります。品質を担保する仕組みですが、見方を変えると設計や開発のブロッカーにもなります。一回の実装で何回も実行されるため、高速に結果を返すことを外せない要件とし、LLMによる推論ではなく、決定論的に実行できるスクリプトとして実装しました。
面白さと大変さ
面白さ
-
01知見を、仕組みに変える
実際の案件で得た知見を、次の案件を進めやすくする仕組みに変える仕事です。何を作るべきか、どうAIの正しさを確かめるか、どう現場へ届けるかを考えたい人には、面白い仕事だと思います。
-
02正解がまだない
AI Agentが出力する成果物を評価する仕組みには、まだベストプラクティスと言える型が存在しません。評価機構と品質ゲートは実際の案件で使われ始めましたが、正直なところ、うまく機能する場合もあれば、欠陥を見落としてしまうこともあります。あるべき姿をチームで考えながら改善を続けています。
大変さ
-
01速さと共通化の両立
一つの案件を早く進めることと、複数案件で使える仕組みにすることの両立。
-
02変更がほかの案件に響く
共通基盤を変えると、別の案件にも影響します。目の前の修正に加えて、影響範囲、更新手順、運用まで考えます。
-
03レビューの深さを選ぶ
AI Agentを使って開発を行うと、人間のレビューがボトルネックになり、全てのコードを読めなくなります。とはいえ、リリースする機能に責任を持たなければならない事実は変わりません。
向いている人
- 曖昧な問題を自分で調べ、整理していくことが好きな人
- 業務とコードの間を行き来することを楽しめる人
- 得た知見を、ほかの人が使える形で残せる人
- AIの正しさをどう確かめるか、正解のない問いに向き合える人
入社時点で、すべての領域に精通している必要はありません。一方で、担当範囲が最初から区切られ、方向性がはっきり決まった環境を求める人には、向かないかもしれません。
まずは、カジュアル面談から。
選考は、お互いを知るカジュアル面談から始まります。
詳しい条件と給与の内訳は、求人票(HERP)にも掲載しています。