6
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

リーダー不在で回らなくなったチームが、スクラム的アプローチで「自走」を取り戻すまでのストーリー

Last updated at Posted at 2025-12-10

この記事は Schoo Advent Calendar 2025 の11日目の記事です。

はじめに

こんにちは!布袋寅泰が大好きなエンジニア、こうざい(@yukhy_BE)です。
Schooでは、技術戦略部門・インフラチームに所属しています。クラウドインフラを中心に触っています。

今回は、私が所属するインフラチームでこの1年で取り組んだチームビルディングについてお話しします。

私たちのチームは、とあるきっかけから、トップダウン型の組織だったチーム運営をメンバー一人ひとりが自律して動く組織へシフトチェンジすることを余儀なくされました。

本記事では、そのきっかけと、どのようにして自律的なチームへと変わっていったのか、その過程での失敗や得た学びを共有します。同じようにチーム運営に悩むエンジニアの方にとって参考になればと思います。

背景:リーダーへの依存と、その後の混乱

かつて私が所属するインフラチームは、良くも悪くも一人の強力なリーダーに依存していました。
決断力の高いリーダーが戦略戦術を決定して、メンバーは確かな技術力で実践する。このトップダウン体制は意思決定が速く、効率的な業務遂行のあり方と思われていました。

しかし、リーダーの転職に伴いチームに大きな混乱が生じることになります。
残されたのは、「個」として仕事をまっとうするプロフェッショナルなメンバーたちと、当時入社3年目を目前に控えていた私です。

それまではリーダーが情報のハブとなってタスクを割り振っていたため、メンバー間の横の連携は希薄でした。リーダー不在の状況下では、誰が何をしているのかお互いに把握できておらず、次に何をすべきかの判断軸も曖昧な状態で、チームというよりも、個人の集まりであるグループに近い状態でした。

当時の私は、このチームがチームとして存続し、会社や社会に貢献し続けるためには、根本的にチーム運営を見直さなければいけないという強い危機感を抱いていました。

やったこと1. 週次報告の限界と日次共有への転換

最初の改善は、コミュニケーション頻度の変更です。 もともとのチーム定例は、「週に1回・30分」のみでした。

強力なリーダーが在籍していた頃は、彼が週の途中でも適宜指示を出し、細かな軌道修正を行うことで業務が回っていました。しかし、リーダー不在となってからは状況が一変しました。「次の定例までの1週間」というタイムラグが、生産性低下の要因となっていたのです。

1週間、情報を同期する場がないまま作業を進めた結果、以下のような問題が多発しました。

  • 手戻りの遅延: 定例の場になって初めて認識齟齬が発覚し、大幅な修正が発生する。
  • 属人化による停滞: 突発的な課題を発見した人がそのまま着手することで、本来進めるべきだったタスクが止まってしまう。
  • 優先順位の迷走: 「今、何をするのが最適か」の判断がつかず、優先度の低いタスクに着手してしまう。

デイリーMTGの導入

そこで、毎朝15分、状況を同期する場(デイリーMTG)を導入しました。

インフラチームは突発的なアラート対応や割り込みタスクが頻繁に発生します。この「不確実性」に対処するには、日次の同期が最適でした。導入により、主に以下の効果が得られました。

  • 負荷の分散: 「Aさんが重い作業中だから、アラート対応はBさんが巻き取ろう」といった柔軟な連携が可能になった。
  • 状況の透明化: 誰が何をしていて、どこで詰まっているのかを全員が把握できるようになった。

さらにデイリーMTGとは別に時間を設け、設計内容や対応方針についてメンバー間で相談できる場を作りました。これにより異なる視点で課題を捉え、技術的負債の発生要因をあらかじめ排除できるようになったことが大きな成果だと考えています。

やったこと2. チームとしての成果を最大化するためのスプリントの導入

次に直面した課題は、タスク管理の形骸化です。

バックログには数ヶ月前のチケットが山のように積まれ、優先順位も曖昧なままとなっていました。チームは目の前のタスク消化に精一杯で、「今、チームとしてどこに向かっているのか」という、進むべき道筋が見えにくくなっていました。個々がどれだけ頑張ってもベクトルが分散しており、チームとしての成果が最大化されていない状態でした。

そこで、スクラムのフレームワークを参考に、2週間のスプリントを導入しました。

プランニングの実施

以前は、バックログに蓄積された大量のタスクから都度チケットを拾っていましたが、スプリント導入に合わせて、「この2週間で何を達成するのか」を決める時間(プランニング)を設けました。

このプロセスには以下の効果がありました。

  • チケットの棚卸し: 2週間ごとにバックログを見直す強制力が働き、賞味期限切れの不要なタスクが滞留しなくなった。
  • 目標への接続: 「なぜこの作業をやるのか?」を問いながら計画することで、チームや会社の目標に直結するタスクへ集中的にリソースを割けるようになった。
  • 意思決定コストの削減: 期間中にやるべきことが明確になったため、「次は何をやろうか?」と都度迷う時間がなくなり、作業に集中できるようになった。

これにより、個人の頑張りを分散させず、チームとして重要な一点に集中できるようになったと感じています。

失敗談:「時間」ではなく「ポイント」で見積もる

プランニング導入当初は、「このタスクは3時間」といった時間(絶対見積もり)による見積もりをしていました。

しかし、インフラ作業は検証してみないと分からない挙動など「未知の要素」が多く、見積もり通りに進むことは稀でした。見積もりを担当するメンバーも、「本当にその時間で終わるか?」というプレッシャーから、自信を持って時間を提示することに難しさを感じていました。

そこで、スクラムではお馴染みのポイント(相対見積もり)へ切り替えました。これは「基準となるAタスクに対して、Bタスクはその2倍の複雑さがある」というように、タスクの重みを相対的に比較して数値化する方法です。

「正確な終了時間」を当てることよりも、「チームとして2週間でどれくらいの総量(ポイント)を消化できるか」に重点を置いた結果、計画の精度と納得感が大きく向上しました。

ポイントを判断する際に使う基準の例

ポイント タスクの例 必要な時間の目安 タスクの不確実性のリスク
1 ・Route53 の TXT レコードを 1 行追加
・Datadog monitor の閾値を微調整
数分 極小
2 ・ArgoCD の Application YAML を 1 ファイル修正して再デプロイ
・ALB のリスナールールを 1 つ追加
数時間 極小
3 ・CloudFront の TTL を短縮し、Athena で軽い効果検証
・ECS/EKS のタスク定義に環境変数を追加し、全環境反映
1日
(8時間程度)
5 ・新しいサービスのために ALB + TargetGroup を追加
・WAF ログの Athena テーブルに新しいフィールドを追加し、既存ログとの互換確認
数日
8 ・EKSバージョンアップの調査と開発環境の移行
・本番・ステージング全 CloudFront の TTL 統一化と動作検証
1週間
13 ・Terraform/Terragrunt の環境統合・大規模リファクタ
・ログ基盤の移行
2週間~1か月

やったこと3. レトロスペクティブによる自律的な改善

期間を2週間に固定したことのもう一つのメリットは、「レトロスペクティブ(振り返り)」が習慣化したことです。これは、他メンバーの発案により実施が決まりました。

手法としては、一般的なKPT(Keep, Problem, Try)に、具体的なアクションを決めるTodoを組み合わせた形式で行っています。

  • Keep: 良かったこと、続けたいこと
  • Problem: 発生した問題、不安に思ったこと
  • Try: 解決に向けてやってみたいこと
  • Todo: Tryをもとにチームとして「やること」、あるいは「あえてやらないこと」

「個人の改善」から「チームの改善」へ

これまでは個人の発案で散発的に改善がなされることもありましたが、「チーム」を主語にして全員で振り返る機会ができたことで、主体性が大きく高まりました。

個々のメンバーが得た学びや失敗が共有され、即座にチーム運営に還元されるというこのサイクルは、「学習」に重きを置くSchooの行動指針(Philosophy行動)にも沿った活動だと感じています。

さいごに

一連の改善により、チームをトップダウン型から、メンバー主導の自律的な形へと大きくシフトさせることができました。「誰かが決めてくれる」という受動的な状態からの脱却は、メンバー個々の当事者意識を高め、心理的安全性も大きく向上したと感じています。

しかし、組織構造の変化には常にトレードオフが伴います。現在の課題は、意思決定スピードの維持です。「みんなの意見を聞く」ことを重視しすぎると、議論が発散しやすく、決定までに時間を要する場面が増えます。緊急時の対応や意見が割れた際の収束といった、決断までのプロセスにはまだ改善の余地があります。

民主的なプロセスを尊重しつつも、必要な時には迅速に決断して実行へ移す、「スピード感」と「納得感」を両立できるより強いチームを目指して、私自身がチームをリードできる存在に変わっていきたいと思います。

本記事のまとめ

  • 情報の透明化: デイリーMTGで「個人の作業」から「チームの状況」へ視座を上げる。
  • ゴールの共有: スプリント導入で、バックログ消化ではなく「目標達成」にフォーカスする。
  • 継続的な改善: 振り返りを習慣化し、チームの運営方法をアップデートし続ける。

Schooでは一緒に働く仲間を募集しています!

6
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
6
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?