ゆとりを計画しておく-物流業界の"Flying Spares"という考え方
はじめに
Blog: Allow for Uncertainty with Built-In Slack – The Flying Spare Example | Innolutionというブログ記事で、物流業界における「計画されたゆとりで不確実性に備える」例が紹介されていました。とても興味深い内容なので概要を紹介します。
Flying Sparesとは?
空っぽ、または積載量に空きがある飛行機を指した用語だそうです。 別の呼び方として"hot spares"とも呼びます。 ソフトウェア開発でいうと「ホットスタンバイ」のサーバが近い気がします。
他の飛行機の積み残しを搭載する、または故障時の代替として使用することを想定して「常に」用意するだそうです。 航空機を使った物流では下記の「不確実性」が日常的に発生しうるそうです。
- 顧客が持ち込んだ荷物が事前の連絡よりも大きかった
- 航空機機材の故障
- 天候不順
FedEx 1311便
FedEx 1311便は"Flying Spares"用の定期便らしくデンバーからFedExの拠点があるメンフィスまで定期運行しています。 空っぽの航空機を飛ばすにもパイロットや従業員が必要で、さらにこの便はデンバーからメンフィスまで直線距離(2時間15分)で向かうのではなく、ニューメキシコを経由して3時間30分のフライトをします。 1回の飛行にかかる費用は$30k(300万弱)とのことです。
それでもアメリカの南西部の空港で起きた不確実な事態に備えるため今日も飛んでいます。
おわりに
プロジェクト管理やリソース配分を考える際、つい不確実性を過小評価し、有事の際は頑張り・努力で対応して、結果スケジュールを遅らせてしまいがちです。 航空機を使った物流ビジネスほど大掛かりな準備が必要な分野でできている「計画されたゆとり」が、ソフトウェア開発で実現できないはずがないと考えました。
LOVOT体験会に行ってきました: 最高の特典や催しは事業や顧客について理解を深められる機会である。
はじめに
1/11(金)と1/14(月)の2回、GROOVE X社が開発したLOVOTの体験会に行ってきました。金曜日は同じ会社の友人と、月曜日は子供を連れ家族とです。
「体験会の様子をぜひSNSで拡散してください」とお願いがあったのですが、このブログのテーマは「アジャイル開発、組織変革、ファシリテーションについて学んだことの記録」としているので「ちょっと違うかな」と思っていたのですが、最近読んだネットフリックスの組織本にあった文章をふと思い出しました。
ネットフリックスが考える「従業員が仕事に満足感を得る時」はどんな時か
- 作者: パティ・マッコード,櫻井祐子
- 出版社/メーカー: 光文社
- 発売日: 2018/08/17
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (2件) を見る
この本はカルチャーデックと呼ばれるNETFLIXの企業文化や社員の行動規範を定めたガイドをより詳しく説明したものです。
その中で「従業員が仕事に満足感を得る時」について、こんな説明があります。
仕事に対する真のゆるぎない満足感は、優れた同僚たちと真剣に問題解決に取り組む時や、 懸命に生み出した製品・サービスを顧客が気に入ってくれた時にこそ得られる。
従業員が働きたくなるように、給与・福利厚生・ピカピカしたオフィス・ビールサーバーなどいろいろな用意をする企業が多いですが、ネットフリックスはこれを「従業員を子供扱いしている」と一刀両断しています。
最高の特典や催しは事業や顧客について理解を深められる機会である。
ネットフリックスの例では映画事業について学ぶ機会をたくさん設けたそうです。 従業員全員をサンダンス映画祭へ連れて行ったり、著名な映画監督・映写技師・映画編集者の話を聞きにロサンゼルスへしょっちゅういったと紹介されています。
LOVOT体験会の様子
体験会のアンケート項目から推測するに、LOVOTの購入を検討している近い将来のお客様から、LOVOTに興味を持っている少し将来のお客様、ロボットや技術に興味があるエンジニアなど様々な人が訪れているようです。
そういった人と社員が直接コミュニケーションが取れる機会を与えるのはまさに「事業や顧客について理解を深められる機会」だなと思いました。
またLOVOTを構成する技術を集めたコーナーからは「優れた同僚たちと真剣に問題解決に取り組む」ことに真摯に向き合っていることが伝わります。
技術展示会やオープンハウスを年一で開催し、社員が説明に立つことはよくあると思いますが、それとは違った印象を受けました。残念ながら理由は私もうまく言葉にできません。少人数制で説明員の方とたくさんお話しする機会があったからなのか。技術・アイデアの出し惜しみをしてないように感じたからか。これから育てていく、いわばβ版をぶつけてきているからなのか。そもそもGROOVE Xもどう広めていくか悩みを素直にぶつけているように感じたからか‥。
会場にいるLOVOT達にはみなかわいい名前がついています。社員からも愛されていることが自然と伝わります。
金曜日訪問した際、何気ない雑談で「LOVOTがいる家庭の子供達は「LOVOTネイティブ」として大きくなるんですね。どんな考えをロボットに対して持つんだろう。」といったやり取りがありました。それを聞いた社員の方は「そんな製品を自分たちは作っていたんですね!」と話していたことが印象的でした。「事業や顧客について理解が深まった時」に立ち会えた気がします。
「率直に買おうと思う?」
と聞かれると、NOです。
一般家庭で買うには価格が高いですし、LOVOTの振る舞いもまだまだ少なく、飽きてしまうかもと感じました。家の見守りもできるそうですが、人がLOVOTに求めるものとは少し違う気がします。
ただ、そんなことは会社もとっくにわかっていて、それでもいい製品に育てるべく、一歩歩みを進めるために今回の体験会を開いたのだと思います。よその会社の展示会と違うと感じたのはこれが理由かもしれません。
おわりに
残念ながら今回の体験会は1/18(金)までとのことです。 反響を見て秋に開催するかもしれないそうですが、行く機会があればぜひ行ってみてください。
最低なスクラムマスターの言動集
スクラムマスターとして不適切な言動をテンポよくまとめた動画です。
- それはこのスクラムイベントで話すことではない。
- 今日の振り返りでは開発を改善する10のアイデアを話したいんだ
- もっとアウトプット増やしたいからたくさんのことに着手して欲しいんだけど
- 今日のデイリースクラムは過去最短で終わったぞ!
- (スクラムのことを質問しにきた開発者に対して)仕事に戻れ
- 振り返りの始めは5分黙ってまとめを書いてみよう。 おい、そこ!黙ってって言っただろ!
- それはチームの障害じゃないよ
- この機能追加は友人に約束したものだから必要なんだ。
- (今日の午後にデモがあるから急ぎで対応して欲しいんだという依頼に対して) OK、問題なし。
- Continuous Integrationに関する取り組みは誰の助けにもなっていない。
- おい、みんな! 今日のふりかえりはCEOが来たぞ。でもいつ通りやろう!
- スプリント中に終わらなそうだから期間を2週間じゃなくて3週間にしよう。
- (チームに質問) みんな、このストーリーは終わったかな?
- 君のチームのベロシティはうちのチームよりも悪いから残業してカバーした方が良い
(スクラム)チームに人を連れてくる
はじめに
Regional Scrum Gathering Tokyo 2019のOpen Space Technologyで「隣の部署から借りているあの人を3ヶ月でもらう方法」というお題が出て参加してきました。
「ひとさらいしたい!」の文字が印象的ですが、本当にさらったことがある人はどうも少ないようなので、「チームに人を連れてくる」コツをここにまとめておきます。
以下、読む人にわかりやすいようにOSTで話した順番とは必ずしもあっていません。
話したこと
チームに必要な人を連れてくるのはマネージャーの仕事
そもそも論としてマネージャーの仕事は「人・モノ・カネ」の用意であると言われています。 「人さらい」というと物騒ですが、「チームに必要な人を探して連れてくる」のはマネージャーの立派な責務です。与えられたメンバーで最善を出そうとすることがマネージャーの仕事ではありません。
マネージャーという肩書きはなくとも、プロジェクトの責任者であればチームに必要な人を連れてくるのも仕事のうちの一つだと考えを改めた方がよいです。
専任を増やそう
よくあるのが兼任でプロジェクトに追加リソースが充てられるパターンです。30%だけとか、50% とかどこかで聞いたこと、やらされたことはありませんか?
過去のプロジェクトで追加人員をお願いした時に50%の人が2人割り当てられ、合わせて1人月のリソースとなったことがあります。50%の人がスクラムチームに入る問題として「イベントに来ない(来れない)」「イベントに来なくても強く怒れない」がありました。「別プロジェクトの打ち合わせがあるから月曜と水曜のデイリースクラムは欠席します。今週のスプリントレビューと振り返りは出れません。」といった類です。50%だと「どちらのプロジェクトも重要」となるので、このことを叱ることに躊躇してしまいました。
当時の解決策は上位の管理職に「人数が減っても良いので、プロジェクトの参加率が50%よりも多くなるメンバを作ってください」と調整を依頼しました。「50% 」が2人ではなく。「100%」が1人や、「60%」の人と「40%」の人にして欲しいというものです。またスクラムへの参加が50%に満たない人をチームメンバから除外して、プロジェクトに関するチーム外の作業を割り振るようにしました。これは名前だけ載せておくと上の管理職にはたくさんの人が割り当たっているように見えるからです。
結果は50%の2人は100%の2人になって戻ってきました。
居心地のよい場所を作る
別の部署から連れてくる人は席が物理的に離れていることが多いので、チームに座席を作り、協力してもらう時間が長くなるようにするといったものがありました。場所を作るだけでなく、性能の良いPCを用意する、複数のディスプレイを用意する、楽しいチームの雰囲気、おやつなど元の部署より居心地が良いと思わせてついつい協力しすぎちゃう効果を狙いましょう。
正攻法でもらう
「現在のリソースではプロジェクトの進捗に支障が出ます。XXXが原因なので人を追加していただかないとスケジュールが遅延します」と上位の管理職にアラートを送るのが正攻法だと思います。スクラムの原則の一つに「透明性」がありますので、現在の進捗・進捗を阻む障害がなんであるか明確にしてチーム外に発信しましょう。コツは手を変え、品を変え、何度もアラートを上げることです。世の中には「何度も相談に来ないということは、もう解決したんだろう」と判断する上位管理職が少なからずいます。
借りている人員を返す時にこう言ってみてもいいかもしれません。「元のプロジェクトで必要としているのもわかりますが、うちのプロジェクトでも頼りにしている人材です。どちらのプロジェクトの専任とするかの調整はお任せしますが、本人の希望を聞いて、望ましいようにしてあげてください。」自分のプロジェクトになびいていることがわかっていれば、自信を持って言いましょう。メンバーのことを考えているいいリーダーだと思われる副次的な効果も狙えます。
人と予算がセットになっていて連れてこれない
SIer的な問題です。1つのプロジェクトに特定の人が結び付けられてしまうことで炎上するまでどうにも手出しができなくなってしまいます。
いくつかのプロジェクトをまとめ、それに複数の人材を「リソースプール」としてまとめて結び付けすることで、その中での人員融通がやりやすくなるかもしれません。エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリングの中でバッファはタスク単位でなくプロジェクト単位でまとめて管理することで見える化しやすくするといった話がありました。人月管理でも応用できる考え方かもしれません。
新人を連れてこよう
「新卒・新人」はしがらみが少なく、連れてきやすいタイプの人員です。 既存メンバーと比べてアウトプットが少ないのでは・・・と思いがちですが、新人に限らず誰でも参加してしばらくはアウトプットが出しにくいものです。 またチームに入ってからの成長を考えると伸び代が大きく期待できるかもしれません。
副次的な効果として中堅メンバが新人に教えることによりチーム内にコミュニケーションが生まれ、雰囲気がよくなることもあります。
「この仕事はスペシャリストが必要です。だから兼任でないとダメなんです。」
とよく聞く話ですが、本当にそうでしょうか? 専任のチームメンバでは学べないのでしょうか? スペシャリストがトラックに轢かれたらプロジェクト、ひいては会社の存亡の危機です!
まずはプロジェクトに必要な技術を棚卸しして、スキルマップを作ってみましょう。 チームにスペシャリストの仕事を誰か学んで身につけられないか聞いてみると良いでしょう。 その上でスペシャリストでないと担えないものが本当にあったのだとしたら、すぐに採用活動を始めた方が良いと思います。
チームをプロジェクトにあてる
スクラムは自己組織化したチームを作り、継続してプロダクト開発を行うことを良しとしていますが、実際は有期のプロジェクトが立ち上がり、そこに人が割り当てられることが多いです。 チームメンバは同じまま、新しいプロジェクトに割り当てることができれば、リーダーは強いチームを作るものという意識に向けさせられると考えます。
社外から連れてくる
社内から連れてくると揉め事になるため、急成長中の会社では社外から採用して連れてくることを奨励していると聞きました。 転職が活発になってきた昨今ならではの動向だと思います。
攻めと守りを意識しよう
「連れてくる」ことばかり考えていると「連れていかれることもある」ことを忘れてしまうので、チームメンバーを守ることもお忘れなく。
急成長中のAI/ロボット会社の事例として、「社内に面白いプロジェクトが次々立ち上がるため、開発者が移って行ってしまう」というものがありました。今のプロジェクトが重要で意義があることだと折に触れて伝えましょう。
(番外編)Netflixの話
- 作者:パティ・マッコード
- 発売日: 2018/08/17
- メディア: 単行本(ソフトカバー)
「社外から連れてくる」「メンバを守る」で思い出して共有したのがNETFLIXの最強人事戦略 自由と責任の文化を築くです。 今のNetflixを形作った文化、採用について書かれているのですが、下記のようなことが書かれています。
- 社員が本当に求めているのは福利厚生ではない。自社のビジネスをより深く勉強し学ぶ機会こそが人を惹きつける。
- Netflixは自社に合わなくなった、必要としなくなった社員を解雇するようにしているが、躊躇なく解雇するのは代わりの人材をいつでも補充できるようにしているから。採用は何より重要な活動で、社外から人材会社の人員をスカウトし、社内にヘッドハンティング組織を構築した。
終わりに
ここまでで30分です。 思い出しながらまとめるのは大変でしたが、濃密で楽しい時間が過ごせました。
Regional Scrum Gathering Tokyo 2019に参加しました
はじめに
初参加です。参加者同士の交流色が強い、活気あるイベントでした。
聞いてきた話と個人的なメモ
Outcome Delivery: delivering what matters
「最高のコーヒー」と聞かれると豆や入れ方、カップや砂糖などコーヒーのことだけを考えてしまうが、「素晴らしいコーヒー体験」を問われると誰と飲むか、どこで飲むかなど人それぞれ違った視点が生まれてきます。 「開発する」ことを考えると短時間でたくさんの成果を作り出すことに頭が向いてしまいますが、その前に「なぜ」それが必要なのかをよく考えてみましょうという話でした。
「なぜ」を繰り返すところはトヨタ自動車の「なぜなぜ5回」に似ていると感じました。リーン由来で何か影響を受けているのかもしれません。
Coaching resilient Scrum teams
プロジェクトに関わるたくさんの人を「作業グループ」から「チーム」に変え、さらにアジャイルに動けるようにするため、コーチとして行なったことを紹介されていました。
コンテキスト別にチームをマッピングし、効果が出やすく全体への影響が大きいところからコーチとしてサポートしていったとのこと。
チームごとに改善の取り組みを可視化するためにマインドマップを作っていたのが面白かったです。「最近は何の改善を検討してたんだっけ」というのは忘れてしまいがちなので俯瞰図を作ってマメに更新するのは良いと思います。
運用中のモバイルゲーム開発チームに、並行バージョン開発を導入してみた
ゲームづくりの難しさ、Apple/Googleのプラットフォームに載っているため配信が自分たちでコントロールできない難しさ、評価の難しさなど色々悩んだ末にどうチームを分割して成果が出るように考えたかというお話でした。背景がわからないとどうしてバージョン別チームを作ったのか腹落ちできませんが、20分枠だとそこの説明に時間を使ってしまって説明が難しそうだなと感じました。
講演後に「2チームで同一バージョンを半分の期間で作ってはどうか」と話をしましたが、「ゲームは組み合わせ評価が難しく、QA期間が短縮できないからそこがボトルネックになってしまう」と聞いて腹落ちしました。でも「評価をもっと短く終える手段はないのか」と考えると次の段階が見えてくるような気がします。
スクラムチームを辞めて20人でカンバン運用してきた半年間の軌跡
20分枠なのにスライド150枚の対策でした。 クロスファンクショナルチームを組んでいたが、評価が難しく、職能別チーム(バックエンド・フロントエンド)に組み直した。そしてチーム同士の連携を強化するためカンバン開発に移行し、カンバンもなんども作り直してようやく良さそうなカンバンにたどり着いたというお話でした。カンバンの改善事例はあまりみないのでその点で面白い発表だったと思います。
一方で本当の問題は「評価をどうするか」であって、クロスファンクショナルチームを止めるほどのことだったのかが気になりました。話を聞けなかったので憶測ですが、真因は「給与が評価と連動しており、エンジニアの納得感を得ることが難しい」のような気がします。最近読んだNetflixの本では「給与と評価を連動させるな」と言っていました。
東名阪をまたいだLeSS Huge(大規模スクラム)においてスクラムマスターとして実践したこと
www.slideshare.net
東京・名古屋・大阪の3拠点でLeSS Hugeをやった取り組み紹介でした。「LeSSみなさんご存知ですよね」といった体で話が進んでいきましたが、本当に認知度あるのでしょうか? 結局いろいろあって、発表時点ではLeSSをやめてしまったようです。一気にHugeを始めてしまったのがよくなかったんじゃないかと思います。
ちゃんとやってるのになんかうまくいかないスクラムからの脱出
スクラムの基本を、スクラムという言葉を使わずに、1歩ずつチームを導く優しいコーチのお話でした。 「スクラムを基本通りやれ」って言ってはダメですかねというお話を後でしましたが、「いきなりたくさんのことはできないから」と返答いただきました。コーチの余力がある場合にはとても良いやり方だと思います。
エンジニア採用もカンバン使ってみたら、「透明性」によって採用が活動が変わったこと / Agile Recruiting
唯一の「開発」でないアジャイル事例だったのではないかと思います。 ほとんどエンジニアしかいない会場ではなく、違う場であればもっと引きがあってもおかしくない事例紹介だと思いました。
スクラムならできる プロダクトバックログの戦略
www.slideshare.net
スクラムコーチが事業会社のIT部門部長として転職し、社内の信頼感を得て、組織を立て直していく泥臭いお話でした。 タイトルももっと泥臭くつけた方が話を聞きにくる人を惹きつけられたんじゃないかと思います。 スクラムをうまく社内に根付かせることができた人にとっては「あるある」話だったと思います。泥臭い経験の共有は貴重です。
Learning to Experiment
モブプログラミングを考案したHunter Industries社のChris Lucian氏の公演でした。 流行しているモブプログラミングですが、突然ひらめいでできたものではなく、さまざまな実験を大小繰り返し、失敗を学びながら生まれたものだとわかりました。 LeSSでも「実験が大事」だと話していて、根っこは一緒なのかなと思います。
心に残る言葉が多いセッションでもありました。
- 失敗するリスクが高い実験こそが学習を最大化する
- 学習する時間を定期的に用意する
- いいプラクティスを広げるには透明性、結果、一貫性が重要
- チームに「最近何を実験しているか」を聞く。
喧嘩できるチームを作るワークショップ
振る舞いは観測できるけど、何を考えているかは見えない。でも考えの元となる価値観・常識・正しいと考えていることは人それぞれ違っていて、それを形作るのは文化・風土・空気である。でも文化や空気も実は個人の経験や学習によって少しずつ作られるもので価値観も変わるので、対話を観察し、フィードバックすることで良い文化、チームの器を作っていこう・・・というワークショップだったと思います。抽象的な話も多く正しく受け止められたのか自身がありません。
「場を取り繕おうとする”安全”」ではなく「そもそも論が言える”安心”」な空気を作ることが大事だとワークを行なったチームで話してこれが一番すっときました。
ワークショップの途中で議論の内容を他の方にみていただく機会があったのですが、やり取りを第3者からみてもらってフィードバックしてもらうのはヤフーの1on1―――部下を成長させるコミュニケーションの技法でも1on1を訓練するやり方として紹介されており、少し似ているなと感じました。
明日現場で使える!とにかく明るいScrum Patterns 活用ワークショップ
とにかく明るかったです。
自分たちが普段使っているプラクティスを解きほぐし、どういう時に使えるものなのか、それが本当にベストなのか、考えるきっかけとするのに面白いワークショップでした。まだできたてのようなので、今後さらに良くなっていくと思います。
よなよなエール流 熱狂を生むチームづくり ~8年連続赤字から13年連続増収増益までの軌跡~
今回聞いてきた中で一番面白いお話でした。
- 競合が少ない道を選び、真似できないほど徹底的に差別化する。これを繰り返し行う。
- チームを育てる。中心となる人の立候補を待ち、チームビルディングをきちんと学ぶ。
- コミュニケーションは意図的にとる場を作る。「大人数⇄少人数」と「質⇄量」の軸でマップを作り、マップの全域がカバーされるように社内イベントを配置する。
本もいただけたので時間を作って読みます。私はヤッホーブルーイングのファンになってしまいました。
- 作者: 井手直行
- 出版社/メーカー: 東洋経済新報社
- 発売日: 2016/04/08
- メディア: 単行本
- この商品を含むブログを見る
素直な感想
自分のチームはかなりうまくアジャイル開発/スクラム開発できている部類だなと感じました。おそらく中の上か、上の下ぐらい。 ただHunter Industriesの事例など上には上があるので日々実験を繰り返してまだまだよくする余地はあるのだなと思いました。
この点が改善されるともっと良いのに
と思った点です。
- 持ち帰り荷物が多い
- 20分の発表枠がきつそう
- 背景の説明で10分ぐらい使わされている例が多かったです。休憩時間を短くして30分枠にしてもよいのでは?
- 質疑応答の時間がない
- 20分枠を20分話すとQ&Aができません。5分ぐらいはQ&Aに時間を割くか、またはフィードバックを貼り付ける紙を壁に用意してもよいのでは?
- 同時通訳聞きにくい
- 会場中に英語のスピーチが鳴り響き、レシーバーから日本語が流れてきます。どっちも大きい音で入ってくるので英語が少しでもわかると体が聞こうとしてしまって辛いです。
- レシーバーをつけないで英語で聞くことにしても隣の人・会場中のレシーバーの音漏れが大きくて結局聞こえてしまうという話も聞きました。同時通訳があるイベントはこういうものなのかもしれませんが、もっといいやり方ないですかね。レシーバーがイヤホンのように音漏れしにくいものに変わるとか。
- ネットワークパーティーのタイミング
- Confengineがスマホで読みづらい。
- ノートPCを会場に持ち込んでいないとスマホで確認することになりますが、レイアウトが詰められて大変読みにくいです。
- スケジュールは急遽変更することが無いようなので、会場の壁に貼ってあっても良いのではと思いました。
アジャイルプラクティスを整理する : Agile Landscape v3とOpen Practice Library
はじめに
Regional Scrum Gathering® Tokyo 2019に参加してきました。
初日の基調講演を行なったGabrielle Benefieldさんのスライドで紹介されていた「アジャイル開発に関するプラクティスは多すぎる」という意味合いで引用されていたAgile Landscape v3と、Gabrielleさんが教えている"Outcome Delivery"フレームワークを使ってまとめられたOpen Practice Libraryが面白かったので紹介します。
Agile Landscape v3
下記が原典で、作者はDeloitteの方のようです。
www.slideshare.net
見た目のインパクトが強すぎて、中身が正しいのかは全く終えていません。 下記のような批判記事もあるので、見た目の面白さはあるけど実用的なものではないと思います。
Open Practice Library
・・・の前に、Outcome Deliveryフレームワークの紹介
「どう作るのか」だけでなく「なぜ作るのか」、「作った結果、何を学びどう方向転換するのか」を含めてぐるぐると考えを深めていきましょうという思考のフレームワークです。トヨタの「なぜなぜ5回」に似ていると思いました。
思考を深める流れはメビウスの輪の形になっており、3つの領域に別れています。
- Discovery Loop : なぜ作るのか、誰のためなのかを考える
- Options Pivot : 1, 3を踏まえ、どのような選択肢があり、どれを採用するかを考える
- Delivery Loop : 実装・提供を行う
Outcome Deliveryでは各フェーズごとにあったアプローチをまとめたカードがあり、その中から適切なものを選択して使うそうです。
興味がある方は下記を参照されると良いと思います。
改めて "Open Practice Library"
上記フレームワークを使ってアジャイル開発のプラクティスをまとめたものです。Redhatが自分たちのためにまとめたものをOSSの精神で公開していると公演で聞きました。Googleで検索しにくそうなサイト名なのが日本では知られていない要因かもしれません。
サイトを見るとこんな形で分類されていました。
- Discovery Loop
- Options Pivot
- Canaryリリース
- バックログリファインメント
- ...
- Delivery Loop
- スプリントプランニング
- デイリースクラム
- レトロスペクティブ・ふりかえり
- ...
あまり知られてなさそうなものもあるので時間を見つけて見てみると良いと思います。
プロダクトバックログリファインメントに関する10の改善案(10 Experiments With Product Backlog Refinement)
はじめに
昨年公開されたブログ記事で、プロダクトバックログリファインメントをより良くするために行なった10の施策が面白かったので紹介します。 「10の改善案」とありますが、続きものもあるのでアイデアとしてはもう少し少ないです。
10の改善案
1. 「ストーリーが着手できる状態」についてチームと合意する (Agree a Definition of Ready with the team)
「スプリントの始まりにプロダクトバックログの先頭にあるものが着手するものだ」ではなく、着手できる条件を明確に決めておき、着手できないのであれば時間を作って事前にもう少し詳細化しておきましょうねというものです。
「ストーリーが着手できる状態」は「1. リファインメントができる状態」と「2. ストーリーが着手できる状態」に分けて考えないといけません。
定義すると、例えば以下のような感じでしょうか?
- リファインメントができる状態
- なぜ実装するのか、誰にとっての機能なのかなどが明確になっている。
- どういうUI/UXにするか、どういう設計にするか、作業見積もりができる程度まで明確になっている。
- ストーリーが着手できる状態
- チームがストーリーをタスクに分解できるだけの情報が備わっている。
- どういうUI/UXにするか、どういう設計にするかがスプリント内で取りかかれる程度まで明確になっている。
2. 誰がリファインメントを担当するかを決めておく (Decide ownership, then allow others to opt out.)
全員で見積もりすると時間の無駄になるから、「このストーリーを担当するのはこの人たち」とあらかじめ任命してしまうというものです。
個人的にはスクラムマスターと、一番詳しい人と、分野外でツッコミ入れてくれそうな人をランダムで呼び集めれば事前に決めるまでしなくても良いのではないかと思います。
3. チーム内に階層があることを理解する (Acknowledge the existence of hierarchy.)
マネージャーやQA責任者といった組織上の上位階層に位置する人を尊重し、イベントに参加できるように取りはからいましょうというものです。 事前に呼ぶことを伝えておけば、リファインメントに参加できなくても適切な人を代役に立ててくれるはずです。
4. プロダクトバックログリファインメントは同じ時間に開催する (Schedule PBR Sessions at Same time every day.)
タイトル通りです。
私は英語を誤読していましたが、「毎日同じ時間にリファインメントをスケジュールしよう」ではなく、「リファインメントをスケジュールするなら時間を都度決めるのではなく、やるならこの時間と決めておこう」という意味のようです。
5. リファインメントに回すユーザーストーリーを事前に回覧する (Circulate User Stories 48 hours in advance)
2日前(48時間前)に回覧できるかは分かりませんが、会議の議題を事前に送るのが有効なように、やった方が良い施策だと思います。 一方で自分の経験で、送ったこともありましたが、必ずしも読まれるとは限りません。
原文でも言及されいるようにリファインメントの最初に「回覧したストーリーは読んできましたね」と毎回確認し、「事前に読んでおかなければならないもの」と印象付けるのが良いと思います。
6. リファインメントの結果をSlackに流す (Slack Channel with details of Refinement done that day)
RedmineとかJIRAとか何らかのIssue管理システムを使っていればRSS配信や外部システム連携機能が備わっているので設定すれば任意のチャンネルに自動投稿ができるようになります。 私もやったことがありますが、スクラムマスターがたまに見てくれているぐらいです。効果があるのかはよくわかりません。
7. リファインメントの進捗状況がわかるようにカンバンボードを用意する (Kanban Board for Refinement Process)
「リファインメント待ち」「議論中」「デザイン待ち」「設計待ち」のように、各ストーリーがどの状態にあるのかを見える化するという施策です。 プロダクトオーナーが思いついてからチームが着手するまでによくよく議論するチームはこういう施策が必要なのかもしれません。
私の経験では必要になったことがないので分かりません。
8. (7の続編で)リファインメントの進捗状況がわかるようにTrelloでボードを用意する (Trello Board for Refinement Process)
7をWeb化したものです。コツは7が成功して、効果を感じられるようになってから8をやることだそうです。
9. (4に近いが)リファインメントの開催スケジュールをスプリントの始めに決めておく (Prepare Refinement Schedule at Start of Sprint)
プロダクトオーナーの思いつきで開催するのではなく、きちんと事前に決めておきましょうというものです。 スプリントごとにリファインメントの打ち合わせ日時を変えるメリットはさしてないと思いますので、「毎週何曜日の何時から何時はリファインメントの時間だから空けておくように」と決めておくのがよいとおもいます。
10. スパイク(着手前の事前調査)が発生することを許容する (Please Please Please: Allow for Spikes to happen)
安定して成果を提供できるようにするには事前の準備が欠かせませんが、スケジュールがタイトだったりするととにかく実装しろというプレッシャーをかけてしまいがちなのでやめましょう。
おわりに
原文では導入した詳細な背景、おすすめ度なども言及されています。 興味がある方はぜひとも参照下さい。