サマリ
- 正社員0で業務委託のみの10人程度の小さな開発チームは結構安定していい感じに運営できるみたい。
- チームが小さい間は現実的な選択肢としてありえる。
前置き
これから、僕がCTOをやっているAIトラベルという会社で、うまいことエンジニアチームを回せるようになってきたぜ！みたいなことを書くのですが、決して僕個人のエンジニアのキャリアの中でエンジニア組織をうまく回せてきたわけではありません。
いくつかの開発組織を経験して、直接僕が原因であったわけではない（と信じたい）ですが、開発チームがうまく機能しておらず、どんどん人が減っていく状態をエンジニアの立場から見てきました。そして自分に力がなく、それを改善することは出来なかった苦い思い出もあります。
そういう悲しい経験も踏まえて、エンジニアチームをどう運営していけば、小さいチームでも着実にプロダクトを育てていけるのかをいろいろ考えてきたので、少しでも参考になる部分が読んでいただけた人に共有できると嬉しいです。
そしてもっと良い方法があれば切実に教えてほしいです。
強い組織ってなんなんだろう
ビジョンに紐づくエンジニア集団に対する幻想
昔はエンジニアの採用担当として、常にビジョンに共感するソフトウェアエンジニアを探し続けていました。そして、技術力が高いソフトウェアエンジニアを求め続けました。 ただ、そんなエンジニアには出会えませんでした。（もちろんいないことは証明できないのですが。。）
そもそも考えてみると、メルカリのように、資金が潤沢でビジョンやプロダクトの方向が定まっているような会社で取るべき選択であって、資金が潤沢でなく、事業がピボットするような会社がそれを取るのはいささか無理があるやりかたなのかもと思います。
小さな組織における強い組織とは
僕たちは小さい開発組織（ソフトウェアエンジニアが10人程度)ではあるのですが、サービスにお金を払ってくださる大きなクライアントがおり、サービスを絶対に潰すことができません。でも、そんなお金がたくさんあるわけでもなく、外から見れば、他の会社に比べて魅力的なのかも正直なところ自信がありません。（いい会社なんですけどね。。）
そのような状態でもソフトウェアエンジニアを確保しつつ、プロダクトをきっちり育てていける盤石な状態を作ることが強い組織では必要という結論に至りました。
AIトラベルのアプローチ
いろいろ諦めました。
諦めたこと
- フルタイムのソフトウェアエンジニアを採用することに固執することを諦めた
- 稼働時間をきっちりトラッキングすること
諦めなかったこと（これからも諦めたくないこと）
- ソフトウェア仕様とタスクの優先度付け
- 自動テスト
- 開発者の人数をちゃんと増やしていくこと
フルタイムのソフトウェアエンジニアを採用することに固執することを諦めた
自分の周りをみていても、優秀なソフトウェアエンジニアなんてほとんど知り合いづてで転職しているので、転職市場に出てくることはケースとして少ないでしょうし、いきなり自分たちのプロダクトに惚れさせるのは結構無理があります。
（ビジネス側の人は惚れさせることができるプロダクトだと思うのですが）
でも優秀なエンジニアが欲しいとなると、副業でもなんでもいいから手伝ってもらえる人を探すのが現実的という結論に落ち着きました。 そして、そういう人たちの数を増やしていき、開発組織を安定させていく方向に倒しています。
ちなみに、AITravel はもともとはCEO 1人で開発していたソフトウェアでした。
そういう組織なので、ソフトウェアエンジニアはフルリモートOKにしていますし、今後も変えないでいこうと考えています。 現状もオンラインでのミーティングもほぼなく、Slack, チケット, プルリクによる非同期なやり取りで、ほぼ完結させています。
もちろん、それによる面倒さもリスクもあるのですが、少なくとも現状我々の文化にはあっているようで、大きな事故なく回っています。 取締役3人のうち、CEO, CTO がエンジニアであり、ソフトウェアの要件のコントロールをしているというところも結構大きいのかも。。？と思っています。
稼働時間をきっちりトラッキングすることを諦めた
そもそも、一人前のソフトウェアエンジニアが、そんなに作業をサボるのであろうか？というのがこの諦めの始まりでした。 WIPのプルリクをみれば、だいたいどれくらい進んでいるかはまぁ見えるし、ざっくりしたスケジュール感と確度だけ教えてもらえれば、経営的にはそんなに困らなかったのです。
なので、「稼働時間」のトラッキングををやめ、自己申告の時間報酬分を払う、そのかわり成果はしっかり見て、単価と見合うか定期的にウォッチしていく方針に振りました。
ソフトウェア仕様とタスクの優先度付けは諦めなかった
エンジニアの方に自由に働いてもらうために、細かい話でいうとソースコードのコンフリクトが起きにくい順番で開発を行えるようにする調整や、大きい話でいうとビジネスインパクトに対する機能の優先づけは、僕がやることになりました。
今後は、細かいところはどんどん経験値の高い業務委託の方に順次権限委譲していきたいと思っています。
自動テストは諦めなかった
いろんなレベル感の人がソースコードを触るため、テストが無いとやってられないということで、ここはちゃんとしてます。（実は、E2Eテストが30分かかるというとんでもない状況になっていて、これを解決していく話も今後書こうと思います）
今は追加でモデルのテストを書かないとそもそもCIが落ちるという仕組みを作って更に重要なビジネスロジックに絡む自動テストを強化する運用を進めています。
開発者の人数をちゃんと増やしていくことは諦めなかった
我々は明確に強く優秀なエンジニアを取りに積極的に取りに行くことを諦めました。（もちろん来ていただきたいのですが、、待ってます！） なので、きっちり組織の人数を増やして戦っていく必要があります。
ただ、現状は何故か優秀なエンジニアが結構いる組織になっています。運と縁に恵まれているのでしょうか。
このやり方で上手くいっているところ
お手伝いいただいているエンジニアの方と長く一緒にお仕事できているところです。
結局ソフトウェアの設計の知識は人に貯まるので、どういう関係性であったとしても、長期間働いていただけることがサービスの成長に重要であると考えていたので、とても感謝しています。
僕たちのやり方が、少なくとも今いるエンジニアの方にとってはマッチしているやり方なのかなぁと考えています。
おかげでそんなに急ピッチで人を増やす必要もなく、こんな小さな会社なのに開発組織として非常に安定しています。
うまくいっていないところ
改善ポイントはたくさんあれど、現状は想像以上にうまくいっていると思います。 強いて言えば、仕様やプロジェクトマネージメントのようなコントロールが全てCTOである僕になっていて、そこがボトルネックになりそうなところです。
今は、技術的なところとビジネス的なところをふわっと僕が決めて、場合によっては画面設計・データベース設計などもしてしまっているのですが、このペースでエンジニアを増やすとおそらく来年半ばにはパンクしていることが目に見えるので、こっちの職種もなんとかしないと。。というのが今の課題です。
最後に
個人的には、ビジョンで一致団結したチームみたいなものも好きなのですが、こういうやり方も一定ありだなと最近はすごく思っています。
いろいろ諦めを入れつつも、ソフトウェアエンジニアの方々がより働きやすく、その結果プロダクトが成長し大きく利益が出せるようになればいいなぁと願っているし、そうなるようにしていきたいと考えています。そして、その結果をチームに還元できる組織にしていきたいです。