支払い.com で主にバックエンド全般を担当しているエンジニアの水村です。
支払い.comのエンジニア組織はまだまだ整備中で課題も多く、カオスな状況です。そんなカオスな状況を改善するため、やらないようにしていることや、意識的にやっていることなどをまとめました。
支払.com のサービスについては、支払い.comのサイトをご覧いただけるとめちゃくちゃ嬉しいです。（https://shi-harai.com/）
TL;DR
- 我々がやらないようにしていること
- 意識的にやっていること
- 開発フロー
- エンジニア紹介
やらないようにしていること
いきなり話がブッ飛びますが、エンジニア組織でやらないと決めていることは次の通りです。また、いくつかの項目については詳細を記載しました。
アジャイル開発やスクラム開発をベースに開発を行っているのですが、デイリースクラムやスプリントなど、検討した結果採用していない手法もあります。
- エンジニア抜きでの意思決定
- スプリント
- 無駄な会議
- デイリースクラム的な毎日のミーティング、稼働の管理
- 過剰なタスクの管理
- 休日、深夜の Slack メンションや DM を遠慮して控えること
- Slack DM によるコミュニケーション
- ダメな物事を無視する行為
- 偉そうにすること
- 聖域を作ること
- 働きすぎること
エンジニア抜きで意思決定をしない
エンジニアが意思決定に大きな裁量と権限を持っているので、基本的に意思決定にはエンジニアが関与します。
エンジニアが意思決定に大きな裁量と権限を持っているのは、カード側の事業も同じです。支払い.com事業でも同様に、ビジネスサイドの偉い人がこういったからそれに従う、といったような組織ではありません。
よって、エンジニアには自立的に動いて意思決定をすることが求められます。言い方を変えると、自走力のあるメンバーであれば、正社員でなくとも一定以上の権限と裁量を持って取り組むことができる環境です。
むしろ、このように大きな権限と裁量を持っているフリーランスや副業のエンジニアが多いのがUPSIDERという会社の特徴の一つです。
スプリントをやらない
フルリモート、フルフレックス、コアタイムなし、稼働時間に制限がなくバラバラ、副業が多いという環境であるからこそ、スプリントを採用することが難しいので採用していません。
スプリントを採用した場合、毎週リリースしなければいけないというプレッシャーから、品質がおろそかになったり、テストがおざなりになって本番障害につながるというリスクがあると思っています。
微妙な状態でリリースするのかどうかという判断を毎回するのも面倒ですし、バグがある状態でリリースブランチにマージされていると revert するのも面倒ですし、とにかく面倒なことが多いわけです。
リリース対象が増えれば増えるほどリリースに対する負荷が高くなり、テスト対象が増え、影響範囲も大きくなるので、細かくテストして細かくリリースできた方が高い品質を維持できるという認識からスプリントを採用していません。
ですが、スプリントを採用することによって開発サイクルにリズムが生まれて開発がやりやすくなるというメリットがあることも認識しているので、スプリントで開発することが最適だと思ったら採用すると思います。
無駄な会議、デイリースクラム的な毎日のミーティング、稼働の管理
会議などにより必要以上に時間を拘束することは、エンジニアという職種の特性上、業務に支障がでることが多いので、無駄な会議を行わないようにしています。
必要に応じて会議は設定していますが、副業でジョインしているメンバーが多いためデイリースクラムを行うことは実質不可能です。働く時間帯がメンバーそれぞれ異なるため、作業を開始するときに Slack で「稼働開始、終了」といった報告も不要としています。
各々のエンジニアの稼働については、性善説に基づいています。不正をしたところで github のコントリビュートが少なければわかりますし、その人が働いているかどうかは、一緒に働いていれば大体わかります。
ただ、デイリースクラムができないことにより、日々のコミュニケーションが少なくなってしまうことや、エンジニア同士の関係性を築くことが難しくなってしまうと思っています。
そのために、エンジニア同士が会話をしやすいような雰囲気づくりを心がけたり、ちょっとした雑談をするような任意参加のミーティングを設けたりするといった施策もおこなっています。
休日、深夜の Slack メンションや DM を遠慮しない
休日、深夜の Slack メンションなどは基本的に気を遣う必要はないというスタンスです。
理由は以下の通りで、どうしても今すぐに反応してほしい緊急事態の場合は電話をする運用になりました。
- 非同期コミュニケーション前提なので、後で返事すれば問題ない
- 通知は各自でオフにできるので休日、深夜はオフにしても問題ない
また、Slack DM に関してはあまり使用を推奨していません。会社的にもオープンなコミュニケーションを行うようにしたいという考えがあるので、基本的に Slack チャンネルでの発言を推奨しています。
ダメな物事を無視しない
ダメな物事を無視していると、割れ窓理論的に秩序が保たれなくなり、優秀な人がいなくなるので、なるべく早く手を打つように心がけています。
ですが、ある程度放置しても問題なさそうなことに関してはあえて放置して、成り行きに任せるケースもあるので、その辺りの見極めが必要だなと思っております。また、問題によっては「この問題は放置しても問題ないよね」という合意が必要だと思うので、事前に合意するという運用が必要になってくると考えています。今のところまだそのケースは発生していないですが、人が増えてくると必要になりそうかなという認識でいます。
偉そうにしない
まず、UPSIDERでは偉い人という概念がありません。基本的に全員フラットで役割の違いがあるという状態を目指しています。
「Tomo さん（弊社代表の水野）が言っているから正しい」というようなことはなく、間違っていると思ったら反対意見を言います。関係性としてはフラットですが、お互いへのリスペクトや礼節はある、という組織です。
あとは、パフォーマンスや日々の行動によって、自然発生的にリーダーやマネージャー的なポジションが決まっていっていくような感じです。実際、僕はリーダーをやってくださいと任されたわけではないですが、自然とそうなっています。もっとイケてるリーダーは他にたくさんいると思うので、いつでも代わってもらえるように環境を整備中です！
聖域を作らない、働きすぎない
これらの施策はまだ取り組み中ですが、目指している課題でもあります。
主体性と属人化、コードオーナーと責任感は、複雑に絡み合って切り離すのが難しいと個人的には考えています。ですが、同時にその人にしか作業できない聖域を作ってしまうので、共有したい業務の仕様を少しずつ切り出して他の人にやってもらったり、モブプロを行って他の人に仕様を共有する、ドキュメントを整備するなどで対応していっている最中です。
働きすぎない、というのは文字通り働きすぎないようにすることです。仕事の Slack を昼夜休日問わず見続けたり、仕事が無限にあるからといって毎日遅くまで働くと脳がおかしくなるので、働かない時間を意図的に設けています。スタートアップではこれがかなり難しくなってしまう傾向があるので、意識的にやる必要がある認識です。
意識的にやっていること
エンジニア組織で意識的にやっていることを次に記載しました。
- 小さく頻繁にリリースする
- リファクタリングを頻繁に行う
- 技術負債を早めに解消する
- コミュニケーションしやすい環境づくりをする
- ジョインした人がミスマッチだった場合はすぐに対応する
小さく頻繁にリリースする
支払い.comでは早く作って早くリリースすることを心がけています。
リリースサイクルは特に定めていないので、機能が出来上がってテストが完了したら、すぐにリリースすることが多いです。簡単な修正や小さな機能は、すぐにテストが完了することも多いので、週に数回リリースすることも割とあります。スプリントを採用していないのでリリースまでの待ち時間（リードタイム）がほぼ存在しません。全体に関わる影響が大きい機能に関してはリリースタイミングの調整が必要になるので、もちろんそのようなケースではリリース時期を調整することはあります。
リファクタリングを頻繁に行う
細かいリファクタリングを頻繁に行うようにしています。
放っておくと負債はどんどん積み上がっていってしまい、品質を維持できなくなり、かつ素早くリリースすることが困難になるためです。というよりも、エンジニアが自発的にリファクタリングを行なって、コードベースをきれいな状態に保っているので、気がついたらなんかコードベースが綺麗になっていてありがたいという感じです。
もしかしたら AI が勝手にコードを綺麗にしているのかもしれません。
技術負債を早めに解消する
大きめな技術負債は早めに解消するように心がけています。
ローンチ当初は Nuxt.js とAnt Design という UI ライブラリを採用して画面を開発していたのですが、Nuxt.js が2系で Ant Design のレイアウト制約などがきつくて両方とも技術負債になってしまいました。
そこで、Nuxt.js と Ant Design をやめるという判断をローンチから3ヶ月ほど経過した際に行い、1ヶ月ほどかけて Nuxt.js をやめて、 Next.js にリプレイスを行いました。機能がまだそれほど多くなかったので、約1ヶ月という短期間でリプレイスは完了し、かつReact に強い優秀なエンジニアが何名かジョインしてくれたので、Next.js にリプレイスしてよかったと思っています。Ant Design をやめてからは、基本的に UI ライブラリは使用せず、必要に応じて小さなライブラリを導入するようにしています。管理系の画面は Nuxt.js のままなので、こちらもそのうちリプレイスするか、Nuxt.js の3系にバージョンアップしたいところです。
コミュニケーションしやすい環境づくり
フルリモート、フルフレックス、コアタイムなし、働く時間も自由という環境は、とても自由度が高く働きやすい環境ではあるのですが、コミュニケーションが希薄になってしまい、チームの一員として動くことに障壁が存在します。
僕自身も多くのメンバーとリアルで会ったことがありません。よって、コミュニケーションをしやすくするための施策として、定期的に雑談をする任意参加のカジュアルなミーティングを設定しました。
English-speaker が何名かいるので、基本的には英語で話すことを推奨しています。また、英語が苦手な人でも話しやすいような雰囲気づくりを心がけたり、仕事の話だけではなく、お互いのプライベートな話や最近の出来事などを英語で話すようにしています。こうすることによって、仕事のちょっとした相談などをしやすくしたり、ミーティングの場でも話しやすい環境づくりにつながればと思っています。
このような施策以外にも、例えば新しくジョインした人に対しては、毎日軽く話すような軽めのミーティングを設定することも考えています。さらに、UPSIDER 全体の施策としては、毎週木曜日 WeWork にエンジニアが集まってカジュアルに話す WeWork day というのを設けていますので、もし UPSIDER のエンジニアとちょっと話してみたい方がいらっしゃいましたら、是非ご連絡ください。いつでもウェルカムです。
ジョインした人がミスマッチだった場合はすぐに対応する
正直なところ、面談をしただけでは判断できないことが多く、一緒に働いてみないとわからないことが多いです。
一緒に働いていると、成果物が出るまでの早さや適切なタイミングでのコミュニケーション、コードの品質など、いろいろとわかってくることが多いので、そこで初めてちゃんと評価ができる認識でいます。もちろん、面談時に判断できることも一定あるので、面談の際にはあらかじめ決めた質問をして、人によって面談の内容にばらつきが出ないように標準化して面談をするようにしています。
ミスマッチが発生した場合は早めに手を打つようにしており、こちら側で改善が可能なことに関しては改善し、相手に改善が必要だと思ったことは率直に伝えるようにしています。結果はどうあれ、なるべく早く対策を打つことが、お互いにとってポジティブであると考えています。
開発のフローについて
特にこれといって変わったことをやっているわけではなく、一般的な開発フローです。
git のブランチ構成は develop, main ブランチと各機能単位のブランチを作成する一般的な構成です。タスクの管理は主に github project を issue で管理しており、Epic issue を作成し Epic issue の中に各種 sub task の issue を作成して追記するようにしています。Epic issue のサンプルは次のような記載です。English-speaker のエンジニアがいるため、基本的に全て英語で Issue を記述するようにしていますが、限定的に日本語で書いても OK としています。
開発のフローは notion に定義し、どのような流れで機能を開発するのか、意思決定の基準は何かなどを記載しています。ただ、一般的な開発の流れだと思うので、普通のエンジニアであれば迷うことなく開発が進められる認識です。
エンジニア紹介
支払い.comで活躍しているエンジニアの特徴を紹介します。
- 素早く機能を作り上げること
- コードの品質が高くバグが少ないこと
- 自立性があること
- 重要な部分に関してはきちんと相談ができており、その判断を間違えることがない
- 相談の必要ない部分に関しては自分で判断して機能を作る
これだけ書くとものすごく仕事ができて、人間的にも非常に優れているように思うかもしれません。ですが、実際のところ、新しいゲームが発売されると気配が消えるエンジニアもいますし、部屋がめちゃくちゃ汚かったり、そもそも机と椅子がない状態でベッドの上働いているエンジニアもいたりします。
また、学歴がとても良いというわけではなく、僕は IT 系の専門学校卒（日本電子専門学校という素晴らしい専門学校です）ですし、新しいゲームが発売されると気配が消えてしまうエンジニアも同じ専門卒です。高卒のエンジニアもめちゃくちゃ活躍してますので、学歴はぶっちゃけ関係ないなって感じです。
エンジニアとして濃い経験をしているメンバーが多いので、自走力やタフネスなど、それぞれがそれぞれの強みを持ったチームだと自負しています。ブラック企業で叩き上げられたエンジニアが多いので、とにかくタフネスが違います。
このように、非常に優秀だけどどこか欠点がある（？）エンジニアに支えられています。
支払い.comのエンジニアを何名かピックアップして簡単にご紹介します。エンジニアの多くが30代であり、経験豊富なメンバーが多く、ほぼ全員がフリーランスです。とてもいい人が多いので大変助かっておりますし、みんな優秀で自律的にいろいろと動いて取り組めるタイプです。
フロントエンド
- Oさん
- フロントエンドの全般を担当
- とにかく実装がめちゃくちゃ早くてクオリティも高いし、レスポンスも早い
- 副業で週2-3日の稼働だが、夜に働いていると思って翌朝に気づいたらフロントエンドの機能がほぼ出来上がっているので妖精かもしれない
- Oさんが連れてきたOさん
- 副業でジョイン（週1ぐらいの稼働）
- 実装が早くバグが少なくて最高
- Slack のアイコンが猫
- Mさん
- 副業でジョイン（週1の稼働だがおそらく週2〜ぐらい稼働している）
- タスクをお願いして気づいたら終わっている
- OpenAPI のスキーマ分割をお願いしたら、なんか知らんけどいつの間にか終わっていた
- 僕の友達のOさん
- 別プロジェクトで Go をメインに書いているが、 React の経験豊富なのでジョインしていただいた
- 今は稼働少なめだが、能力はめちゃ高いので将来的にいろいろやってもらえそうな感じ
バックエンド
- 僕
- バックエンド全般を担当していたが人が増えたので最近はマネジメントを担当
- エンジニアとビジネスサイドが協調して働ける環境整備をおこなっている
- 最近ジョインした English-speaker のエンジニアと3歳児並みの英語力で週に2-3回打ち合わせをしている（大変ご迷惑をおかけしています。。）
- Aさん
- もう一人のOさん
- 別の会社で正社員をやりながら副業で支払い.comを手伝っていただいている（週1ぐらいの稼働）
- バックエンドを主に担当していただいているが、僕からの無茶振りで管理画面（Nuxt.js）も作成していただいており、積極的にいろいろ手を動かしていただいている
- 医療系の業界からエンジニアに転身してエンジニアのキャリアはまだ浅いがすごくしっかりしている
- Vさん
- Hさん
- Yさん
- バックエンド全般を担当
- 最も複雑な支払い登録周りの処理を素早くキャッチアップしていただいている
- 支払い.comのエンジニアチームの中では数少ない英語がちゃんと話せる日本人エンジニア（余談ですが、僕の英語レベルはだいたい3歳児並みで、週に2〜3回 English-speaker なエンジニアとミーティングをしています）
- 来年ごろカナダに移住する予定
- カナダはビザを取るのがそんなに難しくないらしい
- カナダには雄大な自然がある
あとがき
エンジニアが働きやすい環境を作るためには、チームみんなの協力が不可欠なのですが、いろいろな改善案などを提案してくれたり、みんなに協力してもらってめちゃくちゃ助かっています。
まだまだ改善中でカオスなエンジニア組織ですが、みんなが働きやすい環境になるように、これからも継続して改善していきたいと思っています！
最後までお読みくださり、ありがとうございました。UPSIDER はエンジニアやプロジェクトマネージャー、プロダクトマネージャーなど幅広く募集中ですので、もしご興味がありましたら、ぜひ一度カジュアルにお話しましょう！
