新機能の開発にあたってデザイナーがやってきたこと
22Inc.のUXデザイナー、台湾出身のヨウソウシです。
先日弊社サービススタンプスの管理画面に新機能がリリースされました。一通り要件定義・設計の段階からデザイン作成・検証・QAまでやってきたので、本記事はそれらのことをまとめたいと思います。
開発手法について
まずは開発手法の話をします。主流な開発手法は、ウォーターフォール開発とアジャイル開発この２つがあり、どちらかと思いますが、弊社では開発の内容によって分けております。
たとえ同じ「新機能の開発」だとしても、内容によって軽い実装と重い実装があります。軽い実装（1スプリント内）であればアジャイル開発で、重いかつ影響範囲の広い開発は、ウォーターフォールでしっかりスケジュールを引いて実装します。
ウォーターフォール開発と言っていますが、もっと正確にいうと「スプリント以外の開発プロジェクト」という感じです。要件が多く、工数も長いプロジェクトは強い前後関係があるので、アジャイルではなく、時系列で「企画→要件定義→デザイン→開発→テスト→リリース」という流れでフェーズを踏んでいくしかありません。
今回の記事はこのようなプロジェクトの新機能開発について話します。
プロジェクトの開発流れ
まずはざっくり流れを洗い出します。
- 課題発見
- 企画
- 要件を固める
- 要件定義
- 開発工数見積もり
- ワイヤー作成
- デザイン作成
- 開発
- QA、テスト
- 社内公開
- リリース
原則としてはこの流れでプロジェクトを推進していきますが、柔軟性を保ちつつ、たとえばデザイン作成の段階でふわっとしている要件を気付いたら3~4に戻って見直してきます。もしくは開発着手してたらデータの持ち方やバリエーションの配慮不足で再度デザインを修正するなどもあったりします。
私1人のデザイナーとして、関わるフェーズはざっくり2の途中から9辺りまでです。次はそれぞれ説明します。
1. 課題発見
もちろん日頃自社サービスを利用して課題（もしくはアイデア）はいくらでも見付けてしまいますが、経営陣の観点でどのような戦略で運営していくのか、ある程度の考え方が具体になってから打ち合わせに同席して一緒に議論します。
2. 企画
CEOとCTOの意見がメインで企画を具体化していきます。経営観点でどのような機能が欲しいのか、それに対してどれくらいの工数・リソースが必要なのか、総合的に判断して最善の企画案を練ります。
3. 要件を固める & 4. 要件定義
企画の段階では方向性を固めて、3.4の段階では「どういうものが欲しいのか」、「どういう風に作るのか」具体的に詰めていきます。
この段階ではなるべく細かい要件定義書を作ります。1人のデザイナーとして、プログラミングの知識がなくても、最低限「どのようなデータをどのように出して、どのような画面になるか」を考えて地道に要件を清書していきます。
5. 開発工数見積もり
要件定義が完成したら、タスクもある程度分解できて、フロントエンド・サーバーサイド・iOS・Androidなどリソースのアサインと工数見積もりもできるようになります。
あとはスプレッドシート作ってエンジニアメンバーに工数記入の依頼をするだけです。
6. ワイヤー作成 & 7. デザイン作成
デザイナーのフル稼働です。イメージの確認・共有の打ち合わせ・修正の繰り返しです。 要件定義の漏れや認識のずれもこのタイミングでビジュアル化によって問題発見できます。
8. 開発
エンジニア陣のフル稼働です。22Inc.ではデザインをsketchで作成してzeplinにアップしています。細かい指示などはzeplinにコメントを入れてエンジニアに伝えますが、どうしても認識のずれが発生するので、この段階では緻密なコミュニケーションがとても大事です。
9. QA、テスト
開発が完了したらステージング環境でQAを回します。QA項目が多い場合はチーム全員手分けしてチェックしていく場合もあります。特に最終的にデザインカンプに沿ってちゃんと作られているか確認します。（基本8の段階ですでに確認しながらですが）
この段階でミスが発見したら、修正・再確認などの作業も発生します。もう一息なのでみんなのテンションも上がってきます。
10. 社内公開
いよいよプロダクトチーム内では完璧の状態です。社内公開して他のチームにも確認してもらいます。
もしこの段階で他のチームから修正が入ったら、最悪な場合は7に戻ってデザインを修正することになります、、が、時間を節約するため口頭でデザインの修正指示出したりします。
11. リリース
問題なければいざリリース。プロジェクトの内容によって、クライアントにメルマガなど事前共有する場合もあり、双方のタイミングを合わせてリリース日を決めます。
デザイナーが開発プロジェクトにあたって気付いたこと
バリエーションをできる限り全て網羅すること
デザイン作成して完成かと思ったら、実装の段階で「このデータがこの場合だとデザインがどうなるの？」とか、エンジニア陣からのツッコミがどんどん来ます。配慮が足りないとあとあとは大変なことになります。
データを意識すること
既存のデータベースにどんなデータがあるのか把握し、これらのデータを使ってこのような表現をしたいというロジックでデザインを作成すると、開発の指示を出すのもかなり楽になります。
「このデータだけで、このような表現はできないだろう、、」など、自分の判断でデザインの可能性を諦めるのも勿体無いので、あくまでも参考程度で、できないと思ったら実はできるという場合もあります。
実装とUXのバランスを考える
何となく作ったデザインで、しかも開発には工数がかかってしまうとお互いに幸せになりません。「ここはなぜこういう風にしたの？実装が大変なので理由が知りたい。」とか突っ込まれたりします。ある程度のプログラミングの知識があるとこういう場面も多少避けれます。
まとめ
直近は色々プロジェクトが同時に進められていて、感じたことをまとめてみましたがいかがでしょうか。22Inc.はこのような感じで毎日開発を進めています。
採用も行なっておりますので一緒にスタンプスを大きくしていく方を絶賛募集中です。
