#あすみかんの上にあすみかん

#たのしいことしかかかないことをここに決意します

スクラムマスター7つの大罪: day.7「チームをうまく回せても、価値のあるプロダクトは作れない」【スクフェス神奈川2024、スポンサーで登壇します!】

qiita.com

🎄🦌メリークリスマス!🦌🎄

これはNE Advent Calenderの25日目の記事です! 毎年会社のアドカレに参加していますが、書く記事を2021年から+2ずつ増やしていき、2023年、ついに7日分の記事を書くことになりました。7日間あすみアドベントカレンダー的には7日目の記事です📚

この1年、スクラムマスターとして活動していた自分の間違っていたことをふりかえっていくぞ〜〜!!」&「あの頃読んで好きだった本のOSUSUME〜〜!!」を7日間通してやっています💪

かなりの大罪を重ねていた私ですが、いや〜〜〜ついに最終日まで来ましたっ・・・!! 寝るまでが!!25日ですからね!!*1 ここまでやりきったーーー!

数年前まで、わりと「自分が発信することって世の中の人はもう知っていて、もうみていて歯痒い気持ちになるだとか、ダッサ!って思われるんじゃないかなあ」と思ってわりと発信するのが怖かったのですが、最近はそれを乗り越えないとな〜と思っていたのでここまでおおっぴろげに恥ずかしいことが書けて満足です。きっと恥ずかしい思い・失敗をして私は強くなるんだ。その過程がちゃんと残っていた方がエモいですよね(??) あと、きっと、めちゃくちゃ知っている人が「これはこうだよ!!」って教えにきてくれるかもしれないし〜〜!!!どんどん発信していくぞ〜〜!!!

そして、何人かの方は、引用RTや直接だったりで、何かしら反応をしてくれのが本当〜〜〜にめちゃくちゃ❤️🫰BIG BIG HAPPY🫰❤️でした😭! 発信するのが大事とはいえ"大罪"ではあるので......心理的に自分のダメなところを晒してる分、激病みラップYOYOズゥーーン!!という感じでした。 そんな時に反応を頂けると「ウオッ・・・自分の発信誰かに役立ってるのかも」って思えるんですよね。

そのおかげでここまで来られました。本当にありがとうございます*・゜゚・*:.。..。.:*・'(*゚▽゚*)'・*:.。. .。.:*・゜゚・*

では、最終日やっていこう〜〜🍥🍥🍥

【まずは大宣伝】Scrum Fest Kanagawa 2024- 春の陣 -、スポンサーとして登壇します!

www.scrumfestkanagawa.org

2024/03/16(Sat) - 17(Sun) の2daysで行われるイベントです。

NE株式会社としてSilver Sponserとして協賛します!

スポンサーセッションとして5分枠があり、私が登壇する予定です!!🙏🎉

なんとなんと・・・小田原開催なのです!!!嘘でしょ〜〜〜!!!!!! 小田原城の女として〜〜〜!!!絶対に行くぞ〜〜!!!爪痕のこすぞ〜〜〜!?!?となり、CTOに直談判してスポンサーになることを決めました!やっていき💪💪💪

と、いうことで、大事〜な大宣伝が終わったところで本題にいきます。

チームをうまく回せても、価値のあるプロダクトは作れない

どんな罪か

様々な困難や大罪(?)を乗り越え、ついにPJは終わりを迎えました。

エンジニアは超効率でリリースしていけるし(最終2,3スプリントは常に巻いて作っていた)、スプリントレビューでは多くの人が興味を持って議論をするし、最後のふりかえりでも、チームとして"成功"したな、という感想に溢れていたし、リリースしたものも反響があり自分たちが期待していた数以上のユーザーが使用する機能となりました。

...なんだけど、なんだけど!!

なんか、どことなく「これでいいのか?」感が自分の中にありました。

「チームビルディング、ひいてはスクラムが最終的に形になったこと」「他ロールの人たちと何かを作り上げた経験」「それなりに刺さるものが作れている事実」...これ等は良かったのですが、うーん、なんか、虚無に向かってリリースしている感覚...?がありました。 "期待していた数以上"というところに満足しているのはいいのか?そもそも、このプロダクトは"自分たちが期待していた数以上のユーザー"を入れられたら成功としていいのだろうか?

自分のモヤモヤをだんだんと鮮明にさせていった経験

アジャイルコーチとスクラムマスターの集い

このイベントに参加して自分の中で鮮明な"大罪"になりました。

詳しい参加レポは↓こちらを見てくださいっ

asumikam.com

▲ 1日目、森 雄哉さんの「開発だけアジャイルな状況を越えて顧客のアウトカムにつなげる一歩」という発表をリアルタイムで見ました。 「これ、私(たち)のことだ.........」と強く思いました。

HOWはアジャイル、価値はウォーターフォールのまま。開発だけアジャイルに進んでいて、他ロールがウォーターフォールのまま。

プロダクトオーナーとして他ロールの人が一緒にスクラムをやっているとはいえ、やっぱりどこか「他から借りてきている感」は否めませんでした。というか実際に"そう"だった。 というのも、彼ら彼女らにも「ロールで追っているKPI」「通常業務」があるからです。そこに加えてこちらのプロダクトオーナー業をやってもらっている状況でした。 KPIとスクラムがうまく統合できる状態が理想的ですが、それをすぐに実現するのは容易ではありません。

つまり、プロダクトオーナーとして最高の状態で機能していたかというと、そうでないなというのが自分の所感でした。(day.6の記事も参照)

モヤっと感の1つとしてまだ追うべき最高のプロダクトオーナー像があるが自分の中で鮮明になりました。

zenn.dev

▲ そして、実は「アジャイルコーチとスクラムマスターの集い」に参加する少し前に、森さんに社内講演をして頂いていました。

2日目の夕食前、森さんとその時の話をし、「NEさんよかったですね、プロダクトのことを考える人がおおい」と言ってもらえました。とても嬉しかったのですが、自分の中では「自分はそんなことない、まだまだ足りない」と思っている最中だったので、その気持ちを吐露しました。

そして、話を聞いてもらっている、アドバイスをもらっている中で、私たちはユーザーに直接会って"観察"をしてないのでは?と、モヤモヤがまた鮮明になりました。

これが虚無感の大きな正体っぽい。そう気付きました。

全くその考えがなかった訳じゃないんです。例えば「ユーザーにインタビューする」とか「ユーザーにアンケートをとる」とか...そういうのは「やりたい」って思うタイミングあったし...と思ったのですが、森さんは「実際にユーザーを見に行かないと意味がない」と教えて頂きました。

......自分の中ではちょっとハードルが高そうだと思いましたが、でも、明確に、ここを越えないと私たちは成長できないと思いました。

ユーザーストーリーマッピング

また、day.3の記事Today's Osusume Booksでも紹介した「ユーザーストーリーマッピング」という本も、私の心に火をつけてくれた本です。 めちゃくちゃ好きなのでここでも紹介させてください。

優れたチームは、リアルな問題を解決するためにスコアカードKPI(重要業務評価指標)、顧客の苦闘状況、顧客が製品を使ったときに生成されるデータをよく見て、絶えず新技術を応用するチャンスを探しながら、ヒントやアイデアをつかんでいる。ダメなチームは、営業や顧客から要件を集めてくる。

優れたチームは、もっとも大切なステークホルダーが誰か、そのステークホルダーがどのような制約を抱えているかを理解し、ユーザーと顧客のために役立つだけでなく、ビジネスの制約の枠内で作れるソリューションを作り出すことに力を注いでいる。ダメなチームは、ステークホルダーから要件を集めてくる。

(中略)

優れたチームは、ビジネスKPIに大きなインパクトを与えられたときに祝杯をあげる。ダメなチームは、何かをリリースできたときに祝杯をあげる。

(マーティ・ケーガンによる序文)

マジで、マジで、刺さりました。

優れたチーム・ダメなチームがぶわーっと羅列されているのですが、ダメなチームに当てはまることがあるな、もしかして私たちのこと知ってる?という気持ちでした......。 序盤でブッ刺さりして、その後、どっぷり縋るようにこの本を読みました。

モヤモヤをまとめると...

  • まだ追うべき最高のプロダクトオーナー像がある
  • 私たちはユーザーに直接会って"観察"をしてないのでは?

この辺が、まさに自分の中で感じていた「なんか、虚無に向かってリリースしている感覚...?」を生み出しているモヤモヤなのだな、と思いました。

スクラムがうまくいってもアウトプットがどれだけ出せても、アウトカムを見ていない。 私たちは価値のあるプロダクトを作れてないんだ、と思いました。

気付けたら、あとは、取り組んでいくだけっ!

私は何をするのか?

ユーザーに直接会って"観察"する

はい。

紆余曲折ありましたが、年明けやります!

アジャイルコーチとスクラムマスターの集い」に参加して、「ぜってーーーーやるぞ」と思い、新しいPJが始まったタイミングで↓の活動をしました。

  • PJ始動後、まずサクッとできる追加機能をリリース
  • この機能が使われているか使われていないかをちゃんと追う
  • 追った結果「ターゲットとなるユーザーには使われていない」ことがわかる
  • 「ターゲットとなるユーザー」と話したい、と顧客対応の人たちに依頼する
    • ターゲットとなるユーザーが現時点では母数が少ないのもあり難航
      • その間にオンライン対応を録画してもらって皆で視聴できるようにする
      • 顧客対応の方がユーザーと話したログを見られる状態にして目を通す
    • というかそもそも12月は年末商戦でユーザーも忙しいので対応するリソースがない...
  • 色々もがいていたら顧客訪問できることに決まった。年明け行ってきます!!

ここまでできたのは他ロールの人がめちゃくちゃ協力的で同じ方向を向いているとか、組織で今まで築いてきた関係性とか、単に勤続年数が増えてきたので何事も怖くないとか(まじでこれはある)、色々ありそうですが、ようやく第一歩を踏み出せそう。

勝手にハードル高いと思っていることもやればできる。うまくサイクル回して、次は「ハードル高い」をぶち壊していきます。

プロダクトオーナーになった

なんかここまで書いていて、「スクラムマスター目線じゃなくなってないか?」みたいなの思った方、正解です。

今、新しいPJではプロダクトオーナーに挑戦しています。 理由は3つあります。

1つ目は「プロダクトが好きという思いが強いこと」です。

そもそも、私はずっと自分のプロダクトが好きです。 "もっと良くできる点"はいっぱいあるし、"溜まりに溜まった技術的負債"も少しずつ返していきたいし、それにしたってもめちゃくちゃ良いサービス!!夢があるなぁ〜〜どんどん広げていきたいなぁ〜〜といったかんじ。 とにかくやることはいっぱいある。なんて刺激的なプロダクトなんだ!と思いながら日々奮闘しています。

前PJでは「チームを良くすること」に目がいっていたのですが、終盤にかけて自分の中でプロダクトに対してもっとやってやりたい、と思う気持ちが強くなっていきました。

アジャイルコーチとスクラムマスターの集い」でも、「スクラムやプロダクトがうまくいかないのはプロダクトオーナーが悪いぞ(意訳)」という話がしばしば出てきており、うーんじゃあ私がやって全責任を負いたいと思い始めました。(?)

なんというか、もしアウトプットが刺さらないなら誰かのせいにするんじゃなくて、自分の責任にしてめちゃくちゃ考えたい。うまくいったら自分に自信を持ちたいし、何よりチームで喜びたい。そういう気持ちが強い。

2つ目は「内製できた方が色々動きやすい面がありそう」です。

day.6で書いた図の右の状態を目指す

元々のPJでは、プロダクトオーナーは委員会形式になっていて「営業・顧客対応の意見を余すことなく吸い上げる」「他ロールの人と同じチームで働きたい」という価値観から左図のような構図を採用していました。 しかし、先ほども触れた通り他ロールにも追うべきKPIがあり、どうしても通常業務(営業・顧客対応)の片手間になってしまいます。

「あれ?自分がプロダクトオーナーやればいいのでは?」と気づいた瞬間、なんかめっちゃ動きやすくなりそうな気持ちになりました。 割と自由に動けるエンジニアでプロダクトのことをめちゃくちゃ強く考える自分がプロダクトオーナーとして、同じように「余すことなく吸い上げ」「他ロールの人がめちゃくちゃ興味を持ってくれている状態を作ればいい」とおもったワケです。

3つ目は「他にスクラムマスターをやりたいと思っている人がいること」です。

私自身、スクラムマスターとして相談できる相手が増えるのは嬉しいことです。

たまたま同じチームに「スクラムマスターに挑戦したい」という同僚がいたので、「じゃあ私はプロダクトオーナーに挑戦する」と自分のやりたいことを素直に言えました。

この同僚がスクラムマスターとしてめちゃくちゃ成長してくれて最強のスクラムマスターになってくれたらお互いを支え合っていけそうです。 ワクワクしちゃうなそんな未来。

まとめ

本日は最終の〆となる大罪でした。

色々、本当に色々やってるんですが、私の軸は全てはめちゃ最高なプロダクトを作るため。 スクラムマスターというのはHOWでしかないな、という感覚になりました。 プロダクトが最高になれるためにやれることはなんでもしていくぞ〜〜まじでもがいていきます!

そして、本当に強く思うのは、「コミュニティマジ最高!!!」ということです。

私は「認定スクラムマスター研修」を受けて何名かの方とSNSで繋がり、「アジャイルコーチとスクラムマスターの集い」でその輪が広げられました。 そして、この輪に救われて自分のプロダクトに活かせることを模索できているのです。ありがたすぎるでしょ〜〜!!!

知っているぞ、喋ったことあるぞ、という人が増えると、カンファレンスにもめちゃくちゃ参加しやすくなります。あの人の話が聞きたい、あの人とお話したいという感情ができます。 できた結果!!RSGTもオンラインですが参加します!!冒頭で書いたScrum Fest Kanagawa 2024もだし!!

アジャイルスクラム方面で発信していきたい」という意思を強めていくので今後色んなイベントに顔をちゃんと出していきたい・・・!! がんばる!どんどんインプットするぞ!!!叶うことならアウトプットもできるといいなっ!!!

NE株式会社、めちゃめちゃめちゃくちゃ、エンジニア募集してます!!

「なんかいいな」って思った方、まずはカジュアル面談からでも良いし、Xで私に連絡でもOKです!小田原にフラっときた時に声かけてもらうでもOKです!!(?)

ne-inc.jp

ウェブアプリケーションエンジニア、マジで募集してます、一緒に働こう〜!!!

切磋琢磨できるような方きてほしい〜!一緒にマジで最高のプロダクト作りしませんか🙏

ne-inc.jp

▲ SRE、マジで募集してます、一緒に働こう〜!!!

弊社のプロダクトは数年前にクラウド化したのですが、まだまだ課題はたくさんあり、越えるべき"楽しいこと"は山積みです!!w

ne-inc.jp

▲ その他の職種も色々募集中〜〜〜!!です!!!

Today's Osusume Books

プロダクトマネージャーのしごと

アジャイルコーチとスクラムマスターの集い」に参加するにあたって、なんか本読みたいなっと思ってその時出ていた本で新しく、積読してあったので読みました。

めちゃくちゃ良かったです。タイトルとしては「プロダクトマネージャー」とあるのですが、プロダクトマネージャーじゃなくても実践できるアクションが散りばめられていました。

印象的なのは「人間とやり取りする上での泥臭さ、絶対あるよね、大事だからやってかなきゃならんのだよ」という様なアクションが多数載っていることです。 具体的なやれることとしてはプロダクトマネージャー目線で書かれていますが、これEMだったり、チームリーダーでも適用できるアクションあると思います。

特に好きなのは「しなやかマインドセットを育む」です。

しなやかマインドセットの人は、失敗や挫折を学習の機会だととらえます。硬直マインドセットの人は、失敗や挫折を本来備わっている価値の悪い面の現れだととらえます。しなやかマインドセットの人は、初めてのスキルや物事を成長の機会として取り組むことができます。硬直マインドセットの人は、初めてのスキルや物事に恐怖を感じます。

(3.2 しなやかマインドセットを育む)

「しなやかマインドセット」という言葉も可愛くて好きなのですが、良いですよね〜これ。

「失敗や挫折を本来備わっている価値の悪い面の現れ」みたいなのは正直よくやっちゃうことだと思っていて、そう思わずにポジティブに捉えられることが重要だよ、みたいな解釈をしました。

スクラムマスターを始めてから、なるべくポジティブでいようと心がけていました。 元々結構ピシャリと物事を言ったり、自由奔放に生きていたのですが、認定スクラムマスター研修でも「ポジティブ」でいることが大切だよ、と学んだし、チームの雰囲気をよくするためにはまずポジティブな風を流し込む人が必要だな、と肌感でも感じていました。

その時に割と自分は「ポジティブ変換」をめちゃくちゃやっており、その結果「しなやかマインドセット」のような感情が自然と現れることが増えてきました。

失敗したタイミングで1人ふりかえりだったり、一緒にふりかえってみたり、チームでふりかえってみたり。そこから学んで成長してもらうところを推進していきたいですよね。

あとは、もう1つめちゃくちゃ好きなところがあって、それは第6章の「ユーザーに話しかける」です。

「上から読む計量カップ」の話が載っており*2、その続きとして以下が書かれています。

このストーリーはあなたの仕事をユーザーにさせようと質問することの落とし穴を示しています。ユーザーに機能のリストを挙げてもらえば、チームに戻って「これは良いアイデアだ!ユーザーから特に要望があったんだ!」と言って自信を持つかもしれません。でも、ユーザーには、自分たちの目的やニーズと、それに対応する会社独自の機会を結び付ける必要はありません。それはユーザーではなく、あなたの仕事です。

(6.2 そう、ユーザーと話す方法を学ばなければいかない)

これは「実際にユーザーを見に行かないと真の課題が見つからないよ」という価値観をより強くしました。 また、「真の課題」を見つけるためには自然にユーザーが話しているところをこちらからキャッチアップする必要がありそうです。

最初は自分向けじゃないかな、と思いましたが、全然そんなことなく!!いや〜面白い本でした!! そんなに厚くないのでサクッと読めそうです🤩

プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける

この本は、少なくとも私の組織にいるエンジニアは読んでおいた方がいいな〜と思う本でした。

開発者は動くコードをたくさん書くと評価されます。デザイナーはインタラクションの絶妙な調整やピクセル単位の完璧なデザインによって評価されます。プロダクトマネージャーは長い仕様書を書いたり、アジャイル用語でいうバックログをたくさん作ったりすることで評価されます。チームはリリースした機能が多いほど評価されます。このような考え方が広まっていますが、これは有害です。

(1章 価値交換システム)

めちゃくちゃその通りだなと思った...。「リリースした機能が多いから評価!」だったり、その逆の「リリースした機能がスコープ削れてちっさくできたから評価!」となっている時があったら危険信号だな、と思うようになりました。 その発言、本当にユーザーのこと考えているか?ただ目の前のアウトプットだけ考えてアウトカムまで考えられてないんじゃないか?という問いかけを自分、チーム、組織にしていきたいな、と言う気持ちになりました。

また、「プロダクト主導組織」の話も印象的でした。自分たちはできてねーな、という観点で...。

  • プロダクト主導組織
    • ビジネスアウトカムを軸に最適化し、プロダクト戦略を自分たちの目標に合わせて調整する
    • 組織としてこうあるべき
  • セールス主導組織
    • プロダクト戦略は契約によって決まる
    • そのせいかどんどん機能が膨れ上がる
    • 最初は寧ろセールス主導、そこから変化していく必要がある
  • ビジョナリー主導組織
  • テクノロジー主導組織
    • 最新のクールなテクノロジーを軸にして進む
    • テクノロジーも必要だが、プロダクトが先行していなきゃならない

自分の組織は「セールス主導組織」な面が大きいな〜と感じました。 ここから「プロダクト主導組織」に持っていきたいな、という思いが強くなりました。

...と、いった様に、「自分の組織まだまだ伸び代あるな!(ポジティブ変換)」と思う部分が多く、私ができるところから進めていくぜっという前向きな気持ちになりました(•̀ᴗ•́)و ̑̑ あと、7章の「優れたプロダクトマネージャー」の章には実際の「こう動いたらうまくいったんだよ」な話が載っており、自分の中で「優れているとはどういうことなのか」が具体例から想像していけるので、この章もめちゃくちゃ好きです!!

そして、この本のいいところは、なんといっても1章1章が短くサクサク読める点ですね〜〜10分とかでサクッと読めそうな章が多いです。 毎日ちょっとずつ読んでもいいし、ガーッと1日で読んでもいいし・・・なんにしてもおすすめでっす!


2023年のアドカレ、7つの大罪たち

回遊してってね🐟💨

asumikam.com

asumikam.com

asumikam.com

asumikam.com

asumikam.com

asumikam.com

asumikam.com

*1:強く主張していきたい。0時越えても寝るまで概念的な意味で日付は変わらない。

*2:計量カップに欲しい機能を求めた時は筋が良さそうな特徴をスラスラ言うが実際に使わせてみるとメモリを横から読もうとしてかがんでいたのを発見した、と言う話