アジャイル開発におけるUXについて

スライドシェアにUPしてくださっているので詳細はこちらで。

アジャイル開発におけるUXについて

坪田さんは

• UX Design部のマネジメント
• comm.のプロダクトオーナー
• mobage Platform UI/UX担当

をされています。（commの一番えらい人ってこと？）

クリエイティブグループ→UX Design部に名称を変更した→UXをリードしていこうという意図だそうです。

UXとはどのようなものかという事を定量的に定義した上で、開発のなかでUXDesign部でやっていることを事例にUXデザインについて非常にわかりやすく説明してくださいました。

UX Design

UXの話をすると着地しないことが多い。これは人によって解釈が異なり多くの概念を包括した用語である。

UXとは『システムを利用して人々が持つ体験（経験）』

• UXタイムスパン
• UXのハニカム構造（UX）７つの要素

UXについては以下の書籍が参考になる。

UX デザイナーとは

ユーザーの立場を中心に考えながら様々な方法ロンを組み合わせて課題・要求を解決する。

いけてないUIができる原因

• ユーザーニーズの不理解
• 市場の勉強不足
• コミュニケーション不足
• チューニング不足

UX Designの手法

リサーチ
　↓
要件定義
　↓
開発
　↓
テスト・リサーチ
　↓
リリース
　↓
リサーチに戻る

これら全てに責任をもつのがUX Designer

リサーチの手法

• 定量調査
• 定性調査
• 競合調査

定量調査

アンケートを通じて数値化し分析する

• キャッチコピー
• サービス/機能名
• コア機能のニーズ
• イラスト・キャラクター

定性調査

ユーザーテスト＠アイトラッカー

競合サービス・ペルソナユーザーからにヒアリング

被験者にたいして『commを起動して◯さんと無料通話してください』というような課題をだしその動向を調べる。

競合調査

他のアプリは何が刺さっているのかを調査する。

• ターゲットユーザー
• プロモーション・マーケティング
• デザイン
  • 設計

要件定義 / UI開発

課題を言語化する（ストーリー化）→ワイヤーをいきなり作ってしまうと視野が狭くなってしまう
　↓
問題を解決するための方法をリストアップ
　↓
ペーパープロトタイピングを行う（UI設計）
　↓
モック作成（実機検証）
・モックレベルを実機に当てはめて検証する
・手書きのものでも実機の実寸サイズで作成して触ってみる
・違和感を感じたら何度でも作りなおす
・迷ったら落とす

GUIに起こす

様々なパターンのGUIを作成する。色、パーツなども含めてのビジュアル、グラフィックを作成。

リリーステスト

さらにアイトラッカーでテスト！

• GUIまで実装したものをユーザーテストを実施する
• テキスト・アイコンなどの検証する

ようやくリリース/リリース後のリサーチ

リリーステストを経てようやくリリース。その後のリサーチを行います。

A/Bテスト

• 一定のユーザーにのみ公開
• 半々で出し分けしてテスト
• 特定のセグメントにのみ公開

というような実装のレベルで実験的な要素を含んだリサーチを行うなど。

UI設計で重要なこと

• 徹底的に分析
• プロトタイピング
• ユーザーテストの実施と繰り返し

分析とプロトタイピング、テストという繰り返しがUIの設計に大きな影響を与える。

Scrum開発

Original Update by royskeane

Scrumとは

アジャイル開発の一つ

現場に求められていることは「スピード」「スピード」「スピード」

でも、結局『数字は？』と数字を求められる。

スピード×結果＝Scrum

• 優先度・目的の可視化
• 役割の明確化
• コミュニケーションコストの低減

Scrum FrameWork

• ストーリー
• MTG
• 役割

ストーリー

• 目的を明文化する
• 解決のためのストーリーをリストアップ優先度を決める（プロダクトバックログ）
• ストーリーに一つづつ以下を決める（スプリントバックログ）
  • ゴール（目的共有）
  • タスク分解
  • 見積り
  • 担当決め

目的を明文化しゴールを定めてタスク分解をすると見積りができて担当を決めれば、開発メンバーは開発に専念できる。

MTG

２週間を１スプリントと定めて、第１週月曜日にプランニングMTG、毎日朝会とスタンドアップMTG、最終金曜日にレビューと振り返りを行うことにしている。

毎日スタンドアップMTGを行うことでコミュニケーションロスを少なくする。

役割

プロダクトオーナー、UXデザイナー、チームに分けそれぞれの役割で

• ストーリーの決定（全体統括・プロダクトマネジメント）
• ストーリーの設計（全体設計・UI/仕様の決定）
• ストーリーの分解（部分設計、開発、テスト）

という役割分担をする。

ディレクションはシステム化すればいい。

ディレクションを行う担当者は各種折衝に作業時間の大半を奪われてしまい作業をとる時間がなくなってしまう。

コンセプトは『優先順位を明文化することで自走するチームを作る』

Scrumという体制を整えることによってディレクションをシステム化する。

• ガントチャート→朝回
• MTG→スタンドアップMTG
• タスク管理ツール→タスクボード
• パワポのワイヤー→ホワイトボード
• エライ人との調整→レビュー

専門性

広く浅く知っている一人がすべてをコントロールするのではなく、各スペシャリストが「決定し、作り、改善し、説得する」

専門性の高いメンバーにより部分的に分けることで見積り、仕様考慮もれを防ぎ巻き戻りを防止する。

まとめ

• サービスデザインはエンジニア/クリエイターの領域になってくる
• UI設計はリサーチ・テストが大事超大事
• リリース後の効果分析は徹底的に

Scrumという手法は初めて知ったのですが、非常に理にかなっていて各作業単位に集中できて実に効率的な仕事の仕方かなと想いました。

UXの視点からの開発プロセスについて、LINEの場合とcomm.の場合の違いが聞けたのは非常に勉強になりました。