tuneの日記

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

知的コンバットできていますか？

Regional Scrum Gathering Tokyo コミュニケーション スクラム プロダクトマネジメント 組織 開発プロセス

qiita.com

この記事はAdvent Calendar for upcoming Regional Scrum Gathering Tokyo 2022 Advent Calendar 2021 25日目の記事です。自分がRegional Scrum Gathering Tokyoに初めて参加したのが2019年のこと。2020年は会社でスポンサーでき、2021年は同僚が登壇して、2022年は自分が登壇できることになりました。今所属しているRettyはアジャイルに・大規模スクラム(LeSS)に取り組む会社としてある程度認知いただけるようになった感触がありますが、年初にRSGTでエネルギーを貰えているのが助けになっている気がします。

知的コンバットによりイノベーションを生み出す

www.youtube.com

※ 注 : RSGT2021での野中先生基調講演動画はRSGT2022開催までの期間限定公開だそうです。

RSGT2021の最終日の基調講演で野中先生から投げかけられた言葉「知的コンバット」。これまで自分が探究していきたいことを「顧客にとって価値のあるプロダクトを、チーム一丸となって協力し、短期間にリリースする開発体制のあり方」と表現していましたが、もっと端的に短く・もっと情熱がこもった言葉を聞くことができ、この1年間自分の頭から離れないキーワードとなりました。

全身全霊で向き合うためには二人、ペアであることが最適です。同時に、双方の目線が上向きや下向きではなく、真っ当に向き合っていることが大事です。それでもそう簡単にはコンセプトは出てきません。「知的コンバット」を何度も繰り返す必要があります。双方が感じた異なる直観を、真剣勝負で何度もぶつけ合いながら、ようやく「こうとしかいえないよね」というコンセプトにつながっていくという感じです。この「共同化」のプロセスがない限り、組織で「知」を生み出す、イノベーションが起こるということはあり得ません。

※ 【野中郁次郎氏対談】第2章　徹底的な対話による「知的コンバット」なくして、イノベーションは生まれないより引用

「プロダクトオーナーが決めたプロダクトバックログの優先順位に従って開発を行う。開発チームは固定期間で区切ったスプリント内でインクリメントを作成し、リリースして得られた学びから次に何をしていくべきかを改めて考える。」こうして不確実なプロダクト開発に挑戦してくのがスクラムですが、真に優れたプロダクトを作る・イノベーションを生み出していくにはもっと真剣に自分たちが取り組む対象に向き合い、議論を戦わせていかなければなりません。

知的コンバットは難しい

「議論が大事だから意見を戦わせよう。職責やロールにこだわらずやっていこう。」と言うのは簡単ですが、実際に起きるのはレベルが低いケンカとトラブルです。 「セールス・企画・開発で納得のいく計画・プロダクトを作りたいのでお互いに意見を伝え合おう」と言うと、率直な意見が攻撃と受け取られ、職責を超えた提言が信頼感の欠如として受け取られてしまいます。「なぜ取り組むのか」「なぜ今なのか」「もっとよい打ち手はないのか」「何を学ぼうとしているのか」、プロダクト開発に真摯に向き合い本質に迫ろうとする問いほど、その山を知らなかったり、登り始めたばかりの当人にとっては致命傷となるマサカリになります。

HRT(Humility, Respect, Trust)を心がけた発言に、ドメインの理解や背景の共有、相手との信頼感を醸成し、人・相手ではなく問題・ゴールに目を向けて話す。ここまで段取りを整えてようやく知的コンバットの入り口に立てそうというのが私の正直な感想です。

RettyのAdventCalendarでプロダクトマネジメント組織で浸透した7つのキーワード(①PMスキル定義・評価制度, ②アウトカム, ③ロードマップ, ④事前検証, ⑤問いを立てる力, ⑥既知と未知, ⑦因果ループ)を野口がまとめてくれていますが、知的コンバットの土台となるこれらを浸透させるだけで1年です。長い道のりです。

note.com

知的コンバットの実現に手応えを感じた出来事

知的コンバットと呼べるような議論の成功を目指し、うまくいったりいかなかったりを繰り返しながらの開発でしたが、「知的コンバットとはこう言う状態なのでは?」と手応えを感じたことがありました。その出来事の直前は1ヶ月弱ほど中規模プロジェクトの開発に取り組んでおり、その振り返りで「実はプロジェクトの序盤からうまくいってないもやもやを抱えていて、良くないと思っていました」という告白を複数人から聞いたことがきっかけです。「その時言っておけばもっと違った今があるかもしれないのに」と静かな怒りを覚えたのをとてもよく覚えています。

その次のスプリントではスプリントプランニングにいつも以上の時間と熱量をかけました。「次のスプリントに何を取り組むべきか」「プロダクトオーナーの優先順位に質問はないか」「開発観点で先に取り組むべきことはないのか」「言うならこのタイミングだぞ、終わってから意見の後出しだめだぞ！」「本当に納得したか?」とかなり口すっぱく確認し、そこからチームの動きや成果が大きく改善された気がします。

本当に足りなかったのは熱量なのかも。

この記事を書きながら思い返してみると、タイミングやプロセス、知識の問題もあったかもしれませんが、それ以上に熱量が足りてなかったのかもしれません。 その後のメンバーとの1on1で気持ちを込めたアドバイスを多く送った気がします。

  • 相手に言っても聞いてくれないじゃない、聞いてもらえるように言うんだ。
  • 聞いてもらえるために「背景を説明する」「費用対効果を説明する」「時には感情を込める」「めげずに何度も言う」など色々試す。
  • 「コミュニケーションが足りない」とはどういうことなのか。真の問題から目を背けているのではないか。
  • あとでふりかえりをしたらダメだったことが良かったことに出来るわけではない。勇気を出していつでも言うべき。

終わりに

「真剣勝負で意見をぶつけながら、こうとしか言えないコンセプトを作り上げる」を達成した瞬間の楽しさは何ものにも代えられません。 「知的コンバット」の実現に必要な土台は準備は簡単ではありませんが、こうした経験が積める場を作れつつあることがマネージャーとしての今年の成果かと思います。

今日の話は「協働でゴールに向かう"チーム環境"」に関する話ですが、RSGT2022では「高速に石橋を叩いて渡る"開発環境"」の話をします。来年もRSGTでエネルギーを補充し、イノベーションを産む原動力を養っていきましょう。

心理的安全性をもたらすには

組織 マネジメント プラクティス 心理的安全性

この記事はEngineering Manager Advent Calendar 2021 4日目の記事です。

f:id:tune:20211122101448p:plain

心理的安全性という言葉が一般的になり、その重要性も、誤解(心理的安全性=ぬるま湯とか)も、訂正(心理的安全性は当人が決めるもの)も広まった状況かと思います。

心理的安全性を扱った記事はたくさん見かけるものの、「心理的安全性を高めるに具体的にどう行動したら良いのか?」という疑問に正面から答えた事例は少ないように感じます。ということで自分が普段行なっている行動や背景にある考えを紹介します。

ただ話す

チーム間の調整にもっとも良い方法は単純に、ただチーム間の調整をすることです。課題があれば自己管理されたチームの誰もが他チームの所に行って議論することが期待されています。もし、「ただ話す」ことが出来ない状況なのであれば、電話したり、最悪の場合にはメールを送れば良いわけです。調整の為に形式張った場は不要で、調整が遅れるだけです。立ち上がって話に行ってください。

これは大規模スクラムのフレームワークの一つ、LeSSで紹介されているプラクティスの1つです。 何か相談しないといけない時にマネージャーやリーダーに相談したり、定例会議を設けたり、調整役を設定したりすることをよくしますが、LeSSでは調整が必要になった時にただ立ち上がって相手のところに行き話すことを推奨しています。

チーム同士で調整が必要な項目はマネージャーを介さず話してもらっていますし、チームに対してのもやもやを相談された時は直接当人に伝えてみてはと話しています。マネージャーが間に入った方がうまくいくケースは少ないですからね

調整と統合 - Large Scale Scrum (LeSS)

"誰"の話をしているのかを明確にする。

「チームに言いずらい」という悩み相談を1on1で聞くことがありますが、その時は「言いづらい相手はAさんのことですか? それともBさん? それともCさんのことですか?」と名指しで聞くようにしています。1人1人の顔を思い出して考えてもらうと個別の人に言いづらいということはほとんどなく、大抵はチームや組織といったボヤッとした対象に対してなんとなく受け入れられないんじゃないかという不安感を抱いているケースがほとんどです。

対象をぼやかして話すと、さも抽象度の高い難問に取り組んでいる感じが出てしまうので、具体的に掘り下げてみましょう。 似たような話ですが「組織は話さない」というブログ記事が切れ味鋭くて好きです。

組織は話さないですよ｜qsona｜note

個人の問題ではなくプロセスの問題として扱う

「ただ話す」を実施してもらい、「誰の話か明確」にしても解決しない問題はあります。 1個人の望ましくない振る舞いが槍玉に挙げられることは少なくありませんが、この手の問題は「個人のコミュニケーションの問題」としてしまいがちです。 ですが一緒に働くメンバーを信じるならば、これは個人の問題ではなく「問題を生み出す背景プロセスの問題」なのではないでしょうか。

プロセスの問題を炙り出すには事例を複数集めて共通する背景要因を時間をかけて考える工数が発生しますが、個人の問題として安易に断じない姿勢をとり続けることで、問題をエスカレーションしても正しく議論されるという安心感が醸成できるのではないかと考えます。

聞きにくいことを率先して聞く

皆にしてほしい振る舞いを率先して行い、背中で見せることはよくあると思います。 私は言葉足らずだなと感じた説明があったら、意図を明確にするためにあえて聞くことを意図的に行なっています。

例えばあるルールが「"従業員"を対象に実施」と説明された場合、正社員の自分が対象者に含まれることは自明ですが、アルバイト・業務委託・インターン・契約社員のメンバーは悩むかもしれません。こんな時は「従業員にアルバイト・業務委託・インターン・契約社員は含まれますか?」とSlackチャンネルでオープンに聞いたりします。「マネージャーなので質問しやすいんでしょう」と思われているかもしれませんが、投稿する時はドキドキしています。役職者になってもそんなものです。

心理的安全性があるかのように振る舞う

心理的安全性の話が出るといつも引用してくる好きなスライドです。 マネージャーだからドキドキしても聞きにくいことを聞く、マネージャーだからメンバーを信じてプロセスの問題を探す、マネージャーだから皆が自律的に動けると信じて後ろで見守る。皆も同じような振る舞いを続けて自信がついてきた結果の先に心理的に安全な職場が実現できる。私はそう考えています。

おわりに

心理的安全かどうかは各々が感じる・決める話ではありますが、2021年夏に勉強会を開催した際に「今の会社は心理的に安全か?」とファイブフィンガー　(指1本：安全でない〜指5本安全である)で回答してもらったことがありました。私は指4本を出しましたが他のメンバーは指5本出していたので、そこそこ安全な職場が作れているのだと考えています。

そんなエンジニアリングマネージャーが考えていることの紹介でした。

チームトポロジーを読んで考えたこと

書籍 開発プロセス 組織 Team Topologies

チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計

チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計

Amazon

2021年12月1日にTeam Topologiesの翻訳 チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計 が発売になります。 本書のレビューに参加させていただき、翻訳者の皆様から一足先に書籍をいただきました。 レビュー時は「なかなか難しいな…」と思っていましたが、翻訳者の皆様の努力とカラー装丁の効果か、読みやすい本に仕上がっております。

チームトポロジーとはどんな本か

翻訳者の一人であるryuzeeさん始め、多くの方が既にまとめてくださっているのでそちらを参照するのが良いかと思います。

チームトポロジーは、このコンウェイの法則を踏まえたチームファーストのアプローチです。 「チーム構造と組織構造を進化させて、望ましいアーキテクチャーを実現する」という逆コンウェイ戦略を実現するために、4つのチームタイプと3つのインタラクションモードを定めています。 それをもとにフローを最適化する組織を設計しようというのが肝です。

自分の言葉で話すと「ソフトウェア開発体制」の定石を扱った本かなと思います。パターンランゲージとかが近いのかもしれません。 チームトポロジーの知見を踏まえつつ、状況に応じた開発体制のあり方を議論し見直していく。うまくいく状態を見いだせてから組織図に反映していく。本書とはそんな付き合い方が良いのではないかなと思います。

"ソフトウェア開発はこうしたらうまくいくんじゃないかな?"という経験や理論が体系化されている

「フロー(デリバリー、バリューストリームとか)を最大化する組織を目指す」「チームを基本単位として長く存続させる」「コミュニケーションパスを整理する」といった、ソフトウェア開発をうまくやるための知識が幅広く紹介・解説されており、関連する書籍や一次情報へのポインタもまとめられています。「サービスが成長し、人も増えて来て組織のあり方を見直したい」というのは"あるある"のよく聞く悩みですが、本書はそんな悩める人が手に取り読み、共通の知識・用語を使って議論を始める土台とするのにちょうど良いと思います。

自分は開発部門のマネージャーとしてチーム編成を見直すことが時々ありますが、チームにどんなコミュニケーションを取ることを期待しているか説明することができていなかったなと本書を読んで感じました。本書で説明されている3つのインタラクションモードは誤解なく伝えることができそうで、業務でも取り入れようと考えています。

逆コンウェイ戦略という用語の難しさ

本書のベースにはコンウェイの法則と逆コンウェイ戦略があります。

先に引用したryuzeeさんの説明も「チーム構造と組織構造を進化させて」とあるので、変えていくこと前提だと思うのですが、「目指すソフトウェアアーキテクチャの正解があって、それに合うように開発体制を作るんだ」と考えている人が一定割合いるんじゃないかなと感じることがあります。本書はそんなこと書いてないんですが、斜め読みして誤解する人が増えると嫌だなーとか用語が出てくるたびに頭をよぎります。

"ドメインの知識はあっても望ましいサービス責務が見えていない"は割とあるケースだと思っています。 ストリームアラインドチームのコラボレーションを促し、チームの責務を意図的に広く・曖昧にして議論を促すと良いのかなーとか考えたりするんですけど、逆コンウェイ戦略かと言われると違う気がしています。「脱コンウェイ戦略」とかなのかな?

ハブやコミュニティをどう表現するか

組織のスケーリングを扱った書籍だとコミュニケーションのハブとなる人材や、ノウハウマネージャーを置いたりして、コミュニケーションパスを短くするアイデアがよく紹介されます。Spotifyモデルのギルドのように職能や目的別のコミュニティを作るというやり方もありますが、これらはチームトポロジーではどう表現するとよいのでしょう。

仮想的なイネーブリングチームがあって、他チームをファシリテートで導いている気もするし、チームの一部メンバーがコラボレーションしているとも言える気がします。

ソフトウェア開発以外の組織体制はどうしていくといいんだろう?

サービスはソフトウェア開発だけで成立しないので、営業や企画など他部門を交えてフローを最大化していく必要があり、開発組織と合わせて進化させていく必要があると思います。チームトポロジーの考え方は使えるような気がするんですが、本書はソフトウェア開発に絞った話なんですよね。

チームトポロジーの狙いはあくまで明快なパターンの提供だとすると、もう少し具体化したルールを定義することで「アジャイルはソフトウェア開発にしか適用できないが、スクラムはソフトウェア開発以外にもで起用できる」ような状態にできるような・・・できないような・・・

他社の事例も聞きたい

読んで終わりにするのではなく、自社の状況を図示して整理し、共通の用語を使って議論できることにチームトポロジーの価値があると思っています。自社の開発体制を描いたものが手元にありますので、見てみたい方・議論したい方・ツッコミしたい方、お声がけください。

Meety or Meetyのグループディスカッションを考えたのですが、クローズよりはオープンな勉強会とかの方が良いのかなと思ったり。何社か集まってできるといいな。

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

LeSS アジャイル スクラム コミュニケーション プラクティス プロダクトマネジメント スクラムマスター スプリントレビュー ファシリテーション

社内でアジャイル開発を議論するSlackチャンネル #tech_agile に見かけた良記事のまとめです。この記事は第7弾で2年目に突入しました！

ノウハウ・知見

Ryuzeeさんがまとめてくれたアジャイルに関するFAQ

これもよいし、Waicrew 角さんのも良いまとめだなと思っています。

www.ryuzee.com

山型クロスファンクショナルチーム

クロスファンクショナルチーム/フィーチャーチームを組もうとすると「全部触れるようにならないとダメですか?」と質問がいつもくるのでこういう考え方もあるよって広まってほしい。

Miroの便利機能まとめ

有償でしか使えない機能があったりするので色々探検が必要。

note.com

短期と長期両方大事

理想論から長期目線に引っ張られることが多いけど、短期でも成果を出していくことは大事。

yattom.hatenablog.com

スクラムフェス三河キーノートスピーチ書き起こし

ありがたい

logmi.jp

カイゼン・ジャーニー・カンファレンス - プログラマのジャーニー

3年前の発表資料のようですが何かの拍子にふと見かけて良い内容だったので

しいばさんと咳さんとみわさんの雑談

タイミング合わなくて聞けなかったのが残念。

咳チームのことを考えると、自分の中の不純物に気づくことができるから。

これわかります。

aki-m.hatenadiary.com

bufferings.hatenablog.com

「心理的安全性おじさん」になっていませんか?

概念じゃなくて現場に寄り添いましょう。

www.nakahara-lab.net

余白を作り、埋める動きをする

自分が社内でやっている動きに近い。

他社事例

atama plusのスプリントの紹介記事

スプリントレビューで500件コメント出るのはすごい。見学に行ってみたい。

note.com

atama plusでLeSSを取り入れたことのエンジニア感想

Rettyと大差ないねーという声がありました。

note.com

Twitter

オンラインのアイスブレイクにはしりとりがおすすめ

うまくいかない時は自分と周囲の状況把握こそ大事

仕様通り以上の品質にチャレンジしているか

すぐできる改善はさっさとやろう

ミーティングなんか出てないでディスカバー行ってこいよ

入社したばかりの人に「次にこの人と話すといいよ」というテレフォンショッキング形式 1on1をやるとよい

Rettyでも次に入社した人にやってあげようと思っています。

改善項目の選び方

ほんとこれ

デプロイを自動化したいというPBIはHowを表している

Keepを考えるのが苦手な方へ

POが決める優先順位にはフィードバックをあげる必要がある。

Minimum Viable Productを作るイメージ

mobile.twitter.com

ステークホルダーの紹介をきちんとしてあげよう

スクラムフェス三河 2021でスクラムマスター育成の話をしてきました #scrummikawa

カンファレンス アジャイル スクラムマスター スクラム Scrum Fest Mikawa

はじめに

スクラムフェス三河でスクラムマスターの育成について話してきました。今年は会社からも5名の登壇者が出ており、普段の業務を通じた学びをコミュニティに少しは還元できたかなと思っております。

https://confengine.com/conferences/scrum-fest-mikawa-2021/proposal/15593

資料をSpeaker Deckに公開していますが、はてなブックマークのホットエントリ入りした効果か、スクラムフェス三河の参加者以外にも読まれているようですので、当日の発表・スクラムフェス三河のDiscordで捕捉した事項も本記事で紹介しておきます。

発表の捕捉

なんでこんな話したの?

アジャイル・スクラム系の情報発信、勉強会・カンファレンスで多く登壇機会をいただいているおかげか、「うちも(大規模)スクラムやろうと思っているのですが、少し話を伺えませんか?」というお話をいただく機会が少なからずあります。数社お話して毎回質問されるのが「チームが増えたときにスクラムマスターの成り手がいないのですがどう対処したのですか?」というものです。最初はその会社固有の課題なのかと思いましたが、話を伺った会社全てに聞かれた気がしたのでこれはひょっとして普遍的な悩みなのかと考えるようになりました。あまりにたくさん聞かれたので、このブログでも5月に一度記事を書いています。

tune.hatenadiary.jp

あらためて読み直すとスクフェス三河発表スライドよりも情報量多いですね💦

リーダー・管理職は、どうしてスクラムマスター不向きなの?

「権力勾配を使って自分の意見を押し通しやすい」ため、"名前を付け替えただけで何も変わってない"状態に陥りやすいと思っています。

※リーダー=会社・組織で定義されているチームリーダーのような役職を指してます

「スクラムがやりたい人」は、どうしてスクラムマスター不向きなの?

熱意があるのは素晴らしいのですが「本に書いてあるからこのやり方が正しい！あの人はスクラムの勉強が足りてない！！異論は認めない！！！」という対立構造を引き起こしがちな気がしています。私たちは価値提供・課題解決をしたいのであって、スクラムをやりたいわけではないはずです。

悩み続ける人はスクラムマスターに向いているの?

メンバーからの「どうしてスクラムだとこういうやり方をするんですか?」という質問に対し、自分たちの言葉で答えを考え続ける方が、その組織にあった良いやり方に辿り着ける確率が高いと思います。

スクラムマスターは役割なの?

スクラムガイドを参照したところ「責任」と言う表現を使っていました。

スクラムチーム全体が、スプリントごとに価値のある有⽤なインクリメントを作成する責任を持つ。 スクラムはスクラムチームにおいて、開発者、プロダクトオーナー、スクラムマスターという 3 つの明確な責任を定義する。

スクラムガイド 2020版

いずれにせよ、「スクラムチーム全体が、スプリントごとに価値のある有⽤なインクリメントを作成する責任を持つ。」なので、スクラムマスター一人が勉強して、スクラムの全てに責任を負わせているような体制は良くないと思います。

開発者兼任のスクラムマスターってどうなの?

「専任はダメ」としているのではなく「専任でも兼任でもいいよ。結果的に全員兼任を選んでいるよ」という状態です。 スクラムマスターに話を聞くとームの状況に応じ、開発に割く時間は増やしたり減らしたりしているそうです。 「他の開発者と同じぐらいコード書いてね」という前提がなければ良いと私は思うのですが、専任にすべき派の意見も聞いてみたいところです。

スクラムを好きになってくれるかもわからないのに「あなたはスクラムマスターになったのだから真のリーダーとしてサーバントリーダーシップを発揮し、スクラムチームとその外の組織に奉仕する必要がある」と言われても困ってしまうと思うのです。

教科書通りやることが何より難しいんだけど

「教科書通りやることだけ」を注文すると案外できますよ。 最初からいろいろスクラムマスターに色々求めすぎているのでは?

「スクラムマスターじゃなかったら」という前提条件の外し方はどういうこと?

スクラムでの正解が欲しいのか、問題に対しての打ち手が欲しいのかでいうと、ほとんどのケースは後者だと思うのです。

スクラムマスターとしてはお給料上がらないということ?

スライドの表現が紛らわしかったなと思っています。

  • エンジニア共通のグレード定義がされており、社員はいずれかのグレードに分けられる (よくあるグレード制度・役割等級制度)
  • 「スクラムマスターは役割」であり、どのグレードに所属していもスクラムマスターになれる
  • グレードで定義された役割・成果が果たせていれば昇格する。

スライドで伝えたかったことは下記です。 - エンジニアのグレード定義とは別にスクラムマスターのグレード定義を用意しているわけではない。 - スクラムマスターの次に、シニアスクラムマスターとかアジャイルコーチのようなキャリアパスを社内で整備しているわけではない

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

開発プロセス 育成 組織 採用 マネジメント

はじめに

今流行りの 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月に社内で共有したアジャイル開発関連の記事

LeSS アジャイル スクラム コミュニケーション プラクティス プロダクトマネジメント スクラムマスター スプリントレビュー ファシリテーション

社内でアジャイル開発を議論する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]