心理的安全性をもたらすには
この記事はEngineering Manager Advent Calendar 2021 4日目の記事です。
心理的安全性という言葉が一般的になり、その重要性も、誤解(心理的安全性=ぬるま湯とか)も、訂正(心理的安全性は当人が決めるもの)も広まった状況かと思います。
心理的安全性を扱った記事はたくさん見かけるものの、「心理的安全性を高めるに具体的にどう行動したら良いのか?」という疑問に正面から答えた事例は少ないように感じます。ということで自分が普段行なっている行動や背景にある考えを紹介します。
ただ話す
チーム間の調整にもっとも良い方法は単純に、ただチーム間の調整をすることです。課題があれば自己管理されたチームの誰もが他チームの所に行って議論することが期待されています。もし、「ただ話す」ことが出来ない状況なのであれば、電話したり、最悪の場合にはメールを送れば良いわけです。調整の為に形式張った場は不要で、調整が遅れるだけです。立ち上がって話に行ってください。
これは大規模スクラムのフレームワークの一つ、LeSSで紹介されているプラクティスの1つです。 何か相談しないといけない時にマネージャーやリーダーに相談したり、定例会議を設けたり、調整役を設定したりすることをよくしますが、LeSSでは調整が必要になった時にただ立ち上がって相手のところに行き話すことを推奨しています。
チーム同士で調整が必要な項目はマネージャーを介さず話してもらっていますし、チームに対してのもやもやを相談された時は直接当人に伝えてみてはと話しています。マネージャーが間に入った方がうまくいくケースは少ないですからね
調整と統合 - Large Scale Scrum (LeSS)
"誰"の話をしているのかを明確にする。
「チームに言いずらい」という悩み相談を1on1で聞くことがありますが、その時は「言いづらい相手はAさんのことですか? それともBさん? それともCさんのことですか?」と名指しで聞くようにしています。1人1人の顔を思い出して考えてもらうと個別の人に言いづらいということはほとんどなく、大抵はチームや組織といったボヤッとした対象に対してなんとなく受け入れられないんじゃないかという不安感を抱いているケースがほとんどです。
対象をぼやかして話すと、さも抽象度の高い難問に取り組んでいる感じが出てしまうので、具体的に掘り下げてみましょう。 似たような話ですが「組織は話さない」というブログ記事が切れ味鋭くて好きです。
個人の問題ではなくプロセスの問題として扱う
「ただ話す」を実施してもらい、「誰の話か明確」にしても解決しない問題はあります。 1個人の望ましくない振る舞いが槍玉に挙げられることは少なくありませんが、この手の問題は「個人のコミュニケーションの問題」としてしまいがちです。 ですが一緒に働くメンバーを信じるならば、これは個人の問題ではなく「問題を生み出す背景プロセスの問題」なのではないでしょうか。
プロセスの問題を炙り出すには事例を複数集めて共通する背景要因を時間をかけて考える工数が発生しますが、個人の問題として安易に断じない姿勢をとり続けることで、問題をエスカレーションしても正しく議論されるという安心感が醸成できるのではないかと考えます。
聞きにくいことを率先して聞く
皆にしてほしい振る舞いを率先して行い、背中で見せることはよくあると思います。 私は言葉足らずだなと感じた説明があったら、意図を明確にするためにあえて聞くことを意図的に行なっています。
例えばあるルールが「"従業員"を対象に実施」と説明された場合、正社員の自分が対象者に含まれることは自明ですが、アルバイト・業務委託・インターン・契約社員のメンバーは悩むかもしれません。こんな時は「従業員にアルバイト・業務委託・インターン・契約社員は含まれますか?」とSlackチャンネルでオープンに聞いたりします。「マネージャーなので質問しやすいんでしょう」と思われているかもしれませんが、投稿する時はドキドキしています。役職者になってもそんなものです。
心理的安全性があるかのように振る舞う
心理的安全性の話が出るといつも引用してくる好きなスライドです。 マネージャーだからドキドキしても聞きにくいことを聞く、マネージャーだからメンバーを信じてプロセスの問題を探す、マネージャーだから皆が自律的に動けると信じて後ろで見守る。皆も同じような振る舞いを続けて自信がついてきた結果の先に心理的に安全な職場が実現できる。私はそう考えています。
おわりに
心理的安全かどうかは各々が感じる・決める話ではありますが、2021年夏に勉強会を開催した際に「今の会社は心理的に安全か?」とファイブフィンガー (指1本:安全でない〜指5本安全である)で回答してもらったことがありました。私は指4本を出しましたが他のメンバーは指5本出していたので、そこそこ安全な職場が作れているのだと考えています。
そんなエンジニアリングマネージャーが考えていることの紹介でした。
チームトポロジーを読んで考えたこと
2021年12月1日にTeam Topologiesの翻訳 チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計 が発売になります。 本書のレビューに参加させていただき、翻訳者の皆様から一足先に書籍をいただきました。 レビュー時は「なかなか難しいな…」と思っていましたが、翻訳者の皆様の努力とカラー装丁の効果か、読みやすい本に仕上がっております。
チームトポロジーとはどんな本か
翻訳者の一人であるryuzeeさん始め、多くの方が既にまとめてくださっているのでそちらを参照するのが良いかと思います。
チームトポロジーは、このコンウェイの法則を踏まえたチームファーストのアプローチです。 「チーム構造と組織構造を進化させて、望ましいアーキテクチャーを実現する」という逆コンウェイ戦略を実現するために、4つのチームタイプと3つのインタラクションモードを定めています。 それをもとにフローを最適化する組織を設計しようというのが肝です。
- 新刊『チームトポロジー』発売のお知らせ | Ryuzee.com
- Team Topologiesを読んだ | Taichi Nakashima
- 「ちいとぽ」こと『Team Topologies』の翻訳(12月1日発売)を読んだ - こまぶろ
- Team Topologies(by Manuel Pais)のキーポイント
自分の言葉で話すと「ソフトウェア開発体制」の定石を扱った本かなと思います。パターンランゲージとかが近いのかもしれません。 チームトポロジーの知見を踏まえつつ、状況に応じた開発体制のあり方を議論し見直していく。うまくいく状態を見いだせてから組織図に反映していく。本書とはそんな付き合い方が良いのではないかなと思います。
"ソフトウェア開発はこうしたらうまくいくんじゃないかな?"という経験や理論が体系化されている
「フロー(デリバリー、バリューストリームとか)を最大化する組織を目指す」「チームを基本単位として長く存続させる」「コミュニケーションパスを整理する」といった、ソフトウェア開発をうまくやるための知識が幅広く紹介・解説されており、関連する書籍や一次情報へのポインタもまとめられています。「サービスが成長し、人も増えて来て組織のあり方を見直したい」というのは"あるある"のよく聞く悩みですが、本書はそんな悩める人が手に取り読み、共通の知識・用語を使って議論を始める土台とするのにちょうど良いと思います。
自分は開発部門のマネージャーとしてチーム編成を見直すことが時々ありますが、チームにどんなコミュニケーションを取ることを期待しているか説明することができていなかったなと本書を読んで感じました。本書で説明されている3つのインタラクションモードは誤解なく伝えることができそうで、業務でも取り入れようと考えています。
逆コンウェイ戦略という用語の難しさ
本書のベースにはコンウェイの法則と逆コンウェイ戦略があります。
先に引用したryuzeeさんの説明も「チーム構造と組織構造を進化させて」とあるので、変えていくこと前提だと思うのですが、「目指すソフトウェアアーキテクチャの正解があって、それに合うように開発体制を作るんだ」と考えている人が一定割合いるんじゃないかなと感じることがあります。本書はそんなこと書いてないんですが、斜め読みして誤解する人が増えると嫌だなーとか用語が出てくるたびに頭をよぎります。
"ドメインの知識はあっても望ましいサービス責務が見えていない"は割とあるケースだと思っています。 ストリームアラインドチームのコラボレーションを促し、チームの責務を意図的に広く・曖昧にして議論を促すと良いのかなーとか考えたりするんですけど、逆コンウェイ戦略かと言われると違う気がしています。「脱コンウェイ戦略」とかなのかな?
ハブやコミュニティをどう表現するか
組織のスケーリングを扱った書籍だとコミュニケーションのハブとなる人材や、ノウハウマネージャーを置いたりして、コミュニケーションパスを短くするアイデアがよく紹介されます。Spotifyモデルのギルドのように職能や目的別のコミュニティを作るというやり方もありますが、これらはチームトポロジーではどう表現するとよいのでしょう。
仮想的なイネーブリングチームがあって、他チームをファシリテートで導いている気もするし、チームの一部メンバーがコラボレーションしているとも言える気がします。
ソフトウェア開発以外の組織体制はどうしていくといいんだろう?
サービスはソフトウェア開発だけで成立しないので、営業や企画など他部門を交えてフローを最大化していく必要があり、開発組織と合わせて進化させていく必要があると思います。チームトポロジーの考え方は使えるような気がするんですが、本書はソフトウェア開発に絞った話なんですよね。
チームトポロジーの狙いはあくまで明快なパターンの提供だとすると、もう少し具体化したルールを定義することで「アジャイルはソフトウェア開発にしか適用できないが、スクラムはソフトウェア開発以外にもで起用できる」ような状態にできるような・・・できないような・・・
他社の事例も聞きたい
読んで終わりにするのではなく、自社の状況を図示して整理し、共通の用語を使って議論できることにチームトポロジーの価値があると思っています。自社の開発体制を描いたものが手元にありますので、見てみたい方・議論したい方・ツッコミしたい方、お声がけください。
Meety or Meetyのグループディスカッションを考えたのですが、クローズよりはオープンな勉強会とかの方が良いのかなと思ったり。何社か集まってできるといいな。
2021年9〜10月に社内で共有したアジャイル開発関連の記事
社内でアジャイル開発を議論するSlackチャンネル #tech_agile に見かけた良記事のまとめです。この記事は第7弾で2年目に突入しました!
- 2020年9〜10月に社内で共有したアジャイル開発関連の記事 - tuneの日記
- 2020年11〜12月に社内で共有したアジャイル開発関連の記事 - tuneの日記
- 2021年1〜2月に社内で共有したアジャイル開発関連の記事 - tuneの日記
- 2021年3〜4月に社内で共有したアジャイル開発関連の記事 - tuneの日記
- 2021年5〜6月に社内で共有したアジャイル開発関連の記事 - tuneの日記
- 2021年7〜8月に社内で共有したアジャイル開発関連の記事 - tuneの日記
- ノウハウ・知見
- 他社事例
- Twitter
- オンラインのアイスブレイクにはしりとりがおすすめ
- うまくいかない時は自分と周囲の状況把握こそ大事
- 仕様通り以上の品質にチャレンジしているか
- すぐできる改善はさっさとやろう
- ミーティングなんか出てないでディスカバー行ってこいよ
- 入社したばかりの人に「次にこの人と話すといいよ」というテレフォンショッキング形式 1on1をやるとよい
- 改善項目の選び方
- デプロイを自動化したいというPBIはHowを表している
- Keepを考えるのが苦手な方へ
- POが決める優先順位にはフィードバックをあげる必要がある。
- Minimum Viable Productを作るイメージ
- ステークホルダーの紹介をきちんとしてあげよう
ノウハウ・知見
Ryuzeeさんがまとめてくれたアジャイルに関するFAQ
これもよいし、Waicrew 角さんのも良いまとめだなと思っています。
山型クロスファンクショナルチーム
クロスファンクショナルチーム/フィーチャーチームを組もうとすると「全部触れるようにならないとダメですか?」と質問がいつもくるのでこういう考え方もあるよって広まってほしい。
Miroの便利機能まとめ
有償でしか使えない機能があったりするので色々探検が必要。
短期と長期両方大事
理想論から長期目線に引っ張られることが多いけど、短期でも成果を出していくことは大事。
スクラムフェス三河キーノートスピーチ書き起こし
ありがたい
カイゼン・ジャーニー・カンファレンス - プログラマのジャーニー
3年前の発表資料のようですが何かの拍子にふと見かけて良い内容だったので
しいばさんと咳さんとみわさんの雑談
タイミング合わなくて聞けなかったのが残念。
咳チームのことを考えると、自分の中の不純物に気づくことができるから。
これわかります。
「心理的安全性おじさん」になっていませんか?
概念じゃなくて現場に寄り添いましょう。
余白を作り、埋める動きをする
自分が社内でやっている動きに近い。
他社事例
atama plusのスプリントの紹介記事
スプリントレビューで500件コメント出るのはすごい。見学に行ってみたい。
atama plusでLeSSを取り入れたことのエンジニア感想
Rettyと大差ないねーという声がありました。
オンラインのアイスブレイクにはしりとりがおすすめ
そういえば、以前やったことあるんですがオンラインMTGにあまり慣れていない人の集まりのアイスブレイクはしりとりがおすすめです。そこそこ楽しい気持ちになるし、全員のマイクとスピーカーの調子が一撃で確認できるので。
— だいくしー (@daiksy) 2021年9月3日
うまくいかない時は自分と周囲の状況把握こそ大事
上手くいかないのをシステム、上司、同僚、他部署のせいとか、あるけども、それはひとつの可能性としてだし、求められる態度は
— きょん@アジャイルコーチ、システムアーキテクト (@kyon_mm) 2021年9月11日
何が起きていて、自分は何をしていて、周りはどう、っての解像度の高い説明をできるように知ろうとすること
なんだよな。。。結果としての1つの選択肢でしかないというか
仕様通り以上の品質にチャレンジしているか
多くの現場が「仕様の確認」ばっかりテストしているので、「仕様どおりであること」以上の品質にチャレンジできていない。そして、網羅性の価値比重が高いので、探索テストが重要視されないのではないか
— Dai Fujihara | mabl ノーコードテスト自動化SaaS (@daipresents) 2021年9月22日
すぐできる改善はさっさとやろう
すぐできるような改善は別にレトロスペクティブなんか待たずにガンガン勝手にやればいいんだよ
— Ryutaro YOSHIBA (@ryuzee) 2021年9月24日
ミーティングなんか出てないでディスカバー行ってこいよ
プロダクトマネージャーがプロダクトディスカバリーに時間が取れないというのは、本人と(特に)チームがプロダクトディスカバリーを他タスクよりも優先させていないから。参加が必須ではないミーティングにでも出ていたら、そんなことよりプロダクトディスカバリーしてこいよと言うチーム文化が欲しい
— 及川卓也 / Takuya Oikawa (@takoratta) 2021年10月1日
入社したばかりの人に「次にこの人と話すといいよ」というテレフォンショッキング形式 1on1をやるとよい
Rettyでも次に入社した人にやってあげようと思っています。
フルリモート環境で転職して新しい職場に馴染むために、勝手に「テレフォンショッキング方式1on1」をしている話を、来月登壇時の資料として書いている。
— Akiko Kurono - a.k.a crema (@crema) 2021年10月2日
すぐに仕事をご一緒する人と1on1する→そのとき「次に誰と会ったらいいですか?」と紹介してもらう→その人にDMして1on1を依頼。以下ループ。
改善項目の選び方
ほんとこれ
- どうでもいい小さな改善をたくさんやるよりインパクトのある1つの改善を
— Ryutaro YOSHIBA (@ryuzee) 2021年10月4日
- 問題を扱うときは薄く広くじゃなく、深く狭く
- 意見と事実を切り分けろ
- 実際に改善できたかどうか追求しろ。効果がなければもとに戻せ
- 改善は仕掛け化しろ、気を付ける、注意する、共有する、連携するとかは無意味
デプロイを自動化したいというPBIはHowを表している
今日はこういう基本的な話をした。 pic.twitter.com/Xs2Z6ZbVdS
— Ryutaro YOSHIBA (@ryuzee) 2021年10月7日
Keepを考えるのが苦手な方へ
ふりかえりのシート、ぱっと見KPTなんだけど、【Keep】の見出しに
— よこち (@akira6592) 2021年10月15日
・学んだこと
・楽しかったこと
・ポジティブな気づき
・など
とかいたら、何時も書かれないタイプのKがでてきた。
POが決める優先順位にはフィードバックをあげる必要がある。
POが決めるための十分な情報(めりでめだけじゃなくどっちがいいと考えてるかとか、ほんと十分な)を与える職責があり、決めたことにもきちんとフィードバックする必要はあるんだけど、そこをしなくていいと思ってる人が結構いて、そういうのがすごく嫌い。
— いろふ (@irof) 2021年10月22日
Minimum Viable Productを作るイメージ
— Pukar (@PukarDesign) October 24, 2021mobile.twitter.com
ステークホルダーの紹介をきちんとしてあげよう
スプリントレビューで、POが招待したステークホルダーの名前や仕事の内容とかバックグラウンド、プロダクトとどう関わっているのかを参加者全体に説明してて、とても良い
— Ryutaro YOSHIBA (@ryuzee) 2021年10月27日
スクラムフェス三河 2021でスクラムマスター育成の話をしてきました #scrummikawa
はじめに
スクラムフェス三河でスクラムマスターの育成について話してきました。今年は会社からも5名の登壇者が出ており、普段の業務を通じた学びをコミュニティに少しは還元できたかなと思っております。
https://confengine.com/conferences/scrum-fest-mikawa-2021/proposal/15593
資料をSpeaker Deckに公開していますが、はてなブックマークのホットエントリ入りした効果か、スクラムフェス三河の参加者以外にも読まれているようですので、当日の発表・スクラムフェス三河のDiscordで捕捉した事項も本記事で紹介しておきます。
発表の捕捉
なんでこんな話したの?
アジャイル・スクラム系の情報発信、勉強会・カンファレンスで多く登壇機会をいただいているおかげか、「うちも(大規模)スクラムやろうと思っているのですが、少し話を伺えませんか?」というお話をいただく機会が少なからずあります。数社お話して毎回質問されるのが「チームが増えたときにスクラムマスターの成り手がいないのですがどう対処したのですか?」というものです。最初はその会社固有の課題なのかと思いましたが、話を伺った会社全てに聞かれた気がしたのでこれはひょっとして普遍的な悩みなのかと考えるようになりました。あまりにたくさん聞かれたので、このブログでも5月に一度記事を書いています。
あらためて読み直すとスクフェス三河発表スライドよりも情報量多いですね💦
リーダー・管理職は、どうしてスクラムマスター不向きなの?
「権力勾配を使って自分の意見を押し通しやすい」ため、"名前を付け替えただけで何も変わってない"状態に陥りやすいと思っています。
※リーダー=会社・組織で定義されているチームリーダーのような役職を指してます
「スクラムがやりたい人」は、どうしてスクラムマスター不向きなの?
熱意があるのは素晴らしいのですが「本に書いてあるからこのやり方が正しい!あの人はスクラムの勉強が足りてない!!異論は認めない!!!」という対立構造を引き起こしがちな気がしています。私たちは価値提供・課題解決をしたいのであって、スクラムをやりたいわけではないはずです。
悩み続ける人はスクラムマスターに向いているの?
メンバーからの「どうしてスクラムだとこういうやり方をするんですか?」という質問に対し、自分たちの言葉で答えを考え続ける方が、その組織にあった良いやり方に辿り着ける確率が高いと思います。
スクラムマスターは役割なの?
スクラムガイドを参照したところ「責任」と言う表現を使っていました。
スクラムチーム全体が、スプリントごとに価値のある有⽤なインクリメントを作成する責任を持つ。 スクラムはスクラムチームにおいて、開発者、プロダクトオーナー、スクラムマスターという 3 つの明確な責任を定義する。
いずれにせよ、「スクラムチーム全体が、スプリントごとに価値のある有⽤なインクリメントを作成する責任を持つ。」なので、スクラムマスター一人が勉強して、スクラムの全てに責任を負わせているような体制は良くないと思います。
開発者兼任のスクラムマスターってどうなの?
「専任はダメ」としているのではなく「専任でも兼任でもいいよ。結果的に全員兼任を選んでいるよ」という状態です。 スクラムマスターに話を聞くとームの状況に応じ、開発に割く時間は増やしたり減らしたりしているそうです。 「他の開発者と同じぐらいコード書いてね」という前提がなければ良いと私は思うのですが、専任にすべき派の意見も聞いてみたいところです。
スクラムを好きになってくれるかもわからないのに「あなたはスクラムマスターになったのだから真のリーダーとしてサーバントリーダーシップを発揮し、スクラムチームとその外の組織に奉仕する必要がある」と言われても困ってしまうと思うのです。
教科書通りやることが何より難しいんだけど
「教科書通りやることだけ」を注文すると案外できますよ。 最初からいろいろスクラムマスターに色々求めすぎているのでは?
「スクラムマスターじゃなかったら」という前提条件の外し方はどういうこと?
スクラムでの正解が欲しいのか、問題に対しての打ち手が欲しいのかでいうと、ほとんどのケースは後者だと思うのです。
僕のスライドじゃないので想像ですけど、スクラムに対する思い込みや誤解がわかったり、スクラム自体を目的化しちゃってる可能性に気付けるかもしれないですね
— Ryutaro YOSHIBA (@ryuzee) 2021年10月2日
スクラムマスターとしてはお給料上がらないということ?
スライドの表現が紛らわしかったなと思っています。
- エンジニア共通のグレード定義がされており、社員はいずれかのグレードに分けられる (よくあるグレード制度・役割等級制度)
- 「スクラムマスターは役割」であり、どのグレードに所属していもスクラムマスターになれる
- グレードで定義された役割・成果が果たせていれば昇格する。
スライドで伝えたかったことは下記です。 - エンジニアのグレード定義とは別にスクラムマスターのグレード定義を用意しているわけではない。 - スクラムマスターの次に、シニアスクラムマスターとかアジャイルコーチのようなキャリアパスを社内で整備しているわけではない
エンジニアリングマネージャーとしてどんなことをしているのか?
はじめに
今流行りの 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)」を採用しているため、それを実施しています。
プロダクト開発はスクラムで進めていますが、"チームで開発する"・"優先順位に従って開発する”・"やることは適宜見直す"というスクラムの性質から、やりきり目標や個人ごとの開発項目を建てると都度見直しが発生して運用が大変です。そこで組織目標・個人目標・個人課題に分けて設定しています。
- 組織目標(部門目標)
- 複数チームで共通
- 3ヶ月毎に見直す、大きくは変わらない
- 個人目標
- 全員ほぼ共通、公開する
- 3ヶ月毎に見直す、あまり変わらない
- 個人課題
- 個人ごとに固有、非公開
- 業務グレードが変わらない限り変わらない
目標の難易度設定が難しかったり、評価の時期と成果が出る時期がずれたり、評価の時期は毎回悩み事が発生しますが、マネージャーとして重要な職務だと考えて丁寧に説明することを心がけています。
評価の話は2020年のスクラムフェス大阪でも話をしました。
後進の育成
新卒1〜3年目くらいのジュニアエンジニアは1on1を通じて成長を阻害している要因を突き止め、アドバイスをしています。 成長曲線や壁を乗り越えるタイミングは人によって異なるため、取り組み姿勢が間違っていなければ焦らず目の前のタスクに取り組むよう話すことが多いです。
中堅・シニアエンジニアになると、複数の人を巻き込んで大きい成果を出してもらいたいことが増えるため、大きな開発の取りまとめや推進役をお願いしたり、ジュニアエンジニアのメンターを依頼したりします。役割の数がどうしても少ないため、機会提供が偏ることが無いよう、乗り換えられそうなちょうど良い難易度になるよう、3ヶ月〜半年ぐらい前から考えることが多いです。
マネージャーの育成は最も時間がかかります。開発とマネジメントは求められるスキルや振る舞いが異なるため、開発タスクを減らし、マネージャーとしての振る舞いを考え・学ぶための余裕を意図的に作ってあげる必要があります。 自分が抱えている問題を移譲して代わりに解決に取り組んでもらったり、実際に起きてしまった問題を題材として「今から戻ってやり直せるならどうしたら良いか」を議論するなど、時間をかけて考え方やアプローチを伝えています。
日常の労務管理
いわゆる勤怠管理ですが、忙しさの山や谷を作らず、一定のペースで働けるように業務量を気をつけて見ています。 より具体的には残業が常態化していないか、残業が一時的に増えた場合はそれが開発の山場として妥当なものかをチェックしています。
開発
プロダクトマネジメント
企画に責任を持つプロダクト部門が別途あり、施策や方針決めは基本委ねています。 アイデアや機能提案をすることはありますが、それよりも技術負債やセキュリティ問題などエンジニアでないと判断がつかないものについて開発優先順位の強めの提言をすることが多いです。
開発タスクを分解したり、メンバーにアサインすることは基本していません。 プロダクトオーナーにより優先順位で並べられたプロダクトバックログを、開発チームが毎週開発できると考える分だけとっていきます。 自分は四半期・半年・2〜3年といったスパンで、"何をやっていきたいか"を社内のいろいろな立場の人から聞き、どう実現していくのが良さそうかを考えることが多いです。
エンジニアリングのリーダーシップ
機能追加や不具合修正関して、プロダクトコードを直接書くことはしていません。 技術採用や開発方針の決定、細かな設計も開発チームに委ねています。
開発への関与としては、チームが将来取り組むであろうふわっとした課題を先に調査しておくことを手が空いた時にしています。 また現場では決められないような「決めの問題」が生じた時に、開発責任者として意思決定したりしますが極めて稀です。 障害・インシデントが発生したときはその影響範囲の大きさによって、対応の陣頭指揮をとったりします。
開発を広く見てはいますが、自身の役割は技術でプロダクトを引っ張ることを期待されるテックリードとは異なるもので、エンジニアリングマネージャーのキャリアの先にCTOがあるとも考えていません。
採用・採用広報・アドバイザーの招聘
上位の目的としては「今の開発体制で足りない人を連れてくる」だと考えています。
採用
採用チームと定例を持ちながら、採用活動に広く協力をしています。 スカウトのフィルタリング、スカウト文面の送信、カジュアル面談の実施、コーディング試験の評価、技術面接など。
またインターンコンテンツを考えたり、採用イベントを準備したりします。 ここ半年だと下記のイベントに携わりました。
- プログラミングコンテスト「Rettyグルメオープン」を開催しました - Retty Tech Blog
- 【イベントレポート】Retty Beer Bash#2〜スクラム開発におけるあれこれを語る会〜|Retty Inc.|note
- Rettyサマーインターン2021開催決定! - Retty株式会社のWebエンジニアの求人 - Wantedly
採用広報
勉強会の開催、カンファレンス登壇、テックブログ執筆などの活動です。 自分自身の知名度を上げキャリア形成をやりやすくする目的もありますが、組織としても採用活動に遅れて効果が出てくると考えています。 直近だとスクラムフェス三河に会社から5件のプロポーザルをだし全て通過、Go Conference Autumnに会社から7件のプロポーザルを出すことができました。 ノルマや金銭的なメリットを設定しているわけではないため、普段の業務で学んだことを対外的にアウトプットし、学びにつなげるメリットを広く組織に浸透できているのだと思っています。
また定期的に対外アウトプットをしておくと、一定期間の自分の活動をまとめるきっかけになるだけでなく、「口だけにならない」と言う自分への戒めにもなるなと感じています。
アドバイザーの招聘
自分が詳しくなく組織としても弱い領域、自分ができるけど手が回らない領域で外部の識者の方にアドバイザー・相談役をお願いしています。 どの方にも豊富な経験に基づいた適切なアドバイスをいただけており、組織として悩む時間を減らせたり、自信を持って取り組む後押しになっています。
社内勉強会での講演や、単発のワークショップももっとやっていけたらなと思っているのですが、開発の状況・予算・開催タイミングなどあり、声はかけながらも開催にいたってないものがいくつもあります。これは私の力不足が大きく、ただ申し訳ないです。
他社との情報交換
エンジニアリングマネージャーとしての打ち手は組織や置かれた状況のコンテキストによって効果があるものもないものもあり、引き出しを増やすことが大事だと考えています。 なので他社の方から相談をいただいた場合は基本的に引き受け、積極的に自分たちの経験を共有しています。 相談を持ち込んだ側は同じ問題で時間を取られることなく、壁を乗り越えた先にあった新しい問題も次回に共有してくれるためどの会社とも学びのある情報交換をさせていただいております。
他にも「自社で起きている問題が一般的なのか、自社固有の問題なのかを切り分ける判断材料になる」「他社の相談を先に受けておくことで、自社で別の相談が出てきた時に相談しやすい」というメリットもあります。
終わりに
会社から与えられた仕事や目標はあるようであまりありません。会社やプロダクトの様子を見ながら社内を広く見渡し、自分で考えて作っています。 直接的な仕事はなく、自分が居なくても開発業務は回ると考えています。 1週間居なくても全く問題ないでしょう。事前に準備しておけば1ヶ月居なくても多分大丈夫だと思います。 ただし3ヶ月居なくなると開発でうまくいかないことが増えてきたとメンバーが感じることが増えるのではないかなと思っています。 エンジニアリングマネージャーとしての貢献はこれぐらい長期で効いてくると考えています。
大変なことが多い、直接的な達成感も得にくいエンジニアリングマネージャーですが、下記が面白さかと考えています。
- プロダクトの成長 : なんだかんだ方向性に関与できる裁量が大きい。
- 組織の成長 : 同じメンバーでも雰囲気や成果は異なる。
- メンバーの成長 : 突然殻を破るような成長を身近で見れるのは嬉しい。
この記事を読んでもっと聞いてみたいと思った方、ディスカッションしたいと思った方、Rettyのエンジニアリングマネージャー職に興味が沸いた方は是非Meetyでお話ししましょう。
2021年7〜8月に社内で共有したアジャイル開発関連の記事
社内でアジャイル開発を議論するSlackチャンネル #tech_agile に見かけた良記事のまとめです。この記事は第6弾でトータルで1年間まとめを続けることができました。
- 2020年9〜10月に社内で共有したアジャイル開発関連の記事 - tuneの日記
- 2020年11〜12月に社内で共有したアジャイル開発関連の記事 - tuneの日記
- 2021年1〜2月に社内で共有したアジャイル開発関連の記事 - tuneの日記
- 2021年3〜4月に社内で共有したアジャイル開発関連の記事 - tuneの日記
- 2021年5〜6月に社内で共有したアジャイル開発関連の記事 - tuneの日記
ノウハウ・知見
チームで品質を考えるレビュー
プロダクトオーナーとしての成長
わかりやすい。
エンジニアが自走する組織の作り方
個人が持つタスクに期限を設けてみる
弊スクラムチーム、個人がタスクを持つ期限を作るというアイデアが出ておもろそう pic.twitter.com/V7SbeJZJm2
— resessh (@resessh7) 2021年7月14日
スケジュールにバッファを設けるのは悪か?
不確実性コーンの実例として分かりやすい。
体験のデザイン・リーン・アジャイル開発の関係
何が欠けるとどうなるのか説明がわかりやすい。
アジャイル関連本の年表
アジリティを支える品質特性
リモートアジャイル開発のノウハウ集
片思いマッピング
他社事例
LINE NEWS
エンジニア40人、企画60人でLeSSっぽく作るLINE NEWS
HERPのLeSS事例
LeSSをやめたRepro
ラクスのLeSS事例
アカツキのLeSS事例@CEDEC
PdMは映画監督説
PdMは映画監督である説をずっと唱えているので、開発チームは○○組と呼ぶべきだし、作品ができたらクレジットを載せるべきだし、アカデミー賞を受賞したらオスカーを受け取るのだ。
— 角 征典/Masanori Kado (@kdmsnr) 2021年7月7日
ツールが問題を解決してくれるのは幻想
テスト自動化に限らず「ツールが問題を解決してくれる」なんて幻想。「よく切れる包丁買ったら美味しい料理が自然とできるのか」を考えてみれば答えは簡単なはず
— Dai Fujihara | mabl ノーコードテスト自動化SaaS (@daipresents) 2021年7月12日
ふりかえりでファシリテーターが全ての発言にコメントしてしまうあるある
ふりかえりのファシリテーターが、誰かが話したときにいちいちコメントするのはついやってしまいがち。
— TAKAKING22 (@TAKAKING22) 2021年7月27日
最初にWhyを明確化しろ
whatとhowだけでゴリゴリ進めると、仮説検証に時間をかけなくていいからスピード感が出る。こまめにリリースすればアジャイルっぽく見える。
— Aki (@AkiDebukatsu) 2021年7月29日
こうして「リリース後も業務部門からの変更要求が多くて追加開発に追われています」の状態ができあがる。最初にwhyを明確にしろとあれほど…
プロダクトバックログの優先順位が守られない困りごとの比喩
コース料理(前菜、スープ、魚料理、肉料理、デザート)を作っている。岩塩とブラックペッパーを軽くふった牛フィレ肉を強火で「さあ焼くぞ!」となったとき「自分できることないんで、先にデザート作って出しときました!」て言われたら、すごくやだ…… https://t.co/GfuvEaYenq
— miwa (@miwa719) 2021年8月8日
スプリントレビューは料理の試食会
ある現場でやっている「ScrumMasterTheBook」 の読書会で、「スプリントレビューって料理の試食会だよね。実際のお客さんに食べてもらって、その様子を観察するって感じで」という話が出ていて、良い表現だなって思って聞いていた
— yoh nakamura (@yohhatu) 2021年8月10日
スクラムマスターは先頭に立つな
スクラムマスターをうまくやりたいなら、自分が先頭に立たないことが大事です。イベントの進行とかやらんでいいから。
— Ryutaro YOSHIBA (@ryuzee) 2021年8月17日
その他
Rettyメンバーからのカンファレンスプロポーザルです。話が聞きたいなと思ったらConfengineにログインして「いいね」をお願いします。 採択されなくても、勉強会に声かけいただければ皆喜んで参加すると思われます。
※8/29時点
- Scrum Fest Mikawa 2021 - スクラムマスターの育て方 | ConfEngine - Conference Platform
- Scrum Fest Mikawa 2021 - 「守破離の守!」スクラムガイドをみんなで読んでみた。 | ConfEngine - Conference Platform
- Scrum Fest Mikawa 2021 - チームがLeSSにJoinして1年半経ったので振り返ってみた | ConfEngine - Conference Platform
- Scrum Fest Mikawa 2021 - チーム開発を怖がっていた私がスクラムマスターになって壁を乗り越えた話 | ConfEngine - Conference Platform
- Scrum Fest Mikawa 2021 - みんなでやればいいじゃん!チームの力を高めるモブワークを始めよう! | ConfEngine - Conference Platform
[スクラムフェス札幌]
[Regional Scrum Gathering Tokyo 2022]
2021年5〜6月に社内で共有したアジャイル開発関連の記事
社内でアジャイル開発を議論するSlackチャンネル #tech_agile に見かけた良記事のまとめです。この記事は第5弾、次回で祝1周年となります。
- 2020年9〜10月に社内で共有したアジャイル開発関連の記事 - tuneの日記
- 2020年11〜12月に社内で共有したアジャイル開発関連の記事 - tuneの日記
- 2021年1〜2月に社内で共有したアジャイル開発関連の記事 - tuneの日記
- 2021年3〜4月に社内で共有したアジャイル開発関連の記事 - tuneの日記
ノウハウ・知見
リモートのスプリントレビューを盛り上げるコツ
弊社でもレビュー後のZoomブレイクアウトルームを使った議論タイム設けました。簡単で効果高いのでおすすめ。
スクラムマスターの資格まとめ
当方無免許です。
初めて入るチームでの立ち回り例
内製化に取り組む方へのアドバイス
スクラムとSECIモデルの関係
開発スピードを上げたいなら開発スコープを小さくしよう
はい。
ロードマップに機能を書くべきではない
ブロッコリーさんがよくシェアする記事、シチュエーションも添えて
良記事集です。
素早く頻繁に失敗しよう
ゾンビスクラムサバイバルガイド
面白そう。
リチーミングモデル
固定的なチームが成熟しすぎると、サイロ化が生じて学習や改善がチーム内に閉じ、組織学習を阻害するという考え方。下記のどれもやった記憶あり。
- 社会化(Socialization) — 新たなチームメンバを参加させるためにチームが継続的な努力を払う。そのような継続的プラクティスを通じて、新たなチームメンバの受け入れ能力が向上する。
- 有糸分裂(Mitosis) — 分裂可能な大きなさまで、チームが成長する。新たに生まれたチームは、すでにその時点から、業務に精通している。
- ボランティア消防団(Volunteer Fire Department)チームモデル — 有志メンバが一時的なタスクチームを結成して、主要な問題を解決した後に、元のチームに戻る。
- 交換所(Trading Places) — チームが他のチームとの間でメンバを一時的に交換することで、組織全体で学習成果を共有する。
仕事中は理想のプログラマーを演じ切るといい振る舞いができると言う話
他社事例
ヤフー
デイリースクラム(朝会)でチームが見つけたチーム内の課題を話すのよさそうです。
SMS
リリース出来たらご褒美にレゴを組み立てる文化
LINE
LINE TODAYでのLeSS事例、LeSS成分は少なめ
Chatwork
モブレビューのおすすめ
Scrum@Scaleの取り組み
SmartHR
デザイナーのスクラムへの関わり方で「スプリントレビューでステークホルダーを観察する」というのがあって面白い、確かに。
LeSS開発の話がチラッと。4〜5人/チーム * 5チーム = 20名弱っぽい。
スプリントレビューにユーザーを招待した話、すごい!
ユーザー要望から機能を開発した場合、要望をくれたユーザーに報告して開発完了となるらしい。素晴らしい。
この記事、ひとつ大事なことを書き忘れてました。
— Takashi Adachi (@asanebo_) 2021年6月17日
リリース後に要望をくれたユーザーに報告をするというプロセスがあるのです。NPSでクローズドループと呼ばれる概念です。
実務を担当してる人が書いてくれたらうれしいな〜 https://t.co/2QBwpskju2
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事例
勉強会・カンファレンス
iCare Dev Meetup
キヤノンメディカルの「あのチーム」の話
スクラムフェス大阪
基調講演
サイボウズ天野さんの社会人の基礎としてのアジャイルの背景知識まとめ
家事の話だけど、開発部門が取り組むカイゼンがどういうものかわかりやすいと思い会社の子育てチャンネルに投げた。
世の中いろんなスクラムマスターがいます。
アカツキさんのLeSS事例
ラクスさんのアウトカム指向への転換取り組み。課題感がうちとちょうど同じくらい。
テストを書く前に考えるテストの話
トヨタ主査制度の最初の1人の話
スクラムフェス札幌
残念ながらオンライン開催のようですが、今年も盛り上がって参りましょう。
その他
Google Relay
まだ読めてない><
Google が Design Sprint のその先を探究するためのプロジェクトをコミュニティ内で立ち上げ、その成果物を公開しているサイト「relay」が凄すぎる。フレームワーク、ツール、プレゼンテーション資料など、直ぐに参考にできるものが盛り沢山。https://t.co/4tDxkjPtvS pic.twitter.com/hkfEQjeIhU
— Kazumichi Sakata (@mariosakata) 2021年5月15日
スクラムマスターになると張り切っちゃう問題
スクラムマスターに任命されたらなんかしなくちゃと考えてチームに取って余計なことを一杯しちゃうの本末転倒なので、まずはゆっくり観察しつつチームに何をしてほしいか聞けばいいんじゃないかね
— Ryutaro YOSHIBA (@ryuzee) 2021年5月15日
スプリントレビューの工夫
ユーザーに近しい方に来てもらい、シナリオを渡して観察する。どんな感じか見学に行ってみたい。
ある現場のスプリントレビューがホントに見ていて面白い。利用者に近い人に来てもらって、ほとんど説明せず、テストシナリオを渡して操作してもらってそれを観察し、終わった後はディスカッションして、フィードバックを集めている。さらに価値がありそうなものはかなり早いスピードで対応している
— yoh nakamura (@yohhatu) 2021年6月6日
ベロシティを目標においてしまうアンチパターン
社内で何人かにマサカリささってました。
こう言ってたら気をつけろ(というか問題あり)。
— Ryutaro YOSHIBA (@ryuzee) 2021年6月11日
「各スプリントでベロシティ●●ポイントを達成しなきゃいけない」
Miroにホワイトボードを置くとトピックが散らからない説
ふと思うところがあって、オンラインホワイトボードの中にホワイトボードを設置してみた。みんなでディスカッションするとき、トピックが散らかりがちなので、今話ししないといけないことをホワイトボードに貼る。面白いことに、結構意味がある。 pic.twitter.com/P3YkksZtx7
— Mikio Kiura / ANKR DESIGN (@kur) 2021年6月11日
プロダクトチームのあり方
右側を志向していかないといけない。
two org structures ....
— John Cutler (@johncutlefish) 2021年6月13日
one with the PO/PM divide
one with a product team pic.twitter.com/Tj5LCygCdl
TRYを翌週振り返るときのよい意思表明のやり方
最近のふりかえりでTRYレビューというのを試している。簡単だしみんな面白がってくれるので紹介。ふせんにスプリントのTRYを書いてドット投票するだけ。このTRYやったなら右寄りにドット、このTRYでもとの課題解決したなら上寄りにドット、だけ。ドット位置で感想が素早く可視化されるのがお気に入り! pic.twitter.com/Evdpu7HfRm
— naiban (@sasatoshin3104) 2021年6月19日
「直接話した」スタンプ
弊社にもできたんだけど、「話した内容をSlackに書くべきだ!」という主張の方がそれなりにいるみたい。 主張はわかるけど、スタンプもないと話しがあったのかも、誰が話したのかもわからないし、ないよりは全然マシだと思うんだけど。 内容を残しておいて欲しいほどのやつなら「口頭で話したことをメモで残して下さい」と言いやすくなるので。
Slackでこのスタンプを発明した弊社の誰かにノーベル平和賞を差し上げてください。
— すぃんや (Frasco) (@Shinshin_Frasco) 2021年6月22日
このスタンプひとつが、どれだけ無駄なやりとりを未然に防いでくれたことか。 pic.twitter.com/MwjqrZiST9
PBIの打率測ってますか?
POのみなさま、PBIの打率(インクリメントが利用者にいつも・ときどき使われている割合)って測ってます?
— HARADA Kiro (@haradakiro) 2021年6月25日