見出し画像

おかしいくらいの速度でマルチプロダクトを作るときに、エンジニアががんばってること #UPSIDER春のTech祭り

前回までのお話

業務システムを、チャットインターフェースで作り直すとマジでカオスだけど楽しい!」と題して、UPSIDER の機能をAIを駆使してチャット上で開発する面白さと大変さについてお話しました。(まだご覧になってない方はぜひチェックを!)


はじめに

はじめまして!UPSIDERの新規機能開発を担当するPioneer チームでエンジニアをしていますRyoto(@ryoto_kubo)と、Takuyaです。

今回は、“テックカンパニー UPSIDER”の挑戦と面白さからUPSIDERがどのような開発体制でプロダクトラインナップを拡充していこうとしているのかをより深掘ってお話しします。

記事の中では、プロダクトを高速で作ってリリースしていくために大切にしていることや、あえて一定の犠牲はあるよねという共通認識を持ちながら進めていること、どのようなコミュニケーションを行いながら開発を進めているのかを書いています。少しでも面白そうだなと思ってくれたらぜひ最後まで読んでいただけると嬉しいです!

では早速、プロダクトを高速で作っていくために大切にしていることからお話ししたいと思います!プロダクト開発は良い日ばかりではなく、雨が降る日もあれば時には槍が降る日もありますよね?それでも僕達は全力で走っていきます!

傘をさしても吹き飛んでしまうほど全速力で走る

UPSIDERの挑戦を成功させるためには、僕らエンジニアは新規プロダクトを高速で作っていく必要があり、まさに今その最中です。
その上で僕らのポリシーとして重要な指針がありまして、それは「新規プロダクトは品質よりもアウトプットを出すスピードを重視する」というものです。理由はいくつかありますが、代表的なものは下記でしょうか。

  • 結局リリースできないと顧客にとって価値のあるものを作っているかは確かめることすらできない

  • 成果物が出てこないと、PdMがレビューしづらく、顧客の意見を聞きに行けない

  • プロダクトの検証を進めていくと、過去に考え抜いた最適な設計が、割と早い段階で崩れることがあるが、崩れるなら早いほうが良い

  • 細かくリリースしないと、リリースの単位が大きくなり、逆にリリースのハードルが上がってスケジュールを立てづらくなる

そのため、多少考慮が不足した設計だったり、TODOを残しながらでも、とりあえずわかりやすいアウトプットを高速で提供し続けることを優先しています。
また、結構大事なポイントだと思っているのは、そのポリシーをPdM含めたチームメンバー全体で強く共感しておくことです。手戻りは絶対に発生するという前提のもと開発を進めているわけなので、どこかの時点でそれを改修する必要があるというのはチーム全体で覚悟を決めつつチャレンジしています。

これは主題とはあまり関係がないのですが、実際に新規プロダクト開発を始めて改めて痛感したことを紹介しますと、自社のサービスを動かす上で必要なコンポーネントを、最低限薄く広く理解しておくことが重要であるという気づきがありました。弊社の場合だと既存プロダクトがかなり技術選定を頑張ってきたので、それを踏襲する形で開発を高速化しており、そのためには既存プロダクトがどのように動いているのかを理解しておくとスタートダッシュに成功する印象を受けました。

筆者小話

定期的にお風呂に入り、たまには銭湯へ

さて、このように泥に塗れながら開発を進めているわけですが、当然負債は貯まっていきますし、だんだん開発はやりづらくなっていきます。TODOを無計画に放置していくと直接の開発に影響が出るだけでなく、新たに参画するメンバーのオンボーディングにも苦戦することは火を見るより明らかですね。

僕らは一週間単位でプロダクトアウトカムを出すようなスタイルで開発を進めていますが、その週の開発が終わったらその週の残りの時間を機能開発に充てることはありません。機能を爆速で作った反動でリファクタリング欲求がマックスを超えているからです。なので、求められる機能を爆速で作り上げ、残りの時間はリファクタリングに充てるというのが慣例になっています。

とはいえそれではまとまった時間をリファクタリングに割くというのはなかなか難しいというのも現実です。そこで、半年に一回2週間のリファクタリング期間というのを定めており、その間は新規開発を止めて負債の解消のみに集中しています。

年末キレイキレイプロジェクトとして負債を解消するためのチケットを切っている図

また、日常的に行なっている改善策として、ビジネスロジックレイヤーのコードはテストカバレッジを100%の状態に保つというのを意識しています。デプロイ後の実行時エラーが圧倒的に減らせるなど開発効率にも寄与しますし、コードが必要以上に複雑になることを防ぐ効果も実感しています。
これらの施策によって、泥に塗れながら進むというポリシーに強く共感していながらも、それを単なる免罪符にしないという意識を醸成することができています。

生活リズムを整える

以上のようなポリシーのもと日々開発を進めているわけですが、次は具体的にどのような一週間の過ごし方なのかというのをご紹介させてください。

1週間のスケジュールイメージ

まず、僕らのチームはデイリーミーティングを行なっており、お困りごと相談や軽い進捗確認を恒例イベントとして行なっています。加えて、それぞれの曜日でメインの役割が決まっています。

  • 月曜日: IPM

    • 今週のプロダクトアウトカムを出すための実装方針を共有

  • 水曜日: 中間レビュー

    • 今週のプロダクトアウトカムを出すための中間レビュー、開発進捗の確認とプロダクトアウトカム目標の調整

  • 木曜日: Pre-IPM

    • 翌週のプロダクトアウトカムの確認と、それを実現するためのユーザーストーリーのレビュー、また、現実的なベロシティで開発できるかどうかの確認

  • 金曜日: Demo、KPT

    • Staging環境でユーザーストーリーの完了とプロダクトアウトカムが創出できたことの確認

チームメンバー全員が肝に銘じているのは、仮に全体リソース観点では効率性が悪くなったとしても、毎週のプロダクトアウトカムが確実に一つずつリリースされることを重視した、フロー効率重視で開発を行うということです。これによりチームの生産性が可視化され、スケジューリングに大きく寄与していきます。

リソース効率とフロー効率の対比

ご近所付き合いを大切にする

さて、ここまで開発業務の設計的な話をメインに進めていましたが、最後にチームの雰囲気についてお話しさせてください。

綿密に練られた設計であっても結局その上で実際に業務をするのは今の所人間でありまして、チーム内の雰囲気というのはかなり重要なものだと思っています。また、アウトカムを確実に出していくためにはどうしても120%の力を出さなければいけないタイミングというのは来るものです。それらを円滑にするために特に気を配っている二点をご紹介します。

まず1つ目はチームの方向性に共感できるメンバーを探すことです。繰り返しにはなりますがこのチームはアウトカムをテンポよく着実に積み上げていくことに最もフォーカスしています。そのため、そもそもビジネスロジックを考えることが好きだったり、自分の責任範囲を明確に定めてそれを死守するといった責任感ある人柄が求められる組織になっています。
これは人それぞれ考え方の違いがある部分なので、採用の段階でミスマッチが発生しないことに特に気をつけなければなりません。

2つ目は、コミュニケーションを密にすることです。基本的なことのようですが、特に弊社はフルリモートで業務をしているため、疎かになりやすい部分なのです。
コミュニケーションを疎かにすると、どれだけ優秀なエンジニアの集まりであっても、それぞれのメンバー間で細かい部分の誤解が発生しやすくなりますよね。それらが積み重なると意外と巨大な誤解になったりして本来不要な手戻りが発生してしまいます。
また、やりとりにタイムラグが生じるとどうしても業務を並行したりして、コンテキストスイッチが積み重なり業務の遂行に悪影響が及びます。
それらを回避するために、僕らはわからないことや文章で伝わりづらいことがあったら即SlackのハドルやGoogle Meetで会話するようにしていますし、Slackのレスポンスも基本5分以内くらいには返すようにしています。また、レスポンスが遅くなる場合は先に知らせておくというのも意識しており、例えば僕は13時くらいから毎日散歩しているのですが、それもSlackにポストしています。もはや荒らしみたいになっています。

散歩流行っています

これらを日々意識しながら、頑張らなければならないときにお互い支え合える、相互に尊敬しあえるチームを目指しています。

最後に

最後まで読んでいただきありがとうございました!UPSIDERは「AI化された総合金融機関」として「挑戦者を支える世界的な金融プラットフォームを創る」ためこれからもプロダクトを拡充していきます!次回は4月10日(水)11時更新。「UPSIDER のファンを熱狂させるプロダクト作りを加速させるTech 組織の挑戦 」を紹介しますのでお楽しみに!
また、UPSIDERではまだまだエンジニアが足りない状況です!この記事を読んで面白そうだなと思ったら、ぜひカジュアル面談からお話ししましょう。お待ちしております!


この記事が参加している募集

仕事について話そう

この記事が気に入ったらサポートをしてみませんか?