これをやったらいいと思う!そうだね!誰がやる?いないね。いろんなことを廃案にしてます。やれるならやったらいいし、うまくいったら続けていきたいけど、無理しない。実行委員もボランティアも2/3以上の人が熟練なので、いつもの感じで自律的に対応できる。参加者もスポンサーさんもそう。そこに画期的な新企画なんていらないのでやらない。ご飯があって椅子と机があって仲間がいれば楽しい。話し合えれば学びが最大化する。同僚も連れてきたいと思う。知り合いにも紹介しよう。楽しくて、やりたいことができて、学びがある。ディズニーランドみたいなもの。キャストとゲストがいるだけ。そこに一方的にサービスされるお客さんはいないんです。いうことでうまくいっているとしたら偶然なので、もっとこうしたい、みたいなご提案はありがたいですけど、やるとなると現状維持を優先したいです。学んでることじゃないですか。規模を大きくするにしても30%くらいまでにしたいのは、常に2/3は去年と同じにしたいから。同じような会場、トラック構成、スポンサー規模、飲み食い、参加者やスタッフ。「30%は人工的な数字」って言われたけど、割と根拠あると思ってます。2/3を経験者にする。書いてあったように、文化は多数決なので。ROI高くしないと、自分が楽しめないと思うんですよね。スタッフが一番楽しみたくてやってるのに滅私奉公だと続かない。スタッフが続かないと引継ぎ負荷が上がってROIが下がる。スクラムも知られてなくて、チケットも売れなかった時代を経験してる人たちがいなくなると、またちょっと変わっていくのかもしてないけど、今はなるべく現状維持で、来る人の認知負荷が低い状態を維持したいです。馴染みの銭湯が毎回模様替えしてたら居心地悪いので(なんのこっちゃ)。ぼっち対策のポスターが秀逸だと思いました。パックマンルールを常に心がけよう。mind!初参加の人や初対面の人が話の輪に入りやすくなるよう、必ず入り口を開けておきましょう、パックマンの口があいているように。究極の対策でもなんでもないんですけど、このちょっとした心がけを普及させれば、「入れてあげるようにしよう」「入っていいのかも」という気持ちが少しだけ高まる気がします。comment2019-12-21「難しい人を受け入れるのは同時に一人まで」ルール考え方が違うとか、感覚が違うとか、うまく付き合うのがちょっと難しい相手っていうのがたまにあって、別にずっとそうなわけではないんだけど、今はちょっと大変な相手。いって距離を置くのも適切じゃないようなケースで悩むわけですが、あるときから、「難しい人を受け入れるのは同時に一人まで」ルールで考えるようになりました。時間あれば打ち解けられるんだろうけど、複数人がその状態だとこっちが疲れてしまうし、そもそも時間をかけられなくなってしまうので。なんかきついなーと思ってふと見回すと複数人を相手していたりするので、ちょっとタイミングをずらしたり、片方は一旦距離をおいたりできないか考えてみる。一人というのはパラメータで、人によっては3人かもしれないし、10人100人といけるかもしれません。そこはやりながら許容量を見定めていけばいいと思います。タイミングも細かくできると思いますので、切り替えの早い人は実質無制限に行けるのかもしれない。(マルチコアとクロックアップで性能向上するCPUみたい。)ただ、クソッタレさんはお断りです。非日本語ネイティブ向けのGlobalチケットを発売することにしました。「数分で完売?クレイジーだね。「日本に行こうと思うんだけど、チケットが完売してる。「日本は遠いけど行ってみたい」というお問い合わせをいただくようになりました。日本人向けのチケットも十分に用意できない中で、と感じる方もいらっしゃると思いますが、今回、少数ですが英語話者向けのチケットを用意することにしました。発売は来週月曜日16日正午です。東京近郊に住む日本人だけの閉じた場所にしたくないという思いがあります。キーノートは毎回英語圏の方をお呼びしてますし、トラックも一つは英語で聴けるようにしています。nativeも何人も来てました。ボランティアの方にも英語に抵抗がない方をお願いしています。Allianceです。アジアからもヨーロッパからも北米からも国内からもあらゆる国や地域の方々が参加しやすいカンファレンスにしたいと思っています。miholovesq.hatenablog.comお近くに非日本語ネイティブの方で、カンファレンスにご興味ある方がいらっしゃいましたら、ぜひこのチケットのことを教えてあげてください。Ticketをご購入されないよう、お願いいたします。*1*1:そんな方はいらっしゃらないと信じてますが、「ルールを破りに行くチャレンジ」は、社会的正義を背景にやるべきと思います。非日本語ネイティブ向けのGlobalチケットを発売することにしました。comment2019-12-08何十年分の人生経験と対峙するなんらかの概念を人に教えたり、やりたくなってもらおうとしたときに、それまでのその人の何十年分の人生経験と対峙することになるので、それをたかだか数時間や数ヶ月でなんとかするのはそもそも成功率の高くない賭けなんじゃないかと思うことがあります。言葉通じない人に楽しさを教えるのはすごく難しそう。基本的に人はバラバラ。違う環境にいても同じようなことに共感することがあって。言語や環境や性別や年齢を超えてなぜか話があったりする不思議。パターンの根底にはそんな考え方があるみたいです。共犯者も見つかります。(角川コミックス・エース)実はこれは井庭崇さんのパターンランゲージのワークショップで学んだことなのですが、たぶん多くのアジャイルコミュニティやパターンコミュニティの人が共通の根底として持っている理解のような気がします。相談できる同志(39)」として書かれています。comment2019-12-07お客さんがプロダクトオーナーになるべきなのか?プロダクトオーナーが忙しい、プロダクトバックログ書いてくれないって話をよく聞くんですけど、そのあと話を聞いていくと実はプロダクトオーナーは同じ会社じゃないんです、お客さんなんですっていうパターンがちょくちょくあります。プロダクトオーナーがやる仕事は結構あります。ビジョンを持ち、いつ誰に何を届けるかを考え、プロダクトバックログに落とし込むなるべくROIを高められるようにプロダクトバックログを優先順位付けする。直近の数スプリント分は準備完了(チームが着手可能)にするチームと定期的に話し合ってバックログを見直す(リファインメント)すべてのステークホルダーと話す予算を取るバックログの内容についてチームからの質問を受けつけ、明確化するチームが完成としたバックログ項目の成果物(出荷判断可能なプロダクトインクリメント)の受け入れ判断をする受け入れた成果物をリリースすべきときにリリースするプロダクトオーナーは一人、もしくは複数人でやる場合にもチーフを置き、最終決定責任を明確にします。これって顧客側でカバーできるんでしょうか?日本でウォーターフォールが多いのは、顧客側が曖昧な要件と厳しい予算/納期を要求し、それを受注側がカバーする構造のために、事前に受注側で様々なリスクヘッジが発生することに起因する気がしています。顧客側が十分な要件や仕様を提示するケースは極めて少ないのではないでしょうか。「スクラムがうまく行かないのはお客さん(PO)が仕様をくれないから」だとすると、デスマーチになるウォーターフォールとだいたい同じような問題を抱えてしまうように思います。組織を跨ぐのがベストではないとしても、なにかうまくやる方法はないのでしょうか?共犯者モデル一つの考え方は、共犯者モデルと呼んでいるものです。顧客側と開発側にプロダクトオーナーを置いて、緊密に連携する。お互いに背中を預けて、説明していく。会社を跨いでしまうとそこ(会社間)で交渉してしまいがちなんだけど、それは全体の価値を考えればムダ。POはあらゆるステークホルダーと話す必要があるので、ペア/チームを組んで360°をカバーします。顧客側がカバーしやすいことビジョンを持ち、いつ誰に何を届けるかを考え、プロダクトバックログに落とし込むなるべくROIを高められるようにプロダクトバックログを優先順位付けする。すべてのステークホルダーと話す予算を取るチームが完成としたバックログ項目の成果物(出荷判断可能なプロダクトインクリメント)の受け入れ判断をする。受け入れた成果物をリリースすべきときにリリースする受注側がカバーしやすいこと直近の数スプリント分は準備完了(チームが着手可能)にするすべてのステークホルダーと話すチームと定期的に話し合ってバックログを見直す(リファインメント)バックログの内容についてチームからの質問を受けつけ、明確化するもちろんこれは協調してカバーしましょうというだけの話です。役割分担ではありません。開発チームが最も高いROIを利用者に届けられるように、ベストをつくします。以上、2009年くらいに思いついた話でした。togetter.com信頼に基づく共犯者が裏切ったら終わり、というところですので、信頼が大事です。2人の認識がずれたり、片方が「お客様」になってしまったりするとうまくいかなくて。2人で世界を変えてやろう、くらいの目的と共感が、うまくいくケースには存在しているのではないかという仮説です。2010このエントリもRSGT2020のアドベントカレンダーに向けて投稿してみます。さんによる、大規模組織のお話がありました。Gathering、今回)ですし、ありがたいことに、色んな人に日本語で説明することもあるので、周りの人とも話しながら自分なりの認識がまとまってきました。いや、お前のまとめなんていらないんだよ、とは思いますが、全体をちゃんと書くのは難しいので(ビデオとっとくべきでした)、ざざっと書いておきます。人々は組織をツリー構造*1で考えがちで、実際に公式な組織アサインはそのように運営されがちだが、末端のノード間やたすき掛けのようなつながりは自然に起きていて、それによって情報流通の効率性が維持されている。これは、兼務をつけて複数部署にマネージャーを頭出しさせるのとも違うし、マトリックス型組織でプロジェクト運営するのともちょっと違うかもしれない。自然に、必要な人と必要な人が話したり、そういうパス(経路)の発見を手助けするハブになる人というのがいるものなのだ。ツリー型組織の問題は、3階層、4階層と深まっていくと、部署を超えた末端実務者どおしのコミュニケーションの「間に入る人」が増えていくことだ。World仮説だと6次の隔たりで世界中の人が話せるかもしれないというのに、たった数百人の社内で話すだけで6次以上の隔たりが常態化してしまう。これは効率的な組織とはいえない。組織の調査をしてきた。人々がもつパスの数を調べると、そのヒストグラム(パス数ごとの人数分布)は、通常の組織では5を中心とした正規分布になる。5人前後のつながりを持つ人が多いということだ。ツリー型の組織で一人の上司が4人の部下を持ち、それが多階層になるとこうした分布になる。高効率の組織はパス数が少ない人が多く、パス数が増えるにつれて該当人数は指数関数的に減少していく。一方で、非常に多数の、数十のパスを持つ人も複数現れる。インターネットなどのスケールフリーネットワークは、ローカルの密なつながりと、ハブを経由したネットワーク間のつながりで構成されていて、しかも冗長性を確保する。一本の線が切れても、ほかの線でつながることで、パフォーマンスは落ちるが全体が不通になることを避けるようになっている。組織も同じで、ツリーにこだわらないノード間のつながりが重要。それは自然に起きていて、効率的な組織ではそれが観察される。アジャイルではトラックに一人轢かれると業務が出来なくなるのがトラックナンバー=1という。組織がツリー構造だと上司が単一の経路になり、上司が休暇に入るとネットワーキングのパスが切れてしまう。ネットワークの冗長性がない。スケールフリーネットワークは複数のハブが機能することで冗長性を担保する。トラックナンバー=1を避けることは重要だ。Royceは論文の中で、フィードバックが必要だと言っていて、つまりやってみて新しい情報が明らかになったところで手戻りをすることは必然。それぞれ別の人たちで、組織をまたがる手戻りは、許されていてもなかなか起きない。スクラムはそれをできるかぎり1チームのクロスファンクショナルな組織でやろうと言っている。すれば、フィードバックを素早く受けて、チーム内で柔軟に手戻りができる。ウォーターフォールからアジャイルに移行しようとすると、これまで情報を握っていた中間の管理職が不安に陥る。自分の頭越しに情報が行き来することになるからだ。組織にとって、一番末端に近いマネジメントは実際の現場をマネジメントしているが、マネジメントをマネジメントしている人たちは現場にアクセスしていない。これはトヨタの現地現物、ホンダの三現主義でいえば、ありえない話だ。管理職が考えている以上に、組織はもともとスケールフリーネットワークで動いている。中間管理職をなくしても、各チームが自律的にマネジメントすればよく、大規模な組織でもおそらく運営可能だ。同じ組織は2つと無いので、実験してみる必要がある。上司を通さずに、隣の部署の上司やチームメンバーと会話をするのが、スケールフリーネットワークの重要なところ。そのつながりを多数持つのがハブだ。一方で、チーム同士が密結合してしまうと効率が悪い。仕事はローカルなチームで独立してできるようにして、かつ、ハブになる人がチーム間をつなげていく。チームで解決できない問題があったら、ハブに相談すれば、適切な人たちをきっと紹介してくれる。ように多層になっていくと、ツリー構造になり、これまで言ったような不都合を生じてくるのではないか?ハブとスケールフリーネットワークは新しいことではなく、自然に発生している「パターン」だ。ハブを任命して作る、というものでもないだろう。やったらハブになれる人を育成できるか?というより、それは自然にあるもので、むしろ阻害する要因が既存の組織のマネジメント階層にある。頭越しに情報をやり取りすることを阻害する上司がそれだ。SpotifyのGuildなどもその一例だろう。その後飲み会で話していて、第一歩として「ハブがよいことなのだ」という認識が大事だなと思いました。パターンの名前づけの力。ないと「上司を差し置いて隣の部の人と話すと上司が気を悪くするかも」という余計な懸念が人々の活動を止めてしまう。その考え方が危ないのに。いやー、RSGTでの基調講演がとても楽しみです。confengine.com今回のイベントはこちらでした。taco.connpass.comありがとうございました。関連する本はこのへんです。Coplienさんの研修もご興味ありましたらどうぞwww.jp.agilergo.comこの記事はRSGT2020のアドベントカレンダーに登録しています。記事の作成にあたっては、藤村新さん、蜂須賀大貴さん、守田憲司さん、前田浩邦さんのご意見をいただきました。Zaryaninovさんに撮影いただいたものを花井宏行さんからご提供いただきました。ありがとうございます。adventar.org木構造を本醸造と見間違えたのでもう飲みに行ってきます。非日本語ネイティブ向けのGlobalチケットを発売することにしました。