Regional Scrum Gathering Tokyo 2020に初参加してきた話[Day2]

Day2

Day1からめっちゃ間が空いてしまいました。あの楽しかったRSGTもう2週間も前になるのか!

f:id:daidai7:20200109170146j:plain
藤村さんのしくじり先生

キーノート Lost in Translation: The Manager's Role in Agile

2日目のキーノートは、CAL(Certified Agile Leader)などのコーチを務める、Michael K Sahotaさん。 RSGT Day2の参戦記録を早く書きたかったんですが、実はこのキーノートの内容お咀嚼に時間が掛かってしまった感じです。

ざっくりの内容としては、初日のコープさんのキーノートにあった、「スクラムの究極系はマネージャーなんて要らないよね」という話に対して、自律組織はいわゆる理想郷でまだまだ道は遠く、いわゆるティールの世界に到達するまでには、まずはちゃんとヒトにフォーカスしてオレンジからグリーンの状態になる必要ってあるよね、と。

そこで取り上げられたXY理論の話も面白くて、ヒトは元来サボったり責任逃れをするのが好きで誰かにコントロールされることを要するという考え方のX理論と、仕事が好きで好きで自分のやりたい事にむかって何にでも興味を持って取り組んでいくY理論があり、マネージャーと呼ばれる層は、メンバーに対してはX理論だなと思うものの、自分自身のことはY理論に属するだろうという認知バイアスが働くことが多いよね、という話。

とはいえ、現場リーダー「だけ」が頑張って変わったところで、全部を変えることはできないので、そのためには、ある程度トップダウンによって組織ごと変わる必要があり、置いていかれがちなミドルマネジメント層においてもマインドセットを変えていって、組織みんなを変革に連れて行きましょうという話がとても印象的でした。

と、言う事ぐらいは、講演中に聞いてたメモをみても、RSGT2020ことを書いてるブログなどをみてもなんとなく書いてあるのだけど、イマイチ腹落ち、というか、正しく理解が出来ておらず悶々としてたので、サホタさんのブログを読んでみることに。 そこには、組織文化を変えていくにはまずリーダーが先に行き、リーダーシップが成長することで進められる、と。このあたりを頑張って理解すすめていくウチに、いろいろと内容が補完されてきてとても理解に繋がりました、とさ。

今回の講演内容には関係ないけど、先述のブログに出てきた、Spotifyのエンジニアリングカルチャーについてのビデオがメッチャ刺さったので載せておきます。もちろん、「そのまま」マネ出来るわけではない、というのは大前提としても、拾える部分はどこかあるよね、と。

vimeo.com vimeo.com

なにか少しでも実践出来るところ、とか見つけていきたいな、と思ったのでした。

ちなみに、タイトルである Lost in Translation は20年ほどまえに公開された東京が舞台のハリウッド映画からとったもの、だそう。

www.youtube.com

日本にJoy,Inc.を創る!ぼくらのジョイインクジャーニー3年間の軌跡

クリエーションライン代表の安田 忠弘さんのセッション。会社を立ち上げて数年、会社として目先の利益や数字を追いかけていたら、しらずしらずのうちに会社の空気が重くなったり、プロジェクトが炎上したりして、安田さん的にどん底になってしまった2013年頃に、Joy,Inc.に出会って、それをきっかけに会社をどんどん良くしていく話でした。 あれ、Joy,Inc.が話題になったの割と最近じゃ?って思ったら、原著は2013年発刊なんですね。 「あなたは喜びに満ちた人生を送りたいですか?」と聞かれて、Noという人なんて少ないと思うけれど、Joy,Inc.の中にも「それは困難な旅の始まり」とあるように、文化を変えていくことは、困難で孤独で勇気が必要な大変な道のりであるけれど、いまの状況がよくないと感じるのであれば、一歩踏み出すことが必要なんだろうと思いました。

ジョイ・インク 役職も部署もない全員主役のマネジメント

ジョイ・インク 役職も部署もない全員主役のマネジメント

Joy,Inc.といえば、いわきりさんのこのツイートにちょっと焦りを感じたり。

実際に経営層の方が、Joy,Inc.に感化されて会社を変えていく例はあまり多くないらしいそうですが、生き生きと仕事が出来るカルチャー醸成はしてみたいところですね。

そして、RSGT2018に、著者のリッチーさんのキーノートがあったのを機会に、もっと具体的に買えていくことになるんですが、スライドに出てきたHRTってなんだろ?と過去のブログを辿ってみると、Humility(謙虚)/Respect(尊敬)/Trust(信頼)の略だそうで、Team Geekにでてきたんですね。これはこちらもチェックしないと。

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

このセッション、とても面白かったんですが20分枠で、もっと聞きたいな!って思ってたら、なんとロングバージョンがあるとのことで!気になる…。

スライド資料はこちら。

www.slideshare.net

組織変更をして部長がいなくなってから起きたこと

Cybozu水戸 将弥さんのセッション。興味深いのは、水戸さんがここでいう居なくなる側の存在だったって話。この話は、年末に公開された Fukabori.fm のエピソードでも語られていて、気になっていたのでした。

fukabori.fm

ざっくりとした内容としては、Cybozuではソフトウェアのクラウド化にともなって、開発スタイルもアジャイルに進めるようになってきた際、10年以上続いてきたマトリクス組織をチーム主体のフラットな組織に変えていった話で、その際、いわゆる「部」がなくなってしまったので部長という役職を無くしました、というお話。 目的はユーザー価値を最大化するため、チームに必要なことをチームが決められるように権限委譲をしたよ、っとさらりと語られていますが、これはかなり大変だったはず…。そこを職能横断のモブをやったり、他の職能に体験入部する仕組みを作ってみるなど、自己組織化していくのに、システム的にもいろいろと考えられたそうで。

で、かつての部長陣はその仕事を解かれてなにをしているの?という話は、組織運営チームを結成し、いわゆる横断的にチームやメンバーをサポートする立場にシフト。しかもマネージャー陣もチーム化することで、いわゆるマネジメントの孤独からも解放されたのだというから興味深いです。

いきなり組織が変わる、ということはむずかしいでしょうし、この規模の組織改革だと、かなりの痛みも伴ったでしょうが、これはまさにサホダさんのキーノートにあった、トップが変わることで組織を変える、を体現しているのではないでしょうか。

スライド資料はこちら。 speakerdeck.com

大企業の縦割り組織の中でProduct Discovery Teamを創ってサービスをリリース出来た話

半谷 充生さんは楽天仙台支社でEC関係をずっとやってこられた方。 余談ながら、楽天社員は推し店舗なるものがあるらしく、半谷さんの話されていた米屋はちょっと気になりましたw

今回のお話は、楽天市場での、店舗と顧客とのチャットシステムを作る際に、他支社もリモートで巻き込んでの大規模チームでの開発となったが、トヨタの主査を中心として複数のコンポーネントエキスパートチームでプロダクトを開発するスタイルや、いわゆるLeSS(Large Scaled Scrum)からヒントをもらって、One Teamとして進めていくことを試してみたとのこと。 OneTeam感って、いわずもがな大事な話ですが、困難に対して、どうしても相手組織を指して他責になりがちですが、課題をそれぞれの組織をまたいで自分達事にすることで、プロダクトに対する「愛」を育むチームにしたらうまく行ったよ、とのこと。ありきたりな感想ですが、やはり仕事に対して愛や情熱、信頼などがあることが大事なんだな、と再認識しました。

スライド資料はこちら。 speakerdeck.com

キャリアパス再考:開発者と働くQAテスターからチーム支援するスクラムマスターへ

CI&Tという、ブラジル創業の日本オフィスでQAエンジニアからスクラムマスターにステップアップした、中村 ありささんのお話。 テスターとしてキャリアをはじめたが、同社では、1人1人にコーチが付く制度があるらしく、メンターさんと相談して、スクラムマスターとして進んだとのこと。スクラムマスターの素養として、テスターの時と比較して、POやチーム、案件、プロジェクトの状況などいろいろと気を配らないといけないので、マルチタスク的な働き方を身につける必要があるためマインドセットを変えたり、情報の管理に関して気を配れるようになったとのこと。

完全に余談ですが、CI&Tのオフィス、錦糸町の駅前ってことでウチからめっちゃ近い…w

スライド資料はこちら。

speakerdeck.com

アジャイルな組織を作って行くには?地銀で取り組むアジャイルな組織作り

元ゲーム業界(DARTSLIVE)だった松崎 一孝さんが、地銀であるふくおかファイナンシャルグループに転職して、アジャイル開発に取り組む事になった話。

そもそも地銀が何故内製でシステム開発をすることになったのか?の背景や、とはいえ行内に開発経験者が十分にいたわけではないが、このご時世、銀行員の行内でのキャリアチェンジが迫られているという背景もあり、無理にでもチームビルドする必要が出てきたとのこと。松崎さんでさえWebの開発経験は初めてで、実装に関しては未経験者ばかりだったので、いろいろと学んで、スクラムチームを作ったり、ペアプロをしたり、CI入れたり、TDD/ATDDを取り入れたり…と、ゼロベースから開発チームを育てていく様が赤裸々に語られていました。

リーダーシップの使い分けの話で、「チームの意見を尊重すること ≠ チームに遠慮すること」と、「自律的なチーム ≠ 自立的なチーム」と、現状のチームの状況に合わせて、リーダーがどのように接すればいいかを使い分けることが必要というのは、サーバントリーダーというものを取り違えるとあり得る課題感だな、と思いました。

松崎さんの活動がとても精力的で、福岡でのスクラム勉強会のコミュニティをやられているそうです。

fukuoka-scrum.connpass.com

スライド資料はこちら。

speakerdeck.com

10年たってやっとアジャイルがわかりかけてきた話

HoloLensなどの、いわゆるxR技術関連のプロダクトの開発を行っている、ホロラボ代表の中村 薫さんのセッション。メンバーがHoloLensを被ったアー写みたいなのがメッチャカッコよかったですw

自社サービスは、きちんと作ってきちんと売らないと会社が死ぬので、より真剣似考えることが必要だが、受託よりも自分達が自分達のビジネスに対して責任を持ってプロダクトを作れる状況において、アジャイル開発はより合っているとのこと。

スライド資料はこちら。

speakerdeck.com

最高のScrumをキメた後にスケールさせようとして混乱した(してる)話

今回参加されている多くの人が、おそらくRSGT2020のベストセッションの一つなんじゃ?と挙げるだろう、クラスメソッド藤村 新さんの講演。しくじり先生のフォーマットで藤村さんの取り組みとしくじり談が展開されましたが、本家番組よろしく、見てるだけでぐぐっと引き込まれる内容でした。 某外資系コーヒーチェーンのシステム開発を担当する際、スクラムマスターとして1つのスクラムチームを作ってうまくプロダクトをリリースできた、という話で、スクラムの文脈でいういつでもリリースできる状態を作るという観点から、開発前に決めた方がよかったことベスト3があったそうです。 一つ目の「明確なコンセプト」に関しては、当たり前だろう…と思うかもしれませんが、自分の観測範囲でも結構コレがブレてて苦労してるプロジェクトがたくさんあるような気がします。インセプションデッキにおけるエレベーターピッチ的なもの、ほんと大事ですよね。 二つ目の「3つのフェーズ」に関しては、プロダクトを、「実用最小限の機能をもつMVP」、「リリースするのに普通作るでしょ、というMUST」、「リリース前に整えておく、ADDITIONAL」の3つの段階に分けて実装し、MVPフェーズでちゃんと背骨を作ってどんどん肉付けして行くというやり方。背骨駆動開発、みたいな言われ方もしますが、これも出来るようで、外圧などによりなかなか実践できないことかも。 三つ目の「デザイン先行FIX」に関しては、アジャイルでありがちな、デザインは固めないというアンチパターンを避け、ちゃんと都度リリース出来るデザインをFIXさせることを重要視したという話。これも…(ry

ここまでだと、とても良い話ですが、後半がしくじり話。 先の話の成功から、クライアントから他の2チームにもスクラムのやりかたでスケールして欲しいというオーダーが。まずは成功しているチームと別チームとを混ぜて、成功体験を共有してからチームを分割し本格的に拡げようとしたが、一瞬でチームが崩壊してしまい失敗したという話。このときの問題は、チームが大きすぎた、コミュニケーションパスが爆増した、PO間での意思決定が難航した、またそれにより悪い印象が付きすぎた、という最悪な状態へ。 その時の一番の問題は、SMである藤村さんの目線の問題。スケールさせる際に、チーム目線でなく組織目線で考えてしまって雑につっくつけたこと。スモールチームで成功したという前提を軽視したこと、だそう。 ではどうすれば良かったか。優れたスモールチームをたくさん育てる、が正しいステップで、よく自己組織化されたチーム同士は、ヘンにスケール手法を押しつけなくとも、自然に連携して進めることが出来ること。そのためにはチーム目線をしっかりと持って育てていくことが重要だと。このあたりは組織マネジメントの観点でもやりがちなので、注意しなきゃな、と感じました。 ちなみに、スクラムのスケール手法は、ここではScrum of Scrumsが取り上げられたが、知識が少なめな自分は、LeSSが一般的なのかな?って思ったんですが、SAFeなるものがあるんですね。シェア3割なんですって…。 でも、こう言う記事もあり、確かにスクラムの文化が根付くまえにうっかり導入すると地獄絵図しか見えないんだろうな…と。Scrum@Scaleの記事でも、まずは「良いチームを2つ育てる」ありきなんだな、というのがスケーリングに関しての学びでした。

スライド資料はこちら。

www.slideshare.net

Day2のネットワーキング

この日は残念ながら、仕事のために終了後にすぐ離脱。 Twitterなどを見ていると、地下の中華屋が盛り上がっていたようなのでとても残念…。