教科書通りのスクラムは、複数案件を兼任する制作チームにはそのままは合わなかった ― EMの試行錯誤

スクラム開発に慣れた私が、自分の部署をスクラムで良くしようとして、最終的にスクラムを捨てた話です。

XRコンテンツ制作の部署でエンジニアリングマネージャー（EM）をしていたとき、私はスクラム開発の発想を持ち込んで、業務効率を改善できないか試行錯誤しました。

結論から言うと、最終的にできあがった体制は、スクラムとは全然違うものになりました。

ただ、その部署の業務効率は大幅に向上させることができたので、これはこれで良かったと思っています。担当した3年間で、私が関わったものだけでも延べ40案件を納品しました。

教科書通りのスクラムにこだわるよりも、チームの構成に合わせて会議体や進め方を設計し直すことのほうが大事だった、という話を書きます。

これは特定の部署での私個人の体験・見解です。「スクラムが悪い」という話ではなく、「ある前提のチームには、教科書通りのスクラムがそのままは合わなかった」という体験談として読んでください。むしろ私は、スクラム開発を8年以上続けていて、スクラムマスターの認定資格（PSM I）を取るくらいにはスクラムが好きです。

私がいた部署：少人数で常に5案件が並行する受託制作チーム

まず前提から。私がEMを担当していたのは、受託でXRコンテンツ制作をする部署でした。XRコンテンツ制作と一口に言っても作業の幅は広く、たとえば以下のようなものが含まれます。

• 3Dモデリング
• 3Dアニメーション制作
• Unityシーン制作（C# などのコーディング含む）
• シェーダー開発（HLSL など）
• 描画負荷の軽減
• AWSインフラ構築（CDN など）
• REST API 開発

チームの体制としては、こんな前提でした。

• 私を含めて5〜6人の少人数チーム
• 常に5案件くらいを同時に抱えている
• 納期も納品先もまったく違う

人数だけ見ると小さなチームですが、実質1人1案件という高稼働状態で、納期も納品先もバラバラの案件が常に並行して走っている、という状況でした。プロダクト開発のように「チーム全員が1つの成果物に向かう」状態とは、前提がかなり違います。ここが後で効いてきます。

図にすると、こんなイメージです。プロダクト開発が「全員で1つのゴールを見る」のに対し、私の部署は「1人が別々のゴールを見る」状態でした。

元の体制：1案件＝1人。そして全部が暗黙知になっていた

私が加わる以前、この部署は「1案件につきメンバー1人を割り当てる」という体制でした。手が早いメンバーだと、1人で2案件を抱えていることも普通にありました。

一見すると、各自が自分の案件に集中できて効率的に見えます。ですが、これには大きな弊害がありました。ノウハウがメンバー個人に閉じてしまうのです。

• その案件のことは、担当者しか分からない
• 進め方も、ハマりどころも、全部が暗黙知になる
• 他のメンバーが助けたいと思っても、暗黙知だらけで手が出せない

担当者が1人いなくなったら詰む、という状態が常にありました。「これはやばい」と感じたのが、改善のスタートでした。

暗黙知を開くには定例が要る。でも、新参者がいきなり会議は増やせない

属人化を崩すには、案件をまたいでノウハウを開く場 ―― つまり何らかの定例が要る。これは早い段階で見えていました。担当者の頭の中にしかない知見を、定期的に外へ出す仕組みがなければ、暗黙知はいつまでも暗黙知のままだからです。

ただ、ここで素直に「じゃあ週1で共有会議をやりましょう」と号令をかけることはできませんでした。当時の私はこの部署に加わったばかりで、まだメンバーの信頼を得られていなかったからです。

メンバーは全員、自分の抱える案件で精一杯です。そこに、現場の苦労をまだ知らない新参者がやってきて、いきなり「会議を増やします」と言ったらどう見えるか。十中八九、「現場を分かっていないのに、安全地帯から指示してくる面倒なヤツ」と思われて終わりです。実際、こういう場面では「みんな忙しいのに、なんで更に会議を増やすんですか？」という反発が出るのが自然だと思います。

会議体そのものは必要。でも、それを正面から増やすと拒否される。この矛盾をどう抜けるかが、最初の課題でした。

だから「会議」ではなく「ヒアリング」から始めた

そこで私が取った建て付けは、「会議を増やす」ではなく「私にヒアリングさせてほしい」でした。

具体的には、こう持ちかけました。みんなの案件で共通して使える部品を私が作りたい。そのために、週1回だけ、それぞれが何をやっていて何に困っているかを聞かせてほしい ―― と。

ポイントは、負担をかける側が私だということです。メンバーに何かを報告させるのではなく、私が話を聞きに行き、私が手を動かして共通部品を作る。メンバーから見れば「自分の手間が減るかもしれない場」であって、「報告のために拘束される会議」ではありません。

この建て付けにしたら、メンバーからも歓迎されました。週1回のヒアリングという、ごく軽い形でスタートできたのです。

まず手を動かす：共通部品化で「次の案件で楽をする」

ヒアリングで集めた「みんなの困りごと」をもとに、最初の数ヶ月は私が自ら手を動かしました。案件をまたいで共通する部分を、部品化・再利用できる形に整えていったのです。

受託制作は案件ごとに違いますが、作業を分解すると意外と共通要素があります。XR/Unityの制作だと、案件が変わっても「これ前にも作ったな」という処理が繰り返し登場するのです。じっさいに私が共通部品として切り出したものには、たとえば以下のようなものがあります。

• プレイヤーの位置に応じて、表示するものを切り替える機能
• 体験者がVRコントローラーを誤って操作して体験が中断してしまわないよう、コントローラーのボタン操作を無効化する処理
• 遠くにあるものほど透明になるシェーダー
• 画面に表示する文言を、サーバーからリアルタイムに差し替える機能

どれも、案件が変わるたびに「またこれ作るのか」と地味に消耗していた処理ばかりです。一度ちゃんと作って部品化しておけば、次の案件でそのまま、あるいは少し手直しするだけで使い回せます。だから、案件ごとに毎回ゼロから頑張るのをやめて、再利用できる形（モジュール化）に寄せていきました。

ここで意識したのは、とにかく自分が先に動くことです。共通部品をメンバー全員で考え、分担して作るのが理想ではあります。しかし、各自が自分の案件で精一杯の状況でそういう理想論を語っても、結局は前述のとおり煙たがられて終わりです。まず自分が動いて「これがあると次の案件が楽になる」という実物を見せるのが、結局いちばん早いと感じました。

具体的には、「こういう部品があるとみんな便利だと思うから、もう作っておきました」という感じで、ヒアリングで集めた困りごとへの成果物を、週1の場で発表するスタンスでのぞみました。これを続けて数週間経つと、他のメンバーも「私もこういうの作ってみました」と乗ってきてくれるようになりました。これは本当に嬉しかったです。「面倒なヤツ」ではなく「みんなの課題を解決してくれる頼れる人」として認められること。定例を機能させるには、この立ち位置を最初に作ることが大事だったと思います。

意識していたのは、シンプルにこういう方向です。次の案件で楽できるものを、少しずつ増やしていく。進捗を報告し合うより、こうやって「共通土台」を太らせていくほうが、このチームには効いたと感じています。

週1のヒアリングが、ノウハウ共有の場に育っていった

私が共通部品を持ち寄り、メンバーも自分の工夫を持ち寄るようになると、週1の場は自然と性格を変えていきました。最初は私がヒアリングする場だったのが、メンバー同士でノウハウを共有し合う場になっていったのです。

そこで話されるのは、こんなことです。

• 今週はこんなことをやった
• この部分、誰か手伝ってほしい
• こういう手法を編み出した

繰り返しになりますが、これは進捗報告会ではありません。案件が違う以上、進捗を聞いても「へぇ」で終わります。狙いはあくまで、閉じていたノウハウを開いて、案件をまたいで再利用できる状態にすることでした。

なお、スクラムでいうレトロスペクティブに少し似ていますが、レトロは「同じチームが同じプロセスを振り返る」場です。ここでやっていたのは「別々の案件を持つメンバー間でのノウハウ流通」なので、目的は近いようでけっこう違います。

この場のおかげで、徐々に1つの案件を2人以上で担当しやすい環境に移行できました。担当者が1人に閉じる状態が減り、属人化のリスクが下がっていきました。

ただ、この移行には弊害もありました。1案件を複数人で見るようにした結果、メンバーは常に複数案件を兼任することになっていきました。この「全員が複数案件を掛け持ち」という状態が、次の判断に効いてきます。

デイリースクラムを入れようとして、やめた

ノウハウ共有がうまく回り始めたので、私は次にデイリースクラムのような「毎日話す場」を作ろうかと考えました。スクラムに慣れた私からすれば、ここまで来たら毎日のデイリーを入れるのが当然の次の一手 ―― そう信じて疑いませんでした。

でも、やめました。

理由はシンプルで、同じ部署ではあっても、同じ案件を担当しているわけではないメンバー同士だからです。

毎日集まっても、案件が違えば話すことはそんなにありません。私のチームでは、話すことがない会議はあっという間に形骸化してしまうだろうと感じました。

ここで大事なのは、デイリースクラムを誤解しないことです。デイリースクラムは本来、進捗報告会ではなく、同じスプリントゴールに向かうチームが、その日の計画を検査・適応するための場です。つまり「共有すべき同じゴール」があって初めて機能します。

私の部署のように共有するゴールがないチームに、形だけデイリーを持ち込んでも、機能するはずがなかったのです。

気づき：会議体の粒度は、チーム構成に合わせて決める

ここで私は気づきました。なんとなく「教科書通りにデイリースクラムを入れればいいだろう」と安易に考えていたけど、そうじゃない。会議体の粒度は、チームの構成に合わせて設計すべきだったのです。

私の理解では、スクラム開発は「同じ案件（プロダクト）を共有するメンバー同士で組む」ことを前提としたフレームワークです。同じゴール、依存関係、チームで持つ意思決定 ―― これらが揃うからこそ、短い周期での擦り合わせが効きます。

だとすると、部署全体に1つのスクラムを敷くのは、前提からして合いません。ゴールも納品先もバラバラだからです。

じゃあ「案件単位でスクラム」は？

「部署単位が無理なら、案件単位でスクラムを回せばいいのでは？」とも考えました。各案件は、確かに1つのゴールに向かうチームに近いからです。

でも、これもやめました。

5案件が同時並行している中で、5件分のスクラムを全部導入することになります。ほぼ全員が複数案件を兼任している状況では、1人が複数のデイリーやスプリントイベントに出ることになり、会議負荷が膨れ上がって破綻します。複数チームにまたがるスケーリングの手法（Nexus や LeSS など）もありますが、5〜6人の当部署ではそこまでの仕組みは現実的な選択肢ではありませんでした。

スクラムの「良さ」は分かっていても、このチーム構成では素直に適用できなかった、というのが実感です。

では会議体はどう設計したか

最終的に落ち着いた形は、こうです。

1. 案件単位の会議 ＝ スプリントレビュー的な役割

案件ごとに、社内関係者・クライアント・取引先がまったく異なります。そのため、案件単位の会議体はそれぞれ存在します。

これはある意味、スクラムでいうスプリントレビュー（成果物を見せてフィードバックをもらう場）の役割を果たしています。ただし参加するのは、その案件にアサインされたメンバーだけです。部署全員を巻き込みません。

2. 案件横断の会議 ＝ 週1のノウハウ共有

それとは別に、前述した週1回の、案件をまたいだノウハウ共有の場を置きました。こちらは「進捗」ではなく「再利用できる知見」を流通させる場です。

この2階建てにしたことで、

• 案件の中身は、その案件のメンバーで密に回す
• 案件をまたぐ知見は、週1で部署全体に開く

という役割分担ができ、余計な会議に全員を縛らずに済むようになりました。

図にすると、こんな2階建ての構造です。案件の中身は担当メンバーだけで密に回し、そこで生まれた再利用できる知見だけを、週1の場で部署全体に開きます。

まとめ：教科書通りより、チームに合わせて崩す

最終的に、私の部署の体制はスクラムとは別物になりました。でも、振り返るとこういう整理ができます。

• 新参の段階でいきなり会議を増やすと、「安全地帯から指示する面倒なヤツ」と見られて拒否される
• だから「ヒアリングして共通部品を作る」という建て付けで入り、まず自分が動いて信頼を得た
• スクラムは「同じ案件を共有するメンバー」を前提としたフレームワーク
• 複数案件を兼任し、ゴールがバラバラなチームでは、そのままは合わない
• だから、会議体の粒度をチーム構成に合わせて設計し直した
  • 案件単位の会議（スプリントレビュー的役割）＝ アサインされた人だけ
  • 案件横断のノウハウ共有 ＝ 週1で全体に開く
• 技術的には共通部品化で「次の案件で楽をする」を積み上げた

結果として、属人化が減り、1案件を複数人で見られるようになり、部署の業務効率は大幅に上がりました。私が関わった案件だけでも、3年間で延べ40案件を納品できました。

逆に言えば、制作チームでも

• 1案件にチームで集中する期間がある
• 兼任を絞れる（同時に抱える案件数を減らせる）
• メンバー間の依存関係が増える

ような状況なら、スクラムがそのまま機能する可能性は十分あると思います。「合う・合わない」は、XRコンテンツ制作だからではなく、チーム構成で決まる ―― これが私の結論です。

さいごに

複数案件を兼任するような制作・受託のチームで、

• 会議を増やしすぎず
• 案件が並行する状況でも
• 属人化を防ぎつつ生産性を上げられている

チームがあれば、どんな会議体・分業にしているか知りたいです。「このテンプレが効いた」「この粒度の定例がちょうどよかった」など、ぜひ教えてください。

なお、PSM I の勉強方法は別の記事にまとめています。これから受けてみようと思っている方の参考になればうれしいです。

X（旧Twitter）でも制作やチーム運営について発信しています。よかったらのぞいてみてください。