弊社アプリの仕様確認フローの紹介 / Mobile Act TOKYO #3

459 Views

March 09, 21

スライド概要

Mobile Act TOKYO #3 で、Zaim アプリ開発の際の仕様確認のフローを LT で発表したときのスライドです。
https://mobileact.connpass.com/event/97409/

会社のブログに書いた内容をまとめています。
https://blog.zaim.co.jp/n/n14dbb869cced?magazine_key=mc3188bfc9448

シェア

埋め込む »CMSなどでJSが使えない場合

関連スライド

各ページのテキスト
1.

弊社アプリの仕様確認フローの紹介 2018.09.06 Mobile Act TOKYO #3 Kyosuke Takayama

2.

https://twitter.com/takayama https://github.com/ktakayama

3.

うちのアプリの現状

4.

• •機能が豊富 •条件判断が色々複雑 画面数が豊富

5.

画面数・機能が豊富 = 7年の歴史の積み重ね 家計簿の入力・入力履歴の表示・分析グラフ の表示・レシート撮影・電卓・お気に入り・地図か らお店検索・金融機関連携ステータスの表示・ScanSnap と連携・口座残高や推移グラフの表示・アプリ内から使い方を見た り・問い合わせができたり・自治体の給付金情報や医療費控除を整理できたり、 トクバイ情報とも連携してるし、マルチアカウントに対応してるし、プレミアムな機能もあるし、 なんなら API も公開してるし…………、などなど

6.

• 画面数が豊富 • 機能が豊富 条件判断が色々複雑 • ちゃんとした仕様書はない コードが仕様

7.

1年くらい前から UI の再構築や遷移の整 理をしています

8.

開発フローについて

9.

before

10.

仕様作成 > 実装 > テスト > リリース 🙂普通ですよね

11.

仕様作成 > 実装 > テスト > リリース 🤔開発者「fmfm 仕様があるのか。 よしよしやりながら考えてみるか」

12.

仕様作成 > 実装 > テスト > リリース 🤔「レアケースですけど、○○な状態になった場合の パターンが漏れてました」 😭「この UI の配置だと実装が難しいので別のやり方 にできませんか?」 😅「どうもこの UI だと使いにくい気がしてならない のだけど…」

13.

🤮場合によっては結構なやり直しが 発生するハメに 仕様作成 > 実装 > テスト > リリース 😱仕様作成者「先に言ってくれたら助かった のに」

14.

😱仕様作成者「先に言ってくれたら助かったのに」 🙂開発者「いや、仕様作る時にもっとしっかり 作ってよ」

15.

🙂開発者「いや、仕様作る時にもっとしっかり 作ってよ」 ⭕歴史的経緯の積み重ねなので協力して作り あげましょう

16.

after

17.

目標:できるだけや り直しを減らす

18.

目標:できるだけやり直しを減らす なぜやるか •手戻りが発生すると予定していたスケジュー ルが遅れる やり直しは精神的にも消耗する みんな困る • •

19.

目標:できるだけやり直しを減らす どうやるか •仕様が完成するまでのフローを数段階に分 ける 意見が後出しにならないように、仕様書の レビューにめっちゃ本気出す •

20.

プロフェッショナルレビュー ブランディングレビュー 責任者レビュー 開発チームレビュー

21.

プロフェッショナルレビュー ブランディングレビュー 画面イメージをもとに Prott などで作成したものにた いして、実装の方向性をレビューするフェーズ

22.

プロフェッショナルレビュー ブランディングレビュー 画面イメージをもとに Prott などで作成したものにた いして、実装の方向性をレビューするフェーズ • 開発しづらい仕様になっていないか • メインペルソナである「マリ」にとってわかりやす • いか 「Zaim らしさ」から外れてないか

23.

責任者レビュー プロトタイプを作り込んで改修範囲全体の動作イメー ジを作成したものをレビューするフェーズ

24.

責任者レビュー プロトタイプを作り込んで改修範囲全体の動作イメー ジを作成したものをレビューするフェーズ • 詳細な仕様を作成するために不足している情報がないか • おおまかな工数の把握及びスケジュールに問題が生じないか • 開発チームレビューからのフィードバックの検討

25.

開発チームレビュー 画面や機能ごと、必要に応じて「どんな条件でどんなデータが 表示されるのか・どういった遷移をするのか、スクロールしたらどう なるか?データが少ない場合や空の場合は?日英での違い………」等などと にかくあらゆることを網羅した詳細な仕様書をレビューする フェーズ

26.

開発チームレビュー 画面や機能ごと、必要に応じて「どんな条件でどんなデータが 表示されるのか・どういった遷移をするのか、スクロールしたらどう なるか?データが少ない場合や空の場合は?日英での違い………」等などと にかくあらゆることを網羅した詳細な仕様書をレビューする フェーズ • 仕様に不足や矛盾は生じていないか • 開発のしにくい仕様になっていないか • このプロセス以降の差し戻しをできるだけ避ける目線で見る

27.

結果

28.

やり直しホントに減った 仕様のブラックボックスが減った

29.

会社のブログにもうちょっと細かいところまで書い てあるので、興味があるひとはぜひ見てください https://blog.zaim.co.jp/ 積極採用活動中!!!