副業ゲームシステム開発の終了報告（活動報告編）

いつも大変お世話になっております。

上はフロントエンドから下はFPGAまで、たくさんの先輩後輩に恵まれながらプロジェクトもプロダクトもマネジメントしている、スーパーウルトラミラクルめっちゃフルスタック奴隷エンジニアの LRIKI さんです。

先日副業として請けていたゲーム開発がひと段落しましたので、普段本業で行っているような感じでプロジェクトの終了報告を書いてみることにしました。

この報告が、みなさまのお役に立てれば幸いです。

この記事は失敗プロジェクトの報告となります。

お金だけ見ると受託開発としては洒落にならないくらいの赤字を叩き出しましたが、一方で一部の成果物は今後のプロジェクトの土台になりそうな、完成度のあるモジュールとして仕上げることができたと思います。そのためこういったプロジェクトを経験できたことなど色々考えると、トータルでは「請けてよかったかな」とポジティブにとらえています。

なので関係者はどうか悲観しないで！何卒！何卒！

そういった諸々の主に心の事情がありますので、リリースしたタイトルは検索すれば見つかると思いますが、コメント等でリンクを張るのはご遠慮いただけると助かります。

プロジェクト計画

目標

• RPGツクールMZ上で動作する不思議のダンジョンゲームシステムの開発

要するにツクールでトル〇コクローン作ってね、というプロジェクトです。
タイトル固有の仕様やツクールの制約に対応しつつ、再現率 80% 程度を目標にします。
ツクールの仕様に引っ張られてやむを得ない仕様以外は頑張るって感じです。

プロジェクト概要

顧客	個人
依頼内容	ゲームシステムの開発
受注金額	レベニューシェア（成果報酬）
契約形態	準委任
作業場所	フルリモート
作業期間	2020年7月 ～ 2022年8月
最終成果物	RPGツクールMZに組み込み可能なプラグイン

• いわゆるインディーゲームや同人ゲームと呼ばれるゲーム開発です。

• 特徴的な契約として、開発したプラグイン及びソースコードに関しては私が権利を持つものとして合意していただきました。

立ち上げまでの経緯

• 当時の私は日々の業務の疲れや不満の救いを趣味コードへ求めつつ「美しいコードだぐへへ」とか言いながら GitHub へ垂れ流す様を、個人開発とかいう言葉でカッコつける不毛な生活を続けていました。
• ある日なんとなく某掲示板を覗いたところ、私がプログラミングを学び始める強い動機となったフリーゲームの作者さんが、そのタイトルのリメイクのメンバーを募集していました。そこで色々あってご縁ができます。
• そのタイトルとは別になりますが、当時 C++ で不思議のダンジョンを作っている様子を Twitter に上げていたところお声がかかり、今回のプロジェクト立ち上げの運びとなりました。

体制・メンバー

メンバー	アサイン	ロール
依頼主さん	コアメンバー	企画・販売・ゲームデザイン
自分	コアメンバー	システム開発
絵師さん	アドホック	🎨
テスターさん	アドホック	👀

会議体

タイミング	内容・議題	メンバー
Daily	なし	-
Weekly	なし	-
Milestone	なし	-

• 計画された会議体はありませんでした。と言ってもほとんどの期間は2人プロジェクトで、普段から Discord でやりとりしていたため、大きな問題はありませんでした。

資源・データ管理

分類	内容
物理データ	なし
企画・仕様書などの文書	Googleドライブ
プロジェクトデータ・ソースコード	GitHub
要求・障害管理	Googleドライブ → GitHub
タスク管理	Jira → GitHub

• ひとつ前のプロジェクト小規模であったため zip に固めた成果物を共有していたのですが、さすがに今回は本格的なシステム開発なので、それだと炎上のにおいが隠し切れません。
• 依頼主さんに懇願して GitHub を使っていただくことにしました。それにあたり、プロジェクト初期に使い方をマニュアル化し、レクチャーを行いました。
• プロジェクト後半は不具合管理も GitHub に移行し、かなりスムーズに対応が進められました。

品質戦略

分類	内容
Quality	並
Cost	優先
Delivery	優先

• これはサークルのポリシー的なものにかなり依っています。全力を掛けた作品を 1 つ作るよりも、ホドホドでたくさんリリースする感じです。

見積・予定スケジュール

工数	400h
工期	2020年7月 ～ 2022年4月

• 工数については既にあるシステムのクローン開発となるため、仕様がある程度揃っていました。そのため見積はそれほど難しくはありませんでした。

• しかし普通の開発プロジェクトでもあまり見ないような、非常に長い工期で予定を立てています。これは自分が本業とは別に開発を行うため、十分に時間を確保できないことを勘案してのことです。一応、1週間に10hくらいは作業できるだろうという見積で予定を引くことにしました。

• ちなみにプロジェクト開始時は Proto までのスケジュールしかなく、その後リリースまでのスケジュールは、Proto の出来具合で判断する、ということで走り出しました。

リスク管理

リスクについては特に依頼主さんとすり合わせたものはありません。主に自分が心がけていたものです。

• Proto 開発中はほとんど私の個人作業となるため、Twitter などで生存報告と進捗を上げるようにしました。
• 月1回ペースでその時点の成果物を作成し、出来具合を実際に動かしてみていただきました。

プロジェクト報告

製品イメージ

リポジトリはこちらです。

アーキテクチャ

詳細は後で別記事にしようと思います。
さらっとだけ触れると、

• ランタイムの主なフレームワーク・ライブラリは、ツクールMZ標準で入っている NW.js, PIXI.js です。
• 開発言語は TypeScript で、ゲームシステムはフルスクラッチ開発です。
• サポートツールに React, MUI を使いましたが、ツール自体は中途半端に終わりました。
• ユニットテストに Jest を使いました。プロジェクト中盤からはほぼ100%、テスト駆動開発となっていました。
• 設計は典型的な MVP アーキテクチャを発展させたものとしました。

工期（スケジュール）の予実

予定（再掲）

実績

• 当初はαというマイルストーンはありませんでしたが、Protoがある程度動くようになった時点で月1回ペースでリリースし始めたので、その期間をαと呼んで区別しています。

• β期間の中抜けは、私の本業プロジェクトが炎上していた期間です。この間は作業をお休みしました。

開発速度の変化

正確に記録していたわけではありませんが、月ごとの開発速度の変化をざっくりと表してみました。

• 2022年3月ごろは本業の炎上とプライベートの色々なイベント重なって、心をやっちまった時期でした。幸いプロジェクトからの離脱はありませんでしたが、リリース前の重要な期間に十分なサポートができませんでした。

工数の予実

こちらも正確に記録していたわけではありませんが、おおよそこのくらいだったかと思います。

予定工数（再掲）	400h
実績工数	700h

• 原作のシステムとツクールのシステムに大きな乖離がありましたので、その合わせこみで多くの時間を使ってしまったと思います。

不具合分析

主にβ以降で発生した問題について分析しています。

仕様の誤り	3
設計・実装の誤り	46
未実装での動作確認	14
仕様追加	21
テストデータ混入	2
デグレード	4

• これはソフト開発あるあるだと思いますが、機能を組み合わせた時の不具合が非常に多かったです。
• 一方今回は最初からユニットテストを積極的に作ったため、デグレードの量は少なかったです。
• 「1.動くようにする」「2.正しくする」「3.最適化する」のマインドでとにかく動かすこと優先に進めていましたが、大きなシステムでしたのでそのときの積み残しを上手く管理しきれず、未実装での動作確認が出てしまったのかと思います。

メトリクス

ソースコード

ファイル数	375
コメント・空行	39,498
論理LOC	38,408

• 実コードと同じくらいコメントがありますが、これは設計資料や実装メモを全部コメントで書いていたためです。ごめんね…ごめんね…公開するときはもうちょっと整理するから…。
• ちなみにRPGツクールMZのランタイムは 28,000 くらいなので、本体よりでかくなりました。ﾜｵ

テストコード

ファイル数	153
コメント・空行	5,230
論理LOC	8,450
テストケース (Jest)	275

• 個人的には少ないかな感ありますが、実際のところひとつのテストケースの中で複数の機能をチェックしていたりもするので、カバレッジはかなりいい感じでした。

活動成功事例

αフェーズの定期リリース

これは実施してよかったと思います。1スプリント1カ月のなんちゃってスクラムな感じでしたが、定期的に動くものを共有できたことで、メリハリや安心感があったと思います。前半はほぼ個人プレーだったのでサボり防止の意味が大きかったかもですが。

ハイブリッドアジャイルっていうのかな。カッコつけると。

GitHub に情報を一元化

エンジニアの方々には何を今更という感じかもしれませんが、今回は Git, GitHub の経験がほぼない方と組むこととなりました。
人数が少ないのでおおげさかなぁとは思いましたが、特にテストフェーズに入ってからの不具合と、修正したコードのマージを捌くのに大きな助けとなりました。

導入時は多少強引な感じでしたが、最終的にはスムーズに事が運んだかなと思います。

前に進めようというマインド

サクサクとプロジェクトが前進している風通しのよさというか、さっぱり感というか、粗削りでもガッと作って、細かいところは後半でブラッシュアップしていこうという雰囲気は非常に良かったと思います。

ひとつの機能ごとにリテイク喰らいまくった時の停滞感は意外とモチベに響くのです。

ブラックボックスなユニットテスト

コードカバレッジではなく機能仕様に着目したユニットテストを組むことで、プロジェクト初期に作成したテストケースをずっと使いまわすことができました。特にシステムの中核にあたるキャラクターの行動順の処理は試行錯誤を繰り返し、5回くらい作り直しましたが、そのたびにデグレから救ってくれました。

テスターの方々にやり直しを求めることも防げましたし、テストの作成を後回しにしていたら、完成しなかったと思います。

ユニットテストを積み重ねることで、過去のすべての自分が、今日の自分を護ってくれるのですよ。

活動失敗事例

「むきなおり」に失敗した

今回のプロジェクトは、売上的に見ると大失敗だったと思います。
リリース1カ月時点でプロジェクト開始時の売り上げ目標の5%にも届きませんでした。

私はプロジェクトの全容を把握しきれていたわけではありませんでしたが、見える範囲で考察すると、出来上がった作品は「原作システムの上にキレイな絵を乗せただけ」になってしまっており、目新しさが無く、多くのユーザーはトライアル時点で止まってしまったのかと思います。

実は α 中盤時点で「この作品は本当に面白いのか？」という議論はありました。その際丸1カ月使って市場分析を行い取捨するべき要素を提案しましたが、結局は枝葉の改善に留まってしまいました。

このようにむきなおりのチャンス自体はあったのですが、リソースの都合か、あるいはプロジェクトの根幹を揺るがす事態の恐怖に勝てなかったのか、チームがそれに立ち向かう関係や土台を築けていなかったのか。フルリモートだったのもあり、込み入った議論の「壁」がどうしてもあったのかなと思います。

2年先の予想なんて不可能だよ

2年スパンのプロジェクトで一定の開発速度を維持するのは非常に難しいと思い知りました。

いや当初予想できなかったことではないけれど、プロジェクト外から飛んでくる問題は本当に突然のものばかりで、僕らエンジニアのいかに効率よく品質の良いプロダクトを作るか常に考えスキルアップに邁進する様子もナニソレという感じで叩き潰しに来るあの大質量かつ大量のメテオフォールを受け止めることなど我々矮小な人間にかなうのだろうか（いや、できない）

まぁプロジェクトの後半で、僕の人生に重大なイベントが発生して開発速度にダメージを受けちゃったという反省です。
長いプロジェクトは要注意って再三言われてたはずなのにね…。

感想

全体を通して色々勉強になったのでよかったと思います。

凹んでないよ？強がりじゃないよ？ホントだよ？

というのもこのプロジェクトは一部の成果物が私の手元に残ることが重要な事項だと思っていて、最初に売り上げ予想はいただいたのですが、その時点で普通に仕事として請けたら200万くらいの赤字出るだろうなぁという前提で請けていたりします。

今はこの手に残ったものをどう料理していこうか考え中です。

といったところで最後のまとめといたしまして、

• レベニューシェアは趣味
• むきなおりの恐怖に勝つ力がほしい
• 2年先の予想なんて不可能だよ

最期までご覧いただきありがとうございました。

エンジニアのみなさまの益々のご活躍をお祈りいたします。

TODO:

• ゲームシステム開発の終了報告（アーキテクチャ編）
• ゲームシステム開発の終了報告（ゲームシステム考察編）