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

タグ
スライド概要

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

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

profile-image

Kyosuke Takayama

@ktakayama

作者について:

ちわす

スライド一覧
シェア
埋め込む

作成日

2021-03-09 09:20:08

各ページのテキスト

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/ 積極採用活動中!!!