エンジニアが始めるUX

Slide 1

Slide 1 text

エンジニアが始めるUX 2018.04.21 freee株式会社 moai

Slide 2

Slide 2 text

何の話？ 2 エンジニアがUXDをやってみた結果、エンジニアもUXDにかかわるべきだと思った。そこに至るまでの話をしようと思います。 ● 背景：なぜ始めたのか？ ● 実行：何を行ったのか？ ● 振り返り：エンジニアがUXDにかかわる価値は何なのか？

Slide 3

Slide 3 text

3 山崎遼介 moai freee株式会社エンジニア 2015/10月にfreeeにjoin。現在は人事労務freee開発チームで要件定義・設計・実装・運用に携わる。

Slide 4

Slide 4 text

4 人事労務ソフトとは勤怠・給与計算・労務手続などの処理をサポートするソフト例) ● 給与明細の発行 ● 年末調整 ● 入退社の手続き

Slide 5

Slide 5 text

5 歴史的な経緯要求定義を詳細に詰める人が不足 freeeの開発体制 freeeでは要件定義の段階からエンジニアがかかわっています。自社サービス要件を変更することで開発コストを下げることもある要求定義要件定義設計開発テストエンジニアの守備範囲

Slide 6

Slide 6 text

背景 6 なぜ始めたのか？

Slide 7

Slide 7 text

7 例) 源泉徴収票を出力する ● 払われた給料が記載されている ● 年末になるともらえるアイツ ● 確定申告とかに使う UXDエイヤッ時代古はUXDなんか考えなくても何とかなっていた。なぜUXDが必要とされなかった？ ● 書類出力だけでユーザに喜ばれた ● ユーザの行動はボタンを押すだけとシンプル

Slide 8

Slide 8 text

8 8 従業員追加チームが混乱したプロジェクトの出現入社の際に必要な情報を入力入社手続きの書類を出力するプロジェクト。情報入力書類出力

Slide 9

Slide 9 text

混乱は多岐にわたりました

Slide 10

Slide 10 text

10 UIフローに関してメンバーの意見が分かれなかなか意見が集約しないメンバーの『思う』を互いにぶつけ合う展開に混乱その1: 要件がなかなか決まらない

Slide 11

Slide 11 text

11 意見が食い違うたびに軋轢を避けようとより理想的なプロダクトを作ることに。結果、工数は増加混乱その2: 工数の増加

Slide 12

Slide 12 text

12 リソースの関係上、強引な決断を何度かした。しかし個々の判断に統一性がなく、メンバーはイライラ混乱その3: メンバーもイライラ

Slide 13

Slide 13 text

13 13 要件が決まらなかった例: TODO機能労務担当者は多くの入社処理をする。管理するためにはTODO機能があったほうが良いのでは？ 1. 欲しい派 vs なくても良い派議論 2. 理想を目指し、途中まで実装 3. リリース間際、かなり簡易版にする TODOの状態を表すアイコンだけ付けた

Slide 14

Slide 14 text

14 反省: その時何を思ったのか上流のプロセスでしっかりとした認識合わせが要る。さもないと、以降のプロセスで問題が大きくなる。想像で語り合うと収束しない『～だと思う』が多かった根拠が薄弱でどの意見も決め手に欠けた実現方法の議論だけでは製品は形作れない『～をやるかどうか』の検討を繰り返すだけでは製品を作るのは難しい開発指針が不足『どのようにチームが動いて製品を作っていくのか』という指針のないまま、製品を作るのは難しい

Slide 15

Slide 15 text

15 人事マスタって何？人事マスタをユーザはどう使うの？難度の高そうなプロジェクトが始まった人事マスタ開発プロジェクト。

Slide 16

Slide 16 text

16 要求定義プロセス学習からスタート @ 2017/12 上流工程ちゃんとやろうユーザの要求を理解して、MVPを作ろうと決意

Slide 17

Slide 17 text

実行 17 何を行ったのか？

Slide 18

Slide 18 text

18 実行プロセスの概要 UX Design プロセスを一つずつ実行愚直に以下を行う。 ● 目的を確認 ● ユーザ観察 ● モデル化 ● MVP導出 Source: https://www.hcdnet.org/docs/Hints%20of%20HCD_vol%201.pdf

Slide 19

Slide 19 text

19 プロジェクトの目的を確認なぜ実行するのかをマネージャー陣からヒアリングをしつつ、ロードマップ等から自分たちのプロジェクトの立ち位置を明確にする 1. 目的を明確にするドキュメントを作成 2. チームに共有

Slide 20

Slide 20 text

20 ユーザにインタビューを行うその機能に関係していた人に、インタビューを実施 1. 誰がいつどのようなことをどのような気持ちで行っていたのか 2. 複数の人からインタビュー 3. インタビューを記録

Slide 21

Slide 21 text

21 モデル化する: ワークモデルを使うモデリングの手法としては、ワークモデルを採用。ワークモデルとは？ Source: ワークモデルとは？ https://u-site.jp/research/methods/work-model/ 5つの視点によるモデル化を通じて構造的に解釈することで、ユーザー行動に対するより深い理解を得る方法

Slide 22

Slide 22 text

22 フロー図行動パターンを洗い出す。モデル化するヒアリングしてきた内容をもとに、行動をモデリング。シーケンス図行動の順番、コミュニケーションを表す Source: ワークモデルとは？ https://u-site.jp/research/methods/work-model/

Slide 23

Slide 23 text

23 23 対象ユーザに必要な機能を洗い出すユーザが実行するタスク毎に必要な機能を洗い出し、MVPを特定。ファンクショナリティマトリクスで行う。

Slide 24

Slide 24 text

振り返り 24 エンジニアが UXDにかかわる価値は何なのか？

Slide 25

Slide 25 text

ユーザの理解が深まる開発工数を下げられるエンジニアの得意領域もある

Slide 26

Slide 26 text

26 ユーザの理解が深まるユーザの生の声が聞けることで、ユーザ理解が深まる。モチベーションが向上する勤怠情報の収集給与計算会計連携給与明細人に関する情報収集法定三帳簿税務署への報告給与振込所得税納付社会保険の納付住民税納付その他の情報の収集

Slide 27

Slide 27 text

27 例) 長期的なコストも勘案できるロードマップにある機能をトータルでコストを下げるやり方を考えられるのもエンジニアならでは。例) 要素の少ない手段で提案複数の要素が複雑に絡み合う場合、開発コストが増えることが予想される。そういう時に単純化した代替案を提示できるのはエンジニアならでは。開発工数を下げられるユーザに目が向きがちなプロダクトマネージャーやUXデザイナーに実現コストの低い手段を提案できる Product Management Design Engineering

Slide 28

Slide 28 text

28 フロー図これはUMLのユースケース図と同じ。エンジニアの得意領域もあるワークモデルはUMLに似ていると思いませんか？古来からの要件定義のスキルが使える。シーケンス図これはUMLのアクティビティ図と同じ。

Slide 29

Slide 29 text

つまり

Slide 30

Slide 30 text

エンジニアがUXDをやる ↓ 今あるスキルを使って最速のMVP導出に貢献できる