トップ > 知り合いを6人辿れば、世界80億人と繋がれるのに、組織内のコミュニケーションに6人以上必要なのは、おかしくない？ #TACO

知り合いを6人辿れば、世界80億人と繋がれるのに、組織内のコミュニケーションに6人以上必要なのは、おかしくない？ #TACO

Tokyo Agile Community (TACO)の「Scaled Agile with Jim Coplien」の講演メモ。

taco.connpass.com

英語がわからない私が、同時通訳してくれた内容を私の理解でメモしたものです。
断片的な上、正しくない表現や誤りが多いと感じます。いつも以上に自信がありません。
講演者と質問者と通訳者と私の言葉がとてもまざっています。
正しく理解したいため、違う点や補足などあれば、ぜひフィードバックお願いします。

Tokyo Agile Community (TACO) について

私は3回目の参加でした。
今回は、講演者の影響なのか、いつもと参加者層が違った（増えた）ように感じました。
（Twitterで聞いたら、来たことある人は、少数だったらしいと、川口さんが教えてくれました）

TACOは、主催者の方の多くが日本語ネイティブではない日本（東京）のコミュニティです。
日本と海外をつなぐ、特異点な気がしています。まさに、ネットワークのハブ。
特に、英語できる日本人は、どんどん参加すると良いと思います。月１回開催みたいです。
（私が英語わからないので、勉強しなきゃ...）

川口さんがまとめてくれました。是非こちらを見てください！

kawaguti.hateblo.jp

Scaled Agile with Jim Coplien


www.slideshare.net

  • Jim Coplienさんは、今年2回目のTACO
  • コミュニティは未来
    • 私はコミュニティを育てたい
  • 1プロダクトで1チームの人はいますか？
  • 複数のDevチームの人はいますか？
    • 3チーム以上が多い
  • LeSS
  • SAFeはアジャイルじゃない
  • スケーリングはよくない
    • 日本チームと中国トームのように離れている以外では、スケールする意味がない
  • ただ、プロダクトが大きすぎて、誰も作り方がわからない
    • フィーチャーが多すぎる
    • 90%のフィーチャーは誰も作らない
  • Spotifyは1つのプロダクトに思えるが、80個の小さいプロダクトがたくさんある。
  • 1つのプロダクトは1つの開発チームでできる。
  • Skypeは人がたくさん増えたが、うまくいかなかった
    • はじめたときは５人だけ
  • スケーリングはそもそも悪い
  • ソフトウェアはアンフェア
    • 1人だけでソフトウェを作って、お金をたくさんもらうことができる
  • そもそもなぜスケーリングしたいか？
    • ビジネスがうまくいくと、もっとやりたくなる→スケール
  • スクラムチームは改善するだけで10倍、100倍になる
    • 新しい人を入れるより効率が良い
  • 7 + 1
  • 7人のチームに 新しく1人を追加すると？
    • 2チームに分ける
    • 40%はコミュニケーションコストになる
    • 20個くらいのチームでないと、同じ効率にならない
      • 勿体無い
  • お金がたくさんある会社は、スケーリングをやる
    • お金があるから。できるから。
    • キャピタリズムの証拠
      • お金がたくさんあるから、やる
  • 日本で「あなたの仕事はなんですか？」と聞くと
    • 「電話を受けて、他の人に共有すること」と答える人がいる。
    • 必要？
    • いろんな会社は意味がないことをしている
    • もしかしたら、そういう会社の人は参加者の中にいる
  • スケーリングはそもそも悪い
  • ある人は、「スケーリングしなきゃ」という。
    • 「改善」の考え方がない
    • SAFeを使って改善できないよね
  • 組織的なスケーリングについて話しましょう
    • 「たくさんある部門の人たちと話しますか？」
    • 自己組織化されておらず、他のチームと少しだけ話さないといけない
    • 他の人と話さないといけない状況は、スクラムチームの以外の他の人たちも実はスクラムチームにいる状況
  • Scrum@Scaleはスクラムではない
    • お金をもらいたいから、コンサルが広めてる？
      • 「スケールをやりたい場合は～」
  • サザーランドは、スケーリングパターンがないと言ってた
  • スクラムチームをコピペ→Scrum@Scale
    • フラクタル構造
    • Scrum of Scrum of Scrum of Scrum of Scrum of ...
    • Chief Chief Chief PO
    • ケン・シュエイバー
      • 完全に階層がある。ドイツの軍隊から持ってきた
  • 木構造。ツリー。
    • （データ構造の木構造の話）
    • 組織も同じような構造を持ってる
      • 人間はコミュニケーションできるツリーを作らないといけない
        • TACOはそのコミュニティのひとつ
  • Scrum@Scale
    • スケールフリー
    • 「どんな組織でもスケールできる」
    • 「どういうことですか？」聞くと
      • たくさんのチームでも 「一人あたりの生産性は下がらない」と言い張ってる
      • 組織が大きくなると生産性は上がるはず？
      • ジェフが解決しようとしたことはそもそも問題じゃなかった
  • 同じ話をしたら、数学者は怒っていた
  • そもそもスケールフリーってどういうこと？
  • Scrum of Scum of Scum ….
    • 5人いて下に5チームあるを想像する
    • 一番下に開発者
    • アジャイルだとindividual interaction
  • 完璧な状態だと他のチームとコミュニケーションしなくていい
    • 自己組織化ができてる
    • どう考えても話さないといけない場合
  • 平均的に2人で話したい場合、間に7人くらいのチームや人がいる
  • 100人と話さないといけない
    • 会ったことない人もいる

f:id:kobase16:20191205005106p:plain

  • 友達を辿っていくと6人で、地球の誰とでも繋がれる
    • スモール・ワールド仮説(6次の隔たり)
      • 世界の80億人が6ホップ
    • ヒエラルキー組織は6人以上
    • 統計的に証明されている
      • 地球は組織されてるわけじゃない
  • 組織を超えて、直接自分のネットワークで話すことができないと
    • 8人と話さないといけない
    • 世界の他の人と6人でいいのに？
  • アーキテクチャはイントラクションできない
  • どう直せばいいでしょうか？
    • 同じフィーチャーを、別のチームも触ってる
    • 新しいチームを作って、2チームを1チームにする。ハブと呼ばれている。
  • チームには何人いますか？
    • どう連携しますか？
      • 複数チームのエキスポートが集まって解決
    • Spotify
    • ギアツ
    • バーツ
  • スクラムだとどうチームで解決するか？
  • Scrum@ScaleのScrum of Scrums
    • 10年前はスクラムマスターではなく、一番困ってる人が集まってた
  • LeSS
    • Scrum@Scaleと比べて、スクラムに近い
    • 勝手に作って意味がないと思ったらやめられる
    • 作って終わって、作って終わって
    • 1回だけ作らないといけないと思ったら作る
  • 数学的にスケーリングを説明します
    • グラフ理論
    • ノードは5つの繋がりがある
    • ノードは1個だけのつながりがある
  • 組織についてのデータを集めて統計的に見ると、5を真ん中にして標準偏差になる
  • 5人以上は多すぎ
  • 多くの組織でも大体こんな感じ
      • Scrum@Scaleはこれ
  • ヒストグラム
    • 1人が何人と繋がっていますか、
  • スケールフリー
  • 例を見ると、普通の会社だけど、最後は多い
    • そういう人たちはホップが必要な人たち
  • チームをコミュニケーションするハブがない
  • アジャイルになるときに、会社は*何を捨ててきたか？*
    • コードオーナーをやめて、専門家をやめて、マネジメントをやめて*
    • コードのモジュールのオーナーはいますか？その人だけしかコミットできない。
    • マネージャーは自然なハブ
    • アジャイルするとハブはなくなる
  • How to build software
    • 人間はソフトウェアではない
    • 組織の中だとマネージャはうまくいかない
    • 文化人類学、社会学、組織デザインの知見が巻き込まれないのが良くない
  • インタラクションが多い人たちは
    • こういう仕事をしたくて作ったのではなくて
    • 自己組織的に作った。コミュニティ。モチベーションのある人
  • 25人で6ホップ
  • ハブを作ったら6から3になる
    • コミュニケーション
      • ヒエラルキーの場合、間の人がいないと、他の人はコミュニケーションできない
        • 階層構造の問題
      • ハブだとできる
        • 人が休んだり、やめてもコミュニケーションに影響がない
    • マネージャーは、600人が自己組織的に動けることを信じられない
    • 人間は自己組織的にコミュニケーションができる
    • Scrum of scrum of …みたいな時間があれば非常に時間かかる
  • ツリー型（ヒエラルキー）の組織だと、末端ノードの人は上の人しか見てない
    • 上の人がバケーションに行くと、コミュニケーションパスをなくす
  • ハブはネットワーク型で冗長構成になってる。一部壊れてもネットワークは死なない。
  • ヒエラルキー型のコマンドコントロールから、ハブを中心としたパラダイムにいるのではないか？
  • ヒエラルキーの間にいる人（マネージャー）は、自分を通してほしい
    • 自分を通さずにコミュニケーションしようとすると、間に入ろうとする
    • これがひとつめの問題
  • Scrum@ScaleだとたくさんPOがいる
  • ふたつ目の問題
    • POが多重になってる。二段目のPOは何を持ってるの？→何も持ってない。
    • スケールしようとすると、
    • 途中のマネージャーいらないから「解雇しようぜ」って言う
  • ハブを使えれば、Scrum of Scrumsはいらない
    • 「A Scrum Book」にパターンが乗っている（宣伝）
      • Scrum of Scrumsと書かれてるけど、実際はハブ*1
  • Scrum@Scaleは、ある状況では良い
    • 個人的にはScrum@Scaleを使うのは、スクラムではない
  • Scrum@Scaleは
    • 「スクラムチームを『管理』したいならこういうやり方がありますよ」って言ってる
    • 自己組織化すれば、上にあるのがなぜ必要か、理解できない。
  • LeSS
  • Scrum@Scaleには、個人的には、いろんな問題があると考えているScrum Allianceと一緒に考える
  • LeSSを作った一人はScrum Allianceから抜けつつある
  • Scrum AllianceとLeSSは一緒にやっていたが、ジェフがScrum@Scaleが一番大事と言ったので、LeSS は離れつつある（？）

  • ウィーンのScrum Gathering で、今日と同じ話をした資料があります(近日公開予定だそうです)

Q&A


Q:ウォーターフォールで、スケールフリーネットワークを作れる？
  • A:ウォーターフォールだとそもそも難しい
  • 他の部署に渡すと終わり
  • 例えば、テストの時には、分析した人は、別にものにアサインされてる
  • それだと、テストの結果を、分析にフィードバックすることは無理
  • ウォーターフォール：ロイスの論文
    • 論文には、戻るライン（フィードバック）は、絶対に必要だと書いてる
    • 実際には、部署がバラバラだと戻らない
    • 部署間で、レビューがあるだけで、渡したら終わり
    • 「戻す」が必要だと書いてあるけど、それがない
  • ミラクルが起こらないと変わらないと思う。
  • ↑ここまでは、守破離の「守」の話



  • コーディングをいつしますか？
  • 開発をはじめないと、デザインをわかることができない
  • ソースコードの80%は、デザインしながら書く
  • （理想は）どっちの部署も話し合って
  • ルールを柔軟に変更しているのは、ウォーターフォールと呼ばれている何か
Q:「スケーリングは悪い。小さいプロダクトの集まり」という話だったが、最初から分けたほうがいいか？
  • A:お客さんは、小さいものにお金を払いたくない
    • たとえば、iPhoneの場合に1つずつのアプリにお金を払ってないですよね
  • できるだけUX大事
  • 小さい部分で分ける
  • 半分は UXわかってる人がいたほうがいい。UXは非常に大事
  • OOP(オブジェクト指向プログラミング)をやってる方はいますか？
  • OOPの源流の定義はなんですか？
    • アラン・ケイが作った
    • 作ろうとしのは、子供達が学べるようなプログラム
    • 子供から見たメンタルモデルをマシンの中に入れる
    • マシン自体が子供の頭の延長になる
    • すると、脳のウェットウェアとマシンのハードウェアが近いインターフェースになる。
    • OOPは目的は認知モデルと近づけることがアラン・ケイの考え。


  • UXを学んでください
    • UXのスケーリングは必要ですよね
Q:LeSSだとHubがありますか？
  • A:LeSSのハブは同じハブはない
    • 必要だったら集まって、終わったらなくなる
  • Scrum@Scaleは15年前の考え方
  • LeSSだと、問題を抱えている人を呼ぶ。
    • 判断で参加する
  • ハブはツールではない
    • Confluence(アトラシアンの製品)上にハブを作らない
    • *対話で解決*してください
  • ハブだと定期的でも、１回でもいい
  • ハブは３種類
    • スクラムだと２つ
    • お寺、神社の檀家さんみたいなつながり。ひとつのノードから何千人もいる
      • 人工的に設計しようと思ったらできる
    • ロールを作ることができる。マネージャーとかコードオーナーとか
  • ハブの種
    • 育てて、できるだけ人のためになる
    • その人はハブのオーナーになるかを判断したほうがいい。
  • 最初、会社に入ると、コミュニティやハブを知らない
  • スケールフリーネットワークだと、（理論上）人がたくさん入っても同じ長さになるけど
    • どう考えても、たくさん人が入るとダメになると思う
    • もしこれができたら、修士論文書けるレベル
  • ハブがあれば、行っていなくても、認識できる
    • それぞれのハブが詳しく何をしてるか知らなくても、どういうハブがあるかわかればいい。
Q:ハブの悪いところはないの？
  • A:ハブはパスをカットしても、問題ないと言っているけど、
  • ハブを完全に切ってしまうと、非常に問題がある
  • ハブが急に消えないようにしないといけない
  • 個人的に、弱さはこれしかないと思っている
  • ハブが解決したい問題がなくなったら、ハブは自然に消える
    • スプリントプランニングで2つのチームで問題あるよね。とわかったら、ハブができる。
Q:ハブと組織全体の情報共有はどうするか？
  • A:なぜそれが必要ですか？
  • ハブは本当に情報が必要な人が集まってる
  • 情報を中心とした集まり
  • そもそも全員が全員の詳細を知ってる必要がない

かんそー

  • *Small is beautiful!*
  • そもそもスケールは、よくないこと。
    • でも、大きくなって、お金があると、スケールしたくなってしまう。
  • 小さなプロダクトをたくさん作るほうがいい
  • 「ヒエラルキー組織構造をスケールするのではなく、ネットワーク型のハブ的なコミュニティ構築をする。」
    • ということの背景や捉え方を深めることができるお話でした。おもしろい！
    • ティールやらなんやら、「ヒエラルキー型ではなくネットワーク型」と最近流行っていますが、その理由を少し深く見れた感じ。
  • スモール・ワールド仮説の話は、
    • 「知り合いを6人辿れば、世界80億人と繋がれるのに、組織内のコミュニケーションに6人以上必要なのは、おかしくない？」
      • という「問い」なんだろーなーと感じました。
  • Scrum@Scaleとの比較

  • 上記のはちさんのツイートはまさにそうだと思いました。
    • 先日Scrum Interaction 2019で、ジェフ・サザーランド博士が「Scrum@Scaleでビジネスアジリティを実現する」という講演を話をされていたので、本日の話と比較すると見えるものが違うかも？おもしろそうです！
    • まだ、消化できていないのですが、ゆっくり時間ある時に比較して考えたい。
    • Scrum Interaction 2019の内容は、下記参照。

kobase16.hatenablog.com

  • 個人的に、生Jim Coplienさんを見たのは、はじめて。

*1:本の原稿の元ネタ http://scrumbook.org/product-organization-pattern-language/scrum-of-scrums.html