PDCAサイクルと実施例について
PDCAサイクルとは
PDCAサイクルとは、「Plan」、「Do」、「Check」、「Action」の略です。下記の例え話はゲームの開発に準拠するものにします。
Planは、計画を建てるフェーズです。ここで、何を作るのか、どんな手段で作るのか、何をしたら終了なのかを決める段階です。ゲームのキャラクターはどう動くのか、ゲームのルール、ゲームでのダメージ判定、またはゲームの世界観などを決めておきます。ここで決定したことをDoで実行します。
Doは、計画の実行です。文字通り、計画を実際に実行します。
Checkは計画を実行した結果を確かめています。そもそもキャラクターの動きは自分が思っていた世界観とマッチしていのか、計画実行時にどんな壁があったのか、ゲームのルールに理不尽なのことはなかったのか、そもそもゲームの世界観が面白いのか、などゲームの完成度に関わるものを確認していきます。
ActionはCheckで出てきた問題点、改善点を見つけて改善案を出していきます。ゲームの動きが甘かったからアニメーションに改善を加えよう、ゲームのルールで一部の処理が不正が起きやすいから改善する、計画していたときに見えなかった壁があったから壁の回避方法を出す、といった方法を考えることができます。
このようにPDCAサイクルを回すことで回すたびに完成に近づいていって最終的には当初計画していたものにより近いものを作り上げる。これがPDCAサイクルを回すことで得られるメリットです。
完成を目指す基準
そして、完成を目指す基準ですが、これはまちまちです。計画をしている時点でゲームならある程度作り方がわかっている人と、全くの素人が作るのとでは計画で許容できる誤差も想像の粒度も全く違います。
ですが、素人だろうが玄人だろうが、かならず計画には計画している当事者がわからない事象が必ず存在します。ゲームの作成であっても、unityを使いこなしていない人ならすべてがほぼ未知の状態ですし、unityを使いこなしている人でも新機能が追加されてそれを使って新しいことをする時にもわからないことは絶対出てきます。そのため、各plan時に負う未知のリスクは計ることができません。
ですので、Planの完成度を考えるときに私が気をつけていることは「自分ができることの少し上くらい」を意識しています。例えば、unityの基礎をできている状態で基礎＋＠で炎のエンチャントをリアルに近づけてみたり、コントローラーで入力ができるようになったらそれをキャラクターの動きと同化させる、といったような完成度にします。
ここでやってほしくないことが、完璧な計画を立てようとすることです。私も含めてやったことのないことを最初から完璧な完成度を持った成果物を作ることはまずできません。ゲームを作るにしたって最初から「最新のマリオに劣らないものを作る！」というのは無理です。これは玄人でもそうそうすぐにできるものではありません。一見できそうでも必ず作る時落とし穴のような壁があったり、ハードウェアの限界を超えるような仕組みをゲーム自身に作り込まれていることも考えられます。
ですので、PDCAサイクルは修正しながらやるのが目的です。最初の完成度は良くて３０％程度の方がいいです。
PDCAサイクルの各ステージでの対応方法
では、実際にPDCAサイクルの対応方法を説明していきます。ここでの対応方法は私自身の我流が履いているのでご容赦していただきたい。
今回は当たり判定をつけるときにどのようなことをやるのか、を題材に話を進めていきます。
Plan
当たり判定をつけるのならば、私なら下記のようにします
- 四角形同士で当たり判定をつける
- キーボード操作はもうできるのから、動きあってあたったら止まる。
これだけにした理由は、そもそも当たり判定をつけたことがないのと、スピードがある場合の処理が難しそうだなという感じたからです。
ここで下手にキャラクターに凝ったアニメーションを加えると、どこまで戻ればいいのかがわからなくなるので、あえて単純にしています。
Do
ここでは基本的に１日１日コーディングするか、設計書をまとめるしかしません。
メモを残しておきますが、メモはCheckとActionのときに使います。
Check
ここでなのですが、おそらく仕事でやるであろう〜期ごとに仕事ぶりを確認することはやりません。
個人や少人数で、いままでやったことのないことをしているのであれば毎日のように結果が出てくるはずです。
当たり判定であれば、教科書通りの「AABB方式」の通りにコーディングしたら動かなかった、または２個の衝突判定はうまくいったけど、３個だとうまく行かなかった、使っている言語でうまくループが回せなかった、といろいろとトラブルが起こります。Checkではそれらのトラブルを集積します。もしくは、AABB方式で衝突判定ができることが確認できた、のように実験してみてうまくいったことも集積していきます。
CheckをするのはDoを回すたんびでいいです。なにかいい気付きがあったらその都度集めていけばいいです。
Action
ActionはCheckで集めたトラブルや実験結果から分析をしてなにかいい解決策を作り出すフェーズです。
「衝突判定で３個以上うまく行かないことが分析したら、どうも書いたコード自体の計算量が多くなっている。それに対して以前本で読んだ〜の方法をためしてみたらうまく行きそう」といったような方法を書いてきます。
これもCheckをしている最中で解決策が出てきたら書いて、その時出てこなくても定期的にCheckを見てなにか思いついたら書いていく。これをPlanで計画していたものがある程度消化されるまで行います。
制作物に活かすには？
先ほどは当たり判定をつけるという技術的なことにフォーカスしました。制作物にもおそらく同じことが言えます。
Unityで商業ゲームまたは同人ゲームを作るのならば、最初のPlanで完成形を作らずにまずは骨組みだけを作る。RPGならばRPGで主人公と敵がいて戦えるようにする、アクションゲームなら相手を踏みつけてやっつけっる、アドベンチャーゲームなら会話して選択肢をつけて選べば次に進める、といったようなことをすればいいです。
完璧をもとめて最初設計をすると、得る教訓が少ないと私は考えています。なぜなら、失敗が多すぎてどれが重要なものかがわからないからです。最初からマリオみたいな世界観のあるアクションゲームを１から作ると、失敗したのがステージで局所的に起こった失敗なのか、それとも設計でミスをしてだめだったのかの、というような教訓を得るのが難しいです。正直そこで忘れることは多々あります。
そして、１回Planを回したら、それを次のPDCAで修正しておく。最初に自機と敵と戦うだけの処理を組み込んだら、そこで何が足りなかったのかを精査して修正、リファクタをする。これだけでも完成度に磨きがかかるはずです。
それを忘れずに自分の糧にするためにも、小さくして計画を立てて完璧よりも完成を急いだほうがいいというのが私の考えです。
Discussion