みなさんこんにちは！ふるまいチーム、アニメーター改めビヘイビアデザイナーの中里です。 社内外で"アニメーター"と呼称されていた我々ですが、採用活動強化などを機にロールが分かりやすくなるよう呼称を"ビヘイビアデザイナー"に変更しました。多少分かりやすくなったでしょうか？社内での浸透率は体感50％くらいです。
本題と逸れてすみません、今日は6月に受講した認定スクラムマスター(CSM)研修でなんとスクラムマスター(SM)だけではなくデベロッパー(Dev)のこともよく理解してしまったので、記事にしたいと思います。レッツゴー
なぜスクラムマスター研修を受けたのか
わたしはDevですが、エンジニアではないためこれまで社内でよく扱われていた認定スクラムデベロッパー(CSD)研修には参加できていませんでした。もう10年近くGROOVE Xにいるのにコードが書けないからです。びっくりしますよね。人間興味がないとこうなるのです。 そんなわたしでもチームの生産性向上には興味があるというか、仕事をいっぱいして成果をいっぱい出したい人間なのでスクラムを最大限活用したくて、ピィピィ騒いでいたら研修に行かせていただける事になりました。ありがてぇありがてぇ
何を得たか
CSM研修は、SM視点でのスクラム開発とその中でのSMのあり方について学習するのですが、スクラム開発自体の全体像を正しく詳細にしっかりと学べるので、その中で我々Devやついでにプロダクトオーナー(PO)のあるべき姿も知ることができました。Devとはこういう責任があってこういうがんばり方をするんや！というのがよく見えたのが自分にとってうれしい収穫でした。もちろんSMのこともよく知ることができたので、たまにSMの目をポッケから取り出してチームのスクラム開発を覗いてみたりしています。
なるほどと思ったこと
Devのがんばりどころを俯瞰できた
スクラムガイド2020に加えられたProductGoalと、それに付随してプロダクト開発に必要なPoductVision, ProductStrategiesなどの概念を交えてPOとDevのそれぞれの関与度と関わり方を学びました。研修で分かりやすい図説をしていただいたときのメモを元に図を作りました。POとDevそれぞれの一般的な関わり度合いを■で表しています。
- Product Vision: 「なぜ」作るのか（究極のゴール）
- Product Goal: 「何を」達成するか（長期的な確約）
- Product Strategies: 「どうやって」市場で勝つか（方針）
- Sprint Goal: このスプリントで「何の価値」を生むか（短期的な確約）
- Sprint Backlog: ゴール達成のための「タスク」（計画）
- Product Increment: 完成した「価値」（結果）
ProductGoalを決めるにはマーケット条件(対象、価値、指標)が明確になっていることが必要です。 POが顧客、競合他社、ステークホルダー、予算、市場トレンドなど外向きの視点に責任を持っているのに対し、Devは技術的負債、アーキテクチャ、品質、開発速度など内向きの視点に責任を持ちます。研修では、この図で言うProduct Strategiesの左側(POの領域)にDevが踏み込んでいけるなら頑張ってもいいが、そこを目指すよりInvestmentを下げる方がやりやすいしDevには合っているでしょう、という説明でした。なるほど！？
「Investmentを下げる」について、Devのがんばり方を考え直した
スクラムを採用している目的は、ただ速く作ることではなくて、「投資対効果(ROI)の最大化」と「リスク管理」です。そして、ここで出てくるinvestment(投資)とは、Devへの投資、つまりDevの使う時間とか労力にあたります。
絶対に成功が約束されているプロダクトなんてほとんどありませんよね。めちゃくちゃ時間をかけて作り込んだものをリリースして失敗した時と、1スプリントだけ最低限の機能だけの開発でリリースして失敗したとき、同じ失敗でも損失が小さい後者の方がビジネス的には助かるわけですね。
作り込んだからって成功(確率はあがるかもしれないが)確実になるわけじゃないし、どのみちリリースしてみないとユーザーの反応はわからんという場合は、とにかくミニマムチャレンジで、かすり傷なら治すのも簡単ということ！
「この仮説を検証するために、いちばんサボれる( = 低コストな)実現方法は？」っていう考えを最初に持ってくるのを忘れないことが必要かなと最近は考えています。
POとコンフリクトするときは「技術的戦略」をメイン武器にしよう
POとDevとのコンフリクト(対話)はプロダクトの質を上げるために必要不可欠です。
ただし今回学んだのは、DevがProduct GoalやProductStrategiesに関与したい場合は、TechnicalStrategy(技術的戦略)として提案しないと分が悪いよ、ということ。
前述した「マーケット条件」に対する視点をDevは持ち合わせていないことがほとんどなのでないものには頼らず、Dev諸兄の得意分野である技術観点と、低いInvestmentで高い価値を生み出せまっせ！！の二段構えで戦うのが良いでしょう。（技術に乏しいビヘイビアデザイナーはクリエイティブ観点から小石を投げること）
自分はこのように理解しました
Devの本分は技術的な専門性を武器にただの制作物(output)ではなくて価値(Outcome)を最大化することで、同時にInvestmentを少なくしてリスクを最小限に抑えることを考える。楽していいものを作って自慢しよう。
おわりに
SM研修に行ってまさかのDev記事を書くという今回のブログはいかがでしたでしょうか。
こんなふうにスクラム開発についていろいろ考えたり話し合ったり、騒げば研修に行かせてくれるGROOVE Xではいつもいつでも採用を行っています。上手くいくなんて保証はどこにもないけど。気になる方はぜひお気軽にお問合せください！
