tuneの日記

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

エンジニアリングマネージャーとしてどんなことをしているのか?

はじめに

今流行りの Meetyを使って社外の方とお話しする機会を作っているのですが、「エンジニアリングマネージャーとしてどんなことをしているのですか?」という質問を何度かいただいたので、自分の整理のためにも日々の具体的な行動・活動をまとめてみます。

私はRetty株式会社toC Web開発/toB Web開発 両方をみているエンジニアリングマネージャーであり、この記事を書いた2021年9月時点では20名弱のマネジメントを務めています。エンジニアリングマネージャーとなってからは2年が経ちました。

エンジニアリングマネージャーとは?

いろんな議論・定義がありますが、Engineering Managerは何をする人なのかが網羅されていると思います。個人的には「エンジニアリングのマネジメント」であり、開発で生じる様々な問題を監督し、組織が期待する開発力を用意することが一番の役割だと考えています。開発力は分解すると"プロダクトを生み出す力"、"デリバリーのスピード"、"プロダクト品質"など様々な側面があると思いますが、その時々で組織の弱いところを補うように動かざるをえないことが多い結果、各社・各自でエンジニアリングマネージャーの役割の差が生じているのかと考えます。

いくつかの軸でまとめるにあたりラクスルVPoEの高橋さんがまとめた下記資料を思い出しました。この中でも"やってるもの"と、"やってないもの"と、"書かれてないけどやっているもの"があり、本当に領域が広いのだなと改めて感じました。

メンバーのサポート・育成・評価

メンバーの状態観察

週1回〜隔週1回のペースで1on1を1回30分行っています。社内の他部門や他社の話を伺うに、開催頻度は多いようです。 結構な時間が1on1で割かれてしまいますが、問題の芽が小さいうちに拾えることが多く、実施は大変ですがこのペースでやっています。

1on1は相手のための時間とし、何を話すかは基本相手に委ねています。 入社以来使っている1on1テンプレートには先頭に目的が記載してあり、短くまとまっていてとても気に入っています。

[1on1について]
- 1on1される側のための時間であって、進捗確認や伝達命令のためのものではない
- 問題解決ではなく、課題発見をするためのもの
    - 解決は自分で考えて自主的に行っていってほしいです
    - 解決のための相談、アドバイス等の協力は積極的に行います
- お互いの期待値のすり合わせとFBの場

[Topics テンプレート]
- 目標達成の上でもやもやしていること、困っていること
- 業務上での気付き(前回から今回までで学んだこと、うまくいったこと、いかなかったこと)
- チームがもっと良くなるためのアイデア、改善点
- MGR/EM/ボードメンバーへのリクエスト
- プライベートについて(家族や自分の病気、イベントなど仕事に影響があることがあれば。結婚、出産、介護等)
- 将来のキャリアについて(変更や悩みがあれば)

目標設定・人事評価

会社の仕組みとして「3ヶ月単位で目標を建て、評価を行うMBO(Management By Objectives)」を採用しているため、それを実施しています。

プロダクト開発はスクラムで進めていますが、"チームで開発する"・"優先順位に従って開発する”・"やることは適宜見直す"というスクラムの性質から、やりきり目標や個人ごとの開発項目を建てると都度見直しが発生して運用が大変です。そこで組織目標・個人目標・個人課題に分けて設定しています。

  1. 組織目標(部門目標)
    • 複数チームで共通
    • 3ヶ月毎に見直す、大きくは変わらない
  2. 個人目標
    • 全員ほぼ共通、公開する
    • 3ヶ月毎に見直す、あまり変わらない
  3. 個人課題
    • 個人ごとに固有、非公開
    • 業務グレードが変わらない限り変わらない

目標の難易度設定が難しかったり、評価の時期と成果が出る時期がずれたり、評価の時期は毎回悩み事が発生しますが、マネージャーとして重要な職務だと考えて丁寧に説明することを心がけています。

評価の話は2020年のスクラムフェス大阪でも話をしました。

dev.classmethod.jp

後進の育成

新卒1〜3年目くらいのジュニアエンジニアは1on1を通じて成長を阻害している要因を突き止め、アドバイスをしています。 成長曲線や壁を乗り越えるタイミングは人によって異なるため、取り組み姿勢が間違っていなければ焦らず目の前のタスクに取り組むよう話すことが多いです。

中堅・シニアエンジニアになると、複数の人を巻き込んで大きい成果を出してもらいたいことが増えるため、大きな開発の取りまとめや推進役をお願いしたり、ジュニアエンジニアのメンターを依頼したりします。役割の数がどうしても少ないため、機会提供が偏ることが無いよう、乗り換えられそうなちょうど良い難易度になるよう、3ヶ月〜半年ぐらい前から考えることが多いです。

マネージャーの育成は最も時間がかかります。開発とマネジメントは求められるスキルや振る舞いが異なるため、開発タスクを減らし、マネージャーとしての振る舞いを考え・学ぶための余裕を意図的に作ってあげる必要があります。 自分が抱えている問題を移譲して代わりに解決に取り組んでもらったり、実際に起きてしまった問題を題材として「今から戻ってやり直せるならどうしたら良いか」を議論するなど、時間をかけて考え方やアプローチを伝えています。

日常の労務管理

いわゆる勤怠管理ですが、忙しさの山や谷を作らず、一定のペースで働けるように業務量を気をつけて見ています。 より具体的には残業が常態化していないか、残業が一時的に増えた場合はそれが開発の山場として妥当なものかをチェックしています。

開発

プロダクトマネジメント

企画に責任を持つプロダクト部門が別途あり、施策や方針決めは基本委ねています。 アイデアや機能提案をすることはありますが、それよりも技術負債やセキュリティ問題などエンジニアでないと判断がつかないものについて開発優先順位の強めの提言をすることが多いです。

開発タスクを分解したり、メンバーにアサインすることは基本していません。 プロダクトオーナーにより優先順位で並べられたプロダクトバックログを、開発チームが毎週開発できると考える分だけとっていきます。 自分は四半期・半年・2〜3年といったスパンで、"何をやっていきたいか"を社内のいろいろな立場の人から聞き、どう実現していくのが良さそうかを考えることが多いです。

エンジニアリングのリーダーシップ

機能追加や不具合修正関して、プロダクトコードを直接書くことはしていません。 技術採用や開発方針の決定、細かな設計も開発チームに委ねています。

開発への関与としては、チームが将来取り組むであろうふわっとした課題を先に調査しておくことを手が空いた時にしています。 また現場では決められないような「決めの問題」が生じた時に、開発責任者として意思決定したりしますが極めて稀です。 障害・インシデントが発生したときはその影響範囲の大きさによって、対応の陣頭指揮をとったりします。

開発を広く見てはいますが、自身の役割は技術でプロダクトを引っ張ることを期待されるテックリードとは異なるもので、エンジニアリングマネージャーのキャリアの先にCTOがあるとも考えていません。

採用・採用広報・アドバイザーの招聘

上位の目的としては「今の開発体制で足りない人を連れてくる」だと考えています。

採用

採用チームと定例を持ちながら、採用活動に広く協力をしています。 スカウトのフィルタリング、スカウト文面の送信、カジュアル面談の実施、コーディング試験の評価、技術面接など。

またインターンコンテンツを考えたり、採用イベントを準備したりします。 ここ半年だと下記のイベントに携わりました。

採用広報

勉強会の開催、カンファレンス登壇、テックブログ執筆などの活動です。 自分自身の知名度を上げキャリア形成をやりやすくする目的もありますが、組織としても採用活動に遅れて効果が出てくると考えています。 直近だとスクラムフェス三河に会社から5件のプロポーザルをだし全て通過、Go Conference Autumnに会社から7件のプロポーザルを出すことができました。 ノルマや金銭的なメリットを設定しているわけではないため、普段の業務で学んだことを対外的にアウトプットし、学びにつなげるメリットを広く組織に浸透できているのだと思っています。

また定期的に対外アウトプットをしておくと、一定期間の自分の活動をまとめるきっかけになるだけでなく、「口だけにならない」と言う自分への戒めにもなるなと感じています。

アドバイザーの招聘

自分が詳しくなく組織としても弱い領域、自分ができるけど手が回らない領域で外部の識者の方にアドバイザー・相談役をお願いしています。 どの方にも豊富な経験に基づいた適切なアドバイスをいただけており、組織として悩む時間を減らせたり、自信を持って取り組む後押しになっています。

社内勉強会での講演や、単発のワークショップももっとやっていけたらなと思っているのですが、開発の状況・予算・開催タイミングなどあり、声はかけながらも開催にいたってないものがいくつもあります。これは私の力不足が大きく、ただ申し訳ないです。

他社との情報交換

エンジニアリングマネージャーとしての打ち手は組織や置かれた状況のコンテキストによって効果があるものもないものもあり、引き出しを増やすことが大事だと考えています。 なので他社の方から相談をいただいた場合は基本的に引き受け、積極的に自分たちの経験を共有しています。 相談を持ち込んだ側は同じ問題で時間を取られることなく、壁を乗り越えた先にあった新しい問題も次回に共有してくれるためどの会社とも学びのある情報交換をさせていただいております。

他にも「自社で起きている問題が一般的なのか、自社固有の問題なのかを切り分ける判断材料になる」「他社の相談を先に受けておくことで、自社で別の相談が出てきた時に相談しやすい」というメリットもあります。

終わりに

会社から与えられた仕事や目標はあるようであまりありません。会社やプロダクトの様子を見ながら社内を広く見渡し、自分で考えて作っています。 直接的な仕事はなく、自分が居なくても開発業務は回ると考えています。 1週間居なくても全く問題ないでしょう。事前に準備しておけば1ヶ月居なくても多分大丈夫だと思います。 ただし3ヶ月居なくなると開発でうまくいかないことが増えてきたとメンバーが感じることが増えるのではないかなと思っています。 エンジニアリングマネージャーとしての貢献はこれぐらい長期で効いてくると考えています。

大変なことが多い、直接的な達成感も得にくいエンジニアリングマネージャーですが、下記が面白さかと考えています。

  • プロダクトの成長 : なんだかんだ方向性に関与できる裁量が大きい。
  • 組織の成長 : 同じメンバーでも雰囲気や成果は異なる。
  • メンバーの成長 : 突然殻を破るような成長を身近で見れるのは嬉しい。

この記事を読んでもっと聞いてみたいと思った方、ディスカッションしたいと思った方、Rettyのエンジニアリングマネージャー職に興味が沸いた方は是非Meetyでお話ししましょう。

meety.net

2021年7〜8月に社内で共有したアジャイル開発関連の記事

社内でアジャイル開発を議論するSlackチャンネル #tech_agile に見かけた良記事のまとめです。この記事は第6弾でトータルで1年間まとめを続けることができました。

ノウハウ・知見

チームで品質を考えるレビュー

speakerdeck.com

プロダクトオーナーとしての成長

わかりやすい。

takaokimura.medium.com

エンジニアが自走する組織の作り方

medium.com

個人が持つタスクに期限を設けてみる

スケジュールにバッファを設けるのは悪か?

不確実性コーンの実例として分かりやすい。

tech.unifa-e.com

体験のデザイン・リーン・アジャイル開発の関係

何が欠けるとどうなるのか説明がわかりやすい。

note.com

アジャイル関連本の年表

app.mural.co

アジリティを支える品質特性

speakerdeck.com

リモートアジャイル開発のノウハウ集

www.agile-studio.jp

片思いマッピング

service.plan-b.co.jp

他社事例

LINE NEWS

エンジニア40人、企画60人でLeSSっぽく作るLINE NEWS

engineering.linecorp.com

HERPのLeSS事例

note.com

LeSSをやめたRepro

octopass.jp

ラクスのLeSS事例

speakerdeck.com

アカツキのLeSS事例@CEDEC

speakerdeck.com

Twitter

PdMは映画監督説

ツールが問題を解決してくれるのは幻想

ふりかえりでファシリテーターが全ての発言にコメントしてしまうあるある

最初にWhyを明確化しろ

プロダクトバックログの優先順位が守られない困りごとの比喩

スプリントレビューは料理の試食会

スクラムマスターは先頭に立つな

その他

Rettyメンバーからのカンファレンスプロポーザルです。話が聞きたいなと思ったらConfengineにログインして「いいね」をお願いします。 採択されなくても、勉強会に声かけいただければ皆喜んで参加すると思われます。

※8/29時点

[スクラムフェス三河]

[スクラムフェス札幌]

[Regional Scrum Gathering Tokyo 2022]

2021年5〜6月に社内で共有したアジャイル開発関連の記事

社内でアジャイル開発を議論するSlackチャンネル #tech_agile に見かけた良記事のまとめです。この記事は第5弾、次回で祝1周年となります。

ノウハウ・知見

リモートのスプリントレビューを盛り上げるコツ

弊社でもレビュー後のZoomブレイクアウトルームを使った議論タイム設けました。簡単で効果高いのでおすすめ。

medium.com

スクラムマスターの資格まとめ

当方無免許です。

yattom.hatenablog.com

初めて入るチームでの立ち回り例

ikikko.hatenablog.com

内製化に取り組む方へのアドバイス

blog.kengo-toda.jp

スクラムとSECIモデルの関係

iucstscui.hatenablog.com

開発スピードを上げたいなら開発スコープを小さくしよう

はい。

medium.com

ロードマップに機能を書くべきではない

note.com

ブロッコリーさんがよくシェアする記事、シチュエーションも添えて

良記事集です。

nihonbuson.hatenadiary.jp

素早く頻繁に失敗しよう

ゾンビスクラムサバイバルガイド

面白そう。

agnozingdays.hatenablog.com

チーミングモデル

固定的なチームが成熟しすぎると、サイロ化が生じて学習や改善がチーム内に閉じ、組織学習を阻害するという考え方。下記のどれもやった記憶あり。

  1. 社会化(Socialization) — 新たなチームメンバを参加させるためにチームが継続的な努力を払う。そのような継続的プラクティスを通じて、新たなチームメンバの受け入れ能力が向上する。
  2. 有糸分裂(Mitosis) — 分裂可能な大きなさまで、チームが成長する。新たに生まれたチームは、すでにその時点から、業務に精通している。
  3. ボランティア消防団(Volunteer Fire Department)チームモデル — 有志メンバが一時的なタスクチームを結成して、主要な問題を解決した後に、元のチームに戻る。
  4. 交換所(Trading Places) — チームが他のチームとの間でメンバを一時的に交換することで、組織全体で学習成果を共有する。

www.infoq.com

仕事中は理想のプログラマーを演じ切るといい振る舞いができると言う話

druby.hatenablog.com

他社事例

ヤフー

デイリースクラム(朝会)でチームが見つけたチーム内の課題を話すのよさそうです。

techblog.yahoo.co.jp

SMS

リリース出来たらご褒美にレゴを組み立てる文化

tech.bm-sms.co.jp

LINE

LINE TODAYでのLeSS事例、LeSS成分は少なめ

www.youtube.com

Chatwork

モブレビューのおすすめ

creators-note.chatwork.com

Scrum@Scaleの取り組み

SmartHR

デザイナーのスクラムへの関わり方で「スプリントレビューでステークホルダーを観察する」というのがあって面白い、確かに。

creatorzine.jp

LeSS開発の話がチラッと。4〜5人/チーム * 5チーム = 20名弱っぽい。

tech.smarthr.jp

スプリントレビューにユーザーを招待した話、すごい!

tech.smarthr.jp

ユーザー要望から機能を開発した場合、要望をくれたユーザーに報告して開発完了となるらしい。素晴らしい。

Mixi / みてね

LeSSをやめた話

[https://atsushisakai.medium.com/%E3%81%BF%E3%81%A6%E3%81%AD%E3%81%AE%E9%96%8B%E7%99%BA%E3%82%B9%E3%82%BF%E3%82%A4%E3% 83%AB%E3%82%92%E5%A4%A7%E3%81%8D%E3%81%8F%E5%A4%89%E3%81%88%E3%81%9F%E8%A9%B1-6e1a206922a6:embed:cite]

Timers

LeSS事例

techblog.timers-inc.com

勉強会・カンファレンス

iCare Dev Meetup

キヤノンメディカルの「あのチーム」の話

www.youtube.com

スクラムフェス大阪

基調講演

qiita.com

サイボウズ天野さんの社会人の基礎としてのアジャイルの背景知識まとめ

家事の話だけど、開発部門が取り組むカイゼンがどういうものかわかりやすいと思い会社の子育てチャンネルに投げた。

世の中いろんなスクラムマスターがいます。

アカツキさんのLeSS事例

ラクスさんのアウトカム指向への転換取り組み。課題感がうちとちょうど同じくらい。

テストを書く前に考えるテストの話

トヨタ主査制度の最初の1人の話

スクラムフェス札幌

残念ながらオンライン開催のようですが、今年も盛り上がって参りましょう。

www.scrumfestsapporo.org

その他

Google Relay

まだ読めてない><

スクラムマスターになると張り切っちゃう問題

スプリントレビューの工夫

ユーザーに近しい方に来てもらい、シナリオを渡して観察する。どんな感じか見学に行ってみたい。

ベロシティを目標においてしまうアンチパターン

社内で何人かにマサカリささってました。

Miroにホワイトボードを置くとトピックが散らからない説

プロダクトチームのあり方

右側を志向していかないといけない。

TRYを翌週振り返るときのよい意思表明のやり方

「直接話した」スタンプ

弊社にもできたんだけど、「話した内容をSlackに書くべきだ!」という主張の方がそれなりにいるみたい。 主張はわかるけど、スタンプもないと話しがあったのかも、誰が話したのかもわからないし、ないよりは全然マシだと思うんだけど。 内容を残しておいて欲しいほどのやつなら「口頭で話したことをメモで残して下さい」と言いやすくなるので。

PBIの打率測ってますか?

スクラムフェス大阪 2021でシステム思考の話をしてきました #scrumosaka

はじめに

今年もスクラムフェス大阪でプロポーザルを採択いただき、話してきました。

confengine.com

社内で向き合う課題が段々と複雑に・難しくなってきているため「システム思考」を布教することが増えてきています。 ただ「これ読んでおいてー」ですむような、最初のとっかかりに適した資料がなかなかなく、「ないなら自分で作るか!」と追い込むためのプロポーザルでした。 他の方の登壇を聞いていてもシステム思考に言及することが最近増えてきたのでニーズはそれなりにあるのではないかと思っています。

登壇準備をしている時は20分枠だといろいろ盛り込むのが難しいなと感じていましたが、使い始めるにあたって必要最小限のことを盛り込むようにまとめられたかと思います。

過去のシステム思考に関連しそうな記事

参考資料

なぜあの人の解決策はいつもうまくいくのか?―小さな力で大きく動かす!システム思考の上手な使い方

世界はシステムで動く ― いま起きていることの本質をつかむ考え方

学習する組織 ― システム思考で未来を創造する

#JBUG 広島 #8 でRettyでの改善取り組みを話してきました

2021年6月13日に行われたJBUG 広島 #8でRettyでの改善取り組みを話してきました。以前 LeSS Studyで紹介した内容 をベースにした再演です。

jbug.connpass.com

4月に刊行されたユニコーン企業のひみつと絡めて話して欲しいという話があり、アジャイル/スクラム/LeSSではなく、何を課題と考えて、どう変えていったかを中心とした話としました。

反応など

Twitter

カジュアル面談で話すとよさそうなこと

f:id:tune:20210605151926j:plain
Photo by Christina @ wocintechchat.com on Unsplash

はじめに

先日heyさんの採用イベントで公開カジュアル面談をさせていただきました。

hey.connpass.com

「できるだけ本当のカジュアル面談に近づくようにやりたい」というhey 勝亦さんの希望もあり、事前に打ち合わせは特にせず、「こいつらヤラセっぽいな」と思われないように深く切り込むような質問もときおり混ぜ込みました。もちろん事前にheyさんの公開資料を読み込んで考えてきたものです。

せっかくなので「自分がカジュアル面談を受けるならこういうことを聞くだろうな」と考えたこと、逆に普段実施する側で「これは必ず説明するように心がけていること」をまとめてみました。 Googleで「カジュアル面談 質問」と検索すると例がいくつも出てきますが、大抵は公開されている会社情報を調べるとわかることばかりなので、直接聞かないとわからないことを聞いた方が良いですよね。

自分ならこんなことを聞いてみたい

事業構造、何でお金を稼いでいるか。

創業時の事業や広く認知されているサービスと、実際にお金を稼いでいる事業・サービスが異なる会社がよくあるなと思っています。 会社における売り上げ比率から社内のパワーバランスや、今後力を入れていく開発領域も推測できると思います。

何で収益を上げられているのかわからないけど積極的に採用を行なっている場合、調達した資金を燃やしながら人員を拡大している可能性があります。 広告事業ができる前のGoogleも採っていた戦略ではありますが、Googleになれなかった会社の方が圧倒的多数ですので、目処・戦略はついているのか、いつまで挑戦できる余力が残っているのか、リスクとリターンを確認しておくと良いと思います。

募集の背景

「〇〇で有名なあの人と一緒に働けるチャンスかもしれない」と思わせる募集要項がはっきりした求人をたまに見かけることがありますが、憧れのその人が退職するために代わりの人材を募集していることがあります。「これからXX人材を集めて業界内を引っ張っていくんだ!」とピュアに想像せずに、きちんと確認した方が良いと思います。

募集の背景をはっきり答えられない場合は採用の頭数を追っている可能性が高いと思います。あなたの経歴やスキルはそこまで重要ではなく、他の誰かでも代替はきくでしょう。

競合との差異

競合が全くない会社・事業領域はまずないと思います。 競合を意識し過ぎているのもユーザーを見ておらずよくない兆候ですが、意識しなすぎなのも自分たちのやりたいことをやっているだけでまずいサインかもしれません。

業界の2番手企業が1番を追い抜かすことはほぼなく、逆転にはなんらかの競争軸の変化が必要なので、何を差別化ポイントと考えているのか説明してもらうと良いと思います。営業力や気合いが答えとして出てくる場合は多分逆転は望めないでしょう。

今の会社の課題

「人が足りない」みたいな話しか出ないと、見えにくい・隠れてしまっている本当の問題に向き合えてないのではないかと思います。 ここをはっきりと答えてもらえると、自分が入ることでどう貢献できるか、過去の経験がどう生かせるかといった話で盛り上がれるはずです。

事業成長の先に何が起きるか

今伸びている事業があってもいつか成長の終わりを迎えます。その時に会社はどう動くのでしょうか? 国外を目指す、新規事業を立ち上げる、M&Aを実施するなど考えられますが、会社の打ち手は自分の考え方とあっていますでしょうか?

その会社で働くことで何が得られるか

せっかくなので他の会社では得られない貴重な経験があると良いですよね。 すぐに答えるのが難しい質問かと思いますが、すぐに答えてくれるようだと普段から自社の強み・差別化を意識している証拠かと思います。

説明するように心がけていること

会社でできること、できないこと

事業構造や経緯に起因する正解があるわけではない事項は、最初に確認しておいた方が双方時間を無駄にしなくて良いと思います。

  • 会社が一番重視していること。ユーザー、売り上げ、事業成長など。
  • 開発スタイル。個人で行うのか、チームで行うのか。
  • 開発領域。フロントエンドからインフラまで広く触れるのか、職能・特定の機能に限定されるのか
  • 新規技術の採用。取り入れやすいか、しにくいか
  • 新規事業の立ち上げ。携われる機会は多いか、少ないか。

働き方、会社の制度

自社が裁量労働制なのでフレックスとの差異を必ず説明しています。 また裁量労働だと勤務時間の懸念を持たれるため開発のサイクル、1日の流れを紹介しています。

コロナ禍になってからはリモート勤務の割合、緊急事態宣言中の勤務、コロナが落ち着いた後はどうなりそうかを話すことが増えました。

面談相手の質問に時間が許す限り全て答える

「会社にいい印象を持ってもらう、願わくば選考に進んでもらう、すぐに選考に進まなくても転職の機会にまたコンタクトを取って欲しい!」が面談する側の気持ちなので、どんな些細なことでも相手が知りたいことは答えるようにしています。

おわりに

上記の話、カジュアル面談を面接の1歩目として考えている会社だとウケは悪そうですが、「カジュアル面談」だしこれくらいは答えてくれる会社が多いといいなと思っています。

スクラムマスターを育てるコツ

f:id:tune:20210509174936j:plain
Photo by Element5 Digital on Unsplash

はじめに

スクラムマスターをどう選んだら良いか、どう育てたら良いか」という悩みを多くの方が持っているようなので自分の経験をまとめておきます。

自分はアジャイルスクラムを学び始めて丸5年が経ちました。 CSM(認定スクラムマスター)資格は持っていません。 初めてスクラムマスターに挑戦するメンバーをサポートした経験が複数回(累計10人以上)があります。

私にとってのスクラムマスターのゴールは「スクラムを始める前よりもよい働き方がチームでできている」ことです。 スクラムのルールをきっちり守ることではありません。

スクラムマスターの選び方

皆から立候補を募り、やる気がある人を信じるのが良いかと思います。 チームのエースや次のリーダー・マネージャー候補を選ぶ事例を聞いたことがありますが、そうなると役割ではなく役職感が出てくるのであまりお勧めしません。

「チームに献身的になれる人(細々としたタスクを普段から自主的にとってくれる)」「メンバーから慕われていて、助けたい・盛り立てたいと思わせる人」が強いて言えば向いているような気がします。 職位・グレード・スキルが高い人が務める必要はありません。どちらかというとそういうメンバーがスクラムマスターになると、メンバーが指示を仰ぐようになったり、自分が隠れてタスクをたくさんこなしてアウトプットを確保しようとするのでスクラムがうまく回らないことの方が多い気がします。

最初にお願いすること

スクラムマスターをお願いする人が決まったら下記の事項を伝えています。

  1. スクラムマスターはスクラムというフレームワークの中の役割であって、役職ではない。
  2. プロジェクトリーダーやチームのリーダーではないし、そういう振る舞いを求めてもいない。
  3. まずはスクラムで定義されたプロセスをきちんと守ることを心がけてほしい。

また、スクラムマスターを任された人のマネージャーには下記のお願いをします。

  • まずは「チームの雰囲気がよくなればヨシ」ぐらいに思っておいてほしい
  • スクラムを一人で回せる(カンファレンス登壇者でもお互いに相談し合っている)」とか「ベロシティをX % 向上させる(見積もりを水増しされるだけ)」ような目標を設定しない

まずは基本に忠実に従い、スクラムのイベントをつつがなく回せることに注力してもらいます。

チームメンバーも含めて初めてスクラムを導入する場合、最初の1回は全てのスプリントイベントに同席し、やり方がおかしいところがあれば適宜直します。 2回目以降はふりかえりだけ毎回呼んでもらうようお願いし、2週間〜1ヶ月ぐらいは同席します。 出席しても基本何も言いませんが、強いて言えば振り返りの改善案として出てくる策が「お気持ち(XXX に気をつける)」だったときだけ具体的な行動に直させます。

最初からスクラムマスター専任でお願いすると何をして良いのか混乱することが多いので、開発メンバーと兼任でお願いすることがほとんどです。

スクラム自体が初めてであればSCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発を読んでもらいます。 スクラム自体は経験があるけどスクラムマスターが初めての場合はアジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~を読んでもらっています。

うまくスクラムが回っていない兆候

2〜4週間(または2〜3スプリント)もたつと、大抵開発のリズムができ、何らかの成果が見え始めるようになります。 振り返りがうまく回っているとチームで改善しようという雰囲気が出てくるのでスクラムを始める前よりも「チーム雰囲気が良くなったのでヨシ」という目標が達成できます。

スクラムに従っているんだけど今ひとつしっくりきていないというときは、下記の兆候が出ていることが多いです。

1. スプリント内に全てのやることが終わらず、それがスプリントの最終日になってわかる

スプリント内で終わらないことはさておき、問題は「終わらないことがスプリントの最終日にわかる」ことです。 このケースはデイリースクラム(朝会)が機能しておらず、互いのやったこと・やることを発して終わっていることが多いです。 開発タスクの残り時間合計の推移や、全体でボトルネックになっていることをデイリースクラムで確認するようになると終わらないことが早期にわかり、プロダクトオーナーやステークホルダーとスプリントのスコープ調整を前もって実施することができます。

スプリント中にバーンダウンチャートを作ることを提案すると解決することが多いです。

2. スプリント内に全てのやることが終わらず、仕掛かりを多く持ち越す

スプリントプランニングが不十分(実装・テスト のような雑なタスクにばらされている)で、バックログの各アイテムに1人を割り当て終わっていることが多いです。 「複数人で取り組んだら少しでも早く終わらせることができないか」という話をチームがしていないことがほとんどに感じています。

一度チームに指摘すると、モブプロを始めたり、手が空いたメンバーが他メンバーの助けに入るなりするようになって解決することが多いです。

3. チームがスクラムマスターの指示を待ってしまう

「手が空いたんですが次に何をしたら良いんですか」とスクラムマスターに質問し、スクラムマスターが指示してしまうケースです。 スプリントプランニングとデイリースクラムの実施が不十分で、どういう順序でタスクを片付けていくのかメンバーが理解できておらず、自分で判断できないことが起因になっているように思っています。

「〇〇さんはどう思いますか?」と相手にボールを投げ返すと自分で考えるようになったり、その結果スプリントプランニングをもっとやろうといったり根本解決につながることが多いです。

スクラムの基本が身についてからの伸ばし方

上記のやりとりを3ヶ月もするとスプリントイベントは一通り回せて、チームの雰囲気も良くなった状態になります。 「自分が手を動かさず、サポートに回った方がチームとしての成果が出るんですよねー」とコメントが出てくるようになります。 またスクラムマスターにチームの状況を聞いてみると「言葉にできないモヤモヤ」や「もっと上手くできるはず」といった感想を聞くことも出てきます。

ここからは個別に壁打ちの機会を設けて伸ばしています。 あとは「最近実験している?」と聞いて、何かしらチームを良くするチャレンジに取り組んでいるかを聞くことが多いです。

相談される悩みの多くは経験・引き出しが少ないケースが多いため、外部の勉強会を教えたり、上級者向けの本をお勧めすることが多いです。 色んな経験を知れて良いなと思った本はスクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-でした。またアジャイルとかスクラムとか書いてないけど、結局基本を深く理解できるのはトヨタ生産方式をお勧めしています。 他にもいい本はたくさんありますが、本を読むだけで成長することはあまりなく、自分の持ち場・現場の課題に向き合う時間を増やした方が結果的に早く・強く成長するなと感じてます。

トヨタ生産方式

トヨタ生産方式

おわりに

私の場合はこんな感じです。他にも色んな方のノウハウ知りたいです。