469 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
弊社アプリの仕様確認フローの紹介 2018.09.06 Mobile Act TOKYO #3 Kyosuke Takayama
https://twitter.com/takayama https://github.com/ktakayama
うちのアプリの現状
• •機能が豊富 •条件判断が色々複雑 画面数が豊富
画面数・機能が豊富 = 7年の歴史の積み重ね 家計簿の入力・入力履歴の表示・分析グラフ の表示・レシート撮影・電卓・お気に入り・地図か らお店検索・金融機関連携ステータスの表示・ScanSnap と連携・口座残高や推移グラフの表示・アプリ内から使い方を見た り・問い合わせができたり・自治体の給付金情報や医療費控除を整理できたり、 トクバイ情報とも連携してるし、マルチアカウントに対応してるし、プレミアムな機能もあるし、 なんなら API も公開してるし…………、などなど
• 画面数が豊富 • 機能が豊富 条件判断が色々複雑 • ちゃんとした仕様書はない コードが仕様
1年くらい前から UI の再構築や遷移の整 理をしています
開発フローについて
before
仕様作成 > 実装 > テスト > リリース 🙂普通ですよね
仕様作成 > 実装 > テスト > リリース 🤔開発者「fmfm 仕様があるのか。 よしよしやりながら考えてみるか」
仕様作成 > 実装 > テスト > リリース 🤔「レアケースですけど、○○な状態になった場合の パターンが漏れてました」 😭「この UI の配置だと実装が難しいので別のやり方 にできませんか?」 😅「どうもこの UI だと使いにくい気がしてならない のだけど…」
🤮場合によっては結構なやり直しが 発生するハメに 仕様作成 > 実装 > テスト > リリース 😱仕様作成者「先に言ってくれたら助かった のに」
😱仕様作成者「先に言ってくれたら助かったのに」 🙂開発者「いや、仕様作る時にもっとしっかり 作ってよ」
🙂開発者「いや、仕様作る時にもっとしっかり 作ってよ」 ⭕歴史的経緯の積み重ねなので協力して作り あげましょう
after
目標:できるだけや り直しを減らす
目標:できるだけやり直しを減らす なぜやるか •手戻りが発生すると予定していたスケジュー ルが遅れる やり直しは精神的にも消耗する みんな困る • •
目標:できるだけやり直しを減らす どうやるか •仕様が完成するまでのフローを数段階に分 ける 意見が後出しにならないように、仕様書の レビューにめっちゃ本気出す •
プロフェッショナルレビュー ブランディングレビュー 責任者レビュー 開発チームレビュー
プロフェッショナルレビュー ブランディングレビュー 画面イメージをもとに Prott などで作成したものにた いして、実装の方向性をレビューするフェーズ
プロフェッショナルレビュー ブランディングレビュー 画面イメージをもとに Prott などで作成したものにた いして、実装の方向性をレビューするフェーズ • 開発しづらい仕様になっていないか • メインペルソナである「マリ」にとってわかりやす • いか 「Zaim らしさ」から外れてないか
責任者レビュー プロトタイプを作り込んで改修範囲全体の動作イメー ジを作成したものをレビューするフェーズ
責任者レビュー プロトタイプを作り込んで改修範囲全体の動作イメー ジを作成したものをレビューするフェーズ • 詳細な仕様を作成するために不足している情報がないか • おおまかな工数の把握及びスケジュールに問題が生じないか • 開発チームレビューからのフィードバックの検討
開発チームレビュー 画面や機能ごと、必要に応じて「どんな条件でどんなデータが 表示されるのか・どういった遷移をするのか、スクロールしたらどう なるか?データが少ない場合や空の場合は?日英での違い………」等などと にかくあらゆることを網羅した詳細な仕様書をレビューする フェーズ
開発チームレビュー 画面や機能ごと、必要に応じて「どんな条件でどんなデータが 表示されるのか・どういった遷移をするのか、スクロールしたらどう なるか?データが少ない場合や空の場合は?日英での違い………」等などと にかくあらゆることを網羅した詳細な仕様書をレビューする フェーズ • 仕様に不足や矛盾は生じていないか • 開発のしにくい仕様になっていないか • このプロセス以降の差し戻しをできるだけ避ける目線で見る
結果
やり直しホントに減った 仕様のブラックボックスが減った
会社のブログにもうちょっと細かいところまで書い てあるので、興味があるひとはぜひ見てください https://blog.zaim.co.jp/ 積極採用活動中!!!