海外エンジニア比率8割の製品開発のリアル
リチカ、CTOの内田と申します。
リチカアドベントカレンダー23日目で、多国籍エンジニア x フルリモートの製品開発というテーマで、エンジニアチームと製品開発の普段の様子について共有させていただきます！
エンジニアチームの普段の様子
普段のコミュニケーションは、Slack、Backlogを中心として英語でやりとりしており、アジア4割、ロシア4割、日本人2割となっており、エンジニアは計15人になりました。
研究系も含めて大小さまざまですが、現在走っているプロジェクトは10近くに増え、一人でいくつかのプロダクトを兼任しているメンバもいます。
ユーザ数の多い、進化の速いプロダクトでは、エンジニアは約4名くらいで開発しています。
一番最初にRICHKAを一人で開発していた頃から既にリモートワークであり、現在もエンジニアのほとんどがリモートワークで、国外エンジニアも現地で開発しています。
新型コロナの影響でリモートワークの難しさが話題になっていますが、コロナ発生前後で開発スピード・スタイルに変化は全く無いです。
コミュニケーションで気をつけていることは、リモートワークは相手の表情や様子がほとんど見えない状況になるので、みんなお互いに、これから何を開発して、どういった課題で困っているか、Slackのコミュニケーションを全員で活発にするように意識しています。
MTGについては、テキストだけでは伝えにくい相談をたまにスポット的にオンラインMTGで行いますが、当初からこれまで4年ほどエンジニアメンバで定例MTGに相当するものは一度も行ったことがないです。
その理由は、普段からSlackやBacklog上で議論が活発なので、定例MTGをやるとしてもそもそもアジェンダが無い状態です。
議論の場を定例MTGに依存し過ぎると、その開催タイミングを待つメンバが出てきて、むしろ課題が複雑化したり開発スピードを落とすボトルネックにもなると思っています。
どうやって普段マネージメントしているか色々な方からよく質問を受けるのですが、マイクロマネージメントは一切せずに、ジョインしたら実地で2,3ヶ月ほど現場で実際に開発してもらい、その様子から我々チームの一員として戦力になるかどうか、スキルレベルとコミュニケーション力をかなり厳しく見極めています。
その見極めをパスする基準としては、マイクロマネージメントしなくても自己管理しながら、与えられた開発タスクを一人で完遂できる強い個人かどうか見ています。
スタートアップで絶え間なく進化続けるプロダクト開発を支えるもの
世界標準のデファクトスタンダードの技術を選定する
我々のWebアプリ開発では、サーバアプリフレームワークとしてDjangoを使っています。
世界の優秀なエンジニアにアプローチしようと最初から思っていたので、日本人エンジニアくらいしか得意としないRailsやPHPは最初から一切使わずに、世界標準のデファクトスタンダードの技術しか選定しないようにしてきました。
RICHKA開発をスタートした2017年は、Machine Learningの3次ブーム起きて数年経った頃で、そのブームに関連して新しく出てくる有用なOSSライブラリもPythonが多かったので、我々プロダクトに資産として活用しやすいようにPythonベースのDjangoを選びました。
この世界標準のトレンドに乗れると我々の活用可能なOSS資産の幅を広げることができ、プロダクト開発を更にスピードアップできるようになります。
よって、PythonやDjangoが得意だから、開発しやすいからという基準だけで選んだのではなく、今後数年先のOSS資産の増加量を見据えた上で選びました。
もしPythonの人気が落ちて、OSSコミュニティの大部分が別のプログラミング言語に移行した場合には、我々も躊躇なくそちらに移行していきます。
また、インターネットの情報源を言語で絞ってはもったいないので、インターネットで検索するときは最初から英語のWebサイトを中心に探した方が良いです。
特に難易度の高い課題を解決するには、世界の優秀なエンジニアの発信している情報くらいしか役に立たなくなってきます。
我々のエンジニアメンバは当然英語のドキュメントであっても問題なく読めるので、インターネットに取りにいく情報リソースも、スコープは最初から世界になります。
良い意味での暴れ馬を入れる
同じ国籍、スキルセット、バックグラウンドで揃えればマネージメントしやすいですが、刺激をお互いに受ける機会に溢れる、開発していて面白いチームになるかというと、そうではないと思います。
また、スタートアップのようにプロダクトの進化が激しいと、当初想定していなかった新しい難問が次から次へと出てくるので、自分の得意とする技術や過去にうまくいった方法だけでは足りないケースが時々おとずれます。
インターネットでどんなに調べても解決策が１つも見つからない難問にこれまで幾度も遭遇してきましたが、こういったケースを突破するには、チームとしての多様性、特に多少危険なウルトラCを躊躇なく繰り出してくる良い意味での暴れ馬が一定割合必要で、我々エンジニアチームにもそういったメンバが数名います。
RICHKAは、他社とは比較できないほどの表現力に富んだ動画クリエイティブを生成する動画サーバを独自開発していますが、複数ユーザが同時に安定して動画生成可能にするのが非常に難しく、どんなにインターネットで調査しても同じことで悩んでいる会社、エンジニアは皆無でした。
しかし、我々の多国籍 & 多様性に富んだチームは、普通の慎重な日本の会社だったら考えもしないであろうウルトラCを考案して製品適用し、現在の主要プロダクトの土台として支え続けています。
多少のやけどを覚悟して何よりも市場への投入速度を最大化させる
目の前のバグ修正が今本当に必要かどうか、発生確率と致命度合いを掛け算して考えています。
致命度レベル 中 x 発生確率 5% であれば、2、3日程度はユーザはそのバグを踏まないだろうと期待できるので、市場への投入速度をとってリリースに踏み切ります。
そして3日以内にHotfixリリースすれば、結果的には市場への投入速度がMAXになります。
その修正スピードを支える技術力は当然必須ですが、こういう判断でも我々チームの多様性が生きています。
もし品質を過度に重視し過ぎる気質のチームであれば、このやり方は危険だから辞めた方が良いと止めに入るメンバが数名出てくるのが普通でして、スタートアップらしいリリース速度を出すのは難しくなってしまいます。ここまでリクスを犯してまで攻める会社は他になかなか無いだろうと思います。
自分の前職では、プロダクトのカテゴリ的に品質を重視せざるを得なかったですが、そういった過去で培ってきた正攻法だけに拘らず、むしろスタートアップらしく、プロダクトのミッションクリティカルと我々チームの特性を鑑みて、こうして市場投入速度を最大化する方法を選んできました。
我々のエンジニアチームであれば技術的負債は酒の肴にしかならない
スタートアップは市場へ投入してユーザからフィードバックを得て改良するサイクルの速度を重視するため、現状のプロダクトのGUI画面、サーバサイドのアーキテクチャの賞味期限は非常に短いです。
ユーザの増加速度にも依存しますが、v1.0で実装したアーキテクチャの使用期限は半年も持たない印象があります。
絶え間なく続く新機能開発と平行してユーザ増加数に応じて負荷分散の仕組みも刻々と改良していくので、1年くらい経つと初期の頃に実装したコードの半分以上が別コードに置き換わっているような気がします。
初期の頃に実装したイケてないコードとも付き合い続けて、ユーザ数増加に耐えうるシステムに進化させなければならないので、当然巷で言うところの技術的負債はスタートアップだと多く生まれやすいです。
しかし、我々チームではこの技術的負債に対してはほとんど不平不満は出ずに、どうやったら解消できるか、前向きな議論しか生まれない文化を持っていると感じます。
後ろを見ても失敗しか無いスタートアップなので、そういったお互いを咎めるような発言が出てきたら止めるつもりですが、そういった後向きの生産性の無い議論に時間を費やしたことはほとんど記憶に無いです。
これはあくまでも自分の想像に過ぎないですが、このチームの文化の背景に、そういった過去の技術的負債にくよくよしない国民性を持った国外エンジニアの比率が高いところからも来ているような気がします。
またアジア、ロシアにとっても英語は第2外国語なので、不平不満を漏らすに必要な英語のフレーズにあまり馴染みがないことも関係しているかもしれません。
どういった因果関係であれ、技術的負債や過去の失敗にくよくよしないチーム文化は、スタートアップに適していると思います。
ユーザや製品価値に直接影響が無く、その技術的負債にも余裕を持って付き合い続けられるスキルと懐の深さがあれば、我々にとっては技術的負債というよりも過去の足跡に過ぎず、酒の肴にしかならなさそうです。
We are Hiring!!!
私が所属するプロダクトを始め、リチカは絶賛採用中です！
下記にリチカの情報についてまとめております。
少しでもご興味をお持ちいただいた方は、ぜひご連絡ください。
■採用情報
採用サイトはこちら
最近Meetyも始めました。よかったらお気軽にお話しましょう！
プロダクト以外のポジションも積極採用しています。 リチカについてもっと知りたい方と思っていただいた方がいらっしゃれば、ぜひ以下もご覧ください。
この記事が気に入ったらサポートをしてみませんか？