見出し画像

不具合報告の仕方をひと工夫してモノ作りを加速しよう！

tamachang

非エンジニアからPMになった自分の立場からお伝えできる事、きっと役に立つであろう事を実体験をベースに発信しています。

今回の内容はPM、PdMだけでなく、プロダクトオーナー、開発の発注を依頼する側の方にもご理解いただけるとメリットがありますので、ぜひご一読ください。


今回のテーマ

開発したアプリケーションやシステムの動作テスト、または発注者側での検収中にて不具合や期待と異なる挙動を見つけた時に、エンジニアに対してどういう情報量で報告するとスムーズか？をご紹介します。

特段変わった事をする訳ではなく、開発経験がある方であれば普通にやっている事かもしれませんが、、

プロジェクト進行上の、ムダを削ぎ落とし、メンバーが気持ちよく・テンポ良く仕事をするためにはモノ作りを加速させるために大事な要素だと個人的に思っているのと、この辺りがうまく回ると結果的にプロダクトの品質向上に繋がります。

最後にその部分についても触れます。

結論から説明しますと…

以下の項目を記入してチケットを作成します！

不具合チケット報告のテンプレート

なぜ上記の項目が必要なのか？この辺りを掘り下げて説明していきます。

修正作業に取り掛かるまでに必要な作業

エンジニアが不具合がある事を把握してから、修正をするまでにはおおまかにこんな流れで作業を進めます。

  1. 自身の環境で報告にある事象が発生するか再現チェックする

  2. 再現したら、再現したタイミングでのアプリ内部のログやアプリ内で処理しているデータを確認する

  3. エラーに至る原因にあたりをつけて、プログラムやデータを修正し、改善されるか確認する

  4. 修正を反映し、不具合報告者に修正確認依頼をする

ご覧の通り、再現させるところがスタート地点となります。

報告例

悪い例

口頭だけで報告する
いますぐに修正に取り掛かれるとは限らないので、口頭では相手が正確にメモでもしていない限りタスクから漏れる可能性が高くなります。

エンジニアがいざ修正に取り掛かれるタイミングになった時に備えて、チケット化しておきましょう。

不具合の発生時の状況について情報量が少ない
一つ前のブロックで触れましたが、エンジニアがすぐ再現できる状況を作っておく事で無駄な時間を削減できます。

エラーが出る事実だけ伝えても、それだけしか情報が無いと該当のエラーが出るパターンを確認する作業にひたすら時間が掛かってしまうかもしれません。

不具合報告者はその不具合の発生状況を最も詳しく理解しているので、再現手順や自身がテストしている環境について読みやすく整理してチケットに記載しましょう。

特に悪いケースとしては、以下を行ったりきたりして時間が過ぎていくことです。

エンジニアから報告者に不具合発生時の状況を質問する
↑↓
報告者から質問に答える

同じ手順を踏んだとしても、再現しないというケースもありえますが、特定の操作や特定のアカウント利用中に起こる事象であれば調査するスコープを絞ることにも役立ちます。

少ない情報で修正依頼をかけたとしても結局質問がきて答えるというやりとりが発生してしまうので、最初の報告の時点でクリアにしていけると良いですね。

修正後にどういう状態になるのが正解なのかが不明
不具合内容や思っていた挙動と異なることだけ伝えても、原因特定して修正しようとしたタイミングで「どう直すのが期待値ですか？」と質問があがります。

この質問やりとりも時間のロスになるため、チケット作成時に期待する結果についても記載しておきましょう。

良い例

冒頭でも挙げましたが以下の項目が揃っているのが望ましいです。

チケットのタイトル
発生した事象について一文で完結にタイトルを付ける

再現手順
どういうステップで操作をしたら事象が発生したかの手順を言語化する

発生率
事象が100%起こるのか、10回手順を踏んで1回だけ起こるのか頻度を記載する

スクリーンショット
画面の表示が崩れる、また異常なデータ表示される、など見た目的な指摘であれば該当の画面のスクリーンショットを貼る

期待する挙動
どういう状態なれば解決できるかを記載する

発生環境
■ スマホアプリの場合は以下を記載
・使用しているデバイスの機種名、OSバージョン
・テスト時に使用したアプリの環境とバージョン　※1

■ Webアプリの場合は以下を記載
・使用しているPCのOSバージョン、ブラウザの種類とバージョン
・テスト時に使用したアプリの環境　※1

※1
アプリの環境が開発環境、ステージング環境、商用環境などいくつか存在するプロジェクトの場合はどの環境で発生したかを記載する

補足
上記では表していない情報があれば記載する
（複数のログインアカウントのうち、特定のアカウントを使っている場合にだけ事象が発生する事実があればそういった事を記載するなど）

情報が多いことに越したことはないですが、項目が多すぎると腰が重くなり書かなくなってしまったりしますし、どう書けば良いかわからないという方は上記を参考にして頂ければと思います。

テスト担当者とのコミュケーション

テスト作業に他者をアサインしている場合、一緒に仕事した実績が豊富で報告の粒度に定評があればお任せして問題ないですが、いざテストがスタートしチケットを量産してもらった後に書き方を直してもらうのは大変です。

特に理由がなければ、テストがスタートする前にチケットのフォーマットを決めてテスト担当者と意識合わせしておきましょう！

PO、発注者する方へのメリット

一見、エンジニアの負担を減らすための内容に見えるかもしれませんが、決してそうではありません。

こんな事はありませんか？

  • リリースまでに出来るだけユーザーからの改善要望を取り込みたい

  • アップデートに盛り込みたい機能がスケジュール的に少しハマらない

プログラム作業としてはエンジニアでしか対応ができませんので、エンジニアには出来るだけ設計・実装・チューニングに集中してもらえる状態を作る事で上記の事に対応していける可能性が出てきます。

回あげた様な情報整理など、プロジェクトに関わる人たちが適材適所で運用をしていく事もその状態を作るための要素となります。

まとめ

今回はテスト工程にフォーカスをして、不具合チケットへの必要情報整理の仕方についてご紹介しました。

新しく作成したチケットだけでなく、既にあるチケットに対して修正を反映したバージョンに対して確認結果をコメントする時にも、「OK」「NG」かだけ書いても情報不足になるので可能な範囲で情報を記入する意識ができるとスムーズです。

ご自身の中に運用の型が無い場合は、まずはこちらを参考に自分なりにやってみた感触を踏まえてカスタマイズして頂くのも良いと思います！

〜クリエイションで世界の「面白い」を増やす〜
株式会社Futurizeはプロダクト開発スタジオです。
Web2系のサービス開発から、「ブロックチェーン」や「AI」を用いた開発に取り組んでいます。

一緒に働く仲間も順次募集しているため、ご興味あればXアカウント（@tamametal666）や弊社HPまでお気軽にご連絡ください！

HP：https://futurize.jp/