サインアップ
リーダーが仕事をメンバーに指名して割り振ることをサインイン、メンバーが貼り出された仕事から取って行くのをサインアップと言うらしい。
スクラム開発では、スプリントで達成すべき仕事をチームで片付けていく。そのため基本的な考えはサインアップになります。
これはゲームの現場では大きな議論を起こすもののひとつだと思います。
- 描画系、サウンド系、システム系、人工知能、物理エンジン、コンピューティング、シェーダなど専門分野があまりにも多い。
- 企画とエンジニア、企画とアーティスト、アーティストとエンジニアが１対１などの少人数で結びつくことがこれまで多かった。
- 担当分野を決めてそこへの習熟度を高めたほうが、最終的に効率良く開発できる（個人単位の普請方式）と従来考えられている。
- ごく少人数で結託して、全体で把握されていないものにこっそりとトライすることで創造的なものが作れるという文化がある。*1
こーゆーのどうするんじゃろう。
Cross functionally チームが作れれば 1 と 2 は解決しそうな気がします。うまくやればアニメーションシステムと物理エンジンのエンジニアが同じチームに配置されませんし、密接に結びつく企画とエンジニアが同一チームに入ったうえでチームと共有されます。
1 と 3 は似て非なるもの。 1 は専門性が高すぎてサインアップ体制を取りたくても難しいという話。 3 は積極的にサインインを活用するのでサインアップと反するという話です。
Aさんなら１時間で済む仕事も、初めて取り組むBさんでは何時間かかるか分からない。そもそもそれ自体、現場でコードレビューをやってないという証拠なんですけども。
こうなると、プロダクトオーナーの選択に制約が入ります。あるスプリントでAさんの担当ぶんが飽和してしまって、重要だけど次のスプリントに見送るしかない。またBさんの手は空きっぱなしなので、さして重要でもないBさんの分野の仕事をスプリントに積まなければいけない。
仕事の規模、優先度、依存関係に加えて、担当者という情報が一個増えてるので、結構大変です。
難しい問題なので何ともいえませんけど、最近ひとつ重要な再発見をしたような気がするので報告します。"サインアップ方式は結構楽しい"です。把握してない事柄について、ソースそ読んで、情報を聴いて集めて、分析し、戦略を話し合って、協働して問題を解決する。忘れてましたがエンジニアは結構こういうこと好きだった。オープンソースが楽しいのもひとつはコレですよね。
よっぽど極端なスケジュールが絡むと難しいけど、少なくともエンジニア側にはサインアップ方式を拒む理由はないなぁと思いました。
*1:方法論はともかく潰してはならないスピリットだと思う
