1. 強いチームのつくり方 Ryuzee.com Ryutaro YOSHIBA (@ryuzee)
2. 吉羽 龍太郎 http://www.ryuzee.com (@ryuzee) アジャイル開発、DevOps、クラウドコンピューティング(AWS)、インフラ構 築自動化、組織開発を中心としたコンサルティングおよびトレーニングが専門。 野村総合研究所、AWSなどを経て2016年に独立
3. 新刊予定!! 2/26 サーバ/インフラエンジニア養成読本 DevOps編 3/25 カンバン仕事術 ―チームではじめる見える化と改善 3月 VisualizaEon Examples - How great team visualize their work
4. 提供サービスのご案内 アジャイルコーチング Cloud Architecting支援 Agile開発については多くの誤解があり、 ビジネスの成長やシステムの利用状 況に柔軟に対応できるのがクラウド の特性ですが、一方でシステムアー キテクチャがレガシーであればその メリットを享受できません。本支援 ではマイクロサービス化を始めとし て、柔軟で結合度の低いクラウドネ イティブアーキテクチャの構築を支 援します。 また経験の無いチームが自力で行うのは 難易度が高いものです。当方ではオンサイ トでAgile開発での企画∼開発まで全工程 を支援します。例えばプロジェクト立ち上 げに際しての集合研修、ふりかえりや計画 ミーティングのファシリテーションな ど。 DevOps実践支援 DevOpsには組織とツールの2つの要 素があります。サイロ型の組織構造 のDevOps型組織への転換(組織デザ 技術顧問・執筆・講演 技術顧問として定期的に訪問した り、Agile・DevOps・クラウドに関 イン、採用プロセス、評価プロセ する講演をいたします。またWeb・ ス)、ツールによるデプロイ・プロビ 書籍・雑誌など各媒体向けの執筆・ 翻訳を行ないます。 ジョニング・運用・監視の自動化な ど幅広い側面で支援します。 本セッションの再演(1時間+QA)、トレーニング(半日/1日)を承っております(有償)。 お気軽にお問い合わせください。 詳細は http://www.ryuzee.com/service.html をご参照ください
5. 実際のところ、ソフトウェア開発上の問題の多 くは、技術的というより社会学的なものである ‒トム・デマルコ/ティモシー・リスター「ピープルウェア」より引用
8. チームのよくある課題 仕事が多すぎて新しい技術やプロセスを試す時間がない 必要なスキルを持った人が足りない 状況を改善しようにもアイデアがでてこない すぐに人が入れ替わるので仕事のやり方に慣れない メンバーのやる気がない
12. 課題を認識してて カイゼンしていないのは さらに質が悪いかも？
14. カイゼンの進め方 • 流れに注目する • 知恵を活用する。ツールや手法に頼り過ぎない • 今が最高だと思わないで変わり続ける • 他でうまくいっていることを真似する • 目標をたてる。結果を数字で把握し見える化する • チームで取り組む。現場が主体になって考える
15. フィードバックサイクルは製品だけ？ 組織運営にも必要 d Learn Bu il s a e M e r u
17. そもそも人が集まっただけではチームではない
18. Photo credit: Art Dino via VisualHunt / CC BY-SA 一人でできない規模の仕事をするためにチームが必要
19. Photo credit: MTAPhotos via Visual Hunt / CC BY ゴールを共有し、各人の持つ色々なスキルを組み合わせ 全体の能力を補完しレバレッジするのがチーム
20. 強いチームは「続けられる」 ビジネス上の 結果を出す 変化に 対応する 成長を 維持する
22. あなたの仕事は単純なのか？ • 単純な繰り返し作業ならバラつきを減らす方向へ • 自分だけ別のやり方をすることは許容されない • 新しいやり方を提案するのも良く思われにくい • 安定性を重視。したがって機械化されやすい
24. 多様性の必要性 • 複雑な問題や遭遇してない問題の解決を目指す • そのためには多角的な視点で問題の対象に迫る必要 • フィードバックによる軌道修正 Photo credit: MTAPhotos via Visual Hunt / CC BY
25. チームに多様性がないと？ • 従来のやり方にフィードバックしにくくなる • 文句が外に向けられるのみで現状は変わらない • うまくいっていないことを他の人やツールのせいにする • 思考を停止してあきらめる • モチベーションが下がり組織のリテンションが下がる
27. タックマンモデル 形成期 混乱期 統一期 機能期 解散期 意見を言うようにな 一緒に活動し、異な よく機能するチーム 人が集まるがまだ独 るが、一方で自分と る意見を受け入れ となる。チームには 目的を果たし、チー 立しておりコミュニ 違う意見に抵抗を示 る。目的や期待値な 一体感がある。自立 ムが解散する時期 ケーションが少ない すようになる どが一致する 性が高い 安定して機能するチームを作るには時間がかかる
28. 合意とアコモデーション ゴール 目標 価値観 最終的に何を 実現するか 短期的には どこに到達したいか 自分たちの考え方や ゆずれないもの 相手のことを よく知ろうとする のを合意する 現時点では合意で きないことを 合意する 検討を一緒に継続 することを 合意する
29. 反対意見の提示と決定事項へのコミット リーダーは、賛成できない場合には、 敬意をもって異議を唱えなければなり ません。たとえそうすることが面倒で 労力を要することであっても例外では ありません。リーダーは、信念をもち、 容易にあきらめません。安易に妥協し て馴れ合うことはしません。しかし、 いざ決定がなされたら、全面的にコミッ トして取り組みます。 Amazon Leadership Principles Photo credit: sⓘndy° via Visual Hunt / CC BY-SA
30. 多数決の危険な罠 昨日今日あったばかりの5名の人間が何かを決める時 多数決は、非常に便利で効率的に思える だがそれは危険で甘い罠!! 決をとるという行為は 一見個人の意思を尊重しているように思える しかし実は少数派の意思を抹殺する制度に他ならない!! もしもこの状況で何度も連続して少数派にまわり自分の 意思が抹殺されてしまったら 湧き上がるのは疎外感!!不満!!怒り!!対立 不信そして崩壊 ‒HUNTERxHUNTER 第3巻 (019) / 冨樫義博 / 集英社 / 9784837983415 より
32. 0 この時点で決定を行なうこと自体に反対 1 重大な問題がある。そのまま決定したらアクションを起こす 2 問題がある。もっと話し合いをしたい 3 良いとは思わないが自分はそれでも構わない 4 良いので協力する 5 素晴らしいので自分が実行のリーダーになっても良い
33. プランニングポーカー ＜1回目＞ ＜2回目＞ 僕は5ポイントだと思う やっぱ8ポイントだと思う 僕は3ポイントだと思う 僕は3ポイントだと思う 私は2ポイントだと思う やっぱ5ポイントだと思う フィードバックを行なうことで共通理解を得られる
34. チームのだいじな責任 • 説明責任 (Accountability) • 改善責任 (Responsibility)
35. チームのルール • 外部のルールや標準がパフォーマンス向上の障害になることもある • 盲目的に「ルールや標準だから」で思考停止しない • 意図が分からないもの、形骸化しているものが多くある • 不要なものは廃止するよう働きかける • ルールにないものを「やってはいけない」わけではない • 自分たちのルールを自分たちで作ってカイゼンしていく 「わしの言う通りやるやつはバカで、やらんやつはもっとバカ。 もっとうまくやるヤツが利口」(大野耐一)
36. できない理由を考える前に、 できる方法を考えてくれ。 ‒市村清 リコー初代社長
37. チームのスキル育成 スキルの見える化・リスクの見える化・学習速度向上 Ruby RSpec 阿部 ○ ◎ 坂本 ◎ ○ 長野 ★ 鈴木 ・ 高橋 ・ ・ 片岡 △ △ HTML5 jQuery Elastic Fluentd MongoDB Search ・ △ ・ △ ◎ ◎ ★ AWS Chef Circle CI Git 応 ◎ リテー ション △ △ ◎ ★ ◎ ◎ ◎ ◎ △ ◎ ○ ○ △ ◎ ○ ◎ △ ◎ △ ◎ ファシ △ ◎ △ 設計 障害対 ◎ ○ ○ ○ ◎ ・ ◎ ・ ○ ★：エース / ◎：得意 / ○：一人で出来る / △：助けがあればできる / 空欄：できない / 今後習得したい：・ ◎
38. 個人としてどうスキルアップ？ • 個人として変化に対応するかしないかの問題 • 変化に対応しないことを選ぶなら生殺与奪権は自分以外に移る • とはいえ会社が守ってくれる信仰はもう幻想 • 自分を守るために自分にスキルをつけた方が安心 • 自分にスキルをつけることはもっともROIの高い投資 • 全ての責任は自分にある Photo credit: Leadnow via VisualHunt.com / CC BY-SA
39. 結局、捨てられない原因を突き詰めていくと、 じつは二つしかありません。それは「過去に対 する執着」と「未来に対する不安」。この二つ だけです。 ‒近藤麻理恵「人生がときめく片付けの魔法」より引用
40. チームの単一障害点 何かあったときどういう問題がおこるか？ その問題は許容できるか？ 夜も眠れないような問題なら 既に間違っている 特定の人しか知らない情報を減らす 自分の仕事を守りたい欲求を捨てる。 外で役にたたないものを 抱え込んで守る意味はない
41. SL理論 • リーダーシップの形態はメンバーの成 熟度によって変わるという理論 • S1からS4に向かってメンバーが成熟 していく サポート行動 S1：指示型。意思決定はリーダーが行う S2：説得型。考えを説明し疑問に答える S3：参加型。意見を聞き意思決定を支援 指示的行動 situational.comから図を引用 S4：委任型。任せる
42. チームのマネジメント/権限委譲 1 指示する 管理者として意思決定をおこなう 2 売り込む 意思決定についてまわりを納得させる 3 相談する 決定する前にチームの意見を求める 4 同意する チームと一緒に意思決定を下す 5 助言する チームによる意思決定に影響をおよぼす 6 確認する チームによる意思決定後の確認を求める 7 委譲する 特に影響をおよぼさずチームに意思決定を任せる
43. チームメンバーの入れ替え ケース1 一度に半数の人を入れ替えた場合、 今まで築き上げたチームの文化や規 律は失われる覚悟が必要 (タックマ ンモデルを思い出すこと) ケース2 一度に1-2人を入れ替えた場合、新 たなメンバーは既存の文化に乗りつ つ慣れた段階で他のチームの文化や ノウハウを持ち込みやすい 一度に入れ替える人数は少なくする
44. チームメンバーの採用 • 一緒に働くことになる人が採用の判断をする • たった数回のインタビューではお互いのことは分からない • • • • 良い人を落としてしまうより Job Descriptionを明確にする。 悪い人を入れてしまう方が問題なので、 文化への適合性も判断基準に入れる 悩んだら採用しない チームの平均より上であることを基準に入れると チームがスケールしてもチームの能力が低下しにくい 優秀な人の知り合いは優秀であることが多い
45. チームメンバーの退職 大部分の企業は、退職の統計さえ取っていな い。実際問題として、熟練スタッフが辞めた場 合、比重にどれぐらいのコストがかかるかは誰 にもわからない。その結果生産性を議論すると き、退職はありえない、あるいは、退職しても タダ同然で補充がきくとの前提で話を進める ‒トム・デマルコ/ティモシー・リスター「ピープルウェア」より引用
46. (参考)退職の理由 アメリカ海軍に学ぶ「最強チーム」の作り方 / マイケル アブラショフ / 吉越 浩一郎 三笠書房 / 9784837983415 より • 第一の理由は「上司から大切に扱ってもらえないこと」 • 第二の理由は「積極的な行動を抑えこまれること」 • 第三の理由は「意見に耳を貸してもらえないこと」 • 第四の理由は「責任範囲を拡大してもらえないこと」 • 第五の理由は「給与」 Photo credit: MTAPhotos via Visual Hunt / CC BY
47. 組織構造はアーキテクチャに影響を与える システムを設計する組織は、その構造をそっ くりまねた構造の設計を生み出してしまう ‒メルヴィン・コンウェイ (コンウェイの法則)
48. Microservicesに関心があるかもしれないが、 それを実現できるかどうかは自分の組織構造に大きく依存。 過度な幻想を抱かないこと Photo credit: kennymatic via VisualHunt / CC BY
49. チームの外側を見る必要性 WIP: 2 2日/ 機能 WIP: 4 3日 / 機能 WIP: 6 2日/ 機能 WIP: 1 20日 / 機能 分析 開発 テスト QA / デプロイ Dev $$$$ Ops このケースではリードタイムはとても長い。というのもQA/デプロイが20日も占めているから。さら に同時に1つしかデプロイできないのでスループットも低い。ここでDevチームの生産性を向上させて も全体のリードタイムとスループットの向上はわずか
51. なぜコミュニケーションが必要？ ミッション・ビジョ ン・ゴール・目的・ 期待の共有 進 や課題の 把握 コミュニケーショ ン自体は目的では なく手段 Photo via visualhunt.com
52. コミュニケーション基本モデル 何かを伝えたからといって行動が起こるとはかぎらない 送 信 済 み 受 信 済 み 理 解 合 意 アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング James Shore (著), Shane Warden (著) / オライリージャパン / 9784873113951 より 有 益 な 行 動 へ の 変 換
53. 同期型コミュニケーション • 同じ時間を共有しておこなう • 多くの人が関係することを集中してやるのに向いている • 参加者全員の時間を消費する問題 • 何かを中断しないといけない問題 • 場所はツールの進化で問題ではなくなりつつある
54. 非同期型コミュニケーション • 異なる時間軸の中でおこなう • 自分でタイミングを制御できる • 割り込みになりにくい • 相手が増えると手間と時間が増える • 意図したことが伝わったかどうかがわかりにくい
55. 同期と非同期の例 • 毎日の短い朝会 • 単なる通知や報告 • トラブル対策会議などの緊急時 • 会議の日程調整 • 仕様や優先順位決め • ドキュメントやコードの細部確認 • アイデア出し・ブレインストーミング • 具体的な質問とそれへの回答 • フィードバック • 小さな課題の対応方針検討 • チームの立ち上げ • マイナーバグの報告 • 複数案の比較・検討 • 飲み会の連絡 • ペア作業 • 製品フィードバックの取得
56. 会議 • 会議の目的・参加(希望)者は明らかか • 会議の冒頭でゴールを確認しているか • 終了時に決定事項や宿題を確認しているか • そもそもその会議は必要か • 時間通りに開始しているか • 会議は短く保っているか • 会議を延長していないか • 定時後に会議を設定していないか • 職位を会議に持ち込んでいないか
57. 平均すると、会議の割合が 業務時間の25%を超える？
58. 時間の4分の1以上が会議に費やされている ならば、組織構造に欠陥があると見てよい ‒ピーター・F. ドラッカー
59. 外部とのコミュニケーション • コンテキストが共有されていないことを理解する • コミュニケーション方法も確立されていない • 従ってチームと外部で対立が発生し相手を責めたくなる • 外部とのコミュニケーションの必要性の頻度が高いのは 組織構造が問題 (DevとOpsの問題など) • チームのやり方を見える化する
60. • Amazonではamazon.com用のサーバを調達する手 続きをAPIに置き換えた • そうすることで、コミュニケーションオーバーヘッドを削 減しプロビジョニングまでの時間を短縮
62. 評価の基本原則 • 価値観/優先度/期待値/求める成果を先に合意し後出しを避ける • 公平・公正であること • 定量評価と定性評価の組み合わせ。定量に寄せると倫理観崩壊 • 検査と適応。 うまくやることが目的なのでもっと頻繁に(1-3ヶ月単位で) • ピアレビュー(1 on 1)の活用 KOREA.NET - Official page of the Republic of Korea via VisualHunt.com / CC BY-SA
63. フィードバックの方法 • もっと頻繁に (毎週1回30分上司と1:1など) • ネガティブなフィードバックも必要。 個人攻撃ととられないように! 個人攻撃とはとらない! • 対立構造に見える座り方を避ける • あなた vs わたし ではなく、問題 vs わたしたち • I messageを使う
