エンジニアがビジネスに踏み込むために共通言語として「会計」を学ぶ

#pde_talks 登壇資料

https://upsider.connpass.com/event/401501/

Transcript

1. 2026.09.08 エンジニアが ビジネスに踏み込むために 共通⾔語として「会計」を学ぶ ⼤⽯悠真 / @umaidashi18 株式会社BuySell Technologies / 在庫管理グループ / バックエンドエンジニア
2. ⼤⽯悠真 @umaidashi18 株式会社BuySell Technologies 在庫管理グループ / バックエンドエンジニア 在庫管理システム「Stock」を作っています 2024.02 内定者インターンとして参加 2025.04 新卒⼊社 2026 テックリード 学⽣時代 商業⾼校で簿記、⼤学で商学
3. バイセルの事業範囲 出典：株式会社BuySell Technologies 決算説明資料
4. 25年と26年で、仕事の質が変わった FY25 FY26 機能開発 M&A後のグループ会社への システム導⼊ → 販売の最適化 販売実績を分析し、利益が最⼤になる販路を選ぶ 販売リードタイムと利益のバランスで決める ほかに AI活⽤推進‧スキル平準化、開発⽣産性の向上 プロダクトを作る⼈から、プロダクトで事業をグロースさせる⼈へ。
5. エンジニアの関わり⽅が、変わった AIで開発コストが下がり、事業部と並⾛するような体制に変わっています。 Before 事業部が課題を⾒つける → PdM が整理する → Engineer が実装する 解くべき問題が定義されたあとから参加していた After 事業部 ＋ PdM ＋ Engineer 課題を⾒つけるところから⼀緒に。同じ⽬線で、同じ⾔葉で話しています。 実装する⼈から、何を解くかを決める⼈へ。
6. 課題発⾒から関わるなら、知るべきことが増える ドメイン知識 現場では何が起きている？ ↓ ビジネスモデル どうやって会社は収益を上げている？ ↓ 事業のレバー この部署が動かせる数字は何？ ↓ トレードオフ この数字を上げると、代わりに何が増える？ ドメイン知識だけでは⾜りないと感じています。下の3つは、事業部が使っている⾔葉です。 レバーとトレードオフが⾒えると、全体最適な施策の ROI を⾒積もれる。
7. たとえば、査定速度を 30% 上げる という企画がたったと仮定します。 買取 → 査定 → 仕分 → 商品化 → 査定速度 +30% 速くなったことも、1⽇に回れる件数が増えたことも、⾃分たちで測れます。だから報告に出ます。 「はやくなった」で、終わりでしょうか。 販売
8. 速くすると、別の⼯程に仕事が増える 事業全体で⾒ると、こういうことが起きているかもしれません。 買取 → 査定 → 仕分 → 商品化 → 販売 査定速度 +30% 訪問件数 +10% 物量 +10% 値付けの⾒直し 査定精度 −10% 速度と引き換えに、増える側と減る側が同時に出ます。どれも誰かの失敗ではありません。 良くなった数字と、増えた数字。両⽅そろって、はじめて選べる。 滞留が伸びる
9. 会計を使って事業を俯瞰できる こういう問題に、会計を使って向き合えると思います。 現場の課題 → 業務 KPI → 事業 KPI → 右の3つは、事業部と経営が毎⽇⾒ている数字です。その先は予算や経営KPIにつながります。 会計は「何を作るか」を教えてくれるものではありません。 その課題を解くと、会社のどの数字が動くのか。 それを考えるのに使えます。 売上 / 原価 販管費 → 利益‧キャッシュ
10. 査定を速くすると、増える数字と減る数字が同時に出る 具体的に当てはめてみます。 現場の課題 業務 KPI 事業 KPI 売上 / 原価 利益‧キャッシュ 販管費 査定を 速くしたい → 査定速度 +30% → 訪問件数 +10% → 査定精度 −10% 粗利が増える ⼈件費が増える → 営業利益は？ 件数が増えて粗利は増えますが、対応する⼈件費も増えます。 精度が落ちた分、相場より⾼く仕⼊れて粗利率が下がるかもしれません。 KPI は途中の数字。⾜し引きするには、増えた分と減った分の両⽅の数字が要ります。
11. 事業の o11y システムのレイテンシーやエラー率を⾒るのと、やることは同じだと思っています。 計測点を 置く → システム → 事業 遅延 失敗 追跡 レイテンシ エラー率 分散トレース 査定にかかる時間 査定精度 1点を販売まで追う ↓ ↓ ↓ 売上⾼ 原価率 粗利 → 営業利益 会計にすると さっきの例で⾜りなかったのは、この3つだと思います。会計の⾔葉に置き換えると、営業利益まで辿れます。 欲しい数字を⾔えるのは、事業部。 その数字を⽤意できるのは、エンジニアです。
12. 決めるのは事業部。だから、同じ⾔葉で話す。 改めて、役割を整理します。協⼒するとしても、できることは違います。 エンジニアができること 事業部ができること ＋ 事業を計測できる 現場の肌感がある データで確かめられる 予算を決めて、実⾏できる ↓ 会計を共通⾔語にする 売上 / 原価 / 販管費 → 営業利益 → 予算 同じ⾔葉を話すことで、同じ⽬標に向かえると思っています。事業部が向かっているのは、予算です。 同じ⾔葉になって、はじめて同じ⽬標に向かえる。
13. まとめ 1 実装する⼈から、何を解くかを決める⼈へ。事業部との関わり⽅が変わった 2 ある⼯程の KPI 改善が、別の⼯程のコストを増やす。KPI だけを追うのは限界がある 3 KPI は現場で⽬指せる途中の数字。会計なら、その先の利益まで辿れる 4 エンジニアは、事業の o11y で⼯程ごとの⽣産性とコストを数値にできる 5 決めるのは事業部。データと会計を共通⾔語に、事業をグロースさせる ビジネス構造が分かると、事業部と同じ⾔葉で施策の ROI を話せる。 はじめの⼀歩は、担当する事業がどこで利益を⽣んでいるかを、 決算資料と突き合わせて説明できること。