NowLoading...

NowLoading
  1. ホーム
  2. 技術備忘録
  3. ウォーターフォール開発が失敗する理由

コラム「デザイナーの主張」

  • facebook
  • twitter
  • line
  • hatena
  • pocket

ウォーターフォール開発が失敗する理由

ゲーム開発の現場では、プランナーやディレクターをピラミッドの頂点として、企画からエンジニアやデザイナーに開発指示を下すウォーターフォール型の開発が主流です。 ウォータースライダー しかし、僕の経験上ウォーターフォール型の開発が成功した試しは一度としてありません。

開発メンバーが優秀すぎる

SGはもともとWEBサービスを作っていた会社がゲーム開発を始めた経緯などもあり、チームに集まってくるメンバーは、ゲーム開発だけに携わってきた人よりも他業種から異動してきた人の方がまだまだ多いです。
ゲーム以外の開発を経験しているので、他社の効率的な進め方やサービスの作り方を熟知している人が多く、各々が独自に自走できるだけの能力を持っています。(みんながみんなじゃないけど)

つまり現場の人間だけで開発を推し進められるだけの力があるので、適切な指示さえ与えればそれなりの製品を作り上げることが可能なのですが、ウォーターフォール開発の場合はこの状況が諸刃の剣になります。

ウォーターフォールが失敗する最大の原因

今まで経験してきたウォーターフォール型の開発で失敗する場合の共通パターンがあります。 それは 指示が曖昧で無責任 ということ。

プロデューサーやディレクターの指示のもと、企画メンバーが開発メンバーに指示を出すため、企画担当者に責任が集中するのですが、
完成形のイメージがプロデューサーやディレクターの頭の中だけにあって担当者に共有されていなかったりするので、仕様の中身が大雑把で大切な部分は作業担当者に丸投げという無責任さが開発を混乱に陥れます。
さらに、何から何まで細かく面倒を見たがる割に、開発のことを全く理解できていなかったりするので、開発側からすると仕様の穴が多すぎて、どう動けばいいのか解らず混乱してしまう状況が多々発生してしまうのです。 お役所

二つの解決策

完璧な指示を出す

こと細かく指示を出して、思惑通りの成果物を開発現場に求めるのなら
突っ込み所の無い完璧な仕様書を作る 以外に解決策はありません。

どんな疑問にも完璧に答えられて、開発途中で試行錯誤しない、仕様書通り作れば何の問題もなく完成まで漕ぎ着けられる。
そんな完璧な指示書があれば現場は混乱しません。

しかし、そんなことは不可能です。

各職域の専門知識を完璧に熟知しているスーパーマンでもない限り、完璧な仕様書など作れるはずがありません。 スーパーマン

現場を信用する

先にも触れましたが、SG開発の現場には優秀な人材が集まってくることが多いです。
各々が独自に自走できる能力を有しているので、現場のメンバーを信用して丸投げしてみるのも一つの手です。

とはいえ、ただ無責任に放置するというわけではなく、どうしたいかという根本的なイメージだけはきちんとメンバー間で共有し、どうしていくのが最適なのか相談しながら進めていくという手法をとるのが安全です。

現場の開発者と相談することで穴を埋めていけば仕様の精度も高まりますし、決まったことをきちんと上層に報告して、上層から全体に周知させることで混乱もなくなります。
自分たちで相談して決めたことのなので、ある日突然初耳指示が降って来るより心理的にも楽です 事件は ただし、注意点が一つ。上層への報告は必須です。これを怠ると現場が暴走を始めます。

結局のところ細かい部分はその職域の専門家に委ねるのが最も効率的なので、何でもかんでも細かく面倒を見ようとせずに 現場を信用して任せる のが優秀なメンバーを有する開発チームには有効的です。(餅は餅屋です)

余談ですが。。

有名タイトルを有するコンシューマーゲームの開発会社には、過去のヒット作を手掛けた ”神” が存在します。
そういった”神”からある日突然現場に直接作業指示が降ってくる ”メテオフォール” と呼ばれる現象もあります。
神からの指示なので人民は逆らえません。
指示の内容が曖昧だろうと、理不尽だろうと、従わざるを得ないのですが、いつも神が正しいとは限りません。
現場が混乱するどころか火の海です。

出来ることなら神には出くわしたくありませんね・・・ モーセ

関連記事

もっと見る

技術備忘録 でよく読まれている記事

人気記事TOP10