こんにちは、やまだたいし( やまだ たいし (@OrotiYamatano) | Twitter )です。
個人でゲーム開発をしているのですが、完成せず「開発手法の一つであるスクラムの考え方を個人の開発に取り入れられないか」と考え、本記事を作成しました。
名付けてソロスクラムなんちって。
本記事は(途中アドバイス口調ですが)こうしたら良いよ等のアドバイスではなく、私の頭の中を整理するために書いたものですので、
参考にするのは辞めたほうが良いかもしれません。
逆に個人開発では、こうしてるよ等あれば聞いてみたいです。
目次
個人ゲーム開発でゲームが完成しない訳
そもそも、スケジュールやコストを決めるプロデューサー役割が存在せず、
一人でやるとディレクター(ものづくり)視線でゲームを考えてしまい、工数度外視で制作してしまいます。
それで完成すればいいのですが、ゲームを完成させることが出来るのはごく一握りです。
ゲームジャムのように期限が決まっていればまだしも、一人だと「まぁ良いや」とズルズル引き伸ばしてしまいます。
壮大なゲームを作ろうとしすぎたり、ゲームについての案が途中で思いついて収集がつかなくなったり、本当にいいゲームなのか疑心暗鬼になったり……。
いわゆる「エターナる」。
では、完成させるためにはどうすればいいか
シンプルです。終わりを決めてソコで打ち切ればいいのです。
それが出来れば苦労はない！！！シンプルではあるが、イージーでは無い……。
どれだけ途中だったとしても個人制作の場合は自分が終わりだと思えば終わりです。
だとするなら、おわりとなる何らかの区切り(期間や実装機能)を決めて、やれば良い。
しかしながら、クリエイターとしてはどうしても納得いかなかったり、機能追加をしたくなることがあります。
私は前職基幹系Webシステムを作ったりもしていたのですが
Webアプリなら機能面が重視され、ある程度妥協しやすい部分もあります。
しかし、ゲームの場合「音楽」「シナリオ」「ビジュアル」「プログラム」とアート的な側面が大半を占め、こだわり始めるとキリがないです。
また、神は細部に宿るなんて言葉が信じられるゲーム業界では工数度外視の要件定義をひっくり返すレベルの仕様変更も少なくない……。
それなら、ウォーターフォール的な工数設定よりも、運用保守に特化したスクラム的な作り方の方がゲーム開発に向いているのではないかと考えました。
個人で開発する場合も、リリースしてからパッチで追加するなんて事も最近は多くなってきてますからね。
個人開発にスクラムを採用するワケ
もうちょっとだけ、工数管理の話に突っ込んで考えてみます。
実際大型開発やいくつかの保守案件に入って気がついたのですが、前職IT系の職種で働いていた時と比べ、工数管理が意外とゲーム業界は雑だと感じました。
なんというか、自走力が弱いように感じました。
ゲーム業界でも、それぞれ大体どのぐらいの工数が掛かるのか工数出しをしますが、
工数出しをしたとしても、要件レベルで仕様が変わったり作業差し込みが入ったりします。
また、ゲーム系はノウハウに関しては企業秘密にしている部分が多く、様々な知識が行き渡っていません。
ですので、ほぼ同じような一つの機能だとしても「案件ごとに異なる実装をしていたり」「イチから作り直して考えていたり」します。
いわゆる業界全体のフレームワーク的な物が存在せず、
大変な思いをしながら手探りで進むことが多いため予想以上に工数が膨らみます。
とはいえ、ゲーム業界以外でも予想以上に工数が膨らむことは少なくないとは思いますが……。
そうなると、工数がかなり曖昧なものになってしまいます。
その上、工数管理方法や工数だし方法についてもノウハウと同じ様に既存のフレームワーク的な物が存在する会社は少なく、管理者たちは毎回大変な思いをしているように思います。
定量的な作業が推測できないのですから、そりゃ工数も見積もれないに決まっています……。
それなら、既存の古いゲーム業界のやり方に載っかるよりは、Web系などの工数管理の考え方を真似たほうがまだ明確に工数出しが出来るのではないかと思いました。
会社と違って個人開発ならスクラム採用しやすいですしね……。
Web系の個人開発を参考にする
基本的にスクラムベースで考えたいとは思いますが、Web系の個人開発は開発時の工数管理ノウハウを展開しているものが多いです。
まずは、いくつかの工数管理について調べてみようと思います。
Zennを作った人の話。
youtu.be
Mentaを作った人の話。
youtu.be
スケブを作った人の話。
and-engineer.com
どれも、何を作るか明確化し基本機能だけ作って短い期間でリリースされているようですね……。
ゲームについてはリリース後が一番大事だと言われており、マーケティングを行ってからリリースしなければ、
そのゲームがある程度面白くても売れないと聞きます。
とはいえ、開発するモチベーションを維持するためには基本機能を先に作るのはアリに感じます。
実際のスクラムとの差異
因みにアジャイルとスクラムについて違いわからない人の為に一言説明すると、
スクラムはアジャイル開発の一種になります。
アジャイルと言いつつ、ほとんどの場所がスクラムにも触れて解説されているところが多いです。
スクラムについて詳しく知るならスクラムの本を読んだ方が良いですが、まずはアジャイルについて正しく理解しましょう。
アジャイルについて学ぶところは沢山ありますが、こちらのサイトが概要を理解するのには良さそうです。
agile-douga.tv
本だとアジャイルサムライとかがオススメです。
スクラムについてだと個人的にはScram Boot Camp The Bookがオススメです。
しかしながら、チームで運用するのに特化しているため、このまま個人で使うことは出来ません。
顧客について
個人開発なら顧客は実際にプレイするユーザーと思うかも知れませんが、意見を聞くことは出来ませんので、
実際の所、要件は自分で出すことになり自分が納得すればリリースになります。
つまり、自分自信がユーザーです。(実際のゲーム開発ではパブリッシャーやディレクターがユーザーでしょうか……)
通常発生するやり取りは存在しませんので顧客とのやり取りという部分は存在しないので省いていいと思います。
(誰かに作りたいとか品質について口を出してプレイしてくれる人がいれば、その方をユーザーにしても良いかもですね)
今回は自分がユーザーとして考えを進めていきます。
要件について
開発は不確実性のコーンと呼ばれるプロジェクトが進行するにつれて見積もりのバラツキが存在してしまいます。
本来ならユーザーの要求や要件、ユーザーとの専門性の壁を取り除くことが不確実性のコーンを明確化することが不確実性のコーンは狭く出来ます。
ユーザー＝自身になります。専門性の壁はありません。
しかしながら、要件は個人で開発する場合だとしても、自分が自分自身のゲームに求める要件がブレてしまうと、ゲーム開発の期限が無限に延びてしまいます。
例えば、見た目は二の次にしようと思っていたのに、細やかな見た目が気に入らなくて、何回も絵やプログラムを修正したりなどがソレに当てはまります。
最初に何が重要かしっかり要件定義が必要なのは個人でもチームでも変わらないように感じます。
個人開発の場合でも、自分の作業が定義した要件からズレていないか振り返ることが大事かも知れません。
役割について
本来ならスクラムには開発側にプロダクトオーナー、開発者、スクラムマスターが居ます。
個人の場合全部が自分担当になります。
また、開発外にはステークホルダー(利害関係者)という役職も居ます。
ここがチーム開発と一番違い偏らないような方法を考える必要性があるかも知れません。
変更コスト
こちらについては、チームだろうが個人だろうが期間やコード量が増えるたびにコストが増大します。
逆に言うと小さいプロジェクトならば、変更コストは多くないです。
変更が少なかったり、小さなゲームなら考えなくても良いかも知れません。
1週間でやること
リファインメント、スプリントレビュー、デイリースクラム、レトロスペクティブ、スプリントプランニング。
ここはチームによって違うかも知れませんが、こういうことを取り組んだりします。
それぞれ、個人の場合はどうやって実現できそうか考えてみます。
リファインメント (頻度は1週間に1回とか2回とか)
プロダクトバックログ(要件リストみたいなもの)を見直し、優先度の高いPBI(プロダクトバックログアイテム 以下PBI)を具体化します。
チームの場合:
プロダクトバックログを見直し、優先度の高いPBIを具体化する
大きい項目を具体的なPBIにスライスを行い、どうやって実装をするか開発者が理解しているか確認など
INVEST:プロダクトバックログの書き方
「独立している」「交渉可能」「価値がある」「見積もり可能」「適切な大きさ(1週間or2週間に6～10個終わる)」「テスト可能」
個人の場合:
優先度の高いPBIを具体化、ココは替わりません。
どうやって実装をするか具体化
INVEST:プロダクトバックログの書き方
「独立している」「交渉可能」「価値がある」「見積もり可能」「適切な大きさ(1スプリントに6～10個終わる)」「テスト可能」
交渉可能な所、以外は同じ様にすべきかも知れません。
要件や工数的に許容範囲なら実際のPBIとして見積もりします。
スプリントプランニング (頻度はスプリントの最初に行う)
リファインメントで出たやることを更に細かく分離(分離作業は設計込み)させ、タスク化します。
チームの場合:
2～4時間ほどで出来る内容に落とし込み出来るようにします。
PBI別に作業完成しているかを判断する条件を定義します。
個人の場合:
そもそも個人開発の場合、1日に取れる開発の時間は少ない場合が多いです。
何度も粒度分解する作業をするより開発時間に当てたくなります。
リファインメント時点で、タスク並みに粒度を落とし込んだほうが良いかも知れません。
PBI別に作業完成しているかを判断する条件の定義はしても良いかもですね。
具体的な完成の定義はココでは語りません別途調べてみてください。
デイリースクラム(朝会) (頻度は毎日)
スプリントに向けて何するか明確化と再計画をします。
こちらはウォーターフォールでもやっているチームが多いですね。
チームの場合:
昨日やったこと、今日やること、問題点3つを報告し、チーム内共有します。
問題が出たらどうするかを考える。
個人の場合:
問題点などは理解しているため、これはやる必要があるか分かりませんが、問題が出たらどうするかを考える。というタスクの見直しの面では必要性を感じます。
頭を冷やして自身を見つめ直す為に一定間隔でやったほうが良いかも知れません。
レトロスペクティブ(振り返り) (頻度はスプリントの最後)
活動についての振り返りになります。
チームの場合:
現状の確認、KPTA,KPTを使う。
個人の場合:
現状の確認、KPTA,KPTを使う。
ココは変わらないかもですね。強いて言うなら、チームの場合は指摘出来る場面ですが、
個人の場合は自身を振り返る部分のため、振り返る内容は違ってくるかも知れません。
スプリントレビュー(振り返り) (頻度はスプリントの最後)
こちらはスプリントで出来た成果物についての振り返りになります。
いわゆる成果物レビューです。
チームの場合:
ステークホルダーに見せてフィードバックを受ける。(ゲームならα版などのロム提出に当たりそうですね)
個人の場合:
なし?自身がステークホルダーになると思いますのでコレは要らないかも知れません。
成果物について気になるならレトロスペクティブと一緒にやってしまって良いかも知れませんね。
個人で、こんなにしていられない
これらを見た方、「個人でこんなにしていられないよ！」って思ったかも知れません。
実際問題、仕様変更が頻繁でなく、仕様変更がないのならチーム開発でも、ウォーターフォール開発の方が開発が早いみたいです。
詳しくは知らんけど……
じゃあ、なぜスクラムをやるのかというと、仕様変更で工数が膨らむ「からこそ」どこまでやるか、方向性を定期的に見直す必要があるというワケですね。
個人ゲーム開発でゲームが完成しない人ほど、目標がブレやすいです。
ウォーターフォールで出来るのであればそれに越したことはないですが、無理な仕様をそのまま突き進めてしまうよりは、
多少時間がかかっても定期的に見直して、「どこに着地するか」「方向性が間違っていないか」「どのように方向転換するか」を考えるのがスクラムです。
つまり、「転ばないように頑張るんじゃなく、転んでもすぐ起き上がれるようにする」というやり方です。そのようなやり方では、もちろん時間がかかります。
その上でどちらを選ぶかはあなた次第だと思います。
これらを踏まえて実際に疑似スクラム化してみる
さて、チームと個人でやる場合の違いを述べてきましたが、なんとなく私自身も頭の中を整理出来てきた気がします。
上のことを考慮し、5ステップに落とし込んでみました。
1.自分が作りたい物を具体化する/コンセプトを作る
スクラムで本来ならステークホルダーからヒアリングするニーズ(要件)ですが、最初の段階では「具体的に自分が何を作りたいのか」を明確化することが大事に思えました。
ゲーム開発では企画意図やキャッチコピー、ゲームをプレイするターゲットやペルソナ定義、コンセプト、プレイ端末、ゲーム内容や期間、プレイ人数などがあります。
アジャイルでは、インセプションデッキと呼び何をするか具体化します。
我々は何故ココにいるのか、やらないことリスト、エレベーターピッチなどなど、ココでは割愛しますが言ってしまえば、
最初にやるべき事は自分たちがブレないように何をしたいかを明確化、明文化すると言うことです。
特に、一番大事なのはキャッチコピーやエレベーターピッチだと思います。
この時点でまだ不明確な部分があってもいいとは思いますが、ゲームを一言で表す言葉は作りましょう。
(後、ゲームでは、デザインの方向性を決めるために、この時点でコンセプトアートを作ったりしますね)
ここで決めたものは絶対にブレないようにしましょう。
不確実性のコーンが大きくなってしまいます。
2.プロダクトバックログを作る
Web開発者たちを見習い3ヶ月で作り切るという期限をまずは設定し、
1スプリントでまずは動くという所を目指し、実装できるゲームのコアとなる部分を定義し、プロダクトバックログを作ってみます。
一旦今回は1スプリント1週間と定義します。
優先度も決めましょう。優先度の指標は時間・予算・品質・スコープです。
3.タスク化をしよう
何がしたいかを明文化したら少なくとも、今からやるスプリントでどんなタスクをやるかをはっきりさせます。(つまり毎スプリントのはじめに実行)
スクラムで言う所のリファインメントとスプリントプランニングを同時にやってしまうという話です。
チームなら詳しく話し合う必要がありますが、個人制作ですので一気にタスク化や設計までやってしまっていいと思います。
1週間にこなせるタスク量は個人開発では1日あたり2時間以下が妥当でしょう。
疲れてできない日もあったりするので土日だけ頑張って1日あたり4時間定義するなどはやめましょう。
土日頑張ったとしても案外2時間ですら捻出は難しいものです。それに長期間開発するとなると、「短距離走と長距離走の違い」と同じ様にペース配分を考える必要があります。
気長にやりましょう。
1スプリントあたり1日はタスク化や設計に注力するとして、1タスク2時間と考えるとタスク枚数は多くとも6枚。
1日休みを考えると5枚。少ない場合は、1タスク4時間と考えるとその半分の2.5枚程度でしょう。
PBIの粒度は1スプリントに6～10個終わるとされていましたが、PBIの粒度とタスクの粒度が合わず、この時点でチーム開発との違い乖離が生じます。
個人開発の場合のPBIの粒度は1スプリントに6～10個ではなく、もう少し大きく定義するしか無さそうです。(2スプリントで6～10個にするとか?1スプリントの長さを長くするとか?)
ココに関してはスプリントの考え方をそのまま適用できませんので、ココに関しては新たな手法を、考えたほうが良さそうです。
4.やるタスクを決める
昨日やったタスクの反映とその日やるタスクの決定。(タスクボードの作成)
スプリントが終わるまでの期間を考えて次にタスクに移るかなど、毎日決めましょう。
5.スプリント振り返り
スプリントレビュー兼レトロスペクティブです。
1スプリントに1回行います。
一人で振り返りをやるのは大変です。
ちゃんと振り返られているかわからないからです。
出来るならチームでやったり客観的な意見が欲しいですが、個人開発では難しいです。
とはいえ振り返らないワケにもいかないので出来る範囲でやっていきましょう。
個人での振り返りでは、タスクボードが役立つと思います。
どんなタスクをしたかはもちろん、そのスプリントでやれたタスク数は定量的で客観的データになります。
前週と比べて数がこなせたかなどだけでも、判断基準になると思います。
本当にうまくいくの?
しらん！！！！！
そもそも、個人開発をやる上で、私自身がスケジュール管理やタスク管理に大失敗している。
少しでもフレームワークに当てはめてやることで、全然出来ないというのを回避できないかを考えた結果、生まれた記事です。
チームでのスケジュール管理は世にいっぱいあるが、個人開発でのスケジュール管理はあまり見かけない。
あったとしてもせいぜい、TODOリストやToggleでのタイムトラッキング、スケジュール帳などの自身の生活におけるタイムマネジメントばかりで、作業に対するスケジュール管理ではない事が多い。
まぁ、そもそも個人開発をしてる人間なんて言う層が少ないからなのかも知れないが……。
ともあれ、今回仮説の一つとしてこれはどうだろうというたたき台を提案&自分の考え方を書き留めて整理したかったので書いてみました。
コレがうまくいけばイラストレーターさんや夏休み宿題に追われる学生さんなど締め切り駆動している人の助けになるはず……。しらんけど
何はともあれ、続けられるかは不安ですが、一旦やってみたいと思います。
まとめというか、あとがきみたいなもの
この記事を書く上でタイトルに迷いました。
ソロスクラム、一人スクラム、個人スクラムどれもスッキリ来なかったですし、そう堂々と名乗れるものでも無く感じたので、一人を表す言葉はアジャイルやスクラムに付け加えないようにしました。
そもそも私自身ゲーム完成できてないですしね。
まぁ、ともかく色々書きましたが、この記事を書いて思ったのは個人開発をやる上で大切なのは「 自分が納得できるゲームとは何か、自分が目指すゲームの道標になるものは何かを明確化させること 」だと思いました。
結局自分が納得しないから完成しないワケですし、長期的に作成し続けるにはモチベーションだけではやっていけません。
そのため、長期間に渡るゲーム開発をするには人からよく見られたいだとか、いっぱい売れてお金が欲しいだとか、人に依存するような動機は辞めたほうが良さそうです。辛くなります。
流行り廃りを追いかけていると流行りが過ぎた時点でやる気を無くしてしまいます。
チームで開発するならともかく少なくとも個人開発を続けるのなら内発的動機付けがしっかりしていないと、どうしても軸がブレてしまいます。
いわゆる好奇心とか、成長感とか感覚的好奇心です。「好きだからやる」とか理屈じゃなく感情部分が大事です。
その内発的動機を忘れないためにも定期的な振り返りを行い自身を立て直す仕組みや短いやる気でも完成に持っていけるようなワークフローが必要です。
自分のやる気だけで立て直すのは大変なため、出来るだけ仕組みに依存し内発的動機を言語化、リマインドする仕組みの一つとしてスクラムを取り入れたいと思いました。
スクラムなら、やる気が続かなくてもリリースできるように組み立てるため途中で断念できますしね。
なんとか完成できる方が一人でも多くなればきっと楽しいだろうなと思います。
以上、やまだたいしでした。
