そう言えば、登壇してたわ

登壇しました

結構時間は経ってしまったけど7月にエンジニア向けのイベントでLTの登壇した。 いくつかLT登壇は今まで何回かしていたが、会社名を出して代表として出たので初めてだったので軽く準備過程を書いてみることにした。

登壇テーマ

最初は会社で立ち上げようとしていた新規プロダクトの話をするつもりだった。イベントのテーマ自体もフロントエンドだったので新規プロダクトを立ち上げる上での何かをしゃべれば面白いかも、と思って準備していた。 しかし、イベントの日にはまだ新規プロダクトの プレスリリースが出ていない ことからイベントではプロダクト名とあまり詳しい内容を述べてはいけなく、内容として面白くなかったのでテーマを変更。

それで結局決めたのは フロントエンドとフィードバック・テスト についてUzabaseはどうやっているのかを書いてみることにした。当たり前に見えるかも知れないけど最も大事で結構助けられる部分でもあるので自分のためにもまとめてみることにした。

フィードバックは大事

フィードバックサイクルをいかに早く、多く回すか

今回のLTで話したかったことはこの一言になる。サービスの開発でフィードバックサイクルを早く、多く回すかはサービスの質に大きく影響するのですごく重要なポイントの一つ。 その中で 多く回す と 早く回す はそれぞれ技術的なところとそれ以外の所で今回のプロダクトで気をつけたことを述べてみる。

フィードバックを多く回す

トライアルのユーザーを集めて使ってもらうのもすごく良いプラクティスだが、既にあるサービスの追加機能とかでなく完全新規のプロダクトの場合はそれもできないかも知れない。 まだログインしかできないけどフィードバックください とは中々言いにくいと思う。

そのため外部から集めるのは難しいので内部の資源を上手く活用していくことにした。 まだリリース前のサービスの一番のユーザーはやはり 開発しているエンジニアである のでエンジニアからも開発しながら結構なフィードバックを元に改善をしていた。 最初は定まってなかったデザインの基盤もデザイナーさんと多く議論をする中で作り上げていって、最終的には デザインガイドライン を定義できた。コンポーネント設計ではAtomic Designも採用していたのでガイドラインを元にUIフレームワークのように作れたので今後もデザインの統一性は担保できると思っている。

また、Uzabaseではフィードバックは基本的に実際の動いている本番環境を元に行われる。まだ公開してないのでアクセス制限はかけていたが、 実際のユーザーが使う環境と同じ にした上でフィードバックを集めるのでそれらを実現するための工夫はいくつかあるのでまた下で記述する。

フィードバックを早く回す

フィードバックを早く回すための工夫は大きく２つ。

• CI/CD
• 常にMVPを意識する

CI/CD はフィードバックを早く回すためだけでなく、多く回すためにも必要になる。上で 実際のユーザーが使う環境と同じ 環境でフィードバックを集めると書いてあるので開発が終わったユーザーストーリーを本番環境にリリースしないとフィードバックは集まらない。一つのユーザーストーリーであってもフィードバックを早く・多く集めるためにはできるだけ早く本番にリリースする必要がある。

しかし本番環境までリリースする手順が複雑だと リリース回数は当然落ちる のでCI/CDの効率化は大事になる。そこで今回は ArcoCD・Helmを使ったGitOps を採用した。 アプリケーション自体はk8sで動いていたのでHelmでマニフェストを作り、ArgoCDでそれをデプロイする流れになる。

また、 常にMVPを意識する もすごく重要である。リリースを早くするには各ユーザーストーリーのMVPを常に意識し、早く終わらせて早くリリースする必要がある。 ストーリーのゴールが不明確であればすぐに相談する 、 追加の開発が必要であれば別のユーザーストールを作成する 、 対応のタイミングや優先順位を議論する などアジャイル的なスキルが求められる。こういった議論を繰り返すことで今のユーザーに 多くの価値がある機能を早めに出していくことができる。 もちろんこれはもの凄く難しい部分だが、アジャイルの基礎を心かけてトライアンドエラーを繰り返すと精度も上がってくると思う。

テストをしっかり書こう

上記の フィードバックを多く回す や フィードバックを早く回す　を実現するためにはCI/CDを整えることやアジャイル的に意識するなども大事だが、それらを支えるのはやはり 自動テストを書くこと だと考える。

自動テストがないとマニュアルテストで確認するしかないので早く・多くリリースすることに大きく影響する。どんなに早くて使いやすいCIツールがあってもテストにもの凄く時間が掛かっていたら意味はない。 また、フィードバックを集めていたら当然計画は変わる。計画していた機能がなくなったり、新しくできたりすることもあれば既に作った機能の仕様が変わることもあるだろう。自動テストがないとその 変化に対応しにくくなる 。アジャイルで開発をしていたら計画は同然変わるものだと認識をした方が良いと思っている。

エンジニアとして ここの仕様が変わったのでもうその期日には間に合いません と返すのはUzabaseのバリューとは合わないので変わるであろう計画に柔軟に対応するためにもテストはすごく大事である。

ほんで、どんなテストを書くべきか？

テストにはいくつか種類があるが、ここで主に話しているテストのことは フロントのE2E のこと。 もちろんユニットテストは要らないという意味ではなく、E2Eも含めて書いた方が良いという思っている。

チームではE2Eを書く際には Gauge + Chrome Driverを使った Seleniumのテスト で書いている。

# マイページの項目の更新
* トップページにアクセスする
* メールアドレス"test@uzabase.com"パスワード"password"でログインする 
* マイページが表示されている

## メールアドレスを更新することができる - mailaddress * メールアドレスに"test@uzabase.com"が表示されている * メールアドレスに"update@uzabase.com"を入力する
* 更新ボタンを押下する
* メールアドレスに"update@uzabase.com"が表示されている * DBが更新されている
* 外部のAPIにリクエストが行われている

簡単に書くとこんな感じ。実際のユーザーが行う操作を書いていって、それを結果を評価する。 Documentにあるelementが描画されているのか、そのelementがどの状態なのが、どういう値を持っているのかなどの確認から、DBやElastic Searchにどういう値が保存されたのかや、外部のAPIにちゃんと通信しているのかなどまで検証できるのですごく便利。

自動テストの効果

自動テストは色々効果はあるが、結構書くのに時間がかかる。それに最初自動テストの基盤を作る際には更に時間がかかるでしょ。サービスの開発ではスピードはすごく大事に指標なので逆にテストに時間がかかり過ぎて開発が進まなくなるのは本末転倒である。

それでは自動テストを書くことで消費したコスト（時間）は いつ回収できるのか？

質とスピード（2020秋100分拡大版） / Quality and Speed 2020 Autumn Edition

以前Uzabaseでt_wadaさんの登壇があって、その資料を引用する。 自動テストを書くことで消費したコストはマニュアルテスト3回を回すと逆転する。３回はストーリーの状況では1日もかからない時も多々あるので確実にマニュアルテストより効率的だと言える。

まとめ

なんか色々書いてはいたが、フロントエンドに限っての話ではないので少し滑った感じはしていた。 UI/UXなどの外部品質に関するものを改善するにはテストやCI/CDなどの内部品質を上げる必要がある、と言いたかったが、少し外れたかもなぁと思ったので次回もあればその時でこそ新規プロダクトの話がしたい。

登壇資料 | 新規プロダクト立ち上げとフロントエンド設計