普段使っているPDCAをゲーム作りにも導入してみよう【ゲーム開発】

普段のお仕事でもやっているかと思いますが、ゲーム作りでもPDCAサイクルを使ってみると早く技術を高められるかもしれません。

お仕事で使うフレームワークなどは「意識高い」として敬遠されることもありますが、使ってみると便利なことも多いのでゲーム開発の効率を上げていくためにも導入を検討してみてくださいな。

このページではゲーム開発でのPDCAについて、特に個人開発者の視点から紹介していきます。

PDCAサイクルとは

意識合わせのためにPDCAサイクルについて触れておきましょうか。PDCAサイクルとは製品を作るときに継続して改善していくための考え方です。それぞれの文字は略語になっていて、

• 「P」はPlanのPで計画
• 「D」はDoのDで実行
• 「C」はCheckのCで確認
• 「A」はActionのAで改善

をそれぞれ意味しています。

何かのプロジェクトを行う時には、まずはじめに計画を行います。

そして計画に沿って開発を進め、システムが完成したところで全体の振り返りを行って、次のプロジェクトでどう改善するかを見つけて新たな計画を立てていきます。こうして継続的に改善を続けていくわけですね。

この一連の流れは「PDCAサイクルを回す」なんて言い方がされています。

ゲーム開発でのPDCA

ゲーム開発にもこれが応用できて、事前に作るゲームについて企画や設計を行っておいて、それに沿って開発を行います。

ゲームが完成したら、ゲーム作成全体を振り返って改善すべき課題を見つけていきます。時間がかかったところや、実装を諦めたところについて本やインターネットの情報を確認してできるようにしていきましょう。

計画時点で想定していなかった出来事があれば、それも次のゲームを作る時に活かせます。

最初から完璧な企画や設計は難しい……というかはっきり言ってしまえばムリです。

なのでざっくりとした計画を作って、まずは行動に移すことを意識してみてください。ゲーム開発でPDCAを導入してみる目的は、あなたの作るゲームを遊んだユーザーの心が動くような、楽しい時間を過ごしてもらうためのゲームの改善を行うことです。

そのためにPDCAの考え方を使ってどんどんゲームを改善していきましょう。

例えばアプリとしてゲームをリリースしたのなら、リリース→ユーザーの反応をもらう→もっと遊びやすくするたのアイディアを出す→アップデートしてリリース→またユーザーの反応をもらう……のようにひとつのアプリをどんどん改善していく流れになると思います。

複数のゲームを作っているのなら、前回作ったゲームで意図していたことが実現できたかどうかを検証して、できたのならそれはそのまま次のゲームで使い、できなかったのなら新しく情報を取り入れて改善したり、別の方法に切り替えたりと改善していきます。

アジャイル開発の場合は？

ゲーム開発はウォーターフォール式の開発というよりは、ルックアンドフィールを確認しながら設計に反映していくアジャイル開発の方が多いと思います。

ウォーターフォール開発、アジャイル開発というのはソフトウェアの開発手法のことです。

ウォーターフォール開発

ウォーターフォールとは滝のことで、要件定義、設計、開発、テスト、リリースと順番に工程を進めていく方式の開発方法です。「滝」をイメージしている通り、次の工程に進んだら基本的に前の工程に戻らないようになっています。プロジェクトの進捗を管理する上では分かりやすくていいのですが、開発を行っていたらユーザーから「やっぱこうして」と変更要求が来て手戻りが発生、プロジェクトからはデスマーチの匂いが……というのはよくあること(実体験)なので、全く前の工程に戻らないということもありません。

変更要求があったら契約に基づいてその工数を見積もって追加で請求するというのがよくあるケースなので、お客さんとしても要件定義の段階で全部の要望を出しておかないといけないという負担があるかもしれません。実際に見るまで分からないというのはよくあることですから、「なんか思ってたのと違う」ということが起こりうるのもしょうがないかもしれません。そして「これは契約の範囲内でやってくれるんだよね？(威圧)」という言葉がお客さんから出てきたり、手元で契約書の作業範囲を確認しながら「いえいえ、この部分は変更に当たるので別途お見積もりですね(涼しい顔)」と言い返すバチバチした現場が生まれるわけです。

アジャイル開発

もう一方のアジャイル開発は、ソフトウェアの開発単位を機能ごとなどの小規模な範囲に分割して、短い期間で設計から実装、テストまで行う方法です。アジャイルは「素早い」という意味の言葉で、その名の通り素早さを重視した開発方法になっています。

例えばひとつのソフトウェアを開発するとなったら、機能ごとに実装範囲を分割していきます。ある機能について実装するときには、その機能の設計をさくっと行って実装に入り、テストまでおこないます。このとき、実装したものをお客さんに見てもらいながら雰囲気を確認してもらうことが多く、この段階で「もうちょっとこうして」なんて話が出てもすぐに修正しやすいのが特徴です。

機能を本実装する前に雰囲気を掴むモック版を作ることもあります。必要な動きが入っているかを早い段階で確認してもらうことで認識のズレを早めに無くせるのがメリットですね。

アジャイル開発のPDCA

PDCAの話に戻ると、プロジェクトという単位ではウォーターフォール開発の方がPDCAのイメージに近いかもしれません。アジャイル開発でPDCA……？　とちょっと戸惑うかもしれませんが、短い期間に分割した単位で見れば、個々の機能の実装ではPDCAサイクルが使えることが分かります。

機能を設計して、すぐに実装して、お客さんに見てもらいながらフィードバックをもらってすぐに改善、という流れになっているので、これはまさにPDCAの動きですね。

PDCAは古い？

意識の高い世界では「PDCAは古い！　時代はOODA(ウーダ)だ！」みたいな話も出てきていますし、PDCAでググると「PDCA 古い」みたいなサジェストが出てきたりします。

確かにビジネスの世界であれば、長期的な計画に対してPDCAサイクルを回そうとすると改善の機会が少なくなってしまってメリットを享受しにくいのです。ちょっと名前を挙げた「OODA(ウーダ)」では、

• 最初の「O」でObserve(観察)
• 2つ目の「O」でOrient(情勢への適応)
• 「D」でDecide(意思決定)
• 「A」でAction(行動)

というサイクルを繰り返します。変化の早い状況ではOODAの観察と適応が大切で、常にフィードバックを得ながらより良い意思決定を目指していくのがベスト。

ただ個人的にはOODAはどちらかというと戦略レベルの話、PDCAは戦術レベルの話に近いかと思いますので、ひとつのツールだけで全て賄おうとするよりは場面に合わせて使い分けできるといいかなーと思います。特に製品の品質改善の目的を考えればゲーム開発だとPDCAが使いやすいんじゃないかと。作ったゲームをどこで販売するか、どのように広報していくか、といったビジネス的な意思決定だったらOODAかな。

この記事の目的は「普段お仕事でPDCAを使っているならそれをゲーム開発にも使ってみよう！」という点なので、普段のお仕事でPDCAを使っている方向けになっていますが、もしOODAを使い慣れているならそちらを適用するのも良いかもしれません。

ツールを使うこと自体が大切なのではなく、ゲームを遊んでくれたユーザーの心が動き、いい時間を過ごしたと思ってもらえるようなゲームを作ることです。

まとめ

自分でゲームを作る技術を高める、作ったゲームの質を高めていくという目的ならまずPDCAサイクルを使ってみるのが良いでしょう。

技術を高めるためには、本来のあるべき姿を見据えた上で今の自分には何ができていないのかを謙虚に見つめ、あるべき姿に向かうための課題を見つけることで改善していきます。できるところを伸ばす、できないところを減らす、という目的を果たすためには課題を見つけることが重要です。

このためのツールとしてPDCAサイクルが便利なので、まずはこちらを使ってみてください。もし使ってみて合わなければ他の方法を使うのでも良いと思います。技術を高めるという目的に合わせて選べばOKです。

身も蓋もないことを言えば、大事なのはあなたの技術が高まることですからね(笑)