エンジニア組織作り、2か月目の話

はじめに

こんにちは、Flamersの設楽広太/だーらです。Flamersでは共同創業者CPOとして活動しています。
Flamersは今年（2022年）10月に、総額1億円のシードラウンドの資金調達を発表し、恋愛メタバースMemoriaを開発しています。

10月初め頃はVRのエンジニアチームは僕含めほぼ2人で個人開発に近かったものが、現在では5人のチームになりました。
この記事では、エンジニア組織作り2か月目が終わるタイミングの振り返りをまとめていきます。

※ この記事は、IwakenLabアドベントカレンダー22日目の記事です。

前提

• Flamersは創業4期目に入った会社です。創業からずっと長期インターンサイトVoilを運営しており、そちらの事業と並行してVR事業を新規事業として立ち上げようとしています。
• 僕はWebエンジニアとしての経験は数年ありますが、VR開発（Unity/C#)は新規事業がVR事業と決まってから学び始めました。また、マネージャー経験は皆無に等しいです。

記事の構成

• 「自分自身の意識編」と「実務の変化編」の2編でまとめます。
• 「自分自身の意識編」では、僕がマネージャー兼リードエンジニアとして意識していたことを列挙します。そして、現時点での達成度も書きます。
• 「実務の変化編」では、組織で何が2か月で変わったかを具体的に書きます。
• 今回の記事は、僕はこうありたいという宣言の意味合いが強いです。今できていると感じていてもできていなかったり、今後できなくなってしまったりするかもです。それでも良くて、僕がこう思っているということがチームに伝わり、今後チームに入ってくれるかもしれない人に伝わったらいいなと思い書きました。

自分自身の意識編

心理的安全性の高い組織を作る

• 達成度: 高い
• 「心理的安全性の高さ」と、後述する「情報の非対称性の低さ」は、エンジニア組織をこれから作るぞ！と意気込んだときに読んだ本エンジニアリング組織論への招待によって強く意識しました。今もしています。要約した記事を書いたのでよければどうぞ。
• メンバーが対人リスクを恐れずに行動できること（失敗の報告や質問がしやすい）、そして何より楽しく働けることから、とても大切なことだと思っています。
• 抽象度の高い目標ですが、メンバーの可能性を常に信じ続けることや、後述するもろもろの意識によって、割と実現できているかなと思っています。
• ただ、それでもまだ出会って数か月~数週間、相手の考え方、大切にしている価値観などまでわかっているわけではなく、気を使っている面は確実にあります。僕は結構人に踏み込むのは苦手なので、ここは一皮むけたいなぁと思っています🔥

チームに起きる問題は全て、自分の責任である

• 達成度: 高い。（その意識は過去の自分と比べて相対的に高い）
• どんなバグが入っても、タスクの停滞が起こっても、情報の共有不足が起こっても、全て自分に責任があると思っています。この意識を持っていると、自然とメンバーに対して負の感情を持つことが少なくなるなと思いました。
• 全ては自分の責任だと思うことと、その問題の解消を全て自分が引き受けるということは別だというのはありますが、そこはまだ自分は不器用かなと感じています。やや仕事量を抱え込んで、手が回らない瞬間が生じてしまっているので、任せ方などはもっと考えていかなければと思っています。
• 少し似た考えですが、「チームで起こる問題は全て、個人の責任ではなくチームの仕組みの責任である」というのも意識しています。
• この意識も、個人を攻撃をすることを避け、問題に対してチームとして向き合い、再発防止を考える意識に繋がってよいと思っています。
• 例えば、デバッグが不十分でバグがマージされたとき、その開発者がだれであっても、その人は責めません。その人とレビュワーが気づけなかったのは、どんなレビューフローの問題があるのか、あるいはソースコードがバグが潜みやすい設計になっていないか、ということに考えを巡らせるように意識をしています。

チームが働きやすい環境を作ることが、経営者としての責務である

• 達成度: まずまず。意識としては高いが、満足にはできてない感。
• 物理的な仕事環境の準備や、ドキュメントの場所の準備、組織の在り方の提示など、メンバーが働きやすい環境を作ることは自分たち経営者の責任だと思っています。
• オフィスのレイアウト変更や備品の購入などは積極的に動いて、人を出迎える準備をしました。
• 一方、組織の在り方の言語化など、Valueのような面はちゃんと取り組めていません。会社のValueはありますが、エンジニア組織に照らし合わせたとき、毎週レベルで「この指針に沿っててgood！」と判断できるような具体的なものとしてはまだ落とし込めていません。僕自身がエンジニア組織・普通の会社に務めた経験が浅いので、実体験を以て落とし込まれた何かをまねることができていないことは要因としてありそうかもです。
• ここは、周りの他の会社のこととかもきいて考えていきたい。

自分の限界が、チームの限界になってはならない

• 達成度: 中
• これは判断が難しい。意識はそれなりにはしています。
• これに陥るのは、僕がマイクロマネジメントをするときだ、というところまで理解しています。任せるタスクの抽象度がとても低い状態や、開発の要件のみならず設計の仕様まで僕が詰めてしまうと、ただでさえ現時点では高くない僕の能力がチームのキャップになってしまいます。
• 抽象度がある程度高いタスクを任せていきたい、というのは意識をしていますが、まだ成功体験は数個しかないかな。
• 抽象度がある程度高いタスクを任せるために、あるいはメンバーから開発事項がぽんぽん出てくるためには情報の非対称性の解消が大事だと思っているので、まずはそこ頑張りたいです。

情報の非対称性をなくす

• 達成度: 初期は低、今は中？
• この項目も、エンジニアリング組織論への招待を読んで意識した内容です。情報に非対称性がなければ、仕事が詰まることなくスムーズに進めやすいことや、同じ意思決定になりやすいこと、やりがいをもって働けること、などがそのメリットかと思っています。
• この点は、当初の僕の達成度合いの認識と、実際のメンバーの感覚のギャップが大きかったところだと思っています。
• 確かに、創業から会社にいて、事業もほんとに0→0.1の立ち上げからずっと文脈を把握し、資金調達のプレゼンにも一緒に臨んで、毎週事業全体の週次MTGに参加している僕と、その後から参加したメンバーでは持っている情報が全然違うよな、と当たり前のことに気づきました。
• そして、そのストックされた情報だけではなく、毎日生み出されるフローの情報も、ちゃんと共有できる体制を整えなければ共有されることはありません。そんな当たり前のことにも気づきました。
• 対応として、MTG内容のこまめな議事録化を行い、エンジニアチームの週次MTGで僕から口頭で共有するようにしています。
• おそらく他にもやるべきことがあるんだろうなとは思っていますがまだ見えてないので、ここも他社を参考にしていきたいなぁと思っているところです。

差分で勝負しろ

• 達成度: 中
• 10月時点では生まれたてのチームだったので、エンジニアチームにはあらゆるものが足りませんでした。そこに入ってきてくれるエンジニアの方は恐らく、まず無いものに目が向くのが自然だと思います。
• そんな状況でも、この組織で働くことに各人が可能性を感じてもらうためには、この組織の成長の差分が大切だと意識していました。「これだけ早く何かを取り入れるなら、組織のレベルも上がりそうだし、自分の提案も流さず向き合ってくれそうだな」と思ってもらいたいと考えていました。そして、取り入れるだけではなく運用を定着させることも重要でした。
• 具体的には、Notionの導入、PRテンプレートの作成、提案された開発ツールの導入、設計パターンの導入、各種備品の購入、ビルドマシンの購入などです。
• また、今すぐには時間や必要性の検討が必要などの理由から導入できないものも、Notionのやりたいことリストに言語化し、Slackやちょっとしたつぶやきが流れないようにしました。

自分自身の実力の上昇が、チームの実力の上昇にクリティカルに効く

• 達成度: 高（絶対値ではなく、差分は高いと自分で思っているという意味です）
• チームメンバーが増えても、なんだかんだ僕の実力は、直近1年2年は重要だと思っています。
• それは、僕が開発に直接関わることが事業的にも大事だと思っているからです。
• プロダクトでこういう機能が作りたいということは特に創業メンバー中心にチームみんなで考え、そちらビジネスサイドから出てきた機能を、ちゃんと工数や実装順を考えて開発フローに乗せることは、一番自分が持つべき & 持ちたいと思っています。その時に、やっぱり手元の実装に関わっていない状態で判断することは、僕にはまだまだ難しいです（まだまだというのは、僕の技術者としてのレベルが上がればその経験から判断できそうですが、今はまだカスなので経験値を積むしかない）。
• そしてそれは個人的にはとても楽しくて馬力が出るので、結果チームにとっても良い影響を及ぼすと思っています。なので、純粋な技術力向上はとても頑張りたいところです。

実務での変化編

• 「自分自身の意識編」は割と僕がどう考え実行したか、という話でしたが、以下はチームから出たアイデアを、チームとして導入した、という話です。

スプリント導入

• スクラムガイドを読み、2週間スプリントを回すチームになりました。
• イベントを下記の通り実施しています。
  • 週の初めのスプリントプランニング: その2週間で取り組むタスクを決め、割り振ります。
  • 毎日のデイリースクラム: 朝、5分~10分ほど。その日のタスクの共有や、困っていることの共有など
  • 1週目終わり時点の中間振り返り: メンバーを褒める時間を設けることと、スプリント途中での変化への対応をします。
  • プロダクトチェック（スプリントレビューと呼ばれるやつ）: そのスプリントを終えてできるビルドファイルの、コンテンツチェックを全員で行います。
  • 2週を終えての振り返り: メンバーを褒めること、チームとして良かったこと・改善すべきこと・具体的な改善案、を話し合います。

タスク管理

• Notionを導入し、カンバン管理をしています。
• Issueはテンプレートを用意し、ゴールの明確化や、Issue同士の依存関係の整理などをしています。

PRをしっかり出す

• Pull Requestもテンプレートを作成しました。ちゃんと書くようにしています。
• また、PRごとに（必要であれば）動作チェックリストを作っています。
• このチェックリストは、スプリント終わりのプロダクトチェック時点での最終チェックリストに加わります。

設計の意識

• コードは昔より（当たり前ですが）改善され始めています。
• UniRxを使ったMV(R)Pパターンなども最近導入しました。設計の本を読み込み、意識を高めています。要約しましたので良ければ→ 「良いコード/悪いコードで学ぶ設計入門」を読む
• クラス図を書き、分かりやすく伝える、なども意識するようになりました。

まとめ

• メンバーを信じること、を大切に、良いチームを作っていきたいです。