「個人でアプリやゲームを開発する」ための効率的な作業の進め方

さて、前回は「ゲームを1本仕上げて公開するには、どんな知識・技術が必要なのか」という情報をまとめてみましたが、この記事はその続編として、「すべての作業を自分ひとりでおこなう場合の進め方」をテーマにしたものです。

シンプルなゲームでもやるべきことはかなり多く、分野をまたいで作業するため、一般的な就業時間に合わせてPCの前に座っているだけでは、完成までたどり着くのにかなりの時間がかかってしまいます。

また、大規模なタイトルが採用しているような開発モデルもこの条件には適しません。

というわけで今回は、個人で活動する現役のプログラマが実際に利用している、「作業の進め方のルール」をご紹介します。

一般的なチームでの開発手法を可能な限り簡略化し、試行錯誤しながら最適化してきたもので、「ひとりで」という前提条件が同じなら、多少なりとも参考になる部分があるのではないかと思います。

（執筆者：オブさん）

ぽんぽこ

前回の記事はこちらです。

https://propoko.com/blog/app-skill

詳細な作業スケジュールは組まない

すべての作業を自分でおこなうということは、同時に、すべての作業を自由に割り振れるということでもあります。

チームプロジェクトでは、「いついつまでに誰が何を終わらせていないと次が進まない」といった作業の順番・関連性がありますが、個人ならある程度の区切りごとに帳尻が合えば良いわけですから、わざわざ「そのときの自分に向いていない作業」をやる必要はありません。

というわけで、作業内容、それをおこなうタイミングともに、詳細なスケジュールはいっさい組みません。ある程度ベースの作業環境が整った後は、「自分で決めたルールを基に、その日そのときにベストな作業」を割り当てていきます。

個人の場合には、「電車での移動中」、「カフェなどでくつろいでいるとき」、「テレビを観ている間」なども十分に活用できますから、作業フローが一方通行のスケジュールを守るよりも、柔軟に作業を割り振れるルールを自分なりに確立しておく方が効率的だと考えます。

集中力と場所を基準にして作業内容を決める

おこなう作業は、「集中力」と「そのときに自分がいる場所」を元に決定します。

たとえば、なんとなくノリが悪い、などと考えている時点で既に集中できていない状態ですから、そんなときにプログラミングを続けるのは自らバグを埋め込むようなものです。潔く中断し、集中力のレベルを1段落としてもできる作業に切り替えます。

また、一般的な作業頻度、密度をベースにしていると、完成までにかかる日数の長さにだんだんやる気が萎えてきますから、「密度を上げて一気に仕上げきる」という考えで、場所を問わずにスキマ時間を限界まで活用します。

作業内容一覧

やることは本当にたくさんありますが、逆に作業単位ごとの大きさとそれに必要な条件もいろいろですから、うまく作業を割り振れれば、個人の開発は「スキマ時間を活用しやすい」とも言えます。

基本的には、状況が許容する受け口に応じて、手持ちの作業単位の中から一番作業量の大きなものを割り当てます。

たとえば、自宅にいて集中力もあるならプログラミングを始めます。そして、しばらくして集中力が落ちてきたと感じたら、画面の片隅でYoutube動画でも観つつアイコンを作る作業などに切り替えます。

また、電車での移動時間やカフェランチなどのついでになんとなく画面遷移やクラスの構成を考えてくる、というように、ほぼどんな状況でも何かしらの作業は割り当てられます。

作業の内容ごとに「必要な集中力」を決めていますが、これは、何かミスをしてしまった場合にリカバリーが難しいものほど高くしています。

たとえば、プログラミングで致命的なバグを埋めてしまったら最悪どこかで強制終了してしまうかもしれませんが、ピアノロールでの音源編集で1音ズレてなんとなくオンチな効果音になっていたとしても、次のリリースで直せば済みますよね。

アニメーション、音源、画像編集などはそもそも専門外ですから、あまり精度を求めず、「リラックスしてできる作業」というところに位置づけています。

タブレットでスキマ時間を有効に使う

7～8インチ程度のタブレットは、場所を選ばない開発作業ツールとしてかなり便利に活用できます。

それ以上大きくなると持ち運びやテスト用途で少し不備がありますし、スマホだと逆に少し小さいため、イチオシはこのサイズです。

ちなみに、ノートパソコンを持ち出してカフェやファミレスなどでプログラミングする、というのはフリーランスならなんとなくやってみたいことだと思いますが、「PCと水モノの関係」、「トイレに行けない」などの理由から、やはり外での作業は小型タブレットに軍配が上がると思います。

実際何度かおこなってみましたが、そもそも全くと言っていいほど集中できないため、やはりメインのプログラミング作業は自宅PCでおこなうべきです。

仕様書、設計書などは書かない

ビジネス系開発のチームプロジェクトだったら必須の作業ですよね。

ミーティング、レビューを繰り返し、データベース、通信、ビジネスロジックなど、最終的には1点の穴もないように設計して、すべての人間が同じ方向を向けるように準備してから実際のコーディングに「Go」がかかります。

一方こちらは「個人でシンプルなゲームを作る」というお題です。そこでチーム開発と同じことをしていたら、いつまでたっても終わりません。

そもそも自分だけが内容をわかっていれば良いわけですから、ドキュメントの類は「プロジェクト内に覚え書き用のテキストファイルのひとつも置いておく」程度で十分です。

多少複雑なゲームなら、「テストパターン」のスプレッドシートを追加します。

開発モデル

仕様書、設計書を書かない訳ですから、開発もかなりユルユルなプロトタイプ方式になります。ベースから徐々に肉付けして、そのまま最後まで仕上げる方法をとります。

ただし、何らかの矛盾などが解決できずに行き詰ってしまったり、より良いアイデアや仕組みを思いついた場合には、ソースコード管理で新たなブランチを作り、何度でもプロジェクト全体を初めから組み上げなおします。

この繰り返しがチームプロジェクトの「設計レビュー」のフェーズに相当すると考え、自分の「頭の中の設計書」を洗練させていきます。

個人ですべてをおこなっている限り、やり直しも思うほど手間にはなりません。いらなくなった部分や冗長になっている部分を明確に判断できるため、むしろ最終的な成果物がスッキリと仕上がります。

コーディング

完成した後でも修正は必ず入りますから、ソースコード自体の可読性、保守性は自分なりの方法で可能な限り最適化しておかなければなりません。

要は、「設計書など必要ないくらいにソースコードを仕上げておく」ということです。

関連する記事
https://propoko.com/blog/coding-rule

また、プロジェクトを単体としてとらえてコーディングするのではなく、汎用化できそうな部分は「以降のプロジェクトで使用できるように」きっちり改良しながら進めます。

このあたりは多少の時間をとられますが、今後作成するすべてのプロジェクトに対する効率化として考えます。回数を重ねるにしたがい、「修正の必要ない汎用部品クラス」が増えていくのが理想です。

データ管理

データ管理についても、大規模なタイトルが採用するようなモデルを真似する必要はありませんから、データベースは使用しません。

個人的には、プログラム内で常に更新される、状態データ専用のいくつかのクラスを、タイミングごとに丸ごとシリアライズ / デシリアライズする程度で十分こと足りています。

もちろん、ファイルIOよりデータベースとして扱うほうが慣れていて簡単、という方であれば方法は自由ですが、データベースを利用しなければならないような規模になるなら、そもそも「ひとりですべて作成する」という範囲をちょっぴり超えているかもしれません。

まとめ

いかがだったでしょうか？

今回は、個人で活動する現役のプログラマが、「すべての作業を自分ひとりでおこなう場合」にテンプレートとしているルールをご紹介してみました。

モバイルアプリの開発を始めた当初は、一般的なビジネス系開発の手法をほぼ継承して設計からきっちりおこなっていましたが、簡略化に簡略化を重ね、こんな感じになりました。

未来も含めて自分さえ理解できるなら、むしろシンプルであるほど良いのかな、と思っています。

作業時間の割り振り方などは、詰め込みすぎだと自分でも思っていますので、さすがに完全に同じスタイルでいく方はいないかもしれませんが、とりあえず何かひとつでも参考になる部分が見つかれば幸いです。

以上、「個人でゲームを開発するための効率的な作業の進め方」の紹介でした。