広木大地さんがすごい
Findyの主催する開発生産性カンファレンスの感想の2つ目だ。
まず前提としてこのカンファレンス全体として、示唆に富んでいて学びが多い良い会だった。
ただ最後の広木大地さんの発表が自分として桁違いに感じて、それまでの内容が薄れてしまったのはある。
まず思ったのが情報量が多いこと。
これは著書を読んだときも思ったが、それ単体で１章書けるような内容を１文で書くような圧縮度がある。
それを発表で聞くと、理解するまで待つということもできないので忙しなく脳が働かされた感覚だった。
で、これまで具体的な実践の話が講演でなされてきた中で、「デプロイ頻度を上げるのが目的化しても単に細かくなるだけで機能レベルで見たら変わってないとかあるよね」みたいな話は何度も見てきた。
そんな中で、それ全体を包み込むような抽象化をしてめちゃくちゃシンプルな問いに落とし込んだ。
さらにこうした抽象度の高い内容を話すとき、往々にして実務的な、具体的な内容が薄れてしまうことがある。
それが喋ってる内容での補足も含め、生きた経験とつながってくるものが多いと感じられた。
ということで発表中頭良すぎだろって思ったし、なんで自分はこの域に達せないんだろうとも思った。
頭の良いと感じる人
なんで自分はこの域に達せないんだろうって考えたときに、そもそもなぜ私は広木氏が頭が良いと感じたんだろうという疑問に行き着く。
頭の良さは数値的に測れないもので、結局のところ頭の良し悪しなんて自分が感じたことでしかすぎない。
そして自分より優秀だと感じる人はいくらでもいるが、ほとんどはまだ理解可能な範囲にいるように感じられる。
もちろん一生かけても追いつけないくらい差が開いているのかもしれないが、なんていうか「まぁ論理的に考えたらそうなるだろうな」って思える以上到達可能に感じられるのかもしれない。
ただ稀にそう感じられない人がいて、強く感じたのは東浩紀さんと広木大地さんだ。
何をするべきか
まず両者に共通する学術的基盤がしっかりしていること。
哲学的知識もそうだし、連続的に今を捉えるための歴史的知識もそう。
微分積分の定義はわかっても、微分積分で世界を捉える数学的感覚は一朝一夜で身につくものではない。
さらにはちゃんと現実世界のフィードバックを得ながら実践的にブラッシュアップしているからこそ頭でっかちでない重みがある。
仮に知識レベルが追いついたとしても、いちフリーランスエンジニアとして家にこもって機能開発しているだけでは到達できないものだろう。
こうした全てからくるぶ厚さが壁のように目の前につきつけられるからこそ、特に圧倒されるのかもしれない。
東浩紀さんに関しては専門外だからまだ到達不可能なことに納得感はあるが、広木さんは同じエンジニアなのでより自分と比較して敗北感を覚えやすいかもしれない。
まぁ比べる必要なくない？って話ではあるが、負けたくないって気持ちこそが向上心につながる側面もあるため、自分のペースで追いつけるよう努力していこう。
Findyがすごい
Findyの主催する開発生産性カンファレンスに参加してきた。
内容はめちゃくちゃ良くて勉強になったんだけど、同時にFindyの凄さもひしひしと感じた。
というのも、Findy Teamsってサービスの宣伝としてめちゃくちゃすごいなと。
まず参加者のほとんどがEM、CTO、VPoEであり、生産性向上に興味のある層で、サービスを売る対象としてベストなターゲット層だ。
さらにそこに対して開発生産性の有効性、DORAメトリクスの有効性を1日中色々なひとが喧伝して回る。それは直接的にはサービスの宣伝ではなくても、間接的に1日中宣伝されてるようなものだ。
カンファレンスっていう密室で1つの価値観を唱え続けるのは、悪く言えば一つの洗脳手法とも言える。
そして待ち時間にはサブリミナル的にひたすらFindyTeamsの宣伝映像が流れ続ける。
そう思った瞬間、サービスを売る戦略としてすごすぎない？って思った。
「弁当無料ありがとう！」なんてレベルじゃないぐらいリターンを得ているだろうと推察される。
純粋にFindyという企業やサービスの宣伝にもなるしね。
というのと、1つの価値観を広める能力としても純粋にすごい。
DORAメトリクスなんて出たのはだいぶ前なのに、ほぼ日本のエンジニア界隈で聞くことのないワードだった。
それがFindyが力を入れた瞬間に「ん？なんか最近見るな」ってなってきた。
それは過去テレビがトレンドを作ってきたように、エンジニア界隈のトレンドを作る力があるってことだ。
繰り返しになるが、サービスを作ってそのサービスが提供する価値を浸透させる力があるってのがめちゃくちゃすごい。
と、これだけ書くと売り上げのために洗脳してるみたいな感じにもなるが、純粋に業界にとって良いことだと思う。
米国ででたやり方や考え方が日本に浸透するまでにタイムラグがあって、それは翻訳のラグであったり、それを実践して喧伝するまでのラグであったりってので体感５年以上はあった。
それがすぐに広がるスキームができるのは日本のエンジニアリング界隈にとって間違いなくプラスだろう。
トレンド化することでバズワード化し浅い使われ方される懸念もあるが、それはまぁその概念が普及したら避けられないことではある。
（DDDもそうだけど日本は1つのトレンドに皆んな飛びつきすぎだとは思うが）
で、自分自身がこの例を見て参考にできるかというと難しい。
真似しようと思っても、そう簡単にできるものではないのだ。
まず協賛企業が作れるほど色々な企業とのつながりがあることや、そこに協賛するメリット（宣伝効果）を作れるのはFindyの業務形態だからこそでもある。
また登壇してくれるようなエンジニアとの接点があることもそうだし、ちゃんと参加者を集められる拡散力もある。
それも含めてFindyの作ってきたものの凄さだなぁというのはある。
久々にこうしたイベントに参加したけど、オンライン配信じゃこの感想は得られなかったろうし、やっぱり普段と違うことをすると新しい発見があるものだ。
携帯電話PDCA
およそ２年前に携帯を買い替えた。
そもそものきっかけとしてはiPhoneの画面が割れたことだ。
さらに
あたりだ。
で、4万円超ぐらいのAndroidモデルを買ったわけだけど。
- 非３Dゲームでももっさり
- Webの立ち上げなどもやっぱちょっともっさり
- 何より電池切れる速度が速い
ということで、やっぱ重たいゲームするわけじゃなくてもスペックって大事なんだなぁと実感させられることになった。
慣れれば気にならないんだけど、冷静にこの待ち時間って積み重ねていくと人生無駄にしてるよなぁと思ったり。同じ10分の空き時間でも、多少なりともできる作業量に違いは出るわけで。
それに朝充電しても1日持たないのは旅行中辛い。周りにも迷惑かけるしね。
ただAndroid自体は割と良いんじゃない？ってことで、セールに釣られてPixel 7 Proを買ってしまった。
これで今まで通りだとまたすぐボロボロになるだけなので、ちょっと考え方を変えてみる。
- 携帯電話を首からぶら下げるやつを使ってみる
- 無くさない
- 落とさない
- 海外旅行中盗まれない
- 携帯電話を保護する部分に力を入れて、機種変更の際に高値で売れるようにする
買う際の出費は多くても、中長期的に元は取ろうプラン。
これがどう転ぶか試していこう。
スタートアップがGolangを採用すること
Golangを採用しているスタートアップの話を聞いて思ったこと雑記。
Golangの特徴はGoroutineによる高い並列性と、機能を削減したシンプルな設計にある。
反対に他の言語に比べまだエコシステムが不十分であることや、シンプルな設計により機能が少ないことから記述量が増えてしまうこともある。
そしてビルドが必要になることから巨大なモノリスには向かず、マイクロサービス化を進めないと開発速度が低下する側面もある。
このような特徴を踏まえるとPMFに至るまで試行錯誤を繰り返すスタートアップ企業において相性悪くない？って思う。
まずユーザ数は少なく低負荷なのでメリットは享受できないし、マイクロサービス化が正当化できるほどエンジニアもいないこと、そして少ないエンジニアで高速に開発していくにあたりエコシステムが充実しているほど良いためデメリットは全面的に受けることになる。
そしてそれは最近もてはやされがちなRustもそうなのかなぁと。
この観点で見るとスタートアップがインタプリンタ言語を採用するのがやっぱり合理的に感じるし、エコシステムの充実度やフロントエンドとの相性、採用のしやすさからNodeが一番良さそう。
ただChatGPTに聞いたら以下のような返答が来た。
個人的な意見として、スタートアップがGo言語（Golang）を採用することは、多くの場合において合理的な選択だと考えています。
以下に、スタートアップがGo言語を採用するメリットをいくつか挙げます。
-
生産性と開発速度: Go言語はシンプルで直感的な文法を持ち、効率的な開発をサポートします。コードの可読性が高く、言語の設計哲学に基づいており、短期間で柔軟な開発が可能です。また、豊富な標準ライブラリとエコシステムが存在し、開発者の生産性を向上させます。
-
パフォーマンスとスケーラビリティ: Go言語は高速で効率的な実行性能を持ち、大量のリクエストやトランザクションを処理することができます。並行処理とネットワーキングの機能が組み込まれており、スケーラビリティにも優れています。スタートアップが成長するにつれて、アプリケーションのパフォーマンス要件に対応できる特徴です。
-
クロスプラットフォーム対応: Go言語はクロスプラットフォームでの開発に適しています。バイナリ形式での実行可能ファイルを生成するため、異なるオペレーティングシステムやアーキテクチャでのデプロイが容易です。これにより、スタートアップは幅広い環境での展開を迅速に行えます。
-
マイクロサービスアーキテクチャへの適合性: Go言語はマイクロサービスアーキテクチャに適しています。小さな単一責任のサービスを構築するのに適しており、軽量スレッド（goroutine）とチャネルを使用して非同期処理や並行処理を実現できます。スタートアップが成長し、マイクロサービスアーキテクチャに移行する可能性がある場合、Go言語は適切な選択肢です。
ただし、最終的な言語選択はプロジェクトの要件や目標、開発チームのスキルセットによって異なる場合があります。他の言語やフレームワークと比較検討し、プロジェクトのニーズに最も適したツールを選択することが重要です。
うーんこれは成功の桁が違う英語圏のコンテキストが強そうに思う。
日本におけるWebサービスの成功ってそこまでユーザつかないんだよね。
パフォーマンス課題も言語以前にスロークエリが原因であることが多く、逆に言えばこんなスロークエリあっても回るのであればどんな言語でも良いじゃんって感じる側面も強い。
まぁ一概にこれが正とは言い切れないが、少なくとも自分が技術選択するにあたりこの辺は考慮したい。
===
主張に反論させてみた。
その観点は理解できますが、以下の理由からGolangをスタートアップが採用する意義は依然として大きいと主張します。
-
初期開発速度: Golangはそのシンプルさから学習曲線が緩やかであり、新規プロジェクトを迅速に開始するのに理想的です。また、高レベルのパフォーマンスが必要とされない初期段階でも、Goのコードの明確さと可読性はバグを減らし、メンテナンスを容易にします。
-
スケーラビリティ: パフォーマンスは初期段階では重要でないかもしれませんが、製品が成功してユーザーが増えた場合、その高パフォーマンスは大きな利点となります。その際に他の言語からGoへのリプレースを考えるより、最初からGoを採用しておく方がよりスムーズなスケーリングが可能です。
-
マイクロサービスとモノリス: Goはマイクロサービスに適していますが、これはモノリスの開発に適していないという意味ではありません。また、Goはコンパイル時間が短いことで知られており、大規模なプロジェクトでもビルド速度はそれほど問題とはなりません。
-
人材の問題: Golangの人材が少ないという問題は理解できますが、Goの学習曲線は緩やかであるため、他の言語からの移行はそれほど難しくありません。また、Goの人材市場は急速に成長しています。
-
エコシステム: Goのエコシステムは確かにTypeScriptやRubyなどの成熟したエコシステムに比べればまだ発展途上ですが、急速に成長しており、すでに多くの強力なライブラリとツールが利用可能です。
すべてのスタートアップがGoを採用すべきというわけではありませんが、そのシンプルさ、高パフォーマンス、そして急速に成長しているエコシステムは、多くのスタートアップにとって魅力的な選択肢となり得ます。
賛成派・反対派に分けて議論させたり、自分の主張に反論させるのは考えが深まって良い。
転職に何を求めるか聞かれたことを思い出した
過去を振り返りつつ今を見つめると、ある程度正解と思える軸ができてきたなと思えてくる。
特に思い出したのはおそらく２回目の転職活動のとき。
転職先に求めるものを、人・環境・金などのリストから順位付けて説明しろと言われたことだ。
当時困って曖昧な返事をしてたら、「数年後また受けたいと思ったら受けにきてね」と言われたのが印象的だった。
同じような質問を最近されたが、今は少なくとも現時点の考えを答えることができた。
よくあるのが、前の職場で不満だったことがその次の職場の決定基準になることだ。
給料の低さが不満の人は給料高いところいくし、技術力の低さが不満だったら技術力の高いところに行く。しかし完璧な職場などなく、結局足りない要素に不満を抱くことになる。
このパターンは刹那的で、またすぐ別の不満を抱く。
ある程度経験を積むと、よりフラットにそれぞれの基準を比べることができるようになってくる。
そしてある程度軸というものができる。
人によっては「過去の良い職場と比べて常に不満を抱く」モンスターになるパターンもあるし、「どうせ次がある」という感覚が強くなると１つの職場に対しての扱いが雑になっていくパターンもある。
とはいえ極力閉じた系の中にい続けるのではなく、世界に対してオープンに触れていくのが一番なのは間違いないだろう。
思考をどうまとめるか
今回記事を書くに至るそもそものきっかけは、考え事をするときカメラに向かって喋ると捗るという記事を目にしたことだ。
自分は明らかにそれが苦手で、前にひろゆきが言ってるのを見たが「思考する→文章にする→読み上げる」のステップを踏むタイプだからだ。
おそらく多くの人は「思考する→言葉にする」がノータイムでいけるんだろうが、それができない。
なのでこうして文章にして思考をまとめている。
つまり記事を書く目的は思考をまとめるためであり、最近は誰かに読ませるつもりもなくなってきている。
強いて言えば未来の自分のためか。
なぜかこうして文章で発散しないと同じことを考え続けるもので、逆に言えば一度誰にも読まれない記事であれ発散してしまえばそのことが頭に浮かぶことはなくなる。
それに日記として当時の自分はこういう経験を経てこう考えた、というのは非常に参考になる。少なくとも何処の馬の骨かもわからないネット記事よりは信用できる情報源だ。
脱線したが、経験を抽象化しその時点での結論を出し続けることで、人生に軸が生まれてくるのかと推察される。
抽象化が得意なタイプと具体化が得意なタイプ
あわせて考えたのが、抽象化が得意なタイプと具体化が得意なタイプの２種類いることだ。
これは岡田斗司夫の考える４タイプ分類でも用いられる指標だし、MBTIにおける感覚(S) vs 直感(N)もそれなので、人間を分類する際の信用できる指標であることは間違いないだろう。
具体化が得意なタイプは「Golangでクリーンアーキテクチャやってみた」みたいな記事を書くだろうし、抽象化が得意なタイプはまさにこの記事みたいなのを書く。
（実際に物事を前に進めるのは具体化タイプの方が得意かもしれない）
自分は経験から抽象化を繰り返してここまで生きてきたため、人生が１つの哲学となり、ある程度の軸が生まれた。
しかし具体化が得意なタイプはそうでもなく、もっとReactiveに生きているのかもしれない。
たまにこうして異なる価値観を想像して他人の目線で考えてみると、本当に人によって世界の見え方は違うんだろうなと思う。
INTPとISTP
自分はINTPと出たが、具体寄りに生まれてたらどうなるんだろうと思いISTPの性格も見た。
うーんこれも当てはまってるように見える。
割と仕事だと課題解決寄りに振る舞うので、ISTPの傾向が出るのかもしれない。
ISTPで行動してINTPで内省するタイプだとしたら良いバランス感じゃない？
MBTIを見て「このタイプはこういう性格」とただ納得するのではなく、「内向的かつ具体よりな性格はどういう行動をとるか」と頭の中で論理を構築して、答え合わせとしてMBTIの分類表を見るってのを一度やると対人理解力が上がりそうだ。
CTOにはどうやったらなれる？
業務委託でさまざまな会社と関わってく中でさまざまなCTOを見てきたし、同期でCTOになる人も増えてきた。
その中で「CTOって肩書きは結局飾りでしかないよね」という感覚も生まれあまり興味が持てなかったものの、世間一般としての評価値はその肩書き１っ本でめちゃくちゃ上がるというのにも気づいてきた。
CTOもピンキリで、プログラミングできない人もいれば、パワハラでエンジニアが半分辞めたような人もいる。
ただそういったCTOもその後もCTOなり技術顧問なり責任あるポジションについてるのだ。
それでCTOってどうやったらなれるんだろうと思って調べてみると、「CTO経験者、もしくはX人以上のマネジメント経験あり」などの条件が並ぶ。
CTOになる目線で見てみると、『服屋に行く服がない』状態だ。
というわけでどうやったらなれるのか冷静に洗い出してみる。
CTO募集案件にCTOとして応募する
大きく分けて３つのケースが考えられる。
1. 開発組織がまだない or 未熟なケース
2. CTOが不在のケース
3. 経営陣が今のCTOに問題があると感じてる
1. 開発組織がまだない or 未熟なケース
これも２パターンあって、アーリー期か、非IT企業がこれから開発組織を立ち上げようというフェーズか。
アーリー期については一番多いのってリファラルで、ビジネスアイディアを実現するために周りの知り合いエンジニアに声をかけるってケースが一番多いとは思う。
それに規模感的にも仕事内容はEMレベルなので、求められるハードルは低そう。
それを言えば企業側もCTOとして採用せずにまずはEM採用で良いので、あえてその役職を与えるとしたら優秀な人を誘うためのエサになるか。
非IT企業に関しては技術力というよりは、だいぶ政治力が求められそうだな。
やっぱり採用側の期待値としても他部署との調整能力・マネジメント経験が強く求められそう。
2. CTO不在のケース
1番と近いけど「ある程度開発組織も人数いるし、会社のフェーズも進んでるものの、CTOはいない」ってケース。
経営陣のハードルが高いか、誰もなろうとしないか、普通にCTOになれそうな人にめぐり合わなかったか、まだあえてCTOを作ろうという段階ではなかったか。
「開発規模が大きくなってきたのでそろそろCTO的な役職が欲しくなってきました」「これから一気にグロースさせるのでCTO募集です」みたいな意思決定はすごく真っ当。
アーリー期よりはハードルは上がるものの、母数的にも要求値的にも一番現実的な選択肢。
3. 経営陣が今のCTOに問題があると感じてるケース
割と見る。
あくまで「経営陣がCTOに問題があると感じてる」なので本当に問題があるかは別。この場合は地雷案件になりそう。
すでに文化・開発組織が出来上がってる＆何かしらの問題が経営陣に届くレベルにまでなってるからCTOリプレースしたいわけで、求められるハードルも実際に解決するためのハードルも高そう。
いま参画してる企業のCTOになる/リファラル
お互いわかった上での依頼なのでお互いにハードル低い。
そして能動的に掴めるものではなく、完全に巡り合わせとタイミングの問題。
CTOがすでにいる企業でも「今のCTOと変わってくれないか」ってお願いもあるので本当に狙ってやるものじゃない。
というわけで
結局一番真っ当なルートはこれで、そこで肩書きと社会的信用を得た上でCTO案件に応募ってのが正攻法なのかなと思う。
そう考えると今まで何度もチャンスを逃してきたのはもったいなかったな。一度でも挑戦していればその後の未来が大きく変わっていたのかもしれない。
断ってきた企業は「その後CTOが毎年変わって最終的に開発組織がクローズ」とか「社長のパワハラが酷くて平均勤続が数ヶ月」と断るのも正解ではあったとは思うんだけど、履歴書上じゃそんなの知ったことないしね。
起業考えてる人にリファラルで声かけてもらった時もそのビジネスアイディアがいけてるかは置いといて積極的に乗っかるべきだったか。
「この企業で上場目指すために全力で頑張りたい」って気持ちになったらCTOになるってのは求めすぎだったのかも。
ここ数年は特にエンジニアの売り手市場で「いくらでも選択肢はあるよね」みたいな感覚に踊らされてたかもしれない。
次声かけてもらったらどんな案件であれいったん全力でCTOやってみるか。
どう立ち回るべき？
仮にCTO目指すからといってCTO募集案件だけを探すのも、違うかもしれない。
シンプルにいちエンジニアとして参画して目の前の仕事で成果出しつつ選択肢広げていくってのはありそう。
ただいち開発者としての参画は未来につながるか怪しいかも。
今はフルリモートだから特に担当EM以外と全くコミュニケーションラインがないみたいのもざらだ。
1日中開発して1日１回のMTGで進捗喋るだけで終わるのも多い。
対面の頃はエンジニア以外の人とも飲みに行ったり人間的な広がりはあったけど、今はエンジニアですら会ったことない人の方が多い。
というと選ぶ軸として対面というのは１つある。
あと過去CTOにならないかお願いされたときも、やっぱり採用とかマネジメントとかEM的な立ち回りをしていた頃が多かった。
結局「CTOにならないか」ってお願いするのはエンジニア以外の人で、そこの信頼を得るにはある程度高いレイヤーの仕事をしている必要がある。
そもそも振られた開発タスクをただこなすだけの人にCTOにならないかって言うモチベーションも湧かないだろうしな。なんか優秀な作業者でしかない。
せめて「企画などとのコミュニケーションラインもあるような開発体制である」必要がある。
色々考えるとエンジニア以外との繋がりが軸なような気がしてきたなぁ。
エンジニアは何か作りたいと思ったら自分で作れば良いだけだしな。
技術者が事業を始める勝ち筋
重たい技術スタックやジュニアエンジニアだけで作られてるスタートアップのビジネスモデルを軽量な技術スタックで再現すれば、実は安定して勝てるんじゃないかという閃きを得た。
完全にエンジニア以外をないものとして考える技術者目線だし、先行者優位もあるけど、単純化して考えれば市場があることがわかってる中での奪い合いなので下手に新しいビジネスを考えるより確度が高そう。
いちエンジニアがとる戦略としては割とありか。
開発効率って割と技術選択で軽視されがちだけど、色々な会社を見て思うのはものすごく大きなファクタを占めるということ。
同じ機能でも1日でリリースできる現場もあれば、何ヶ月もかかる現場もある。それくらい違う。
1週間で作ったサービスをリプレースするのに1年近くかけたみたいな話も聞いた。
もちろん1週間の方が保守性低かったのかもしれないが、スタートアップにとっての1年は生死に関わるものだ。
今はエンジニアの技術力志向が過剰になってて、保守性を高めるためにいきなりゴテゴテの技術スタックで組んで、結果的に保守性が落ちてる例をよく見る。
1年近くかけて作られたサービスみても、スタートアップに向いた技術スタックでサクッと作っちゃえば同じもの1ヶ月くらいで作れるんじゃない？ってのは実際ある。
そのスピード差は数年後さらに広がる。
というわけで今あるスタートアップを調べるってのをやってみる。
スタートアップデータベース
スタートアップ一覧的なのないかなぁと思って調べると、いろいろ見つかる。
これは無料範囲だと詳しい検索はできなそう。
切り口を変えてWebエンジニアの求人情報から見るのもありか。
今回の選び方は「どんなサービスか」より「この技術スタックなら勝てそうだ」なので、その方が絞り込むスピードが速くなる。
というわけでNotionにまとめていこう。
