不具合やバグを伝えるときに役に立つ! 『報告・連絡・相談』(ホウレンソウ)の極意

最終更新日時:2022.03.14 (公開日:2022.01.19)
不具合やバグを伝えるときに役に立つ! 『報告・連絡・相談』(ホウレンソウ)の極意

発見した不具合やバグ、あるいは仕様の要望やリクエストを、開発エンジニアや関連部署、社外の開発先などに報告するとき、正確にポイントを伝えられずに改善に繋げられず、問題解決までに想定以上に時間がかかってしまうことがあります。ユーザー側だけでなく、レビューを頼まれたりQAに関わったりするエンジニアであっても、不具合報告に戸惑うことがあると言われています。そこで今回は、効率良く、気持ち良くホウレンソウ(報告・連絡・相談)するためのポイントをまとめました。

もくじ

不具合報告をする【前】に確認しておきたいこと

押さえておくべき3つのポイント+α

ITシステムやソフトウェアを操作していて不具合が発生したとき、まず気を付けたいことは「冷静になる」ことです。ソフトウェアが意図しない動作をしたとき、画面フリーズなどのバグがあったときは、まず深呼吸して気持ちを落ち着けましょう。冷静な報告が問題解決までの時間を短縮してくれます。

不具合報告で伝えるべきポイントを先にお伝えしてしまうと「何が起きたか」「再現させる手順」「どんな動作を期待(意図)していたか」の3つです。

良い不具合報告は、エンジニアの素早い問題発見の糸口になります。一見すると複雑そうな事象でも、原因が分かってしまうと意外と簡単なケースが多いのです。そのために必要とされるのが的確な報告ということになります。また、丁寧な口調で相手を尊重・リスペクトして円滑なコミュニケーションを心がけるようにしましょう。これも重要なポイントです。

1. 「簡潔」に記すことを心がける

明快かつ簡潔に、エンジニアに伝わるように書くことが何より大切です。美文麗文を意識する必要はありません。むしろ無駄な形容表現は避けた方が良いことが多いようです。「~した」「~した」「~だった」と淡々と記しても構いません。場合によっては箇条書きの方が好ましいこともあります。美しい文章よりも"伝わる報告"が求められる場面ですから、力まずに淡々と記すのが良いでしょう。

2. 「独自用語」「方言表現」「部署ローカル語」を使わずに記す

自分だけ、または部署内だけで通用する「独自用語」「独自専門用語」を使わないよう心がけましょう。当然ですが、独自の表現は他人や部署外の人に伝わりません。提出前に一回通読して、独自の表現を使っていないか確認するようにしましょう。しかしこれが、予想外にハードルが高いことがあります。ふだんから独自表現を使わないようにするのが一番の対策になるようです。

3. 機能の名前、画面表示の言葉はそのまま使う

独自用語を避けるのと似ていますが、ソフトウェアの機能などの名前や画面に表示されている言葉(キーワード・メッセージ)はそのまま使います。言葉を換えたり、読み違いをしたりすると誤解の元になることがあるので注意してください。例えば「インストール(Install)」を「インスツール」「インスタール」、「gif(ジフ:Graphics Interchange Format)」を「ギフ」と表現してしまう場合などがあります。問題にならないことが多いですが、まれに確認に手間取ることがあります。分からないときは、できるだけ元の英文字表示などを使うと誤解が発生する可能性を減らすことができます。

+α. 問題への「独自見解」をできるだけ述べない

発生した問題の原因を推測して記すことはお勧めできません。そもそも解決できないから報告している状況のため、独自の見解(推測)は誤りの可能性もあり、ミスリードとなってしまって原因究明の妨げになってしまうことがあります。報告文を「推理クイズ」にしないのがポイントです。どうしても伝えたい場合は、推測であることを明確にするようにしましょう。

不具合を【報告】するときのポイント

その問題は再現するか?

ただ「画面がおかしい」「動作が変」「ネットに繋がらない」「フリーズした」という報告だけでは、どんな問題が発生しているのか、現象に遭遇した本人しか理解できません。このような場合、報告を受ける側は「この報告は何か」を理解するところからスタートしなければならないため、報告者も報告を受ける側もただ時間を浪費するだけになってしまいます。そんな事態を避けるため、その問題が再現するのか、事故なのか、報告前に材料を集めるようにしましょう。

可能なら問題の発生した画面をスクリーンショットしたりスマートフォンのカメラで撮ったりしてから、発生した問題が再現するかを確認しましょう。同じような操作をして問題が発生するようであればメモしておくようにし、問題が再現してメッセージ等が表示される場合は画面を保存しておきましょう。

ヘルプやFAQを確認してみる

すでに公開中のバージョンの場合、発生した問題はそのまま不具合である可能性が高いのですが、開発中バージョンの場合、もし開発チームがその問題を把握している場合、詳細な報告が不要となることがあります。

自分が直面している不具合が、ヘルプ、FAQ、開発メモ、更新情報等のドキュメントに記載されていないか、念のため確認します。すでに把握されているケースを報告するために多くの時間を割いてしまうのはもったいない話です。また、不具合だと感じられた動作が何らかの事情によって仕様となっていることがあります。このような点をドキュメント類で確認してみます。

(1)報告すること:状況・現象

上記の確認をして、不具合だと考えられる場合は報告します。どのような不具合が発生したか、具体的かつ詳細に記します。一例ですが「入力画面がクラッシュする」ではなく、「入力画面で文字を入力するとブラウザがクラッシュする」といった書き方になります。また、分かる範囲で問題が発生した環境も報告します。

  • 不具合が発生したソフトウェアのバージョン情報
  • 発生環境(OS、OSのバージョン、使用しているパソコン等)の情報
  • 画面に表示されているエラーメッセージ等の情報(上で保存したもの)
  • その他、追記事項など

(2)報告すること:再現手順

不具合が発生した手順をできるだけ詳しく記します。長い文章で記すよりも箇条書きの方が適していることが多いようです。
例えば、

  1. サービスにログインをして
  2. 入力画面に文字を入力したら
  3. 画面にメッセージが表示されて
  4. ブラウザが反応しなくなった

といったように途中で文が途切れる方法でも構わないので、発生手順を番号付きの箇条書きで記します。

報告を受けたエンジニアが番号順に操作をして問題を再現できるのが理想です。報告の中核となる部分です。付け加える説明として、上の操作をすると100%再現するか、何回に1回といった形で発生しているかといった情報を加えておくと良いでしょう。

ポイントとなるのは画面に表示されるメッセージなどの情報です。可能ならスクリーンキャプチャやスマホカメラで撮影した画面写真など添えておくと説明が伝わりやすくなります。アプリケーションやシステムのログが提出できる場合はこれも添えましょう。

(3)報告すること:期待した動作

報告している操作をして、どのような結果を期待していたかを伝えます。「期待した動作」つまり、報告者の操作の意図が何であったかは重要な情報となります。報告を受けたエンジニアは、なぜ報告者が該当する動作を不具合と感じたのかが理解でき、報告の全体像を把握する助けになりますし、解決策を考えやすくなります。

不具合を【連絡】する際の注意点

報告先が「どこ」の「誰」かを意識する

不具合の報告先が、「社内」か「社外」か「コミュニティ内」か「チーム内」か等で報告の言葉遣いや提出方法、連絡方法が異なってきます。「誰(報告者)」が「どこ(ポジション)」の「誰(被報告者)」に提出するかを意識して、TPOに合わせて円滑なコミュニケーションを心がけましょう。

最近では、不具合の報告がチケットシステムやチャットシステム等を用いて運用されているケースも多く、システムがあるにも関わらずメールや電話で報告すると対応がイレギュラーになり、全体の進行の妨げになってしまいます。適切な方法を選択して報告するようにしてください。分からないときは、はじめに「どこに報告したら良いか」を聞くのも良いかもしれません。

要望を伝えたり【相談】したりするときは?

要望のポイントは不具合の報告に似ている

要望を伝えたり、機能をリクエストしたりするときの基本は不具合の報告に似ています。異なるのは「現在の動作」と「期待する(要望する)動作」と「メリット」を伝える点です。不具合報告の場合は起きている事実をありのままに伝えるのがポイントですが、リクエストの場合は今の動作を変化させると新たにどんなメリットがあるかにフォーカスします。

「どの時点」の「どの動作」を「どうしてほしいか」を明確に

リクエストしたい動作までの手順をエンジニアが再現できるように記します。番号付きの箇条書きが適していることが多いようです。
例えば、現在、

  1. サービスにログインをして
  2. 入力画面に文字を入力したら
  3. 画面にメッセージが表示されて
  4. 結果Aが得られる

というケースの場合、この「3.」をこう変えてほしいとか、「4.」を異なる結果Bにしてほしいというように記していきます。無理やり文章で書く必要はなく、「伝わるように、分かりやすく報告する」方が良いようです。また、感情的な表現は避けましょう。円滑なコミュニケーションが大切です。

要望・リクエストにどんなメリットがあるかを記す

要望・リクエストを実現すると誰にどんなメリットがあるか、またはどのようなリスク、マイナスを回避できるかを必ず記します。これは非常に重要なポイントです。早期の対応が望まれる不具合のケースと異なり、要望・リクエストの場合はほとんどのケースで採用可否の検討が行われます。この際、得られるメリットが分からないと個人の好みと判定されて不採用になることがあるからです。

これまでにない機能などをリクエストする場合、とくにメリットが明確でないとスルーされてしまうことが多いようです。メリットを記すときは慎重に分かりやすく具体的に記すと良いでしょう。

報告を発信・受信する【体制】を作っておく

報告・要望用のテンプレートをあらかじめ用意しておく

自分たちの開発スタイルに合った報告、要望用のテンプレートをあらかじめ用意しておくと、これまでのポイントを抑えた発信がしやすくなります。「不具合 報告 テンプレート」「要望 テンプレート」などで検索すると数多くの事例を見ることができ、配布サイトなども見つかります。

テンプレートを用意するポイントは【連絡】の注意点と重なります。「誰(報告者)」が「どこ(ポジション)」の「誰(被報告者)」に提出するかを考え、検討することが大切になります。

報告・要望用のツールを整えておく

報告・要望を受け付ける窓口が一本化されていると効率は良くなります。以前はメールが主でしたが、最近ではBacklogやslack、Chatworkなどコミュニケーションツールが発達してきているので、報告に用いるツールやルールを事前に定めておく方が良いようです。実際には用意されているほとんどのケースで用意されているので、適切なツールやルール、報告フローになっているか整理することになるでしょう。社外、部署外から受け付ける場合は、報告用の投稿フォームなどを用意しておくと効率が良いことがあります。自チームのスタイルに合った方法を選択するのが良いようです。

まとめ

不具合・バグ報告や要望・リクエストは、人と人とのコミュニケーションに他なりません。本文中でも何度か述べましたが、まず円滑なコミュニケーションを意識することが第一のポイントかもしれません。

執筆者:神田 富士晴

ライター

株式会社アスキー、株式会社光栄、株式会社ビレッジセンター等で書籍・ムック・雑誌の企画・編集、ソフトウエア制作を経験。その後、企業公式サイト運営やコンテンツ制作に10年ほど関わる。現在はライター・マンガ原作者として記事の企画・取材・執筆に取り組んでいる。