CTO/エンジニアリングマネージャー 1年目の軌跡

はじめに

恋愛メタバースMemoriaを開発する株式会社Flamers CTOのだーらです！

本記事は、lainさんのVRChatワールドをリアルでいろんな年齢層に体験してもらったので展示の知見を共有したい！の記事に引き続き、Iwaken Lab.アドベントカレンダー 11日目の記事です。

Memoriaのリポジトリができて1年半、初めてのエンジニアインターンを採用してから1年2ヶ月、プロダクトもチームも成長した2023年でした。
この記事では、この1年でのマネジメント目線での学びを記します。組織規模は、シード規模のスタートアップ（エンジニアチームは1~10名）です。（逆にこれ以上大きい組織のマネージャーには当てはまらないかも？）

記事の構成について

• 独立した項目として、得た学びを列挙しました。
• 最初の方は日々の業務的な観点、中盤は技術的な観点、終盤は経営目線やヒューマンマネジメントの観点になるように並べてみました。

日々の業務的な観点から

開発背景の説明や日頃からの文脈共有を丁寧に行うこと

• その開発はどんな問題から生じて、何を実現したいのか？というissue単位での背景や、事業全体で注力したいこと、ユーザーの生の声など事業単位での文脈共有を丁寧に行います。

理由

• 背景を知ることで開発担当者がその開発内容に意義を感じ、高いモチベーションで開発することに繋がります。
• 発生している具体的な問題や達成したいことを伝えることで、実装のずれが減り、自分自身が思いついていた仕様よりも良いものが出来る可能性があります。
• 事業文脈やユーザーの課題感を分かっているので、ある程度ざっくりした指示でも質の高いアウトプットが出たり、今必要な開発を自分で定義することが出来るようになったりします。

具体的に

• 自分自身の言葉で噛み砕いて伝えることはもちろんですが、ユーザーからのアンケートの生の文面や、Slackでのメンバー同士の議論をスクショをそのまま添付することがあります。
• 特にリモートで働く副業エンジニアの場合、定常的に行われているメンバー同士の会話や、ユーザーとの距離が遠くなってしまいます。それでも意義を伝えるためには、現場にいる人が丁寧に情報を流す心がけが大切です。

実際のコミュニケーション

• issueに、以下のように画像を貼ったりしています。
  
  Slackでの仕様の議論
  
  ユーザーアンケートのスクショ
• ユーザーヒアリングの内容を全員で共有し、振り返っています。
• CS担当者用のSlackチャンネルや、ユーザーからのフィードバックが流れてくるチャンネルに入り、必要であれば開発者が直接ユーザーとやり取りしています。
• 月次ミーティングで事業全体の状況、フォーカスポイントを共有しています。

説明コストを乗り越えて、えいやっ！と思い切って渡すこと

• 「既にここまで自分が知ってしまっている。今更この知識を書き出すなどして共有し、キャッチアップしてもらうのか...大変だ。自分がやってしまうか〜」という気持ちを押し殺し、「よし！！渡すぞ！！頭の中を書き出すぞ！！」と決意を固め、渡します。
• （自分は仕事を抱え込みがちで渡すのが苦手なので、少しずつ成功体験を積み重ねています。）

理由

• まず基本的に、自分にアサインしたタスクはなぜか進みません！他のことがじゃんじゃん振ってきて、着手がなかなかできません。
• 実際に手を動かすとなると、思わぬエラー対処に時間がかかり、動作検証にも時間がかかります。意外と渡すために準備をする時間の方が短いことが分かってきました。
• また、自分が片手間でやるよりも、メンバーに意気込んで取り組んでもらったほうが良い成果が出ることも経験則として分かってきました。

具体的に

• これは決意の話なので、行動自体に特に変わったことはありません。20分くらいかけて、自分が知っていること・参考にしたこと・過去の作業ログをissueにまとめ、それを10分くらいで口頭共有します。

補足: 渡すか渡さないかを判断する基準は？

• とはいえ、全てが全てを渡すわけではなく、自分でやる場合もあります。そこはグラデーションで、本当にメンバーのキャッチアップコストの方が高くなりそうなものは自分で持ちます。いくつか判断の基準を記します。
• 「渡すメンバーが好きそうな内容か？」...ロジック的には繋がっていないようですが、自分が過去に渡すか迷った時、最後はその担当者が興味を持っているかで決めました（CIの整備や、Android移植の開発）。たぶん、興味があるからこそ良いアウトプットが出ますし、メンバーが楽しそうにしていることが自分に心理に対して良い影響を及ぼすのだと思われます。
• 「今後においてもメンテナンスするか？」...単発で終わらず、今後も改修が必要であるときは、渡した恩恵が後々に効いてきます。例えば上記のCIも今後定期的に修正が入ることが予想され、その都度自分が対応する必要がなくなります。

技術的観点から

リファクタリング: 小さなものは日頃から、大きなものは必要になったら気合いをいれて行うこと

• リファクタリングよりも機能追加の方が優先であるという考えは根底にありますが、もちろんコード品質も大切だと考えています。

具体的に

• 小さいリファクタリングは日頃から気づいた人がやる、中規模なものはそれ単体でフォーカスするのは必要に迫られたときにすれば良さそう、大規模なものは覚悟を決めて、自分も強めにコミットします。

リファクタリングの規模ごとの詳細

小さいリファクタリング

• 変数・メソッド名の修正、アクセス修飾子の見直し、古いコメントの修正や削除など。
• 日頃から、気づいた人が行うことを歓迎します。変数・メソッド名の変更をするだけでだいぶコードが読みやすくなるのでコスパ良いです。
• 汚いコードは伝播します。「あれ、あなたが0から考えたらこの命名とかロジックにならなそうですけど、たぶんここに引っ張られてますよね？」と思うことがあります。既存のコードと整合性が取れていなくても、その時点でのベストコードをコミットすることで、少しずつ全体が上書きされて品質が向上していくと思われます。

中規模なリファクタリング

• UnityのMonoBehaviour継承をやめてPure C#としてクラスを書き直す、依存をnewではなくDIから行うよう変更する、など。
• それ単体をissueとして扱うことはあまりありません。問題なく動いているのであれば、まずはUXに影響を与える機能追加系の開発の方を優先します。
• ただし、新規で開発するコードは常にその時点でベストなコードにしていきたく、既存のコードがその支障となるのであれば直していきます。
• こういったレガシーコードは、半年くらいの間に何かしらの仕様変更や他との兼ね合いによって、放っておいても自然と消えていくことが多いな、という印象です。1年くらい残り続けてたら、1年での開発力の成長を味わいながら直していくのでよさそうですね。

大規模なリファクタリング

• XRでのオブジェクトとのインタラクション基盤の総入れ替え、依存性注入ライブラリの導入（サービスロケーターパターンからDIコンテナ利用へ）など。
• 必要に迫られ、覚悟を決めて行い、担当者を二人三脚でできる限り支えます。
• このリファクタリングをしないと今後の体験が作れない、開発の負債が増大しすぎる、などの状況に直面して着手します。
• これらは非常に多くのFile Changesを生み出し、コンフリクトとの戦いとなります。
• PRを分けるように伝え、レビューも最優先に行い、担当者が膨大なタスク量に押しつぶされないように最大限のサポートを行っています。
• ビルドまで割りと時間がある段階で思い切って開発ブランチにマージし、みんなでバグを見つけながら余裕を持って直していきます（一時的に開発ブランチが不安定になることを許容する）。
  

削除しろ警察

• リファクタリングと関連して、不要となったコードを削除するように意識しています。
• 結構みんな、コメントアウトだけしてPRを出してきたりします。
  • でも、たぶんそのコメントアウトは将来いらない！消すタイミングは今しかない。今が一番分かってる！
• 自分が一番プロジェクトを把握しているので、その記述を追加したらこれが被ってて要らなくなるぞ、と思いつきやすいので、思いつく限り伝えるようにしています。

リポジトリ間を横断的に把握し、スムーズなディレクションと尻拭いを行うこと

• （前提: Memoriaでは、Unity/Web(Rails)/モバイルのリポジトリが存在します。自分が軸足を置いているのはUnityですが、全体に責任を追っていると思っています。）
• それぞれのリポジトリにおける重要な事項を理解し、横断的なコミュニケーションを支えています。また、何か問題が発生した際に、どのリポジトリであっても原因特定し、必要な指示や自分での対処が出来るような状態にしておきます。（...まだ道半ばです、頑張ります）

理由

• 結論としては、WebもUnityも知っていることで、仕様決定や緊急バグの対処がし易いです。

その詳細を言語化

• Unityアプリケーションはメインの体験を作りつつ、その外部で重要なデータはWebが管理しています。データベースはもちろんWeb側が持っているため、データ（model）を扱う系の開発はWebが主導権を持ちます。
• Unityではこういう体験制御をしたいからこういうデータがほしい、今のWebのデータベース的にはこういうAPIを作って渡したい、というそれぞれの気持ちを、両方分かって落とし込むところに自分の価値があると思っています。
• 仕様を決めるタイミングだけではなく、「Unity側の操作によってWebのデータが書き換わる時、デバッグのためにデータを書き換えないといけない」「ユーザーからの不具合報告を受けた時、Unity側がAPIを叩くところに問題があるのか？Web側がAPIを叩かれた後に問題があるのか？の原因特定を行う」など、あらゆる場面で両者を知っていることは利点として効いてきます。
• 土日や平日夜に発生する緊急バグなど、メンバーに依頼するにはブラックだと思われる事案に対処するのは経営者なのでやりやすく、その自分がいざとなったら中身を見て対処できる状態は、チーム全体の安心感であり、利益の毀損を最小限に抑えることに繋がります。

具体的に

• Unity側をメインで見つつも、Web側のPRも一定溜まったら目を通すようにしています。（本当は普段から見たいけどなかなか難しくて、1ヶ月ためて半日で見る、とかしている。）
• 特に、データベースの構造（modelの関連付け）に関する理解は重要です。あるレコードをcreate, destroyしたときに関連するmodelがどう変化するのか？メールが自動で送信されたりはしないか？などの知見は常に役立ちますので、それらに重点を置いて理解しています。
• ライブラリでデータベースを可視化してくれるものがあるので、定期的に眺めながら、キャッチアップをしています。
  

経営やヒューマンマネジメントの観点から

経営からの圧力を自分のところで吸収し、メンバーがピュアな気持ちで実装に向き合える心理状態を作ること

• 経営から判断された、期日のある重い実装のリリースプレッシャーを自分が吸収し、担当者はプレッシャーというよりも前向きな、純粋な開発を楽しめるように計らいたいと思っています。

理由

• 本来開発というのはとても楽しいものです！
• しかし、期日があってプレッシャーとなるときや、その開発をする意義への納得度合いが薄いとき、現場の大変さを分かってないじゃん！という気持ちを抱くとき、は仕事をする限りはあるかと思います。
• そういった気持ちを極力持たずに、本来のままの開発の楽しさ、健全なスケジュールへのプレッシャーを感じて動ける組織を作ることが、経営と現場両方に足を踏み入れている自分の役割かと思っています。

経営的な圧力のある開発案件の具体例

• 次の資金調達を見据えた時に、来月くらいまでにはスマホ版をリリースしたい。いけそうか？？いけてくれ。
• この会社と事業提携をした。この事業提携には長期的に意味が大きいのだけど、その代わりこの時期までにこの機能を実装しないといけない。短期的にニーズがあるわけではないのだけど、契約として必要なので実装をお願いしたい。

開発者の気持ち的にも、経営メンバーが現場に足を付けていることが働きやすさに繋がっているのではないか？と推測

• 当たり前ですが僕は、なるべく主体的に、プラスのエネルギーを持って働きたいと思っています。しかし、時に中学生のような怒りの感情を持つことがあります。例えば「あなたは指示は出すけど現場で実際に動くこっちは大変なんだよな。それ分かってるのかな？？」のような感情です。
• こういう気持ちは、経営 vs エンジニアや、ビズ vs エンジニアという構図でも生じることがあるのではないかと推測します（ただ、僕はまだこれを経験したことがありませんが）。
• 経営層かつエンジニアメンバーである僕は、経営・ビズ側から達成したいことが自分の人格と結びついていて、同時に面倒くさいことはしたくない開発者の人格としても存在しています。
• エンジニアメンバーからそのような僕を見ると「面倒なことはしたくない、この開発内容がどれだけ重いか分かっている、そしてそれが実現されなかった時に結局だーらさんが責任を担うことになると自分でも分かっているであろうだーらさん」がやると言っているのであれば、まあ頑張りますか〜という気持ちに、明確に意識をする瞬間はなくてもなってくれているのではないか？と思ったりしています。

チームメンバーが働きやすい環境を作ること

• 今年は特に、リモートメンバーが働きやすいためにはどうしたらよいのだろう？という問を考えることが定期的にありました。
• 情報共有ももちろん大切ですが、場の雰囲気（わちゃわちゃ感、静か感、などの空気）を伝えることが大事であることを感じました。
• TOKYO GAME SHOWなどのイベントごとでの現場の様子や、普段のオフィスの様子の定点カメラ配信を行い、メンバーは喜んでくれました。

定点配信カメラを作った！

TOKYO GAME SHOWでのイベント風景定点配信

オフィスでの作業風景定点配信

自分にとって心地よく話せる人でチームを固めること

• この項目は書くか迷いましたが、組織マネジメントを語るには欠かすことはできないと思い記しました。
• 「自分にとって心地よい」ことが大事です。もちろんそれが「チームにとっても」であれが組織カルチャーと自分カルチャーが合致しているので考えやすいですね。
• マネージャーとしてプロフェッショナルであろうとしても（人間関係を実装に影響させないように意識しても）、人間関係での伝えづらさや遠慮があると、コードにまで反映されることが分かりました（まあこれ以上はレビューで指摘しなくていっか、と手を引いてしまう）。

今後

• 権限委譲をどのように行っていくのか？もう少し規模が大きくなったときの自分の役割は？というのがテーマになりそうです。
• 僕の個人としてのプレイヤーレベルを上げることが設計の仕様検討やコードレビューを通してチーム全体に伝播することはずっと感じています。「言語、フレームワーク、ライブラリ」の学習を、複数の技術領域に跨って、2024年も研鑽したいです。