なにか物事が起きれば、原因がある。
人は、１つのことに原因があると思っているが、物事は１つの事象に見えて複数の事象の組み合わせであることが多い。
そのため、物事に対する原因は１つとは限ららない。
今回は前回の出来事に関して話させていただいた炎上案件の原因究明に関するお話をしたいと思います。
出来事編のリンクを張っておきます。
tkymx83.hatenablog.com
問題は何だったのか
ここまで来ると、問題点が露呈する。
第一に仕様が期間内に終わらなかったことだ。
第二は仕様が詰めきれていなかったこと
第三は試遊会の段階で方針に変更があったことだ。
これらの原因を噛み砕いて深掘りする。
なぜ仕様が期間内に終わらなかったのか？
まず疑われるのは、仕様を考える期間が決まっていたのか？ということだ。
今回の実装は３ヶ月周期のリリースの中での決まったマイルストーンとは外れて動いていた。それは機能が通常よりも大きなものになっていたからである。事前に必須な部分ははじめから決まっていたし、その部分の実装は進んでいた。
そのため、企画が仕様書を作らなくとも、作業は進んでいたし、制限を設ける動きもなかった。動きがないということは誰も仕様書ができていないことを疑わない。そして仕様書作成が遅延したと考えられる。
次に疑われるのは、仕様を策定する期間が適切かどうかだ。
今回作成する機能はかなり大きなものだったため、通常の仕様よりも量が膨大になっていた。そのため、通常の仕様策定期間ではまかなえなかった可能性がある。
しかし、この期間が適切かを図ることは具体的にはできない。それは仕様は考えれば考えるほど深みにハマっていくからだ。期日があれば、それに合わせて適切な仕様を作成する。この仕様の優先度順に実装を行っていけばいい。
まとめると、
期限が設定されておらず、それを追う人もいなかったことが原因となる。
なぜ仕様が詰めきれていなかったのか？
基本的に仕様は企画が作成して、エンジニアに漏れがあるかを確認するフローを経て完成する。エンジニアは実装の担保を行っており、具体的な実装方法を模索しているため、辻褄が合わない仕様があればそれに気づくことができる。しかしそれは、仕様書が正常に出来上がった後の話である。そしてそれが仕様書に記載されていたときの話である。
今回の開発では実装と一緒に仕様書が作成されていった。そのため、仕様書は常に完成されておらず、常に更新され続けた。更新されればよいのだが、口頭ですり合わせた内容が仕様書に記載さていないことも多く、暗黙の了解になっているものもあった。暗黙の了解が増えると、その事象に起因した別の条件で不具合が起きることがあり、それが仕様漏れへと発展していったと考えられる。
つまりは、実装途中であれ、実装前であれ仕様が変わり次第仕様書を更新し実装者に伝えていない体制が原因になる。
なぜ試遊会の段階で方針に変更があったのか？
まず気になるのは、方針を理解して仕様が作られていたのか？その方針が満たされていることを他の人も確認したのか？ということである。
方針というものは基本的に一年前から決まっており、それに則ってゲームというものは作られていく。その方針は全体共有はされているがかなり抽象的な内容になっている。その抽象的な内容を企画担当が具体的な仕様へと落としていく。この過程は企画の仕事になり、企画の腕が試されるところである。
しかし、作成するのは個人であり、方針も抽象的なことから必ず認識の齟齬が発生する。その認識の齟齬は仕方のないことであり、それを防ぐには他の人にも仕様を見て貰う必要がある。方針のレビューである。
これができていなかったために、
仕様の策定の段階でだんだんとずれたものになっていき、最終的に方向修正の工数がかかってしまうのではないかと考えられる。
このような場合どのような対処が必要なのか？
解決は一つ一つが長くなるので記事を分けて書こうと思います。
tkymx83.hatenablog.com
