Stailerのサーバーアプリケーションで採用しているDartパッケージの紹介

はじめに

こんにちは!ソフトウェアエンジニアの yamakazu (@yamarkz) です。

ネットスーパーを日常使いしていますが、スーパーに並ぶ商品の季節感が好きで週に1度は店舗に足を運びたくなってしまい、結局リアル店舗の利用は外せないという生活をしています。

さて、前回は開発文化の話を取り上げて紹介しましたが、今回はより技術寄りな話としてStailerのサーバーアプリケーションで採用しているDartパッケージを紹介します。

類似のトピックとしてアーキテクチャなどは石田さん (@wapa5paw) がリリース直後に紹介してくれていますが、Stailerで使われている具体的なパッケージなどはまだ紹介していませんでした。

StailerのサーバーはDartで書かれており、世間的にもあまり例がない技術選定がされています。(以下参考)

type.jp

採用例が少ないDartという技術選択の中で得た知見をベースに、どういったパッケージを使っているのか?どういったパッケージがおすすめなのか?という問いに答えていこうと思います。

本記事を読んで、Dartでサーバーアプリケーションを開発することに少しでも興味を持っていただければ嬉しいです。😄

パブリックパッケージ

※ ⭐️ の数はパッケージの良さを個人的な推し度で表したもの

. gRPC with Protobuf (⭐️⭐️⭐️)

pub.dev

StailerのWeb APIではgRPCが採用されています。

Protocol Buffersでスキーマを定義し、クライアントとサーバーでインターフェースを共有して、リクエストとレスポンス処理を行うという一般的な使い方です。

10Xではタベリーの頃からgRPCを採用しており慣れていたのと、REST APIにしなければいけない制約もなかったので、引き続きgRPCを採用したと聞きました。

Dartの公式ではHTTP ServerにはShelfというパッケージが推奨されています。 個人的にはShelfを使ってみたい気持ちもありますが、gRPCの生産性やパフォーマンスの高さが優れている面を評価すると、実務ではgRPC優勢かな〜という気持ちです。

. retry (⭐️⭐️⭐️)

pub.dev

リトライ処理にはretryを採用しています。

Stailerは単体でもサービス立ち上げが可能ですが、一部パートナーのAPIを利用して機能を実現している箇所があり、そういったシーンで活用されています。

APIリクエストは大半が成功しますが、稀になんらかの予期せぬ理由で失敗することがあります。 イレギュラーなケースに遭遇してもリトライでカバーできる状態を作り、機能の完全性を担保することは運用で楽をする上で不可欠です。

httpの標準の機能でもあるので、それだけでよければそっちを使っていたりもします。

. clock (⭐️⭐️⭐️⭐️⭐️)

pub.dev

"時間"をシステムで扱うのは難しいですが、clockを使えば扱いやすくなります。

clockは現在時刻の概念を簡単に扱えるようにしてくれるパッケージで、活用するとテスタビリティが向上します。

    test('error if delivery date has not been reached', () async {
      await withClock(Clock.fixed(DateTime(2021, 09, 28, 13, 30)), () async {
         // Written test code
      });
    });

(withClockで特定の日時で処理を実行する例)

特定の時間順序に依存したテストを書きたい場合は、clockを用いて時間操作を容易にしておき、指定時間に処理を実行することを想定したテストコードを記述すると良いです。

主にdailyのバッチ処理系のテストコードで活躍してくれる欠かせない存在です。

. euc (⭐️⭐️⭐️)

pub.dev

Shift-JISのファイルを扱うためにeucを採用しています。

Stailerはパートナーから膨大な量のデータを連携しています。共有されるファイルにはShift-JISが採用されているケースもあり、Shift-JISも扱えるようにするためには文字コードの変換が必要で、そこで利用するのがこのパッケージです。

大抵のことはカバーしてくれるので重宝しているのですが、1つだけ惜しいところがstream処理過程でconvertする機能が未対応です。 ここは自前で列分割を行うパッチ処理を挟んで対応していたりします。

. sync (⭐️⭐️⭐️)

pub.dev

並行処理を行うために採用しています。

syncはGo言語にあるパッケージの思想をDartで表現したもので、インターフェースなどは同じです。StailerではこのsyncパッケージをラップしてConcurrentクラスという表現を作り、並行処理を行なっています。

syncによって1店舗あたり2~3万件ある商品データを350店舗分決まった時間内に同期することができるようになります。スケーリングの観点では絶対外せないパッケージです。

[余談] Null Safety化を進めるために沢田さん(@swdyh)がシュッとPRを送ってくれてたりします 🙏

. collection (⭐️⭐️⭐️⭐️)

pub.dev

複雑な配列操作を行う際にはcollectionを使うのがおすすめです。

firstWhereOrNullwhereNotNull でNullを上手く扱った処理を書いたり、 UnmodifiableListView で配列操作に制約を加えたりもできて安全に便利な配列操作が実現できます。使わない選択肢がないくらい便利です。

. sentry (⭐️⭐️⭐️)

pub.dev

エラーログのトラッキングではSentryを使っています。

サーバーはログが膨大なので、Sentry経由で問題のログに早期に気づくことができた方が運用的には良いです。

Flutter 用には sentry_flutter があるようですが、StailerのClientでは採用していません。

. dartis (⭐️⭐️)

pub.dev

DartisはRedisを扱うDartクライアントで、シンプルなデータキャッシュとして使用しています。

主にパフォーマンス改善で活用しており、売り場で表示されるカテゴリーデータなどは更新頻度が低いためキャッシュを効かせてレスポンス速度を向上させています。

深い使い方をしていないのと、メンテナンス性が高くなさそうなので推しポイントは低いです。

. uuid (⭐️⭐️⭐️)

pub.dev

採用してます。RFC準拠で何も文句がありません。

. html (⭐️⭐️⭐️)

pub.dev

HTMLを楽に扱う時にはhtmlが良いです。

Stailerではパートナーが運営するネットスーパーのサイトをクローリングして商品データを集めるケースがあり、その場合にhtmlは活躍します。

趣味のクローラーを作ってちょっとした情報収集〜といったユースケースにも使えそうです。

プライベートパッケージ

Stailerで使っている自前のパッケージです。

. Firestore

Stailerの永続データストアにはCloud Firestoreが採用されています。

FirestoreのパッケージはPub.devでもいくつか確認できますが、そのほとんどがFlutter SDKを前提に作られており、Pure Dartではないです。

サーバーでも使えるかもしれませんが、使う中で下手に気を使うよりも、自分たちの前提にあったものを使うほうが中長期的に良いという考えから、自前でパッケージが作られました。

f:id:yamarkz:20210927220629p:plain
CTOのishkawaさん謹製のPure Dartなパッケージ

機能は公式で提示されているものを凡そカバーしており、最近だとSelect field機能が試験開発されています。

また、通信で利用されているデータのシリアライズとデシリアライズのパッケージをmirrorからjson_serializableに書き換えなども行なっており、パフォーマンスが大きく改善されたりしました。

f:id:yamarkz:20210927225316p:plain
readのパフォーマンスが10x✨

. Firebase Auth

Firebase AuthもFirestoreの話と同じく、for Flutterなパッケージは存在しますが、サーバーで利用する(Pure Dart)ものは今のところありません。

サーバーを介して認証を行えるようにするために、Firebase Authのパッケージも自前で作られました。

プラットフォームとして扱える様にいくつかカスタマイズを加えていたりもします。

. BigQuery

BigQueryもDartのパッケージが存在しないため、自前で対応しています。 パッケージがないから採用を見送る... の意思決定はなかったです。(BigQuery最高!!)

StailerではBigQueryをフル活用して膨大な在庫データを扱っており、システム基盤としては欠かせない存在です。 (データの話は奥が深く、また別で取り上げられると思うのでお楽しみに!)

f:id:yamarkz:20210927221056p:plain
オーソドックスなクエリの実行

売り場に表示される商品データは、Raw Data → Storage → dbt → BigQuery → Firestoreという変遷を辿って実現しており、BigQueryのパッケージはこの中の BigQuery -> Firestoreのステップで主に使われています。

変わった使い方はしておらず、googleapisにあるBigQuery APIをラップして作られています。

. 決済処理系

Stailerは決済で外部ベンダーのAPIを利用しており、扱う処理はパッケージに切り出されています。

決済系は公式がライブラリ提供してくれているところもありそうですが、基本はWeb APIのみの提供になるので、それをDartの世界で扱いやすくするためにパッケージにしています。

. パートナー連携系

パートナー連携は連携ごとにAPI操作を行うパッケージを作っています。(決済処理系と同様)

機能をサーバーの各処理(API or Batch or Worker)で使い回すのと、"パートナー連携"という文脈で処理をまとめた方がわかりやすいです。

連携系のAPIはそれ自体はアトミックな操作にしておき、サービスクラスを挟んで各々の文脈で使いやすい形に変えたり、エラーハンドリングを加えたりしています。

言葉だけだと伝えづらいのですが、API Request → Service → Partner Client → Partner APIという流れの中でPartner APIを呼び出しやすくするためにClientをパッケージに切り出すということです。

まとめ

  • パブリックパッケージを程よく取り入れるが、基本は薄く使う。
  • プライベートパッケージは主にミドルウェア方面で自作している。
  • 必要であればコントリビュートやパッチを当てて使う。

最後に

Stailerのサーバー開発で採用されているパッケージを紹介してきました。 どんな雰囲気で開発されているのか、少しイメージが膨らんだのではないでしょうか?

端的に言えば、パブリックパッケージを薄く採用しながら、ミドルウェア周りのパッケージを自作し、必要であれば適宜パッチを加えるという感じです。

Dartはまだまだマイナーですが、言語機能自体は素朴で読みやすいのでおすすめです。Server Dartも可能性は0ではないので、ぜひトライしてみてください!🎯

宣伝

10Xではソフトウェアエンジニアを募集しています。本記事を読んで少しでも気になった方はぜひ声をかけてください。Dartを駆使して一緒に小売のデジタル化を進めましょう!🔥

定期的にオープンオフィスを開催しています。会社のことから仕事のこと、パートナーとの関わり方など、ざっくばらんにメンバーが話をしているのでぜひご参加ください。

docs.google.com

10Xのカルチャードリブン開発を支える選考プロセス『トライアル』の紹介

こんにちは。ソフトウェアエンジニアの村岡(@_tapih)です。

私が入社して約3ヶ月が経ちましたが、入社前後のギャップが一切なく、もう何年も働いているような不思議な感覚で日々働いています。 これは弊社が採用で行っているトライアルという仕組みがうまくワークしているからだと感じています。 この記事では弊社の選考プロセスで実施しているトライアルの概要と実際に私がトライアルで行ったことを紹介します。

なお、弊社はSWE/Product Manager/Designer/QA/SET/SREを絶賛募集中です(Dartを使ったことがなくてもOKです!)。この記事が弊社に興味がある方々の参考になれば幸いです。😄

※ 本記事で紹介するトライアルに関する内容は、取り組む課題に個人差があること、今後内容が大きく変わる可能性があることの2点にあらかじめご注意ください。

トライアルとは

トライアルとは、事前に「インパクトあるイシュー」を挙げてもらい、実際に働く機会を設けてそれに取り組んでもらうことで10X Valuesにフィットすることを相互確認する採用プロセスです。

候補者はNDAを結んだ上で弊社の社内情報に事前にアクセスし、あるテーマに対するイシューとそのイシューに対してどう取り組んでいくかを準備します。 その後、1日〜数日かけて事前に決めた課題に取り組み、最後は取り組んだ課題の成果を発表してもらいます。

候補者によってテーマに細かい違いはありますが、プロダクト開発に関わる職種で共通する点として「いかにStailerを10x成長させるか?」という視点を含んでいます。 イシューの選定の際には、短い時間でも「候補者の強みが最大限発揮できる」ようなものに取り組んでもらうことが重要で、決して「タスクの完了」を目的とはしないことで、 何かしらの10xから逆算した貢献ができるイメージを共有できることを目指します。

面接はどの会社も採用しているであろう選考プロセスの代表的な手段ですが、短時間の面接で自社のカルチャーへのフィットを見ることは非常に難しいのではないでしょうか。 一方で、「実際に働く」というプロセスはカルチャーフィットがリアルに感じられ、これを確認するための非常に明快な手段であると考えます。 また、候補者の側は、会社の内情を事前に実体験として知ることができるので、入社前後でのギャップを抑えることができます。 このように、選考を受ける側と提供する側の両者に対して、納得感のある結論を安定して出せることがトライアルのメリットです。

採用プロセスや評価グレードについてはCulture Deckに説明があるので、興味のある方はご一読ください。😄

speakerdeck.com

...といろいろ書きましたが、これだけではイメージが湧きづらいと思うので、後ほど具体例として私がトライアルで行ったことを紹介したいと思います。

トライアルがプロダクトに与える影響

10X Valuesに関しての個人的な解釈は以下の通りです。いずれも抽象的ではありますが、プロダクトを作り上げていく上で必要な要素が全てここに凝縮されていると考えています。

  • 10xから逆算する: プロダクトとの向き合い方
  • 自律する: 自分との向き合い方
  • 背中を合わせる: 他人との向き合い方

したがって、これが体現できること=10xするプロダクトを作ることに繋がり、採用の段階からこのカルチャーに対するフィットを入念に確認することがそのままダイレクトにプロダクトの質につながってくると考えています。

過去のトライアルで取り組まれた内容

弊社が開発するStailerはスーパーマーケット、ドラッグストアなどの小売チェーンがECを立ち上げるためのプラットフォームです。 このプロダクトに対し、過去には以下のような内容でトライアルが実施されました。人によって期間はまちまちですが、そこそこ大きめの粒度で設計から実装までを行っていることが伺えると思います。

  • (SWE) 商品タイトルに含まれる商品詳細の自動抽出とタイトルの再生成の実装(1週間のトライアル)
  • (SWE)「ついで買い」機能のUI及びAPIの設計・実装とリピート購入の傾向分析とロジック提案
  • (Designer) 注文〜受け取りまでの体験設計とUI作成、ユーザビリティテストの実施(約3週間の間、実際のPJで稼働)
  • (Product Manager) 商品検索改善のための全体設計の提案
  • (Growth) パートナーから受領した商品データをStailerに取り込むフローの汎用化方針の設計・実装

私がトライアルで取り組んだこと

さて、トライアルに関するイメージをより明確にするため、ここから私のトライアルについてご紹介したいと思います。

私は「とあるネットスーパーを10x成長させるには?」というテーマに対してネットスーパー利用客がほしいと思った商品にうまくアクセスできていないペインの解消というタイトルで商品検索改善に取り組みました。

1. 採用エントリーからトライアルまでのタイムライン

エントリーからトライアルまで約1ヶ月半程度の時間がありました。 事前に何をやるのかを社員との面談を経て決定した上で、トライアル当日に実際に出社して成果を発表しました。 1回目の面接の前と事前準備にそれぞれ半日程度まとまった時間を使って稼働して、あとは平日夜の時間をちょこちょこ使って準備を進めました。 子育てで時間が確保できるか心配なところがありましたが、比較的ゆったり目のスケジュールで調整し、無理なく進めることができました。

2/17 HPからエントリー
2/22 トライアルについての面談(1回目)
2/24 NDA締結
3/8  トライアルについての面談(2回目)
3/9~ 事前準備
3/31 1dayトライアル
2. 課題設定に至るまで

どのようなペインがあるのかを把握するため、まず始めに一ユーザ目線でStailerが提供するネットスーパーを利用してみました。 そこで、多種多様な品目を扱うネットスーパーにおいて検索機能が非常に重要な機能であるにも関わらず、検索結果が「しっくりこない」と感じることが多いことに気づきました。 続いて、この「しっくりこない」感覚を深堀りするために社内のドキュメントを読み、在庫の問題・検索の問題・商品の見せ方といった点にその原因があると整理しました。

ペインに対する施策の整理
(ペインに対する施策の整理)

現在の事業の状況を踏まえると、中でも商品検索の改善にフォーカスするのがベストと考え、続けて検索改善の全体像の検討に取り掛かりました。 ここで考慮が必要だった点としては、タイトル・説明文・カテゴリ名といった各商品のデータが十分に整備されていない、という問題がありました。 実際にどのような検索ができているか・できていないかを試しながら、限られたデータをいかに有効活用するか、検索クエリのサジェストを用意するなど検索体験の全体設計でカバーできないか、といった観点から検討を進めました。 私はトライアルまで検索改善の経験がなく、ましてやElasticsearchを利用したこともなかったため、このプロセスは非常に苦労しました。

各情報の使い方の整理改善案の全体像
(改善案の全体像)

3. トライアル当日

私が示した検索改善のゴールイメージと現状のElasticsearchの設定を踏まえ、改善の一手段としての「Ngramを利用した単語のアナライズ」と、 改善の計測のための「Ranking Evaluation APIのデモ」の2点にトライアル当日に取り組むことを決めました。 検索の改善は継続的な取り組みが必要な息の長いタスクだと思いますが、その一端をトライアルという短い時間で表現したいというのもこの決定の理由の一つでした。

この記事では具体的な方法論には触れませんが、以下のドキュメントを参考にしました。

www.elastic.co www.elastic.co

余談ですが、トライアル前日にElasticsearchのローカル開発環境を動かそうとしたところサクッと動かせないことに気づき、非常にドキドキして当日にトライアルに向かいました。 結局動いたのは当日の昼過ぎ(!)でしたが、実際にメンバと交流しながら作業をして、最後にデモをして無事終了となりました。

トライアルを通じて事業に対する理解が一気に深まったことを感じました。 また、Howに至るまでのプロセスを評価していただき、かつそういったフィードバックを直接いただいたことでカルチャーフィットを相互に確認できている実感がありました。 シンプルに「トライアルっていいな...」と思いながら帰路についたことをよく覚えています。

今後に向けて

ここまでトライアルの長所ばかりをご紹介しましたが、組織が拡大するにつれて以下のような問題が顕在化してきました。

  • トライアルを行うための弊社側の環境整備(権限等)のコスト増加
  • 社内資産の拡大による候補者側のキャッチアップコストの増加

しかし、社内的にはトライアルという採用プロセスを大事にしていきたいというコンセンサスがあり、今後もよりよいトライアルを行えるように仕組みを整備していきます。

さいごに

この記事では、弊社のプロダクトの質を下支えするトライアルという選考プロセスについて私の実例を踏まえてご紹介しました。

弊社の社員はよく「強そう」「怖そう」と言われている印象があります(笑)が、トライアルで見られるのは「強さ」というよりかはいかに真剣にプロダクトに向き合えるかという点に尽きると思います。 私自身も働きながら、一番大切なのは熱意だな、と日々痛感しています。また、課題はチャレンジングでしたが、フィードバックが柔らかい社員ばかりだと入社してからも再認識しました。

怖くない10X!ということで、本記事を読んでいただきさらに10Xの話を聞いてみたい!と思った方は、定期的に開催しているオープンオフィスへのご参加お待ちしてます!😄 また、カジュアルに10Xのプロダクト開発について聞いてみたい方は本記事を書いた 村岡(@_tapih)のTwitter DMでもご連絡をお待ちしてます!

docs.google.com

10Xのコードレビュー方針と導入までの流れ

はじめに

こんにちは! 10Xで始まったプロダクトブログで初めて筆を取りました、ソフトウェアエンジニアの 山口 (@yamarkz) です。

最寄りのスーパーはライフで、必ずはちみつヨーグルトを買ってます。(おいしいのでオススメ 😋)

自身の初回ということで何を書くか迷いましたが、もうすぐ10Xに加わって1年ということもあり、入社時に驚いたことの1つである 10Xのコードレビュー文化 について紹介しようと思います。

10Xのプロダクトチームがどんなスタイルで開発を進めているのか、その一端を知ってもらえたら嬉しいです。

1. もともとコードレビューする文化がなかった

いきなり否定から入ってしまうのですが、自分が入社した2020年9月の頃は、プロダクトチーム内でコードをレビューする文化がありませんでした。( !! )

正確には全くないというわけではなく、クリティカルな部分の実装や実装者がレビューを希望した場合にのみ実施されており、それ以外は行わず各々がPR (Pull Request) をマージし、リリースしていました。

f:id:yamarkz:20210824094545p:plain
(依頼した方が良さそうな時に、依頼する)

最初この状況を見た時は戸惑いがあり、「すごいな...」と声を漏らして驚いたことを覚えています。自分は10X以前ではコードレビューをゆるくも厳しくも必ず行う世界を見てきたので、初見のギャップが大きかったのかもしれません。

希望して実施されるレビューは大方針が間違っていないかや、クリティカルな箇所のロジックが仕様に沿っているかを確認する程度で、よくある細かな表現に対する指摘などはなく、実装は個々人に大きく委ねられていました。

それでも特段開発に支障が出ることもなく、ほど良い品質で素早く機能をリリースするサイクルが回っていたので、レビューの必要性自体あまり感じない状況だったなと、今振り返ると思います。

これには大前提として、当時からシニアなメンバーが揃っていたのとリリース初期で複雑性が低かったという背景もありました。

2. 1年半で4パートナーのリリース、高まる複雑性

f:id:yamarkz:20210824094618p:plain
(2021/08時点で導入されているパートナー)

Stailerがリリースされてからおおよそ1年半で4パートナーのプロダクトをリリースしてきました。 これが早いか遅いかは主観による所ですが、個人的には極めて早いスピードで進んできたと思っています。

このスピードを実現できたのは、開発言語をDartに統一するという技術戦略や、Stailerをプラットフォームとして事業展開する(≒ 抽象化でレバレッジをかける)といったプロダクト戦略によるところが大きいのはもちろん、先の文化も少なからず寄与しています。

コードレビューを強制しなくても良い感じに開発が進む文化は、自律した個々人の集合によって実現されていました。この文化は見方を変えれば、「開発におけるメンバー間の依存関係が疎である」とも言えます。

疎というのは、メンバー間での情報共有が少なくとも自律的に物事が進められる組織状態のことで。これは仮に10人のメンバーがいた場合、並列して10個の開発が進んだりします。各メンバーは常に業務時間の8割以上を開発に投下でき、非常に生産性の高い状態です。

開発スピードはチームとしての頑張りもありますが、それ以上に戦略と文化によってもたらされる部分が大きいのではないかと思っています。

これまで開発を順調に進めてきましたが、それでもやはり規模が大きくなるにつれてプロダクトの複雑性が高まることは避けられません。

複雑性に対処するために仕様の理解や調整に時間を要することも徐々に増えてきました。

Stailerはマルチテナントで運営されており、共通の実装で複数サービスの展開を行なっています。コードで見れば、6~7割程度は抽象実装でカバーできていますが、残りの3割近くは断片実装が必要になります。

この断片実装周りの仕様が分岐点になり、「Aパートナーには機能提供するが、Bパートナーにはしない」「Aパートナーでは制約付きで提供し、Bパートナーは制約がないが若干表現を変えて提供する」といった複雑な状況が生まれていました。

これらは後々統一した抽象実装に昇華させたりもしますが、直近の断片実装は避けられない状況で、ある程度の複雑性を許容して進めていかなければいけません。

そういった中で開発を進めていくと、仕様の考慮漏れであったり、変更による想定外の副作用などが生まれてしまい、実装者だけで実装の安全性や完全性をカバーすることの限界が見えてきました。

今後支障をきたし始めることがわかってきたタイミングで、コードレビュー必須化の話題が挙がり、導入の検討が始まります。

3. コードレビューの導入を始める

f:id:yamarkz:20210824104808p:plain
(コードレビューを入れるという話の発端)

前段の状況が生まれ始めたことをきっかけに、コードレビューの必須化検討が始まりました。

導入の段取りはCTOのishkawaさんがコードレビュー運用方針のタタキ台をつくって、そこにメンバーのフィードバックを当てて実運用に乗せていく流れです。

運用を始める背景、最低限守りたいライン、運用手順などがドキュメントに起こされました。

これは外に公開しても問題ないという確認を得られたので、10Xのコードレビュー運用ガイドの一部を紹介します。

f:id:yamarkz:20210824094926p:plain
(プロダクトチームのコードレビューガイド)

このコードレビューの方針に沿った形でPRを作った場合、実装方針とその表現の確認に重きが置かれます。具体例として、直近自分が作ったPRは以下の様な表現をしています。

f:id:yamarkz:20210824094945p:plain
(レビューガイドに沿ったPRの例)

課題を解決するHowの候補として取れる選択肢は何があるのか。その中で何を選択したのか。その結果、どういった表現になるのか。表現に対して考慮の不足や副作用の懸念がないか。という一連の方針、実装の大上段をレビューしてもらいます。

WhyやWhatはissueに記載してある場合や、口頭で合意を取っているケースがほとんどなので、PRにはHowのみを記載します。

[余談] これまで運用をしてきた中で「こりゃ便利だな〜」と感じている仕組みとして、Slackにレビュー依頼のメンションを飛ばす仕組みがあります。

f:id:yamarkz:20210824095007p:plain
(Slackに送られるレビュー依頼通知)

この仕組みがあると画像のようにSlackにメンションで通知が来るので、レビューを忘れることことがなくなり便利です。すぐに設定しましょう。

👉 公式ドキュメントに設定方法が紹介されています。

4. 導入後の変化

というわけで、10Xでもコードレビューが必須になりました。🚓 👮‍♀️ 🚨

ルールを変えるということは、結果として何かしらの変化が起きます。 起きた変化を得られたもの失ったもので整理すると次のようになりました。

<得られたもの>

  • 仕様の考慮漏れや変更による副作用でのバグが減った。
  • メンバー間で仕様の共有知を醸成できる様になった。
  • 仕様変更の認識と理解を得る機会になった。
  • 中期を意識したより良い実装表現を見つける機会になった。

<失ったもの>

  • リリースまでの短期的な速度が低下した。
  • レビューで個人の稼働時間を消費するようになった。
  • レビューによる認知負荷が個人にかかるようになった。

導入タイミングとしてはベストで、投資対効果が十分に見合う仕組みになったと感じています。

後から気づいたことで、レビューの機会が「仕様変更の認識と理解を得る機会になること」は新しい発見でした。

急速に複雑化していくStailerの場合、仕様変更に後追いで気づくよりも、レビューの機会を通じて変更が入ることを頭の片隅に入れておけるのはキャッチアップの機会にもなり、良い体験です。

5. 今後の展望

運用によって良い効果が得られている一方で、まだまだ改善の余地があります。 具体的には、レビューの基準をより精密にすることや、実装以前の段階での設計レビューを設けるなどです。より良い形を模索しながら、10Xらしい開発文化を作っていきたいです。

ちょうど先週開催されたProductチームが話すオープンオフィスでは今後のStailerの方針が社外向けにも話されました。

f:id:yamarkz:20210824101534p:plain
(オープンオフィスで紹介されたStailerの開発方針)

Stailerはこれからの1年~3年でプラットフォームとしての拡大基盤の整備、および信頼性と安全性の向上に力を注いでいきます。

コードレビューの導入は、これから達成していくことの最初の一歩目とも言える出来事だったと思いました。

さいごに

10Xのコードレビュー文化について、これまでの過去を振り返りながら、現在の状況、そして今後やりたいことまでを紹介してきました。

コードレビューを強制しない状況から、徐々に実施する流れに進んできていますが、そこには明確な背景や合理的な理由があってやり方を変えてきたというのが、今回の記事で紹介したかったポイントです。弊社の例がコードレビューの導入や改善を検討している方の参考になれたら嬉しいです。

自身の1本目だったので下手なことは書けないなと思い、気合を入れて書いてしまいましたw 今後はゆるい記事も交えながら、10Xのナレッジを公開していけたらと思っています。😄

おしらせ

10XはFlutter/Server Dartという邪道のような技術を選択しながら、店舗のデジタル化という小売の王道になるであろう事業の立ち上げにトライしています。🔥

難しい問題がたくさんありますが、自律した仲間と背中を合わせて10xな価値をつくるのはとても楽しいですよ!

定期的に開催しているオープンオフィスでは、普段の開発の裏話なども聞けるので、興味あればぜひご参加ください。

docs.google.com

10X Product Blog はじめました

はじめまして、10X ソフトウェアエンジニアの岡野(@operandoOS)です。

10Xは現在 チェーンストアECの垂直立ち上げプラットフォーム「Stailer(ステイラー)」を展開しています。

今日からこの10X Product Blogで、社内で日々取り組んでいる開発技術やUI/UX デザイン、プロダクト/プロジェクト マネジメントなど、プロダクト開発にまつわること中心に発信していきます。

最初の記事ということで、今回はこのブログをはじめた経緯を書いていきます。

10Xのプロダクト開発をより具体的に伝えていくために

10Xではこれまで、最新の事業・組織に関する情報を公開するスライドCulture Deckや、定期開催のイベント10X Open Office、社員へのインタビューや社内の日常を伝える10X Blog、プロダクト開発や技術・組織・仕事のあれこれについて話すPodcast 10X.fmなどを通じて、会社にまつわる様々なことを発信してきました。 これらと合わせ、さらにより多くの人に「私たちが日々どんな課題と向き合い、どのようなプロダクト開発をしているのか」を具体的に伝える(届ける)メディアの一つとしてブログを選びました。

より具体的に伝えていくためにプロダクト開発の結果だけではなく、結果に至る過程や背景まで深堀りながらお伝えしていきます。 本ブログを通して、10Xのプロダクト開発が社内・社外問わずしっかり伝わっている状態を目指していきます。

オープンであることを強みとし、業界に貢献する

10Xのワークスタイルの一つに「透明性がスピードを生む」というものがあります。

「透明性 = 必要な情報がオープンであること」を社内だけに留める必要はなく、私たちが日々どのようなプロダクト開発をしているのかをよりオープンにしていきたいと考えています。 オープンにすることで10Xに興味を持っていただけた人が、10Xがこれまでどのようなプロダクト開発してきたのかを手軽に、好きなだけ参照できるようにします。

また、10XがStailerを通して取り組んでいる小売業界の技術はまだまだオープンになっていないことが多いと感じています。 そのため、具体的に何を作っているのか、どんな技術的・プロダクト的チャレンジがあるのかが分かりづらいと思います。

これに対して10Xが業界をリードして様々な情報を発信し、小売業界の楽しさ・すごさなどを感じてもらい、より多くの人が業界全体をよりよくしていける環境づくりを目指していきます。

社員が情報発信できる場作り

会社からのサポートがありながら、社員が日々取り組んでいることを情報発信していける場を作ることも大事です。 情報発信することで自身が取り組んできたことへのフィードバックが社内・社外から得られた結果、それらが個人やチームに役立つ資産として蓄積され、さらによいゴールに向かって正しくプロダクト開発を進めるようになることを期待しています。

また、情報発信は社外だけでなく社内向けの情報共有として機能することも期待しています。 今後社員が増えていくにつれ、誰が具体的に何をやっているのかが把握しづらい時期は訪れると思います。

そういった中でも本ブログなどを通して、社員一人ひとりが日々どのようなことに取り組んでいるのかを知るきっかけの場になることを期待しています。

おわりに

今回はこの10X Product Blogをはじめた経緯を書かせていただきました。

今後は10Xの社員が「日々どんな課題と向き合い、どのようなプロダクト開発をしているのか」を発信していくので、引き続きウォッチしていただけると嬉しいです。

最後に、本ブログなどを通じて「10XやStailerのプロダクト開発についてもっと知りたい!」という方は、2021/8/19(木) 18:00から「10X Productチームが話すStailerの今と未来」というイベントがありますので、ぜひこちらに参加申し込みしていただけると嬉しいです。

jobs.10x.co.jp