2024.01.18
業務を行う上で重要なのが、「ホウレンソウ（報告・連絡・相談）」。
ソフトウェア開発においては、不具合を発見したとき、あるいは仕様の要望やリクエストがあったとき、関連部署、社外の開発先へ正確に伝えることが重要です。なぜなら正確にポイントを伝えられないと改善に繋げられず、問題解決までに想定以上に時間がかかってしまうからです。
ただし、相手に正確に要望や報告を伝えることは簡単ではありません。実際に、レビューを頼まれたりQAに関わったりするエンジニアであっても、不具合報告をもらった際に戸惑うことがあると言われています。
そこで今回は、効率良く、気持ち良く不具合をホウレンソウ（報告・連絡・相談）するためのポイントをまとめました。相手と認識を合わせて、円滑に作業を進めるためにぜひお役立てください。
- もくじ
1．報告・連絡・相談(ホウレンソウ)で心がける4つのポイント
報告・連絡・相談(ホウレンソウ)を行う際に気を付けてほしいポイントが４つあります。
- 簡潔に分かりやすく記す
- 慌てず冷静に伝える
- 「独自用語」「方言表現」「部署ローカル語」を使わずに記す
- 機能の名前、画面表示の言葉はそのまま使う
これら４点を前提として理解しておきましょう。
① 簡潔に分かりやすく記す
簡潔に分かりやすく、相手に伝わるように書くことが何より大切です。
「～した」「～した」「～だった」と淡々と事実を記していきましょう。 (場合によっては箇条書きの方が好ましいこともあります。)
美文麗文を意識する必要はありません。むしろ無駄な形容表現は避けた方がよいです。美しい文章よりも"伝わる報告"が求められるので、力まずに淡々と記していきましょう。
② 慌てず冷静に伝える
不具合が発生したとき、まず意識してほしいのが「冷静になる」ことです。
ソフトウェアが意図しない動作をしたときや、画面フリーズなどのバグがあったときは、まず深呼吸して気持ちを落ち着けましょう。冷静な報告が問題解決までの時間を短縮してくれます。
③ 「独自用語」「方言表現」「部署ローカル語」を使わずに記す
自分や部署内だけで通用する「独自用語」「独自専門用語」を使わないよう心がけましょう。当然ですが、独自の表現は他人や部署外の人に伝わりません。提出前に一回通読して、独自の表現を使っていないか確認することが重要です。
一見当たり前に感じることですが、予想外にハードルが高いことがあります。ふだんから独自表現を使わないようにするのが一番の対策になります。
④ 機能の名前、画面表示の言葉はそのまま使う
独自用語を避けるのと似ていますが、ソフトウェアの機能などの名前や画面に表示されている言葉（キーワード・メッセージ）はそのまま使いましょう。言葉を換えたり、読み違いをしたりすると誤解の元になることがあるので注意してください。
例えば「インストール（Install）」を「インスツール」「インスタール」、「gif（ジフ：Graphics Interchange Format）」を「ギフ」と表現してしまう場合などがあります。問題にならないことが多いですが、まれに確認に手間取ることがあります。分からないときは、できるだけ元の英文字表示などを使うと誤解が発生する可能性を減らすことができます。
+α. 問題への「独自見解」をできるだけ述べない
発生した問題の原因を推測して記すことはお勧めできません。
そもそも解決できないから報告している状況なので、独自の見解（推測）はミスリードとなって原因究明の妨げになることがあります。どうしても伝えたい場合は、推測であることを明確にするようにしましょう。報告文を「推理クイズ」にしないのがポイントです。
2．不具合の発見から【報告】するまでの流れ
実際に不具合を発見したとき、慌ててすぐに報告をしようとすると、うまく伝わらなかったり余計な時間がかかってしまったりすることがあります。
冷静に正確な報告をするために、不具合を発見してから報告するまでの流れを解説します。
(事前に)再現性とヘルプ・FAQを確認する
不具合を発見したら報告前に以下の2点を確認しましょう。
- 再現性
- ヘルプ・FAQ
それぞれ詳しく解説します。
再現性
ただ「画面がおかしい」「動作が変」「ネットに繋がらない」「フリーズした」という報告だけでは、どんな問題が発生しているのか、現象に遭遇した本人しか理解できません。
そのため報告を受けた側は「どんな状況か」を理解するところからスタートしなければならず、時間がかかってしまいます。無駄な時間を削るためにも、その問題が再現するのか、事故なのか、報告前に材料を集めるようにしましょう。
可能なら問題の発生した画面をスクリーンショットしたりスマートフォンのカメラで撮ったりしてから、発生した問題が再現するかを確認しましょう。同じような操作をして問題が発生するようであればメモしておくようにし、問題が再現してメッセージ等が表示される場合は画面を保存しておきましょう。
ヘルプ・FAQ
自分が直面している不具合が、ヘルプ、FAQ、開発メモ、更新情報等のドキュメントに記載されていないか、事前に確認しましょう。すでに把握されている不具合だった場合、報告するために多くの時間を割くのはもったいないからです。
また、不具合だと感じられた動作が何らかの事情によってその仕様になっていることもあります。事前にドキュメント類を確認し報告が必要か判断していきましょう。
状況・手順・期待した動作を報告する
再現性やヘルプ・FAQを確認した上で報告すべき不具合と判断したら、実際に関係者へ報告していきます。
伝えるべきことは（1）状況・現象、（2）再現手順、（3）期待した動作です。
（1）状況・現象
まずどのような不具合が発生したかの状況・現象を、具体的かつ詳細に記します。一例ですが「入力画面がクラッシュする」という現象が起きた場合、「入力画面で文字を入力するとブラウザがクラッシュする」といった書き方をするとより具体的で伝わりやすくなります。
また、分かる範囲で問題が発生した環境も報告します。
- 不具合が発生したソフトウェアのバージョン情報
- 発生環境（OS、OSのバージョン、使用しているパソコン等）の情報
- 画面に表示されているエラーメッセージ等の情報（上で保存したもの）
- その他、追記事項など
（2）再現手順
不具合が発生した手順をできるだけ詳しく記します。長い文章で記すよりも箇条書きの方が適していることが多いようです。
例えば、
- サービスにログインをして
- 入力画面に文字を入力したら
- 画面にメッセージが表示されて
- ブラウザが反応しなくなった
といったように途中で文が途切れる方法でも構わないので、発生手順を番号付きの箇条書きで記します。
報告を受けたエンジニアが番号順に操作をして問題を再現できるのが理想です。報告の中核となる部分です。付け加える説明として、上の操作をすると100%再現するか、何回に1回といった形で発生しているかといった情報を加えておくと良いでしょう。
ポイントとなるのは画面に表示されるメッセージなどの情報です。可能ならスクリーンキャプチャやスマホカメラで撮影した画面写真など添えておくと説明が伝わりやすくなります。アプリケーションやシステムのログが提出できる場合はこれも添えましょう。
（3）期待した動作
報告している操作をして、どのような結果を期待していたかを伝えます。「期待した動作」つまり、報告者の操作の意図が何であったかは重要な情報となります。報告を受けたエンジニアは、なぜ該当する動作を不具合と感じたのかが理解でき、全体像を把握する助けになり、解決策を考えやすくなります。
3．報告先が「どこの誰か」を意識して【連絡】する
不具合の報告先が、「どこの誰に」なるのか認識した上で連絡を行いましょう。例えば、報告相手が「社内」か「社外」か「コミュニティ内」か「チーム内」か等で報告の言葉遣いや提出方法・連絡方法が異なってきます。
最近では、不具合の報告がチケットシステムやチャットシステム等を用いて運用されているケースも多いので、メールや電話で報告すると対応がイレギュラーになり、全体の進行の妨げになってしまうこともあります。そのため、適切な方法を選択して報告するようにしましょう。分からないときは、はじめに「どこに報告したら良いか」を聞くのも良いかもしれません。
報告先が「どこ（ポジション）」の「誰（被報告者）」になるのかを意識して、TPOに合わせて円滑なコミュニケーションを心がけましょう。
4．要望を【相談】する際のポイント
要望を伝えたり、機能をリクエストしたりするときの基本は不具合の報告に似ています。
異なるのは「現在の動作・期待する（要望する）動作」と「メリット」を伝える点です。不具合報告の場合は起きている事実をありのままに伝えるのがポイントですが、リクエストの場合は今の動作を変化させると新たにどんなメリットがあるかにフォーカスして相談をしていきましょう。
「どの時点のどの動作をどうしてほしいか」を明確にする
リクエストしたい動作までの手順をエンジニアが再現できるように記します。番号付きの箇条書きが適していることが多いようです。
例えば、以下のようなケースの場合、
- サービスにログインをして
- 入力画面に文字を入力したら
- 画面にメッセージが表示されて
- 結果Aが得られる
この「3.」をこう変えてほしい、「4.」を異なる結果Bにしてほしいというように記していきます。無理やり文章で書く必要はなく、「伝わるように、分かりやすく報告する」ことを心がけましょう。また、感情的な表現は避けることも意識してください。円滑なコミュニケーションが大切です。
要望に応えることでどんなメリットがあるかを記す
要望・リクエストを実現すると誰にどんなメリットがあるか、またはどのようなリスク、マイナスを回避できるかを必ず記載しましょう。要望・リクエストはほとんどの場合、採用可否の検討が行われます。得られるメリットが分からないと個人の好みと判定されて不採用になることもあるので、とても重要なポイントです。
また、これまでにない機能などをリクエストする場合、とくにメリットが明確でないとスルーされてしまうことが多いです。メリットを記すときは具体的に分かりやすく記すと良いでしょう。
5．報告を発信・受信する体制を作っておくことも重要
報連相(ホウレンソウ)を円滑に行うためには、体制を整えておくことも重要になります。
あらかじめ準備をして、いざというときにスムーズに行動できるようにしておきましょう。
テンプレートをあらかじめ用意しておく
自分たちの開発スタイルに合った報告、要望用のテンプレートをあらかじめ用意しておくと、これまでのポイントを抑えた発信がしやすくなります。
テンプレートを作成する際は、「誰（報告者）」が「どこ（ポジション）」の「誰（被報告者）」に提出するかを考えながら進めましょう。また「不具合 報告 テンプレート」「要望 テンプレート」などで検索すると数多くの事例を見ることができるので、そちらも参考にしてみてください。
ツールを整えておく
報告・要望を受け付ける窓口が一本化されていると効率は良くなります。以前はメールが主でしたが、最近ではBacklogやslack、Chatworkなどコミュニケーションツールが発達してきています。報告に用いるツールやルールを事前に定めておくとスムーズです。
社外、部署外から受け付ける場合は、報告用の投稿フォームなどを用意しておくと効率が良いでしょう。自チームのスタイルに合った方法を選択することが大切です。
まとめ
スムーズな不具合・バグ報告や要望・リクエストは、人と人との円滑なコミュニケーションに他なりません。
報連相(ホウレンソウ)をする際は以下の点を気を付けましょう。
- 簡潔に分かりやすく記す
- 慌てず冷静に伝える
- 「独自用語」「方言表現」「部署ローカル語」を使わずに記す
- 機能の名前、画面表示の言葉はそのまま使う
また、報告を発信・受信する体制を作っておくことも重要です。
報告用のテンプレート作成や、報告用ツールのルール化等、事前に決めて誰でも円滑に報連相(ホウレンソウ)ができる体制を整えていきましょう。
