2025年4⽉23⽇ 1 プロダクトエンジニアのしごと 〜 受託 ✖ ⾼難度を乗り越えるOptium開発 〜 

2 ⾃⼰紹介 宇藤 恭平 / Kyohei Uto 2023年12⽉ ALGO ARTISにジョイン（プロダクトチーム） ※ 前職はまったく違う業界‧業種でした 〜 2024年7⽉ごろまでプラットフォームグループ 〜 現在までOptiumグループ GitHub: https://github.com/kyoheiu 最近はmixi2の観葉植物愛好会コミュニティにいます🌱 

⽬次 3 1. まずはOptiumの全体像 2. システムとしてのOptium 3. Optiumを⽀えるプロダクトエンジニアの役割 4. Optium開発の裏側 

ALGO ARTISが提供する、個社別にカスタマイズされた計画業務最適化ソリューション 主にアルゴリズムによる評価‧最適化と、UIでの計画閲覧‧編集を⾏います まずはOptiumの全体像 計画に必要な データをインプット 1 アルゴリズムによる 評価‧最適化 2 UIで計画を 確認‧編集 3 前段の発表の"プラットフォーム"上に作るWEBアプリケーションです 

ALGO ARTISが提供する、個社別にカスタマイズされた計画業務最適化ソリューション 主にアルゴリズムによる評価‧最適化と、UIでの計画閲覧‧編集を⾏います まずはOptiumの全体像 ● 関⻄電⼒様の燃料運⽤計画 ● ⽇本触媒様の⽣産計画 ● 東北電⼒様の配船計画 ● ⽇本製紙様の配船計画 ● 北陸電⼒様の配船計画 ● コスモ⽯油様の配船計画 ⇦ New! ● 名鉄バス様の交番‧⾏路計画 ⇦ New! そのほか、公開されていないが すでに運⽤に乗っている案件、 開発が進んでいるものが複数あります 導⼊事例 

⽬次 6 1. まずはOptiumの全体像 2. システムとしてのOptium 3. Optiumを⽀えるプロダクトエンジニアの役割 4. Optium開発の裏側 

「計画最適化ソリューション」ではありますが... システムとしてのOptium 必要なのは最適化アルゴリズム「だけ」ではない 実際には最適化アルゴリズム単体では なかなか価値のあるシステムにはなりにくい * * 実質的に最適化アルゴリズムだけでシステムを構成している ミニマルなケースも存在はしています 

最適化アルゴリズム「以外」に必要なもの（架空の⽣産計画を例に） システムとしてのOptium ● インプット処理 （前業務との接続） ● UIでの計画確認 ● ⼿動での調整 （「⼈の意思⼊れ」） ● アウトプット処理 ● etc… ※ Optiumの中でも相当  シンプルなほうのフロー図 

⽬次 9 1. まずはOptiumの全体像 2. システムとしてのOptium 3. Optiumを⽀えるプロダクトエンジニアの役割 4. Optium開発の裏側 

Optiumの構成要素 Optiumを⽀えるプロダクトエンジニアの役割 ↙ 計画業務システムに関係する各ロール ごとに関⼼や役割が異なる傾向にある （もちろん例外もあります） ● アルゴリズムエンジニアは 仕様‧制約を我が物とし ⾼難度の最適化問題を 解くことに全⼒を注ぐ ● デザイナは特にユーザとの インタラクション部分に 興味‧関⼼がある プロダクトエンジニアは全体を⾒る！ 案件ごとにチームを組成 例: プロダクトエンジニア x 1、biz x 1、 アルゴリズムエンジニア x 2、デザイナ x 1 など 

Optiumにおけるプロダクトエンジニアの責務のイメージ Optiumを⽀えるプロダクトエンジニアの役割 ユーザー リサーチ デザイナ との連携 フロント エンド （UI） データ モデリング 権限‧ アカウント 管理 顧客との交渉 リスクコントロール タスクマネジメント 要件定義 ゴールは、「使われる‧使わ れ続けるプロダクト」を作る こと そのために、いわゆる「フル サイクルエンジニア」みたい な動き⽅をすることが多い cf: Full Cycle Developers at Netflix — Operate What You Build リスク 時間 QA カスタマー サクセス 要件定義 ⇨ 開発 ⇄ FB‧QA ⇨ 運⽤ アルゴ リズムと システムの 接続 データ 処理 

⽬次 12 1. まずはOptiumの全体像 2. システムとしてのOptium 3. Optiumを⽀えるプロダクトエンジニアの役割 4. Optium開発の裏側 

いざ開発！ となっても、これがなかなか難しい... その⼼は？ Optium開発の裏側 ⾼難度なシステムを １つ１つ 作るようなもの... この難しさを どうやって 解決するか？ （開発編） 受託 ✖ フルカスタマイズ ドメインごとに共通の要件はそれなりにありつつも そもそもの業務内容や社内の組織分布などに ⼤⼩様々な違いがある 現状の業務フロー（as-is）も⼀定意識する必要がある = ⽂字通りのフルカスタマイズにならざるを得ない 計画業務⾃体の難しさ 計画最適化問題の難度が⾼い * のと同じく そもそも計画業務⾃体が⾮常に複雑で 多岐に渡る仕様‧制約を意識しながら システムを作っていく必要がある * 弊社のアルゴリズムエンジニアが解けなかったら多分誰も解けない 

答えは... Optium開発の裏側 根性 

答えは... 根性 ❌ Optium開発の裏側 

答えは... 柔軟なアドオンアーキテクチャ ✖ ⾼速な意思決定 ✖ ⾼速なデプロイ Optium開発の裏側 

例1: 複雑なUI ✔ アドオンアーキテクチャの１つ、 Frontend Addonで UIを⾼速に開発‧デプロイ 複雑な業務だからこそ、⾼速に サイクルを回して、顧客からの フィードバックを受ける必要がある 👍 UI開発の社内知⾒も蓄積されている 例：ガントチャート、巨⼤テーブル... cf: ドラッグ＆ドロップで動かす同時編集可能なガントチャート開発（React/TypeScript）   https://note.com/algoartis/n/n96805715eada Optium開発の裏側 

例2: バッチ処理も個社別実装できる ✔ アドオンアーキテクチャの１つ、Connect Addonで バッチ処理や外部データとの連携をデプロイ ⇨ 共通基盤で担ってしまうと肥⼤化を避けられない要件のいい例 ✔ ⼩さなモジュールを複数個作って個別に⾛らせている案件も 例：天候データの定期取得 配船系の計画だと、航海可能かどうかを判断するために必要 Connect Addonで定期取得‧データの変換まで⾏ってしまえる Optium開発の裏側 

例3: WASMでフロントエンドの限界を超える ✔ バックエンド処理っぽいことも WASMならパワーで解決できる まさにアドオンアーキテクチャならではの柔軟性 例：帳票出⼒（技術検証段階） 様々なデータをPDFとして出⼒する要件が出てくることがある でもそのためだけにサーバーを⽴てたくない！ ⇨ WASMで書いちゃえ Optium開発の裏側 

アドオンアーキテクチャの恩恵 ✔ アドオンとして作って載せるだけなので 原則的にプラットフォームの承認は必要ない ⾼速な意思決定と開発サイクルに⼤きく寄与 ✔ アドオン内では実装に対しての制限はほぼない 必要なのは意思決定と実⾏⼒だけ ＝ 「調べて、書く」ができれば「なんでもできる」 ✔ 使⽤者視点でプラットフォームへ気軽にFBや要望を出すこともできる プラットフォームと協⼒して解決していくようなプロセスもある = 組織としても柔軟 Optium開発の裏側 そもそもプラットフォームが提供する様々な基盤に加え これらのメリットを享受できるのがOptiumの強み！ 

責務も広く、なかなか⼤変なジョブですが... 最後に、ALGO ARTISのプロダクトエンジニア職のおもしろいところ 👍 責務が広い分、「なんでもできる」 意思決定の部分と開発を進める部分、両⽅を握れる PdMっぽいエンジニア、みたいな感じになる 👍 強めのオーナーシップを持てる 「やること」や「やりかた」を与えられるよりは ある程度⾃由に‧⾃分がいいと思った形で物事を進めるのが好み （顧客の要望はもちろん全⼒で聴きますが）なので ALGO ARTISのプロダクトエンジニアの動き⽅は合っている気がする 👍 世界最強のアルゴリズムエンジニアと⼀緒に働ける 誇張なしに最強軍団 あっちにも、こっちにも最強がいる ⼀緒に働く仲間としてこんなに⼼強い⼈たちはいない 得られる学びもとても多い 常にsyncし、相談しながらプロダクトを作っています 

No content