機能横断的なチームを作る”場”のデザイン / design the "Ba" of cross-functional team

by Yoshiki Iida

Slide 1

Slide 1 text

機能横断的なチームを作る ”場”のデザイン 2018/09/08 XP祭り2018 Yoshiki Iida

Slide 2

Slide 2 text

自己紹介 2 Yoshiki Iida CrowdWorks Inc. Manager(Now) ← Product Owner ← Scrum Master ← Engineer Twitter: ysk_118 Github: yo-iida

Slide 3

Slide 3 text

3 チーム開発してる人　

Slide 4

Slide 4 text

4 機能横断的なチーム開発してる人　

Slide 5

Slide 5 text

5 チームの機能横断をちゃんと作るのは結構難しい

Slide 6

Slide 6 text

6 機能横断的なチームを作るには”場”が大事

Slide 7

Slide 7 text

今日話すこと » 機能横断的なチームってなに? » “場”ってなに? » “場”を作ってみたらどうなったか? 7

Slide 8

Slide 8 text

機能横断的なチームとは 8

Slide 9

Slide 9 text

機能横断的チームとは » 第一段階 ⋄ 異なる役目を持った人がひとつのチームで仕事をしているチーム » 第二段階 ⋄ チームメンバーがそれぞれの役目を超えて連携しているチーム 9

Slide 10

Slide 10 text

機能横断チームのイメージ 10 PO Designer Engineer PO Designer Engineer 第一段階第二段階

Slide 11

Slide 11 text

デザイン思考の観点から » 第一段階 ⋄ マルチディシプリナリーチーム → 複数分野チーム » 第二段階 ⋄ インターディシプリナリーチーム → 異分野連携チーム 11

Slide 12

Slide 12 text

なぜ機能横断チームがよいのか » ゴールに向かうスピードの向上 ⋄ 個人の暗黙知がチームの形式知化することによって手戻りや考慮漏れによる追加作業が減る » ゴールに到達する可能性の向上 ⋄ 質問、疑問がチーム内で議論されやすくなることでゴールに向かう軌道修正が頻繁に行われる 12

Slide 13

Slide 13 text

なぜ機能横断チームがよいのか » チームのスループット向上 » チームの学習速度向上 → チームのパフォーマンス向上 13

Slide 14

Slide 14 text

なぜ機能横断チームがよいのか » チームのスループット向上 » チームの学習速度向上 → チームのパフォーマンス向上このようなチームの状態を作るには”場”が不可欠 14

Slide 15

Slide 15 text

チームの”場”とは 15

Slide 16

Slide 16 text

「アジャイル開発とスクラム」では “知識を創造し、それを共有、成長させるためには、その知が流通しやすいダイナミックな時空間を作り出す必要がある。この時空間において自分と他者の間に構築される関係性、文脈を「場」と呼ぶ。” 16

Slide 17

Slide 17 text

“場”についての要約 » 時間と空間を共有していて、文書による報告では得られない共感があり、暗黙知が共有されるようなもの » 何気なく起こる質問ややり取りも重要な「場」の一部 17

Slide 18

Slide 18 text

“場”のイメージ 18 人と人との関係性会話のコンテキスト “場”

Slide 19

Slide 19 text

“場”のスケール 19 n人のチームのメンバー間の矢印の数は n(n-1) 人数が増えるとO(n^2)で”場”の形成コストが増加する

Slide 20

Slide 20 text

“場”が機能しないケース信頼関係ができていない » 意見に対して否定から入る » 議論に参加しない » 同意していないのに同意してしまう » 一方的に押し付けられる » etc... コンテキストが共有されない » 使っている言葉が違う » 同じ言葉でイメージするものが違う » 議論の観点がずれている » 情報の非対称性 ⋄ 前提共有ができていない ⋄ リモートからオフィスの付箋が見えない » etc... 20

Slide 21

Slide 21 text

機能横断チームにおいて”場”は前提 » お互いの領域に入り込むのは信頼関係やコンテキスト共有ができてないと難しい » 心理的安全が約束されていることが必要 21

Slide 22

Slide 22 text

“場”を有効活用するには? » スクラムイベントでのみ”場”を活用するのはもったいない » 常に一緒に仕事をすると常にチームとして学習する状態を作れる » モブプロ、モブワークはその一例 22

Slide 23

Slide 23 text

リモートにおける”場” » チームビルディングができていて関係性ができていても、リモートになった途端コンテキスト共有のハードルが非常に上がる » リモートの目的とそれによって得られる価値がコンテキスト共有コストを上回るかを意識する必要がある 23

Slide 24

Slide 24 text

“場”を作ってみた〜 CrowdWorksの場合〜 24

Slide 25

Slide 25 text

きっかけ » PO, エンジニア, デザイナーの開発チーム » マークアップはチーム外に依頼 » 手戻りのコストが大きかった » チーム内のデザイナーがコーディングまでできれば・・ 25

Slide 26

Slide 26 text

課題感 » 当時改修していたのは約250個のカテゴリと4個の依頼形式に対応してフォームが切り替わる巨大な入力フォーム画面 ⋄ 古き良きjQueryによるゴリゴリDOM制御 ⋄ 2000行を超えるCoffeeScript » デザイナーにマークアップ教えるのも結構難しい・・ 26

Slide 27

Slide 27 text

課題感 » 当時改修していたのは約250個のカテゴリと4個の依頼形式に対応してフォームが切り替わる巨大な入力フォーム画面 ⋄ 古き良きjQueryによるゴリゴリDOM制御 ⋄ 2000行を超えるCoffeeScript » デザイナーにマークアップ教えるのも結構難しい・・ 27 → 敵もでかいし、思い切って秘密基地(プロジェクトルーム)作ってモブやるか！

Slide 28

Slide 28 text

Slide 29

Slide 29 text

社内に勝手に秘密基地を作った » 共有スペースにモニターやホワイトボードなどの運び込んで占拠 » チームの施策に関する掲示物を充実させた » おかしも持ち込んで1日中過ごせるようにして、モブプロしてるときも個人作業しているときも居心地よくした 29

Slide 30

Slide 30 text

30 掲示物アルフォート人をだめにするクッション

Slide 31

Slide 31 text

よかったこと » 機能横断の広がり ⋄ POのデータ分析をモブでやる ⋄ POもコード修正する ⋄ エンジニアも施策議論や UIの議論をする ⋄ 受け入れテストをモブでやる » 意思決定スピード向上 ⋄ チームとして軌道修正に慣れる ⋄ サプライズがない » 他チームとの連携もしやすい ⋄ 「基地に集合！」と言えば話しが進む ⋄ 会議室とったり・・とかいらない 31

Slide 32

Slide 32 text

うまくいったと思うポイント » スウォーミングできる雰囲気・距離感 » 雰囲気 = 家感・部室感 » 共通のコンテキストに囲まれている状態 » 自分たちでハックできる空間 32

Slide 33

Slide 33 text

まとめ 33

Slide 34

Slide 34 text

まとめ » “場”とはメンバー同士の信頼関係とコンテキスト共有ができていて心理的安全な時空間 » “場”を作れるとチームのパフォーマンスを引き出すことができ、機能横断的な状態も作りやすい » スウォーミングできる環境を物理的に作るとチームの動きが変わるかも 34

Slide 35

Slide 35 text

ご静聴ありがとうございました 35