tuneの日記

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

LOVOT体験会に行ってきました: 最高の特典や催しは事業や顧客について理解を深められる機会である。

はじめに

f:id:tune:20190114174815j:plain
LOVOT体験会に行ってきました

1/11(金)と1/14(月)の2回、GROOVE X社が開発したLOVOTの体験会に行ってきました。金曜日は同じ会社の友人と、月曜日は子供を連れ家族とです。

「体験会の様子をぜひSNSで拡散してください」とお願いがあったのですが、このブログのテーマは「アジャイル開発、組織変革、ファシリテーションについて学んだことの記録」としているので「ちょっと違うかな」と思っていたのですが、最近読んだネットフリックスの組織本にあった文章をふと思い出しました。

ネットフリックスが考える「従業員が仕事に満足感を得る時」はどんな時か

NETFLIXの最強人事戦略 自由と責任の文化を築く

NETFLIXの最強人事戦略 自由と責任の文化を築く

この本はカルチャーデックと呼ばれるNETFLIXの企業文化や社員の行動規範を定めたガイドをより詳しく説明したものです。

その中で「従業員が仕事に満足感を得る時」について、こんな説明があります。

仕事に対する真のゆるぎない満足感は、優れた同僚たちと真剣に問題解決に取り組む時や、 懸命に生み出した製品・サービスを顧客が気に入ってくれた時にこそ得られる。

従業員が働きたくなるように、給与・福利厚生・ピカピカしたオフィス・ビールサーバーなどいろいろな用意をする企業が多いですが、ネットフリックスはこれを「従業員を子供扱いしている」と一刀両断しています。

最高の特典や催しは事業や顧客について理解を深められる機会である。

ネットフリックスの例では映画事業について学ぶ機会をたくさん設けたそうです。 従業員全員をサンダンス映画祭へ連れて行ったり、著名な映画監督・映写技師・映画編集者の話を聞きにロサンゼルスへしょっちゅういったと紹介されています。

LOVOT体験会の様子

f:id:tune:20190114174840p:plain
LOVOTとのふれあい

体験会のアンケート項目から推測するに、LOVOTの購入を検討している近い将来のお客様から、LOVOTに興味を持っている少し将来のお客様、ロボットや技術に興味があるエンジニアなど様々な人が訪れているようです。

そういった人と社員が直接コミュニケーションが取れる機会を与えるのはまさに「事業や顧客について理解を深められる機会」だなと思いました。

f:id:tune:20190114174927p:plain
技術の展示

またLOVOTを構成する技術を集めたコーナーからは「優れた同僚たちと真剣に問題解決に取り組む」ことに真摯に向き合っていることが伝わります。

f:id:tune:20190114174955j:plain
技術展示内容の一例

技術展示会やオープンハウスを年一で開催し、社員が説明に立つことはよくあると思いますが、それとは違った印象を受けました。残念ながら理由は私もうまく言葉にできません。少人数制で説明員の方とたくさんお話しする機会があったからなのか。技術・アイデアの出し惜しみをしてないように感じたからか。これから育てていく、いわばβ版をぶつけてきているからなのか。そもそもGROOVE Xもどう広めていくか悩みを素直にぶつけているように感じたからか‥。

f:id:tune:20190114175016j:plain
着せ替えなどコンセプトの展示

会場にいるLOVOT達にはみなかわいい名前がついています。社員からも愛されていることが自然と伝わります。

金曜日訪問した際、何気ない雑談で「LOVOTがいる家庭の子供達は「LOVOTネイティブ」として大きくなるんですね。どんな考えをロボットに対して持つんだろう。」といったやり取りがありました。それを聞いた社員の方は「そんな製品を自分たちは作っていたんですね!」と話していたことが印象的でした。「事業や顧客について理解が深まった時」に立ち会えた気がします。

「率直に買おうと思う?」

f:id:tune:20190114175318j:plain
体験会で触れ合ってくれた「にんじん」くん(にんじん ちゃん?)

と聞かれると、NOです。

一般家庭で買うには価格が高いですし、LOVOTの振る舞いもまだまだ少なく、飽きてしまうかもと感じました。家の見守りもできるそうですが、人がLOVOTに求めるものとは少し違う気がします。

ただ、そんなことは会社もとっくにわかっていて、それでもいい製品に育てるべく、一歩歩みを進めるために今回の体験会を開いたのだと思います。よその会社の展示会と違うと感じたのはこれが理由かもしれません。

おわりに

LOVOT体験会の申し込みサイト

残念ながら今回の体験会は1/18(金)までとのことです。 反響を見て秋に開催するかもしれないそうですが、行く機会があればぜひ行ってみてください。

最低なスクラムマスターの言動集

www.youtube.com

スクラムマスターとして不適切な言動をテンポよくまとめた動画です。

  • それはこのスクラムイベントで話すことではない。
  • 今日の振り返りでは開発を改善する10のアイデアを話したいんだ
  • もっとアウトプット増やしたいからたくさんのことに着手して欲しいんだけど
  • 今日のデイリースクラムは過去最短で終わったぞ!
  • (スクラムのことを質問しにきた開発者に対して)仕事に戻れ
  • 振り返りの始めは5分黙ってまとめを書いてみよう。 おい、そこ!黙ってって言っただろ!
  • それはチームの障害じゃないよ
  • この機能追加は友人に約束したものだから必要なんだ。
  • (今日の午後にデモがあるから急ぎで対応して欲しいんだという依頼に対して) OK、問題なし。
  • Continuous Integrationに関する取り組みは誰の助けにもなっていない。
  • おい、みんな! 今日のふりかえりはCEOが来たぞ。でもいつ通りやろう!
  • スプリント中に終わらなそうだから期間を2週間じゃなくて3週間にしよう。
  • (チームに質問) みんな、このストーリーは終わったかな?
  • 君のチームのベロシティはうちのチームよりも悪いから残業してカバーした方が良い

(スクラム)チームに人を連れてくる

f:id:tune:20190111113402j:plain
ひとさらいしたい!

はじめに

Regional Scrum Gathering Tokyo 2019のOpen Space Technologyで「隣の部署から借りているあの人を3ヶ月でもらう方法」というお題が出て参加してきました。

「ひとさらいしたい!」の文字が印象的ですが、本当にさらったことがある人はどうも少ないようなので、「チームに人を連れてくる」コツをここにまとめておきます。

以下、読む人にわかりやすいようにOSTで話した順番とは必ずしもあっていません。

話したこと

チームに必要な人を連れてくるのはマネージャーの仕事

そもそも論としてマネージャーの仕事は「人・モノ・カネ」の用意であると言われています。 「人さらい」というと物騒ですが、「チームに必要な人を探して連れてくる」のはマネージャーの立派な責務です。与えられたメンバーで最善を出そうとすることがマネージャーの仕事ではありません。

マネージャーという肩書きはなくとも、プロジェクトの責任者であればチームに必要な人を連れてくるのも仕事のうちの一つだと考えを改めた方がよいです。

専任を増やそう

よくあるのが兼任でプロジェクトに追加リソースが充てられるパターンです。30%だけとか、「50% - 50%」とかどこかで聞いたことや、やらされたことがあると思います。

過去のプロジェクトで追加人員をお願いした時に「50% - 50%」の人が2人割り当てられ、合わせて1人月のリソースとなったことがあります。50%の人がスクラムチームに入る問題として「イベントに来ない(来れない)」「イベントに来なくても強く怒れない」がありました。別「プロジェクトの打ち合わせがあるから月曜と水曜のデイリースクラムは欠席します。今週のスプリントレビューと振り返りは出れません。」といった類です。50%だと「どちらのプロジェクトも重要」となるので、このことを叱ることに躊躇してしまいました。

当時の解決策は上位の管理職に「人数が減っても良いので、プロジェクトの参加率が50%よりも多くなるメンバを作ってください」と調整を依頼しました。「50% - 50%」が2人ではなく。「100%」が1人や、「60%」の人と「40%」の人にして欲しいというものです。またスクラムへの参加が50%に満たない人をチームメンバから除外して、プロジェクトに関するチーム外の作業を割り振るようにしました。これは名前だけ載せておくと上の管理職にはたくさんの人が割り当たっているように見えるからです。

結果は50%の2人は100%の2人になって戻ってきました。

居心地のよい場所を作る

別の部署から連れてくる人は席が物理的に離れていることが多いので、チームに座席を作り、協力してもらう時間が長くなるようにするといったものがありました。場所を作るだけでなく、性能の良いPCを用意する、複数のディスプレイを用意する、楽しいチームの雰囲気、おやつなど元の部署より居心地が良いと思わせてついつい協力しすぎちゃう効果を狙いましょう。

正攻法でもらう

「現在のリソースではプロジェクトの進捗に支障が出ます。XXXが原因なので人を追加していただかないとスケジュールが遅延します」と上位の管理職にアラートを送るのが正攻法だと思います。スクラムの原則の一つに「透明性」がありますので、現在の進捗・進捗を阻む障害がなんであるか明確にしてチーム外に発信しましょう。コツは手を変え、品を変え、何度もアラートを上げることです。世の中には「何度も相談に来ないということは、もう解決したんだろう」と判断する上位管理職が少なからずいます。

借りている人員を返す時にこう言ってみてもいいかもしれません。「元のプロジェクトで必要としているのもわかりますが、うちのプロジェクトでも頼りにしている人材です。どちらのプロジェクトの専任とするかの調整はお任せしますが、本人の希望を聞いて、望ましいようにしてあげてください。」自分のプロジェクトになびいていることがわかっていれば、自信を持って言いましょう。メンバーのことを考えているいいリーダーだと思われる副次的な効果も狙えます。

人と予算がセットになっていて連れてこれない

SIer的な問題です。1つのプロジェクトに特定の人が結び付けられてしまうことで炎上するまでどうにも手出しができなくなってしまいます。

いくつかのプロジェクトをまとめ、それに複数の人材を「リソースプール」としてまとめて結び付けすることで、その中での人員融通がやりやすくなるかもしれません。エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリングの中でバッファはタスク単位でなくプロジェクト単位でまとめて管理することで見える化しやすくするといった話がありました。人月管理でも応用できる考え方かもしれません。

新人を連れてこよう

「新卒・新人」はしがらみが少なく、連れてきやすいタイプの人員です。 既存メンバーと比べてアウトプットが少ないのでは・・・と思いがちですが、新人に限らず誰でも参加してしばらくはアウトプットが出しにくいものです。 またチームに入ってからの成長を考えると伸び代が大きく期待できるかもしれません。

副次的な効果として中堅メンバが新人に教えることによりチーム内にコミュニケーションが生まれ、雰囲気がよくなることもあります。

「この仕事はスペシャリストが必要です。だから兼任でないとダメなんです。」

とよく聞く話ですが、本当にそうでしょうか? 専任のチームメンバでは学べないのでしょうか? スペシャリストがトラックに轢かれたらプロジェクト、ひいては会社の存亡の危機です!

まずはプロジェクトに必要な技術を棚卸しして、スキルマップを作ってみましょう。 チームにスペシャリストの仕事を誰か学んで身につけられないか聞いてみると良いでしょう。 その上でスペシャリストでないと担えないものが本当にあったのだとしたら、すぐに採用活動を始めた方が良いと思います。

チームをプロジェクトにあてる

スクラムは自己組織化したチームを作り、継続してプロダクト開発を行うことを良しとしていますが、実際は有期のプロジェクトが立ち上がり、そこに人が割り当てられることが多いです。 チームメンバは同じまま、新しいプロジェクトに割り当てることができれば、リーダーは強いチームを作るものという意識に向けさせられると考えます。

社外から連れてくる

社内から連れてくると揉め事になるため、急成長中の会社では社外から採用して連れてくるこを奨励していると聞きました。 転職が活発になってきた昨今ならではの動向だと思います。

攻めと守りを意識しよう

「連れてくる」ことばかり考えていると「連れていかれることもある」ことを忘れてしまうので、チームメンバーを守ることもお忘れなく。

急成長中のAI/ロボット会社の事例として、「社内に面白いプロジェクトが次々立ち上がるため、開発者が移って行ってしまう」というものがありました。今のプロジェクトが重要意義があることだと折に触れて伝えましょう。

(番外編)Netflixの話

NETFLIXの最強人事戦略 自由と責任の文化を築く

NETFLIXの最強人事戦略 自由と責任の文化を築く

「社外から連れてくる」「メンバを守る」で思い出して共有したのがNETFLIXの最強人事戦略 自由と責任の文化を築くです。 今のNetflixを形作った文化、採用について書かれているのですが、下記のようなことが書かれています。

  1. 社員が本当に求めているのは福利厚生ではない。自社のビジネスをより深く勉強し学ぶ機会こそが人を惹きつける。
  2. Netflixは自社に合わなくなった、必要としなくなった社員を解雇するようにしているが、躊躇なく解雇するのは代わりの人材をいつでも補充できるようにしているから。採用は何より重要な活動で、社外から人材会社の人員をスカウトし、社内にヘッドハンティング組織を構築した。

終わりに

ここまでで30分です。 思い出しながらまとめるのは大変でしたが、濃密で楽しい時間が過ごせました。

Regional Scrum Gathering Tokyo 2019に参加しました

f:id:tune:20190111215120j:plain
RGST2019参加証

はじめに

2019.scrumgatheringtokyo.org

初参加です。参加者同士の交流色が強い、活気あるイベントでした。

聞いてきた話と個人的なメモ

Outcome Delivery: delivering what matters

f:id:tune:20190111215053j:plain
コーヒーの絵

「最高のコーヒー」と聞かれると豆や入れ方、カップや砂糖などコーヒーのことだけを考えてしまうが、「素晴らしいコーヒー体験」を問われると誰と飲むか、どこで飲むかなど人それぞれ違った視点が生まれてきます。 「開発する」ことを考えると短時間でたくさんの成果を作り出すことに頭が向いてしまいますが、その前に「なぜ」それが必要なのかをよく考えてみましょうという話でした。

「なぜ」を繰り返すところはトヨタ自動車の「なぜなぜ5回」に似ていると感じました。リーン由来で何か影響を受けているのかもしれません。

Coaching resilient Scrum teams

プロジェクトに関わるたくさんの人を「作業グループ」から「チーム」に変え、さらにアジャイルに動けるようにするため、コーチとして行なったことを紹介されていました。

コンテキスト別にチームをマッピングし、効果が出やすく全体への影響が大きいところからコーチとしてサポートしていったとのこと。

チームごとに改善の取り組みを可視化するためにマインドマップを作っていたのが面白かったです。「最近は何の改善を検討してたんだっけ」というのは忘れてしまいがちなので俯瞰図を作ってマメに更新するのは良いと思います。

運用中のモバイルゲーム開発チームに、並行バージョン開発を導入してみた

speakerdeck.com

ゲームづくりの難しさ、Apple/Googleのプラットフォームに載っているため配信が自分たちでコントロールできない難しさ、評価の難しさなど色々悩んだ末にどうチームを分割して成果が出るように考えたかというお話でした。背景がわからないとどうしてバージョン別チームを作ったのか腹落ちできませんが、20分枠だとそこの説明に時間を使ってしまって説明が難しそうだなと感じました。

講演後に「2チームで同一バージョンを半分の期間で作ってはどうか」と話をしましたが、「ゲームは組み合わせ評価が難しく、QA期間が短縮できないからそこがボトルネックになってしまう」と聞いて腹落ちしました。でも「評価をもっと短く終える手段はないのか」と考えると次の段階が見えてくるような気がします。

スクラムチームを辞めて20人でカンバン運用してきた半年間の軌跡

speakerdeck.com

20分枠なのにスライド150枚の対策でした。 クロスファンクショナルチームを組んでいたが、評価が難しく、職能別チーム(バックエンド・フロントエンド)に組み直した。そしてチーム同士の連携を強化するためカンバン開発に移行し、看板もなんども作り直してようやく良さそうなカンバンにたどり着いたというお話でした。カンバンの改善事例はあまりみないのでその点で面白い発表だったと思います。

一方で本当の問題は「評価をどうするか」であって、クロスファンクショナルチームを止めるほどのことだったのかが気になりました。話を聞けなかったので憶測ですが、真因は「給与が評価と連動しており、エンジニアの納得感を得ることが難しい」のような気がします。最近読んだNetflixの本では「給与と評価を連動させるな」と言っていました。

東名阪をまたいだLeSS Huge(大規模スクラム)においてスクラムマスターとして実践したこと

www.slideshare.net

東京・名古屋・大阪の3拠点でLeSS Hugeをやった取り組み紹介でした。「LeSSみなさんご存知ですよね」といった体で話が進んでいきましたが、本当に認知度あるのでしょうか? 結局いろいろあって、発表時点ではLeSSをやめてしまったようです。一気にHugeを始めてしまったのがよくなかったんじゃないかと思います。

ちゃんとやってるのになんかうまくいかないスクラムからの脱出

speakerdeck.com

スクラムの基本を、スクラムという言葉を使わずに、1歩ずつチームを導く優しいコーチのお話でした。 「スクラムを基本通りやれ」って言ってはダメですかねというお話を後でしましたが、「いきなりたくさんのことはできないから」と返答いただきました。コーチの余力がある場合にはとても良いやり方だと思います。

エンジニア採用もカンバン使ってみたら、「透明性」によって採用が活動が変わったこと / Agile Recruiting

speakerdeck.com

唯一の「開発」でないアジャイル事例だったのではないかと思います。 ほとんどエンジニアしかいない会場ではなく、違う場であればもっと引きがあってもおかしくない事例紹介だと思いました。

スクラムならできる プロダクトバックログの戦略

www.slideshare.net

スクラムコーチが事業会社のIT部門部長として転職し、社内の信頼感を得て、組織を立て直していく泥臭いお話でした。 タイトルももっと泥臭くつけた方が話を聞きにくる人を惹きつけられたんじゃないかと思います。 スクラムをうまく社内に根付かせることができた人にとっては「あるある」話だったと思います。泥臭い経験の共有は貴重です。

Learning to Experiment

モブプログラミングを考案したHunter Industries社のChris Lucian氏の公演でした。 流行しているモブプログラミングですが、突然ひらめいでできたものではなく、さまざまな実験を大小繰り返し、失敗を学びながら生まれたものだとわかりました。 LeSSでも「実験が大事」だと話していて、根っこは一緒なのかなと思います。

心に残る言葉が多いセッションでもありました。

  • 失敗するリスクが高い実験こそが学習を最大化する
  • 学習する時間を定期的に用意する
  • いいプラクティスを広げるには透明性、結果、一貫性が重要
  • チームに「最近何を実験しているか」を聞く。

喧嘩できるチームを作るワークショップ

f:id:tune:20190111215138j:plain

振る舞いは観測できるけど、何を考えているかは見えない。でも考えの元となる価値観・常識・正しいと考えていることは人それぞれ違っていて、それを形作るのは文化・風土・空気である。でも文化や空気も実は個人の経験や学習によって少しずつ作られるもので価値観も変わるので、対話を観察し、フィードバックすることで良い文化、チームの器を作っていこう・・・というワークショップだったと思います。抽象的な話も多く正しく受け止められたのか自身がありません。

「場を取り繕おうとする”安全”」ではなく「そもそも論が言える”安心”」な空気を作ることが大事だとワークを行なったチームで話してこれが一番すっときました。

ワークショップの途中で議論の内容を他の方にみていただく機会があったのですが、やり取りを第3者からみてもらってフィードバックしてもらうのはヤフーの1on1―――部下を成長させるコミュニケーションの技法でも1on1を訓練するやり方として紹介されており、少し似ているなと感じました。

明日現場で使える!とにかく明るいScrum Patterns 活用ワークショップ

とにかく明るかったです。

自分たちが普段使っているプラクティスを解きほぐし、どういう時に使えるものなのか、それが本当にベストなのか、考えるきっかけとするのに面白いワークショップでした。まだできたてのようなので、今後さらに良くなっていくと思います。

よなよなエール流 熱狂を生むチームづくり ~8年連続赤字から13年連続増収増益までの軌跡~

今回聞いてきた中で一番面白いお話でした。

  • 競合が少ない道を選び、真似できないほど徹底的に差別化する。これを繰り返し行う。
  • チームを育てる。中心となる人の立候補を待ち、チームビルディングをきちんと学ぶ。
  • コミュニケーションは意図的にとる場を作る。「大人数⇄少人数」と「質⇄量」の軸でマップを作り、マップの全域がカバーされるように社内イベントを配置する。

本もいただけたので時間を作って読みます。私はヤッホーブルーイングのファンになってしまいました。

ぷしゅ よなよなエールがお世話になります

ぷしゅ よなよなエールがお世話になります

素直な感想

自分のチームはかなりうまくアジャイル開発/スクラム開発できている部類だなと感じました。おそらく中の上か、上の下ぐらい。 ただHunter Industriesの事例など上には上があるので日々実験を繰り返してまだまだよくする余地はあるのだなと思いました。

この点が改善されるともっと良いのに

と思った点です。

  • 持ち帰り荷物が多い
    • 初日のグラス、水・お茶、本、ブースでもらえるノベルティなどカバンのスペースを取るものが結構配布されました。スポンサー企業の方はカバンをノベルティグッズにして配ると受けが良いと思います。
  • 20分の発表枠がきつそう
    • 背景の説明で10分ぐらい使わされている例が多かったです。休憩時間を短くして30分枠にしてもよいのでは?
  • 質疑応答の時間がない
    • 20分枠を20分話すとQ&Aができません。5分ぐらいはQ&Aに時間を割くか、またはフィードバックを貼り付ける紙を壁に用意してもよいのでは?
  • 同時通訳聞きにくい
    • 会場中に英語のスピーチが鳴り響き、レシーバーから日本語が流れてきます。どっちも大きい音で入ってくるので英語が少しでもわかると体が聞こうとしてしまって辛いです。
    • レシーバーをつけないで英語で聞くことにしても隣の人・会場中のレシーバーの音漏れが大きくて結局聞こえてしまうという話も聞きました。同時通訳があるイベントはこういうものなのかもしれませんが、もっといいやり方ないですかね。レシーバーがイヤホンのように音漏れしにくいものに変わるとか。
  • ネットワークパーティーのタイミング
    • 「初日に仲良くなってイベント盛り上がろうね」だと思うのですが、初めて参加する人にとっては初日は仲良くなるきっかけが少なく、「旧知の人が飲み食いする場」になってしまっている気がしました。
    • ワークショップ・OSTなど深く対話ができた後だとまた違ったパーティーが開けるんじゃないかなと思いました。
  • 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

見た目のインパクトが強すぎて、中身が正しいのかは全く終えていません。 下記のような批判記事もあるので、見た目の面白さはあるけど実用的なものではないと思います。

medium.com

Open Practice Library

・・・の前に、Outcome Deliveryフレームワークの紹介

「どう作るのか」だけでなく「なぜ作るのか」、「作った結果、何を学びどう方向転換するのか」を含めてぐるぐると考えを深めていきましょうという思考のフレームワークです。トヨタの「なぜなぜ5回」に似ていると思いました。

思考を深める流れはメビウスの輪の形になっており、3つの領域に別れています。

f:id:tune:20190109214512p:plain

  1. Discovery Loop : なぜ作るのか、誰のためなのかを考える
  2. Options Pivot : 1, 3を踏まえ、どのような選択肢があり、どれを採用するかを考える
  3. Delivery Loop : 実装・提供を行う

Outcome Deliveryでは各フェーズごとにあったアプローチをまとめたカードがあり、その中から適切なものを選択して使うそうです。

興味がある方は下記を参照されると良いと思います。

www.attractor.co.jp

改めて "Open Practice Library"

上記フレームワークを使ってアジャイル開発のプラクティスをまとめたものです。Redhatが自分たちのためにまとめたものをOSSの精神で公開していると公演で聞きました。Googleで検索しにくそうなサイト名なのが日本では知られていない要因かもしれません。

openpracticelibrary.com

サイトを見るとこんな形で分類されていました。

  1. Discovery Loop
  2. Options Pivot
  3. Delivery Loop
    • スプリントプランニング
    • デイリースクラム
    • レトロスペクティブ・ふりかえり
    • ...

あまり知られてなさそうなものもあるので時間を見つけて見てみると良いと思います。

プロダクトバックログリファインメントに関する10の改善案(10 Experiments With Product Backlog Refinement)

はじめに

medium.com

昨年公開されたブログ記事で、プロダクトバックログリファインメントをより良くするために行なった10の施策が面白かったので紹介します。 「10の改善案」とありますが、続きものもあるのでアイデアとしてはもう少し少ないです。

10の改善案

1. 「ストーリーが着手できる状態」についてチームと合意する (Agree a Definition of Ready with the team)

「スプリントの始まりにプロダクトバックログの先頭にあるものが着手するものだ」ではなく、着手できる条件を明確に決めておき、着手できないのであれば時間を作って事前にもう少し詳細化しておきましょうねというものです。

「ストーリーが着手できる状態」は「1. リファインメントができる状態」と「2. ストーリーが着手できる状態」に分けて考えないといけません。

定義すると、例えば以下のような感じでしょうか?

  1. リファインメントができる状態
  2. なぜ実装するのか、誰にとっての機能なのかなどが明確になっている。
  3. どういうUI/UXにするか、どういう設計にするか、作業見積もりができる程度まで明確になっている。
  4. ストーリーが着手できる状態
  5. チームがストーリーをタスクに分解できるだけの情報が備わっている。
  6. どういう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)

安定して成果を提供できるようにするには事前の準備が欠かせませんが、スケジュールがタイトだったりするととにかく実装しろというプレッシャーをかけてしまいがちなのでやめましょう。

おわりに

原文では導入した詳細な背景、おすすめ度なども言及されています。 興味がある方はぜひとも参照下さい。

CourseraはいかにしてGoogleやFacebookに対抗して才能ある人材を採用しているか

firstround.com

John Ciancutti氏による最高の人材を採用するやり方を紹介した記事の私的まとめです。

はじめに:採用活動の"おわり"を意識する

採用活動の最初期から候補者とのやり取りの間中ずっと、採用活動の”おわり”を常に意識して動く。

候補者もまた、採用責任者・面接するチーム・会社と行うあらゆるやり取りにおいて、働きたい会社であるか評価をしていることを知るべきである。

採用のいかなる段階であっても(コーヒーを飲んでいる間や、インタビューの途中であっても)、不適切でないと明らかになった場合はそこで採用活動を中断する。 信じられないかもしれませんが、上記の対応をとってもCiancutti氏は、候補者と関係を維持できている。候補者はあなたが彼らの時間をムダにしないことを尊重してくれる。

第1段階 : Sourcings

スタートアップが候補者を探すときは外科医のように振舞うべき。 どのような役割を期待しているのか、どのようなスキルが必要なのか、どのような企業がそのスキルを多く保有しているのか、そこでの最高の人材は誰かといったことを考える。

採用活動は見知らぬ人とたくさん会う大変な作業ではない。「あなたが一緒に働くかもしれない、才能ある人材とたくさん会う」のである。 採用責任者がコミュニケーションを始めるきっかけをたくさん作るべき。イベントで話しかける、メールを送る、友人を紹介してもらうなど。 たくさんの人に会いコミュニケーションをとることで、会社のアピールポイントや求める役割についてより深く理解し、勘所がわかるようになる。

候補者を見つけたらメールでコンタクトを取る。 共通の知り合いを引用するなどしたうえで、たくさんの人の中から選ばれた候補者に興味を持っていることが伝わるように書くこと。 採用責任者であるあなたのこと、会社のこと、なぜ相手が探している人材と考えているかの背景を説明する。 メールの最後は具体的な次の行動の約束を促す。たとえばチャットでより詳しく説明する、電話で話す、コーヒーを飲みに行くなどである。

メールが返ってくればまずは良い。 OKをもらえなくても返事がくれば改善点を見いだすことができる。 今は職場に満足していて断られるかもしれないが、違う人を紹介してもらえるかもしれない。 返答率を観測するべき。返答が悪ければやり方を再考する。

OKをもらえたらスクリーニングに入る。 候補者のモチベーションを観測することがスクリーニングでの目的。 相手もこちらを評価しているので、コミュニケーション応答は迅速に取る。もし合わないなと思ったらそう伝えることも早く行う。

相手と話す機会ができたら自分の紹介、会社の紹介を手短に行い、そのあとに相手の背景を探り始める。 相手が自己紹介で何を話すか、何に興味を持っているか、何に気をかけているかなど話すことに注意を傾ける。 話す内容だけでなく、声のトーンにも気を配る。

スクリーニングの最後には現在の仕事のことを聞く。 誰と働き、何が面白く、会社にとってどんな意義があって、なぜそれを始めることにしたのか。この時に「それは自分の仕事ではない」といった回答があればそれは悪い兆候である。 情熱を持ち、今の仕事のすべてを知りたがるような人を雇うべきである。

第2段階 : Coffee

スクリーニングの次はインタビューではなく、コーヒーを飲む機会を設定する。 カジュアルな雰囲気で互いを知る機会を作るためである。 迅速に設定し、時間に遅れず、共通の趣味・共通の知り合い・興味など話題の準備をしておく。これは候補者にあなたのことを好きになってもらうように尽くすためである。

コーヒーを飲みながら相手のキャリアを聞き、相手のモチベーション、過去の決断から何を学んできたかを知る。 コーヒーを飲む別の主要な目的は相手を次のインタビューに連れ出すことである。 もしコーヒーの後でインタビューを断られたのであれば何かまずいことをしたに違いない。

第3段階 : Interviewing

候補者がインタビューにきた時は、採用責任者が最初に会う。 候補者をリラックスさせ、このあとどのようなやり取りがあるかを教える。 誰に会うか、どんなことを話すかなど。採用責任者が候補者の味方であると思わせる。

インタビューの内容・構成はマネージャーの責任で決める。 Courseraの場合は下記の通り。

  1. コーディングテスト:90分間で解く問題を与え、回答を確認し、どのようなことを考えていたのかを確認する。
  2. 文化についてのインタビュー:採用責任者以外の誰かに、会社にフィットするかを評価してもらう。
  3. 1と異なる技術インタビュー:アルゴリズム系か、業務に関するもの。
  4. 最後のインタビュー:フィットするかに関して。ただし最後はリーダーシップを見る。過去直面した問題にどう取り組み、解決してきたかを聞く。

インタビューが終わったらインタビューアーから評価を集める。できるだけ記憶がフレッシュなその日のうちがよい。

インタビューが終わったら、採用責任者は候補者に再度会う。これはインタビューのためではなく、ケアのためである。 候補者はインタビューで疲れ、神経質になっており、会話をすることで元気付け、あなたといることに居心地が良いと思わせる。 ケアを行う以外の効果として、候補者の考えていることを知ることができる。他に選考をうけているのはどこか、その会社の何に興味を持ったのかなど。

「1年後に雇用主となる可能性はどれくらいあるか」は常に聞くこと。 現在の仕事・他にあるオファーなどを含めて自社の提案がどの程度の価値があるのかを推し量ることができる。 また彼らが現在いくら報酬をもらっていて、他からオファーをもらっているかを確認する。 多くの人は進んで話したがらないと感じるかもしれないが、Courseraでは85%以上の候補者が詳細を話してくれた。 これにより、採用責任者と会社は、現在の採用市場の状況がよりわかるようになる。

他の候補者のインタビューが終わったら採用責任者に最終決定をさせる。

第4段階 : The Close

インタビューを行った日に採用する確信が得られれば、次の日をクロージングにあてる。

最悪のケースはミスマッチで終わることである。 他企業に行くことがベストな解であっても送り出してやり、今後も連絡を取り合いたいと伝える。

もしあなたの会社で働くことがベストだと信じるのであれば諦めないこと。 あなたがなぜ今の会社で働き、情熱的であるかを話すことがこの段階ではオススメ。

候補者が心を決める要因の1つは報酬である。 オファーの詳細を記したスプレッドシートを正確に記入し、将来見込みを踏まえた報酬の計算式を設定し、彼らにシミュレーションさせ考えさせる。 同じスプレッドシートに知る限りの競争相手の情報も載せる。 彼らのため多くの足がかりを用意したこと、そして「彼ら自身のために」最善の決断をさせたいことを伝えることができる。

オファー後でも候補者を引きつけたいならば、候補者が会った人たちにコーヒーやランチを1対1でとる機会を作るように奨励する。 しかし数日から1週間の期限を設ける。

採用に失敗したとしても、もっとも重要なことは失敗の原因を理解することである。 大人の態度をとり、今後も彼らと連絡をとりたい希望を伝えることを忘れないこと。 彼らは他の優れた候補者を知っているかもしれない。 1年後、1年半後に再び興味を持ってくれるかもしれない。

おわりに:結果を振り返る

採用において間違ってもよい。優れた採用責任者でも30%は間違えることがある。 どこに問題があって、すぐに修正できるならば問題はない。