RSGT2020 非日本語ネイティブ向けのGlobalチケットを発売することにしました。

海外の方や日本在住の日本語ネイティブでない方から、

「数分で完売?クレイジーだね。」

「日本に行こうと思うんだけど、チケットが完売してる。なんか買う方法ない?」

「日本は遠いけど行ってみたい」

というお問い合わせをいただくようになりました。

 

日本人向けのチケットも十分に用意できない中で、と感じる方もいらっしゃると思いますが、今回、少数ですが英語話者向けのチケットを用意することにしました。発売は来週月曜日16日正午です。

rsgt2020.eventbrite.com

Regional Scrum Gatgering Tokyo を東京近郊に住む日本人だけの閉じた場所にしたくないという思いがあります。キーノートは毎回英語圏の方をお呼びしてますし、トラックも一つは英語で聴けるようにしています。数年前は私の同僚のNon Japanese nativeも何人も来てました。ボランティアの方にも英語に抵抗がない方をお願いしています。実行委員は海外カンファレンスに積極的に参加してる勢ですし、冠スポンサーは米国の非営利団体のScrum Allianceです。アジアからもヨーロッパからも北米からも国内からもあらゆる国や地域の方々が参加しやすいカンファレンスにしたいと思っています。

miholovesq.hatenablog.com

 

お近くに非日本語ネイティブの方で、カンファレンスにご興味ある方がいらっしゃいましたら、ぜひこのチケットのことを教えてあげてください。

日本語ネイティブの皆様は、申し訳ありませんが趣旨をご理解いただき、Global Ticketをご購入されないよう、お願いいたします。*1

 

*1:そんな方はいらっしゃらないと信じてますが、「ルールを破りに行くチャレンジ」は、社会的正義を背景にやるべきと思います。

何十年分の人生経験と対峙する

なんらかの概念を人に教えたり、やりたくなってもらおうとしたときに、それまでのその人の何十年分の人生経験と対峙することになるので、それをたかだか数時間や数ヶ月でなんとかするのはそもそも成功率の高くない賭けなんじゃないかと思うことがあります。

たとえば言語。言葉通じない人に楽しさを教えるのはすごく難しそう。極端な例ですが。基本的に人はバラバラ。でもたまに全然違う環境にいても同じようなことに共感することがあって。言語や環境や性別や年齢を超えてなぜか話があったりする不思議。パターンの根底にはそんな考え方があるみたいです。

なので、きっと共犯者も見つかります。

f:id:wayaguchi:20191208000447j:image

僕だけがいない街(4) (角川コミックス・エース)

 

実はこれは井庭崇さんのパターンランゲージのワークショップで学んだことなのですが、たぶん多くのアジャイルコミュニティやパターンコミュニティの人が共通の根底として持っている理解のような気がします。素朴理論。

Fearless Changeには、組織を超えても共感してくれる人の大事さが「Shoulder to Cry On : 相談できる同志(39)」として書かれています。

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

 

 

 

お客さんがプロダクトオーナーになるべきなのか?

プロダクトオーナーが忙しい、プロダクトバックログ書いてくれないって話をよく聞くんですけど、そのあと話を聞いていくと実はプロダクトオーナーは同じ会社じゃないんです、お客さんなんですっていうパターンがちょくちょくあります。

プロダクトオーナーがやる仕事は結構あります。

  • ビジョンを持ち、いつ誰に何を届けるかを考え、プロダクトバックログに落とし込む
  • なるべくROIを高められるようにプロダクトバックログを優先順位付けする。
  • 直近の数スプリント分は準備完了(チームが着手可能)にする
  • チームと定期的に話し合ってバックログを見直す(リファインメント)
  • すべてのステークホルダーと話す
  • 予算を取る
  • バックログの内容についてチームからの質問を受けつけ、明確化する
  • チームが完成としたバックログ項目の成果物(出荷判断可能なプロダクトインクリメント)の受け入れ判断をする
  • 受け入れた成果物をリリースすべきときにリリースする

プロダクトオーナーは一人、もしくは複数人でやる場合にもチーフを置き、最終決定責任を明確にします。

で、これって顧客側でカバーできるんでしょうか?日本でウォーターフォールが多いのは、顧客側が曖昧な要件と厳しい予算/納期を要求し、それを受注側がカバーする構造のために、事前に受注側で様々なリスクヘッジが発生することに起因する気がしています。顧客側が十分な要件や仕様を提示するケースは極めて少ないのではないでしょうか。

スクラムがうまく行かないのはお客さん(PO)が仕様をくれないから」だとすると、デスマーチになるウォーターフォールとだいたい同じような問題を抱えてしまうように思います。

組織を跨ぐのがベストではないとしても、なにかうまくやる方法はないのでしょうか?

共犯者モデル

一つの考え方は、共犯者モデルと呼んでいるものです。顧客側と開発側にプロダクトオーナーを置いて、緊密に連携する。お互いに背中を預けて、説明していく。会社を跨いでしまうとそこ(会社間)で交渉してしまいがちなんだけど、それは全体の価値を考えればムダ。POはあらゆるステークホルダーと話す必要があるので、ペア/チームを組んで360°をカバーします。

f:id:wayaguchi:20191206131429p:plain

顧客側がカバーしやすいこと

  • ビジョンを持ち、いつ誰に何を届けるかを考え、プロダクトバックログに落とし込む
  • なるべくROIを高められるようにプロダクトバックログを優先順位付けする。
  • すべてのステークホルダーと話す
  • 予算を取る
  • チームが完成としたバックログ項目の成果物(出荷判断可能なプロダクトインクリメント)の受け入れ判断をする。
  • 受け入れた成果物をリリースすべきときにリリースする

受注側がカバーしやすいこと

  • 直近の数スプリント分は準備完了(チームが着手可能)にする
  • すべてのステークホルダーと話す
  • チームと定期的に話し合ってバックログを見直す(リファインメント)
  • バックログの内容についてチームからの質問を受けつけ、明確化する

もちろんこれは協調してカバーしましょうというだけの話です。役割分担ではありません。開発チームが最も高いROIを利用者に届けられるように、ベストをつくします。

 

以上、2009年くらいに思いついた話でした。

togetter.com

 

信頼に基づく

共犯者が裏切ったら終わり、というところですので、信頼が大事です。

 

このエントリもRSGT2020のアドベントカレンダーに向けて投稿してみます。

adventar.org

 

組織はツリーではない - Jim Coplien さんのスケールフリーネットワーク論

RSGT2020の基調講演をやっていただく Jim Coplien さんによる、大規模組織のお話がありました。

この話を聞くのは実は三回目(飲み屋、ウィーンでのScrum Gathering、今回)ですし、ありがたいことに、色んな人に日本語で説明することもあるので、周りの人とも話しながら自分なりの認識がまとまってきました。

いや、お前のまとめなんていらないんだよ、とは思いますが、全体をちゃんと書くのは難しいので(ビデオとっとくべきでした)、ざざっと書いておきます。

人々は組織をツリー構造*1で考えがちで、実際に公式な組織アサインはそのように運営されがちだが、末端のノード間やたすき掛けのようなつながりは自然に起きていて、それによって情報流通の効率性が維持されている。これは、兼務をつけて複数部署にマネージャーを頭出しさせるのとも違うし、マトリックス型組織でプロジェクト運営するのともちょっと違うかもしれない。もっと自然に、必要な人と必要な人が話したり、そういうパス(経路)の発見を手助けするハブになる人というのがいるものなのだ。

ツリー型組織の問題は、3階層、4階層と深まっていくと、部署を超えた末端実務者どおしのコミュニケーションの「間に入る人」が増えていくことだ。その結果、Small World仮説だと6次の隔たりで世界中の人が話せるかもしれないというのに、たった数百人の社内で話すだけで6次以上の隔たりが常態化してしまう。おそらくこれは効率的な組織とはいえない。

組織の調査をしてきた。人々がもつパスの数を調べると、そのヒストグラム(パス数ごとの人数分布)は、通常の組織では5を中心とした正規分布になる。5人前後のつながりを持つ人が多いということだ。ツリー型の組織で一人の上司が4人の部下を持ち、それが多階層になるとこうした分布になる。しかし高効率の組織はパス数が少ない人が多く、パス数が増えるにつれて該当人数は指数関数的に減少していく。しかし一方で、非常に多数の、数十のパスを持つ人も複数現れる。この人々がハブだ。

f:id:wayaguchi:20191205173804j:image

インターネットなどのスケールフリーネットワークは、ローカルの密なつながりと、ハブを経由したネットワーク間のつながりで構成されていて、しかも冗長性を確保する。一本の線が切れても、ほかの線でつながることで、パフォーマンスは落ちるが全体が不通になることを避けるようになっている。組織も同じで、ツリーにこだわらないノード間のつながりが重要。それは自然に起きていて、効率的な組織ではそれが観察される。

アジャイルではトラックに一人轢かれると業務が出来なくなるのがトラックナンバー=1という。組織がツリー構造だと上司が単一の経路になり、上司が休暇に入るとネットワーキングのパスが切れてしまう。ネットワークの冗長性がない。スケールフリーネットワークは複数のハブが機能することで冗長性を担保する。トラックナンバー=1を避けることは重要だ。

ウォーターフォールの元の論文を書いた Winston Royceは論文の中で、フィードバックが必要だと言っていて、つまりやってみて新しい情報が明らかになったところで手戻りをすることは必然。しかし、現在、一般的に言われる「ウォーターフォール」は、各段階を別々の組織が担う。企画、設計、開発、品質保証、それぞれ別の人たちで、組織をまたがる手戻りは、許されていてもなかなか起きない。スクラムはそれをできるかぎり1チームのクロスファンクショナルな組織でやろうと言っている。そうすれば、フィードバックを素早く受けて、チーム内で柔軟に手戻りができる。

ウォーターフォールからアジャイルに移行しようとすると、これまで情報を握っていた中間の管理職が不安に陥る。自分の頭越しに情報が行き来することになるからだ。しかし、組織にとって、一番末端に近いマネジメントは実際の現場をマネジメントしているが、マネジメントをマネジメントしている人たちは現場にアクセスしていない。これはトヨタの現地現物、ホンダの三現主義でいえば、ありえない話だ。管理職が考えている以上に、組織はもともとスケールフリーネットワークで動いている。中間管理職をなくしても、各チームが自律的にマネジメントすればよく、大規模な組織でもおそらく運営可能だ。ただし、同じ組織は2つと無いので、実験してみる必要がある。

上司を通さずに、隣の部署の上司やチームメンバーと会話をするのが、スケールフリーネットワークの重要なところ。そのつながりを多数持つのがハブだ。一方で、チーム同士が密結合してしまうと効率が悪い。あくまで仕事はローカルなチームで独立してできるようにして、かつ、ハブになる人がチーム間をつなげていく。チームで解決できない問題があったら、ハブに相談すれば、適切な人たちをきっと紹介してくれる。スクラムマスター同士が行う Scrum of Scrums はその一例だろう。しかし、Scrum of Scrum of Scrum ... のように多層になっていくと、ツリー構造になり、これまで言ったような不都合を生じてくるのではないか?

ハブとスケールフリーネットワークは新しいことではなく、自然に発生している「パターン」だ。ハブを任命して作る、というものでもないだろう。どうやったらハブになれる人を育成できるか?というより、それは自然にあるもので、むしろ阻害する要因が既存の組織のマネジメント階層にある。頭越しに情報をやり取りすることを阻害する上司がそれだ。非公式な専門家同士のつながりに Birds of Featherというパターンがある(A Scrum Book)。SpotifyのGuildなどもその一例だろう。

その後飲み会で話していて、第一歩として「ハブがよいことなのだ」という認識が大事だなと思いました。パターンの名前づけの力。そうでないと「上司を差し置いて隣の部の人と話すと上司が気を悪くするかも」という余計な懸念が人々の活動を止めてしまう。むしろその考え方が危ないのに。

いやー、RSGTでの基調講演がとても楽しみです。

confengine.com

 

今回のイベントはこちらでした。

taco.connpass.com

f:id:wayaguchi:20191205105125j:image
ありがとうございました。

関連する本はこのへんです。

A Scrum Book: The Spirit of the Game

A Scrum Book: The Spirit of the Game

 

ほかの方のメモ

kobase16.hatenablog.com

 

Jim Coplienさんの研修もご興味ありましたらどうぞ

www.jp.agilergo.com


この記事はRSGT2020のアドベントカレンダーに登録しています。記事の作成にあたっては、藤村新さん、蜂須賀大貴さん、守田憲司さん、前田浩邦さんのご意見をいただきました。資料写真はJim Coplien さん、集合写真はTACOのYury Zaryaninovさんに撮影いただいたものを花井宏行さんからご提供いただきました。ありがとうございます。

adventar.org

 

木構造本醸造と見間違えたのでもう飲みに行ってきます。

*1:木構造。閉路のない有向グラフ

Post-It が本気出した

7-8年前から紹介しているんですが、Post-Itの本家3Mが作っているiPhone App に Post It Plus というのがあります。

壁に貼った付箋を写真取ると電子化してくれるもので、秀逸なところは、付箋のサイズを自動認識して仮想的なボードに展開し、PowerPointなどに変換でき、パワポの中には個別の付箋のサイズの移動や拡大縮小ができる(オブジェクトとして貼られる)という神アプリです。

今年になって、PlusがとれてAndroidMacをサポートしていることを見つけました。

www.post-it.com

3Mさんは昨年からGlobal Scrum Gathering にもブース出すようになったりして、社内でも風向きが変わった感じでしょうかね。グッジョブ!

f:id:wayaguchi:20191029090741j:plain

 

「できるけどやらない」のがアジャイル

この記事はRSGT2020アドベントカレンダーのために書きました。

Regional Scrum Gathering Tokyo Advent Calendar 2019 - Adventaradventar.org

週末に奥さんに誘われて細野晴臣さんの50周年記念のショーを見に行ったんですが、おん年72歳の細野さんが若者と戯れる空間がそこにありました。(以下敬称略) 高橋幸宏はもとより宮澤りえと水原希子を従えて昭和風味のお茶の間ドラマを展開し、踊りながら歩きまわり、星野源とコーヒーを適当に入れ、ビデオ出演の坂本龍一YMOを生演奏し、全員で昭和な教室コントをやった後にジョイマンを踊るという、細野さんやスタッフの好きなことだけを詰め込んだ一夜限りの謎の幸せ空間でした。みんな細野さん大好きなんですね。

haruomihosono50.com

細野さんはまあだいたいなんでも楽器弾けそうだし、実際昨年のアルバムは全パート自撮りしたとも聞いたんですけど、舞台やコンサートは決してでしゃばらず、みんなで楽しくやる感じが素敵だなと思いました。アンコールもなし。(たぶん最後のジョイマンは相当体力的にキツかったんじゃないかと勝手に思いました。)

 

f:id:wayaguchi:20191202060820p:image

細野さんの公演を見ながら勝手にシンパシーを感じていたのが、決して無理しないRSGTのモットーみたいなもの。近年のRSGTにおきましては会場のキャパも座席数も需要に追いついてない感じで、チケットが取れない方には大変心苦しい限りですが、見えない誰かに無理無茶を押し付けてしまわないことが、ウォーターフォールに比べてのアジャイルの決意みたいなものだと思うんです。スタッフの皆さんにおかれましては、すぐにアンドンのコードを引いて欲しいと思っています。担当者がギブアップするまで続けるチキンレースはやりたくない。

「できないかもしれないけどやる」が若きベンチャースピリット、「できることをやる」が伝統的なエスタブリッシュメントのスピリットだとすると、「できるけどやらない」がアジャイルのスピリットなのかな、って改めて思いました。

f:id:wayaguchi:20191202060041j:image

というわけで、今回は久しぶりに会場が変わる大ジャンプですが、決して無理せず、いつもどおりが実現できたら嬉しいな、と思っています。初の会場はいろいろと不都合なこともあると思います。粗相も多かろうと推測しますが、みんなで作る空間ですし、みんなでいい感じにできればいいなと思っています。果たして何人が大崎に行ってしまうことでしょう。場所は御茶ノ水です。

f:id:wayaguchi:20191202055803j:image

 

漫才師のナイツが幕間に音声出演していて、漫才形式で会場諸注意や、休憩や終了をアナウンスしていたのが素敵でした。パクれるものならパクりたいです。Omoiyari.fm の人とかやってくれないかな。(無茶振りしてた)

数千人も入るような大きなホール久しぶりでした。

f:id:wayaguchi:20191202053335j:image

みんなが納得する答え

みんなが納得する答えが議論の結果としては出ないとしても、作業の先にはあったりするんです。なので、ちゃんと手を動かしてちょっと作ってみるのが大事。

f:id:wayaguchi:20191202062006j:image

先週、紙の申請書を用意する件がありまして、一枚目を書いたら色々ご指摘をいただいて、二枚目を書き直す結果になったんですが、結局一枚目も使うことになって、そういうのも一枚目を出したことによるコミュニケーションの結果だったりして、「申請書って実務者にとってはコミュニケーションツールなのだ」という思いを新たにしました。逆に書き方を教えてくれる人がいないときの入力フォームの絶望たるや....。