kuluna

## 概要 飲食店向けにモバイルーオーダーシステムを提供しているサービスを自社開発で提供しております。 私はSETエンジニアとしてサービスの自動テストを作成・運用・保守しています。 ## 取り組んでいること WebサービスのE2Eテストを作成しています。MagicPodとPlaywrightを使ってテストを行なっています。 メインのリポジトリと開発周期が異なるので異なるリポジトリでテストを構築しました。 毎日リグレッションテストを行い、すぐに挙動の変更に気づけるようにしています。 --- <font color="red">**Appeal Point**</font> E2EテストはUIの変更ですぐ失敗するので、今後のメンテナンス性を考慮しPage Object Patternを採用しています。テストシナリオ内の実際の操作を抽象化して実装することで落ちた箇所を特定、修正しやすくしています。TypeScriptを使いテスト自体の実装ミスも極力減らす工夫もしています。 また最近はノーコードでE2Eテストが可能なMagicPodを積極的にプロジェクトに導入しています。メンテナンス性が非常に高く、コードが読めないQAでもメンテナンスが出来るように取り組んでいます。 その中でもメール本文のテストなどどうしても手が届かないところはGoogleAppScriptを使ってWebAPI経由でテストを実施しその結果をMagicPodに返すという手法をとっています。GASならJavaScriptなのでほとんどのエンジニアでもメンテが可能です。 **自動テストはその有効性だけでなく、保守性についても考えながら作成しています。** --- 自動テストを作成する際にQAがこれまで行ってきたリグレッションテストシナリオを見直しました。 今まで最短経路でなるべく多くの機能に触れるようなシナリオだったものを以下の観点で分割しました。 - ユーザーが実際に利用する想定の操作をなぞる - 自動化できる箇所と手動でないとできないテストをシナリオ中に分けられるようにする 1つめはシナリオに意味を持たせるためと1シナリオを短くするためです。 シナリオが失敗した場合、そのシナリオで想定したペルソナユーザーが影響を受けるためバグの影響度が把握しやすくなります。 また1シナリオが短くなれば単純に保守性があがります。 2つめですが、提供しているモバイルオーダーサービスはWebフロントだけでなく店舗側の端末やプリンターといったハードウェアとの連携も含まれます。これらのリグレッションテストを行う際はどうしても自動テストだけでは全てカバーしきれません。 なので自動テストでできる範囲と手動でないとできない範囲をなるべく固めるようにしました。 例えば、 1. ユーザーが持ち帰り注文する 2. ユーザーに注文確認メールが届く 3. 店舗側が端末で調理完了にする 4. 店舗側が管理画面で売上を確認する というシナリオだった場合、店舗側が端末を操作しなければならない以上これを自動化するのは難しいです。一方で管理画面で売上を確認するのはWebから可能なため、この場合は5を2と3の間に持ってくることで、QAは残りの店舗端末の操作のみだけ手動でテストすれば良いというふうに変更しました。 以上の施策でどうしても手動でやらなければならないテストを除いたほぼ全てのリグレッションテストの自動化を完了させました。 --- テストだけでなく実装コードのコードレビューやペアプロ・ユニットテストの支援なども行っています。 コードが書けないQAに対してSETのスキルを身につける社内勉強会も行っています。

飲食店などの店長さんとアルバイトさんとのコミュニケーションを円滑にするためのアプリ開発に加わりました。 新規事業として企画からMVPの策定、設計、実装・テスト・運用保守までほぼ全てのフェーズに関わっています。 立ち上げ当時は専任のiOSエンジニアがいらっしゃらなかったので、MVP段階では私がiOSとAndroidの両方をネイティブ実装しました。 メンバーが増えてからはAndroidチームのリーダーとしてバックログ管理を行いながら自身も継続して開発を続けています。 現在はiOSチーム4名, Androidチーム1名(自身)の体制です。 ## 常に新しい技術を取り込む 昨今のIDEや言語はバージョンがあがると生産性向上が期待できます。最新情報は常にキャッチアップし、すぐにアップデートして問題なさそうなら次のアプリのアップデートに含めるほどのスピード感で進めていました。 Androidチームでは以下の活動を行いました。 - Androidはプロジェクト初期はLiveData・ViewModel・DataBindingを使ったMVVM構成で作りました。 - 要件にはなかったものの、初めからレスポンシブにViewを作ることでタブレットで使うことも可能にしました。ViewModelを使えば画面回転後も値を保持してくれるのでほぼ全ての画面で画面回転に対応しました。可能な限りAndroid7.0から使えるスマホでのアプリ分割状態で操作ができるようにしました。 - コアのビジネスロジックは最終防衛ラインはもちろんAPIサーバーなのですが、クライアント側でも送信前にわかる範囲で入力チェックしてユーザーに知らせたいので単体テスト可能なオブジェクトにして新しい技術を取り込んでも壊れていないか確認できるようにしました。 - ローカルのプッシュ通知を出したかったのですが、Androidのバージョンが違うと実装ベストプラクティスが変わる状態だった中、JetPackからWorkManagerがリリースされたのでWorkMangerを採用しました。 - フォームのような縦に長い1ページのViewは一度に描画するとパフォーマンスに影響が出るためGroupieを使ってiOSのUITableViewと同じ設計思想を持たせて対応しました。 - Firebase RemoteConfigを使ってマーケティングチームから要望のあった箇所でA/Bテストを実施しました。 - リリースして1年立つとビルド時間と技術的負債が目立ってきたので、マルチモジュール化とクリーンアーキテクチャ化を進めました。現在移行途中ですが、現在14モジュールに分割され、1モジュールの変更なら3秒以内にビルドができるほどまで短縮できました。クリーンアーキテクチャは概念を理解するまでハードルが高いので社内でコーディングガイドラインという形で共有しました。 - Rxは当初から使っておらず、Kotlin Coroutineを導入しました。ViewModelでRepositoryを同期処理のようにかけるのでコールバック地獄がなくなりました。 - 全てのbuild.gradleをkts化しました。 iOS開発チームができてからも最新の開発環境を使い続ける文化が続いており、iOSチームも同じ文化を継承できています。 ## ユーザーのためになるバックログを意識 開発リーダーとなってからはバックログ管理で必ずユーザーストーリーはユーザーのためになるタイトルをつけることをルール化しました。例え社内の都合によって生まれたタスクであっても桶屋メソッドで最終的にはユーザーのためになるようにします。こうすることで全員がユーザーのためにプロダクトを開発しているという意識を持たせることができました。 ## QAやiOSチームとの連携 - 日本においてユーザーへのリリースインパクトが最も強いのはiOSアプリです。私はAndroid開発がメインですが、iOSのタスクが間に合わないと感じた時はPMと相談しスポットでiOSの開発に加わりました。プッシュ通知のハンドリングやアナリティクスイベント仕込み等、他のエンジニアがあまり触手が伸びないようなタスクを積極的に拾い対応しました。QAが対応待ちで手が空きそうなのを見てバグ修正を優先的に対応するといったこともしました。 - AndroidのBuild Variantsを使って社内版のアプリをFirebase App Distribution(旧 Fabric beta)で配布しテストしやすくしました。 ## 開発チーム以外にもエンジニアとしてできることをサポート - CSさんのサポートコストを減らすためにお客様環境を簡単に再現できるツールを勝手に開発しました。 - マーケティングさんをはじめチーム全体で常に追っていきたいデータを確認できるようRe:dashのダッシュボードを作成しました。 ## 一部UIをOSSで公開 シフト管理に必要な高度なUIはOSS化することによってIT業界へ貢献できると考えGitHubで公開しています。 https://github.com/kuluna/EventGridView 現在4名forkしてくださった方がいます。