最低なスクラムマスターの言動集
スクラムマスターとして不適切な言動をテンポよくまとめた動画です。
- それはこのスクラムイベントで話すことではない。
- 今日の振り返りでは開発を改善する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)
安定して成果を提供できるようにするには事前の準備が欠かせませんが、スケジュールがタイトだったりするととにかく実装しろというプレッシャーをかけてしまいがちなのでやめましょう。
おわりに
原文では導入した詳細な背景、おすすめ度なども言及されています。 興味がある方はぜひとも参照下さい。
CourseraはいかにしてGoogleやFacebookに対抗して才能ある人材を採用しているか
John Ciancutti氏による最高の人材を採用するやり方を紹介した記事の私的まとめです。
はじめに：採用活動の"おわり"を意識する
採用活動の最初期から候補者とのやり取りの間中ずっと、採用活動の”おわり”を常に意識して動く。
候補者もまた、採用責任者・面接するチーム・会社と行うあらゆるやり取りにおいて、働きたい会社であるか評価をしていることを知るべきである。
採用のいかなる段階であっても（コーヒーを飲んでいる間や、インタビューの途中であっても）、不適切でないと明らかになった場合はそこで採用活動を中断する。 信じられないかもしれませんが、上記の対応をとってもCiancutti氏は、候補者と関係を維持できている。候補者はあなたが彼らの時間をムダにしないことを尊重してくれる。
第1段階 : Sourcings
スタートアップが候補者を探すときは外科医のように振舞うべき。 どのような役割を期待しているのか、どのようなスキルが必要なのか、どのような企業がそのスキルを多く保有しているのか、そこでの最高の人材は誰かといったことを考える。
採用活動は見知らぬ人とたくさん会う大変な作業ではない。「あなたが一緒に働くかもしれない、才能ある人材とたくさん会う」のである。 採用責任者がコミュニケーションを始めるきっかけをたくさん作るべき。イベントで話しかける、メールを送る、友人を紹介してもらうなど。 たくさんの人に会いコミュニケーションをとることで、会社のアピールポイントや求める役割についてより深く理解し、勘所がわかるようになる。
候補者を見つけたらメールでコンタクトを取る。 共通の知り合いを引用するなどしたうえで、たくさんの人の中から選ばれた候補者に興味を持っていることが伝わるように書くこと。 採用責任者であるあなたのこと、会社のこと、なぜ相手が探している人材と考えているかの背景を説明する。 メールの最後は具体的な次の行動の約束を促す。たとえばチャットでより詳しく説明する、電話で話す、コーヒーを飲みに行くなどである。
メールが返ってくればまずは良い。 OKをもらえなくても返事がくれば改善点を見いだすことができる。 今は職場に満足していて断られるかもしれないが、違う人を紹介してもらえるかもしれない。 返答率を観測するべき。返答が悪ければやり方を再考する。
OKをもらえたらスクリーニングに入る。 候補者のモチベーションを観測することがスクリーニングでの目的。 相手もこちらを評価しているので、コミュニケーション応答は迅速に取る。もし合わないなと思ったらそう伝えることも早く行う。
相手と話す機会ができたら自分の紹介、会社の紹介を手短に行い、そのあとに相手の背景を探り始める。 相手が自己紹介で何を話すか、何に興味を持っているか、何に気をかけているかなど話すことに注意を傾ける。 話す内容だけでなく、声のトーンにも気を配る。
スクリーニングの最後には現在の仕事のことを聞く。 誰と働き、何が面白く、会社にとってどんな意義があって、なぜそれを始めることにしたのか。この時に「それは自分の仕事ではない」といった回答があればそれは悪い兆候である。 情熱を持ち、今の仕事のすべてを知りたがるような人を雇うべきである。
第2段階 : Coffee
スクリーニングの次はインタビューではなく、コーヒーを飲む機会を設定する。 カジュアルな雰囲気で互いを知る機会を作るためである。 迅速に設定し、時間に遅れず、共通の趣味・共通の知り合い・興味など話題の準備をしておく。これは候補者にあなたのことを好きになってもらうように尽くすためである。
コーヒーを飲みながら相手のキャリアを聞き、相手のモチベーション、過去の決断から何を学んできたかを知る。 コーヒーを飲む別の主要な目的は相手を次のインタビューに連れ出すことである。 もしコーヒーの後でインタビューを断られたのであれば何かまずいことをしたに違いない。
第3段階 : Interviewing
候補者がインタビューにきた時は、採用責任者が最初に会う。 候補者をリラックスさせ、このあとどのようなやり取りがあるかを教える。 誰に会うか、どんなことを話すかなど。採用責任者が候補者の味方であると思わせる。
インタビューの内容・構成はマネージャーの責任で決める。 Courseraの場合は下記の通り。
- コーディングテスト:90分間で解く問題を与え、回答を確認し、どのようなことを考えていたのかを確認する。
- 文化についてのインタビュー:採用責任者以外の誰かに、会社にフィットするかを評価してもらう。
- 1と異なる技術インタビュー:アルゴリズム系か、業務に関するもの。
- 最後のインタビュー:フィットするかに関して。ただし最後はリーダーシップを見る。過去直面した問題にどう取り組み、解決してきたかを聞く。
インタビューが終わったらインタビューアーから評価を集める。できるだけ記憶がフレッシュなその日のうちがよい。
インタビューが終わったら、採用責任者は候補者に再度会う。これはインタビューのためではなく、ケアのためである。 候補者はインタビューで疲れ、神経質になっており、会話をすることで元気付け、あなたといることに居心地が良いと思わせる。 ケアを行う以外の効果として、候補者の考えていることを知ることができる。他に選考をうけているのはどこか、その会社の何に興味を持ったのかなど。
「1年後に雇用主となる可能性はどれくらいあるか」は常に聞くこと。 現在の仕事・他にあるオファーなどを含めて自社の提案がどの程度の価値があるのかを推し量ることができる。 また彼らが現在いくら報酬をもらっていて、他からオファーをもらっているかを確認する。 多くの人は進んで話したがらないと感じるかもしれないが、Courseraでは85%以上の候補者が詳細を話してくれた。 これにより、採用責任者と会社は、現在の採用市場の状況がよりわかるようになる。
他の候補者のインタビューが終わったら採用責任者に最終決定をさせる。
第4段階 : The Close
インタビューを行った日に採用する確信が得られれば、次の日をクロージングにあてる。
最悪のケースはミスマッチで終わることである。 他企業に行くことがベストな解であっても送り出してやり、今後も連絡を取り合いたいと伝える。
もしあなたの会社で働くことがベストだと信じるのであれば諦めないこと。 あなたがなぜ今の会社で働き、情熱的であるかを話すことがこの段階ではオススメ。
候補者が心を決める要因の1つは報酬である。 オファーの詳細を記したスプレッドシートを正確に記入し、将来見込みを踏まえた報酬の計算式を設定し、彼らにシミュレーションさせ考えさせる。 同じスプレッドシートに知る限りの競争相手の情報も載せる。 彼らのため多くの足がかりを用意したこと、そして「彼ら自身のために」最善の決断をさせたいことを伝えることができる。
オファー後でも候補者を引きつけたいならば、候補者が会った人たちにコーヒーやランチを1対1でとる機会を作るように奨励する。 しかし数日から1週間の期限を設ける。
採用に失敗したとしても、もっとも重要なことは失敗の原因を理解することである。 大人の態度をとり、今後も彼らと連絡をとりたい希望を伝えることを忘れないこと。 彼らは他の優れた候補者を知っているかもしれない。 1年後、1年半後に再び興味を持ってくれるかもしれない。
おわりに：結果を振り返る
採用において間違ってもよい。優れた採用責任者でも30%は間違えることがある。 どこに問題があって、すぐに修正できるならば問題はない。
エンジニアリング組織論への招待 の私的まとめ
昨年読み「経験から感じていたことが、言語化されてまとまっている素晴らしい書籍だ！」と感じました。 が、「具体的に何を学んだか？」と聞かれると今ひとつ心もとない状態だったので、自分の言葉でまとめ直してみました。
コミュニケーション能力と不確実性
コミュニケーション能力とは「コミュニケーションの不確実性」を減少させ、「組織内で連続的に発生してしまう不確実性の負のループを止めることができる」力を指す。
不確実性の発生源は2つ、「未来(環境不確実性)」と「他人(通信不確実性)」である。 通信不確実性はさらに下記の3種に分けることができる。
- 他者理解の不確実性：他人や事象を完全には理解できない。
- 伝達の不確実性：コミュニケーションが意図通り相手に伝わるとは限らない。
- 成果の不確実性：仮に意図通り理解されたとして、発信者の予想通りに行動するとは限らない
上記を念頭に置いた上で、少しでも不確実性を減らそうとすることによって物事を前に進めることができる。 しかし現実では、人は不確実性に向き合うことに不安を覚え、向き合うことを避けてしまうことから様々な問題を引き起こしてしまう。
エンジニアがソフトウェア・製品に向き合うように、人・チーム・組織に向き合い、「どうしたら効率よく不確実性を減らしていけるか」を考えつづけることで優れたチーム・組織を作ることができる。
組織は何らかの曖昧な指示を入力とし、具体的な作業に置き換えて少しずつ完了させていくことで、プロジェクト・プロダクトを前に進める活動を断続的に行なっているといえる。組織形態は下記の2つに大別することができる。
- マイクロマネジメント組織：具体的で細かい指示を指示者が出し、指示を受けたものがその通りに実行する組織。
- 自己組織化された組織：抽象的で自由度のある指示を指示者が出し、指示を受けたものが考えて行動する組織。
マイクロマネジメント組織の能力は指示者に律速されてしまう。 指示者の不在で仕事が回らなくなり、指示を受ける人が増えるにつれ指示者の負荷が高まり、指示を受ける側では不確実性を大して減らすことができない。 従って不確実性を効率よく減らしていける組織を目指すのであれば自己組織化された組織となる必要がある。
またコミュニケーションの不確実性を効率よく減らしていくには下記に留意する必要がある。
- 論理的思考の盲点
- 経験主義と仮説思考
- システム思考
「論理的思考の盲点」とは、人は論理的に考えていると自分で思っていても、その時の感情や誤った仮定に影響されて論理的でなくなることがあることを指す。 自分の認知がどういう時に歪むのかを把握し、客観視することでネガティブな感情の拡大再生産を食い止める。
「経験主義と仮説思考」は「行動することで「経験=情報」を得る。結果を観察し、結果を踏まえて問題解決を行う。部分的な情報しか得られないかもしれないが、全体像を想定し問題解決を進める。」という考え方である。 経験主義ではコントロールできるものを操作し、観測できるものの結果を見ることで前に進まなければならない。 面白いことに人は不安を感じると他社の気持ちなどコントロールできないものをコントロールしようとする。
「システム思考」は要素同士の関係性に注目して問題の構造を解き明かす考え方である。
メンタリング
メンタリングとは対話を通してメンターの思考力を相手(メンティ)へ一時的に貸し出し、相手の歪んだ認知を補正し、次の行動を明確にし、成長を促す手法である。 メンタリング後は「高い目標」が明確になり、その目標と今の自分の行動・習慣がどのように繋がっているかが明確にイメージでき、そのために何をすればよいかが明確になっている状態を目指す。
メンタリングに似た手法にティーチングがあるが、これは他者による説得である。 人は自分で見つけた答えに対して高い納得感と自己効力感を得て、積極的な解決行動を取ることが期待できる。 そのためメンタリングではメンティに自分自身の問題だと自覚させる。
メンタリングでは下記の3つを実施する。
- 傾聴
- 可視化
- リフレーミング
まずは相手の話を「傾聴」し、相手が今の状態になった理由を理解する。 傾聴で必要なのは「同感」ではなく「共感」である。
次に相手が問題を客観視できない状態を可視化してあげて、「問題と私たち」に構造を変える。 相手が問題を客観視できない状態にあることは下記のキーワードに着目することで気がつくことができる。
- こちら系：この会社は…この人は…、一体感を持っていない時に出てくる。
- あちら系：あの部署は…あの人は…、相手は自分と違う、線引きされた異なる存在として認識している。
- 極端系：いつも…すべて…絶対に…、ゼロイチで物事を捉えている。間の状態が認識できていない。
- すべき系：普通…〜すべき、〇〇でないとならないという考え方が頭にあり、そこに限定して考えている。
- 決めつけ系：どうせ…、感情的になっている。事実を捉えられていない。
相手の問題を一足飛びに解決することはできない。バグの原因を切り分けするように、話を聞きながら少しずつ問題の範囲を再定義(リフレーミング)して限定していくとよい。
メンターの役割はメンティを自律的な問題解決に導くことであり、メンティの問題を解決することではない。
メンタリングでは次に取るべき行動がはっきりするようにする。下記を参考に行動を設定すると良い。
- Specific : 具体的である
- Measurable : 測定可能である
- Achievable : 達成可能である
- Related : メンティの課題と行動が関連している。
- Time-Bound : 時間制限がある。いつまでにやるかが明確になっている。
プロダクト開発とアジャイルな状態
プロジェクトとプロダクトは似た文脈で使われることが多いが、目的が異なる。 プロジェクトは「始まり」と「終わり」があり、「成果を出して終了する」ことが目的である。 最大のリスクは「終了しないこと」であるため、スケジュールに対する不確実性を減少させるように取り組む。 プロダクトは「継続的に収益をあげ」、「終了しないこと」が目的となる。 最大のリスクは「終了してしまうこと」であるため、市場に対する不確実性を減少させるように取り組む。
ソフトウェア開発の前提が変化し、プロジェクト型開発からプロダクト型開発への変化が迫られている。 ウォーターフォールはどう作るか(方法不確実性)と何を作るか(目的不確実性)の削減を目的としていた。 アジャイルはさらにチームが同じゴールに向かって動けているか(通信不確実性)の削減を目的としてる。 アジャイル開発は従来の開発よりも広いスコープを対象として、開発チームを捉え直す動きと言える。
アジャイルとは「チームが環境に適応して、不確実性を最も効率よく削減できている状態」のことである。自己組織化とも呼ばれる。自己組織化は下記が達成されているかを指標に判断することができる。
- 情報の非対称性が小さい
- 認知の歪みが少ない
- チームより小さい限定合理性が働かない
- 対人リスクを取れていて、心理的安全性が高い
- 課題・不安に向き合い、不確実性の削減が効率よくできる
- チーム全体のゴール認識レベルが高い
アジャイルな開発では下記に取り組んでいる。
- 不安に向き合う
- 少人数の対話を重視する
- 役割を分けない
- 経験したことのみを知識に変える。
- 意思決定を遅延する
- 価値の流れを最適化する
アジャイル開発のフレームワークで定義されているプラクティスは実行さえすれば問題が解決するものではない。 チームの背景・コンテキストが異なっても有効な銀の弾丸は無く、自分たちのやり方や役割を見直し変えていく「脱構築」機能をチームが身につけられるようになることを要求している。
スケジュールマネジメント
スケジュールマネジメントは、いかに効率よく「スケジュールに対する不安」とその発生源である「方法不確実性」を削減するかを考えることである。 具体的にはスケジュール通り終わるか、少し伸びてしまうかの間の幅をどのようにして見える化し、効率よく削減できるのかを考え、経営と現場の間で進捗に関して透明性を保つことを継続的に行う。
以下の3つに注目して進めると良い。
- 制約スラックを削減する。
- 見積もり予測可能性を上げる。
- プロジェクトバッファの消費を可視化し改善する
「制約スラック」とは作業に順番があったり、特定のスキルを持つ人に依存している状態を指す。 これらを削減し、作業に取り組むにあたっての制約を取り除く。
見積もり予測を上げる方法はいくつかある。 不確定性の大きいタスクは分解する。初めての取り組みであれば概念検証をプロトタイピングで行い、あたり検討をつける。 絶対見積もりにするとノルマ・約束になってしまうため、相対的に規模を見積もるようにする。 また小さくスプリントを繰り返すのも良い。開発サイクルを決め、人員を固定し、制約スラックが発生しにくいように要件を切っていくことで再現性の高い開発ができるようになる。
最後にバッファは作業・タスクごとに個別に取るのではなく、全体でまとめて1つのバッファを持つようにする。 これによりスケジュール不確実性の削減をプロジェクトバッファの消費という形で見える化できる。
ユーザーストーリーは「どのような人が」「何ができる」「そのことでどのような感情になる」の3点で構成する。 誰が、何のためにという文脈を最終顧客の観点から記述することで思い込みを排除する。
開発に着手できる状態になっているかを判断するフレームワークにINVESTがある。
- Independent：独立している。他のストーリーと依存関係がない。
- Negotiable：交渉できる。実現可能方法について交渉の余地がある。
- Valuable：価値がある。ストーリーを完了させることでユーザに価値を届けることができる。
- Estimable：見積もりできる。ストーリー完了までに必要な作業、要する時間が見積もれるだけの情報がある。
- Small：小さい(≒適切な大きさである)。固定期間のスプリント内で回していくのにちょうど良い。
- Testable：検証可能である。ストーリーが完了したことを客観的に判断できる。
生産性を出すための組織編成
生産性の定義は「投入したリソースに対してどれだけの付加価値を得られたのかを測ったもの」である。 問題は個人の能力の総和が必ずしも組織全体の能力とはならない点である。 組織がメンバの能力を完全に引き出すためには、「1.その中で行われるコミュニケーションが100%の完全な情報伝達である」、「2.構成員が完全に同一の目的・思惑で動いている」必要がある。現実にはどちらも前提条件として成り立たない。 従って組織拡大を行う際は、誰が、誰と、どんなコミュニケーションを、どの頻度でとるようにするかという設計を行い、コミュニケーションコストを一定に保つように組織を分割していく必要がある。
具体的には下記に留意する必要がある。
- 権限の委譲と期待値調整
- 適切な組織・コミュニケーション・外部リソース調達の設計
- 全体感のあるゴール設定と透明性の確保
- 技術的負債の見える化
メンバを職能で組織を分けると組織間でのコミュニケーション・取引コストを増大させてしまう。 ある事業やプロダクトに対して、職能・職種を横断してチームを組成することで、コミュニケーション・取引コストをできる限り下げたチームを作ることができる。書籍では機能横断型のチームと呼んでいるが、アジャイル開発の分野では「クロスファンクショナルチーム」や「フィーチャーチーム」と呼ばれていることが多い。
複数のチーム・チームメンバを一つのゴールに導くには目標設定と管理が欠かせない。 旧来の組織で広く使われている目標管理(MBO:Management By Objectives)は本来、「目標による管理、およびセルフコントロール」であり、自ら立てた目標を達成していくことによるモチベーションの内的動機付けを重視していた。 しかしいつの間にか後者が抜け落ちてノルマ感だけが残ってしまった。
組織全体への理解がなければ誤った最適化が進んでしまうため、近年ではOKR(Objectives and Key Results)が広がっている。 OKRの重要なポイントは透明性の重視にある。目標設定を通じて、従業員一人一人が組織全体を見渡して、自分が何のために仕事をしているのかを深く理解するのがOKRの果たす重要な役割である。
感想
まとめた結果でも1章の分量が多く、不確実性の考え方が一番学んだことなのだなと思う。2章以降はマネジメントに関する知識が広範に網羅されているが、どこかで聞いた話も多く、単独で理解を深めるには少し足りないし、他資料へのポインタとするには引きにくい印象を持った。
マネジメントに関わる人には読んで欲しいが、開発者などに紹介するにはまとめた内容+他書籍へのポインタとするのが良さそう。
