一度正式サービスを開始したMMORPGを運営しながら、その裏側でもう一度、ゲームそのものを根幹から作り直す。
改めて考えても、とんでもないプロジェクトだと思う。
旧FF14から「新生FINAL FANTASY XIV」への立て直しについて、吉田直樹さんが語った講演、
「新生FINAL FANTASY XIV：ゲームを作り直すということ」
を見た。
もともとはFF14がどうやって作り直されたのかに興味があって見始めた動画だった。
ところが、途中から少し見方が変わった。
「これ、ゲーム開発の話であると同時に、プロジェクトを立て直す話そのものでは？」
と思ったからだ。
しかも面白いことに、この講演は冒頭で、
「このセッションはおそらく役に立ちません」
という趣旨の話から始まる。
確かに、一度正式サービスしたゲームを、運営と改修を続けながら裏側でほぼ作り直すという事例は普通ではない。
同じことをそのまま他のプロジェクトで真似できるわけでもない。
それでも、
- 問題だらけの状況で最初に何をするのか
- どこをゴールに設定するのか
- 問題をどう整理するのか
- 誰と一緒に判断するのか
- 改修するのか、作り直すのかをどう決めるのか
- 最後にどう決断するのか
という考え方には、普通のシステム開発にも持ち帰れるものがかなりある。
自分が特に、
「これはプロジェクト立て直しの教科書みたいだ」
と感じた部分を、開発者の視点から整理してみたい。
まず「直す」のをやめる――冷静に現状を把握する
プロジェクトに大きな問題が起きている。
そう聞いたときに、最初に何をするだろう。
普通に考えると、
「問題を直す」
だと思う。
障害が起きているなら修正する。
納期が遅れているなら人を増やす。
品質が悪いならテストを増やす。
目の前に問題があるのだから、一刻も早く手を動かしたくなる。
でもFF14の立て直しで最初に出てくるのは、それではなかった。
まず冷静になる。
講演資料では、「悲観・感情論の排除」とまで書かれている。
当時のFF14には、
「ゲームの出来が悪い」
「ユーザーの意見を聞いていない」
「FFらしくない」
「もう駄目なのではないか」
といった厳しい声が集まっていた。
そんな状況で、がむしゃらに働けば解決するのか。
答えは「違う」だった。
むしろ一度走るのをやめて、
今、何が起きているのかを整理する。
ここが最初の一歩になっている。
これは普通の開発でも同じだと思う。
プロジェクトが炎上しているときほど、
「とにかく作業を進めよう」
となりやすい。
しかし、原因を整理しないまま作業量だけを増やせば、間違った方向へさらに速く進むこともある。
障害が多いのであれば、
「障害を減らそう」
だけではなく、
- どんな障害が多いのか
- どこで混入しているのか
- 設計なのか、実装なのか、テストなのか
- そもそもの要求に問題はないのか
まで一度分解してみる必要がある。
問題が大きいときほど、すぐに解決策へ飛びつかない。
これは、この講演を見て最初に持ち帰りたいと思ったことだった。
「何を直すか」より先に、「どこへ行くか」を決める
冷静に現在地を見る。
その次に行っているのが、
ゴールの再設定
だった。
これも非常に重要だと思う。
問題が山積みなら、
「悪いところを全部直せばいい」
とも考えられる。
でも、それではゴールがない。
例えば、
「UIが使いにくいから改善する」
と言っても、
何をもって改善したと言えるのか。
「性能が悪いから速くする」
と言っても、
どこまで速くなれば十分なのか。
目的地が決まっていなければ、改善は延々と続く。
FF14では改めて、
- FFシリーズとして、どういうゲームなのか
- MMORPGとして何が必要なのか
- プレイヤーとどうコミュニケーションするのか
- どのようなビジネスモデルにするのか
- 長期運営するためにどんな技術が必要なのか
といった、ゲームの根本からゴールを設定し直している。
つまり、
現在のFF14をどう直すか
ではなく、
本来FF14はどうあるべきなのか
を先に決めている。
順番としてはこちらが先なのだ。
システム開発でも、
「既存システムの問題点を直す」
から考え始めるのではなく、
そもそも、このシステムをどういう状態にしたいのか
を一度考えた方がいい場合がある。
現状が悪ければ悪いほど、
現状を基準に未来を考えない。
一度「あるべき姿」に視点を移す。
この考え方はかなり重要だと思った。
現状とゴールの差を、問題として全部洗い出す
ゴールが決まった。
そこで初めて、
現在地とゴールを比較する。
講演では、この差から「問題点」を洗い出している。
この考え方は、とても分かりやすい。
現状 − 目指す姿 = 解決しなければならないギャップ
ということだ。
FF14なら、
「現在のFF14」と「理想とするFF14」を比較する。
- FFとして足りないものは何か。
- MMORPGとして足りないものは何か。
- サーバーは十分なのか。
- クライアント性能はどうなのか。
- プレイヤーとのコミュニケーション手段はどうなのか。
様々な部分を比較していく。
ここでもう一つ印象に残ったのが、
途中で「これは無理そうだ」と気付いても、最後まで問題を洗い出す
という姿勢だった。
これは実際の開発でも難しい。
問題を見つけたとき、
「そこは今さら直せない」
「触ると影響が大きい」
「予算的に無理」
と思ってしまうと、その問題自体を小さく扱いたくなる。
しかし、
問題が存在すること
と、
その問題を今回解決するかどうか
は別の話だ。
まず正しく問題を把握する。
そのあと、
- 直すのか。
- 保留するのか。
- 許容するのか。
- 作り直すのか。
を判断すればいい。
最初から都合の悪い問題を見ないことにすると、現状認識そのものが歪んでしまう。
解決できる問題だけを探すのではなく、本当の問題を全部出す。
単純だけれど、大事な考え方だと思う。
PMがすべてを知る必要はない――判断できる人を集める
問題を洗い出したあとに出てくるのが、
「信頼できる仲間」
だった。
講演では、
- テクノロジーを任せられる人
- デザインの方向性を決められる人
- バトルシステムの専門家
- UIの専門家
- 現状の問題を最も理解している人
など、それぞれの分野について信頼できるスタッフを集めている。
ここも、プロジェクトマネジメントについて自分が考えていたイメージとは少し違った。
プロジェクトマネージャーというと、
- 何でも分かっていて、
- 何でも判断できて、
- メンバーに指示を出す人、
というイメージを持ってしまいがちだ。
でも、大きなプロジェクトになれば、一人ですべてを理解するなんて無理だと思う。
- サーバーについてはサーバーに詳しい人。
- UIについてはUIに詳しい人。
- 業務については業務を知っている人。
- そして、現行システムについて一番詳しい人。
必要なのは、
自分一人で正解を出す能力ではなく、正しい判断ができる人を集める能力
なのかもしれない。
そして、その人たちと、
- 技術的に実現可能なのか
- ゴールは本当に妥当なのか
- 開発規模は現実的なのか
- コストは破綻しないのか
を確認していく。
PM自身がすべての専門家になる必要はない。
むしろ、
「これは誰と一緒に判断すべき問題なのか」
を判断できることの方が重要なのだと思う。
「改修か、作り直すか」を最初から決めない
ソフトウェア開発をしていると、
「もう古いから全部作り直した方がいい」
という話が出ることがある。
逆に、
「今動いているんだから、できるだけ触らない方がいい」
という話もある。
どちらも気持ちは分かる。
でも、このFF14の事例を見ていると、
最初からどちらかに決めるのは違う
のだと思う。
講演では、
「どうするのか」
の前に、
「何をするのか」
を定義している。
そして、
- 描画エンジンを改修する場合のコスト。
- サーバーを再設計する場合のコスト。
- バトルシステムを変更できるのか。
- UIを修正しきれるのか。
- マップシステムを根本から変更できるのか。
そうしたことを一つずつ調査している。
その結果として、
- 描画エンジンは入れ替える。
- サーバーは設計し直す。
- バトルは根本から作り直す。
- UIは思想から変える。
といった判断になっている。
つまり、
「作り直したかったから、作り直した」のではない。
- ゴールを設定し、
- 現在とのギャップを調べ、
- 専門家と検討し、
- 既存を修正する場合と作り直す場合を比較した結果、
作り直すことが必要だと判断した。
ここはシステム開発でも、そのまま使える考え方だと思う。
リプレースありきでもない。
延命ありきでもない。
目的を達成するために、どちらが合理的なのか。
そこから判断する。
「古いから作り直す」
でも、
「動いているから残す」
でもない。
この考え方は、自分自身も忘れないようにしたい。
調査と分析だけでは進まない――最後は決断する
ここまで、
- 現状を把握した。
- ゴールを決めた。
- 問題を洗い出した。
- 専門家も集めた。
- 技術的な調査もした。
- 必要な材料は揃った。
そして講演では、
「あとは思案よりも決断」
という段階に入る。
ここがプロジェクトマネジメントの難しいところなのだと思う。
分析を続けている限り、
「まだ調査中です」
と言える。
もっと調べれば、新しい情報が出るかもしれない。
もっと検討すれば、より良い案が出るかもしれない。
でも、どこかで決めなければプロジェクトは進まない。
FF14ではその結果が、
ゲームを作り直す
という、とてつもなく大きな決断になった。
しかも、既存のFF14を改修・運営しながら、その裏で新しいFF14を開発していく。
普通に考えれば、かなりリスクが高い。
それでも、
- 冷静に現状を見て、
- ゴールを決め、
- 問題を全部出して、
- 信頼できる人と検証して、
その結果として導き出した答えだった。
だから最後は、
腹をくくって決める。
プロジェクトマネジメントというと、
- スケジュールを作る。
- 進捗を確認する。
- 課題表を更新する。
といった管理業務をイメージすることが多い。
もちろん、それらも重要だと思う。
でも、それだけではない。
- 情報を集める。
- 問題を整理する。
- 選択肢を比較する。
- 必要な人に意見を聞く。
そして最後に、
責任を持って意思決定する。
ここまで含めてマネジメントなのだと思った。
FF14が本当に取り戻そうとしたものは「信頼」だった
ここまでの話だけを見ると、
大規模なシステムをどう再構築したのか、
という技術的なプロジェクトの話に見える。
でも、この講演で自分が一番印象に残ったのは、技術の話ではなかった。
FF14が立て直しで掲げていた大きな目標の一つが、
「お客様の信頼はどうやったら取り戻せるのか」
だったことだ。
もっと高性能なゲームを作る。
もっと面白いゲームを作る。
もっと売れるゲームを作る。
もちろん、それも重要だったと思う。
でも、そのさらに上に、
一度失ってしまったプレイヤーからの信頼を取り戻す
という目的がある。
だから単純に、
「今のFF14は失敗したので終了して、新しいゲームを作ります」
では駄目だった。
FFというシリーズに対する信頼。
FF14を遊んでいたプレイヤーからの信頼。
それにゲームを作ることで応える。
この目的があったからこそ、
「既存ゲームを運営しながら、同じFF14として作り直す」
という普通ではない選択につながったのだと思う。
ここはプロジェクトを考えるうえで、とても重要だと思った。
プロジェクトでは、
納期。
コスト。
品質。
売上。
工数。
いろいろな数字を追いかける。
どれも必要だ。
でも、そればかり見ていると、
「そもそも、このプロジェクトは誰のために何を実現しようとしているのか」
が抜け落ちることがある。
納期を守った。
予算も守った。
予定していた機能も全部実装した。
それでも利用者が求めていたものと違えば、本当に成功なのだろうか。
逆に、大きな問題が発生したときにも、
最終的に守るべきものが分かっていれば、判断基準になる。
FF14にとって、それが「信頼」だった。
技術的な話以上に、ここがこの講演で一番印象に残った。
FF14の立て直しから、自分の仕事に持ち帰りたいこと
FF14ほど巨大なプロジェクトを自分が経験することは、おそらくないと思う。
だから、この事例をそのまま真似することはできない。
そもそも講演自身が、
「普通ではない事例なので、そのまま役には立たない」
というところから始まっている。
でも、考え方を小さくしてみると、普通の開発でも使えることはかなりある。
自分なりに整理すると、特に持ち帰りたいのは次のことだった。
1. 問題が起きても、すぐ解決策に飛びつかない
問題が大きいほど、一度止まる。
感情や焦りではなく、まず事実を見る。
2. 現在地だけを見ず、「あるべき姿」を決める
今ある問題だけを直すのではなく、
「最終的にどういう状態にしたいのか」
から逆算する。
3. 現状とゴールの差を、問題として正しく見る
解決できるかどうかは後で考える。
まず問題を問題として認識する。
4. 自分一人で答えを出そうとしない
専門家に任せるところは任せる。
大事なのは、正しい判断ができる人を集めること。
5. 手段を最初から決めない
改修する。
作り直す。
機能を捨てる。
別の方法に置き換える。
どれを選ぶかは、目的と調査結果から判断する。
6. 最後は決める
調査だけを続けてもプロジェクトは進まない。
必要な情報が揃ったら、最後は意思決定する。
こうして並べてみると、一つひとつは当たり前のことにも見える。
でも、
プロジェクトがうまくいっていない。
納期が迫っている。
問題が次々に出てくる。
関係者から色々な意見が飛んでくる。
そんな状況でも、この順番で冷静に考えられるかというと、簡単ではないと思う。
だからこそ、
「ゲームを作り直すということ」
という特殊なFF14の事例が、自分にはプロジェクト立て直しの教科書のように見えた。
プロジェクトマネジメントについて勉強すると、様々な手法や用語が出てくる。
それらを学ぶことも必要だと思う。
ただ、それと同時に、
実際のプロジェクトで問題が起きたとき、その知識をどう使って考えるのか。
そういう実例を見ることも大事なのだと思う。
そして自分自身も、FF14のような巨大なプロジェクトではなくても、
仕事の中で何か問題にぶつかったとき、
いきなり「どう直すか」を考えるのではなく、
「今どうなっているのか」
「どこへ行きたいのか」
「その間には何があるのか」
から考えるようにしたい。
| FF14立て直しで行っていたこと | 一般的な開発で考えると |
|---|---|
| 冷静に現状を把握する | 現状分析・事実確認 |
| あるべきFF14を定義する | ゴール・成功条件の定義 |
| 現状との差を洗い出す | Gap分析 |
| 信頼できる専門家を集める | チーム編成・専門家との意思決定 |
| 改修と作り直しを比較する | 選択肢評価 |
| 最後に決断する | 意思決定・ガバナンス |
| 信頼を取り戻す | ステークホルダー価値の回復 |
