1. 強いチームの作り方 Ryuzee.com Ryutaro YOSHIBA (@ryuzee)
2. 強いチームの作り方 自己紹介 Self Introduction 吉羽龍太郎 (@ryuzee) Ryuzee.com TIS → ベンチャー → NRI → ベンチャー → AWS → ??? DevOps・クラウド・アジャイル開発・ 組織関係・寿司が専門領域
3. 実際のところ、ソフトウェア開発上の問題の多 くは、技術的というより社会学的なものである ‒トム・デマルコ/ティモシー・リスター「ピープルウェア」より引用
5. 強いチームの作り方 チームのよくある課題 Common challenges or issues related to team • 仕事が多すぎて新しい技術や プロセスを試す時間がない • 必要なスキルを持った人が足りない • 状況を改善しようにもアイデアがでてこない • すぐに人が入れ替わるので仕事のやり方に慣れない • メンバーのやる気がない
8. あると答えた人。なにかカイゼンはしてますか？
9. 課題を認識しててカイゼンしていないのはさらに質が悪いかも？
11. 強いチームの作り方 カイゼンの進め方 How to improve things around you? • 流れに注目する • 知恵(ソフト)を活用する。ハード(ツール)や手法に頼り過ぎない • 今が最高だと思わない(変わり続ける) • 他でうまくいっていることを真似する • 目標をたてる。To-Beを描き、結果を数字で把握し見えるよう にする • チームで取り組む。現場が主体になって考える
12. 強いチームの作り方 なぜチームが必要？ Why we need team? • 一人ではできない規模の仕事をするため • 人が複数人いればチームになるのか？ => No • 同じゴールを共有し、各人の持つさまざまなスキルを組み合わせ ることで全体の能力を補完しレバレッジするのがチーム • It s not my business なマインドではダメ
13. 強いチームの作り方 チームの形成ステージ Steps for forming a team タックマンモデル ・・・チームの形成ステージ 1 2 3 4 5 形成期 混乱期 統一期 機能期 解散期 人が集まるがまだ独立しておりコ ミュニケーションが少ない 意見を言うようになるが、一方で 自分と違う意見に抵抗を示すよう になる 一緒に活動し、異なる意見を受け 入れる。目的や期待値などが一致 する よく機能するチームとなる。チー ムには一体感がある。自立性が 高い 目的を果たし、チームが解散する 時期 安定して機能するチームを作るには時間がかかる
14. 強いチームの作り方 強いチームの特徴 The characteristics of the strong team • ビジネス上の結果を出し「続けられる」 • 変化に対応できる • 成長を維持できる
15. 強いチームの作り方 弱いチームと強いチームの違い Differences between strong team and weak team 繰り返す能力 結果を出し続けるためにはこれらの能力を常に向上させないといけ ない。繰り返すことでより強くなっていく 状況を把握する能力 必要な能力を身につける能力 あるやり方に慣れるほどそのやり方が想定 していない状況を把握できなくなる。色々 な物の見方をするメンバーが っているこ とが重要 日々の変化に追いつくために必要な新しい技術やスキルを 自分たちで身につけられるようにする。個人の努力ではな くチームとしてどうそれを進めるかを考える必要 対応策を検討する能力 可能な限りの情報を使ってうまくいく方法を模索する能力。ここで も広い範囲から対応策を見つけられるような多様性が必要
17. 強いチームの作り方 多様性の重要さ The importance of diversity • 単純な繰り返し作業の場合はバラつき を減らす方向へ • 自分だけ別のやり方をすることは許容 されず新しいやり方を提案するのも良 く思われにくい。安定性が重視 • したがって機械化されやすい • 複雑な問題の解決を目指す • いままで遭遇したことがない問題や課 題を解決しなければならないことが多 い。そのためには多角的な視点で問題 の対象にせまらないといけない • フィードバックによる軌道修正
18. 強いチームの作り方 多様性がないとどうなるか？ What happens without diversity • 従来のやり方にフィードバックしにくくなる • 文句が外に向けられるのみで現状は変わらない • うまくいっていないことを他の人やツールのせいにする • 思考を停止してあきらめる • モチベーションが下がり組織のリテンションが下がる
19. 強いチームの作り方 合意とアコモデーション Agreement and accommodation ゴール 最終的に何を実現するのか 目標 短期的にはどこに到達した いのか これらの 合意が必要 価値観 自分たちの考え方 相手のことをよく知る 現時点では合意できないことを合意する 検討を一緒に継続することを合意する
20. 強いチームの作り方 反対意見の提示と決定事項へのコミット Have backbone; disagree and commit Amazon Leadership Principles • Leaders are obligated to respectfully challenge decisions when they disagree, even when doing so is uncomfortable or exhausting. Leaders have conviction and are tenacious. They do not compromise for the sake of social cohesion. Once a decision is determined, they commit wholly. • リーダーは、賛成できない場合には、敬意をもって異議を唱えなければなり ません。たとえそうすることが面倒で労力を要することであっても例外では ありません。リーダーは、信念をもち、容易にあきらめません。安易に妥協 して馴れ合うことはしません。しかし、いざ決定がなされたら、全面的にコ ミットして取り組みます。
21. 強いチームの作り方 プランニングポーカー Planning Poker ＜1回目＞ ＜2回目＞ 僕は5ポイントだと思う やっぱ8ポイントだと思う 僕は3ポイントだと思う 僕は3ポイントだと思う 私は2ポイントだと思う やっぱ5ポイントだと思う フィードバックを行なうことで共通理解を得られる
22. 強いチームの作り方 チームの責任 Team’s responsibilities • 説明責任 (Accountability) • 改善責任 (Responsibility)
23. 強いチームの作り方 チームのルール Team's rule 「わしの言う通りやるやつはバカで、やらんやつはもっとバカ。 もっとうまくやるヤツが利口」(大野耐一) • チームのパフォーマンスをあげようとした時に外部のルールや標準が障害 になることもある • 盲目的に「ルールや標準だから」で思考停止しない • 誰が作ったのか意図が分からないもの、形骸化しているものが多くある • 不要なものは廃止するよう働きかける • ルールにないものを「やってはいけない」わけではない
24. 強いチームの作り方 多数決の危険な罠 Dangerous pitfall of majority voting 昨日今日あったばかりの5名の人間が何かを決める時 多数決は、非常に便利で効率的に思える だがそれは危険で甘い罠!! 決をとるという行為は一見個人の意思を尊重しているように思える しかし実は少数派の意思を抹殺する制度に他ならない!! もしもこの状況で何度も連続して少数派にまわり自分の意思が抹殺され てしまったら湧き上がるのは疎外感!!不満!!怒り!!対立 不信そして崩壊 (トンパ) HUNTERxHUNTER 第3巻 (019) / 冨樫義博 / 集英社 / 9784837983415 より
25. 強いチームの作り方 拳から5本指 5 fingers 0 この時点で決定を行なうこと自体に反対 1 重大な問題がある。そのまま決定したらアクションを起こす 2 問題がある。もっと話し合いをしたい 3 良いとは思わないが自分はそれでも構わない 4 良いので協力する 5 素晴らしいので自分が実行のリーダーになっても良い
26. 強いチームの作り方 チームのスキル育成 Skill map Ruby RSpec 阿部 ○ ◎ 坂本 ◎ ○ 長野 ★ 鈴木 ・ 高橋 ・ ・ 片岡 △ △ HTML5 jQuery Elastic Fluentd MongoDB Search ・ △ ・ △ ◎ ◎ ★ AWS Chef Circle CI Git 応 ◎ リテー ション △ △ ◎ ★ ◎ ◎ ◎ ◎ △ ◎ ○ ○ △ ◎ ○ ◎ △ ◎ △ ◎ ファシ △ ◎ △ 設計 障害対 ◎ ○ ○ ○ ◎ ・ ◎ ・ ○ ★：エース / ◎：得意 / ○：一人で出来る / △：助けがあればできる / 空欄：できない / 今後習得したい：・ ◎
27. 強いチームの作り方 個人としてどうスキルアップすべきか？ How to acquire new skill as an individual • 個人として変化に対応するかしないかの問題 • 変化に対応しないことを選ぶなら生殺与奪権は自分以外に移る • とはいえ会社が守ってくれる信仰はもう幻想 • 自分を守るために自分にスキルをつけた方が安心 • 自分にスキルをつけることはもっともROIの高い投資 • 全ての責任は自分にある
28. できない理由を考える前に、 できる方法を考えてくれ。 ‒市村清 リコー初代社長
29. 結局、捨てられない原因を突き詰めていくと、 じつは二つしかありません。それは「過去に対 する執着」と「未来に対する不安」。この二つ だけです。 ‒近藤麻理恵「人生がときめく片付けの魔法」より引用
30. 強いチームの作り方 チームのSPOFをどう扱うか How to handle with Single Point Of Failure • そのSPOFに何かあったときどういう問題がおこるか？ • その問題は許容できるか？夜も眠れないような問題なら既に間違っ ている • 特定の人しか知らない情報を減らす • 自分の仕事を守りたい欲求を捨てる。 外で役にたたないものを 抱え込んで守る意味はない
31. 強いチームの作り方 SL理論 SL Theory • リーダーシップの形態はメンバーの成 熟度によって変わるという理論 • S1からS4に向かってメンバーが成熟 していく サポート行動 S1：指示型。意思決定はリーダーが行う S2：説得型。考えを説明し疑問に答える S3：参加型。意見を聞き意思決定を支援 指示的行動 situational.comから図を引用 S4：委任型。任せる
32. 強いチームの作り方 チームのマネジメント / 権限の委譲レベル Team Management / Seven levels of Authority 1 指示する 管理者として意思決定をおこなう 2 売り込む 意思決定についてまわりを納得させる 3 相談する 決定する前にチームの意見を求める 4 同意する チームと一緒に意思決定を下す 5 助言する チームによる意思決定に影響をおよぼす 6 確認する チームによる意思決定後の確認を求める 7 委譲する 特に影響をおよぼさずチームに意思決定を任せる
33. 強いチームの作り方 チームメンバーの入れ替え Replace team member(s) ケース1 一度に半数の人を入れ替えた場合、今ま で築き上げたチームの文化や規律は失わ れる覚悟が必要 (タックマンモデルを思 い出すこと) ケース2 一度に1-2人を入れ替えた場合、新たな メンバーは既存の文化に乗りつつ慣れた 段階で他のチームの文化やノウハウを持 ち込みやすい 一度に入れ替える人数は少なくする
34. 強いチームの作り方 チームメンバーの採用 Hiring • 一緒に働くことになる人が採用の判断をする • たった数回のインタビューではお互いのことは分からない • Job Descriptionを明確にする。文化への適合性も判断基準に入れる • • チームの平均(または自分)より上であることを基準に入れると チームがスケールしてもチームの能力が低下しにくい 優秀な人の知り合いは優秀であることが多い 良い人を落としてしまうより悪い人を入れてしまう方が問題 なので、悩んだら採用しない
35. 強いチームの作り方 チームメンバーの退職 Resignation 大部分の企業は、退職の統計さえ取っていな い。実際問題として、熟練スタッフが辞めた場 合、比重にどれぐらいのコストがかかるかは誰 にもわからない。その結果生産性を議論すると き、退職はありえない、あるいは、退職しても タダ同然で補充がきくとの前提で話を進める ‒トム・デマルコ/ティモシー・リスター「ピープルウェア」より引用
36. 強いチームの作り方 (参考) 退職の理由 Common termination reasons アメリカ海軍に学ぶ「最強チーム」の作り方 / マイケル アブラショフ / 吉越 浩一郎 三笠書房 / 9784837983415 より • 第一の理由は「上司から大切に扱ってもらえないこと」 • 第二の理由は「積極的な行動を抑えこまれること」 • 第三の理由は「意見に耳を貸してもらえないこと」 • 第四の理由は「責任範囲を拡大してもらえないこと」 • 第五の理由は「給与」
37. 強いチームの作り方 組織構造とアーキテクチャ Organizational structure and Architecture organiza(ons which design systems ... are constrained to produce designs which are copies of the communica(on structures of these organiza(ons - M. Conway 組織構造とプロセスの相性問題 Agile / DevOps / Microservices…
38. 強いチームの作り方 ボトルネックはどこ？ Where’s bottleneck? WIP: 2 2 day / item WIP: 4 3 day / item WIP: 6 2 day / item WIP: 1 20 day / item Analysis Develop Test QA / Deploy Dev $$$$ Ops In this case, cycle Bme is so long due to 20 days for QA and deploy. Throughput is quite small. If you improve the produc(vity of Dev team, it does not affect on total lead (me and throughput…
40. 強いチームの作り方 なぜコミュニケーションが必要？ Why communication needs? • ミッション・ビジョン・ゴール・目的・期待の共有 • 進 • コミュニケーション自体は目的ではなく手段 や課題の把握
41. 強いチームの作り方 コミュニケーション基本モデル(特性) Communication Basic Model 何かを伝えたからといって行動が起こるとはかぎらない 送 信 済 み 受 信 済 み 理 解 合 意 アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング James Shore (著), Shane Warden (著) / オライリージャパン / 9784873113951 より 有 益 な 行 動 へ の 変 換
42. 強いチームの作り方 同期型コミュニケーション Synchronized communication • 同じ時間を共有しておこなう • 多くの人が関係することを集中してやるのに向いている • 参加者全員の時間を消費する問題 • 何かを中断しないといけない問題 • 場所はツールの進化で問題ではなくなりつつある
43. 強いチームの作り方 非同期型コミュニケーション Asynchronous communication • 異なる時間軸の中でおこなう • 自分でタイミングを制御できる • 割り込みになりにくい • 相手が増えると手間と時間が増える • 意図したことが伝わったかどうかがわかりにくい
44. 強いチームの作り方 同期と非同期の例 Examples • 毎日の短い朝会 • 単なる通知や報告 • トラブル対策会議などの緊急時 • 会議の日程調整 • 仕様や優先順位決め • ドキュメントやコードの細部確認 • アイデア出し・ブレインストーミング • 具体的な質問とそれへの回答 • フィードバック • 小さな課題の対応方針検討 • チームの立ち上げ • マイナーバグの報告 • 複数案の比較・検討 • 飲み会の連絡 • ペア作業 • 製品フィードバックの取得
45. 強いチームの作り方 会議 Meeting • 会議の目的・参加(希望)者は明らかか • 会議の冒頭でゴールを確認しているか • 会議の終わりに決定事項や宿題を確認しているか • そもそもその会議は必要か • 時間通りに開始しているか • 会議は短く保っているか • 会議を延長していないか • 定時後に会議を設定していないか • 職位を会議に持ち込んでいないか
46. 平均すると、会議の割合が 業務時間の25%を超える？
47. 時間の4分の1以上が会議に費やされている ならば、組織構造に欠陥があると見てよい ‒ピーター・F. ドラッカー
48. 強いチームの作り方 メール E-mail • タイトルだけで分かるように • 短い文章で、結論を先に • そんなに沢山の人に送らない • 沢山メールが届いても偉くもなんともない • 受信者に何をしてほしいのか？CCに何を期待？ • 受信者が「行動を起こしてくれる」ことを期待しすぎない • もっとうまく出来るツールを使う
49. 強いチームの作り方 チャット Chat • 全員で使う • 情報量をコントロール • 問題解決のディスカッション を大勢でやらない • 他のツールと併用 • ChatOps
50. 強いチームの作り方 ドキュメント共有 Sharing documentations https://teams.qiita.com/から図を引用
51. 強いチームの作り方 ドキュメント共有 Sharing documentations • ドキュメントの鮮度を明確にする。有効期限やバージョンの設定 • 古くて不要なドキュメントは削除するなど、ゴミ箱にしない努力 • タグ付けや検索機能などのアクセシビリティ • どこで何を共有するのか合意する。バージョン管理システムに入 れるべきものもある • 自分からやり続けて周りも巻き込む
52. 強いチームの作り方 外部とのコミュニケーション Communication • コンテキストが共有されていないことを理解する • コミュニケーション方法も確立されていない • 従ってチームと外部で対立が発生し、相手を責めたくなる • そもそも外部とのコミュニケーションの必要性の頻度が高いのは 組織構造が問題 (DevとOpsの問題など) • チームのやり方を見える化する
54. 強いチームの作り方 評価の基本原則 Evaluation Basic Principles • 価値観・優先順位・期待値・求める成果を先に合意し、後出し ジャンケンを避ける • 公平・公正であること • 定量評価と定性評価を組み合わせる。定量評価に寄せすぎると 倫理観が欠如する • 検査と適応。評価自体が目的ではなくうまくやることが目的なの でもっと頻繁に(1-3ヶ月単位で) • ピアレビューの活用
55. 強いチームの作り方 フィードバックの方法 How to do feedback • もっと頻繁に • ネガティブなフィードバックも必要。個人攻撃ととられないよう にする。個人攻撃とはとらない • 対立構造に見える座り方を避ける • あなた vs わたし ではなく、問題 vs わたしたち • I messageを使う
56. 強いチームの作り方 ハンロンの剃刀 Hanlon's razor 「無能で十分説明がつくことに悪意を見出すな」(Robert J. Hanlon) • 自分が相手からどう見えているかを確認するのが下手 • 感情的にならず冷静に考える
