algonote

There's More Than One Way To Do It

トップ > プログラミング

[Zenn投稿] Flogを使用したリファクタリングの必要性の可視化と負債返却の説得の仕方の一例

プログラミング Ruby Zenn テックリード Ruby on Rails

複雑性の高い部分の探し方

まとめ

Zennに「Flogを使用したリファクタリングの必要性の可視化と負債返却の説得の仕方の一例」を投稿しました。

zenn.dev

所感

カスタマイズが少し弱い部分があるのでPull Requestを出してみたりしたいですね。

rubocopの内部仕様ももう少し把握したいですが、Zeitwerkをもう少し使いこなせると静的解析でモジュラーモノリス化する際のドメインを機械的に導き出せる気もするの調べたいところ。

ランキング参加中
プログラミング

[Zenn投稿] アーキテクトがチェックすべきオープンソースのWebサービス一覧

プログラミング アーキテクチャ Ruby PHP Zenn

実装の参考の当たり

Zennに投稿しました

Zennに「アーキテクトがチェックすべきオープンソースのWebサービス一覧」を投稿しました。

zenn.dev

企業によってはバックエンドと切り離して独立のアーキテクトを置いていることもあります。自分はDevOpsと同じで極力同じ人がやった方がいい派ですが、とはいえそういったケースで慣れないことをやる時は参照先が欲しくなるのでまとめました。

所感

Figma代替のPenpotもClojure製でユニークですね。PerlやElixirだと何になるのやら。

ランキング参加中
プログラミング

[Zenn投稿] Software Design、WEB+DB PRESS全巻読破のすすめ

プログラミング テックリード 書評 Zenn

Web開発の歴史の復習の仕方

Zennに投稿しました

Zennに「Software Design、WEB+DB PRESS全巻読破のすすめ」を投稿しました。

zenn.dev

WEB+DB PRESS休刊、悲しいですね。

所感

似たような雑誌はInterface、日経PC21、トランジスタ技術あたりでしょうか。

Interfaceは組み込みによってはいますがちゃんとソフトウェアエンジニア向けの記事もある印象。日経PC21は少し電気系よりというか規格まわりの低レベルの話が多いですね。トランジスタ技術は完全にエレクトロニクス。

ランキング参加中
プログラミング

rails statsと企業価値

プログラミング Ruby on Rails Ruby ファイナンス

開発スピードが遅いのか、作っているものの筋が悪いのか

前口上: 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サービスもいくつかあるので、そちらでも比較してみたいです。

ランキング参加中
プログラミング

バックエンド開発に必要な能力の半分以上は言語力以外の部分

プログラミング テックリード アーキテクチャ SQL

ChatGPT時代の戦い方

言語経験年数だけ見るのは間違い

ソフトウェアエンジニアの能力を測る指標としてしばしばプログラミング言語の経験年数が使われることがあります。Perl〇〇年、Go〇〇年というやつですね。

一方で例えばWebフロントエンド開発にHTMLやCSS部分のコーディングが含まれるように、Web開発ではロジックの伴う純粋なプログラミング言語の部分だけでなく、マークアップ言語のようにプログラミング言語以外と戯れている時間も意外と多いものです。

クライアント開発だと分かりやすくデザインとロジックが分離されていてその棲み分けがしやすいのですが、サーバー側ではしばしばそういう視点が忘れられてプログラミング言語力が唯一絶対と誤解されがちな印象があります。

JavaっぽいRubyのコードを見てイラッとしたこともあるので、言語力が重要なのはもちろんそうなのですが、バックエンド開発に必要な能力の半分以上は言語力以外の部分、とりわけミドルウェア力なのではと自分の中である程度整理ができたのでまとめておきます。

SQL力

インターネット回線の高速化によりデスクトップアプリからWebアプリに開発の主軸が移るにつれ、データストアはおおむね1ユーザーだけを考えればいいから複数ユーザーのデータを保存する手法に移行しました。

ユーザーが要求した情報を返す時に、複数ユーザー分データをカジュアルにアプリ層に持ってきてハンドリングするとパフォーマンス上問題になることが多く、極力SQL、クエリー言語の世界で完結させて最小のデータをDB層からアプリ層に送るがバックエンド開発のベストプラクティスの一つです。

プログラミング言語も大事ですがデータベース操作言語も同じくらい大事。

テーブル設計力

Webサービスは24時間稼働が想定されていることも多く、メンテナンスで停止期間ができることは通常歓迎されません。

それがDBの寿命はアプリの寿命より長いと言われがちな部分で一度設計に失敗したテーブル設計は後からリファクタリングが容易でないことも多いです。

RDBでなくNoSQLにすれば簡単になるかというと必ずしもそうではなく、RDBのJOINを実現しようとすると、書き込み時にAxBの組み合わせテーブルを作成しないといけなかったりするので、むしろより事前設計が重要になる場合もあります。

API設計力

Web画面だけの時代からアプリやIoTだったり、複数クライアントから呼ばれるようなバックエンドの場合、データの取得や変更はAPI経由で行われます。

一番よく使われるAPIはRESTのJSON APIかと思いますが、最近はGraphQLだったり、Protocol BuffersでgRPCだったり、サーバー間通信、サーバークライアント間通信の選択肢も増えてきています。

GETのAPIで副作用があるとバグを起こしてしまったり、APIが細かすぎてリクエストが増えて捌ききれない、テーブル直結のAPIを作って変更耐性がなどなどAPIの設計には考慮するポイントがいくつかあります。

キャッシュ設計力

社内システムで限られた人しか使わないだと違うかもしれないですが、たくさんの人が使うシステムの場合、どこかでアプリ層で毎度計算するよりキャッシュを使って複数ユーザーでレスポンス(の一部)を使いまわした方が経済的に合理的になる場面があります。

一方で最近はレコメンドやパーソナライズが一つのキラーフィーチャーになっている場合もあり、個別の最適化と全体のサーバー台数削減のバランスを取るようなキャッシュ設計、戦略を描けるかが大事です。

アプリサーバー外に出すパターンだとRedisかMemcachedがキャッシュストアとして使われることが多い印象。

境界設計力

APIの設計にも通じるのですが、開発人数が増えてくるに連れてモノリスが限界になる会社も出てきており、マイクロサービスだったりモジュラーモノリスだったり、マルチモジュール化を進める会社も増えてきています。

どういう境界分けで名前空間やサーバーを分けるかは一つの技術的チャレンジであり、会社によっては専任のアーキテクトを置いていることもあります。専任がいない場合通常はバックエンド担当者の検討範囲になります。

検索設計力

検索機能は簡単なものならRDBでも実現はできるのですが、パフォーマンス面で問題が起きることも多く、どこかのタイミングで検索専用のデータ構造を事前に作ったデータストアが必要になります。

古くはSolrで最近だとElasticsearch、今後はmeilisearchも選択肢になりうるかなというところ。

こういったドキュメントDBはRDBとは違った設計能力が必要です。

デザイン力

アプリしかやっていない業態でサーバーとクライアントが完全に分離されたシステムもなくはないですが、そういったサービスでも管理画面はWeb画面として作っていたり、バックエンド担当と言っても、フロントエンド部分を何も知らずにできるかというとそうではないですね。

スタートアップだとバックエンドとフロントエンド兼任という場合も多いです。

インフラ力

バックエンドサーバーをホストする環境は古くは会社のオンプレサーバー、次にsshするような名前のついたサーバー、最近だとDockerで管理されたクラスターなんかでしょうか。

専任のインフラ担当がいる組織もありますが、いない場合バックエンド担当が兼任することも多いです。

仕様提案、説明力

ここら辺はバックエンドというよりWeb開発全般ですが、PMが作りたいという機能の技術的に難しい部分を説明したり、時には技術的に簡単だけどやりたいことに近い代案を提示する場面もあります。

To Bのビジネスだと複数PMが必要が持論なのですが、とはいえいない場面ではある程度PMの負荷を減らすために代わりをつとめる場面もあります。

ChatGPT時代は言語力の価値は目減るか

多少間違っている場合もあるのですが、ChatGPTを使うと今まで以上にプログラミング言語の変換は簡単になりました。実際プログラミング言語変換のサービスもちらほら出てきています。

その言語特有の書き方もあるので、ChatGPT時代は言語力の価値は目減るかでいうと高度な部分ではそうならないようには思います。一方で初学者の参入障壁は明確に減ってきて、よりフルスタックになっていくように思います。

最近だとElasticsearchのPerl bindingがサポート終了になったり、機械学習系ならRからPythonに移るトレンドがあったり、今後の言語の流行り廃りによってミドルウェア側がサポート終了になることはありそうです。

一方で例えばRuby 3年の求人にPerl 9年、Ruby 1年の人は不適でしょうか？0年だとつらい、個人開発でもいいので熱量が欲しいという観点は確かにあるのですが、エンジニア経験のない人ほど言語力を過大評価している傾向は感じます。サーバー<=>クライアント間の移動だと確かに難易度のレイヤーが一つ上がりはするのですが、バックエンド開発経験は確かに活きるものがあるなと。

まとめ、所感

以上見たようにバックエンド開発では(アプリ層の)プログラミング言語力以上に非プログラミング言語力が必要です。とりわけ、

  • SQL力
  • テーブル設計力
  • API設計力
  • キャッシュ設計力
  • 境界設計力
  • デザイン力
  • インフラ力
  • 仕様提案、説明力

が必要で、フロントエンド開発におけるHTML、CSSの部分がミドルウェアに置き換わっています。フロントエンドのプログラミング言語以外の部分がユーザー側のI/Oだとすると、バックエンドのプログラミング言語以外の部分はデータストア側のI/Oです。

スタートアップで即戦力を採用するのは一つの難しさで過去SIerからWeb系へのコンバートを主軸に採用した企業はあります。最近だとサイバーエージェントさんがGo Academy/Flutter Academyで中途の転向を狙っていたりしますね。土曜出社者を募る必要はありますがよい作戦。

LLM失業とは違うのですが、自分が極めた言語から抜けたくても抜けられない人は結構いると思っていて、エンジニア採用難の時代、バックエンド経験のみで言語力問わない、言語力の要求を低めにする求人は結構ありなのではと個人的には思います。

ランキング参加中
プログラミング

全エンジニアにGitHub Copilotを提供している企業一覧

プログラミング テックリード

GitHub Copilotは人権になるか

前口上

GitHub CopilotはGitHubの言葉を借りるならAI pair programmerです。Visual Studio Code、Visual Studio、Neovim、JetBrainsのIDE拡張として動き、コードの一部を書くことで残りを補完してくれます。

Twitterを開いたら#GitHubCopilot使えますのタグに全エンジニアにGitHub Copilotを提供している企業情報が流れてきたのでまとめておきます。

社名書かず弊社って言ってた人は適当にプロフィールから社名を抜いたので、つぶやき信用ベースで漏れや間違いは少しあるかもしれません。

全エンジニアにGitHub Copilotを提供している企業一覧

他見つけ次第GitHubに追加します。

github.com

GitHub Copilotのライセンスの違い

GitHub Copilotには二つのライセンスがあります。Copilot for Individualsが個人用でCopilot for BusinessがOrganization、Enterprise アカウント用です。

2023/04/13時点の価格は以下

  • Copilot for Individuals: 1 か月あたり $10、または 1 年あたり $100
  • Copilot for Business: 1 ユーザー、1 か月あたり $19

ここら辺は適宜仕様変わる部分ですが、IndividualsだとGitHubにコードを提供するかのチェックボックスがあり、Businessだと元からないようです。

GitHub Copilotは安全か

GitHub Copilotはpublicなコードから学習されていますが、GPL汚染のコードそのまま吐いてしまうこともあるようで、作者他が自分のコードがそのまま出力されたと集団訴訟が起きています。

使うにしても魔法が強すぎる部分はちゃんとバリデートした方がいいですかね。

一方でGitHubにコードを既にホストしている企業はある種もうソースコードという機密情報をGitHubに握られているので補完用にコードは渡すことへの抵抗感は少ないかもしれないですね。直近サムスンが機密情報を(おそらく学習データとして使われてしまう状態で)ChatGPTにリークしたという事件が起きていますが、元から命綱握られているGitHubと新たに渡すChatGPTだと違いがあるかなと。

外部協力者にGitHub Copilotは提供できるか

会社によっては外部協力者にもGitHub Copilotを提供しているケースもあるようなのですが、法的に少し危うい気もしています。

アジャイル開発の外部委託が偽装請負に当たるかは労働者派遣事業と請負により行われる事業との区分に関する基準（37号告示）関係疑義応答集で明文化されています。契約スキームにもよるのですが、ハの要件が

ハ 次のいずれかに該当するものであつて、単に肉体的な労働力を提供するものでないこと。
(1) 自己の責任と負担で準備し、調達する機械、設備若しくは器材(業務上必要な簡易な工具 を除く。)又は材料若しくは資材により、業務を処理すること。
(2) 自ら行う企画又は自己の有する専門的な技術若しくは経験に基づいて、業務を処理するこ と。

であるので、アジャイル開発の外部委託においては自己の責任と負担でGitHub Copilotは準備する必要があるのではないかが自分の見解ですが、法律の専門家ではないので各自業として行っている方に確認をとり判断するようにしてください。

セットアップの簡便さのために全社共通でCodespacesに統一しているなら蓋然性が高く、GitHub Copilot単体は少し低いかなと。実際JetBrains系のIDEを使っている外部委託者は自力で調達している気がします。RubyMineが一番安い3年目以降で年額¥18,137なので価格バランスとして許容範囲かと。

ただ、そもそも前述の訴訟の関係で使うかどうか尻込みしているケースもあるので、GitHub Copilotを使っていい判断が終わっているなら共有はした方がいいですね。

所感

Sublime Textがメインエディターの一つなのですがLSPかませば使えそう?ですかね。そろそろ腹を括ってVisual Studio Codeに全て移った方が良い気もしていますが。

ランキング参加中
プログラミング

[Zenn投稿] ソフトウェアのバグはコードそのものよりも組織構造から生じることが多い

プログラミング Zenn テックリード マネジメント

テックリードは組織を忘れられるか

TLDR

Zennに「ソフトウェアのバグはコードそのものよりも組織構造から生じることが多い」を投稿しました。

zenn.dev

執筆後記

THE INFLUENCE OF ORGANIZATIONAL STRUCTURE ON~でGoogle検索かけると結構他の論文のサジェストも出てきますね。

トップに出てくるThe influence of organizational structure on value-based management sophisticationもおもしろそうです。

Microsoft Researchはその後他にも論文を出しているのでここ15年での発展も追ってみたいところ。

ランキング参加中
プログラミング

ランキング参加中
マネジメント

HIGH OUTPUT PLAYER - 評価されるプレイヤーはどういう人か

キャリア マネジメント テックリード プログラミング

独自理論を提唱してみる

前口上

HIGH OUTPUT MANAGEMENTというマネジメントについて書かれた本があり、そのなかでマネージャーの評価の公式が出てきます。

マネジャーのアウトプット＝自分の組織のアウトプット＋影響力が及ぶ隣接組織のアウトプット というやつですね。

さてこの公式、マネージャーの評価方法の一つとして的を得ている部分はあるのですが、これを少し拡張するとプレイヤーにも使えるより汎化された公式になるのでは？とふと思ったので提案してみます。

TLDR

さっそくですが新公式です。

職業人の評価 = 自身の能力 + 自身の専門性組織への影響力 + 専門外の組織への影響力

以下細かく見ていきます。

マネージャーの評価はHIGH OUTPUT MANAGEMENT + 他マネージャーへの影響力 で決まる

マネージャーの専門性がマネジメントだとすると上に上げた公式は以下のようになります。

マネージャーの評価 = マネージャー自身の能力 + 他のマネージャーへの影響力 + 隣接組織への影響力

概ねHIGH OUTPUT MANAGEMENTの通りなのですが、他のマネージャーへの影響力の部分が増えています。

マネージャーが例えば課長レベルとして、課長と部長の違いはどこにあるかと言えば、課長を育成できるかという部分だと思うんですよね。HIGH OUTPUT MANAGEMENTの公式は課長の評価制度としては的を得ている部分はあるのですが、どういう人が部長になりうるかという観点が欠けています。

マネージャー自身の能力はマネジメントもそうですし、課長レベルなら一定のプレイヤーとしての能力もいるでしょう。

マネジメントが集団を率いる能力だとすればマネージャーのマネージャーのマネージャーくらいになると純粋なマネジメント力だけで戦える可能性もありますが、せいぜい課長レベルなら現場よりなので普通にプレイヤーとしての能力も一定程度必要な気はしています。

隣接組織への影響力はそのままです。

プレイヤーの評価はマネージャー評価をチャプター視点で見たもの

次にプレイヤーは公式を適用すると以下のようになると思います。

プレイヤーの評価 = プレイヤー自身の能力 + 同じ専門性のプレイヤーへの影響力 + 隣接専門性への影響力

おおむねSpotifyモデルでマネージャーがSquad軸で見ていたものをプレイヤーではChapter方向で見ています。

プレイヤー自身の能力はわかりやすいですね。ソフトウェアエンジニアならテックリードとしての自身の能力の部分。

同じ専門性のプレイヤーへの影響力はChapterを率いれるかでここが今回のHIGH OUTPUT PLAYER理論の肝の部分です。ソフトウェアエンジニアでIndividual Contributorの方のインタビューなんか見てもただコードを書くというよりは結構コミュニケーションは必要とされている印象です。

コンサルのような業態やフリーランスの場合はいらない場合もあるかもしれないですが、組織内でサラリーマン的働き方をしていると、単に専門性があるだけではだめで、組織内でエバンジェリスト的役割を期待されることが多いようには思います。〇〇専門委員会を率いて専門組織の底上げができるかが大事かなと。

隣接専門性への影響力は従来コンピテンシーの中にあったようなソフトスキルの部分と、これはプレイヤー自身の能力といえば自身の能力なのですが、複数専門性がある場合に橋渡しできているかがここのポイントになる気がします。

例えばプロダクトデザイナーをおいている企業だとデザイナーがPMの役割を少し兼務している場合があります。同様にデザイナー+フロントエンド=デザインエンジニア、エンジニア+PM=テクニカルプログラムマネージャだったり、２つ専門性があると強みは増えますね。

ジョブ型雇用時代ではコンピテンシーの分解が必要

今回提案したHIGH OUTPUT PLAYER理論はメンバーシップ型雇用であいまいだったコンピテンシー評価の部分がより分解された形だとも思っています。

つまり、従来のコンピテンシー評価 = 自身の専門性組織への影響力 + 専門外の組織への影響力 に分けられるのではないかと。

メンバーシップ雇用でジョブローテがあるとその組織のカルチャーにどれだけどっぷりつかっているか、社内に知り合いがいるか、いいやつかあたりがぼやっとコンピテンシーにのっていた気がします。自身の能力+コンピテンシーで評価だと自身の専門性組織への影響力が軽視されていたのではないかと。

メンバーシップ雇用からジョブ型雇用に移行しようとしている企業は、組織の専門性をあげるために社内エバンジェリスト能力の高さを明示的に別の項とすることでよりうまくいくのではないかというのがひとつの仮説です。

所感

読めていないのですが、エンジニアのためのマネジメントキャリアパスの対極の本でThe Staff Engineer's Pathという本も出版されているようです。読んだらレビュー書きたいと思います。

ランキング参加中
プログラミング

ランキング参加中
マネジメント

[Qiita投稿] Twitterはタイムラインをどうやってキャッシュしているか

Qiita アーキテクチャ インフラ プログラミング

Twitterの内部構造を読解してみる

TLDR

Qiitaに「Twitterはタイムラインをどうやってキャッシュしているか」を投稿しました。

qiita.com

所感

結構頑張ってリソース探したのですが、最近のものは少ないですね。

TwitterのメインDBのManhattanが気になっているのと、Mastodon(Rails)、Misskey(NestJS)のコードリーディングもしてみたいです。

日本のWeb開発にスクラムは本来不要かもしれない

マネジメント プログラミング

専任のスクラムマスターは必要か

前口上

最近スクラムの源流である論文『The New New Product Development Game』を読みました。概ね日本企業を良い開発手法を採用している企業として、米国企業はどうやったら日本企業のようなよい企業になれるかを論じたものです。スクラムガイドのスクラムも影響を受けているようです。

スクラムはアジャイル開発の中では採用件数が多い手法ではありますが、専任のスクラムマスターは置いていないという企業もままあり、どういう時にスクラムガイドのスクラムが有用で、専任のスクラムマスターを置くことの合理性が高いのか整理してみます。

The New New Product Development Gameの概要

さてこの論文、いくつかの企業の製品を例に比較しています。製品は

  • 富士ゼロックスの中規模コピー機
  • キヤノンの家庭用コピー機
  • ホンダの乗用車
  • NECのパソコン
  • キヤノンの一眼レフ
  • キヤノンのレンズシャッターカメラ

で、それらの開発手法を分析しています。分類すると各工程が独立しているウォーターフォール的タイプA、隣接工程がオーバーラップするタイプB、全工程が影響し合うアジャイル的タイプCになるようです。

リードしている企業は以下の特徴を持つとされています。

  • 不安定性の内在
  • 自己組織チーム
  • 開発フェーズのオーバーラップ
  • マルチ学習
  • わずかなコントロール
  • 組織的学習の伝達

概ねボトムアップの強さ、強いトップダウンがなくても改善のサイクルを回せていることを日本的企業良さとしているようです。

日本企業はスクラムがやりたかったことを元からできている

こうしてみると、日本企業の少なくともトップ企業では元々スクラムの要素は元からできていた言えます。

スクラムガイドのスクラムは米国企業に日本企業的開発手法を取り入れるためのマニュアルとも捉えられて、日本企業は何もする必要がない可能性もあるわけです。

シリコンバレーだとエンジニアは1〜2年で転職してしまうとも聞きます。アメリカは移民にも積極的で人も多様ですね。文化的コンテキストの共有が困難で専任の調整役がいる合理性があるわけです。

一方、伝統的日本企業はほぼ全員日本人で終身雇用です。もっと言うならほとんど男性だけだったかもしれません。同僚は長年一緒に働いた見知った顔。専任の調整役がいなくてもよしなにやってくれることも多いでしょう。多様性のないチームほど専任のスクラムマスターは不要です。

日本企業に必要なのはマネージャーレベルの底上げ

一方で今後も日本が同じ手法が使えるかは疑問が残ります。OpenWorkの統計によると、直近10年間で残業時間は月46時間から24時間に減っています。働き方改革の影響ですね。

日本企業はマネージャーがプレーヤーの能力にフリーライドしていた部分がもあったとも言えて、管理者が方向性を少し失敗しても残業ありきでプレーヤーが勝手にカバーしてくれていたからです。今後も人手不足がより進んでくるとそういったマネージャーの能力のなさが今までよりどんどん可視化されていきます。

今強いものをより強くしてももちろん良いのですが、スクラムは暴論を言えばプレーヤーもっと頑張れのフレームワークであり、日本ではもうできている可能性はあります。むしろ逆側のフレームワーク、管理者研修だったり、サラリーマン社長をどう創業社長に近づけるかだったり、米国のいいところを日本企業にどう取り入れらるかを考える方が大事かもしれません。

メンバーの従業員エンゲージメントを管理職の人事評価に使っている企業もありますね。

開発チーム内の職種が多くないとスクラムマスターは不要

他にも専任のスクラムマスターが必要かの視点はあって、例えば開発チーム内のコミュニケーションパスが多いかは一つの指標です。

ソシャゲ全盛期の方がスクラムスクラム言っていたと思うんですよね。それはある種当たり前のことで、本質的にゲーム開発はWebサービス開発と比べてアセットヘビー。プログラミングが必ずしも花形でなくグラフィックや音声も必要で、当然開発内でのコミュニケーションパスが増えます。専任の調整役を置く蓋然性があるわけです。

一方toB SaaSなんかだと導入役のカスタマーサクセスが事業構造上必要と言われており、コミュニケーションパスがソシャゲと比べると開発内から外に移転したトポロジーです。開発内の調整需要は相対的に低いですね。逆に間に入るPMは忙しいになりやすく、複数PMの企業もちらほらみます。

スクラムに限らずIT企業というざっくりとしたカテゴリーわけだと事業構造を捉えることは困難で、Webサービス開発、ゲーム開発、システムインテグレーションはそれぞれ必要な要素が変わってくるので、異なる業態のチームトポロジーはあまり参考にならないことも多いです。

モジュール化が簡単な領域ほどスクラムマスターは不要

IT企業にはもう一つ専任のスクラムマスターの必要性が低い要因があって、それはプログラミングがチームスポーツの中では比較的個人競技だからです。

The New New Product Development Gameに出てくる企業はメーカーなんですよね。それこそ自動車の部品点数はとにかくたくさんあり、相互に作用していることも多いです。機械設計は物理空間に存在がある関係で疎結合しにくいです。ワイヤレスイヤホンの音質向上のためにモジュールをよくしたら重量が目標をオーバーしてしまったりそういうことが起きやすいです。

IT企業でも決して連携が不要なわけではないのですが、プログラマーの生産性が人によって何倍も違うと言う話の根源に何があるかと言えば野球のピッチャー的存在というか個人性の高い部分だと思うんですよね。

以前資本集約的ビジネスと労働集約的ビジネスの違いについて書いたのですが、労働集約的ビジネスの中にもチーム性の高いものと個人性の高いものがあり、メーカーがカメラを作るよりはプログラミングというのは(ちゃんと設計すれば)モジュール間が密結合になるのを避けられます。

DXコンサルの仕事はいずれなくなるのでスクラムマスターは不要

最後にDXコンサルトとしてのスクラムマスターについても書いてきます。スクラムマスターがスクラムというDX手法の伝導者なら教えを布教し終わったら不要になるのではという意見です。実際そうだと思います。

専任のスクラムマスターがスタートアップの実ロール名で言えば何かと言えばCOOだと思うんですよね。PMでもなければテックリードでもない人なので。ボードメンバーが厚い会社の方が投資家目線だと投資したい会社ではあるのでCOOが不要かというとそうではないのですが、ストックオプションの付与率なんかをみてもCFOやCTOなんかと比べるとCOOは貰えていないことが多いです。

技術もわからずプロダクトの方向性も示せない人がいて助かるか?と言えば必要な場合もあると思います。ただ全てではないです。

エンジニアをざっくり分けると技術が好きな人とプロダクト開発の好きな人に分けられると思っているのですが、任意の領域Aについて最初にそれを開発できるのが誰かといえば技術が好きな人のことの方が多いです。機械学習ブームの時に社会人より学生Kagglerの方が強い瞬間もありましたし、ブロックチェーン起業家が若いという話もあります。

Googleの例なんかをみてもギークな若者技術者+大人で会社を成立させる例はあるのですが、スクラムマスターはこの大人を成立させるためのある種方便の可能性もあります。ただ、時間が経ってギークな若者技術者がキャリアを積んでくると確率的にマネジメントができる人も出てきます。時間が経つにつれてCOO、スクラムマスターはいなくても成立するようになるわけです。

CEOの代わりが務まるCOOならウェルカムですが、COO的キャリアは何ができるのかよくわからない人になってしまう可能性もあると思って、上手く立ち振る舞わないとキャリア上不利になることもある認識です。

まとめ

ダイバーシティーの低い日本企業で、プログラミング自体が比較的花形の業態で、ぽっと出の技術がメインではないWeb開発企業ではスクラム、とりわけ専任のスクラムマスターは不要かもしれません。

スクラムガイドでもスクラムマスターは概念と書いてはあるのですが、これだけスクラムマスターは兼業でやっているという企業が多いのを見ると、もっと上手く必要なチームトポロジーを説明したモデルを発明したいものです。