漠然とした問題は誰しも持っていると思う。
僕の場合はチーム開発に関してのものが多い。リリースする機能の開発がいつになっても終わらない。俗に言う炎上案件である。
終わらない理由はいろいろあり、時間がかかっているのもいろいろある。だから、はっきりとこれが問題で何を解決すればいいかがわからない。
今日はそんな炎上案件に対応したときの自分の備忘録として今回起きた問題を聞いていただければ良いと思います。最終的には問題に対する原因の深掘りをできればいいと考えています。
前三部作になっており、
原因究明編のリンクも張っておきます。
tkymx83.hatenablog.com
開発はどんな流れで進んでいたの？
チームの開発は三ヶ月周期で行われている。大体二ヶ月開発をして、一ヶ月検証を行ってバグがないことを確認したらリリースする。その案件は、期間がかかるものだったので、４ヶ月前から開発が行われていた。
ゲームづくりのはじめは仕様決めから行われている。仕様決めを行ってから開発の工数の算出を行って開発が始まる。今回は仕様決めがかなり難航していた。実際に仕様として落とし込むまでに時間がかかり、作業工数がはじめの段階で算出できないことが多いにあった。それは、仕様が決まっていないから、出せないというものだった。
その後、仕様が決まらず、共通部分の開発のみ行っていた。その間も仕様作成が並列で行われており、開発は行われていたが、詰まっていないところもあり、十分に作れなかった。十分に作れるとなったのは開発終了の二ヶ月くらい前でその段階へ工数を再度見積もったが、その時点で開発の遅延が起きることがわかった。
仕様書が作成されてから、仕様書の漏れがいくつか見つかった。それらの追加仕様に対する見積もりは別途追加され、当初よりも想定以上の仕様の開発工数が発生していた。
その後現在の仕様で試遊会が行われた。試遊会では、実際の機能を遊んでみてその感想をインプットシートにまとめる。インプットシートにまとめたものはその後、企画の中で精査されて、改修が必要な場合はそこで修正が入る。
今回はこの試遊会で企画の方向性に難があるといわれ、変更仕様が多数発生した。その後、その仕様の実装の再見積もりが行われ、再見積もりの結果かなりの遅延が見込まれることがわかった。
このプロジェクトはいまだに終わっていない。
事実からわかること
今回の開発では、三回の遅延が発生している。
一回目は、仕様の策定が遅れたことだ。それによって、工数の見積もりができず十分に開発ができなかった。企画が定まった段階で再度見積もりを行ったがすでに開発遅延が決定していた。十分にできないというのは、仕様追加があることを前提で作るため、設計にもれが出る可能性があるということだ。
二回目は、仕様の漏れによる仕様の追加とそれによる実装期間の延長である。実装内容が物理的に増えることで、実装見積もりは大きく変わってくる。今回は仕様の漏れに起因する実装工数増加が複数発生した。
三回目は、試遊会によって企画の方向性が大きく変わったことだ。実はこの段階で企画の担当者が変わっており、変わった段階で方向性が若干異なることがわかった。これによって、追加仕様や修正が発生し仕様が変更。一度に変更があるのではなく、その都度変更が発生したため、最終的な工数見積段階ではすでに遅延が発生していた。
これが今回の事象のまとめである。
理想の開発とは？
理想的な開発について話す。
まず、仕様が期間内に終わっておりそれが当初想定した目的を満たしていることである。仕様期間内に固まっていることで開発工数の算出を行うことができる。それによって、具体的なスケジュールを持って開発を行うことができる。企画がその段階で定まったため、設計を行うことができる。それによって実装の効率化や共通部分の算出などを行うことができ、開発効率化につながる。
次に試遊会では、作成した機能のブラッシュアップを行うことができる。試遊会では実際に手にとって一連の流れを追うことができる。一連の流れを体験することでわかることがある。それは、使いづらさや、機能の分かりづらさなどである。これらは机上の空論ではわからず、実際にやって見なければわからない。試遊会ではそのようなブラッシュアップに関して意見が出て細かな修正にとどまる。
そして、それを直して検証フェーズへと移行する。
これが理想的なパターンである。
では何が原因でこの理想が達成できなかったのか。
それは次の記事で考えていきたいと思います。
