バグをゼロにするためには何が必要か
CyberAgent Developers #2 Advent Calendar 2018の17日目の記事です。 adventar.org
SumzapでゲームエンジニアのTeamManagerを担当していますkazun9です。
私達は、お客様に不利益を与えてしまうものを不具合と呼んでいますが 不具合を大きく分類すると下記のように分けられます。
- ソースコードのバグによるもの
- ゲーム仕様、パラメータ設計等の不備によるもの（いわゆる仕様バグ）
- 社会インフラや環境によるもの（外部的要因）
今回は、バグによる不具合について書いていこうと思います。
不具合による影響
「ZERO BUGS シリコンバレープログラマの教え」という本には
「もしバグが顧客によってみつけられたなら、それは開発者の時間、顧客の時間、品質保証チームの時間、サポートチームの時間を使ってしまっている」
と書かれています。
これを実際のゲームの運用に当てはめてみましょう。
- お客様がバグをみつける
- カスタマーサポートが連絡をうける
- QA(品質保証チーム）が再現確認をおこなう
- 運営チームがゲーム内に現象の告知をする
- エンジニアが修正、テストをおこなう
- QAがチェックする
- デプロイする
- 修正完了の告知をする
さらにお詫びや補填が必要になれば
- お詫び、補填内容を決める
- 内容を仕様に落とす
- エンジニアが実装、テストする
- QAがチェックする
- 配布する
- 完了の告知をおこなう
これは一例ですが場合によれば５分ですむ一手間（テスト）を怠ったが為に このようにお客様を含め膨大な時間を使ってしまうことがあります。
最低限やるべきこと
まずエンジニアがバグを出さないために最低限やらなくてはいけない事は
「追加・変更した全てのソースコードをテストすること」です。 ベースにこの考えがなく、少しの修正だから大丈夫だろうとテストを怠れば 上に書いたようにお客様や他チームの膨大な時間を使ってしまうことに繋がりかねません。 テストをより短時間で安定的に行う為にUnitテスト、静的解析、CI/CDツール等がありますが ツールや手法はなんであれベースの考えは同じであるべきでしょう。
循環的複雑度
追加・変更した全てのソースコードのテストをする為にはコーディング時から注意が必要です。 コードの複雑度を表す指標に 「循環的複雑度」（Cyclomatic complexity）というものがあります。 これはコードの経路の数をあらわしていて ifやfor文などの分岐がないものを１、分岐がが１つあれば2となります。 下記のコードはif文の数は違いますが経路の数は同じなので循環的複雑度は両方とも２です。
if(a){
f1()
}else{
f2()
}
if(!a) f1() if(a) f2() if(!a) f3()
一般的には循環的複雑度は10以下が良いとされるそうです。 小さければ小さいほどシンプルでテスタビリティが高いコードということになります。
組織とバグ
私は7年以上Sumzapでゲームの運用・開発に携わっていますが同じような環境やルールで運用していても 組織の体制や状態によってかなり影響されます。
有名な法則に以下のようなものがあります。
コンウェイの法則 (Conway's law)
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.「ソフトウェアの構造はそれを作った組織を反映している」
マーフィーの法則(Murphy's law)
If it can happen, it will happen.「起こる可能性のあることは、いつか実際に起こる。」
特に組織の体制変更、人の入れ替わり時にはかなり注意が必要で、チーム間のナレッジの共有不足、コミュニケーションロス、属人化等はソフトウエア構造に反映され、ちょっとしたキッカケであっという間に手のつけられないバグの連鎖を生み出します。
まとめ
今回は、サービスを運用していると避けては通れないバグについて書いてみました。 恥ずかしながら現プロジェクトでは到底バグゼロとは言えない状態ですが バグをゼロにする為には個人の意識、新しい仕組み・ツール、組織力それぞれの力を結集して取り組む必要があります。 これからもバグが無く楽しく安心して使っていただけるサービスを目指していきますので今後ともよろしくお願い致します。
