2021年3〜4月に社内で共有したアジャイル開発関連の記事
社内でアジャイル開発を議論するSlackチャンネル #tech_agile に見かけた良記事のまとめです。この記事は第4弾です。
- 2020年9〜10月に社内で共有したアジャイル開発関連の記事 - tuneの日記
- 2020年11〜12月に社内で共有したアジャイル開発関連の記事 - tuneの日記
- 2021年1〜2月に社内で共有したアジャイル開発関連の記事 - tuneの日記
ノウハウ・知見
スクラムで回す開発の実際の話
ここが好き
より良いものを作るために、プロダクトマネージャーと開発者が話をした方がいいなら、手を止めるのを気にしない。
ただ、全員が話をすると時間を持っていかれすぎちゃうから、代表で1人が話をするくらいがいいかな。その人が「他のメンバーの意見も聞いたほうがいいな」と思ったら、みんなに聞く。くらい。これは開発者を代表するくらいのスキルが必要なので、テックリードというロールの人がやる。
サービスの運用による突発対応は、あるものとして考える。突発対応が入ったらデイリースクラムでチームとしての動きを話し合う。「今日は突発対応を優先させるから、別のチケットの作業を止める」みたいなの。もし日中に緊急のものが入って次の日のデイリースクラムまで待てないって場合は、テックリードが開発者を集めてチームとしての動きを話し合う。
専門チームは他にも色んなチームとやり取りをしているから、そのようなチームとのやりとりはスプリントをまたいでやることになる。それも全然気にしない。 組織の活動も後輩の育成も楽しい。
大切にしてるのは、そういうのも全部ひっくるめたうえで開発できるものが、自分たちの健全なスピードなんだなって受け止めること。
リソース効率とフロー効率
細く長く開発続けるのやめたいねーという社内の話から
www.slideshare.net
Whole teamという考え方
勇気をもって質問する。分かるけどまだまだできてない時あります
角を立てない質問の仕方
「ちょっと自分の理解が追いつかなくなってしまったんですけど〜」とか「混乱してきたので自分の頭を整理したいんですけど」って枕詞につけるという話でしたー
— aki.m (@Aki_Moon_) 2021年3月11日
自分はメンバーの感情が過剰に気になってしまうので、誰も傷つけない言い回しで凄い役立っています
Working Agreementでは下限も話し合うと良いのでは無いか?
チームのWorkingAgreementの話。「こういう風にしようね」てのはよく話す合うやろうけど「これはないな」みたいな下限的なものも話し合うと良いと思う。理想はいくらでも話し合えるし、やっていく中で変わっていくことが多い。それに比較すると下限はそこまで変わらない印象がある
— yoh nakamura (@yohhatu) 2021年3月11日
夕方にやる短いミーティング→「帰りの会」
弊社でも帰りの会いくつかできました。
チームラーニング
どういう生活リズムか、強み・弱み、コミュニケーションは話すのが良いかテキストが良いか、MTGに対してのスタンスなど具体的な質問をチームで共有することで働きやすい環境づくりを目指すチームラーニングというプラクティス
ホワイトボード(Miro)の使い方工夫
テンプレートを作ると「いきいき」しないよねという学び
スクラムマスターのキャリアを考える上で、ぜひ立ち止まってやってほしいエクササイズ
他社事例
atama plusのLeSS事例
自分の感想
- 議論を重視する文化があったからか、議論時間が無駄に増えてしまったのかも。
- Rettyではリファインメントの人数を減らし、信頼してもらう方向に倒している
- atama+のリファインメントは10〜20名で、そのうち8人ぐらいが議論する感じらしい
- LeSSを導入する問題背景が全社で揃ってなさそう
- Rettyの場合は「ミッション間の根回し」にパフォーマンスが左右されることが1番の課題だった
- 「開発効率が上がる」ぐらいの意識なので、LeSS導入過程でパフォーマンスが落ちる(新しい領域をチームが学習している)ことに耐えられなかったように見える。
楽天 椎葉さんのチーム作り事例
うちと似ているなーと思うところもあるし、うちより洗練されてるなーと思うところもある。さすがな感じ
GMOのレゴスクラム
勉強会・カンファレンス
モンハンスクラム
マイクラとか繰り返し作業ゲーとスクラムの学習は相性が良いのかも
入社1年目の新人がふりかえりを習慣化して学んだこと
その他
スクラム用語を使わないスクラムの説明
スクラムってカタカナ語が多くて人に説明しにくいって言われたので、スクラム用語使わないで説明する資料作ってみた pic.twitter.com/KiFxXjMNgs
— Ryutaro YOSHIBA (@ryuzee) 2021年3月4日
スクラムとアジャイルのおすすめ本
個人的には「アジャイルな見積もりと計画作り」と「エクストリームプログラミング」で良いんじゃないかと思っています
危ない兆候
こう言ってるときは、立ち止まった方がいいかもよ pic.twitter.com/RDsh1oFc8Q
— Ryutaro YOSHIBA (@ryuzee) 2021年3月24日
SmartHR製のプランニングポーカー
リモートでバックログリファインメントをやる際に、物理プランニングポーカーを使うと顔出しする動機付けになるかもなーと思ったり。
ボブおじさんのインタビュー翻訳
CleanAgileが書かれた背景を掴むのに短くまとまっていて良き。
“The New New Product Development Game”とAgile with ScrumとLean
ユニコーン企業のひみつ/訳者あとがき
「ユニコーン企業はなぜスクラムをやってないのか」に対してと思われる原田騎郎さんのツイート
よりよいプロダクト・プロセス・チームを見出すために安定的に不安定な状態を作り出すための枠組みというのがスクラムの立ち位置なので、結果としてスクラムじゃなくなっていくのは自然なこと。それらを見出す過程の中でスクラムが役に立っているといいなぁ、くらいですね。
— HARADA Kiro (@haradakiro) 2021年4月30日
LeSS StudyでRettyでの大規模スクラム事例紹介をしてきました
2021年4月17日に行われたLeSS StudyでRettyでの大規模スクラム事例紹介をしてきました。
先月のatama plusさんの事例紹介に続いての事例紹介でしたが、多くの方に興味を持っていただいて参加いただき、自分たちの取り組みを整理する機会をいただくことができ感謝しております。
1時間半の長丁場でしたが、参加してくださった皆様、遅くまでお付き合いいただきありがとうございました。
反応など
Discordで頂いたQ&A
Q: チーム横断のリファインメントがどんな感じのことをするのか
A : 複数チームでのバックログリファインメント - tuneの日記
Q: 技術負債はどこからあげられてバックログに追加される感じですか？
A: エンジニアが積むことが多いです。ユーザー観点でも影響がある場合は企画担当にお願いすることもあります。
Q: レビュー→振り返り→プランニングの順番を変えている(こだわっていない？)ところはどういった経緯をたどったのか
A: スプリントレビューを朝一(11:00〜12:00)にしているのですが、メンバーのお昼休憩時間が揃いづらく、振り返りを優先するとプランニング開始時間が安定できないからです。食にこだわりがあるメンバーが多いからか、遠くのお店へ外食し休憩時間が長くなることがよくあります。振り返りを先にした方が良いと私も思うのですが、特に問題も起きていないためチームに委ねています。
A: toCとtoC、Webとアプリのように領域をまたがる大きな機能で実装箇所を一箇所に統一したり、ボトルネックになっている箇所を協力して解消したりという動きは増えました。
Q: 1チームスクラムに比べてPOと開発者の距離が遠くなったりはしませんでしたか？
A: 企画者と開発者の距離が遠くなったというのはメンバーからも上がっており把握はしています。LeSS導入前は一つの組織で以心伝心で動けるところがありましたが、企画者がWhy・開発者がHowに責任を持つにはそれなりの距離を保ち、議論する風土も必要ではないかなと思い、そちらを育くむように心がけています。
Q: POが歩き回ってコミュニケーションとのことですが、オンラインだと歩き回って会話できない気がしますが、オンラインならでは工夫ってあったりしますか？
A: Slackのチャンネルをよく見て、気軽に話しかけているのを見かけます。
Q: コロナ禍で延期しなければ、大物2つはLeSSのままやっていたんだろうか？
A: LeSSでやりたかったですね。スピードは出せたけど属人化はしちゃったよねという反省があり。
Q: PdM チームは、何チーム何人くらいですか？
A: 3〜4人ぐらいです。目的別に6チームぐらいあります。
Q: プロダクトロードマップとPOの関係性はどんな感じですか？（POが決めている？）
A: プロダクトロードマップはPOも入って議論していますが、作成は別のPdMが主導しています。初めての試みなのでどういう関係が良いのか自分たちも模索中です。
Q: 複数のスクラムチームを立ち上げるにあたり、見本となるスクラムチーム（1チーム？）があったからうまくスケールできた、のでしょうか？
A: スクラムチームとしてうまく回っている時の感じがわかるメンバーがいた方が良いと思います。そうでないとスクラムの問題なのか、LeSSの問題なのか切り分けができないので。
Q: 組織目標というのはビジネス目標ですか？
A: エンジニアリング部門はサービス開発・運用に責任を持つ部門ですので「インシデント数」「着手からリリースまでの期日」「サービスパフォーマンス」などの数値を目標として設定しています。
Q: インフラ的なメンバは各フィーチャーチームにそれぞれいる感じですか？それとも横断的ですか？
A: 横断です。フィーチャーチームのメンバーと混在で24時間サービス監視・アラート対応を行うオンコールチームを組織しており、協力してサービス改善に取り組んでいます。
Q: アウトカムかどうか検証するときに、どうやってされていますか？
A: 自分たちも模索中でプロダクトマネジメントを読んだメンバー同士で「それってビルドトラップでは?」「それはアウトプットでは?」「アウトカムはこういうやつでは?」と議論しながら良い表現・やり方を考えています。
Q: 導入期の自分に一つ助言できるとしたら、どんなことを伝えますか？
A: 2社目の導入なので特に焦りや苦労もなかったのですが、初めて取り組む人に伝えるなら成果が出るのに時間がかかるので「焦るな」でしょうか。
Q: スプリントゴールの話がありましたが、どうやって決めてますか？チームがたくさんあると同時に進むものも多くて難しく苦戦しています。。。
A: 雑多なバックログアイテムをカバーするような表現を昔はしていましたが、最近は主要なもの(上位にある、開発規模が大きい)物に絞り、目的やアウトカムを意識した表現で書くようにしています。
Q: ふりかえりはKPTが多いんですかね？
A: 私がコーチとして教えたのはKPTだったんですが、メンバーが自主的に勉強・いろんなやり方を取り入れています。 現在では「よこなーる」を取り入れているチームが多いです。
A: 自分がマネージャーを担当するメンバーの人数が増え、1人でマネジメントできる上限を超えてしまったため、2021年1月にマネージャーを増やし2人でtoC Web開発を見る体制になりました。 マネージャーが増えた際、組織名を考える必要があったのですが、「人数が増えただけで対等の立ち位置」「マネージャー(評価者)が違うだけで、協力して開発にあたる」ことが表現できるいい名前がないかなーと悩んでいました。
「Web開発第1 / 第2」を提案したのですが、堅すぎてNGでした。 「Webメディア開発(フロントエンド寄り)」と「Web基盤開発(バックエンド寄り)」を次に考えたのですが、メンバーが期待される役割を意識してフィーチャーチームの良さが消えると思いやめました。 他社の例に良いものがないかと探した結果、エムスリーさんの「Unit」に落ち着いています。今の私の正式な役職名は「Retty株式会社 エンジニアリング部門 Web Unit1ミッション マネージャー」です。
Rettyさんの勉強会が無茶苦茶面白くて感激している。あとだいぶ生々しくて燃える。
— ナカミチ #BacklogWorld2021運営委員長 (@ici_mici) 2021年4月16日
滑り込み参加！/ LeSS Study Retty 事例講演 「LeSS導入から1年半、Rettyが経験した改善と悩みについて」 https://t.co/3FonHEqmNA
— toshi ohtomo (@toshiotm) 2021年4月16日
発表資料で参照した参考文献
- 「1プロダクトをみんなで作る！」Rettyでの大規模スクラム(LeSS)導入記 - Retty Tech Blog
- Rettyの開発組織をぶっ壊して、LeSSを導入した話をPO視点で書きました｜のぐちひろき｜note
- 「全社で大規模スクラム(LeSS)移行して1年間」 #RSGT2021 での質問に、Retty執行役員が全て答えました - Retty Tech Blog
- もりあがるスプリントレビューをしよう / Let's organize a energetic sprint review - Speaker Deck
- Go To Eatキャンペーンでの神対応はどのようにして生まれたか？ Rettyのプロダクト開発と組織改革の裏側 (1/3)：ProductZine（プロダクトジン）
- Go To Eatキャンペーンを支えたプロジェクトマネジメント / GtE Project Management - Speaker Deck
- PMが「開発を巻き込んだ施策相談会」で工夫したポイント LT - Google スライド
- プロダクトマネジメントをRettyの開発組織にインストールした話〜PO祭り 2021 Spring〜/Installing Product Management in Retty - Speaker Deck
- スクラム開発におけるマネジメント、目標設定・フィードバック・評価 / Management in Scrum - Speaker Deck
"hey Talk" PdM #2「エンジニアと連携した優先順位決め」を聞いてきました #heytalk
はじめに
「企画側と開発側で深く議論して優先順位決めるの難しいなー」と課題を感じていたところ、heyさん主催の勉強会を見つけたので参加してきました。
tl; dr;
- 「やらなければならないもの」はやった先に何が得られるかを明確にすることで、着手順を明確にできたり、取り組むモチベーションをあげることができる。
- 工数大・リターン大のものはロードマップ積む、工数小・リターン中のものは手が空いた時にやっていく。
- 職種間を超えて意思決定をするには腹落ちしてもらえるまできちんと伝え合う努力をする必要がある。heyでは随筆のような長文ドキュメントをしたためる文化があり、それを活用している。
LT① 「STORES 決済における【攻めの安定性】」
プロダクト開発で考えなければならないことは2つあり、バランスを保たなければならない。
- やりたいこと
- やらなければいけないこと
プロダクトの「最適なバランス」はフェーズによって異なる。STORES決済は「やらなければいけないこと」がたくさんあるフェーズ。
「やらなければいけないこと」を「やりたいこと」に変えられると良い。 変えるには「チーム全員が顧客の事業のために必要なことだと理解し、腹落ちする」必要がある。 より具体的には「客が体験するストーリーと紐づけて理解する」必要があると考えている。
決済は客からみて引っ掛かりがあってはならない重要な要素だと考えている。 安定稼働はあたりまえのことではなく、サービスの強みではないかという発想の転換に至ることで、安定稼働という「やらなければいけないこと」を「やりたいこと」に変えることができた。 安定稼働が他社との差別化になるまでやり切りたいと考えている。
プロダクトマネージャーは、なんでもないことにも面白みを見つけられるような素養があると良いのではないか。
LT② 「エンジニアから見た hey の PM とプロダクト開発」
開発チームは職能横断チームで構成されている。目的はコミュニケーションの円滑化と、チーム内の意思決定を促すことである。
開発チームではプロジェクトを理解したり、自律的なチームを育む取り組みをしている。例えばプロジェクトのREADME(入隊キット)を用意したり、ドラッカー風エクササイズを実施したりしている。
PdMは「何のためにやるか」を考える責務がある、先の開発チームは「どうつくるか」を考える責務がある。 PdMは開発チームから「顧客の理解」について強い信頼(期待)が置かれている。
エンジニアリングマネージャーはプロダクトロードマップの計画をPdMと一緒に作ったり、プロジェクト開始前の事前調査(プリプロジェクト)のサポートでPdMと協力している。
PdMはいろいろ大変なこと・求められる責任の大きさがあるが、「コアの課題を見つけてフォーカスできる」「たくさんのステークホルダーからコアの課題を引っ張り上げる」ことがすごいと思っている。
トークセッション
やりたいことがたくさんある中で、やらなきゃいけないMUST案件をどう扱って優先順位決めるか
「やらなきゃいけないこと」は締め切りが決まっているのでやらないといけない。なので「やった先に何が得られるのか」をイメージして動くようにしている。 それが見えるとやらなきゃいけないことの中でもどれを先に取り組むかが見えてくる。 法律で決まったことは「やらなければいけない」だが、人が「やらなきゃいけない」と言っていることはそうでないことがある。 きちんと見極める必要があり、思考停止しないように気をつけている。。
ユーザーから寄せられる多種多様で膨大な要望に対して、やる/やらない、いつやるの優先順位をどう判断するか
[1例目] 要望は社員がGoogleフォームで気軽に投稿できるようにしている。Zapier経由でGitHub Issue化している。 エンジニアが週次リファインメントで工数感を相談している。その後「小案件リスト」化して着手しやすい状態にしている。 「小案件リスト」から汎用的な課題、かつ1〜2スプリントで完了するものを優先してスプリントに割り込ませている。 全体ロードマップは別途あるので、それを邪魔しないように一石三鳥が狙えるものを優先している。
[2例目] 組織規模が小さい時は毎週集まって顧客の声を議論していたが、現在は月一で報告会を開いている。 問い合わせのサマリ・推移などの定量情報や、顧客の生の声のような定性情報も共有している。 「解決したい課題」「発生原因」「解決案」まで整理した状態で共有している。
[3例目] Googleフォーム→slack投稿でカジュアルに要望を集める仕組みを設けている。 週次定例でCS Manager/PdM/EM/Designerが集まってロードマップに組み込むか検討する。 ロードマップは「将来あるべき姿」で作る。登り方は後から考える。
Q: ロードマップとユーザー要望との優先度ってどう決めているか
技術的負債とどう向き合うか
影響度・返済コストがある。 エンジニアから見てまずいものはエスカレーション・提言して、PdMから信じてもらい、エンジニア主導でやらせてもらうことがある。
ロードマップ作成。中長期のやることと短期のやることの紐付け
長い文章を書く文化があり、ドキュメントを活用して「まきこみ・議論・共有」を重要視している。 「決めたことを伝達して終わり」ではなく「理解して腹落ち」してもらうことを気をつけている。
感想
メンバー間のゆるい会話をたくさん聞くことができ、「良い会社なんだろうな」ということが終始感じられました。 思いを文章化する文化、職種間で互いの立場を理解してもらおうと努力する姿勢が根底にあることで、うまく優先順位づけが議論できる文化につながっているのだろうと感心しました。見習えるところは自社でも取り入れていきます。
LeSS Study atama plus 事例講演 「5チームでLeSSをしたatama plusがLeSSから学んだこと」
LeSS Study atama plus 事例講演
LeSS Studyが2021年にオンライン移行してからの第2回。atama plusさんの事例共有会がありました。
講演中に気になったこと、質問して回答をもらったことのメモ
LeSS導入前に社内で話し合いを結構した。
Q: どのくらい話し合った? → A: 3時間/日を5日ぐらい Q: どんなことを話し合ったのか? → A: 「LeSSを導入したらどう変わる?」「LeSS体制でのメンバーのスプリント内での振る舞い方とか」
LeSS移行時に開発を止めてみんなでLeSSを勉強した。
Q: どのくらい勉強したのか → A: 2週間
LeSS移行後の変化 - 移行前はPO3人体制→移行後は1名 - チームに求められるレベルが上がった。
問題点 - LeSS導入でPOが忙しくなった結果、Discoveryフェーズに関われなくなってしまった。 - → BX(Business Experience)という職種を導入 - POの代わりにDiscoveryに協力 - 複数チームでのバックログリファインメントに時間がかかり不評に - 得られるアウトカムが少ないものはチームを決めて1チームリファインメント & 開発に倒した
感想
議論を重視する文化があったからか、議論時間が無駄に増えてしまったのかも。
- Rettyではリファインメントの人数を減らし、信頼してもらう方向に倒している
- atama plusのリファインメントは10〜20名で、そのうち8人ぐらいが議論する感じらしい
LeSSを導入する問題背景が全社で揃ってなさそう
- Rettyの場合は「ミッション間の根回し」が1番の課題だった (参考 Rettyの開発組織をぶっ壊して、LeSSを導入した話をPO視点で書きました｜のぐちひろき｜note)
- 「開発効率が上がる」ぐらいの意識だと、LeSS導入過程でパフォーマンスが落ちる(新しい領域をチームが学習している)ことに耐えられないことはありそう。
大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法
- 発売日: 2019/01/30
- メディア: 単行本（ソフトカバー）
BacklogWorld 2021でGo To Eatキャンペーンでのプロジェクトマネジメントを話してきました #BacklogWorld #JBUG
はじめに
2021年3月13日に行われたBacklogWorld 2021で、RettyでのGo To Eatキャンペーンのプロジェクトマネジメントについて話してきました。公募セッションとして応募し採択されたものです。
反応など
ブログ
- Backlog World 2021 旅 ~Journey~ オンラインに参加しました | ヤマムギ
- 「Backlog World 2021 旅 ~Journey~ オンライン 」視聴レポート｜haly(k2hrm) / おだまりP｜note
- Backlog World 2021 参加レポート - mito’s blog
- backlog world 2021 旅 ~Journey~に参加しました。｜noddy｜note
- Backlog World 2021 に参加しました！！！
- Backlog World 2021 旅 ~Journey~ オンライン 参加リポート（その２）｜たかく しゅういち｜note
基調講演直後の登壇だったのに、まとめツイートの始まりが16ページ目からというのはびっくりです。いかにたくさんの反応がツイートされていたのかがわかります。
感想
YUMEMI.pm #1でも同じテーマの話をしてきましたが、きちんと整理した内容をお伝えできる機会が作れたことがよかったです。登壇後の懇談会で「公募セッションが来るか不安だったのですが、何がモチベーションだったのですか?」と質問をいただいたのですが、会社としても多くを学んだプロジェクトだったので、工夫した点が他者に伝わるよう整理し、広く記録に残しておきたいと思っていました。実際にこの後のプロジェクトでも似たような推進形態をとっており、成功に一定の貢献をしている手応えを感じています。今回の登壇でこのやり方・エッセンスを取り入れた事例が増え、さらなる改善のきっかけが見つかると良いなと思っています。
BacklogWorld自体の感想ですが、オンラインカンファレンスでありながら、熱量を逃がさない工夫が各所でされており、よく考えられたカンファレンスだなという印象を持ちました。Discord運営のカンファレンスだと外に盛り上がりが伝わりづらい課題がありますが、Twitterならその問題はありません。一番ツイートしていた人・いいねが多かったツイート・運営で選んだツイートを表彰する仕組み、ブログレポート枠の充実など、参加者の感想を吐き出させる仕組みがきちんと機能していることに感心しました。過去の開催経験や、地域ごとにあるコミュニティの下支えがあってこそのものだと思います。運営の皆様、聴講してくださった方々、ありがとうございました。
2021年1〜2月に社内で共有したアジャイル開発関連の記事
社内でアジャイル開発を議論するSlackチャンネル #tech_agile に見かけた良記事をよく放流しているのですが、社外向けでも需要があるかもなと思い試しに公開してみます。この記事は第3弾です。
ノウハウ・知見
具体的な事例質問(実例)を通して仕様を明確化する実例マッピングの紹介
バーンアップチャートを使った可視化
他社事例
SmartHR プロダクトデザイングループの活動
社内横断でUI/UXを改善するコミュニティができるとこんな感じなのかなと思いました。
atama plusのLeanUX取り組み
Hunter Industriesでのモブプログラミング
delyとメルカリの開発体制
Spotifyモデル2013とは違うように話されているんだけど何が違うのかがよくわからず。中の人にぜひ聞いてみたい。
勉強会・カンファレンス
Regional Scrum Gathering Tokyo 2021
スクラムマスダーさんの恒例スライドまとめ
ハイブリッドカンファレンスだったので録画も順次公開されています。
ふりかえりカタログ speakerdeck.com
アジャイルコーチとVPoE/EMの違いについて。 speakerdeck.com
カネとAgile
www.slideshare.net
ヒット商品を生み出すプロダクトマネジメントブースター
Developers Summit 2021
リモートワークで取り組むべき事。
EnPitでの学び
その他
スクラムチームの成熟度モデル日本語訳
字が小さいのでもう少し大きい画像が欲しかったり → 公開していただけました！ 【翻訳】あなたのスクラムチームの成熟度は？ | Ryuzee.com
スクラムチームの成熟度モデルに関する基準の例がCCライセンスで公開されていたので、日本語化したものを共有します。元ネタは、https://t.co/lFsD9KDUf1 pic.twitter.com/v1HlDK3z1k
— Ryutaro YOSHIBA (@ryuzee) 2019年8月21日
認定LeSS実践者研修
2021/6/2から3日間。
Certified LeSS Practitioner - June 2, 2021 @ Tokyo - Large Scale Scrum (LeSS)
スクラム実践者が知るべき97のこと が近日発売
目標・評価で使ってはダメなキーワード
友達の黒井のFBに書いてあった言葉が胸に刺さる。。。
— ネモトノリユキ＠ソフトウェアテスト技法練習帳 発売中！！ (@nemorine) 2021年2月18日
『昔、受けた研修で「目標や評価に、推進、連携、共有、向上、効率化、明確化、努める、図る、という言葉は使わないように」って言われたのがとても心に残っていて大事だなーと思ってます。』
これ、TRYとかでつい使っちゃうワードでしょ。。。
Regional Scrum Gathering Tokyo 2021に参加しました #RSGT2021
はじめに
去年に引き続いて3回目の参加です。去年はスポンサーとして参加しましたが、今年は個人参加です。 Rettyから登壇者が出たので現地で参加する予定でしたが、結果的に3日間オンライン参加としました。 Discordの議論を横目に発表を聞いたり、早朝・深夜に他の参加者と無理なく交流が図れたりしてこれはこれで良かったかなと思っています。
聞いてきた話など
「全社で大規模スクラム(LeSS)移行して1年間」Retty執行役員が全て答えます
結果的に3件プロポーザルを出したのですが、これが一番採択されて欲しかったので決まったときはとても嬉しかったです。 自分も含めたパネルディスカッションにすることも考えましたが、「アジャイルのコミュニティにあまり出入りしていない」「導入推進者(自分)よりも上位の職位の人が語る」方がインパクトも大きく、より本質が伝わるかと思いこのような形にしました。
45分のセッションで40の質問が集まり、多くの人の興味を集められたのではないかと思います。
- Regional Scrum Gathering Tokyo 2021 Day 1 「全社で大規模スクラム(LeSS)移行して1年間」Retty執行役員が全て答えます」 - Qiita
- Regional Scrum Gathering Tokyo 2021 Day 1 「「全社で大規模スクラム(LeSS)移行して1年間」Retty執行役員が全て答えます」 - Qiita
Rethink Scrum from a Japanese cultural perspective
23枚目のスライドが好き、「場の文化として生まれ、個の文化のために標準化」この後に続く「空気が場を支配する」の見解も面白かったです。 参考にされた日本と、体系化したアメリカと、そもそもベースが違うし、見つめる人も違うんだから、違った見解を持つことがあるというのはこの先気をつけておきたい。
終盤に出てくる「トヨタのチーフエンジニア(主査)に習いたい」のは自分も考えたことがあるけどまた答えは出ていません。 「大変だから分担して責務持とうぜ」って言うのは楽だけど、主査の凄さって分担しても出せるんだろうか・・・うーん。
アジャイルを忘れるチーム Unlearn Agile
わかるような・わからないようなスライド37枚目。 チーム・メンバーの直感を信じてそれを大事にすると言うのはわかる。直感はいつもだいたい正しい。 でも「ある程度型やルールに従って直感を養う期間が必要ではないか」とも思う。
LeSSのマップは原理・原則が中心にきて、最低限のフレームワーク、条件によって有効なガイド、導入する現場ごとに試行錯誤してもらいたい実験が囲む形をとっている。LeSS実践者研修受けた時はこれはこれでしっくりこなかったけど、決まりや試行錯誤の数で一番多いものが外側にきて土台になるという3角錐のような立体を思い浮かべるとそういう絵なのかなーと今は思える。
キョンさんのマップも視点を変えるともっと自分にしっくりくるかもしれない。
患者さんや顧客に最大の価値を提供するために ～外資系製薬企業が組織全体の変革を目指しアジャイル導入～～
グローバルな製薬会社が、トライアルとして日本から組織・文化変革に挑み、成果が出てきましたと言う事例紹介、今回のRSGT2021講演で一番のお気に入りです。 小さく始める、社内からメンバー(スクラムマスターとか)を募る、広げるときに研修・周知など丁寧に行う、会社の協力を取り付けるなど、これまで多くの書籍・事例紹介・文献で示されている良いやり方が実例を伴って「ここまでやるんだぞ！ お前らはやったのか！？」という迫力となって襲いかかってきます。
「弊社もDXを実現し・・・」とか言っている会社は見習うことがたくさんあると思います。資料公開して欲しいなー。
アジャイルコーチとVPoE、あるいはEMの間にあるもの
RSGTの参加者で「アジャイルコーチ」が増えてきているように感じるのですが、自分は「自社事業」で「当事者として」携わることが楽しいと思って過ごしています。それだけに発表者の悩みがすごくよくわかり、アジャイルコーチとEM/マネージャー/VPoEの違いがよく整理された資料がとても勉強になりました。
アジャイルコーチの価値に「客観性」があって、これはEM/マネージャー/VPoEと兼務してやることは難しいというのは納得。 社内ではアジャイルに詳しい人としてコーチのように思っているかもしれないけど、自分は主観で動いている「アジャイル助言者」ぐらいなんだと思う。 なので「おかしなことをやっていないか」事例発表を行うことで定期的に外部の目が入るようにしているところがある。
野中郁次郎のスクラム再訪問(Nonaka's Scrum Revisited)
普段使っているスクラムがどういう理論に根差し、効果を発揮しているのかを歴史を追って解説していただき、3日目の基調講演の入りとして最高でした。 SECIモデルとか過去に目にしたことがあった気もするんですが、今回初めてつながりが理解できました。 社内でもスクラムをもっと深く理解できるよう上映会の予定を入れています。
Discordでの交流・情報交換
3回目の参加ともなると旧知の知り合いも随分増えましたが、今回初めましての方とも繋がることができました。 昨年、何度か登壇していたことで自社の事例を聞かれることもあり、今後も継続して事例紹介を続けていければと気持ちを新たにしました。
今年の感想
「泥臭く、全力で殴り合いながら、より良い何かを追求していく」しかないんだよねという再確認が最後の基調講演でもらったメッセージです。
今年も一層の精進を目指し、日々の実践・コミュニティへの貢献をやっていきます。
