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