プロジェクト事例：新規登録画面リファクタリング
こんにちは、株式会社Antwayのエンジニアの和泉です。
私は主に、LIFF(LINE Front-end Framework)アプリの開発及びチームの開発プロセス改善を行っています。
当社を検討中のエンジニアに、働き方をイメージする参考となればいいなと思い、本記事を書いています。
私の普段の業務にプロセス改善があるため、実際の案件をもとに開発体制やそのプロセスをご紹介したいと思います。
当社ではCTO + 2名の開発体制で、システム関連のタスクは全員がそれぞれ何でも対応しています。
少人数体制だからこそ、適切な優先度の判断、無駄なコミュニケーション・タスクの防止、将来人員増加時にマネジメント不能になるリスクの回避のために現時点から少しづつプロセス整備に取り組んでいます。
現在は、課題発見、仮説検討(企画)、要件定義、設計/開発、検証/評価のプロセスで案件実行されており、この中でKPI設計、機能開発、インフラ構築、開発環境改善などさまざまな案件をこなしています。
今回は最近実施した新規登録画面リファクタリング案件の内容をもとに、実際の開発の様子を説明していきたいと思います。
お伝えしたいポイント
- 案件の企画 〜 開発まで携われるかつ柔軟な開発環境であること
- 当社の開発環境が案件実行やチャレンジ、成長しやすい環境となっていること
- 当社の開発体制が安全で品質高いプロダクト開発を実行できる環境となっていること
新規登録画面とは
「 つくりおき.jp 」は、お客様に毎週料理を提供するサブスクリプションモデルの惣菜デリバリサービスです。
配達先の情報入力や注文設定のために、内製でLINEのLIFFアプリを提供しています。
新規登録画面はこの配達先情報の入力から初期設定登録完了までの一連の画面で、本案件ではこれらをリニューアルしました。
開発プロセス：課題発見
課題発見では、対応する問題に制限は設けずサービス上の課題と考えられる点をどんどん出していきます。
当社では、課題やアイディアはnotion上の各部署のカンバンにてすべて管理されています。
それらのアイディアから、事業上重要だと思われるものや起案者の熱意などによって対応優先順位を決めます。
新規登録画面は、ユーザビリティの観点及び、コード品質の観点で事業毀損が見受けられたため起案しました。
ユーザビリティ観点では、適切なエラー表示の不足や操作性の悪さ、無駄な情報・画面が多いなど、通常利用にも躓くポイントが多々ありました。
コード品質の観点では、現在の開発体制が構築される前の業務委託が中心だった際に、複数のエンジニアが各々の設計思想で拡張されてきていたため、本来シンプルなはずのシステムがロジックや仕様が理解できないスパゲッティコード状態となっていました。
そして、このコード品質の低さがユーザビリティ改善時の既存機能の品質維持を難しくしており、部分的な改修が難しい状態でした。
ユーザビリティ改善としてはCVR改善を目的とし、コード品質観点では保守性の改善を目的として、新規登録時の導線全体を見直す事となりました。
通常は案件実行の妥当性を定量的に示せた方が良いですが、今回は定性でも妥当だと判断できる程度の毀損リスクを合意できたため、そのまま着手しています。
旧新規登録画面デザイン
開発プロセス：仮説検討(企画)
仮説検討では、発見した課題にたいして、目的・課題整理・原因の深堀り、効果検証計画の検討を行います。
要件定義に移行してからの手戻りを避けるため、この時点で課題や目的の曖昧さや不確実性はほとんど検討しきっています。
案件の検証設計やKPI設計などもこの時点で行っています。
新規登録画面リファクタリングでは、フロントエンドからバックエンドまで多くの課題があったので、整理・選別した上で対応するスコープを設定しました。
CEOとCMOと課題内容の認識合わせを行いつつ、CEOとCMOの課題感も拾い上げながらスコープを合意しています。
コード品質観点の課題は、CEOが元エンジニアのためコード状況と課題の説明のみでほぼ実行が合意できました。
ユーザビリティ観点の方針は、あるべきユーザ行動のフローチャートと画面のモックを作成してUX/UIの観点をCEOとCMOの両方から意見をもらいつつ合意しています。
フローチャート作成はdraw.io、画面モックはHTML/CSSで直接作成しています。デザイナと分業する場合は、figmaやscketchなどのデザイン協業ツールを用いても良いと思いますが、このときはデザイン・実装共に自分で行う都合上直接書いた方が早かったのでこの方法をとっています。
現在の新規登録画面デザイン
当時ほぼこの状態の画面モックを作成
開発プロセス：要件定義
要件定義では、仮説検討で設定された課題を解決し、検証計画を実行できる機能の詳細を検討していきます。
e2eテストでBDD(behavior driven development)的にユースケースシナリオと画面項目定義を記述することで、要件定義書兼仕様書としています。そして、それらすべてはGithubにコミットされプルリクエストレビューとその承認をもって、内容共有と合意としています。
レビューは、技術上の不確定要素や、担当者の考慮漏れはほとんど防ぐことができ、開発者とレビュワーで相互に情報の共有がされるため、多くの学びを得る機会を作れているため最も重要なポイントだと考えています。
新規登録画面リファクタリングにおいては、作成した画面モックから必要な機能の要件定義を行いました。
このタイミングで、e2eのテスト方針、開発環境の構築、コード品質を保つための設計・開発方針の定義も同時に行っています。
開発環境はdockerを用いており、エンジニア全員が同じ開発環境を構築できるようになっています。
本来はコード設計方針策定・環境構築・テスト設計方針策定などは単体で案件になるようなものですが、このときはこれらすべて完了をもって要件定義としていました。
このあとは、設計された画面項目定義の機能ごとにチケットを分割してカンバン管理し、1つづつ開発を行って行きます。
案件管理用カンバン
開発プロセス：設計・開発
設計・開発では、要件定義された内容を設計・実装・テスト実装していきます。
内容は要件によって変わりますが、基本的にはe2eのテスト実装、モジュールの実装、ユニットテストの実装を同時に進行していき、テスト実行とプルリクエストに対するレビューで品質担保しています。
実装完了後は、GithubActionsで構築しているCDによってmasterマージ後自動でデプロイされます。
新規登録画面リファクタリングでは、1機能ずつ実装して案件用の統合ブランチにマージしていく形式を用いましたが、1機能毎にテストを実装していたため、後続機能による変更で先行機能の仕様が破壊されていないことが確認できたため、安心して開発をすすめることができました。
本案件は、影響範囲が大きかったため、最後すべての機能実装が完了したのちリリーススケジュールを組んでリリースしています。
開発プロセス：検証・評価
リリース後は、検証計画に基づいて案件の効果分析を行います。
案件に応じて、BigQuery上のログ情報を集計したり、統計的検定を用いた評価を行います。
新規登録画面リファクタリングでも大きく効果改善が見られました。
ユーザビリティ観点では、CVRが案件実施前の2倍程度に増加し、ユーザ行動が整理されたことでこれまで分析できなかったユーザ行動分析が行える様になっています。
コード品質観点については、バグやコード修正時の修正箇所の特定、修正後の影響範囲の特定、仕様の確認が格段に行いやすくなっており、e2eやユニットテストによる仕様の保証も行える状態となっています。
利用されているお客様に直接影響できていること、その効果と価値を実感できるのはかなり楽しいですね。
プロダクトモニタリング画面
まとめ
このように当社では、課題発見、仮説検討、要件定義、設計・開発、検証・評価のプロセスで案件を実施しています。
今回は、全体感をお伝えするために当社内でも大規模な案件で説明しましたが、実際は大小様々な案件がこのプロセスで実行されています。プロダクト改善だけでなく、チームプロセスすらこのプロセスの中で実行されています。
また、必ずしも一人ですべてを実行しなければならないわけではなく、スキルや志向に応じて担当するプロセスや案件を調整しながら開発を行っています。
また、当記事でも記載している通り、大規模な開発は細かいチケットに分割した上で実行されるため、突然大きく重たいタスクを振られることもありません。
もちろん希望されるのであればすべてを1人で実施することもできますし、実施したことがない分野のタスクを小さい案件から徐々にチャレンジすることも可能です。
個人的には、チャレンジしやすい体制を構築できていると思うので、お客様に価値提供に貢献したい方や当社でチャレンジしてみたい方は一度お話できればと思います。
長くなってしまいましたが、ここまで読んでいただきありがとうございました。