「人為ミス防止」フレームワークと「プロセス可視化」ツールを使って プロセス改善を実践してみた
- 2. 2 Agenda ● 自己紹介・QA組織の紹介・ゲーム運営の状態 ● 障害を削減するために何を改善すればいいのか？ ● どこに問題があるのか？を解決する ～問題があるプロセスを可視化する～ ● 何の問題があるのか？を解決する ～ヒューマンエラーの根本原因を明らかにする～ ● なぜ「PFD」と「A-KOMIK」に着目したか ● どのように効果を測定するか ● 効果と今後の展望 障害分析の準備 障害分析 ツールの採用理由 効果測定
- 3. 3 多摩美術大学大学院 芸術学専攻修士課程修了。セキュリティソフト会社にて、 品質管理部門の立ち上げに関わり、リリースフローの構築、品質マネジメントシ ステムの制定、障害の分析・削減、PMO業務などに従事。 その後、リリースフローへのUXデザイン導入プロジェクトを立ち上げ、リリース 前のプロトタイプ提供により顧客FBを得る仕組みの構築などを実施。 2018年からゲーム業界へ。2019年より、障害の分析の観点から、プロセス改善を 通じて運営中ゲームの品質向上に尽力中。 筑後 友恵 ちくご ともえ 品質管理部 品質管理グループ KLab株式会社 経歴
- 4. 4 QA組織 ● 従来はテストの計画作成、改善、ベンダー管理を担当 ● 昨年より障害管理、テストコスト最適化、魅力的品質に 関わるテストフローの構築などの横断的な活動に着手 ● 限られたリソースで3つの業務を並行して行う必要がある ○ サービス開始前タイトルの品質向上 ○ 運営タイトルの品質維持・向上 ○ 横断的なQA活動 プロデューサー プロジェクトマネージャー 企画 制作 開発 QA テスト 運用、新規‥ イラスト、UI、3D‥ クライアント、サーバー‥ 設計、実施‥
- 5. 5 ● タイトルの運営が長期化し、障害発生の要因が複雑に なっている ○ 5年～ ：3タイトル ○ 3年～ ：2タイトル ○ ～2年 ：4タイトル ● なぜ起きたかの原因を追究した防止策の導入例は少ない 機能追加／環境系アップデート イベント／ガチャ等のリリース モバイルオンラインゲーム運営の状態 Ver.1.1 6/4 6/11 6/18 6/25 7/2 Ver.2.0 7/9 7/16 7/23 ・・・
- 7. 7 現状把握をする ● 複数の運営タイトルを担当 ○ テスト支援 ○ 障害の振り返り会の実施支援と参加 ● 得られた気づき ○ 各タイトルでプロセスや作業、責任分界点が異なる ○ 障害管理は各タイトルごとに実施している ■ 障害ランクや管理項目は、各々カスタマイズされている ○ なぜ起きたかの原因を追究した防止策の導入例は少ない ■ ナレッジ化、標準化、プロセス改善などの観点の不足 ○ 長期運用により障害発生の要因が複雑になっている ■ テストやチェックで拾おうとしてしまっている事例も
- 8. 8 障害分析のコンセプト ● どこに何の問題があるのか ○ どこ ＝ プロセス（作業） ○ 何 ＝ 人のミス ● 問題があるプロセスを可視化したい ○ 不具合を作り込んだ／見逃したプロセス ● ヒューマンエラーの根本原因を明らかにしたい ○ ヒューマンエラーを誘発するシステムや作業フローになっていないか ○ ミスが起きやすい作業環境や心理状況になっていないか
- 9. 9 コンセプトに合う情報収集のための工夫 ● 問題があるプロセスを可視化したい ○ 『障害管理表』に共通項目を作成 ■ 発生箇所 ：マスタ、プログラムなど不具合が発生した箇所 ■ 発生経緯 ：ミス発生、見逃した当時の作業や環境・状況 ■ 作り込み原因：仕様書間違い、コーディング時の考慮漏れなど ■ 見逃し原因 ：テスト手順のミス、仕様レビュー時の考慮漏れなど ● ヒューマンエラーの根本原因を明らかにしたい ○ 障害振り返り会の実施方法の改善 ■ 振り返り会の前に、企画・開発・制作・テストの各セクションで不 具合を作りこんだ／見逃した当時の作業や状況を確認してもらう ■ 各セクションリーダーとQAによる障害振り返り会
- 11. 11 ● PFD(Process Flow Diagram)で作業と成果物を洗い出す プロセスを可視化する インプット 作業 アウトプット 仕様 レビュー 仕様書 マスタ入力 資料
- 12. 12 不具合の作り込み／見逃し ● 不具合を作り込んだ、見逃したプロセスで分類 ○ 『障害管理表』の追加項目と障害振り返り会で得た情報を元にQAが実施 仕様書作成 仕様書 仕様レビュー マスタ入 力 資料 マスタ入力 コーディング マスタ データ ・・・ 作り込んだ プロセス マスタデータ チェック ・・・ 見逃した プロセス 仕様書作成 仕様書 仕様レビュー マスタ入 力 資料 マスタ入力 コーディング マスタ データ ・・・ 作り込んだ プロセス 見逃した プロセス マスタデータ チェック ・・・ パターン1 パターン2 ・・・ ・・・
- 13. 13 プロセス上の問題の傾向を見る ● タイトル間で汎用性の高い言い回しに調整した分類項目 ● 問題があるプロセスを数字で可視化する 発生箇所 不具合を作り込んだプロセス 不具合を見逃したプロセス ミスの種類 ● マスタ ● お知らせ ● 画像・映像 ● 3D制作物 ● プログラム ● インフラ ● SNS ● PF ● 仕様作成 ● マスタ入力 ● 画像作成 ● 詳細設計作成 ● コーディング ● 翻訳 ● SNS投稿 ● バランス調整 ● 仕様レビュー ● マスタチェック ● 実装確認 ● 画像チェック ● コードレビュー ● 翻訳チェック ● テストケース作成 ● テスト実施 ● 考慮漏れ ● 実施漏れ ● 実施ミス ● 伝達漏れ ● 双方の認識相違 ● 外部要因
- 15. 15 ヒューマンエラーの根本原因を見つける ● ヒューマンエラーの未然防止手法(A-KOMIK)を参考にした ヒアリングのフレームワークを導入 ● 直接原因／間接原因を明らかにする ○ 直接原因 ■ 管理（標準化、教育、標準の遵守）が曖昧になっている部分 ■ ルールが無い、抜けがある、教えていない、忘れた‥ ○ 間接原因 ■ 心理的、環境的に間違いやすくなっている状態 ■ 見間違い、聞き間違い、勘違い、記憶間違い、疲労、緊張‥
- 17. 17 間接原因を明らかにする 間接原因① 目学 作業に詳しく、トラブル対応に慣れたベテランであった故に起きてしまった 間接原因② 知り過ぎ 同時並行作業、例外処理作業、変更対応など、集中力が分散していた 間接原因③ 残像記憶 同じ動作を複数回繰り返す作業、数字の記憶・照合作業をしていた 間接原因④ 気を利かせ過ぎ 後でまとめてやる、ちょっと置いておくなど、効率を優先したが故に起きてしまった 間接原因⑤ ずるさ 作業経験に関係なく、誰のミスか分からない 間接原因⑥ 心離れ 休憩時間や退社時間の間際など、頭の中で今やっている作業以外のことを考えてしまっていた 間接原因⑦ イライラ 気になることがあり、作業に集中できていなかった 間接原因⑧ 見間違い いつでも、だれにでも起こり得る 間接原因⑨ 聞き違い いつでも、だれにでも起こり得る 間接原因⑩ 勘違い いつでも、だれにでも起こり得る 間接原因⑪ 疲労 体調不良などにより、五官機能が著しく低下していた 間接原因⑫ 緊張 プレッシャーや緊張を強いられる特別な作業、初めてやった作業だった 間接原因⑬ 気の弛み いつでも、だれにでも起こり得る 【ミス発生時の状況】 ・元資料の内容が正しいかどうかの チェックと、コピー＆ペースト作業 を同時に行っていた→間接原因② ・ある程度溜めて一度にチェックし ていた→間接原因④ ・タスクを抱えてしまい、ギリギリ のスケジュールで実施していた→間 接原因⑫
- 18. 18 フレームワークを使ってヒアリングをする ● ヒアリングシートに直接原因／間接原因を記入 ● 同じ原因のもの、数が多いものを抽出 ● 再発防止策をすり合わせるためのヒアリングを実施
- 19. 19 全体像 1. 発生箇所 ○ 「マスタ」発生の障害が一番多い 2. 不具合を作り込んだ／見逃したプロセス ○ 「マスタデータ作成」時の「実施ミス」が一番多い ○ 「テスト設計」時の「考慮漏れ」が一番多い 3. ヒューマンエラーの直接原因／間接原因 ○ 「ルールが無い」、「勘違い」が一番多い ○ 「ルールが無い」、「見間違い」が一番多い 4. 再発防止策を立てる 一番注力すべき対象 の再発防止 発生箇所で絞りこむ プロセスで絞りこむ ヒューマンエラーの 原因で絞りこむ
- 21. 21 要件 ● どこに問題があるのかを把握したい ○ プロセスを可視化する ○ プロセス、成果物、分担についての認識を合わせる ● 何の問題があるのかを把握したい ○ 障害分析を行う ○ 現状把握で得られた定性的な原因を定量化する ■ 複数のイベントを同時並行で作業していた ■ 急な仕様変更や差し込みだった ■ 人の入れ替わりが激しくて作業に慣れない ● 限られたQAリソースで運用・タイトルの負担を最小限に
- 23. 23 PFDとA-KOMIK ● PFD ○ 派生開発の現場で使われているプロセス設計のための表現方法 ○ インプット／アウトプットを分けて明記するため、作業分担が分かる ○ プロセスと成果物の両方の認識合わせに使える ○ 大きな教育コストを費やさずに作成、閲覧ができる ● A-KOMIK ○ 主に製造業の現場で使われている、ヒューマンエラーの原因分析・対策 ・未然防止のための手法 ○ 現状把握で得られた定性的な原因 ＝ ヒューマンエラーを分類できる ○ フレームワークがそのまま導入できる ○ ヒューマンエラーに特化しているため、汎用性が高い
- 24. 24 どのように効果を測定するか
- 25. 25 障害の削減を定義する ● 障害が削減できている ＝ 再発が防止できている ● 発生箇所が同じ ● 不具合の原因があるプロセスが同じ ○ 作り込まれたプロセスが同じ or 見逃したプロセスが同じ 仕様書作成 仕様書 仕様レビュー Fixした 仕様書 マスタ入力 コーディング マスタ データ ・・・ 作り込んだ プロセス マスタデータ チェック ・・・ 改善した プロセス ・・・
- 26. 26 効果と今後の展望
- 27. 27 効果 ● 2019年12月～2020年5月で繰り返し15件発生した類似障害 ○ 導入後2ヶ月で0件へ ○ 再発を止めることができた ● 問題があるプロセスや作業の特定が各セクションの改善 を加速した ● より上流での品質作り込みの活動に合流できた ○ 仕様書改善、仕様書作成プロセスの改善など ● 全体のプロセス改善を担っている立場の人に、直接原因 ／間接原因の傾向の可視化の需要があった
- 28. 28 今後の展望 ● 今回の導入は1タイトルのみのため、他タイトルでの導入 を検討したい ○ 障害分析の方法の横展開、ナレッジ化 ● 効果・需要があることが分かった以下2点についての情報 提供の方法等を検討したい ○ 問題があるプロセスや作業の特定 ○ 直接原因／間接原因の傾向の可視化
- 30. 30 いただいたご質問への回答 コメント:根本原因の追及の際、ネガティブな内容として言いにくい環境も生まれそうですがその辺り何か対策を 打たれたりされたでしょうか ● 犯人捜しや尋問会のようになってしまうことは絶対に避けたかったので、以下の点に気を付けました ○ 「なぜ起きたか？」という深堀の質問は、各セクションのリーダーさんを経由する ○ 個人ではなく、ヒューマンエラーが発生してしまう環境やシステムを改善したい、というコンセプト を日頃から伝える ● また今回、直接的なヒアリングに行く前にヒアリングシートを挟んだのは良かったかなと考えています ○ ヒアリングシートに書いていただいた内容で、分からないことがあるので聞いていいですか？という 流れでヒアリングをセット ○ お互いの上役に当たる方などはQAからは呼ばず（ちょっと〇〇さんお借りしますねとはお伝えし て）、作業担当者とQA（2名参加しましたが、喋るのは1名）のみのヒアリングにしました ● その際に、QAが担当者の時間を使っているという不透明感が出ないよう、今回の障害削減のプロジェクトに ついてはタイトルのPMには狙いやご協力いただきたいことを定期的に伝える機会を設けました