1. Effective Team Building 2018/2/24 オープンセミナー広島 株式会社アトラクタ取締役CTO アジャイルコーチ 吉羽龍太郎 @ryuzee
2. 株式会社アトラクタのご紹介 ✤ 開発プロセスに関するコンサルティングやトレーニングを提供 ✤ ✤ アジャイル開発 / DevOps / チーム育成 / クラウドコンピューティング / ドメインモデリングなどが専門領域 https://www.attractor.co.jp/
3. 吉羽龍太郎 @ryuzee ✤ 株式会社アトラクタ取締役CTO/アジャイルコーチ ✤ 野村総合研究所、Amazon Web Servicesなどを経て創業 ✤ アジャイル開発/DevOps/クラウドのコンサルティングとトレーニングを提供
4. 新刊のお知らせ ✤ Effective DevOps 4本柱による持続 可能な組織文化の育て方 ✤ 3/24 発売予定 ✤ オライリー 3,888円 ✤ ぜひよろしくお願いします!! ✤ http://bit.ly/EffectiveDevOps
5. ここからの話のコンテキスト設定 複雑な領域 探索 理解 反応 カオスな領域 行動 理解 反応 込み入った領域 無秩序 な領域 理解 分析 反応 ✤ 1チーム〜5チームくらいの規模 を想定 ✤ とてもお硬い領域というよりは 変化の大きい領域の話 ✤ この領域でどう勝てるチームを 作るか 明白な領域 理解 分類 反応
6. “実際のところ、ソフトウェア開発上の問題の多くは、 技術的というより社会学的なものである” –トム・デマルコ/ティモシー・リスター「ピープルウェア」より引用
7. なぜチームが必要なのか？ ✤ 一人でできない規模の仕事をするため ✤ とはいえ、そもそも人が集まっただけではチームではない ✤ ゴールを共有し、各人の持つ色々なスキルを組み合わせて全体の能力を補完し レバレッジするのがチーム
8. よいチームの特徴 ✤ ビジネス上の結果を出し続ける ✤ 変化に対応し続ける ✤ 成長を維持し続ける
9. チームのよくある課題 仕事が多すぎて新しい技術やプロセスを試す時間がない 必要なスキルを持った人が足りない 状況を改善しようにもアイデアがでてこない すぐに人が入れ替わるので仕事のやり方に慣れない メンバーのやる気がない
10. フィードバックサイクルは製品だけ？ Learn Bu il d e r 組織運営やチーム運営にも必要 su a e M
11. 今日の話のスコープ (再掲) 複雑な領域 探索 理解 反応 カオスな領域 行動 理解 反応 込み入った領域 無秩序 な領域 理解 分析 反応 明白な領域 理解 分類 反応
12. みなさんの仕事は単純ですか？ ✤ ✤ もし単純な話だとすると… ✤ 単純な繰り返し作業ならバラつきを減らす方向へ ✤ 自分だけ別のやり方をすることは許容されない ✤ 新しいやり方を提案するのも良く思われにくい ✤ 安定性を重視 つまり機械化されやすい
14. 現在のビジネス状況 ✤ ビジネスの変化がどんどんはやくなっている ✤ VUCA => Volatility (不安定) / Uncertainty (不確実) / Complexity (複雑) / Ambiguity (曖昧) ✤ 多くのサービスがこの10年以内に登場し既存のビジネスモデルに影響を与えた り、人の働き方を変えている。GitHub (2008), Dropbox (2008), Evernote (2008), Slack (2014), Airbnb (2008) , SORACOM (2015) ✤ ITはビジネス上の成果達成のための重要な要素に
15. 問題意識 ✤ 環境の変化についていけないと、ビジネスが頭打ちになる ✤ 売上が伸びないどころか、新たなサービスによってどんどん自分たちの顧客が 奪われていく ✤ こういう問題をなんとかしたい！ ✤ = マーケットや競合などの環境の変化に素早く対応し続け、顧客が必要とする プロダクトやサービスを出し続けられるようになりたい
16. つまり複雑で難しい問題を解決しようとしている
17. 多様性の必要性 複雑な領域 探索 理解 反応 カオスな領域 行動 理解 反応 込み入った領域 無秩序 な領域 理解 分析 反応 ✤ 複雑な問題や遭遇してない問題の解決を 目指す ✤ そのためには多角的な視点で問題の対象 に迫る必要 ✤ フィードバックによる軌道修正 明白な領域 理解 分類 反応
18. 多様性とは？ ✤ 性別そのものと性別の表示 / 人種と民族 • 出身国 / 性的指向 / 年齢 / 障害 / 宗教 / 家庭状況 ✤ 育った環境 / 仕事に対するアプローチ / 物事の見方 ✤ 単に「外形的属性」に限らない
19. 多様性のほかに必要なもの => 心理的安全性
20. プロジェクトアリストテレス ✤ Googleが2012年に開始した労働生産性向上計画プロジェクト ✤ 生産性の高いチームの共通点の洗い出しと成功要因の分析を実施 ✤ 結果や知見をre:Workで公開（https://rework.withgoogle.com/） ✤ NewYork Timesなどでも記事が
23. うまくいっているチームに共通する要素の仮説 ✤ 仕事以外のプライベートでも親しい ✤ 頻繁に飲食をともにしている ✤ 内向的な人同士や外向的な人同士など似た特性の人でチームを構成している ✤ 興味や関心が似ている ✤ 圧倒的なリーダーシップやカリスマ性がある ✤ ボーナスや報酬によるモチベーション ✤ 共通の趣味 ✤ 共通の学歴
25. チームのルールやふるまいに注目 ✤ 個人の能力の合計とチームの能力はイコールではなかった ✤ 個々に対するアプローチより集団に対するアプローチが効果がある ✤ 成果を出したチームにほかのことをやらせても成功するが、失敗するチームは 何をやっても失敗する現象 ✤ よい集団規範の有無が及ぼす影響が大きい ✤ ✤ 不文律・習慣・行動基準（明文化の有無は関係ない） 均等な発言機会と共感力・他者理解力があると成功しやすかった ✤ ＝心理的安全性
26. 機能しないチーム ⑤結果への 無関心 ④説明責任の 回避 ③責任感の不足 ②衝突への恐怖 ①信頼の欠如
28. モダンアジャイル https://www.industriallogic.com/blog/modern-agile/
31. チームの進化 タックマンモデル 形成期 混乱期 統一期 機能期 解散期 人が集まるがまだ独立 しておりコミュニケー ションが少ない 意見を言うようになる が、一方で自分と違う 意見に抵抗を示すよう になる 一緒に活動し、異なる 意見を受け入れる。目 的や期待値などが一致 する よく機能するチームと なる。チームには一体 感がある。自立性が高 い 目的を果たし、チーム が解散する時期
32. チーム形成の初期段階 ✤ ✤ 必要なこと ✤ ゴール(最終的に何を実現するか)を合意する ✤ 目標(短期的にはどこに到達したいか)を合意する ✤ 価値観(自分たちの考え方やゆずれないもの)を合意する だが、いきなりできないので ✤ 相手のことをよく知ろうとするのを合意する ✤ 現時点では合意できないことを合意する ✤ 検討を一緒に継続することを合意する
33. 反対意見の提示と決定事項へのコミット ✤ リーダーは、賛成できない場合には、敬意を もって異議を唱えなければなりません。たと えそうすることが面倒で労力を要することで あっても例外ではありません。リーダーは、 信念をもち、容易にあきらめません。安易に 妥協して馴れ合うことはしません。しかし、 いざ決定がなされたら、全面的にコミットし て取り組みます。 Amazon Leadership Principles
34. 多数決の危険な罠 “昨日今日あったばかりの5名の人間が何かを決める時 多数決は、非常に便利で効率的に思える だがそれは危険で甘い罠!! 決をとるという行為は一見個人の意思を尊重しているように思える しかし実は少数派の意思を抹殺する制度に他ならない!! もしもこの状況で何度も連続して少数派にまわり自分の意思が抹殺されてしまっ たら湧き上がるのは疎外感!!不満!!怒り!!対立 不信そして崩壊” ‒HUNTERxHUNTER 第3巻 (019) / 冨樫義博 / 集英社 / 9784837983415 より
36. 0 この時点で決定を行なうこと自体に反対 1 重大な問題がある。そのまま決定したらアクションを起こす 2 問題がある。もっと話し合いをしたい 3 良いとは思わないが自分はそれでも構わない 4 良いので協力する 5 素晴らしいので自分が実行のリーダーになっても良い
37. チームが成長する上でのリーダーの関与 (SL理論) • SL理論 => リーダーシップの形態はメンバー の成熟度によって変わるという理論 サポート行動 • S1からS4に向かってメンバーが成熟していく S1：指示型。意思決定はリーダーが行う S2：説得型。考えを説明し疑問に答える S3：参加型。意見を聞き意思決定を支援 situational.comから図を引用 指示的行動 S4：移譲型。任せる
38. チームのマネジメント/権限委譲 1 指示する 管理者として意思決定をおこなう 2 売り込む 意思決定についてまわりを納得させる 3 相談する 決定する前にチームの意見を求める 4 同意する チームと一緒に意思決定を下す 5 助言する チームによる意思決定に影響を及ぼす 6 確認する チームによる意思決定後の確認を求める 7 移譲する 特に影響を及ぼさずチームに意思決定を任せる
39. http://jp.techcrunch.com/2010/03/15/20100314key-to-gmail/
40. チームのだいじな責任 ✤ 説明責任（Accountability） ✤ 改善責任（Responsibility）
41. クロスファンクション型チームの必要性 役割分担型 10 9 8 7 6 5 4 3 2 1 0 Day1 ✤ Day2 Day3 クロスファンクション型 Day4 Day5 10 9 8 7 6 5 4 3 2 1 0 Day1 Day2 Day3 Day4 Day5 コンポーネントや役割単位で分割すればするほどウォーターフォール型のように なり、最後まで何も完了しなかったり、追い込みせざるを得なくなる
42. チームのスキル育成 スキルの見える化・リスクの見える化・学習速度向上
43. チームの単一障害点 ✤ 何かあったときどういう問題がおこるか？ ✤ その問題は許容できるか？夜も眠れないような問題なら既に間違っている ✤ 特定の人しか知らない情報を減らす ✤ 自分の仕事を守りたい欲求を捨てる方向に（心理的安全）
44. チームのルール ✤ 外部のルールや標準がパフォーマンス向上の障害になることもある ✤ 盲目的に「ルールや標準だから」で思考停止しない ✤ 意図が分からないもの、形骸化しているものが多くある ✤ 不要なものは廃止するよう働きかける ✤ ルールにないものを「やってはいけない」わけではない ✤ 自分たちのルールを自分たちで作ってカイゼンしていく
45. チームのルール ✤ 外部のルールや標準がパフォーマンス向上の障害になることもある ✤ 盲目的に「ルールや標準だから」で思考停止しない ✤ 意図が分からないもの、形骸化しているものが多くある ✤ 不要なものは廃止するよう働きかける 「わしの言う通りやるやつはバカで、やらんやつはもっとバカ。 ✤ ルールにないものを「やってはいけない」わけではない もっとうまくやるヤツが利口」(大野耐一) ✤ 自分たちのルールを自分たちで作ってカイゼンしていく
46. 機能するチームを簡単に壊さない ✤ 機能するチームを作るのには時間がかかる ✤ プロジェクトに人をアサインするのではなく、チームにプロジェクトをアサイ ンする ✤ 効率より効果 ✤ 稼働率やリソース効率の高さは、成果の質量を満たしてから
47. Werner Vogels, CTO, amazon.com You build it, You run it
48. 2ピザルール チームのサイズを 2枚のピザでみんなが満腹になるサイズに保つ
49. チームメンバーの入れ替え ケース1 一度に半数の人を入れ替えた場合、今 まで築き上げたチームの文化や規律は 失われる覚悟が必要 ケース2 一度に1-2人を入れ替えた場合、新た なメンバーは既存の文化に乗りつつ慣 れた段階で他のチームの文化やノウハ ウを持ち込みやすい
50. 時にはチームの外側を見る必要性もある WIP: 2 2日/ WIP: 4 3日 / WIP: 6 2日/ WIP: 1 20日 / 機能 機能 機能 機能 分析 開発 テスト QA / デプロイ Dev Ops $$$$
51. 前の例をみると… ✤ このケースではリードタイムはとても長い。というのもQA/デプロイが20日も 占めているから。さらに同時に1つしかデプロイできないのでスループットも低 い。ここでDevチームの生産性を向上させても全体のリードタイムとスループッ トの向上はわずか
53. 共通理解の重要性 （どうやって合意を形成していくのか）
54. なぜコミュニケーションが必要か？ ✤ ミッション・ビジョン・ゴール・目的・期待の共有 ✤ 進捗や課題の把握 ✤ コミュニケーション自体は目的ではなく手段
55. コミュニケーションの基本モデル 送 信 済 み 受 信 済 み 理 解 合 意 有 益 な 行 動 へ の 変 換 アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング James Shore (著), Shane Warden (著) / オライリージャパン / 9784873113951 より
56. コミュニケーションの基本モデル 有 益 な 送 受 行 信 信 理 合 動 何かを伝えたからといって行動が起こるとはかぎらない 済 済 解 意 へ み み の 変 換 アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング James Shore (著), Shane Warden (著) / オライリージャパン / 9784873113951 より
57. 同期型コミュニケーション ✤ 同じ時間を共有しておこなう ✤ 多くの人が関係することを集中してやるのに向いている ✤ 参加者全員の時間を消費する問題 ✤ 何かを中断しないといけない問題 ✤ 場所はツールの進化で問題ではなくなりつつある
58. 非同期型コミュニケーション ✤ 異なる時間軸の中でおこなう ✤ 自分でタイミングを制御できる ✤ 割り込みになりにくい ✤ 相手が増えると手間と時間が増える ✤ 意図したことが伝わったかどうかがわかりにくい
59. 同期型と非同期型の例 ✤ 毎日の短い朝会 ✤ 単なる通知や報告 ✤ トラブル対策会議などの緊急時 ✤ 会議の日程調整 ✤ 仕様や優先順位決め ✤ ドキュメントやコードの細部確認 ✤ アイデア出し・ブレインストーミング ✤ 具体的な質問とそれへの回答 ✤ フィードバック ✤ 小さな課題の対応方針検討 ✤ チームの立ち上げ ✤ マイナーバグの報告 ✤ 複数案の比較・検討 ✤ 飲み会の連絡 ✤ ペア作業 ✤ 製品フィードバックの取得
60. 会議 ✤ 会議の目的・参加(希望)者は明らかか ✤ 会議の冒頭でゴールを確認しているか ✤ 終了時に決定事項や宿題を確認しているか ✤ そもそもその会議は必要か ✤ 時間通りに開始しているか ✤ 会議は短く保っているか ✤ 会議を延長していないか ✤ 定時後に会議を設定していないか ✤ 職位を会議に持ち込んでいないか
61. 平均すると、会議の割合が 業務時間の25%を超える？
62. “時間の4分の1以上が会議に費やされているならば、 組織構造に欠陥があると見てよい” –ピーター・F. ドラッカー
63. チームの外部とのコミュニケーション ✤ コンテキストが共有されていないことを理解する ✤ コミュニケーション方法も確立されていない ✤ 従ってチームと外部で対立が発生し相手を責めたくなる ✤ 外部とのコミュニケーションの必要性の頻度が高いのは組織構造が問題 (Devと Opsの問題など) ✤ チームのやり方を見える化する ✤ チーム外とチームのインタフェースを絞り込む
65. 評価面談にて キミはどんな業務してるんだっけ？ （実話）
66. 本当にやりたいことは？ ✤ 人事評価がしたいわけではない ✤ もっと仕事の成果をあげられるようにしたい ✤ もっと大事なことに集中するようにしたい
67. フィードバックサイクルを回す ✤ そもそも変化の速度が早い現在において1年前にたてた目標がそのまま有効で ある保証もない ✤ 変化に対応しうまくやるためにフィードバックサイクルを回す（検査と適応） ✤ 定期的な1:1 (1 on 1) によるフィードバック ✤ 短い間隔での目標管理や業績チェック
68. フィードバックの方法 ✤ もっと頻繁に (毎週〜隔週30分上司と1:1など) ✤ メンタリング、コーチングの色合いも強い ✤ ネガティブなフィードバックも必要 ✤ 個人攻撃ととられないように ✤ 個人攻撃とはとらない ✤ あなた vs わたし ではなく、問題 vs わたしたち ✤ I messageを使う ✤ 対立構造に見える座り方を避ける
69. 1:1 のコツ ✤ キャンセルしない・させない ✤ 上位者はまず相手の話を聞くことに注力 ✤ 単なる状況報告ミーティングにしない ✤ 話したいネタを用意しておく ✤ キャリアについて話をする ✤ メモを取る（PCは避けた方がよいことも） ✤ アクションを決める ✤ 続けながら内容を改善する
70. 最後に… ✤ 予測の難しい変化の早い今の時代では、よいチームがなによりも重要 ✤ よいチームは一朝一夕には作れない ✤ よいチームの土台には心理的安全性が必須 ✤ 心理的に安全だからこそコミュニケーションが有効になってくる ✤ チームをもっとよくするためにはフィードバックサイクルを回し続ける
