10XにSWEとして0->1->10の環境にいて遭遇した問題と対策

この記事は 10X 創業6周年アドベントカレンダーの23日目の記事になります。 昨日はデータプロダクト部のysdytさんが、「ネットスーパー立ち上げの裏でデータの人は何をやってるの？」という記事を公開しています。

この記事では0->1->10になるときに出てくる問題と対策を共有し、同じような境遇にある方や、もうすぐ問題が起きそうなときにどのように対処したらいいかの一例として知ってもらえればなと思います。
書いてある事は自分以外にも10Xのメンバが作り上げてきたものです。

前提として10Xが作っているStailerが0なのか1なのか10なのかはわかりませんが、大手の小売の方に使ってもらえているので0でも1でもない気がしていてここでは10とさせていただきます(10Xだし)。

10Xは「ネットスーパー・ネットドラッグストアの立ち上げと成長を支援」するStailerというサービスを作っています。
ネットスーパーを開きたい小売様がいらっしゃったとして10XのStailerを使えば、商品マスタで売り場を作成し、お客様アプリで注文ができ、スタッフアプリでピッキング・パッキング・配送を行えるようになります。

創業から長らく10名程度だったのですがStailerを始めてから人数が増えいまでは100人以上いる会社となっています。

プロダクトの特性

Stailerは複数のパートナー(小売様)に使ってもらっています。各パートナーがそれぞれ必要な機能があります。

最初はパートナーも機能も少なかったので、少ないメンバで対処できていました。時がたつにつれ機能xパートナーで領域が広がっていくのである時に既存のメンバでは対処できなくなりました。

まずはメンバを増やす必要があります。
（ここらへんプロダクトの特性によってはメンバを増やさないという手もあります。増やさなくていいならばそれが一番です。ただプロダクトの特性によっては増やさないとメンバのキャパに限界が来ます。）

採用をする

10Xは最初はトライアルという形で1日オフィスに来てもらい一緒に働く形で採用をしていました。採用するメンバがすくないうちは問題なかったのですが採用する人数を増やすとスケールができなくなりました。事前の準備や当日にかなり時間がかかっていたのです。1日働く事により候補者の事はまあまあわかるのですが、候補者を判断する基準が言語化されていないのをトライアルという形でなんとか補っているというのが実情でした。

SWE(ソフトウエアエンジニア)の採用においてはトライアルをやめることを決め以下を行い選考プロセスとして整理しました。

1. 採用で何を確かめたいのかを項目にする
2. 項目を確かめられるプロセス(面接・コーディング試験・システム面接)を定義しすべての項目を確かめられるようにする
3. プロセスを適切な順番にする
4. メンバをプロセスにアサインし、実施後に振り返りを行いフィードバックループをまわす
5. 新しいメンバの採用へのオンボードを行う

ソフトウェアエンジニアの選考プロセスをアップデートしましたに詳しい経緯があります。

まだまだ改善するところが多数あるのですが、判断基準も明確になりスケールできるようになりました。

ドキュメント!ドキュメント!ドキュメント!

ある程度10Xではドキュメントを書いていたのですが仕様やシステムのデザインを体系的に管理できていませんでした。
パートナーからこの動作はどうなっているのが正しいかと聞かれたときにソースコードを見に行かなければいけなかったり動作が詳しくドキュメントにかかれていませんでした。

現在は、仕様書やDesign Docsを実装前に書いて正しい動作を定義しています。

ちまたではドキュメントいる・いらない議論があります。Stailerに関しては明確にいると思っています。プロダクト開発でドキュメントを書かないとどうなるか
でもそのことについて書きました。
（間違えないでほしいのはドキュメントがいるかどうかはプロダクトの特性によるのでいらないプロダクトも場合もあります）

ドキュメントは複数の役割を担っています。

1. プロダクトの動作の正解がわかる
2. 新しいメンバも古いメンバもプロダクトの動作を素早く理解できる
3. 作業記録により振り返る事ができる

プロダクトの動作の正解がわかる

コードを見れば正解がわかるという人もいますが、そのコードは本当に正解なのでしょうか。動作を正解としても期待した動作をしているのでしょうか。
そもそも正解が定義されていなければ正解は無いはずです。

ドキュメントされていない機能はどのような動作をしているか調査にも時間がかかるし何より正解がわからないのでパートナーに説明するときに非常に困ります。
このような動作をするという宣言的なドキュメントがありそれにあわせてソフトウエアを作らないとBizDevメンバやPdMがパートナーに説明できなくなります。

新しいメンバも古いメンバもプロダクトの動作を素早く理解できる

採用して新しいメンバが入ってきたらそのメンバにとってプロダクトの理解を助けるものがドキュメントです。ドキュメントが無いことにより新しいメンバが活躍できにくくなり調査に余計な時間をとったりしてひいてはプロダクトにとって損失になります。

作業記録により振り返る事ができる

記録され始めてから気づいたのですが、障害時の対応や、本番・CS対応の記録はそれ自体がメンバの助けになります。
過去の対応にそって対応を行ったりすることにより時間を節約できます。
さらにどのような対応が多いか確認でき自動化する対象を絞り込めたりします。

安心して仕様変更するには

Stailerというプロダクトはパートナーの方の業務(ピッキング・パッキング・配送など)が効率よくできるように作り上げています。日々、業務というのは改善もあるしその改善がプロダクトの変更につながります。
そうです「仕様を一部変更する！」です（とある漫画でよく見ますね）。
安心して仕様変更するには以下を意識する必要があります。

1. 仕様変更する部分がプログラムのどこの部分か特定する
2. モデルの完全性や処理の一貫性を保ったまま変更する

仕様変更する部分がプログラムのどこの部分か特定する

日々ソースコードを書いていると半年前に書いたコードを忘れていたりします。CTOにあの機能どんなふうに動いてましたっけ？って聞いても忘れている事があるので全員が実装したものをきっちり覚えていないのは間違いなさそうです。なんなら長期休暇に入っていてきけない状況もあるかもしれません。

素早く既存のコードを理解してプログラムにたどり着けるように最近は業務フローというのを書いています。
業務フローは以下みたいな形で書いています。

業務フロー = Event Storming + 処理するクラス名とモデル名

概要の処理と詳細の処理が書いてあるので機能がどういう風に動いていたかな、とかここの細かい動きはどうだったかなというのがわかります。処理しているクラスがわかるのでそこまでたどり着いてあとはソースコードを見ます。

新規で業務フローを書くときは実装前に書きます。業務フローを共有してPdMとかDesignerとかと認識をあわせてから実装すると最初に考慮事項をあげられて実装しやすくなります。

実装後に更新されないと業務フローと実装に乖離がでてしまうのでそこらへんどうしようかなと悩んでいます。

モデルの完全性を保ったまま変更する

不変クラスはどのように良いコードに貢献するのかでも書いたのですが、変更されうるモデルに対してモデルを変更しても不正な状態をそのモデル自体が許さないというのは非常に大事な事だと思っています。最初のころはこれに気づかずにいくらでも変更できるクラスを量産していましたがそうすると不正な変更処理ができて何が正しいかわからなくなり不具合が頻発します。
ソフトウエア開発でいろんな大事な事がありますが、モデルの完全性を保つというのはいつでもできて最初からやっておくに越したことはありません。

チームの分割は機能単位

人数が増えてくると適切な単位でチームを分ける必要があります。最初パートナーの軸でわけていたのですが機能でわけるに落ち着きました。
ドメインベースの開発体制への移行にどのようにわけたか書かれています。

機能ごとにわけることによりその機能に専門性をもったチームが生まれます。Stailerは商品の購入完了というAPIひとつとっても非常に複雑です。クレカ決済、ポイント付与・消費、完了メールなどあるため片手間で対処できる機能ではありません。
チームが専門性をもって対処することによりパートナーが増えて決済手段が増えたとしても既存の専門知識を使い対処ができるようになります。

まとめ

10Xのプロダクト開発で様々な改善がなされてきました。

• 採用をトライアルからプロセスに変更
• ドキュメントを書く
• 仕様変更をしやすくするために業務フローや完全性のあるモデルを作る
• チームを機能単位で分割する
• 他にもたくさん

10Xが6周年ということですが自分自身5年以上やってきて大切なのは変化でき、変化する体制だなと思っています。事業をやっていると問題は多々起こるのですが10Xは素早く問題を認識し対処しています。対処がその時で間違えていることもありますがすぐ修正して正しい方向に向かっていきます。これからも変化を楽しみつつソフトウエア開発をいい感じにできるように日々精進していきます。

最後に10Xではメンバーを募集しています！採用ページもぜひご覧ください。明日はプロダクトマネジメント部のエナミンさんが記事を公開する予定です。お楽しみに！