ついに、Hubble Advent Calender 最終日を迎えました！
毎日一緒に仕事をしている仲間でも、こうやって記事として改めてみてみると、その力強さに尊敬の念が再燃します。最後に、創業期からこのような素晴らしいエンジニアの皆様と出会う過程の中で感じた、僕の経験談を共有したいと思います！
スタートアップの一人目のエンジニアとして、とりあえずガリガリコードを書いてプロダクトを作っていくことが最優先事項である一方、やはり創業メンバーとして要求されることは多岐にわたります。少ないリソースの中で選択と集中は必須であり、何に重点を置いておくと良いか、僕個人の経験で振り返ってみました。やらなくて良い、と少し過激な発言をしましたが、やるに越したことはないが後で仲間が増えていったときに挽回できる、という意味と捉えてください。あくまでも僕個人の感想なので、事業内容や社内カルチャーによっては全く違う意見もあるとは思います。
やるべきこと
テストを書く & ドキュメントを残す
まず後続で参画してくださるエンジニアに”開発の安心感”を与えられるかが重要かと思います。テストがない、ドキュメントがない会社はそれだけで不安要素を与えてしまいます。テストやWikiの重要性はおそらくほとんどのエンジニアが理解している一方、スタートアップとして変わりゆく仕様に対して随時更新していくのは簡単なことではありません。優先度を意識して社内カルチャーとして啓蒙しておくことは大事かと思います。
リファクタの重要性をチーム内に植え付ける
これは開発というより組織的なお話です。エンジニアはリファクタリングの重要性は理解している一方、ビジネスサイドはどうしてもリファクタリングの重要性に気づきません。理解のあるビジネスサイドの方でも、エンジニアが言うから必要なんだろう。。。という程度かと思います。この辺りFindyさんの記事がわかりやすく説明されていたので、リファクタリングの重要性の啓蒙活動を行っておくことは、CTOの役目かと思います。
交通整備
仕様以外に後続エンジニアが気になる点は開発におけるルールです。リリースフローはどうなっている？修正はどこからブランチを生やして作業すれば良い？レビュー、動作確認は誰に頼めば良い？等はまとめておくと、毎回説明する手間が省けます。HubbleではNotionに誰でも何でも書いて良い文化と、修正依頼等はForm経由での依頼にしており、依頼から反映までルールを明確にして運用しています。
やらなくて良いこと(後回しでも助けてもらえる！！)
コードは汚くても良い
少し語弊を与える可能性もありますが、未来が予想しづらい初期フェーズでは、再利用可能かつメンテ性に優れたコードを書いておくのは難しいこともあると思います。もちろん綺麗なコードを書くのに越したことはないですが、逆に捉えると後続で参加してくださるエンジニアもメンテ性の高いコードを書きたいと思ってくれる人がほとんどです。（リファクタ好きは結構多い）テストをしっかりと書いておけば、リファクタも安心して取り組めるので、リファクタの重要性をチームに啓蒙し、その時間を確保しておけば、後続エンジニアが手助けしてくれます。
凝ったインフラ
CTOとして、最新技術をできるだけ取り入れて魅力のある開発組織にしたい、とは誰しもが思うでしょう。DDDをベースに、マイクロサービス、GraphQLを採用し、Rustで高速な処理を実現、、、もちろんこれが悪いと言っているわけではないですが、できるだけシンプルにすることが大切かと思います。各フレームワークのベストプラクティスに沿って、SQLを正しく記述（Paginationを入れておく、N+1を防ぐ、、）等をしておけば、昨今のPCリソースでは全然捌けます。システム構成はビジネスドメインや事業戦略とも密接に関わってくるので、小さなうちは出来るだけシンプルな状態に保っておく方が良かったりします。
レガシーすぎるスキーム（オンプレで開発、AWS EC2にmiddlewareをマニュアルでinstall して。。。）は避けたいですが、AWSやGCP等を使用されている場合はよくあるスキームをまるっとそのまま真似して。。。程度にやっておけば良いかと思います。
尖った機能
我々HubbleはSaaS事業です。過去に何度も絶対に受注したい、、この機能があれば受注できそう。みたいな案件がありました。結論から言うと、SaaS事業としては個別のカスタマイズは初期の段階では避けた方が良いです。個別にカスタマイズされた機能は、横展開ができず結果としてその後のメンテ優先度が下がり、、と上手くいかないことがほとんどだと思います。自分たちで作り出したい世界観を実現することに注力し、目先の利益にとらわれずに開発することが大事です。理解あるお客様は必ず存在します。
人事
CTOの役割は人材採用と言っても過言ではありません。ただほとんどのエンジニアが人材採用は無経験かと思います。ここで言いたいのは人事は不必要というわけではなく、人事専門の方には敵いません。スタートアップでは人事を早めに採用しろ、とはまさにこのことで、人事担当を採用すると、採用周り、労務、評価制度、組織構成、等一気に会社らしくなります。CTOとしてはまずプロダクトの力で会社を成長させ、早めに人事担当を採用することを勧めます。
まとめ
会社、組織は一人で立ち上げることはできません。仲間集めが最も重要な仕事であり、「その仲間に安心感と期待感を与え、如何に早くオンボーディングできるか」を意識しながら、誇れる組織を作っていくと良いと思います！