複雑な業務システムを高速でつくるため、チーム全員をつくれる人へ

電力業界は、業界の制度や業務ルールが複雑で、満たすべき条件が膨大です。ドメイン知識が一部の人の頭の中にしかないと、判断のたびにその人を待つことになり、つくる側は「なぜそうするのか」を分からないまま進みます。エンジニアやデザイナーも含めたチーム全員がドメイン知識を身につけ、仕様を密に書くことで品質を担保していく取り組みと、お客様ごとの業務をプロダクトに活かす工夫をご紹介します。

Transcript

1. 複雑な業務システムを高速でつくるため、 チーム全員をつくれる人へ 業務を知らない人が、判断できるようになるまでの話 2026.10.26 ／ 株式会社enechain 倉淵
2. 自己紹介 toCのPdMから、 ドメイン知識ゼロでエネルギー業界へ 倉淵 enechain PdM 前職 年 月〜 2025 9 転職 の toC PdM ソーシャルゲーム ・エネルギー業界 toB ライブ配信 ドメイン知識ゼロから 2
3. enechain について 電力・燃料・環境価値の取引を支える会社 日本最大級のエネルギー取引マーケットプレイス 発電A 小売A 発電B 小売B 発電C 小売C 兆円超 卸電力の累計出来高 3 ほかのマーケット 環境価値 燃料 eXstend 3
4. 01 状況 電力の業務は、制度・外部機関・お金が 複雑に絡み合っている 制度 規程・ルールが多い ＋ 外部機関 やり取りに決まりがある ＋ 時間 ＋ 締切・受付時間がある お金 間違いが損失に直結 機能を絞っても、受入条件は1stリリースだけで 約2,200件 4
5. 01 課題 AIで実装が速くなり、 「何を作るか決める」所で詰まるようになった の前 AI の後 AI 何を作るか決める › 要件・仕様 何を作るか決める › 要件・仕様 いちばん待つ所 設計 どう作るか 設計 どう作るか 実装 › › 確かめる › 確かめる いちばん待つ所 実装 › で速くなった AI 件の「何を作るか」を速く決めることが、リリースを早める 2,200 5
6. 01 課題 原因 1 業務・制度を知らないと間違える 業務・制度を知らないと、 世間の常識で要件を間違える 外部機関に出したデータが変わった → 出し直したい ✕ 世間の常識 ◦ すぐ送る。失敗なら再送 業界の常識 機関が受け付けない時間帯がある 受付が開いてから出す これは一例。こうした制約が業務・制度の至る所にある 6
7. 01 課題 原因 2 判断できるのは1人 判断が1人に集まる限り、速さは頭打ちになる 開発者 業務のエキスパート 本来の規模 私たちのチーム 数十人 少人数＋AI 領域ごとに専任 業務の領域ごとに分かれる 1人 判断できるのは、業務のエキスパート1人だけ 7
8. 02 やったこと つまり、判断できる人を増やさないと速くならない 業務を知らない私たちが、 どうやって判断できるようになったか 私たち＝PdM・エンジニア・デザイナー。全員、電力の業務は初めて 詰まる原因 やったこと 業務・制度を知らないと間違える 知識を置き、参照して、理解する 2 判断できるのは1人 聞く判断を絞り、書き残し、決め方をそろえる 1 8
9. 02 やったこと 原因 1 業務・制度を知らないと間違える AIが参照できるように、 業務知識を全部リポジトリに置いた 仕様を書く・実装する skill が自動で参照する 業務知識の文書 約14,000行 → 18 本 業務知識を参照 本 データ定義 本 → 7 本 外部機関の資料を参照 エキスパートがプロトタイプで書いた業務の理由 外部機関の一次資料 公的機関・市場のAPI仕様・規程PDF PDF 30 24 9
10. 02 やったこと 原因 1 業務・制度を知らないと間違える 仕様を書きながら、 参照して、理解して、足していく 決まったら仕様に書いて次へ 1 分からない所が出る 2 業務知識を AIに参照させる 3 次からは参照できる 5 理由ごと理解する 「なるほど、知らなかった」 決まらない 業務知識に書き足す 4 分からない時だけ エキスパートに聞く 繰り返すほど、業務知識が充実していく 10
11. 02 やったこと 原因 1 業務・制度を知らないと間違える ドメインエキスパートではない私が、 AIの前提の誤りに気づいた 判断したいこと 機関とずれた値を、提出済みとして扱ってよいか の前提 ✕ AI ◦ 最終的な数字は、事前に分かるはず 直した前提 ⇒ 最終的な数字は、機関しか知らない 答え 「提出済みとして扱ってよい」 の出力に違和感を持てるようになり、自分で直せる場面が増えた AI 11
12. 02 やったこと 原因 2 判断できるのは1人 土台はエキスパート、 無数のイレギュラーはPdMが決める ：仕様書に落として細かく定義する（書きながら業務を理解する） PdM イレギュラー系は無数に出てくる 受付時間外の変更 機関とずれた値 同じ内容の重複登録 ほか無数 … エキスパート：業務知識・プロトタイプで土台を決める 正常系は、ほぼ埋まる エキスパートが入れた変更：業務知識 ほぼすべて ／ 仕様書 0件 全部をエキスパート1人で決めるのは重い。だからPdMが担う 12
13. 02 やったこと 原因 2 判断できるのは1人 決めた理由を仕様書に残し、 後から全員が遡れるようにした 各仕様書の Discussion 欄（なぜこう決めたか） 論点 重複登録の警告 なぜこう決めたかを、 全員が後から遡れる 決定と経緯 警告のみ、登録は止めない でエキスパートと合意 Slack 人の判断を、 チームで共有できる 1 理由を忘れても、 後から思い出せる が作る仕様・ プロトタイプも向上 AI 例：9月末に残した行を翌週AIが参照し、聞かずに1分で決まった 13
14. 02 やったこと 原因 2 判断できるのは1人 業務が分かるようになって、 決め方をそろえられた が 項目をすべて参照する AI 16 業務の答え 業務知識の文書 約14,000行 外部機関の一次資料 PDF 30本・データ定義24本 動くプロトタイプの画面 131画面 業務モデル 概念と関係の定義 決めたこと 決めた理由と経緯 約1,800行 設計の決定記録 約200本 リリース範囲 入れる範囲の定義 そろえ方・書き方 用語集 310語 横断ルール 23項目 例：確定値は必ず守る 鉄則 絶対のルール4つ UI部品パターン 45種・文言の書き方 デザインの画面 141画面 ひな形・レビュー観点 2種・10観点 全部を 参照して 非機能の基準 → 仕様書と画面の対応表 仕様書 （正本） 何を作るかが 1か所で決まる 英語表記のガイド 14
15. 03 明日から 聞いた答えを書き残すほど、 判断できる人が増える 業務を知らなくても、書かれた知識を参照すれば判断できる STEP 1 並べる 人に聞いた判断を 1週間分書き出す → STEP 2 分ける → 書いてあれば決まるものと その人しか知らないものに STEP 3 書き残す 聞いた答えを AIが参照できる場所に書く チーム全員を、つくれる人へ 15
16. ありがとうございました 株式会社enechain 倉淵 16