「スクラムマスターは真のリーダーである」によって生じそうな誤解
はじめに
スクラムガイドが更新されました。 変更について色々と考察・議論を見かけますが、個人としては「スクラムマスターは真のリーダーである」が引っかかっています。
スクラムマスターとサーバントリーダーシップ
自分の理解ではスクラムマスターは役職では無く役割でした。プロダクトオーナーも役割、開発チームも役割であって、上下関係のない対等の3者が存在することでパワーバランスが保たれ、プロダクトに向かう一致団結する力が生まれていたのだと思っています。
「スクラムマスターとしてサーバントリーダーシップを発揮して欲しい」というこれまでの説明は納得感がありました。 自分がスクラムマスターを人にお願いする時にも「リーダーをお願いしているわけじゃ無いよ」「チームをまとめて、サポートしてあげて」と説明するようにしていました。
多くの組織にとってリーダーは肩書き・役職
- スクラムマスターは、スクラムガイドで定義されたスクラムを確立させることの結果に責任を持つ。
- スクラムマスターは、スクラムチームと組織において、スクラムの理論とプラティクスを全員に理解してもらえるよう支援することで、その責任を果たす。
- スクラムマスターは、スクラムチームの有効性に責任を持つ。
- スクラムマスターは、スクラムチームがスクラムフレームワーク内でプラクティスを改善できるようにすることで、その責任を果たす。
- スクラムマスターは、スクラムチームと、より大きな組織に奉仕する真のリーダーである。
- スクラムマスターは、さまざまな形でスクラムチームを支援する。
元の文章にきちんとあたると「チーム・上位組織に奉仕する」とサーバントリーダーシップの流れを汲む説明が記載されているのですが、リーダーと呼称してしまうことで違う問題を引き起こしてしまう気がしてなりません。
日本の組織の多くは管理職になる前のステップに「リーダー」という肩書き・役職を置いていることが多いと思います。 リーダーが一人選ばれ、メンバーがそれに従い、プロジェクトを進めるという構造です。 リーダーは出世街道に乗っている人だったり、次の管理職候補でだったり、チームを技術的にも精神的にも支えている人です。 従来からあるリーダーの肩書きを付け替えてスクラムマスターに仕立て上げることも少なくないようです。
「スクラムマスターは真のリーダーである」という短いメッセージと、「リーダーはプロジェクトをまとめて引っ張らなければならない」という従来の発想が結びつくことで、リーダーの「導いてあげないといけない」いう誤った責任感、メンバーの「リーダーに任せて後をついていけば良い」という誤った認識を増長してしまうのではないかというのが私の懸念です。 コミットメントに責任を感じないスクラムマスターは問題ですが、とはいえ真のリーダーという言葉を引っ張り出してくることで意識してもらうのは短絡的かなと感じました。
おわりに
ガイドなのに解釈について皆が議論しているのが面白いなとブログ・Twitter・勉強会の様子を眺めていて感じました。 ガイドというよりも教典に近い位置付けをしている人が多いのだと思っています。
Agile Japan 2020でRettyの開発文化の変革の話をしてきました #agilejapan
はじめに
Agile Japan 2020の公募に応募したのが確か2020年の初春。5月の物理開催がキャンセルされ、11月のオンライン開催となり、ついに参加が叶いました。
応募した頃は昨年のAdvent Calendarで取り上げたLeSSの導入事例をもう少し肉付けして話そうかと思っていました。
- Rettyの開発組織をぶっ壊して、LeSSを導入した話をPO視点で書きました｜のぐちひろき｜note
- 「1プロダクトをみんなで作る！」Rettyでの大規模スクラム(LeSS)導入記 - Retty Tech Blog
しかし採択の結果20分枠となり、アジャイルジャパンの参加者層が「アジャイル開発これから」・「アジャイル開発始めてまもなく」の方が多そうなこともあり方針転換をしました。結果として「アジャイル」「スクラム」という言葉を使わず、なぜRettyが開発文化を変えようと取り組んだのかの核が伝わるように話を作って見ました。他の方の発表を見て「もう少し踏み込んだ話をしてもよかったかな」とも思いましたが、「アジャイルをやる」のではなく「アジャイルにやる」ことのアプローチが伝わっていれば幸いです。
発表の時に触れるのを忘れていましたが、今年のAgile Japanのテーマは「変える勇気、変えない勇気」でした。 20分の発表では取り組んだ結果簡単にできたように伝わる面もありますが、Rettyも1回で成功したわけではなく過去の失敗の下積みがあってのことだと考えています。 自分たちが何を大事にしていて変えてはいけないものが何か、そのために変えられることは何か。言葉にすると簡単ですがこれを継続することがアジャイルにやるの根幹にあるのだと思います。改めていいテーマでしたね。
Q&A・反応など
発表時にいただいたQ&A
Q1: 開発文化を正す戻すときに変えるもの変えないもので、特にポイントがありましたら教えていただけないでしょうか
A1: 会社・組織が大事にしてきたことには耳を傾けた方が良いと思います。 自分の中の正解を押し付けるのではなく、会社・組織にあった正解を一緒に探していくんだという姿勢が相手に伝わるのがポイントだと思います。
Q2: 組織、人の拡大に伴って、一番苦労されたことはなんでしょうか？どのように解決されていったのでしょうか？
A2: 表層的な事項が誤って伝わることでした。例えば「決定者が決めたことを開発がひたらすらこなす社内受託になってしまうんじゃないか」とか。 移行した1ヶ月は説明会・チームごとに説明・個別に説明などとにかく時間をとって誤解を解き、基本的な考え方を説明して回ることに専念しました。
Q3: サービス維持とGotoEatなどの突発案件とのバランス、優先度の考え方はどのようにしていらっしゃいますか？
A3: 四半期ごとに企画部門と開発部門である程度の握りをしています、例えば「サービス維持に20%の工数を使う」とか。 スクラムのストーリーポイントをざっくり分類し、割合がわかるようにしていています。 所定の割合に達しなかった/超過してしまった場合も、割合を戻すことに注力するのではなく、状況を整理して話し、目標を調整することに重きを置いています。
Twitterでいただいたコメント
「開発文化を"正す"、または"戻す"」はグッとくる。人が増えると逆のことを始めてしまうのもあるあるなんだけど、やりがち。 #agilejapan
— y-moritake (@moriyasu0410) 2020年11月17日
ありがとうございました！！
— J.K@バンザイアーティスト (@project_J_K) 2020年11月17日
社内からも「もう一回みたい！」というコメントも！ https://t.co/HtQChUcqTC
Agile Japan 2020の感想
実は初参加だったのですが、Regional Scrum Gathering TokyoやScrum Fest XXXとは違った雰囲気でした。 それはコンサルタント・アジャイルコーチ、製造業・保険・インフラ、ツール販売、SIerなど固め・大きめの企業の参加者が多く、その事例発表の割合が多いことが影響しているかもしれません。connpassで見つかるアジャイル・スクラムの勉強会はWeb企業・自社事業でやっている人の参加が多いと感じていますが、それ以外にもこんなにもアジャイルを取り入れようとしている人が多いことに驚きました。
また発表スタイルとして事業会社の担当者+コンサルタント/アジャイルコーチの組み合わせが多いなと感じました。 発表構成が整えやすいから増えたのかと思われますが、事業会社の担当者の言葉で話してもらった方が臨場感が増し、聴く側も自分ごとに捉えやすいと個人的に感じます。 これからの1年間、自分の現場で奮闘し、来年のAgile Japanで情熱のこもった話ができる登壇者が一人でも増えることを願っています。 その実現のため、この後もAgile Japanはサテライト開催を計画しているようですが、登壇者の一人として、私に協力できることがあればお気軽にお声がけいただければ幸いです。
スクラムフェス札幌 2020で「もりあがるスプリントレビューをしよう」という話をしてきました #scrumsapporo
はじめに
スクラムフェス札幌2020で登壇の機会をいただき話してきました。 Regional Scrum Gathering Tokyo 2020で相談したスプリントレビューのやり方について改善を試行錯誤してみたまとめとなっています。
他所のチームはどんなスプリントレビューをしているのだろうと疑問に思ったので会期中にGoogle Formでアンケートも取ってみました。
感想・反応など
Discord(参加者限定)でいただいた質問・コメント(抜粋)
はずかしながらレティだと思ってました。。
よくある間違いですが「れってぃ」です。よろしくお願いします！
ステークホルダーどころかPO的な人も来ない世界にいる。
見たことあります。不適切なプロダクトオーナー(適切な人が他にいる御用聞き、Fake Product Owner)ほどレビューに興味ないですよね。何をやるか決めるだけが仕事と思っているような。
MIROやMURALで付箋貼っといてーの方が、今ならいいのかな
「レビューのコメントや質問をチャットに流している」に対してだと思うのですが、これも使い慣れているならありでしょうね。 ただ最初の1枚目を貼る人の心理ハードルが高そう。
司会と賑やかし、どっちが重要なんだろう
個人的には「賑やかし」の方が効果が高い印象持ってます。
DONEになったらチェックか。チェックしたらDONEにはしないのかな。
チェックしたらDONEですね。「DONEになったと思ったらプロダクトオーナーに確認してもらいDONEとする」が正しいと思います。
アンケートより
スプリントレビューに感じる課題はなんですか?
そこから気づきが生まれることが少ない
はじめに計画ありきで、計画を分割してスプリントに落とし込んでいるとこうなりやすい気がします。 スプリントゴールに「なんでこれをやるんだっけ」の答えを含めておくと良いかと思います。
運用チームなので完成品のようなものが無い場合が多く、レビューの対象の選定に困る。
あー、わかります。チームの成果アピールが課題であれば551メソッドを試してみてもいいかもしれません。そうでないなら短くやったことと、それによる効果(KPIとかメトリクス見るとか?)を確認するぐらいでもいいのかなと思っています。
ステークホルダーがたくさんいるが、予定が急遽埋まって来れなくなることもあるため、週に複数回実施したいと思っている。
同じ内容で何回かデモするのはやったことがあります。全員集まると大変ですけど代表者でやればそこまで手間ではないですしね。 あとは初回を録画して、それをみてもらうという手もあると思います。
チームがドキュメントを読み上げるだけで、デモなどを通して顧客の感想、要望を収集できていない
プロダウトオーナーにデモしてもらうと、チームと違った視点で成果物をアピールしてくれると思います。
他の人に相談したいスプリントレビューの悩みはありますか?
スプリントレビューの場で、ＳＭは何をする人なのか、わかっていない
司会やファシリテーションすることが多いですね。個人的にはレビューでフィードバックが十分に収集できないことが続いたらそれを直す責務を持っているのだと思っています。
LeSS的な複数チームのレビューでうまくステークホルダーをさばきながら十分な時間をとる方法
指摘をメモしておき、「関係メンバーを集めて別途議論の機会を設けましょう」で良い気がします。
他の人に教えたいスプリントレビューのコツがあれば教えてください。
運用チームという特性上、ＰＯとＤＥＶ（インフラ）の1 on 1形式で１週間の納品の儀式として行う事にしたが。、POのマネジメント能力が飛躍的に向上し、コミュニケーションが劇的に改善した。
レビューを始めるとプロダクトオーナーの意識が上がることはありますよね。できたら確認しないといけないとか、次に何をするのか前もって考えておかないといけないとか、なぜそれをやるのか聞かれたらきちんと答えられないといけないとか。改めて文字にすると当たり前のことですが、なあなあでやっていた仕事の進め方が正されるような感じ。
自分のソリューションを自慢する
何回かに一回、レビューそのものの満足度を参加者にアンケート形式で聞くようになってから手応えあるレビュー増え始めたのでたまにアンケートとってみるといいかもです
これは良さそうですね。うちでも取り入れてみます。
言及いただいたブログ
時間がなくて発表に入れられなかったこと
RSGT2020でいただいたアイデアで紹介できないものが多数ありました。
- ユーザーを真似て演劇形式でデモする
- ステークホルダー / プロダクトオーナーにデモしてもらう
- 実際に触ってもらう/遊んでもらう (ゲーム開発の事例)
- スプリントレビューのテーマを決める
- プロダクトオーナーに語ってもらう。
スプリントレビューについてのアンケート結果
今日時点のアンケートを記事末尾に貼っておきます。
2020年9〜10月に社内で共有したアジャイル開発関連の記事
社内でアジャイル開発を議論するSlackチャンネル #tech_agile に見かけた良記事をよく放流しているのですが、社外向けでも需要があるかもなと思い試しに公開してみます。有用そうだったらシリーズ化するかも。
ノウハウ・知見
リモートワークのノウハウ
Agileリーダーシップ研修の感想
コードレビューを通じたメンバー育成
リリースとはユーザー(とかステークホルダー)に使ってもらって、フィードバックをもらうことだよねという話
Silver Bullet Clubによるチーム開発の振る舞いパターン集
中村洋さんのコーチメモ。
分量も多くたまに見返すと新たな発見があるかも。
振り返りのアンチパターン
ふりかえり手法のまとめ
他社事例
atama plus
LeSSに移行したatama plusの開発体制図
atama plusはLeSS見学レポートもありました。
norihiko-saito-1219.hatenablog.com
カオナビ
自社に似ている雰囲気を感じる
SmartHR
LeSS事例、複数PdMの同期はうちも学ぶところがあるかも
勉強会・カンファレンス
ふりかえりam KPT as ART
スクラムフェス大阪の基調講演書き起こし
その他
Why communication is important in software development 🙂 pic.twitter.com/1I2v9cPMKT
— Ricardo Ferreira (@riferrei) 2020年9月18日
Re: SmartHR 社内でスクラム勉強会を開催した話
練習問題が面白そうだったので自分のブログに回答を載せてみます。
第二回：経験主義と透明性・検査・適応について
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)まで触れるべき。そうでないとデリバリーが他依存になってしまい、安定したデリバリーができなくなる。
「Clean Agile 基本に立ち戻れ」を読んで考えたこと
- 作者:Robert C.Martin
- 発売日: 2020/10/03
- メディア: 単行本
Clean Agileを読みました。 きちんとした書評は会社のTech Blogで公開予定のため、ここではボブおじさんの発言に対して個人的に感じたこと・考えたことを書き留めておきます。
大規模アジャイルについて
書籍の中で一貫して否定されていました😭
書籍の中で「そんな問題は存在しないと思う」とされていました、そうなのかな🤔
今の会社で大規模スクラム(LeSS : Large Scale Scrum)を推進していますが、「これは本当に必要なものなのか、疑う気持ちはわからんでも無いな」という気持ちもあります。 「すでに開発者がたくさんいるから大規模アジャイルを導入しなければならないんだ」となっているような感覚です。 自分で事業スピードと開発者数をコントロールできるのであればやりますかと言われると・・・やらないかもしれません。 チームのスケーリングの話は昨年末にCopeの話を聞いたときも考えさせられました。
ボブおじさんは小さなスクラムチームをたくさん作れば良いんだと主張していたように思えたのですが、それはそれで良いとも思えません。 またBasecampが少人数チームで2年かけてHEYを作ったという話を聞くと、「人数を増やしてリリースまで短くすることはできなかったのか」とも思ってしまいます。
「皆が一丸となり、偉大なサービスを、再現性を持って作れる」これがポストアジャイルなのかもしれません。
こちらはインドネシア･バリ島で撮影されたミナミゴンズイの稚魚の群れです。塊となって捕食者から身を守りつつも、群れ全体で回転しながら海底のエサを食べています。これなら、どんな魚も逃げてしまいそうですね。pic.twitter.com/15sWjDtC5I
— エピネシス (@epinesis) 2020年10月10日
アジャイルはソフトウェア開発のもの
スクラムガイドはソフトウェア開発のためのものという前置きを外していますが、スクラムよりも広義を指すアジャイルがソフトウェア開発だけのものというのはうーんと思います。 アジャイルHRや開発以外のスクラム導入事例も少なからずあるのでこの先もっと広まるのでは無いかなと考えています。
資格は意味が無い
自分もアジャイル開発に取り組むようになって4年半ほど経ちましたが、CSM/CSPOなどの資格試験は取らずにきてしまいました。 一線級のコーチの言葉で学べるメリットは有用だよなと思うのですが、資格試験そのものに意味がないことは同意です。
RSGTに行くとみんな資格好きだなーと思います(参加賞に取得資格を示すシールが貼れるようになっているんです)
コーチはいらない
「コーチいらない」といいながら「自分自身の振る舞いを確認するのにコーチは有用」とも言っていて書籍の中で主張がぶれています。
「コーチいらない」といいながら、後になってコーチングについて意見の異なる友人を肯定する一節が入り、どっちのスタンスなんだろうと混乱しましたが、コーチはいらないがボブおじさんの基本スタンスのようです。(補足いただいて訂正しました)
始めたばかりのコーチ(=トレーナー)はずっとは必要ないけど、定期的にアジャイルから外れていないかを確認するための壁打ち相手は必要なのではないかと思います。
アジャイルソフトウェア開発宣言は見直さない
「陳腐化するはずがないことを皆で合意して署名したのだから見直す必要がない」というのは腹落ちしました。
技術が重要
RSGTもそうですが、「フワッとした」思想を話すプロポーザルが増えているなと感じていたので、アジャイルな開発を支える技術プラクティスへの揺り戻しが来る気がしていますし、自分が外部発表をする時にもそのような割合を増やして行こうかなと思っていました。
この間1回目が開催されたAgile Tech EXPOはドンピシャですね。
関連リンク
Shape Up - Basecampによるプロダクト開発ガイド
はじめに
Basecamp社が公開しているプロダクト開発ガイド「Shape Up」の存在を知り読んでみました。 Basecamp社はプロジェクト管理SaaS Basecampの開発元で、以前は37 Signalsという社名でした。 Ruby on Railsの作者 David Heinemeier Hansson氏がCTOを務め、最近だと新機軸のメールサービス Hey を立ち上げています。
特徴
Basecamp曰く「アジャイル開発でもスクラム開発でもない」、Basecamp社で15年近く試行錯誤して改善してきたやり方だそうです。
「6週間の開発サイクル」と「2週間のクールダウン期間」を繰り返して開発を進めます。 サイクルの途中で中断・見直しはせず、期間内にリリースに至らなかった場合でも期間延長はされません。 6週間は「何か意味のあるものを最初から最後まで作り上げるのに十分な長さ」であり、「誰もが最初から期限を感じることができるほど短い」、経験から導き出した開発期間とのことです。
開発チームが着手する前に少人数のシニアグループが事前に検討を済ませておきます。 ただしこの事前検討(Shaping)は適切な抽象度までで留めるよう留意します。 「チームが何をすべきかを知っているほど具体的である」一方、「詳細を自分たちで考え出す余地がある」程度を目指します。
進め方
- Shaping
- Betting
- Building
Shaping
開発する項目を考えますが、「適切な開発スコープを切り、事前に決めすぎないようにバランスをとる」ことに留意する必要があります。
「開発前に決めすぎない」とは下記のような事例を指します。
- ワイヤフレームを描いてしまうと具体的すぎます。開発着手後にデザイナーが創造性を発揮する余地がありません。
- 言葉による説明は抽象的すぎます。開発着手後にチームが要件を満たす中でトレードオフを見つけるのに十分な情報を与える必要があります。
ガイドではプロジェクト管理ツールにカレンダーを追加しようとした例が挙げられています。 通常カレンダーには月・週・日のビュー切り替え、予定の移動などたくさんの機能が求められていますが、6週間内でリリースするには機能を絞り込む必要があります。 そこで「月表示のカレンダーにイベントをドットで表し、クリックすると詳細が見える」ところまでに機能を限定したそうです。 その際のShapingでのデザインが下記です。
これが開発完了時にはこうなりました。見比べると当初のデザインは詳細が省略されているものの必要な要素は満たしており、何がスコープの範囲外になるのかが明確になっていたことがわかるかと思います。
Shapingはインターフェース・技術的な実現性両方を考える必要があり、ジェネラリストが行うか、デザイナーが主導し他のメンバーと協力して進める必要があります。 インターフェース検討時にワイヤーフレームは具体的すぎるため、インターフェースを構成する主要なコンポーネント・関係を元に議論します。
- Places : 画面・ダイアログ・ポップアップなど、ナビゲートできるもの。
- Affordances : ボタン・入力欄などユーザーが操作できるもの。
- Connections : ユーザー遷移
Shapingのアウトプットは開発スコープを説明する「Pitch」です。 Pitchは下記から構成されます。
- 問題点 - 生のアイデア、ユースケース、またはこの作業に取り組む動機となる何か
- Appetite(食欲) - どのくらいの時間を費やしたいのか、そしてそれがどのように解決策を制約するのか
- ソリューション - すぐ理解できる形で提示されたコアな要素
- リスク
- スコープ外の項目
Pitchはステークホルダーが時間のあるときに読めるよう、課題管理システムのIssueにまとめているなどして置いておくそうです。
各Pitchに対しては以下の2種類に分ける程度の見積もりしかしません。Shape Upの用語では"Appetite(食欲)"と呼びます。
- Small Batch : 1人のデザイナーと1〜2名のプログラマーが1〜2週間で実装できるサイズ。
- Big Batch : チーム全員で6週間かかるサイズ。
Betting
次の6週間で取り組むPitchの候補は"Betting Table(賭け)"の場に持ち込まれ議論されます。 Betting Tableはクールダウン期間に行われる会議で、CEO・CTO・シニアプログラマー・プロダクトストラテジストが参加します。 全員が事前にPitchを読み込んだり、関係者と話して勉強してきているため長くかからず、1〜2時間程度で終わるそうです。
計画ではなく期待値を決める賭けの場であり、6週間後に何か意味のあるものが完成することを目指します。 失敗しても高々6週間分のリソースが失われる程度に抑えるリスクヘッジの仕組みでもあります。
チームは「 デザイナー1名・プログラマー1 or 2名・QA担当者 (サイクルの後半で統合テストを行う)」で構成されます。 6週間の間、割り込みがないように留意します。
バグが見つかった場合、下記のいずれかで対処します。
- 2週間のクールダウン期間を使う
- Betting Tableにバグ修正を持っていく
- バグ対処だけを行う日を決めてそこで対応する
Building
早期にPitchをタスク分解してしまうと全体像を見失ってしまいます。 これはタスクが割り当てられてしまうと、互いの作業の関係性に注意が向かず、判断する責任を感じなくなってしまうためです。
そこでチームは手を動かしながら適切なスコープ(単体で価値が提供できる切れ目)を見つけ、開発タスクを徐々に分解していきます。
スコープが正しいことを示すサインは下記の通りです。
- プロジェクトの全体を見渡せるような気がして、心配するような重要なことが細部に隠れていない。
- スコープが適切な言葉を与え、プロジェクトについての会話がスムーズである。
- 新しいタスクが出てきたとき、どこに配置すればいいのかがわかる
進捗は「できたこと」「できていないこと」ではなく、「わからないこと」「解決したこと」にフォーカスします。 プロジェクトを丘にたとえ、スコープごとに今現在どこにいるかを示すことで進捗を見える化します。
6週間で終わらなかった開発を継続する場合、下記の両方を満たす必要があります。
- 価値が十分に議論され重要である
- 丘を登り終え、下り途中である
リリースすると顧客から負のフィードバックをもらうこともありますが、しばらく待って注意深く観察します。 安易に対応したり、過去バージョンに戻したりせず、機能修正の対象としていた顧客の反応をきちんと見ましょう。 またフィードバックはすぐに対応せず、次の賭けとしてBetsにかけます。
HEYの開発事例
すべてShape Upのプロセスに従って進めた。1年間のシニアチームによるR&Dと1年間の製品開発、リリース前の整理に2サイクルを費やしたとのこと。
- 1年間のR&Dモード(Jason（CEO）、David（CTO）、Jonas（シニアデザイナー）の3人のチーム)
- 1年間の開発期間
- 2サイクルのクリーンアップ
感想
ポジティブな面
- スクラムが明示的に規定していないノウハウを埋めてくれそう。
- 着手前の設計・技術調査
- 事前に設計しすぎないとはどういうことかという事例。
ネガティブな面
- Basecampのような思想(少数の価値ある機能に注力し磨いていく)を前提にしていないと合わなそう。
- 運用するのが難しそう。
- 方向転換できるまでに8週間かかる。スタートアップでは長すぎ、ビジネスモデルを確立した企業では享受できるメリット(機能を絞り込んで開発し磨く)が小さいのでは?
- 原文を読むとわかるがBetting以降の章はルールでなく運用ノウハウ・コツが多い。
小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則
- 作者:ジェイソン・フリード,デイヴィッド・ハイネマイヤー・ハンソン
- 発売日: 2012/01/11
- メディア: 単行本
- 作者:ジェイソン フリード,デイヴィッド ハイネマイヤー ハンソン
- 発売日: 2014/04/01
- メディア: Kindle版
