見出し画像
Photo by take_kuroki

コードベースとエンジニア組織の会計的評価

のみもの@ミラティブ

CTOあるいはエンジニアのアウトプットをどう捉えるかという深淵なる問いを考える。

「エンジニアの売上あるいは利益への貢献をどのように評価すべきか」。この問いに対する一般的な解はないと思う。シードラウンドのスタートアップを評価するときに売上を最重要指標に置くことはおそらくないだろう。プロダクトの特性やフェーズによって、達成すべきあるいは分解された重要なKPIは異なる。これと同様にそのプロダクトにおいて、エンジニアがどのような立ち位置となるかはそのプロダクトの特性やフェーズに大きく左右されると考えるのが妥当だ。

とはいえ、なにか簡易的な指標があると会計的に理解しやすい。シンプルに売上を分解した要素を考えれば良いのではないか。

何らかの数字があれば次の問いに回答できるかもしれない

昔より開発速度落ちてない？

誰か

言い換えると一人あたりの生産性が落ちていると言えるが、直感的には次が理由になると考えられる。

  • 昔よりも一人あたりのコードの量と複雑さが増している

  • 昔よりも一人あたりのコミュニケーションの量と複雑さが増している

後者については以前考えた。

今日は前者の視点で考える。特に結論はないし、また特に先行研究は調べていない。

トップラインの分解

コードの会計的生産性

売上を次のように分解する。

$$
売上 = \cfrac{売上}{コード量} \times \cfrac{コード量}{エンジニア人数} \times エンジニア人数 
$$

売上でなくても良い。プロダクトや組織によって適当なものを使えば良いと思う。

売上をコード量で割ったものは、作成されたコードベースがどれだけ売上に寄与しているかを表す。これが高ければ現在の生産性が高いことが示唆される。

一方、コード量をエンジニア人数で割ったものは、エンジニア一人あたりのコードベースの取り扱い難易度を表す。これが低ければ未来の生産性が高いことが示唆される。

ここでは技術的負債は考察の対象にしていないことに注意してほしい。技術的負債はないものとして扱っている。そうではなく、プロダクトの機能を追加したり改修したりするとき、技術的負債が増えなくても生産性は低下するということを説明している。

コードの量

ソフトウェアの規模をコードの量で近似することは無理があると思うが、ここでは外部からみて会計可能であることを重視する。実際、金融商品はだいたいこの粒度で検討される。

コードの量はLOCで測れば良い。

ツールとしてはclocが便利だ。一応言及すると、LOCは言語やアーキテクチャによって大きく左右されるため、その絶対値にはほとんど意味がない。

同じ言語でも4倍くらい差がつく例（C#）

int Add(int a, int b)
{
    return  a + b;
}

ラムダ式を使えば

int Add(int a, int b) => a + b;

コードは読みやすいことが重要で読みやすさは意図がわかることだから、行数そのものはコードの品質、すなわちエンジニアの生産性と必ずしも関係がない。

この意味でLOCはWebサイトのPV数くらいの意味合いで考えれば良いと思う（本質的な意味はないが目安としてはそれなりに使えることがあるし、とりあえず使いやすい）。

エンジニアの人数

エンジニアのアウトプットが新規のコードを書く量で表されるなら、これを支配するのは既存のコードの量と複雑さである。コードは書くよりも読む方が多い、だから読む方がボトルネックになる。コードはまっさらな状態から新しく書くのが最も簡単で、逆にすでに大規模なコードベースがある状態でこれを修正したり、新しいものを加えるのが最も難しい。

コードの量をエンジニアの人数で割った数がエンジニア一人がカバーするコード量の下限になる。上限ではないことに注意したい。エンジニアごとにプロダクトが完全に独立していない限り、実際にはもっと多くなる。

量を人数で割るという最も荒っぽい方法を取っているが、ないよりましくらいの気持ちで考えているので許してほしい。

また、売上をエンジニアの人数で割れば

$$
\cfrac{売上}{エンジニア人数} = \cfrac{売上}{コード量} \times \cfrac{コード量}{エンジニア人数} 
$$

エンジニア一人あたりの売上という最も原始的な指標が導かれる。

ボトムラインの分解

コードの会計的費用

会計的には、サーバ費用（通信費）をその利用者数によって分解することが多いと思う。荒っぽく言って、サービスの利用者（≒顧客）が増えると

  • 通信が増える

  • CPUの使用率が増える

  • レコードが増える

というわけでサーバ費用が上がる。そこで、利用者あたりのサーバ費用（利用者あたりの単価）を算出したくなる。これに先のコードの概念を加えると

$$
サーバ費用 = \cfrac{サーバ費用}{利用者数}  \times \cfrac{利用者数}{コード量}  \times \cfrac{コード量}{エンジニア人数} \times エンジニア人数
$$

利用者数を消した場合は

$$
サーバ費用 = \cfrac{サーバ費用}{コード量}  \times \cfrac{コード量}{エンジニア人数} \times エンジニア人数
$$

こんな形でサーバ費用と利用者数に対するコード量あるいはエンジニア人数を考えてみると良いかもしれない。

ところで、利用者数をゼロにしたらサーバ費用はゼロになるだろうか。おそらくならない。コード量がサーバ費用に寄与しないと仮定すると

$$
\begin{split}
サーバ費用
&= \cfrac{サーバ費用V}{利用者数} \times 利用者数 \\
&+  \cfrac{サーバ費用F}{コード量}  \times \cfrac{コード量}{エンジニア人数} \times エンジニア人数
\end{split}
$$

第1項が運営費用、第2項が開発費用と考えても良いかもしれない。あまり深くは考えていない。

おわりに

次回なにか考える。

コードはまっさらな状態から新しく書くのが最も簡単

これが真かはともかく、2023年5月時点のAIはゼロから簡単なアプリを作ることはできる。一方で、既存のコードベースにいい感じに手を加えられるほどでもない。この理由は人間でも難しいからで

  • 広範囲に渡る（10万行〜）コードベースの把握

  • ドメイン知識の把握とビジネスロジックの理解

前者はスケーラビリティの問題である。時間が解決するような気もするし、別のアプローチが必要な気もする。

後者はもう少し複雑になる。普通、何らかのリファクタを行うとき、ビジネスロジックを多少の変更させることと合わせて行うことがある。これは技術的な問題というよりもっと総合的な問題で、こちらの方が解決が難しい。すなわち、技術的な複雑さの根本的な要因がプロダクト自体あるいはユーザー体験自体に起因する場合だ。次の手続きが必要になる。

  • 技術的な困難さに比べて、ユーザーの得られる便益が少ない（技術的な困難さは開発生産性の低下を招くから、ユーザーが将来得られる便益を先食いしている状態である）

  • こういう場合はプロダクトの仕様そのものに変更を加えて、技術的な困難さを大幅に緩和することが望ましい

  • というわけで妥当な粒度で、仕様を再設計し、リファクタとともに実装し、品質保証し、リリースする

  • 当然ながら、必要があればリリースに合わせてユーザーと何らかのコミュニケーションを行う（勝手に仕様が変更されることを好ましく思うユーザーは少ない）

AIがこの領域に入るのはまだ相当に期間が必要になると思う。これはプロダクトマネジメントあるいはチーム開発の難しさそのものだからだ。

とはいえ、いずれできるようになるのは想像がつく。何年後になるかわからないが。特におちなし。

この記事が気に入ったらサポートをしてみませんか？