エンジニアが始めるUX

Transcript

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

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

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

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

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

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

   設計 開発 テスト エンジニアの 守備範囲

6. 背景 6 なぜ始めたのか？

7. 7 例) 源泉徴収票を出力する • 払われた給料が記載されている • 年末になるともらえるアイツ • 確定申告とかに使う UXDエイヤッ時代

   古はUXDなんか考えなくても何とかなっていた。 なぜUXDが必要とされなかった？ • 書類出力だけでユーザに喜ばれた • ユーザの行動はボタンを押すだけ とシンプル

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

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

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

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

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

13. 13 13 要件が決まらなかった例: TODO機能 労務担当者は多くの入社処理をする。 管理するためにはTODO機能があったほうが良いのでは？ 1. 欲しい派 vs なくても良い派

    議論 2. 理想を目指し、途中まで実装 3. リリース間際、かなり簡易版にする TODOの状態を表す アイコンだけ付けた

14. 14 反省: その時何を思ったのか 上流のプロセスでしっかりとした認識合わせが要る。 さもないと、以降のプロセスで問題が大きくなる。 想像で語り合うと 収束しない 『～だと思う』が多かった 根拠が薄弱で どの意見も決め手に欠けた

    実現方法の議論だけでは 製品は形作れない 『～をやるかどうか』の 検 討 を 繰 り 返 すだけでは 製品を作るのは難しい 開発指針が不足 『どのように チームが 動 いて 製 品 を 作 っていくのか』 という 指 針 のないまま、 製品を作るのは難しい

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

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

17. 実行 17 何を行ったのか？

18. 18 実行プロセスの概要 UX Design プロセスを一つずつ実行 愚直に以下を行う。 • 目的を確認 • ユーザ観察

    • モデル化 • MVP導出 Source: https://www.hcdnet.org/docs/Hints%20of%20HCD_vol%201.pdf

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

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

    3. インタビューを記録

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

    ユーザー行動に対するより深い理解を得る方法

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

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

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

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

26. 26 ユーザの理解が深まる ユーザの生の声が聞けることで、ユーザ理解が深まる。 モチベーションが向上する 勤怠情報の収集 給与計算 会計連携 給与明細 人に関する情報収集 法定三帳簿

    税務署への報告 給与振込 所得税納付 社会保険の 納付 住民税納付 その他の情報の収集

27. 27 例) 長期的なコストも勘案できる ロードマップにある機能を トータルでコストを下げるやり方を 考えられるのもエンジニアならでは。 例) 要素の少ない手段で提案 複数の要素が複雑に絡み合う場合、 開発コストが増えることが予想される。

    そういう時に単純化した代替案を 提示できるのはエンジニアならでは。 開発工数を下げられる ユーザに目が向きがちなプロダクトマネージャーやUXデザイナーに 実現コストの低い手段を提案できる Product Management Design Engineering

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

29. つまり

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

31. エンジニアもUXD始めてみよう

32. freee 株式会社 ご清聴ありがとうございました