エンジニアリングマネージャーのチームでスクラムをやってみた
Engineering Manager Advent Calendar 2023 11日目の記事です。
こんにちは！
カミナシでエンジニアリングマネージャーとして働いております、吉永です。
今回はカミナシのエンジニアリングマネージャー(EM)が、スクラムの考え方をマネジメントに活かしてみたよ、という事例とそこから得られた学びを共有したいと思い筆を取りました。
複数のEM間の連携や、マネジメントスキルの伝達に悩んでいるEMの方にとって助けになれば幸いです。
前提
私（Mgr of EMs）がマネジメントしているチームは以下のような構成です。
チームAとチームBは同じシステムを担当しています。担当する機能を分けることでチーム間の依存関係が極力少なくなるようにしています。
チームAとチームBにはそれぞれEMがいて直接メンバーをマネジメントをしています。
チームAとチームBの両方が私の担当範囲で、EM間で連携しながらマネジメントしています。
課題
この体制になってからの問題として、以下のようなものがありました。
マネージャー育成の問題
各チームを直接マネジメントしているEMは、マネージャー経験が長くない、または、これから正式にマネージャーになろうとしている段階です。私は比較的マネージャー経験がある方なので、彼らにマネージャーとしての成長を支援してあげたいという思いがありました。ただ、私も間接的なマネジメントの経験が豊富なわけでもないため、どうすればいいのかようわからん、という課題がありました。
チーム間の連携をなめらかにしたい問題
チームAとチームBは同じシステムを開発し、運用しています。担当する機能は分けているものの、扱うコードベースは同じです。この状態だとチーム間の依存関係を無くすことはできず、他チームにレビューを依頼したり、他チームのデプロイをブロックしたりする状況が発生します。このため、チーム間の連携をなめらかにして依存関係を極力減らす必要がありました。
マネージャーのやっていること見えにくい問題
組織が拡大すると、組織構造は階層化、複雑化していきます。そうすると、どうしても情報の対称性が失われやすくなります。特にマネージャーの業務は可視化が難しく、えらく忙しそうではあるが一体何をやっているのじゃ・・？と思われてしまいがちです。また、情報の非対称性に気がつけずに、メテオフォール型の意思決定をしてしまい、メンバーの納得感が生み出しにくい状況も発生していました。
解決策：なぜスクラム？
だいくしーさんが今年執筆された、 「スクラムの拡張による組織づくり」 を読んだことがきっかけです。
当時、スクラムの拡張も検討したかった私にとって、非常にタイムリーな本でした。「スクラムのスケールは安易に選択すべきでない」と書かれてあり、勇気づけられました。また Scrum@Scale のプラクティスや会議体などは大変参考になりました。
そこで原点に戻って、スクラムガイド2020 をもう一度読み返してみると、その冒頭の内容であるスクラムの定義に衝撃を受けました。
スクラムの定義: スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、⼈々、チーム、組織 が価値を⽣み出すための軽量級フレームワークである。
→ 私たちEMチームも、まさに複雑な問題に対応することが求められています。スクラムの価値は経験的に理解しており、スクラムを通じてチームが成長していく過程を私は知っています。また、私たちはスクラムの三本柱「透明性・検査・適応」のうち、透明性が不足しているが故に困っているのではないかと思えました。
そこで、二人のEMに「僕らEMチームでもスクラムをやってみない？」と提案し、その意図を説明したところ、快く「やってみよう！」と言ってくれました。2023年8月くらいの出来事です。
実施したこと
スクラムガイドの通り、スクラムをなるべくそのまま実践しようとし、結果的に以下のプラクティスを取り入れました。
プランニング:
今週のスプリントゴールを話し合って決める。スプリントゴール達成に必要なタスクをスプリントバックログに積む。
デイリースクラム:
毎日15分決まった時間に集まり、バックログの確認をする。
レトロスペクティブ:
スプリントゴールが達成できたか、できた理由、できなかった理由を探る。
各チームのレトロスペクティブで話したことや、次のスプリントのスプリントゴールを共有する。
一方で、スクラムをそのまま実践できなかったのは、以下でした。
スプリントレビュー:
ステークホルダーにとってわかりやすいインクリメントを示すことが難しいと思い、断念しました。
プロダクトオーナーとスクラムマスター:
3人の少人数なチームなので、これらは兼務で十分と判断しました。
効果
3ヶ月ほど続けていますが、複数の良い効果があったと思っています！
チームでマネジメントしているという安心感
デイリースクラムで毎日顔をあわせることができるのは安心感に繋がりました。Slackには書きにくいけど、ちょっと相談したいことを話せる場としても機能していました。
やるべきことにフォーカスできる
スクラムのプラクティスにより、透明性・検査・適応を活用することができました。スプリントゴールが未達に終わり、バックログアイテムが全然終わらずにスプリント終了した時に、「1週間前達成したいと思っていたことが、そうなっていないのはなぜなんだろう？」「優先順位を上げられていないけど、ほんとにこれでいいのかな？」という会話がレトロスペクティブで生まれました。
EMsで今やるべきことを自ら定義して向き合い続ける、ということができるようになりました。
タイムリーに連携できる
Slackの非同期でのコミュニケーションでは補いきれなかったことを補完できるようになりました。確認漏れや締め切り直前の状態を相互にチェックすることができ、以前よりもチームに対するメッセージングがうまくいくようになりました。またマネジメント系のタスクのボールを誰が持つか、相談して決めるので、ボールが宙に浮く状態が少なくなりました。
透明性高くマネージャーチームとしての力を引き出せる
組織に関してふと思いついたアイデアはそれぞれバックログアイテムに起票して、スクラムイベントで共有する動きができるようになりました。3人の知恵を集結し、相互にレビューしあうことで、一人では得られなかった視野の広さをもてるようになり、組織をさらに良くしていくための選択肢の幅出しや、アクションの質に良い効果が得られました。また、バックログはエンジニアが誰でも見れる場所にあるため、マネージャーがどんなことを考えているのか共有する効果も得られました。
今後
良い効果は感じられているものの、これに満足せずに更なる変化を遂げられると良いなと思っています。そのためにもいろんなフィードバックを積極的にもらえると嬉しいです。
以上です！
最後に、私たちと一緒に働いてみませんか？という宣伝です！私たちに興味をもっていただけたら、まずはカジュアルに話してみませんか？会社の採用ページや Wantedly などからコンタクトとっていただけると嬉しいです。お待ちしています😃
この記事が気に入ったらサポートをしてみませんか？