$30 off During Our Annual Pro Sale. View Details »

デザイナーの帽子をかぶりながら、チームとの関わり方を考えつづけている話/How does a designer fit in a Scrum Team?

デザイナーの帽子をかぶりながら、チームとの関わり方を考えつづけている話/How does a designer fit in a Scrum Team?

スクラムフェス大阪2023登壇資料
プロポーザル:https://confengine.com/conferences/scrum-fest-osaka-2023/proposal/18545

Hiromi Morikawa

July 01, 2023
Tweet

More Decks by Hiromi Morikawa

Other Decks in Design

Transcript

  1.  
    Scrum Fest Osaka 2023
    デザイナーの帽子をかぶりながら、
    チームとの関わり方を考えつづけている話
    2023.7.1

    View Slide

  2.  
    2
    freee株式会社
    プロダクトデザイナー
    とある大きな製造業(2009年〜)
     フロントエンド開発 / UXデザイン / アジャイル推進
    freee株式会社(2021年10月〜)
    HCD-Net認定 人間中心設計専門家
    CSPO/A-CSPO/CAL1
    最近の趣味
    森川 裕美(ひろみつ)
    Product Designer
    Hiromi Morikawa
    プロフィール画像の
    トリミング⽅法

    View Slide

  3. 3
    いまはプロダクトデザイナーのぼうしをかぶっています

    View Slide

  4. 4
    昨日の基調講演聞きました?

    View Slide

  5. 5
    本日お話しすること
    話すこと
    ● なぜアジャイルとデザインにこだわるのか、理由となる原体験
    ● 関わるうえでどんな悩みがあるか
    ● 新しいチームのなかにどのようにデザイナーが関わっていったか
    ● ひとつの事例としてのわたしの経験
    話さないこと
    ● デザインプロセスの全体像
    ● 具体的なデザインとスクラムのプロセスのあわせかた、⼿法、フレームワーク

    View Slide

  6. 6
    01 わたしとデザインとチームの出会い
    02 「プロダクトデザイナー」の わたしと、
    「スクラムチーム」
    03 守破離からやり直し貢献を増やす
    04 まとめ
    ⽬次

    View Slide

  7.  
    わたしと
    デザインとチームの出会い

    View Slide

  8. 8
    大学にいくために香川県から福岡へ
    わいは
    デザイン
    やるんじゃ!

    View Slide

  9. 9
    「チームでものづくり」の原体験
    http://www.design.kyushu-u.ac.jp/~festival/tamayura/
    学園祭

    View Slide

  10. 10
    「チームでものづくり」の原体験
    ● 各学科の学⽣で構成
    ○ 環境設計、⼯業設計、⾳響設計、画像設計、芸術情報設計
    ○ 各専⾨分野の学⽣が横断的に集まる
    ● 共通⾔語は「デザイン(芸術⼯学)」
    ○ 個々のスキルを活かしてコンセプトが形になってゆく
    ● 「1たす1が2」ではなくて、掛け合わせて2以上のものができる…!
    ● 熱狂!熱狂!

    View Slide

  11. 11
    「チームでものづくり」の組織

    副頭
    舞台美術班 ⾳響班 映像班 広報班 ⾐装班

    View Slide

  12. 12
    「こんなチームで仕事がしたい」の原点
    ● 今思えばはじめての職能横断チーム
    ● デザインという考え⽅、向かうべきゴールは共通していて、各⾃の得意な能⼒
    を使っている状態
    ● 相⼿の能⼒、考えをリスペクト、⾃分を侵害される恐れもない
    ⼤学という環境なので利害関係も少なく、違いはあれど、強烈な原体験

    View Slide

  13. 13
    芸術工学 = design
    https://design-academia.net/1046/

    View Slide

  14. 14
    技術の人間化 - 技術を人間のために活かす
    技術の人間化を目指すデザイン (平成 17年度第52 回研 究発表 大会 基調講演 )
    https://www.jstage.jst.go.jp/article/jssds/13/3/13_KJ00004289367/_pdf

    View Slide

  15. 15
    人の役にたつものを作りたい…でも
    エンジニアであるわたしがデザインを知り乗りこなすまで

    View Slide

  16. 16
    社会⼈になってこんなことをやってきました
    Front-end Development
    UI Design
    UX
    Now!
    +
    +
    Agile
    + 社内啓蒙
    プロダクトデザイン
    2009〜 2021〜
    Java

    View Slide

  17. 17
    プレイヤーからアジャイルの推進者となって学んだこと
    ● 場の観察やファシリテーションなど、デザイナーの経験を活かせる
    ● UXの知⾒も無関係ではない
    ● アジャイルでやろうとしていることは、プロダクト開発そのものでは?
    ● アジャイルは「チーム」で探索的に「プロダクト」を作っていく活動
    「チームでものづくり」のヒントがありそう!
    UX
    +
    Agile
    + 社内啓蒙
    プロダクトデザイン

    View Slide

  18. 18
    情報アーキテクチャ
    「情報アーキテクチャ設計のプロセスにはその下に横たわる企業内
    の政治的な力関係がはっきりと現れてきます。(中略)設計者は、組
    織構造の政治的環境に敏感でなければなりません。(中略)しかし、
    政治的なことも理解しておけば、それがアーキテクチャに及ぼす影
    響をコントロールすることもできます。」(情報アーキテクチャ p.109-110)
    https://amzn.asia/d/asfG3RC

    View Slide

  19. 19
    "organizations which design systems ... are constrained to produce designs
    which are copies of the communication structures of these organizations."
    Conway's law - Wikipedia
    コンウェイの法則
    「システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう」

    View Slide

  20. 20
    分業が、UI設計でのペインとも繋がっている!
    https://twitter.com/HikaruTayama/status/1111814066845040640

    View Slide

  21. 21
    顧客からはじめ、早期にコラボレーションする
    ・顧客から始めるのがアジャイル
    ・早期から頻繁にコラボレーションするのがアジャイル
    ・不確実性を計画するのがアジャイル
    プロセスやツールの「正しい」実践の先を見据え、
    それぞれの人たちの違いや複雑さを受け入れ、
    より良い方向に向かって一緒に働く方法を見つけることを求める。
    https://amzn.asia/d/e26ZnAh

    View Slide

  22. 22
    チームの外から中に戻る決意
    ● 「開発」はアジャイルになった、では事業は?
    ● 新規事業⽴ち上げ & クローズの繰り返ししか経験のない⾃分が
    プロダクトづくりの⽀援をしていいのか?後ろめたさがあった
    ● ユーザーに使われるプロダクトを成⻑させる経験を積もう
    ● 再度チームの中に⼊り「プロダクトデザイナー」として経験を積むことを決意
    HCD,UX
    +
    Agile
    + 社内啓蒙
    プロダクトデザイン

    View Slide

  23. 23
    プロダクトデザイナー?
    ● ”デザイナー”種類が多すぎ問題
    ○ UIデザイナー、UXデザイナー、サービスデザイナー etc…
    ● freeeには「エクスペリエンスデザイナー(XD)」「プロダクトデザイナー
    (PD)」がいる
    ○ XD:ユーザーリサーチによる課題の発⾒、調査結果に基づくコンセプト検
    討、およびプロジェクトの計画⽴案サポートを実施する
    ○ PD:共通仕様の⽅針やプロダクトデザインの⽅針を決定する。継続して改善
    し、プロダクトをより良い⽅向へ導いていく

    View Slide

  24. 24
    個人的に推しているプロダクトデザインの定義
    What the heck are the differences between product, UX, and UI designers?

    View Slide

  25.  
    「プロダクトデザイナー」
    のわたしと「スクラムチーム」

    View Slide

  26. 26
     
    自動化・可視化を実現する
    これまでにない統合型クラウド会計ソフト

    View Slide

  27. 27
    私が担当している領域
    ・対象ユーザー:会計士さん/税理士さん向け
    ・法人や個人事業主から通帳や領収書などを預かり、記録を代行することがある
    ・この「記帳」の業務が主に担当範囲

    View Slide

  28. 28
    開発しているもの

    View Slide

  29. 29
    不確実性の高いプロダクトづくり
    ● 新しいセグメントのユーザーに受け⼊れられるか?
    ○ インストール型の既存ソフトに近い使い⼼地が必須
    ○ 情報構造が違う=既存ソフトを完全には真似られない
    ○ ⼊り⼝のレベルを下げ、⾃分達の世界に導く設計が必要
    ● 社歴の浅いメンバーで古いコードに向き合う
    ○ 屋台⾻のプロダクトコードに⼿を⼊れるには、深い理解が必要
    アジャイルなプロダクトづくりが向いていそう🤔

    View Slide

  30. 30
    わたしが働いているチーム
    エンジニア
    @名古屋
    プロダクトマネージャー
    QA
    デザイナー
    @東京

    View Slide

  31. 31
    デザイナーも「開発者」の一員
    スクラムガイド2020日本語版
    https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf

    View Slide

  32. 32
    デザイナーも「開発者」の一員
    スクラムガイド2020日本語版
    https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf

    View Slide

  33. 33
    デザイナーも「開発者」の一員
    p.48
    私は開発者という呼び名を⾮常に広い意味で使っている。こ
    の⾔葉が指すのは、ソフトウェアを開発する全ての⼈のこと
    だ。プログラマ、テスター、アナリスト、データベースエン
    ジニア、ユーザビリティエキスパート、テクニカルライ
    ター、アーキテクト、デザイナーなどである。
    p.79
    ここで開発者というとき、そこにはプログラマ、テスター、
    データベースエンジニア、アナリスト、ユーザーインター
    フェイス‧デザイナなど、すべての担当者が含まれることを
    忘れないでほしい。
    https://amzn.asia/d/1iCT05w

    View Slide

  34. 34
    わたしが働いているチーム
    エンジニア
    @名古屋
    プロダクトマネージャー
    QA
    デザイナー
    @東京

    View Slide

  35. 35
    わたしが働いているチーム
    エンジニア
    @名古屋
    プロダクトマネージャー
    QA
    デザイナー
    @東京

    View Slide

  36. と、息巻いてチームに⼊ったものの…

    View Slide

  37. 37
    繰り返す形成期と混乱期
    形成期
    Forming
    チームが
    形成される
    混乱期
    Stoming
    ぶつかり合う
    統一期
    Noming
    共通の規範が
    形成される
    機能期
    Performing
    チームとして
    成果を出す
    散会期
    Adjourming
    チームの
    終結
    タックマンモデル

    View Slide

  38. 38
    繰り返す形成期と混乱期
    ● 頻繁に⼊れ替わる⼈員・・・
    ● ふりかえりで⾔いだせない危機感…
    ● 価値をユーザーに届けたい気持ちはあるのに…リリースできない期間が続く

    View Slide

  39. なぜこんなにうまくいかないんだろう?

    View Slide

  40. 40
    ①チームのエンジニアからの思いがけない反応
    ● ひろみつの動き⽅はfreeeのデザイナーとして異質なのでは?
    ○ デザイナーが少しづつ作っていくやりかたをあまり⾒ない
    ○ 社内の他のデザイナーの標準と合ってる?
    ○ ロードマップはプロダクトマネージャーが作るものでは?
    ● デザイン作業の時間取れてる?
    ○ PRD(製品要求仕様書)を書くからデザイン作業ができないのでは?

    View Slide

  41. 41
    ● 過去に仕事をしたデザイナーはどんな動き⽅をしていた?
    ○ どんなプロダクトで?
    ○ どんなコミュニケーションがあった?
    ● ⾃分とのギャップ
    ○ ⾼速にルック&フィールを決めることを求められているのでは
    ● これまでのデザイナーの印象が理解や期待値になっているのでは?
    ○ 「デザイナー」という帽⼦は被り⼼地が悪いかもしれない…
    あとで思い直して本人に背景を聞いてみた

    View Slide

  42. 42
    こういう距離があったのでは?

    ● プロダクトづくりの話だと思っている
    ● 実験しながらプロダクトデザインする
    ● 複雑なUIは技術⾯とトレードオフ
    ● なぜデザイナーが外に?
    開発からはじまるスクラム
    ● 最初はつくることから
    ● 決まったものをプロダクトバックロ
    グにしたい
    ● クオリティの⾼いUI設計がほしい
    期待値のすれ違い

    View Slide

  43. 43
    ● 「スクラム」と「デザイン」のプロセスは相性がわるい
    ● スクラムのなかにはデザイナーが⼊っていないので疎外感がある
    アジャイルとデザインの関係でたびたび耳にしていたこと
    もしかしてこれか…!という実感

    View Slide

  44. 44
    ②こういうプロセスでやりたいという理想があった
    ● これまでの経験と思い込みからくる慢⼼、⼈と状況を⾒れていない
    ● デザインプロセスの共有も⾜りていなかった
    共通の課題感と知識がないのに焦っていた

    View Slide

  45. 45
    エンジニアからの指摘
    ● デザイナーのほうが壁をつくっているのでは?
    ● エンジニアと⼀緒に考えられる部分もあるのでは?
    ● 全部やろうとしていない?
    ● デザイナーであるということを意識しすぎて、結果的に壁を作っているように
    ⾒えたらしい
    そうか、壁をつくっているのはわたしなのかも…

    View Slide

  46. 46
    かぶる帽子がかわると振る舞いが変わってしまう気づき
    ● チームのなかにいると完全なる当事者
    ● 引いて場を冷静に⾒れない
    ● 出来事に感情で反応してしまう
    推進者
    メンバー
    推進者の距離 当事者の距離

    View Slide

  47. 47
    当時を知っているコーチ曰く
    「ひろみつさん何してんねん」

    View Slide

  48. 動きを変えよう、仕切り直しだ!

    View Slide

  49.  
    守破離からやり直し
    貢献を増やす

    View Slide

  50. 50
    守破離の守からやり直す
    ● ⼀旦求められる動き(Figma作成)をやりつつ、機会を伺うモードに
    ● 新しいエンジニアが増えるのを機に、コーチに⼊ってもらい「守」からやる決
    意をチームでする
    ● 個⼈的にもコーチに助けを求めた
    ○ はじめはプロセスへ積極的に介⼊せずにUI設計に注⼒すること
    ○ 私の⽬から⾒える課題感を伝えること

    View Slide

  51. 51
    観察モードから再出発
    ● UI設計難易度の低い開発エピックのタイミングで⼼に余裕が出てくる
    ● 先にUI設計を全て終えて開発に渡す形式に
    ○ スプリントには参加するが、エラー表⽰や気になる点があれば対応
    ○ UI実装ができた段階で、デザイン⾯をレビュー

    View Slide

  52. 52
    「もやみ」
    ● UI設計観点で修正したいものがPBIに残り続ける
    ● 完成の定義にしてデザイナーもPRを確認すればいいのでは
    ● デザイナーが中に⼊っていたほうがいいのでは?
    ● ふりかえりで少しずつ主張してみる

    View Slide

  53.  
    53
    Figma作業
    もくもく配信
    スプリントレビュー
    をリードしてみる
    同じ本を
    読んでみる
    リリース後の
    様⼦を⾒にいこう
    目の前のできることから
    01 02 03 04

    View Slide

  54. 54
    デザイナーっていつなにしてるの?
    ある⽇のふりかえりでの、コーチのひとこと…
    コーチ「みんな、ひろみつさんがどんな仕事してるか知ってるん?」
    チーム「知らないかも」
    わたし「そっかー(´‧ω‧`) 」
    Figma作業をしているところのありのままを⾒せるTryをしてみることに

    View Slide

  55. 55
    モブ部屋を作って作業を配信してみた

    View Slide

  56. 56
    ● 作業が遅いなって更に思われないだろうか…
    ● 簡単そうだという印象にならないだろうか…
    ● UI設計にダメ出しされたらどうしよう…
    作業をオープンにする怖さ
    https://twitter.com/morozov_dev/status/1563590470504042497

    View Slide

  57. 57
    やってみて起こったこと
    ● 気軽にUI要件の相談ができるように
    ○ UI設計に困っているポイントも共有できる
    ○ 逆に実装の相談も

    View Slide

  58. 58
    次に生まれた「もやみ」
    ● デザイナーの他の思考をどう知ってもらえばいいのだろう?
    ○ Figma上で⾒えている部分以外の活動
    ○ プログラミングが開発の数割でしかないように、Figmaもその⼀部

    View Slide

  59.  
    59
    Figma作業
    もくもく配信
    スプリントレビュー
    でユーザーテスト
    同じ本を
    読んでみる
    リリース後の
    様⼦を⾒にいこう
    目の前のできることから
    01 02 03 04

    View Slide

  60. 60
    それまでのスプリントレビュー
    ● 開発した機能をエンジニアが操作して説明
    ● プロダクトマネージャー(スクラムのPO)やデザイナーが確認する

    View Slide

  61. 61
    「合っているか確認してもらう」「承認してもらう」ものではない
    スプリントレビューってなんだっけ

    View Slide

  62. 62
    もっと効果的にレビューをするにはどうしたらいいのか?
    関係者の⽅々をレビューに呼び、
    説明した結果のフィードバックを受ける
          

    View Slide

  63. 63
    想定シナリオに沿って動くものを触ってもらう
    Tryをやってみることに
    もっと効果的にレビューをするにはどうしたらいいのか?

    View Slide

  64. 64
    「ユーザビリティテストが活かせるのでは!?」
    ● 設計したUIが妥当な設計になっているか、ユーザビリティ問題の発⾒を⾏う
    ● ストーリーに対して、使えるものになっているか確認するのと同じでは
    ● 簡易的なユーザビリティテストを組み込んでみることをリードすることに

    View Slide

  65. 65
    freeeのプロダクトデザイナーが関わるリサーチ
    ユーザビリティテスト
     設計したUIを利用が想定される人に試しに使ってもらい、UIの操作性上の問題を発見すること
     Figmaでの設計段階やプロトタイプ段階など、スプリント外で行うことが多い
    業務観察
     「人々の実践(していること)のありのまま」を、おもに観察とインタビューを組合せて体感・
      理解しようとすること
     ※エスノグラフィを応用したリサーチをfreeeではこう呼んでいます
    プロダクトデザイン
    ユーザビリティ
    テスト
    業務観察
    設計を
    検証する
    得たヒントを
    活かす
    設計を修正する

    View Slide

  66. 66
    スプリントレビューでやった流れ
    ● プロダクトチーム+関係者を呼ぶ
    (ユーザーを良く知っている⼈ or ユーザーに近い⼈)
    ○ カスタマーサクセス
    ○ マーケ
    ● 事前の機能説明などは⾏わず、仮の状況を伝え、実際に使ってもらう
    ● 操作画⾯をシェアしてもらい「考えていること」を声に出してもらう
    ● メンバーはカメラとマイクをオフにして操作を観察
    ● ⼀通り操作が終わったら、操作中に気になった⾏動を深掘りしたり、率直な感
    想を聞く

    View Slide

  67. 67
    提示したシナリオ

    View Slide

  68. 68

    View Slide

  69. 69
    やってみてメンバーからどんな反応があった?
    ● 現場で使うために何が必要かがわかった
    ○ 運⽤を含めた全体の流れのなかで、改善したい箇所が明らかになった
    ○ 連携されたデータを受け取るビジネス部⾨の観点で⾒ることもまたテスト
    ● 開発していると⾒えにくい課題点が⾒えた
    ● モチベーションが上がった
    ○ 直接的に利益を享受する⼈たちが喜んでくれた
    ○ ユーザーが使える、役に⽴ちそうだという⾃信が持てた

    View Slide

  70. 70
    チームのテンションが爆上がりした

    View Slide

  71. 71

    View Slide

  72. 72
    やってみたことで得たもの
    ● 動くものをもとに、早い段階でフィードバックを受ける重要さを体感
    ● エンジニア、QA、デザイナーそれぞれの視点でユーザーの理解度が上がる
    ● スクラムのリズムのなかでデザイナーの専⾨性を発揮して協働できる
    ● 同じものをみることでチームを強化する学習のループを回すことができるかも

    View Slide

  73. 73
    ”ヒアリング”だけではわからない
    ● UI設計の際に、関係者に「どんな課題があるか」事前にヒアリングしていた
    ● 動くものを元にシミュレーションしてみると、出てこなかった課題が出てきた
    ○ なぜ現場で困っているのか
    ○ さらに運⽤を楽にするには何を解決すべきか
    ■ 例:

    View Slide

  74. 74
    やってみたことで起こった変化
    ● スプリントごとに簡易ユーザビリティテストをするように
    ○ 成功体験から、1パターンに定型化してしまう
    ○ 結果「コストかかりすぎでは?毎回やるの?」という声が上がりだす
    ● シナリオはもっと前段階、計画時、PBI作成時に決められるのでは?
    ● 設計に仮説があり確かめたいものだけに絞るという決断をする

    View Slide

  75. 75
    やってみたことで起こった変化
    ● 「レビューの⽅法はこれでいいのか?」あるエンジニアから疑問が上がる
    ○ 実現したいことに近づいているか分かるか?
    ○ ユーザビリティテストではその時点での設計(仮説)検証が主
    ● レビューではなくプロダクトゴールとスプリントゴールが原因では
    ○ チームでゴールとチームの状態、検査するものを計画するように
    ○ 進捗としてレビューで定量のデータも⾒よう

    View Slide

  76. 76
    また生まれる個人的な「もやみ」
    ● ユーザビリティテストでは、その時点で設計/開発したものの設計の妥当性は
    確認できるけれど、ゴールに近づけているかは検証できない
    ● ユーザー候補からのあらゆる要望を、チームが真に受けないためには?
    ○ 「ユーザーは嘘をつくことがある」という知識の共有が必要そう
    ○ ユーザー像が共有されていないと、要望を受け⽌めてしまう⼼配もある
    ○ 「ぴったり」なユーザー像を共有するには?
    ○ それは今実装すべきものか?

    View Slide

  77.  
    77
    Figma作業
    もくもく配信
    スプリントレビュー
    をリードしてみる
    同じ本を
    読んでみる
    リリース後の
    様⼦を⾒にいこう
    目の前のできることから
    01 02 03 04

    View Slide

  78. 78
    とある日のラーニングセッションで
    ● チームが担当している機能の不具合対応をどう扱えばいいか?
    ● 主としているプロダクトの開発を圧迫せず予測可能性を⾼めるには?
    ● プロダクトバックログとポイントの考えかた、バーンアップチャートについて
    ふかぼりして学んだ
    ● チーム内ではアジャイルについての経験差もある

    View Slide

  79. 79
    機運おばさんと化すわたし
    https://amzn.asia/d/1iCT05w

    View Slide

  80. 80
    読書会、はじまる
    ● 毎週1章ずつ
    ● チーム全員参加
    ○ プロダクトマネージャー、エンジニア、QA、プロダクトデザイナー
    ● 事前に読んできて感想を書いておく
    ● 当⽇コメントが盛り上がっていたり疑問に感じることを話し合うスタイル

    View Slide

  81. 81
    実際の読書会メモ

    View Slide

  82. 82
    やってみて起こったこと
    ● チームで同じ話題について議論する場ができた
    ○ 感想以外にも、考えていることや意⾒も表明できる
    ● 「これあの本で読んだやつだ」とチームで共通の語彙ができる
    ○ アジャイルに関する知識の差が埋まる
    ○ ユーザーストーリーやリースプランニング、ゴールについての共通認識
    ● 「これやってみたい」とTryが⽣まれ出す

    View Slide

  83. ”計画づくりとは価値の探求なのだ。”

    View Slide

  84.  
    84
    Figma作業
    もくもく配信
    スプリントレビュー
    をリードしてみる
    同じ本を
    読んでみる
    リリース後の
    様⼦を⾒にいこう
    目の前のできることから
    01 02 03 04

    View Slide

  85. 85
    freeeのプロダクトデザイナーが関わるリサーチの種類
    ユーザビリティテスト
     設計したUIを利用が想定される人に試しに使ってもらい、UIの操作性上の問題を発見すること
     Figmaでの設計段階やプロトタイプ段階など、スプリント外で行うことが多い
    業務観察
     「人々の実践(していること)のありのまま」を、おもに観察とインタビューを組合せて体感・
      理解しようとすること
     ※エスノグラフィを応用したリサーチをfreeeではこう呼んでいます
    プロダクトデザイン
    ユーザビリティ
    テスト
    業務観察
    設計を
    検証する
    得たヒントを
    活かす
    設計を修正する

    View Slide

  86. 86
    リリース後に行ったリサーチの目的
    ● 使い続けている会計事務所と使わなくなった会計事務所の差分は何か?
    ○ 定量データの裏には何が隠れている?
    ○ なぜ使われている?継続利⽤を阻害する⽋点はない?
    ○ 利⽤ユーザーに時系列にヒアリング
    ● あとからチームに参加したエンジニアのユーザー理解向上

    View Slide

  87. 87
    画面外の業務環境を知る意味
    ● デスクの上には何がある?どのような配置で?何のために?
    ○ ディスプレイ、資料、電卓、文房具 etc…
    ● どんなキーボードを使っている?それはなぜ?
    ● 入力している際のキータッチは?右手と左手はどこにある?
    ● 画面外と画面内、どのように見ていそう?
    ● 紙と画面をどのように行き来する?
    ● 画面を操作する前に物理的に準備していることは?
    ● どれくらいの速さで仕事が進んでいる?
    設計のWHYがたくさん隠れている
    ※イメージ

    View Slide

  88. 88
    業務を観察する
    ● 普段業務を行っているデスクの近くにお邪魔する
    ● 見せていただきたい業務を再確認する
    ● 普段通り業務を進めてもらう
    ○ 黙って見る
    ○ 普段の作業を解説するデモにならないように注意する
    ● ひとかたまりの業務を見せていただいた後に、気になる
    行動などをインタビューする

    View Slide

  89. 89
    師匠と弟子のように
    https://www.amazon.co.jp/dp/4274214834
    インタビュアーを弟子、ユーザーを師匠
    と見立てて、師匠の体験を弟子に継承
    するイメージ

    View Slide

  90. 90
    Human Centered Design(HCD)
    人間中心設計の計画 利用状況の把握と
    明示
    ユーザの要求を満たす解決策の
    作成
    ユーザの
    要求事項の明示
    要求事項に対する
    設計の評価
    解決策がユーザーの
    要求事項を満たす
    「ISO 9241-210」で国際規格化されている
    インタラクティブシステムの⼈間中⼼設計に関する規格

    View Slide

  91. 91
    HCDサイクル
    ● デザイナーはHCDに沿ってデザインしたといっても…
    ● ⼯程が縦割りだとアジャイルと組み合わさってなくない?
    ● 要求事項に対する設計の評価は本当にできているのか…?

    View Slide

  92. 92
    やってみてどうだった?

    View Slide

  93. 93
    やってみてどうだった?
    ● 使われているんだという実感
    ● 同じ語彙(ユーザーや業務フロー、速度感、雰囲気、発⾔)で議論できるよう
    になった
    ○ 操作の速度感など⽂字にしにくい感覚の共有
    ○ あの機能や対応はやっぱり必要だ、という肌感
    ○ 提供順や設計への納得感
    ● プロダクトゴールへの距離をチームで実感できた

    View Slide

  94. 94
    続く個人的な「もやみ」
    ● 「課題」は聞いても出てこない、⾒るべきはユーザーのAs-Is
    ● 開発するのはたった1画⾯だが…
    ○ 複数パターンの業務プロセス上で使われる
    ○ 複数の役割のユーザーが利⽤する
    ○ モデル化していないとチームで同じものを⾒れないのでは?
    ● 設計上のトレードオフが複数発⽣するということ
    ○ ⽬先の要望をフラットに扱っているとゴールを⾒失う
    ○ 設計の優先度に影響する
    ○ ゴールに向かうために検証すべき問いか?

    View Slide

  95. 95
    巻き戻していっている感覚
    プロダクトゴール
    スプリントゴール
    設計としての仮説

    View Slide

  96.  
    まとめ

    View Slide

  97. 97
    やってみて思ったこと
    ● 何かをリードすることは、⾃分の仕事を知ってもらうということでもあった
    ○ 「デザイナーの◯◯さん」ではなく、「デザインが得意な◯◯さん」になる
    ● ちょっとずつやっているところを⾒せて、巻き込むということかも
    ○ 最初からきれいなプロセスでやるのは難しい
    ○ ⽬の前のことから
    ○ チームのその時その時に必要そうな情報を取り⼊れることで前進した

    View Slide

  98. 98
    開発者の⼀員として「チームでものづくり」の旅はつづく
    ● デザイナーと協働するときに出てくるフレームワークの話もあるけれど…
    ● デザイナーの守備範囲もチームの理解もその現場次第
    ● プロセスを取り⼊れることに意識がいくと⽬の前の課題がみえなくなる学び
    ● ⽬の前のチームと課題に⽬を向けるのが先かも
    ● デザインのプロセスを巻き戻してさかのぼらせていく
    ● 最終的に融合した状態を⽬指すのはあり
    ● 「みんなで」っていうのはどういうことだろう?
    ○ 合議ではない
    ○ 全員が同じことを同じレベルでできる必要はない、では協働って?

    View Slide

  99. Fin
    わたしの蒼い⿃さがしは続きそうです٩( 'ω' )و

    View Slide