CycleTechLog (サイクルテックログ)

cycling, map and gis technology, and myself.

スクラムを大人数で運用したところ💩な結果になった。

言いたいことを3行で

  • 関係者を増やすのは慎重に
  • プロダクトから強制的に引き離された開発者は愛着をなくすよ
  • プロダクトが何をやりたいかが重要

背景

国内にある地理的に離れた3拠点のオフィスで、大きな2つのプロダクトと無数なWeb、API群、データ生成などのサーバを持った部署がある。

今まで、メンバーはそれぞれ持っているプロダクトに対して別チームや属人として対応していた。

エンジニアのリソースを2つの大きなプロダクトに注力したいため、全員のリソース配分を可視化・最適化をするために大規模なスクラムLeSSの要素を取り入れた体制を作り1年超運用した。

振り返ると

開発体制の運用に1年超、参加した体験を次に活かしたい、 という振り返ると以下のメリット・デメリットがあるように思う。

メリット

  • 今まで見なかった人、プロダクトに関われるのは面白い
  • ベロシティ(達成pt数)という形でチームの貢献度が表されて、みんなが働いている状況を数字で共有できる

デメリット

  • 関係者が増えたおかげで、責任が不明瞭になり物事の決めごとに労力と時間がかかる。 1週間のスプリントで、見たこともないプロダクトの見積もりと学習をし、数チームと合意し、複数のSMと合意するのは無理ある。
  • スクラムに不慣れな人間がたくさんいる状況は仕方がないが、習熟と効率化が発揮されるのが遅い。 人の入れ替え、組織変更を挟むと初期化される...
  • ベロシティを重視するために、無理に計測期間で対応しようとしてプロダクトが壊れる。事故が多くなる。 また、余裕があるときも、がんばると次のスプリントのベロシティ基準が高くなる力学が働くので、ほどほどにしようとしてしまう。
  • 注力以外のプロダクトから人を引き剥がすと愛着がなくなり、放置され壊れていく。 プロダクトオーナーをアサインするだけでは運用できない。

f:id:ctyo:20181117145156j:plain ※適切に案件管理された結果、公平にポイント付けされたissueが積まれ、消化されないの図 フリー写真素材ぱくたそ

考えのまとめ

2つの大きなプロダクトをグロースさせるために、トライアンドエラーとリリース速度をあげたかった。

そのために、人的メンバーを増やしたかったはず。そのような背景もあって、トップダウンで案件が降ってくる形になり現場での改善活動ができなかった。また、エンジニアのみでスクラムチームで動いていたのは良くなかった。

開発以外のノイズが増え、集中してプロダクトに向き合う環境がなくなっていたように思う。

普通の話だけど、権限と責任の移譲をしっかりやって、コンパクトな組織を維持できるようにしたほう良いと思った。

人間なので関係者が増えると、コストが調整コストが増えて、効率は下がる。 ゆるい横のつながりは良いけど、チーム責任範囲を決めて落ち着いた状況をつくるのが大事だと思った。

当初の目的の大きなプロダクトのグロースをしたいときには、機能単位や画面でコンポーネントをうまく割って、 小さいチームで無理なく開発できるようにするのがいいんじゃないの?と、将来同じ轍を踏まないようにしようと思ってます。

また、小さく始めず無配慮に大規模にスクラムアジャイルを導入しようとする人間を警戒しようと思うようになった。