1年間CTOとEMを兼任して考えたこと

はじめに

昨年2023年は、株式会社NoSchoolのCTOとして、オンライン家庭教師マナリンク（https://manalink.jp/ ）に関わる開発、エンジニアリングマネージャー、採用、UIデザイン、運用保守、PMなどを兼任していました。
本記事では、エンジニアリングマネージャー（以下EM）を兼任していて考えたことをまとめていきます。
シリーズA前後のスタートアップという特異な状況かつ、マネジメントしたメンバーも3人と小規模なためあまり参考になる知見か分かりませんが、現時点での自分の考え方の備忘録的な意味も込めてまとめておきます。

考えたことまとめ

それでは早速矢継ぎ早に考えたことをまとめていきます。

テキストによる情報量の欠落を想像するようになった

直接会話することと、文字でやり取りすることを比べると、つくづくテキストって情報量が欠落するなぁと思います。ソースレビューのコメント1つ取っても、自分は意味が分かっているつもりで書いていても、相手が間違った解釈をしてしまって、記載不足だったなと思います。
それによって、たとえばソースレビューでいうと、レビューコメントの前に【must】【ask】【仕様について】といったカテゴリのラベルを付けるといった対策を取るようになりました。
ちなみに、僕はソースレビューを受けた側が批判された気持ちになるからレビューコメントを柔らかい文章にしたり絵文字を文末に付けます！といった考えはあまり好きではないです。というのも自分の文章で相手がどう「感じる」かはコントロールできないからです。それより意味や意図が正しく伝わることにフォーカスする方が好きです。（もし自分の文章が怖いと受け取られてしまうのであれば、日々のコミュニケーションに課題があると思うので、そちらを改善したほうが良いと思う）

任せられる前にやる人と、任せられてから頑張る人がいて、後者の人を事前に見抜くのは難しいのでとにかく任せてみるといいことがわかった

当たり前すぎる話かもしれませんが、誰でも任せられる前に勝手に学んだり課題解決するわけではないです。任せてみると早速自分で色々調べたりトライアンドエラーするメンバーもいるので、とにかく小さくでもいいから任せてみることが大事だなと思いました。

EMやる前により少人数のマネジメントないしはメンターをやるとよい

とあるきっかけで、メンバーに別のメンバーのメンター業務をお任せしたことがあったのですが、短い期間ではあったもののとてもいい期間だったと僕は客観的に見ていて思いました。EMをいきなり始めると4〜5人程度のマネジメントを0から経験していくことになるので、その前に、1人でも良いですしメンターという立場でもいいので、育成やサポートする、仕組みを作るといった視点に立てる機会があるとステップアップしやすいんだろうなと思いました。

レビューをする上では、正しい正しくないではなくて、目的や意思が一貫しているかが重要

ソースレビューなり設計レビューなりのレビューをするとき、目的や意思が一貫しているかを重視していることに気が付きました。わかりやすい例を挙げると、DB設計をするときに、重要なデータだから変更履歴も保存するという意思決定をしているのに、履歴テーブルに保存されているデータが全然後からリカバリーするに足りない項目数しかない、といった場合です。重要なデータだから変更履歴も保存するべきだ、という意思決定自体の正しい正しくないは簡単には判定できませんが、その意思決定に沿った実装がなされているかは判定できます。
また、正しい正しくないといった話は、レビューの時点でやることではなく、規約で決めることであると思っています。

正しい正しくないが明確に言えるものは、即ESLintなどで仕組み化するのがいい

逆に、正しい正しくないが明確に言えるようなもの、たとえばReactで分岐の後にフックを呼んでいるみたいな場合に対しては、極力仕組み化する発想を第一に考えます。ESLintなどを駆使します。
とはいえ、分岐の前にフックを呼ぶようにしたら誰でもきれいなコンポーネントを作れるとは限りません。そういった簡単に仕組み化できないところは個々人のスキルということになると思っています。

完璧にできている状態と、全然駄目な状態の2択だと思うとしんどい

EMないしCTOとして開発されているものを見ていくにあたって、完璧主義にいつの間にか陥っていると辛いと思いました。そもそも自分が思う完璧が全然完璧ではないことも有り得るのは自明として、完璧にできている状態と、全然駄目な状態の2択しか無いのではなく、その間にグラデーションで、完璧ではないがまあ耐えている、という状態があります。これをどこまで許容するか、許容できないギリギリのラインを決めて仕組み化する発想が必要だと思いました。
たとえば完璧主義者をやりすぎると、設計において何でもかんでもクリーンアーキテクチャに沿ってやろう、みたいな結論に至りがちです。

メンバー同士が互いの得手不得手を知っていることが重要

いくらEMが各メンバーと1on1して得手不得手を知っていても、メンバー同士がお互いに知らなかったらソースレビューなど何だかんだ相手のレベルによって変えないといけないコミュニケーションを委譲しにくいため、重要なフローが全部EM任せになるか、メンバーに任せてもどこか上手くいかないといった状況になりそうです。なので、簡単でも技術勉強会を主催したり、timesに色々書いて良い文化にするなどして、互いの得手不得手を知る仕組みを作るのは有効に思います。◯◯さんは最近オブジェクト指向設計を勉強しているから、今回のソースレビューでその点に注意して見てみよう、といった塩梅は何だかんだ言って多少属人的に起きうると思いますし、レビュー等に限らず日々のペアプロや技術的な対話などでも加味されることだと思うからです。

ハードルを下げるのはマネジメントの役目だが、下がったハードルを超えるのはメンバーの役目

以下のツイートの受け売りなのですが、素敵な考え方だと思いました。

https://x.com/Yuiiitoto/status/1714260087219659172?s=20

僕の好きな故事成語？で「水辺に馬を連れて行くことはできるが馬に水を無理やり飲ませることはできない」みたいな言葉があるのですが、これに近いです。
前節の話を関連して、以下のような図を以前考えました。

遅かれ早かれ、結局世の中の先に進んでいるフェーズの組織構造に近寄ってくる

珍しい組織形態を取っているスタートアップ企業も多いですが、特段そこに至る背景がない場合は、何だかんだ言って遅かれ早かれ、結局世の中の先に進んでいるフェーズの組織構造に近寄ってくるんだろうなと思いました。なので、なんであんな組織構造や職種を用意しているんだって斜めに構えないほうがいいですね。

具体的に考えるのが好きな人と、抽象的に考えるのが好きな人がいる

具体的に考えるのが好きな人と、抽象的に考えるのが好きな人がいるなあと思っています。それぞれの思考特性に応じて、同じことを伝えてもどのように伝わるかが違っているので、気をつけるポイントだと思っています。
以下僕の持論ですが、
抽象的に考えるのが好きな人の特性として、言われたことをそのまま受け取らない、目的やそもそも論から考える、他人からどう思われるかより自分がどうあるかを気にする、などがあります。具体的に考えるのが好きな人はその逆の傾向があり、言われたとおりに一旦解釈する、手段を模索するところから入る、自分の役職やラベリングを良くしていきたい、などがあります。
また、組織の中では抽象派の人ばかりだと皆そもそも論を提唱し始めてまとまらなくなるし、具体派ばかりだと意思決定が受け身になるので、抽象派2割、具体派8割みたいなバランスがちょうどいいんだろうなと思っていたりします。
この話は他にも、「あることをお願いするときのメリットの訴求の仕方」や「抽象派と具体派の間を取り持てる人はどんな人か」、「バズりを狙う記事のタイトルや中身の決め方は」といった議題もありキリが無くなるので一旦ここで終えておきます。

手段の目的化は悪なのか？

一般論として、手段を目的化するなとは良く言われるが、目的で考えられるのはすなわち抽象化思考とほぼ一緒であり、向き不向きがあるので目的ベースでコミュニケーションするのはスケーラビリティが担保されにくいです。場合によっては、手段の目的化自体を手段として採用することも必要で、一概に悪とは言い切れません。ただし抽象化思考の人から理解が得られないので、手段の目的化をするときにどうして手段の目的化に至ったのかを添えておくと良いのかなとも思います。

とはいえ、手段の目的化とは少し違うことで、特定の手段しか知らないor浮かばないからこの目的を果たすにはこの手段しか無いんだ、ってなるとか、手段を探している時点でおかしい、とか課題の深掘りができていない、といった類のは間違っていることが多いなと思います。
極論だけど、開発スピードを上げたいので、月のリリース数が多いエンジニア1名に報奨金を与えることにしました、みたいな手段はおかしいですね。
上記の例は極論すぎるが、当事者意識がない状態で問題解決しようとするとこういう形だけの手段を提示して、なんでみんな着いてこないんだ！ってヤキモキする人になってしまいそうなので注意したいです。

情報は伝えられるが、概念を伝えることは難しい

たとえば、バックエンドの実務経験が無いエンジニアが目の前に2名いるとして、片方は個人開発で1つWebサービスを作ったことがあり、バックエンドもAPIサーバーを格安インフラで立てている、とかだと知識量はともかく概念を掴んでいるんだな、と思うので、概念を得るための努力は割と自発的にやらないといけないことなのかなと思っています。EMとしては、こういう自学自習をやってみたら概念が身につくんじゃないかなといったアドバイスをしたり、概念から考えないといけないような話題や論点を提供することが成長機会になるのかなと思います。

根本原因は、より時系列的に前にあると考えると良い発見が得られることがある

たとえばソースレビューで大きな修正が入ることが多い、という悩みは、ソースレビューだけでなくDB設計レビューやAPI設計レビューを挟もう、という時系列的に前に何か入れる改善案で解決される可能性が高いです。
他にも、会議で何も発言できないんです、という人の場合、その場で考えがまとめられないことが課題ですってしてしまうと、頭の回転速度が上がるまで何もできないことになってしまいます。実際は、会議の前にアジェンダと想定される意見等を自分なりにまとめるのをまずは習慣づけることで、議論で初出の情報を見ることが減り、発言できる可能性が上がるのではないでしょうか。

---

まとめ

以上、ここ1年、EMを兼任していて考えたことをまとめてみました。
ずっと今の考えを変えません、といったことでもないので、EM経験のある方とかに意見を伺ったりしつつ、もしタイミングが合えば弊社に入社いただいて色々日々議論できると嬉しいです！