開発スピードが遅いのか、作っているものの筋が悪いのか
前口上: rails statsで企業価値は測れるか?
rails stats
はRailsリポジトリの統計情報が取れる便利コマンドです。LaravelでもLaravel Statsを使って php artisan stats
で同様のことができます。
結構リポジトリの内情を丸裸にするコマンドで、モデルやコントローラーのサイズからアプリの規模感が掴めますし、コードとテストの割合からしっかりテストが書かれているかがわかります。
Webサービスの事業価値は大きく見れば売上や成長率、より細かく見ると業態やtoBかtoCか、どこの産業向けか、アクティブユーザー数などで決まります。一方でIPO以降の売上成長率は従業員数に比例しているという話もあり、ビジネススキームが決まってしまえば後は頭数に比例するとも言えそうです。
Four Keysなどの開発生産性の指標を計測する企業も増えてきて、エンジニアの人数を投下した時のPR数やコード量はある程度最大化する手法が固まってきたように思います。そうすると今度は儲かりづらいところで戦っていないかやPMの施策の打率がボトルネックになってくると思っています。
rails stats
類似の統計情報は企業ブログやカンファレンスの発表資料などで公になることがあり、公開されている情報を集めて比較することで、他社だとこのくらいのコード量でこのくらい儲かっているを可視化できないかと思い比較してみます。
rails stats
参考までにRedmineのrails stats
は以下です。
+----------------------+--------+--------+---------+---------+-----+-------+ | Name | Lines | LOC | Classes | Methods | M/C | LOC/M | +----------------------+--------+--------+---------+---------+-----+-------+ | Controllers | 8830 | 6600 | 55 | 534 | 9 | 10 | | Helpers | 6740 | 4932 | 1 | 396 | 396 | 10 | | Jobs | 112 | 88 | 3 | 9 | 3 | 7 | | Models | 19512 | 14119 | 102 | 1502 | 14 | 7 | | Libraries | 20325 | 14490 | 149 | 1176 | 7 | 10 | | Controller tests | 0 | 0 | 0 | 0 | 0 | 0 | | Helper tests | 4121 | 3198 | 21 | 282 | 13 | 9 | | Model tests | 0 | 0 | 0 | 0 | 0 | 0 | | Mailer tests | 0 | 0 | 0 | 0 | 0 | 0 | | Integration tests | 10344 | 7263 | 101 | 575 | 5 | 10 | | System tests | 1504 | 1022 | 10 | 65 | 6 | 13 | +----------------------+--------+--------+---------+---------+-----+-------+ | Total | 71488 | 51712 | 442 | 4539 | 10 | 9 | +----------------------+--------+--------+---------+---------+-----+-------+ Code LOC: 40229 Test LOC: 11483 Code to Test Ratio: 1:0.3
縦軸が種類、横軸が指標です。Controller/Model/Mailerのテストがないのは意外ですね。
2012年のBasecampのCode LOCが13146でそれよりは大きいですね。DHHのプロダクト(おそらくHEY)のcode-to-test ratioが0.7なので0.3だとテストは少なめな印象。
Linesが生の行数、LOCがコメントや改行を除いた行数。M/CはMethod Per ClassでLOC/MがLOC Per Method。 RubocopのMetrics/MethodLengthのdefaultが最大10ですが、もう少し緩くしている企業が多い印象でRedmineは平均9。
Zeitwerk以降から1 class 1ファイル前提ですが、それ以前から割合Railsではそうであることが多いので、Class数=ファイル数とすればテーブル数が100くらいで、コントローラーが50くらいですかね。
scaffoldするとcontrollerのmethodはverb 7個 + set_xxxで8個でしょうか。RedmineのControllersのM/Cは9なので+1くらい。全てのコントローラーにverb全て必要なわけではないですが。
Modelのmethod数14は他と比較してみないとなんとも言えないので以下、企業のrails statsを見ていきます。
SmartHR(2022)
https://speakerdeck.com/sugamasao/smarthr?slide=19
ユニコーン企業のSmartHR。NEXTユニコーン調査によると2022年9月時点の推計企業価値は1731億円。2022年9月時点で従業員数686名、エンジニアが70人。
Code to Test Ratioが3.8でかなりテストを厚めに書いていますね。モデル数が664、コントローラー数が596。Redmineより1:1対応していますね。
コントローラーのM/Cが4、モデルのM/Cが4で細かくファイル作っている印象。LOC/Mは60で少し大きめですかね。
freee(2021)
https://speakerdeck.com/mihyaeru21/freee-backend-api?slide=8
会計ソフトのfreee。rails statsではないですが統計が載っている資料があったので載せておきます。
freeeさんは複数プロダクトをやっているので難しいところはありますが、2021年6月の時価総額が5593億ですが、2022年6月だと市況によって1860億円に下がっているので難しいところですね。SmartHRのシリーズDが2021年なので、PSRは緩めの値で比較するのがフェアかなといったところ。
2021年6月の従業員数が656名。
テーブル数700はSmartHRより同じかちょっと多いくらいですね。Rubyファイル数1万はえぐいですね。ファイル数=クラス数とすればSmartHRの6.7倍でしょうか。
雑にroutesの数をcontrollerのmethod数と同等とすればroutingもSmartHRの2倍あるように思えます。
カンム(2022)
プリペイドカードのバンドルカードなどを運営しているカンム。2022年12月にMUFGに買収されています。報道によれば評価額250億円。
M&AはIPOより評価額が下がると言いますが、2021年の売り上げが39億円だそうなので2023/04のSaaS系のPSR5.5倍程度を加味するとそこまで悪くない気もしますね。ひとまずそのまま使います。
従業員数43名でエンジニアはバンドルカード単体だと5.5人でしょうか。
技術ブログによれば、2022/03時点で
- テーブル数: 310+47 = 357
- APIエンドポイント数: 121+6=127
だそうです。
決済系は競争力がデータのハンドリングの部分で、ドメインモデリングが純粋なSaaSより少ないかと思ったのですが、結構テーブル数ありますね。
クックパッド(2015)
https://speakerdeck.com/a_matsuda/the-recipe-for-the-worlds-largest-rails-monolith?slide=26
レシピ共有のクックパッド。2015年12月の時価総額が会社の歴史上のピークで2771億円。今回の主題ではないですが、お家騒動があったのが2016年1月で翌年から時価総額が下がっています。従業員数が連結で臨時除いて519名。
2015年の時点でモデル数1732はだいぶ多いですね。コントローラーと比べて3倍あるので結構Viewとかテーブル以外の概念が入っているのかもしれません。
LOC/Mは21で比較的抑えている印象。足すとコード部のLOCが140,206なのでCode to Test Ratioは2.1でしょうか。
クックパッド(2017)
https://speakerdeck.com/hogelog/kutukupatudofalseju-da-rails-apurikesiyonfalsegai-shan?slide=16
2年後のクックパッド。2017年12月の時価総額が652億円。従業員数が連結で臨時除いて389名。
モデル数が1892で2年で160増えています。単体の従業員数が280名で1/3がエンジニアとして93なので(モバイル他含む)エンジニア総数で一人あたり1テーブル/年増加といったところでしょうか。
コントローラーのクラス数は2年で101増。メソッド数増加が564。
Code to Test Ratioが1.4で減りましたね。一応多ければいいという訳ではなく、MECEというかきれいに書けていると減るという考え方もあるようです。
LOC/Mが20なので節度を持って開発しているなといったところ。
テーブル数と時価総額を比較してみる
いくつかデータが取れたのでモデルのクラス数=テーブル数という緩めの仮定のもと比較してみます。
あんまり上手くいかないですね(泣)。外的要因が大きい。
試しにfreee(2021)はPSRが高すぎたとして2022年の値を、クックパッドはお家騒動前が本来の企業価値としましょう。
見たいように見てしまった感はありますが、これだとテーブル数*1.5+345=時価総額(億円)ですね。もっとざっくり把握用に切片除けばRDBのテーブルが一つ増えるたびに時価総額が2億円あがるくらいが上場企業のベンチマークでしょうか。
せっかく従業員数も調べたのでテーブル数と比較してみましょう。
だめですね(泣)。同様に補正すると
だめですね(泣)。総テーブル数は今までの従業員数x年数の積分で効くので爆発的成長をするスタートアップで比べると現在の従業員数はそれほど意味がないとは言えそうです。
所感
思ったほどrails statsが集まらなかったので他にも公開している企業があれば教えてもらえればと。
RailsはオープンソースのWebサービスもいくつかあるので、そちらでも比較してみたいです。