今いるチームが、トラブルを少なくするためにやっている事(人間系)

  • 46
    いいね
  • 0
    コメント
この記事は最終更新日から1年以上が経過しています。

はじめに

これは ドリコムAdventCalendar の12日目の記事です。
11日目はmickey19821さんによる出来る!DNSのお引っ越し!です。

自己紹介

@motsat

  • ドリコム暦3年ほど
  • スマートフォンのネイティブゲームのチームで、クライアント/サーバサイドのエンジニア

この内容について

今のチームで行われている、トラブルを少なくするための動き(手動系)について書きました。
RSpec等の自動テストや検知ツール等の「自動系」については他社含め情報が入ってきやすいと思います。

ただ、それ以外で人間がトラブルを防ぐ「手動系」はあまり情報が入ってこないなと思い今のチーム内で行なわれている事について書いてみました。
(自動テストが通ったら即リリースみたいな環境もあるとは思いますが)

※このページにはモダンなテストツールや便利な検知サービス等の話は出てこないので探さないでください

今いるプロジェクトの状態

iOS/Androidでプレイ可能なネイティブゲーム。

・アップデート、更新頻度

月に約1度くらいの機能追加アップデート、2週間に一回ほどのイベント配信 + その他に日々細かいコンテンツや告知周りの配信
という感じ。

・トラブルが起きる頻度

大きめなトラブル(例えば緊急メンテが必要になる物等、全て/大多数のユーザに「補填(お詫び)」不利益があるものとする)については、数ヶ月に1度くらいです。同種のアプリの中では比較的少ないかもしれません。
小さなトラブルについては毎日とはいかないまでも、数日に一度個別に補填、調査を行ってデータの修正等が必要になる事があります。

トラブルを事前に見つけるためにやっている事(検証)

手動での検証です。
手動テストの対象になるものは自動テストに技術的に変換しづらいものだったり、自動テストの環境が出来上がっていなかったり、人間の目での確認が必要になるものだったりするかと思います。

チーム内で見切れないような大きな更新がある場合は外部での検証を行う事もありますが、それ以外ではエンジニア/ディレクター/デザイナーなど含め、全ての人間がなんらかの検証をします。

検証に関わるメンバー

基本的に全員。
QA担当者もいるが量的に全てを見切れないのと、開発メンバーの観点で見る事も多いためほぼ全ての人が関わる。

Apple申請前

・新機能のチェック

やってる人:主にエンジニア、ディレクターだけどほぼ全員

要件やデザイン的なチェックはこの前段階(開発段階)で満たしている事は確認済みですが、申請直前のアプリの状態でさらに細かいシステム的なチェックを行います。
テストの観点は主に新機能の開発に関わった人が出し、過不足を他のメンバーがつっこみます。

gitのcommitログやredmine、他管理資料などからも更新内容を漁って項目が漏れないようにします。

また、正常系以外に異常系などを細かく見たりします。
例)
・時間限定の処理の場合、端末時間をずらしてサーバと違う時間でおかしくならないか
・処理の一連の流れの中で、アプリを落としてみる(復帰時の処理確認)
・ネットワーク系の異常処理の確認(途中で切れた、タイムアウトなど)
・ネットワーク通信中などの処理中にタップしまくる(タッチイベント無駄にとってないか等)
・その他、新機能のなるべく全条件を網羅できるテスト

・既存機能のデグレチェック

やってる人:主にエンジニアだけど、他の職種もする

既存機能がデグレを起こしていないかフルで見ます。
サーバ側は一部テストツールでデグレチェックは行われますが、それ以外のツールでは難しい部分等を見ます。
フルとはいっても、異常系の確認や条件のマトリクスチェック等を含める出すととても手が回らなくなるので、主に正常系の機能確認をベースとしています。

・アップデートチェック

やってる人:主にクライアントエンジニア

一部のデータをSQLiteで持っているため、スキーマなどに変更がある場合に旧バージョンから正常にデータ移行できるか等のチェック。
基本的には、ストアからダウンロードできるバージョンからのチェックを行っています。(さらに古いバージョンからのチェックまではちょっとできてないです…。)
実際にアプリケーションのバージョンアップなどをしてチェックをします。

データ配信のみの更新直前(イベント等のマスタデータ、画像/アニメーション/サウンドなど)

やってる人:主にディレクター、デザイナー、アニメーター、エンジニア

アプリ組み込み以外のデータ等を配信する時です。

パラメータに問題は無いか、デザイン、アニメーション(音も)に問題はないかなどを実際に動かして確認。
追加コンテンツ周り(イベントや新ステージなど)を、実際にプレイして確認します。

マスタデータの問題検知はjenkinsで自動で動かしてはいますが、配信タイミングが問題になったり、それがチェックできない何かまずい物がないかサーバエンジニアが差分を目視で人知れずチェックもします)

「お知らせ」配信前

やってる人:ディレクター、デザイナー、カスタマーサポート、「週直」

アプリを開いたときに、最初に表示される運営からのお知らせです。
リソースの配信作業等を基本的に必要とせず、管理ツール等で設定可能になっています。

内容に誤りがないか(文言、日時、数値、画像と文言の不一致などもないか、ユーザ観点での理解できないものや違和感がないか)をチェックします。

検証環境に設定された「お知らせ」をアプリから見ます。
配信担当者、お知らせの内容を考えた人、使用する画像を作った人以外にも「週直」と呼ばれるチェック担当者が週ごとに設定されます。
「週直」は、職種に全く限らずにほぼランダム(前の人からの指名)で割り振られます。

また、ユーザの生の声を一番知っているカスタマーサポートにもチェックをしてもらい問題が無い事を確認します。

トラブルを作らないためにやっている事(検証以外)

ここからは、そもそもトラブルを作らないための動きに影響してそうな事を書きました。

製品の「機能以外」の問題もストーリー化

やってる人:全員

スクラムベースでの開発を行っていますが、「ストーリー」には「製品」に必要なものだけでなく、「サービス開発(運用)のため」のストーリーを同等に扱っています。

スクラムの説明資料には「製品」に求める要求仕様を設定するとあり、運用する上での問題解決などがあまり扱われていない事もあります。
こうなると、製品の開発のみがトップクラスの優先度をもってしまって他の運用効率化などになかなか力をいれる事ができません。

運用の効率化、リファクタリング、??がしやすいなど、プロジェクトメンバーから見た、サービスを開発/運用する上でのストーリーも普通に追加されます。プロジェクトオーナーよりも、これはどちらかというとメンバー発信が多いと思います。

例えば、以下のようなものが追加されました。

  • デバッグしやすい
    デバッグ機能をチーム内で募集して開発する。
    簡単なものなら業務中に作ってしまえますが、規模の大きいものだと休日/残業力を使わないとなかなか難しいものです。それには期待せず、ストーリー化して工数をとって対応しています。

  • あるソースコードを誰でもいじれる
    レガシーコードで誰もいじれない(が、更新頻度も高い)部分があり、そのリファクタリングを行う

  • 配信が効率的に運用できる

  • 今後、??を更新していく体制がわかる

など。

負債を作らない、直す

やってる人:主にエンジニア

誰もいじれない、影響範囲がわからない、頻繁に問題が発生する等の技術的負債です。
今のプロジェクトではプロトタイピングからの歴史的事情により?、すごいSQL(JOIN、JOIN、JOIN、画面半分JOIN…)でかなりメンテナンスしていくには厳しい実装がありました。
これはリリースされたとしてその後のメンテナンスがかなりきつい事になるという事で、リリース直前にリファクタリングのストーリーを発動し解決されました。
リリース以降も、リファクタリングのストーリー=チームの問題として、技術的負債を作らない/直す事を必要な工数として対応しています。

振り返る

一定のタイミングで振り返りを行います。スクラムベースなのでスプリントレビューの中でも振り返りを行いますが、

  • リリース作業の後
  • 各イベントの制作/終了の後
  • 新バージョンの開発/リリース後
  • その他、振り返りった方が良いねって時

主に作業担当した人の参加率が高いですが、基本的には職種関係なく行います。
方法としてはKPTでの振り返りを行いますが、それぞれの項目に対して具体的な行動が設定されないと振り返りdoneとされません。
× 〜が良かった

○ 〜が良かったのは、今回〜をしたため。なので、今後もこれをキープする
など。

無理しない

 間に合わないもの、ぎりぎり完成しそうだけど検証が間に合わないようなものはスケジュールの見直しが行われます。
普通っぽい話ですが、無理して間に合わせるという判断が行われることも環境や状況によっては少なくないかと思います。

ただ、経験上、間に合わせでぎりぎりになって検証もおろそかになったものはまずトラブルが起こります(起こしました)。

開発メンバーからのアラートをトリガーとして、まずそうなスケジュールに対して見直しが行われます。

まとめ

人の手がかかる部分は多いですが、トラブルが起こるとそれ以上に対応する手がかかり、ユーザ的にも精神的にも(だいたい肉体的にも)つらい事になります。

これからも検証の内容、量、自動/手動の切り分けは更新されていくと思います。
人間と機械でうまく作業分担してトラブルを無くしていきたいものです。

明日はtakeshi.kamiya.vjさんです。