Jira 導入事例 - 株式会社gloops 様
gloops ソーシャルゲーム事業本部 品質管理部 岸康司氏に、自社のバグ管理およびプロジェクト管理にJira、WBSガントチャートを活用している理由とその効果について詳しく聞きました。
(gloopsについて）
gloopsは、「みんなの手に、新しい遊びを。」をスローガンに、モバイルゲーム上で革新的な価値を提供しつづけ、遊びを通じて人々と繋がる面白さを体験できるゲームの開発・運営を行っております。現在までに約40タイトルを配信し、累計約4,000万人のお客様に楽しんでいただいております。
Jira、WBSガントチャートを社内の標準ツールとして活用
gloopsでは、Jira、WBSガントチャートをどう活用していますか。
gloopsではJiraおよびWBSガントチャートを、それぞれ「ゲーム開発のバグ管理、タスク管理」のために「標準使用ツール」として活用しています（※）。
概要は次のとおりです。
| 項目 | 内容 | 備考 |
|---|---|---|
| Jiraの用途 | - バグ管理 | プロジェクトによっては「外部企業との見積やりとりにもJiraを活用している」という使用例もあります。 |
| WBSガントチャートの用途 | - タスク管理 | プロジェクトの工程・進捗管理。 |
| 利用者 |
-プロジェクトメンバー（外部委託含む） - 品質管理部門 |
|
| ライセンス数 | 2000ライセンス | オンプレミス運用 |
| 導入時期 | 2014年11月 |
|
「標準使用」とは「会社として強く推奨」という意味合いです。どんなツールを使うかの最終決定権は各プロジェクトのプロデューサー、ディレクターに属します。
外部とのアクセス制限
アクセス制限などセキュリティ対策はどのように実施していますか。
アクセス制限については「社員」と「協力会社社員」で運用方針が分かれます。
まず基本ルールとして「社員」のアクセス制限は特に実施していません。情報共有が推進するためにも「他のプロジェクトのバグ管理やスケジュール管理の様子が知りたいのなら、いつでも自由に見てよい」という運用です。ただしIPコンテンツなどは知財管理のために社内でも関係者のみ閲覧可能としているプロジェクトもあります。
次に「協力会社へのアクセス制限」についてですが、これは次のように運用しています。
- 参加プロジェクトの情報のみアクセス許可
- 協力会社社員は自分が参加しているプロジェクトの情報しかアクセスできません。他プロジェクトの情報は閲覧できません（gloops社員とはここが違う）。
- 会社からのアクセスのみ許可
- gloopsの社内または協力会社の会社からのアクセスしか認めていません。つまり協力会社の社員が自宅PCやモバイル環境からアクセスすることができません。
バグ管理の基本方針
gloopsのバグ管理の運用方針を教えてください（※）。
バグ管理では、大きくは「どんなバグがいくつあって、現時点では誰がどう対処しているのか」を把握します。詳しくは次のとおりです。
- 総数
- 今いったいバグがいくつあるのか？ 数値把握は管理の基本です。
- 優先度
- 数え上げたバグを「お客様にとっての重要度」を基準にレベル分けします。お客様のゲームプレイを阻害する度合いの高いものが、対応優先度の高いバグということになります。
- 担当者
- どのバグを誰が担当しているのかを明確にします。
- ステータス
- 各担当者のバグへの対応状況を「未着手」「対応中」「対応済み」などステータスで明確化します。
Jiraでは、これらバグ情報を様々な形でカスタマイズ表示できます。
- 全体を把握したいプロデューサ、ディレクター向けには…
- →「ダッシュボード」の形で「バグの全体状況」をグラフィカルに一覧表示し、状況を把握できます。
- 自分の仕事に集中したい現場プログラマ向けには…
- →「自分が担当となっているバグの一覧」という形で表示できます。開発者はこれらバグを「消し込んで」いきます。
Jira導入の効果および改善点は次の通りです。
- バグの可視化により、以前に比べ、バグの解決スピードが2倍に高速化した。
- 担当者が明確化されたことで、全体の状況把握が容易にできるようになった。
バグが一覧表で見えるようになったことで、「このままでは気分が悪い、速くバグを一掃してスッキリしたい」という、技術者なら誰もが持つ「攻略マインド」が刺激されたわけです。「バグ状況の見える化」により、品質改善の対応速度が改善されました。
あたりまえ品質と魅力的品質をバランス良く確保するために
gloopsでの「品質管理のコンセプト」を教えてください。
ゲームの品質管理の目的は「お客さまにゲームを楽しく快適にプレイしていただくこと」です。この大目的を実現するために、ゲームには「当たり前品質」と「魅力品質」の両方が備わっている必要があります。
「あたり前品質」とは、「発売されたゲームにバグがない」「スムーズにプレイできる」などお客さまにとっての「あたりまえ」が実現されていることを指します（一般工業製品の「品質」は、通常この「あたりまえ品質」を指します）。これの確保は、ゲーム発売前のテストを担当する、品質管理の業務となります。
一方、「魅力品質」とは「ゲームのおもしろさ」のことです。これら2つの品質を確保するにあたっては、大きく次のような課題、困難があります。
- 課題1．「ソーシャルゲームは開発に終わりがなく、したがって品質確保にも終わりがない」
- ＲＯＭ化され店頭発売されるゲームの場合、「リリース」がひとつのゴールであり、開発や品質管理の作業は、それまでに終えなければなりません。一方、オンラインで楽しむソーシャルゲームの場合、初回発表後もイベントの追加など企画・開発作業はサービス運用として継続して行うため、品質管理（バグ取り）も継続します。「リリース」が本当のスタートいえるでしょう。
- 課題2．「ゲームコンテンツの運営は『魅力品質の向上』が本来業務」
- プロジェクトがバグ対応に忙殺されると、ゲームを面白くするための「魅力品質の向上」に時間を割きにくくなります。プロジェクトのリソースを「魅力品質（おもしろさ）の向上」という本来業務に集中させるためにも、バグ対応を効率的に行うしくみが必要でした。
2012年に、バグ管理システムとして有名だったフリーウエアRedmineを全社導入しました。しかしRedmine導入は残念ながらうまく運用する事ができませんでした。
最初のバグ管理システム導入が失敗した理由
なぜそのシステムは効果的に使われなくなったのでしょうか。
今、ふりかえると、導入失敗の理由は「運用目的、運用ルールを定めないまま導入したこと」だったように思います。
「運用ルールの不備」ですが、Redmineを導入した際は、バグ管理のシステム化を急ぐあまり、「とにかく」「とりあえず」バグ管理システムを導入するという形になりました。
そのため運用ルールの設定が「現場任せ」となり、その結果、バグの重要度、優先度など各種指標の粒度が、プロジェクトごとメンバーごとにバラバラになってしまい、バグ管理の運用がプロジェクト依存となってしまいました。
その後、ゲームコンテンツの品質を向上させるために品質管理部門が中心となり、開発リーダへの状況や要望のヒアリングを行い、Jiraを含む数製品を比較検討しました。2014年前半のことです。
システムに求めた要件
新たなバグ管理システムを選定するにあたっての、求めた要件を教えてください。
gloops全体で活用するバグ管理システムに対しては、次の6点を要件として求めました。
- 要件1．「バグ管理システムとしての基本機能が十分である」
- バグの種別、性質、個数、担当者、仕掛かり状況を明確に把握できることを求めました。
- 要件2．「インターフェースの使いやすさ」
- バグ管理システムは技術者にとって「毎日使う”いつも使いの道具”」となります。今回、導入するシステムには、操作性、ボタンの位置、画面遷移の速さ、少なさなど、現場が「さくさく使えること」、「使っていてイライラしないこと」を求めました。
- 要件3．「各種画面のカスタマイズが可能であること」
- インターフェースというものは、人ごとに「使いやすさの観点」が違います。また、それを使う人の「立場」、すなわちその人がマネージャーなのか、現場プログラマなのか、品質管理部門なのかによっても見たい情報は異なります。新たに導入するバグ管理システムは、使用者それぞれの観点、ニーズに合わせて自由に画面をカスタマイズできることが望ましいと考えました。
- 要件4．「プロジェクトごとのカスタマイズが容易であること」
- 「人ごと、立場ごと」のカスタマイズに加え、「プロジェクトごと」の表示カスタマイズも重要です。プロジェクトごとに目的も体制も運営方法も異なるため、「表示すべき情報」をざっくり統一し、これを基本にして、プロジェクトにとって必要な情報を個々カスタマイズする事が考えました。
- 要件5．「拡張性・将来性の高さ」
- 新たなシステムは、とりあえずは「バグ管理システム」として導入します。しかし将来的に開発部門から、「タスク管理」、「スケジュール管理」などプロジェクト管理機能の追加、拡張をを求められることは十分ありえます。今回、導入するバグ管理システムには、そうした「拡張性」を備えていることを求めました。
- 要件6．「セキュリティ機能」
-
バグ管理システムは、社外の協力会社にも、ある程度まで開放して使うことになります。そうした運用に耐えうる十分なセキュリティ機能があることを求めました。
以上、6要件を基準に各製品を比較した結果、Jiraが弊社の求める要件を最もよく満たしていたので、これを導入することに決めました。
Jira導入を行ったプロジェクトからは直後から「スケジュール管理も同じJira上でやりたい」という要望が上がったことを受け、2014年12月には「WBSガントチャート」を正式導入しました。
社内浸透のために気を配ったこと
「Jiraの導入、社内浸透にあたり気をつけたこと」を教えてください。
Jiraの導入にあたっては、Redmineがうまく浸透しなかったことの教訓を生かし、「事前の運用ルール作りとその説明」に、時間と手間をかけました。
まず「運用ルール作り」については、「お客さまに品質の高いゲームサービスを提供する」ことを目標に私たち品質管理部門が主導してゲーム開発に則した基本ルールを定めました。「gloopsとしての品質管理のあるべき姿」を定めて、必要な管理項目が何か、それに必要なバグ管理の項目、守るべき運用ルールを逆算しました。
さらに、リックソフトに協力をあおいで、バグ管理の社内勉強会を開催しました。Jiraは開発プロジェクトの「全員」が使える必要のあるツールです。
しかしプロジェクト内全員が課題管理システムの操作に習熟していません。そうしたスタッフ向けに、「バグ管理のいろは」、「Jiraの使い方」を「自由参加の社内勉強会」という形で講義してもらったのです。
社内勉強会の反響
自由参加での開催でしたが、出席人数はどうでしたか？
当初はバグ管理のような地味な勉強会にどれほど参加者があるか未知数でしたが、実際には30人前後の出席がありました。
リックソフトの講師の説明も分かりやすく、勉強会後のアンケートでは「ためになった、わかりやすい、出席して良かった」などたいへん好評でした。アンケートの得点は5点満点の4点と高得点で、説明会は開催して本当に良かったと思います。
Jiraへの評価
Jiraの評価をお聞かせください。
まずJiraについては、社内でみなが積極的に使ってくれています。プロジェクトサイドからは「Jira、いろいろできていいよね」と好評で、「もっとこんなこともできてほしい！」「このプラグインを導入してほしい！」など積極的な要望も次々上がっています。
社内に「Jiraはファン」も生まれているほどで、今回の導入は順調に進んでおり、軌道に載ったといえます。
このたびのJira導入の効果（ビフォーアフター）は、「以前はバグの状況が『分からなかった、数えられなかった』のが、現在は『分かる、数えられる』といなったこと」、「それが開発スタッフのやる気を刺激して、バグ解決スピードが劇的に向上したこと」となります。
今後、バグ管理や数値を蓄積していけば、月次分析、プロジェクトごと分析を行うことも可能になるでしょう。細かい分析を重ねていけば、今とは違う確度からバグ削減を推進できると確信しています。
先輩ユーザーからのアドバイス
現在、バグ管理システムの導入を検討している企業に向けて「先輩ユーザーからのアドバイス」などあればお聞かせください。
まず「バグの見える化は本当に力がある」ということをお伝えしたく思います。可視化によりバグの解決速度が向上します。
また「事前の運用ルール作りと説明会が必須であること」もお伝えします。とりあえず導入して、ルールは後から決めればいいというのではなく、最初にガッチリ固めることが重要です。この場合、説明会の講師は外部に依頼することになるでしょうから、それを快諾してくれるベンダーから製品を購入することが重要です。
今後の期待
リックソフトおよびアトラシアンへの今後の期待をお聞かせください。
まず追加要望から述べます。Jiraはカスタマイズが自由で、その上プラグインが2000以上もあり、「何でもできる」のはたいへん素晴らしい点です。しかし、一方で「あまりにプラグインが多すぎて、どれが自分たちに適正なのか、どんな使い方をすれば良いのかが判然としない」という副作用も出ています。
この点についてはリックソフトに、「プラグイン選択のガイドラインの提示」あるいは「使い方のコンサルティング」などのサービスを強化していただければと思います。
gloopsでは今後とも「みんなの手に、新しい遊びを」という企業スローガンが実現できるよう、引き続きゲームの品質向上に努めていく所存です。リックソフトおよびアトラシアンには、gloopsのそうした取り組みを、優れた製品とサポートの提供を通じて後方支援いただくことを希望します。今後ともよろしくお願いします。