Chocolateの楽園を目指して

-楽園を目指す過程での試行錯誤を記していきます-

PDCAが上手くいかなかったプロジェクトの1つ事例

el.jibun.atmarkit.co.jp
私もPDCAを実行しているプロジェクトに参加したことがありましたが、
結果、うまくプロジェクトが回っていなかったので、問題点をまとめたいと思います。


ちなみに私が参加したプロジェクトはゲーム開発となります。
このプロジェクトを仕切っていたのはクライアントで、
私は、プロジェクトが燃え上がりつつあるのでヘルプで入って!ということで参加していました。


PDCAとは、
Plan(計画)→ Do(実行)→ Check(評価)→Action(改善)を繰り返し、
業務の質を改善していくための1つのフレームワークです。
ただし、質の改善は見込めますが、
プロジェクトの効率化につなげるためには、よく考え、事前の準備を入念にしないと躓いてしまいます。


結論から言いますと、
PDCAサイクルを回すにあたって、1人の人間にタスクが集中した結果、
そこがボトルネックとなり、他のメンバーの仕事が滞ったことが失敗の大きな原因でした。
このプロジェクトでPDCAを回した際、
Plan、Check、Action(改善の計画)を1人のメインプランナーが行い、
Do、Action(改善の実行)は、スクリプタープログラマー、デザイナーなどが実行します。
そのため、そのプランナーのタスクがいっぱいいっぱいとなりました。


Plan、Check、Actionも何人も携われるようにするべきなのですが、
このプロジェクトでは、そのタスクを切り分けることが困難でした。


ゲーム業界の人間は、業務遂行のためのスキルが低いことが多いです。
タスク切り分けを困難にしたのは、
ゲームに関する仕様書、データの管理リストなどのドキュメントが存在しないか、
著しくクオリティが低く、他人が見たときに伝わらないものだったためです。
よって、製品の正解を知っている人間がボトルネックとなったプランナーしかいない状況となりました。


ソフトウェア開発においては、Checkに時間のコストがかなりかかります。
分岐のチェック、さまざまな状況の操作に問題がないか、再開チェック、見た目のチェック等。
さらに、未完成品なので不具合も多発することが多く、Checkの作業を大きく阻害していました。
(不具合の多発は、ゲーム開発であるあるではありません。
 正しく進めれば、不具合だらけにはなりません)


さらにこのプロジェクトでは、このうまく回っていないPDCAサイクル
α版前に2回程、α版、β版、Master版と実施を続けており、
Checkの手が回っていないので、
ROM提出まで時間があるときは手が空きがちですが、
ROM出しの締め切り直前にCheckが一気に始まり、
Actionの対応をあわてて行うといった状態になっていました。


これが私の経験したPDCAの失敗例です。
思うに、PDCAを回すためには、前提となるスキルが多くあります。
タスク管理、情報共有化、他人へ仕事を切り分ける、などでしょうか?
今、世にあふれてくるフレームワークは、高級な状態に思います。
何もわかっていない状態から、高級なフレームワークを導入すると炎上します。
そのためには、基本スキルの習得を怠らないことが本当に大事になりますね!