Slide 1

Slide 1 text

Copyright ©A.R.I. All Rights reserved. 1 DX Criteria 読合せ会 ~No1:チーム編(前編)~ 2023年04月28日 中野ヤスオ(@yasuoyasuo)

Slide 2

Slide 2 text

会社紹介 Agenda 1.はじめに 2.チーム編 解説 1. チーム編のポイント 2. 各Criteriaの紹介 1. チーム構成と権限委譲 2. チームビルディング 3. 心理的安全性 4. タスクマネジメント 3.まとめ

Slide 3

Slide 3 text

会社紹介 Agenda 1.はじめに 2.チーム編 解説 1. チーム編のポイント 2. 各Criteriaの紹介 1. チーム構成と権限委譲 2. チームビルディング 3. 心理的安全性 4. タスクマネジメント 3.まとめ

Slide 4

Slide 4 text

4 この勉強会の狙い  想定ターゲット ✓ 日本CTO協会「DX Criteria」を効果的に活用するため 各Criteriaの内容を適切に理解したい人 (一人で黙々とコンテンツを読むのが苦手な人) ✓ 各Criteriaに含まれる専門用語の解説を受けたい人 ✓ DX推進および開発者体験の高いエンジニア組織作りの 一つの型を学びたい人  勉強会の内容 • 各Criteriaの紹介 • 各Criteriaに含まれる専門用語の概要解説

Slide 5

Slide 5 text

5 DXCriteriaの全体像

Slide 6

Slide 6 text

6 Criteriaの構成

Slide 7

Slide 7 text

7 各Criteriaの解説は公式Webページをご覧ください https://dxcriteria.cto-a.org/8a4cd78ec4c546b083f1be075da2106e

Slide 8

Slide 8 text

会社紹介 Agenda 1.はじめに 2.チーム編 解説 1. チーム編のポイント 2. 各Criteriaの紹介 1. チーム構成と権限委譲 2. チームビルディング 3. 心理的安全性 4. タスクマネジメント 3.まとめ

Slide 9

Slide 9 text

9 チーム編の全体像 今日の範囲

Slide 10

Slide 10 text

10 「チーム」編の重要なキーワード • 素早い仮説検証 • 経験主義 • 不確実な世界と向き合う • 小さなチーム • 人間関係の構築 • 事実に基づいた観察 • ふりかえり

Slide 11

Slide 11 text

11 1.チーム構成と権限委譲 https://dxcriteria.cto-a.org/50c8f46047514303900ec17db30f80b6 なぜ重要か • メンバーが多すぎたり、少なすぎたりすると管理を複雑にするばかりでなく、生産性を悪化させてしまう • 高速に仮説検証を行うためには予算・意思決定・実行能力を1つのチームで保つ必要がある 解説あり

Slide 12

Slide 12 text

12 TEAM-1-1: システムを開発する1チームの構成人数は、3人以上10人以下か。(ピ ザ2枚ルール) ハーバード大学の研究者である故J.リチャード・ハックマン氏: プロジェクトチームの最適なメンバー数 通常は6名程度 10人以上のメンバーを持つべきではない 参考: » 心理学者リチャード・ハックマンが暴くチームワークの真実 | doda X キャリアコンパス https://careercompass.doda-x.jp/article/55/

Slide 13

Slide 13 text

13 TEAM-1-2:属人化を洗い出して減らす方法 https://dxcriteria.cto-a.org/d6e71d5f212e4dd28c3639b597fce836 ある特定の人物に属人化した仕事を洗い出し、減らしていく仕組みが チームにあるか。

Slide 14

Slide 14 text

14 TEAM-1-2:トラックナンバーとは? 参考:「トラックナンバー」という言葉をご存知でしょうか?|https://blog.fenrir-inc.com/jp/2013/02/trucknumber.html ある特定の人物に属人化した仕事を洗い出し、減らしていく仕組みが チームにあるか。 トラックナンバー: プロジェクトやチームにおいて「トラックに轢かれるとプロジェクトが立ちゆか なくなったり、チームの活動が困難になる人数」 よく見聞きする方法: ドキュメント書く! → 結構ちゃんとやるの大変・・・ うまくいった方法: ペアプログラミングなどのペア作業 → トラックナンバーが2になる 可読性も上がる

Slide 15

Slide 15 text

15 TEAM-1-3:RACI図とは? 参考:RACIとは?責任と役割分担を明確化!意味と使い方も解説|https://kigyolog.com/article.php?id=981 チームとチームメンバーの権限について、RACI図やデリゲーションポー カーなどによって、可視化され共有されているか。 RACI図(レイシー図と読む) 実行責任者 :R 説明責任者 :A 相談先・協業先 :C 報告先 :I

Slide 16

Slide 16 text

16 TEAM-1-3:デリゲーションポーカーとは? 参考:権限委譲で自己組織化を促す!デリゲーションポーカー×実践的ワークショップのススメ| https://developers.cyberagent.co.jp/blog/archives/13234/ チームとチームメンバーの権限について、RACI図やデリゲーションポー カーなどによって、可視化され共有されているか。 デリゲーションポーカー 7枚のカードを用いて、権限ごとの認識を管理者とメンバーとですり合わせながら権限委譲を行うゲーム 1. 指示する :管理者として意思決定を行う 2. 売り込む :意思決定についての人々を納得させる 3. 相談する :決定する前に、チームからの意見を得る 4. 同意する :チームと一緒に決定を下す 5. アドバイスする :チームによる意思決定に影響を及ぼす 6. 問い合わせる :チームの決定後のフィードバックを求める 7. 移譲する :特に影響を及ぼさずチームに任せる

Slide 17

Slide 17 text

17 TEAM-1-3:デリゲーションポーカーのやり方 参考:権限委譲で自己組織化を促す!デリゲーションポーカー×実践的ワークショップのススメ| https://developers.cyberagent.co.jp/blog/archives/13234/ • 特定の権限(ex:就業時間やツール選択など)に対して、管理者とメンバー(複数可)とでどのレベルの権限 でやるべきだと思っているかを同時にカードを出して示します。 • 権限のレベルが一致しなかった場合、なぜそのレベルだと思ったかをそれぞれ発表します。相手の意見を 踏まえ、再度カードを出します。これを権限のレベルがすり合うまで繰り返します。

Slide 18

Slide 18 text

18 TEAM-1-3:デリゲーションポーカーの結果 参考:権限委譲で自己組織化を促す!デリゲーションポーカー×実践的ワークショップのススメ| https://developers.cyberagent.co.jp/blog/archives/13234/ • 就業時間は管理者の独断で決まる。 • ツール選択はメンバーが決めるが、選択 後に管理者からフィードバックを得る。 • チームボーナスは管理者とメンバーで一 緒に考えて決定を下す。 • 決定した権限はデリゲーションボードと呼ばれるボードに記載していく • 権限の割り振りが可視化されている 例えばこんな感じ・・・

Slide 19

Slide 19 text

19 TEAM-1-4:フィーチャーチームとは? チームは価値提供をするのに必要な全職能のメンバーで構成されてい るか。(フィーチャーチーム) 参考:フィーチャーチームについてまとめてみた - SmartHR Tech Blog |https://tech.smarthr.jp/entry/2022/03/08/165003

Slide 20

Slide 20 text

20 TEAM-1-4:フィーチャーチームとは? チームは価値提供をするのに必要な全職能のメンバーで構成されてい るか。(フィーチャーチーム) メリット • 顧客にとって最良で価値があるものを提供できる • 製品をリリースするまでの時間を短縮できる デメリット • 複数のフィーチャーチーム間のコラボレーションが不 足する可能性がある • (特に専門性に関する)組織内ノウハウが溜まりにくい • チームメンバーはより多くの領域を学ぶ必要がある 参考:フィーチャーチームについてまとめてみた - SmartHR Tech Blog |https://tech.smarthr.jp/entry/2022/03/08/165003

Slide 21

Slide 21 text

21 2.チームビルディング なぜ重要か • システムを改善するチームは、組成してからパフォーマンスするまでに時間がかる • 同じメンバーで継続的に1つのシステムを改善すると学習が進み、開発を高速に行えるが、 あまりに長い期間同じメンバーが継続しすぎると、属人化や改善のサイクルが止まってしまう https://dxcriteria.cto-a.org/50c8f46047514303900ec17db30f80b6

Slide 22

Slide 22 text

22 TEAM-2-2:インセプションデッキとは? チームは月に一度以上の頻度で仕事のふりかえりをおこなっており、 その際にプロジェクト憲章またはインセプションデッキを見返して目 的を再確認しているか。 参考:» インセプションデッキ - NEXTSCAPE blog https://blog.nextscape.net/research/agile/inceptiondeck 1. 我われはなぜここにいるのか(Why1) 2. エレベーターピッチを作る(Why2) 3. パッケージデザインを作る(Why3) 4. やらないことリストを作る(Why4) 5. 「ご近所さん」を探せ(Why5) 6. 解決案を描く(How1) 7. 夜も眠れなくなるような問題は何だろう(How2) 8. 期間を見極める(How3) 9. 何を諦めるのかをはっきりさせる(How4) 10.何がどれだけ必要なのか(How5) インセプションデッキ: プロジェクトの全体像を 端的に伝えるための 10枚のスライド (10個の質問と回答)

Slide 23

Slide 23 text

23 3.心理的安全性 https://dxcriteria.cto-a.org/af072fe11775440b9938973dcb8faca1 なぜ重要か • チームメンバーが相互に自分の意見を言ったとしても、不利益を受けることがない という環境がソフトウェア開発の生産性につながる。このような状態を心理的安全という。 • 心理的安全性についての継続的な投資はチームの生産性につながる。

Slide 24

Slide 24 text

24 TEAM-3-1: チームメンバーの心理的安全性を測る指標があり、定期的に計測して いるか。 参考:» 心理的安全性の作り方・測り方。Google流、生産性を高める方法を取り入れるには | d's JOURNAL(dsj)- 採用で組織をデザインする | 組織文 化・働き方 https://www.dodadsj.com/content/190318_psychological-safety/ チームメンバーに対して 質問をしてみる

Slide 25

Slide 25 text

25 TEAM-3-3: チームメンバーの行動/発言を明示的に承認行為をおこなう習慣がある か。(成果ではなく行動したこと自体に対して、拍手する・感謝を述 べるなど) 参考:https://dxcriteria.cto-a.org/efd44801bd6243a8a002215e55da704a

Slide 26

Slide 26 text

26 TEAM-3-5: チームの不安や不満などを可視化し、吸い上げるための仕組みを持っ ているか。 参考:» Slackで簡単に「日報」ならぬ「分報」をチームで実現する3ステップ ~Problemが10分で解決するチャットを作ろう~ - 株式会社クラフトマン ソフトウェア https://craftsman-software.com/posts/56 チャットで 「分報」を 運用している 事例も

Slide 27

Slide 27 text

27 4.タスクマネジメント https://dxcriteria.cto-a.org/50c8f46047514303900ec17db30f80b6 なぜ重要か • タスクが明文化されないまま口頭などでのやり取りが多かったり、曖昧 な要求が多いとそれだけ手戻りの手間が生じてしまう。 明文化しきれないことも多々あるが、 継続的に基準をアップデートすることでムラのない仕事のスピードを得ることができる。

Slide 28

Slide 28 text

28 TEAM-4-4: チームが仕事を始めるために必要な課題やタスクの粒度について、明 文化されたフォーマットが存在するか。 参考:» ユーザーストーリーとは何か?アジャイル開発におけるユーザー要求について解説 | Promapedia(プロマペディア) https://ssaits.jp/promapedia/method/user-story.html ユーザーストーリーフォーマット: 『<who>として、<what>を達成した い。それは<why>だからだ』 ユーザーストーリー例: 「銀行の顧客として、ATMからお金を引 き出したい。それは購入したいものがある からだ」 「ユーザーストーリーマッピング」を使った要件の表現 例えばシステム機能開発の場合: 事前にテンプレートを固めることで品質を安定させ メンバー同士の期待ギャップを防ぐ

Slide 29

Slide 29 text

29 TEAM-4-5:完了の定義とは? チームのタスクに関して、「完成(完了)の定義(Definition of DONE)」が 存在するか。 参考:» スクラムにおける完了の定義(Doneの定義)とは? https://abi-agile.com/definition-of-done/ 完了の定義例: • コードレビュー済 • 機能テストに合格 • 単体テスト合格 • 統合テストに合格 • リグレッションテストが作成され合 格している • テスト環境にデプロイされている • POはユーザーストーリーの完了を確 認している スクラムのみならず あらゆるタスクで重要

Slide 30

Slide 30 text

30 TEAM-4-7: どのチームタスクであるかが曖昧なとき、ボールが落ちないようにす るための仕組みや文化が存在しない。 https://dxcriteria.cto-a.org/9750f8b7efe443e09414128a93581696

Slide 31

Slide 31 text

江戸下町はなぜ 道の真ん中がきれいなのか? それは お互いが真ん中より向こうまで 掃き合うから 江戸小話 https://speakerdeck.com/yasuoyasuo/dao-falsezhen-nzhong-wokireinisurupuroziekutomanezimento

Slide 32

Slide 32 text

会社紹介 Agenda 1.はじめに 2.チーム編 解説 1. チーム編のポイント 2. 各Criteriaの紹介 1. チーム構成と権限委譲 2. チームビルディング 3. 心理的安全性 4. タスクマネジメント 3.まとめ

Slide 33

Slide 33 text

33 今日のまとめ(イケてる組織とはこんなチーム) • チーム構成と権限委譲 • 小さなフィーチャーチーム、役割権限を可視化、属人排除 • チームビルディング • チームのゴールや方針を可視化し、継続的に共有 • 心理的安全性 • 全員が互いに耳を傾け、尊重し合う • タスクマネジメント • 開始と終了の期待を合意する、分担の可視化/明確化 • 道の真ん中をきれいにする

Slide 34

Slide 34 text

34 最後はいつもの 早く行きたいなら、一人で行け 遠くまでいきたいなら、みんなで行け by アフリカのことわざ

Slide 35

Slide 35 text

35 やってみて欲しいこと ✓ 自分のチームをセルフ チェックしてみる ✓ 改善できそうなことが見つ かれば、リーダーに提案し てみる https://dxcriteria.cto-a.org/07be1dbf832f49eb9720448be01e3c42 何か一つでも改善できることがあれば すぐにトライしてみよう!

Slide 36

Slide 36 text

Copyright ©A.R.I. All Rights reserved. 36 DX Criteria 読合せ会 ~No1:チーム編(前編)~ <END> 2023年04月28日 中野ヤスオ(@yasuoyasuo) 次回:チーム編(後編) 2023/05/11 (木) 18:00 - 19:00@Zoom