どうやってプロジェクトの不具合を4ヶ月連続で0件達成できたのか
はじめに
こんにちは、株式会社SHIFTでプロジェクトマネージャーを担当している「立野」です。現在PMとしてプランナーの皆さんのお仕事をお手伝いしています。
私のプロジェクトではソーシャルゲームの運営を行っています。
ゲーム運営という性質上、毎週イベントやガチャのリリース日があり追われるように仕事を行っていました。そのような忙しい環境もあって配属前からプロジェクトでは不具合が頻発していました。
これにより多くのクレームが来ている状況で、これはゲームを楽しんでいるお客様にはもちろん、それを提供しているチームとしても不健全な状況です。そこで私は配属後に改善に向けたアプローチを行いました。
本記事では、その方法や考え方などをご紹介します。マネジメントスキル向上の一助になれば幸いです。
1．不具合の要因を徹底的に「分解」する
まず課題を要素ごとに分解しましょう。
不具合はなぜ起きたのか
不具合はいつ起きたのか？
不具合によりどういう影響があったか
不具合発生時どういった状況だったのか
ここでポイントとなるのは、自分（PM）だけで完結せず、必ず不具合を出した担当者と一緒に不具合の原因や状況を整理します。
例）画面表示用のテキストデータに誤字があった
正しいテキストは何なのか
どういった誤字なのか
どのタイミングで誤字になったのか… 等
5W1hはもちろんですが、それぞれの要素は最小まで分解してみてください。
課題の例：いつ誤字が混入したのか？
良い例：初回のデータ入力後、修正指示があり、データ更新時に誤字が混入した
悪い例：データ投入前に誤字が混入した
良い例と悪い例では、分解の解像度が異なります。
良い例の方が、細かく課題を分解しています。
課題は考えうる最小単位まで分解しておくと後の原因と対策が立てやすくなります。
あいまいな状態にしておくと、見えていない別の課題が後から出てくる可能性があります。
2．時系列を整える
不具合が発生した場合には、その前後の時系列を整理しましょう。
誤字混入経緯の例（時系列）：
担当者が初回のデータを入力した
担当者が入力したデータを目視で確認した
担当者が別作業を実施した
管理者より修正指示があり、担当者が別作業を中断した
担当者がデータを手入力で修正した
＜誤字発生＞
入力したデータをリリース環境に反映した
ユーザーから誤字の報告があり、不具合となった
このように時系列で記載すると、不具合の事象だけでは見えてこない、当時の状況が把握できます。
今回の例でいうと
別の作業中にさしこみで修正作業に対応した
修正後の確認をしていない
システムへの反映後に表示テストを実施していない
が該当します。
時系列を整理すると、不具合がを修正できるチャンスがあったことに気づくことができます。どのタイミングで不具合があり、いつなら気づけるポイントがあったのか。
そのチャンスを把握するためにも時系列の整理は必要です。
3．仕組み化を行う
課題の分解と、時系列の整理をすると「ああ、ここで～～をすれば防げたかもしれない」といった対策が見えてきます。まずはその対策案をリストアップしていきます。
ただし、「自分がダブルチェックする」は使用禁止しましょう。なぜダブルチェックが禁止かは別途解説します。
リストアップの例：
2回目のデータ投入後はチェックツールを経由する
誤字が出ないようにツールでテキスト置換を実行する（手入力をやめる）
未FIX箇所があるかを事前に確認する
マニュアルを整備する
リストアップした後は、それがどのフェーズなのかを分類していきましょう。
フェーズとしては「作業前・作業中・作業後」の3つで良いです。
■作業前
未FIX箇所があるかを事前に確認する
マニュアルを整備する
■作業中
人的ミスが起きないように、ツールでテキスト置換を実行する（手入力をやめる）
■作業後
2回目のデータ投入後はチェックツールを経由する
作業前ばかりに改善策が偏っていたりする場合には、他のフェーズでの防止策が他にないかを考えていきます。
ミスはそれ単体で防ぐのではなく、その前後の工程で「ミスが起きづらくする」「ミスに気づきやすくする」のが大事だと思っています。
補足）なぜダブルチェックがダメなのか？
ダブルチェックは費用対効果が悪いからです。私のプロジェクトでも不具合の再発防止として、「ダブルチェックする」が多くありました。
まるで金言のように扱われていますが、その後も不具合が出ているので、防止効果はあまり期待できません。
各フェーズに細かくダブルチェックを挟むほど工数は増え、ダブルチェック毎の注意力が落ちます。つまり、「あれだけ前工程でダブルチェックしているのだから、大丈夫だろう」という先入観が、毎回のダブルチェックの精度を下げます。これにより、ダブルチェックの作業価値が下がるため、工数のコスパが悪いのです。
ゲーム業界は週刊誌の連載のようなもので、締め切りまでにどれだけ高められるか時間との勝負です。何度もダブルチェックをかさねた結果、リリースできなくなっては本末転倒。時間という限られた資源をわずかでも無駄にしないことが大事です。したがって、時間効率の悪い「ダブルチェック」は悪手として避けましょう。
4．担当者へのフォローを徹底する
ここまでのフローで再発防止を徹底することができました。しかし、再発防止ができるだけでなく、メンバーのフォローができてこそ「マネジメント」だと思います。
フォローと行っても「気にするな」と声をかけたり、仕事帰りに一緒に飲みに行ったり…というものではないです。
それは心の傷に向けたフォローで、問題の解決とは別軸の話です。
具体的には「他責で問題を見せる」ことが大切です。
前述した「１」の作業タイミングで、不具合の担当者を同席させることをお話しました。これは担当者にしか気付けない課題を拾うことに意義があります。担当者へヒアリングを行い、現場目線での課題や対策をお互いに確認しましょう。
ただし、その場で「なんでこんなミスをしたんだ」「どうしてミスしたんだ」と問い詰めるようなことは絶対に避けてください。本当にそこに原因があるかはさておいて、当人が「私が悪いです、反省します」と個人責として処理してしまい、問題の根本解決に光が当たらなくなる方が問題です。
あくまでもミスをした担当者が「他責である」と感じられるようにコミュニケーションをしましょう。ポイントとしては「自分じゃなくても起きていた」と感じさせることです。
具体的には、
「話を聞いてみたんだけど、これはマニュアルが悪いね…」
「これはフローの〇〇に問題がありそう」
など。
他責であることをお互いに認識できれば、むしろ客観的で俯瞰した対策ができます。感情や罪悪感、根性論といったノイズを排除し、具体的で徹底した対策が必要です。そのためにも「他責ベース」で話しましょう。
5．まとめ
この記事では不具合の防止や対策についてまとめました。
多くの記事や本ではPDCAサイクルや独自の方法論が紹介されていますが、手法やフォーマットに即した対策であっても、原因の分解や対策が不十分では「やった気になる」で終わります。
問題を極限まで分解
時系列を整理
再発防止の仕組み化
上記3点を意識することで、個人の個性に左右されない徹底した不具合防止ができます。
特に不具合は対策から実行までのスピードが大事です。防止策を講じる前に次の不具合が出てしまったり、フォーマットにまとめる時間がかかっては意味がありません。
短くすぐに振り返りができて、即対応ができるものを洗い出す。
これにより現場に即した不具合防止ができていくと考えます。
最後までお目通しいただきありがとうございます。同じような状況で課題を感じている方に、少しでもお役立ていただければ幸いです。
執筆者プロフィール：立野 健人
2020年SHIFT入社。入社前はコンシューマータイトルのデバッグからプランナーへ転向。アプリゲームの開発から運営を経験し、現在はソーシャルゲームの運営サポートに従事。
お問合せはお気軽に
https://service.shiftinc.jp/contact/
SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/
SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/
SHIFTの導入事例
https://service.shiftinc.jp/case/
お役立ち資料はこちら
https://service.shiftinc.jp/resources/
SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/
PHOTO：UnsplashのMaxim Tajer