DUOLABS
ポートフォリオ

出張自動車整備予約プラットフォームの刷新

整備マネージャーがユーザーの選んだ時間に自宅前や会社へ出向き、エンジンオイル・バッテリーを交換する出張車両整備サービスで、アプリ2.0刷新の土台となる構造を設計し、基盤を作りました。構想の段階にとどまっていた設計を実際のプロジェクト構造に移す仕事で、既存の出張整備の予約フローはそのまま守る必要がありました。構造があいまいだと、機能が一つ増えるたびに直す箇所が複数の画面に広がります。作業は画面・通信・端末内ストレージの境界を分けるところから、共に働いた開発者との構造の議論と引き継ぎまでです。

Launch
2021
Client
車両管理スタートアップ
Type
車両・ナビゲーション

01 / 04

構想だけだった設計を実際のプロジェクトに移したアプリ構造

出張整備アプリ2.0の刷新は、全体の設計が構想にとどまった状態から始まりました。画面モジュール・データモデル・通信層・端末内ストレージの境界を分け、実際のプロジェクト構造として具体化しました。画面ごとにサーバーへのリクエスト・業務ルール・画面状態・ユーザー入力を分離し、各画面が担う役割をはっきりさせました。新しい機能が入っても既存の境界に触れずに付け足せる形を基準にしました。

構想だけだった設計を実際のプロジェクトに移したアプリ構造
02 / 04

予約・車両情報・サービス商品のリクエストを一つの枠に収めた通信層

出張整備アプリは、出張整備の予約・車両情報・サービス商品のように性格の異なるサーバーリクエストを複数の画面から送ります。ユーザーは車両を登録し、エンジンオイル・バッテリーのような整備商品を選んでから、整備マネージャーが来る時間と場所を決めて予約します。リクエストをドメインごとに整理して同じ枠に収め、非同期で返る応答は一つの流れで受けて画面の状態につなげました。リクエストが増えても、どこに追加しどこで応答を受けるかが一通りに決まります。

予約・車両情報・サービス商品のリクエストを一つの枠に収めた通信層
03 / 04

車両情報と作成中の予約をアプリ内に置く端末内ストレージ

出張整備アプリは、車両情報・ユーザーの状態・一時保存したデータをアプリ内に保持します。このデータのための端末内の保存構造を設計し、ネットワークの状態と画面の流れに応じて必要なデータを取り出し更新するアクセス層を別に整理しました。どのデータを端末に置き、どのデータをサーバーから改めて受け取るかを、この段階で分けました。

車両情報と作成中の予約をアプリ内に置く端末内ストレージ
04 / 04

ジュニアと共にすり合わせ、シニアに引き継いだ設計意図

出張整備アプリの構造は、ジュニア開発者と共に議論しながら実装の方向を検証しました。コードを書くだけでなく、画面状態・通信・端末内ストレージがなぜ分かれるべきかを説明し、それぞれの役割を一緒にすり合わせました。構造の作業を終えた後は、続けて開発するシニア開発者に、設計判断の理由と拡張ポイントまで整理して渡しました。

ジュニアと共にすり合わせ、シニアに引き継いだ設計意図

この仕事のポイント

01

画面・通信・端末内ストレージの境界を分けたアプリ構造

02

予約・車両情報・サービス商品のリクエストを一つの枠で扱う通信層

03

設計判断の理由と拡張ポイントまで渡した引き継ぎ

インサイト

ブログをすべて見る