はじめに
Rehab for JAPANでCTOを務めている@rkyuragiです。
今回は、タイトルにあるように、エンジニアと事業、エンジニアとビジネスのつながりについて、財務諸表のB/Sを使って私が考えていることを共有していきます。
考えるきっかけとなったのは、ビジョナルの取締役CTOである竹内さんのこの記事です。 PdMはP/Lに準ずる指標に責任を持ち、エンジニアはPdMからの要求に責任を持ってB/Sを構築していくという考えが腹落ちしました。
この考えを参考に、エンジニアリングとB/Sについてより深掘ることで、さらに何か見えてこないかと思い今回独自の考えとして、「エンジニアリングとビジネスをつなげる、エンジニアリング視点のB/S」をまとめてみました。
背景
最近、エンジニアと事業に関する注目された記事として、「エンジニアは事業を理解すべきか？」がありますし、少し前には、「エンジニアとビジネスの距離感の難しさ」や、「商売としてのソフトウエア開発、そのコード1行がいくら稼ぐのか」といった記事もありました。
私の考えとしては、利益を追求する企業や組織に属するエンジニアは、ビジネス/事業のことを理解していくことが重要だと考えています。
自社の事業、売上がどのように生まれるのか？利益を生むためにはどうすればいいのか？を理解し、ビジネスの目標を達成するためにエンジニアとしてエンジニアリング力をどう活かすか、といった視点は欠かせません。
加えて、エンジニアはいつも足りません。その限られたリソースの中で成果を最大化していくためにも、ビジネスに貢献するための解くべきイシューに注力すべきです。
とは言え、逆算で考えるのはかなり難しいので、まずは、自分の目の前の仕事、チケットがビジネスの何に繋がっているのか？繋がっていくのか？を考えながらエンジニアリングしていくといいかと思います。
ちなみに、B/S(貸借対照表)とは?
ChatGPTの回答
貸借対照表（バランスシート）は、会社の財務状況をひと目で把握できる表です。
資産（左側）：会社が持っているもの（例：現金、在庫、設備など）。
負債（右側の一部）：会社が借りているお金や返済すべき義務（例：借入金、未払い金など）。
純資産（右側の一部）：資産から負債を差し引いた残り。いわば「会社の持ち分」や「自己資本」。
イメージ
「資産＝負債＋純資産」という構造で成り立っており、会社がどうやって資産を調達し、どのように使っているかがわかる仕組みです。
たとえるなら
家計簿で言う「家にあるお金やモノ（資産）」と「借金やローン（負債）」「手元に残るお金（純資産）」をまとめたものだと考えるとイメージしやすいです。
本記事のターゲット
- 営利企業に属しているがビジネスと距離があると感じているエンジニア
- もっと自身の市場価値を上げたいエンジニア
- エンジニアリング力をビジネスに活かしたいエンジニア
エンジニアリングとB/Sについて
財務諸表のB/Sは以下の構成で成り立っています。
- 資産の部
- 流動資産 / 固定資産
- 負債の部
- 流動負債 / 固定負債
- 純資産の部
これをエンジニアリング視点で見た場合、私は以下のようになると考えています。
- 資産の部
-
流動資産: 顧客(社会)への価値提供ができ利益が生まれている機能/プロダクト
- 価値提供、利益創出まで早い機能、プロダクト
-
固定資産: 顧客(社会)への価値提供が遠く利益が生まれにくい機能/プロダクト
- 価値提供、利益創出に時間がかかる(もしくは使われていない)機能、プロダクト
-
流動資産: 顧客(社会)への価値提供ができ利益が生まれている機能/プロダクト
- 負債の部
- 流動負債: 顧客/事業に悪影響を及ぼしている機能/プロダクト
- 固定負債: 開発体験に悪影響を及ぼしている機能/プロダクト
- 純資産の部
- 返済の必要がない機能/プロダクト
上記を図で示すと以下のようになります。
エンジニアリングとB/S
エンジニアが注目すべき負債とは？
負債の部の流動負債、固定負債について、もう少し詳しく見ていきます。
流動負債
流動負債は、顧客/事業に悪影響を及ぼしている機能/プロダクトです。
ここでいう悪影響というのは、顧客/事業に実害が出ていて、なおかつ、すぐに対応が必要な機能/プロダクトです。
例として以下のようなものが考えられます。
- 緊急度高いインシデントが発生する機能
- クレームにつながる機能(CSの負担が増える)
- 表示が遅い画面 / 使いづらい機能 etc.
- お金の力でなんとか保てているシステムアーキテクチャ
- MySQL/ライブラリのEOLによるバージョンアップが必須
- バージョンアップしないとサポート費用が追加でかかる。（最近の話題だと、AWSのAurora MySQL2(MySQL 5.7互換)の延長サポート）
固定負債
固定負債は、開発体験に悪影響を及ぼしている機能/プロダクトです。
この悪影響というのは、新機能開発や既存機能の改善のアジリティに支障をきたしている機能/プロダクトです。
例として以下のようなものが考えられます。
- 機能追加しにくい設計、コード
- 保守性の低いコード（テストコード不足）
- 使われていない機能のメンテナンス
- 最新の情報が更新されていない仕様書
B/S観点でエンジニアがやるべきこと
財務諸表において理想的なB/Sとは、下図にあるように、資産の部では流動資産が多く、負債の部では、負債が少ないことが重要です。
理想的なB/S
理想的なB/Sが上記である場合、エンジニアリング視点のB/Sでエンジニアがやるべきことは何か？
それは以下になります。
- 資産を増やす
- 流動資産を増やす
- 負債を減らす
- 1~3を効率化する
エンジニアリングとB/S
1. 資産を増やす
まずはなんといっても、資産を生み出し、増やす必要があります。
資産を増やすには、新たなプロダクトを開発してリリースすることや、既存のプロダクトに新機能を追加することが該当します。
資産を生み出す際に、できるだけ利益創出の早い資産(流動資産)を、できるだけ負債が少ない状態（理想的なB/Sの形）で、できるだけ早く大きく産み出すことができるとBestです。
また、あえていうと、利益創出の可能性があるのはリリースしたプロダクト、機能であり、リリースしていなければ資産価値は0に等しいと言えます。
2. 流動資産を増やす
顧客に使われない機能やプロダクトは休眠資産であり、時間経過によってただの負債になっていきます。
使われていない機能の原因を分析して使われる機能にするために、データドリブンな開発・改善と検証のサイクルを回していきます。（ユーザの行動分析やA/Bテスト等を駆使する等）
機能を改善しても活用度が改善されない/機能改善が困難である場合は、負債になるだけなので勇気ある削除が必要です。
3. 負債を減らす
借金の返済に追われて、本来やりたいことがやれないような自転車操業にならないために、負債を減らしていく必要があります。
本来エンジニアがやるべき、資産を増やすための活動を継続的に行うために、戦略的に負債を減らしていくことが重要です。
技術負債を解消するのはこのためです。
4. 1~3を効率化する
上述した「資産を増やす」、「流動資産を増やす」、「負債を減らす」は資産を直接変動させるので、直接的開発生産と私は呼んでいます。
一方で、これらを効率化するための活動は、間接的開発生産と私は呼んでいます。
間接的開発生産には、阻害係数を下げるための活動と、シナジー係数を上げるための活動があります。
（阻害係数とシナジー係数は、私が勝手に作った開発生産に係る指標ですので、一般用語ではないです。）
阻害係数とシナジー係数とは？
-
阻害係数: 生産を阻害する数値や指標のこと
- 技術的要因
- 技術負債、トイル、品質低下、セキュアではない環境、etc.
- 人的要因
- 心理的安全性の低さ、コミュニケーションロス、非効率な開発プロセス、etc.
- 技術的要因
-
シナジー係数: 二つ以上の要素が組み合わさることで、それぞれの要素が単独で行動する場合に比べて、全体としてより大きな効果や価値が生まれることを示す数値や指標のこと
- 自己組織化、組織、チームの効力感、etc.
この阻害係数とシナジー係数を用いることで、開発チームの生産力の式を以下のように表すことができます。
開発は、団体戦ではなくチームで挑むので、個々の生産力を足し合わせるのではなく、個々の生産力の掛け算であると考えると、チームの生産力がどのように変動するかがわかりやすくなります。
開発チームの生産力の式
そして、上述した開発チームの生産力の式とB/Sを含めたエンジニアリング全体の関係図は以下のようになります。
B/Sの負債が阻害係数に影響していることがわかります。
エンジニアリング全体の関係図
まとめ
エンジニアリングとB/Sをベースに、エンジニアとビジネスのつながりについて、私が考えていることをまとめてみました。
B/S観点でみることで、普段のタスクやチケットがどのようにビジネスに繋がっているのか？が見えてくる一助になれば幸いです。
Rehabのエンジニア組織では、インパクトエンジニアとして社会やビジネスにインパクトを生み出すことを、エンジニア組織の方向性として定めています。
私自身としても、エンジニアリング力をどのように事業や社会課題に活かしていくかを常に考え、強いインパクトエンジニアになっていけるよう精進していきます。
ちなみに、インパクトエンジニアについては、こちらの記事を見ていただけると幸いです。
今後の課題
今回はあくまでも考え方でしかないので、
これから定量的にエンジニアリングとB/Sを結びつけるためにも以下の課題に取り組んでいきたいと思います。
- 資産(負債含む)をどのように計測するか？
- 直接的/間接的開発生産力の式をどのように計測するか？
- 阻害係数、シナジー係数をどのように計測するか？
- 開発生産につながるエンジニアの日々の行動量を計測するためにはどの指標が適切か？
Discussion