tuneの日記

アジャイル開発、組織変革、マネージメント、ファシリテーションについて学んだことの記録

分散アジャイルチームについて考える会でスクラム開発におけるマネジメントの話をしてきました

マネジメント 勉強会 アジャイル スクラム 組織

2020年12月17日に行われた分散アジャイルチームについて考える会でスクラム開発におけるマネジメントの話をしてきました。

distributed-agile-team.connpass.com

スクラムフェス大阪の話の続編であり、当時いただいた質問を元にRegional Scrum Gathering Tokyo 2021にプロポーザルを出していたお話となります。プロポーザルは残念ながら落選してしましましたが、勉強会主催者のきょんさんよりお声がけいただき、興味のある方に話を聞いてもらえる良い機会をいただくことができました。

この勉強会ですが、存在は前から知っていたものの参加するのは初めてでした。「濃いメンバーが集まる、議論が大好きな勉強会」という印象を持っており、せっかくだから答えのないもの・モヤモヤもそのまま持っていき、議論の種・酒の肴になればと思って資料を用意しました。そのおかげか勉強会のDiscordでは多くのコメント・質問・指摘をもらい、自分の過去登壇を含めても一番の熱量だったのではないかと思います。

プロポーザルの落選は残念ではありましたが、興味のある人に声をかけてもらい、話ができる機会が作れるのであれば今後も継続してプロポーザル投稿を続けていこうかと思います。

参加してくださった皆様、遅くまでお付き合いいただきありがとうございました。

参加レポート

izumii19.hatenablog.com

aki-m.hatenadiary.com

YUMEMI.pm #1でGo To Eatキャンペーン立ち上げの話をしてきました

マネジメント 勉強会 開発プロセス

2020年12月10日に行われたゆめみ主催のプロジェクトマネージメント勉強会で「Go To Eatキャンペーン立ち上げ」時のプロジェクトマネジメントについて5分のLTを行ってきました。

yumemi.connpass.com

今年の半分以上をGo To Eatキャンペーンに費やしており、締め切りありきの開発では久しぶりのプロジェクトマネジメント業を行いました。日々の業務で創意工夫したことを短くまとめて発表する機会をいただき、準備してくださったゆめみの皆様、聞いてくださった参加者の皆様に感謝しております。

「スクラムマスターは真のリーダーである」によって生じそうな誤解

スクラム スクラムマスター

Photo by Markus Spiske on Unsplash

はじめに

スクラムガイドが更新されました。 変更について色々と考察・議論を見かけますが、個人としては「スクラムマスターは真のリーダーである」が引っかかっています。

スクラムマスターとサーバントリーダーシップ

自分の理解ではスクラムマスターは役職では無く役割でした。プロダクトオーナーも役割、開発チームも役割であって、上下関係のない対等の3者が存在することでパワーバランスが保たれ、プロダクトに向かう一致団結する力が生まれていたのだと思っています。

「スクラムマスターとしてサーバントリーダーシップを発揮して欲しい」というこれまでの説明は納得感がありました。 自分がスクラムマスターを人にお願いする時にも「リーダーをお願いしているわけじゃ無いよ」「チームをまとめて、サポートしてあげて」と説明するようにしていました。

多くの組織にとってリーダーは肩書き・役職

元の文章にきちんとあたると「チーム・上位組織に奉仕する」とサーバントリーダーシップの流れを汲む説明が記載されているのですが、リーダーと呼称してしまうことで違う問題を引き起こしてしまう気がしてなりません。

日本の組織の多くは管理職になる前のステップに「リーダー」という肩書き・役職を置いていることが多いと思います。 リーダーが一人選ばれ、メンバーがそれに従い、プロジェクトを進めるという構造です。 リーダーは出世街道に乗っている人だったり、次の管理職候補でだったり、チームを技術的にも精神的にも支えている人です。 従来からあるリーダーの肩書きを付け替えてスクラムマスターに仕立て上げることも少なくないようです。

「スクラムマスターは真のリーダーである」という短いメッセージと、「リーダーはプロジェクトをまとめて引っ張らなければならない」という従来の発想が結びつくことで、リーダーの「導いてあげないといけない」いう誤った責任感、メンバーの「リーダーに任せて後をついていけば良い」という誤った認識を増長してしまうのではないかというのが私の懸念です。 コミットメントに責任を感じないスクラムマスターは問題ですが、とはいえ真のリーダーという言葉を引っ張り出してくることで意識してもらうのは短絡的かなと感じました。

おわりに

ガイドなのに解釈について皆が議論しているのが面白いなとブログ・Twitter・勉強会の様子を眺めていて感じました。 ガイドというよりも教典に近い位置付けをしている人が多いのだと思っています。

Agile Japan 2020でRettyの開発文化の変革の話をしてきました #agilejapan

LeSS アジャイル カンファレンス 組織 Agile Japan

はじめに

Agile Japan 2020の公募に応募したのが確か2020年の初春。5月の物理開催がキャンセルされ、11月のオンライン開催となり、ついに参加が叶いました。

応募した頃は昨年のAdvent Calendarで取り上げたLeSSの導入事例をもう少し肉付けして話そうかと思っていました。

しかし採択の結果20分枠となり、アジャイルジャパンの参加者層が「アジャイル開発これから」・「アジャイル開発始めてまもなく」の方が多そうなこともあり方針転換をしました。結果として「アジャイル」「スクラム」という言葉を使わず、なぜRettyが開発文化を変えようと取り組んだのかの核が伝わるように話を作って見ました。他の方の発表を見て「もう少し踏み込んだ話をしてもよかったかな」とも思いましたが、「アジャイルをやる」のではなく「アジャイルにやる」ことのアプローチが伝わっていれば幸いです。

発表の時に触れるのを忘れていましたが、今年のAgile Japanのテーマは「変える勇気、変えない勇気」でした。 20分の発表では取り組んだ結果簡単にできたように伝わる面もありますが、Rettyも1回で成功したわけではなく過去の失敗の下積みがあってのことだと考えています。 自分たちが何を大事にしていて変えてはいけないものが何か、そのために変えられることは何か。言葉にすると簡単ですがこれを継続することがアジャイルにやるの根幹にあるのだと思います。改めていいテーマでしたね。

Q&A・反応など

発表時にいただいたQ&A

Q1: 開発文化を正す戻すときに変えるもの変えないもので、特にポイントがありましたら教えていただけないでしょうか

A1: 会社・組織が大事にしてきたことには耳を傾けた方が良いと思います。 自分の中の正解を押し付けるのではなく、会社・組織にあった正解を一緒に探していくんだという姿勢が相手に伝わるのがポイントだと思います。

Q2: 組織、人の拡大に伴って、一番苦労されたことはなんでしょうか？どのように解決されていったのでしょうか？

A2: 表層的な事項が誤って伝わることでした。例えば「決定者が決めたことを開発がひたらすらこなす社内受託になってしまうんじゃないか」とか。 移行した1ヶ月は説明会・チームごとに説明・個別に説明などとにかく時間をとって誤解を解き、基本的な考え方を説明して回ることに専念しました。

Q3: サービス維持とGotoEatなどの突発案件とのバランス、優先度の考え方はどのようにしていらっしゃいますか？

A3: 四半期ごとに企画部門と開発部門である程度の握りをしています、例えば「サービス維持に20%の工数を使う」とか。 スクラムのストーリーポイントをざっくり分類し、割合がわかるようにしていています。 所定の割合に達しなかった/超過してしまった場合も、割合を戻すことに注力するのではなく、状況を整理して話し、目標を調整することに重きを置いています。

Twitterでいただいたコメント

Agile Japan 2020の感想

実は初参加だったのですが、Regional Scrum Gathering TokyoやScrum Fest XXXとは違った雰囲気でした。 それはコンサルタント・アジャイルコーチ、製造業・保険・インフラ、ツール販売、SIerなど固め・大きめの企業の参加者が多く、その事例発表の割合が多いことが影響しているかもしれません。connpassで見つかるアジャイル・スクラムの勉強会はWeb企業・自社事業でやっている人の参加が多いと感じていますが、それ以外にもこんなにもアジャイルを取り入れようとしている人が多いことに驚きました。

また発表スタイルとして事業会社の担当者+コンサルタント/アジャイルコーチの組み合わせが多いなと感じました。 発表構成が整えやすいから増えたのかと思われますが、事業会社の担当者の言葉で話してもらった方が臨場感が増し、聴く側も自分ごとに捉えやすいと個人的に感じます。 これからの1年間、自分の現場で奮闘し、来年のAgile Japanで情熱のこもった話ができる登壇者が一人でも増えることを願っています。 その実現のため、この後もAgile Japanはサテライト開催を計画しているようですが、登壇者の一人として、私に協力できることがあればお気軽にお声がけいただければ幸いです。

スクラムフェス札幌 2020で「もりあがるスプリントレビューをしよう」という話をしてきました #scrumsapporo

カンファレンス アジャイル スクラム ファシリテーション スプリントレビュー Scrum Fest Sapporo

はじめに

スクラムフェス札幌2020で登壇の機会をいただき話してきました。 Regional Scrum Gathering Tokyo 2020で相談したスプリントレビューのやり方について改善を試行錯誤してみたまとめとなっています。

他所のチームはどんなスプリントレビューをしているのだろうと疑問に思ったので会期中にGoogle Formでアンケートも取ってみました。

forms.gle

感想・反応など

Discord(参加者限定)でいただいた質問・コメント(抜粋)

はずかしながらレティだと思ってました。。

よくある間違いですが「れってぃ」です。よろしくお願いします！

youtu.be

ステークホルダーどころかPO的な人も来ない世界にいる。

見たことあります。不適切なプロダクトオーナー(適切な人が他にいる御用聞き、Fake Product Owner)ほどレビューに興味ないですよね。何をやるか決めるだけが仕事と思っているような。

MIROやMURALで付箋貼っといてーの方が、今ならいいのかな

「レビューのコメントや質問をチャットに流している」に対してだと思うのですが、これも使い慣れているならありでしょうね。 ただ最初の1枚目を貼る人の心理ハードルが高そう。

司会と賑やかし、どっちが重要なんだろう

個人的には「賑やかし」の方が効果が高い印象持ってます。

DONEになったらチェックか。チェックしたらDONEにはしないのかな。

チェックしたらDONEですね。「DONEになったと思ったらプロダクトオーナーに確認してもらいDONEとする」が正しいと思います。

アンケートより

スプリントレビューに感じる課題はなんですか?

そこから気づきが生まれることが少ない

はじめに計画ありきで、計画を分割してスプリントに落とし込んでいるとこうなりやすい気がします。 スプリントゴールに「なんでこれをやるんだっけ」の答えを含めておくと良いかと思います。

運用チームなので完成品のようなものが無い場合が多く、レビューの対象の選定に困る。

あー、わかります。チームの成果アピールが課題であれば551メソッドを試してみてもいいかもしれません。そうでないなら短くやったことと、それによる効果(KPIとかメトリクス見るとか?)を確認するぐらいでもいいのかなと思っています。

ステークホルダーがたくさんいるが、予定が急遽埋まって来れなくなることもあるため、週に複数回実施したいと思っている。

同じ内容で何回かデモするのはやったことがあります。全員集まると大変ですけど代表者でやればそこまで手間ではないですしね。 あとは初回を録画して、それをみてもらうという手もあると思います。

チームがドキュメントを読み上げるだけで、デモなどを通して顧客の感想、要望を収集できていない

プロダウトオーナーにデモしてもらうと、チームと違った視点で成果物をアピールしてくれると思います。

他の人に相談したいスプリントレビューの悩みはありますか?

スプリントレビューの場で、ＳＭは何をする人なのか、わかっていない

司会やファシリテーションすることが多いですね。個人的にはレビューでフィードバックが十分に収集できないことが続いたらそれを直す責務を持っているのだと思っています。

LeSS的な複数チームのレビューでうまくステークホルダーをさばきながら十分な時間をとる方法

指摘をメモしておき、「関係メンバーを集めて別途議論の機会を設けましょう」で良い気がします。

他の人に教えたいスプリントレビューのコツがあれば教えてください。

運用チームという特性上、ＰＯとＤＥＶ（インフラ）の1 on 1形式で１週間の納品の儀式として行う事にしたが。、POのマネジメント能力が飛躍的に向上し、コミュニケーションが劇的に改善した。

レビューを始めるとプロダクトオーナーの意識が上がることはありますよね。できたら確認しないといけないとか、次に何をするのか前もって考えておかないといけないとか、なぜそれをやるのか聞かれたらきちんと答えられないといけないとか。改めて文字にすると当たり前のことですが、なあなあでやっていた仕事の進め方が正されるような感じ。

自分のソリューションを自慢する

何回かに一回、レビューそのものの満足度を参加者にアンケート形式で聞くようになってから手応えあるレビュー増え始めたのでたまにアンケートとってみるといいかもです

これは良さそうですね。うちでも取り入れてみます。

言及いただいたブログ

qiita.com

時間がなくて発表に入れられなかったこと

RSGT2020でいただいたアイデアで紹介できないものが多数ありました。

  • ユーザーを真似て演劇形式でデモする
  • ステークホルダー / プロダクトオーナーにデモしてもらう
  • 実際に触ってもらう/遊んでもらう (ゲーム開発の事例)
  • スプリントレビューのテーマを決める
  • プロダクトオーナーに語ってもらう。

f:id:tune:20201108114217p:plain

スプリントレビューについてのアンケート結果

今日時点のアンケートを記事末尾に貼っておきます。

f:id:tune:20201108112414p:plain

2020年9〜10月に社内で共有したアジャイル開発関連の記事

開発プロセス 組織 勉強会 振り返り

社内でアジャイル開発を議論するSlackチャンネル #tech_agile に見かけた良記事をよく放流しているのですが、社外向けでも需要があるかもなと思い試しに公開してみます。有用そうだったらシリーズ化するかも。

ノウハウ・知見

リモートワークのノウハウ

Agileリーダーシップ研修の感想

www.creationline.com

コードレビューを通じたメンバー育成

リリースとはユーザー(とかステークホルダー)に使ってもらって、フィードバックをもらうことだよねという話

mactkg.hateblo.jp

Silver Bullet Clubによるチーム開発の振る舞いパターン集

scrapbox.io

中村洋さんのコーチメモ。

分量も多くたまに見返すと新たな発見があるかも。

scrapbox.io

振り返りのアンチパターン

agnozingdays.hatenablog.com

ふりかえり手法のまとめ

qiita.com

他社事例

atama plus

LeSSに移行したatama plusの開発体制図

atama plusはLeSS見学レポートもありました。

norihiko-saito-1219.hatenablog.com

カオナビ

自社に似ている雰囲気を感じる

SmartHR

LeSS事例、複数PdMの同期はうちも学ぶところがあるかも

tech.smarthr.jp

勉強会・カンファレンス

ふりかえりam KPT as ART

www.youtube.com

スクラムフェス大阪の基調講演書き起こし

logmi.jp

その他

Re: SmartHR 社内でスクラム勉強会を開催した話

スクラム

tech.smarthr.jp

練習問題が面白そうだったので自分のブログに回答を載せてみます。

第二回：経験主義と透明性・検査・適応について

Q: 経験的プロセス制御の実現において、なぜ透明性が重要なのでしょうか？ また、透明性がある状態の具体例を教えてください。

A : 「進捗どうですか?」→「順調です、進捗80%です」→「問題が発生してスケジュール遅延しそうです」というよくあるダメな進め方をしないため。 チームの外から見て見える形で状況がわかるように保つ。

透明性がある状態の具体例とは・・・

  • チーム外のメンバーがカンバンなど見える化された何かを見て、作業状況・進捗・リリース日の目安などがわかる。
  • チーム外のメンバーがチームに進捗に関する質問をして、誰に聞いてもすぐに同じ答えが返ってくる。
  • 開発中のものを部分的にではあるが動かして、できている状況を確認することができる。

Q : 経験的プロセス制御の実現において、なぜ検査が重要なのでしょうか？ また、検査できている状態の具体例を教えてください。

A : 定期的に検査を挟まないと、自分たちが進んでいる方向性・スピードが十分なのか判断がつかないため。

検査できている状態の具体例とは・・・

  • 開発中のもの・開発が完了したものを実際に動かして、受入条件を満足しているかどうかデモで確認してもらうことができる。

Q : 経験的プロセス制御の実現において、なぜ適応が重要なのでしょうか？ また、適応できている状態の具体例を教えてください。

A : 新しく得た情報・変化した状況に追従し、計画を見直していくため。週間天気予報を毎日更新するのと同じ。

適応できている状態の具体例とは・・・

  • 開発過程で受入条件の抜け・漏れが見つかったので項目が見直され、リリース日が見直された。

第三回：プロダクトオーナー / 開発チーム / スクラムマスター

Q : プロダクトオーナー / 開発チーム / スクラムマスターをそれぞれ何かに喩えてください。また、それに喩えた理由を教えてください。

A :

  • プロダクトオーナー：J.Y.Park 音楽プロデューサー、ビジョン・ゴールを示し皆を導く。
  • 開発チーム : NiziU メンバー、歌唱力・ダンスを磨き、ファンを魅了する音楽を提供する。
  • スクラムマスター : 歌唱コーチ・振り付けコーチ、メンバーに基本を教え、訓練によって苦手を共に乗り換え、プロダクトオーナーが描くゴールへ伴走する。

Nizi ProjectのJ.Y.Park氏に学ぶことが多いなと最近感じているので(※番組は未視聴)

Q : なぜプロダクトオーナーは「一人の人間」でなければならないのでしょうか？

A : 利益が相反する事象の決定は誰かが決めるしかなく、複数人いるとその判断基準や責任がぼやけてしまう。

Q : 自己組織化チームとは一言で表すとどんなチームでしょうか？ また、なぜ自己組織化チームである必要があるのでしょうか？

A : 自分たちの管理を自分たちでできるチーム。マネージャーがマイクロマネジメントで進めるのであればマネージャーの能力を超える成果は生み出せない。 何かしら見落としや対処遅れが発生し、チームが成果を出す阻害要因になってしまう。

第四回：スプリント / スプリントプランニング

Q : スプリントの長さを固定するのはなぜでしょうか?

A : 開発にリズムを持たせるため、一定間隔で経常的にアウトプットを出していくため、うまくいかない時に比較しやすくするため。

Q : 直近の 3 スプリントをすべてバーンダウンできなかったチームの中で、スプリントを 1 週間から 2 週間に伸ばした方がいいのではないかと議論になっています。あなたがスクラムマスターなら、どのように振る舞いますか？ その理由も教えて下さい。

A : スプリントの期間を延ばすのは簡単だけど今うまく行ってないなら振り返りをして短く改善していった方がよいし、もう少し1週間で続けてみたらどうかな? 3スプリント続けて終わらなかったなら、次のスプリントは思いきってやることぐっと減らしてみたら? もし全部終わったならバックログからおかわりしたっていいんだし。

理由：スプリントを長くするのは最後の手段。立ち上げ当初は振り返りを数多くこなして改善サイクルを作った方が良い。

Q : あるチームがスプリントプランニングに丸 2 日かかってしまいました（スプリントは 1 週間）。残りの期間で計画したタスクは全て Done し、PBI は PO に受け入れられました。あなたがスクラムマスターなら、どのように振る舞いますか？ その理由も教えて下さい。

A : 開発を始めて見落としが見つかったらリスキーじゃない? 今回はラッキーだったけど、いつも全てを見通してから開発に着手できるわけじゃないからある程度のところでプランニングは打ち切って手を動かすのは大事だと思うよ。1週間の開発なら2時間ぐらいが上限じゃないかな? 少し開発してみて改めて計画を見直すならそれでもいいからさ。

理由：設計は十分に行った方が良いが、手を動かさないと何も経験できない。経験できなければ開発を進めるリスクはちっとも下がっていないことになるため。

第七回：インクリメント / 完了の定義

Q : とあるスクラムチームの PO から、スクラムマスターであるあなたに以下のような相談がきました。「1ヶ月前に完了の定義を作ったのはいいものの、リリース後に完了の定義が満たされていないことがたびたび発覚します。また、完了の定義を満たした PBI であっても、リリースするまでにいくつかの調整を私が行なっています。どうしたらよいでしょうか？」。あなたがスクラムマスターならどのように振舞いますか？ また、その理由も教えてください。

A : 完了の定義が満たせていないのは開発チームと私の責任です。リリース調整までお願いしてしまって申し訳ないです。開発チームと話し合いをして改善を検討します。 ・・・と伝えて完了の定義をチームが確実にできるレベルにまでいったん落とす。その上で少しずつ完了の定義のレベルを再度上げていくようにする。

理由：守れない崇高なルールを掲げるよりも、自分たちのレベルに見合ったルールを守り、スキルアップしていく方が良いと考えます。

Q : とあるスクラムチームはレシピ検索サービスの Android アプリを製作しています。そのアプリは同じ会社の別チームが開発する Web API に依存しています。スクラムチームは毎スプリント Android アプリをインクリメントとして作成していますが、アプリは実際に Web API に繋いでいるわけではなく、スプリント終了時点ではモック API に繋いでいます。Android アプリの開発が Web API の開発に先行しており、モック API が返すサンプルレスポンスを使用するしかないためです。そのような状況で、あなたがスクラムマスターならどのように振舞いますか？ また、その理由も教えてください。

A : Web APIを開発しているチームのところへ行き、「バックエンドと繋いでの開発・検証を回していきたいので開発を手伝わせてください。お作法にはきちんと従いますのでmm」という話をして、コードを触っても良い了解を取る。

理由：チームは価値提供に必要な上(Androidアプリ)から下(Web API)まで触れるべき。そうでないとデリバリーが他依存になってしまい、安定したデリバリーができなくなる。