近年、様々な製品やサービスにおいてソフトウェアは欠かせない位置付けとなってきた。そのソフトウェアにおいて不具合が発生すると、顧客や市場に迷惑をかけ、信頼を損ねてしまう。
ソフトウェア不具合報告をする側の心得は「簡潔に」「誠実に」「迅速に」「深い分析」「再発防止」などとよく言われるのだが、受ける際の心得についてあまり語られることがない。
ここではお互いWin-Winとなるために、ソフトウェア不具合報告を受ける側の心得についてお伝えしたいと思う。
はじめに
システム開発企業の部門の責任者は、ソフトウェア不具合に対して、早期の回復、関係者への説明など、迅速で真摯な対応が求められる。中でも、ソフトウェア不具合報告に関しては、「事実関係を、簡潔に、適切に」などと報告する側へ求める指導内容はよく見受けられる。これは一部正しい。
しかし、現実のところ報告する側も報告以外の不具合対応で疲弊している人間にとっては、綺麗事や根性論でしかない。ここに厳しい指摘でも不具合発生部門にとってプラスになることならまだしも、単なる感情をぶつけるだけ、現場で頑張っている人達の苦労も汲み取れず、説明者や不具合発生部門を不快にさせる迷惑で残念な人というのも一定割合いる。
この記事では、ソフトウェア不具合報告を受ける側として心得るべきこと、私が気をつけていることを書いている。不具合報告を部下から上司へ行う場合、ソフトウェア開発企業から取引先へ行う場合、色々あるが共通して言えることは、「人間対人間」だ。これをよくわかっている企業と、そうでない企業で、大きく分かれるのではないかと思っている。
1.二律背反（ダブルバインド）にならないように配慮する
ソフトウェア不具合報告を含めて、「報告は簡潔」にと一般的には言われている。
簡潔に報告すると、「分析が浅い」とか言う人もいる。
細かく報告すると、「よくわからないから簡潔に」と言う。
どちらか一方を選択すれば、他方の理由で否定される。このような状況を二律背反（ダブルバインド）という。
｢なぜミスをしてしまったか説明して｣と言われて説明しようとすると、｢言い訳しない｣などと言われたりするのも、二律背反である。
二律背反によって当事者や報告者を、戸惑わせてはいけない。相手側を追い込むパワハラとなる手段に変貌するリスクがある。
2.ソフトウェア開発は簡単ではないことを理解する
多くのソフトウェア不具合は、簡潔に報告できるほど、単純ではない。「簡潔に報告」すると、「内容が簡単」なものであると勘違いする人がいる。
「詳細な報告を受けても内容の把握が追い付かない。」というのはその通りだろう。そのような人には「簡潔に報告」することが必要である。
問題はその先である。「簡潔に報告」されたからといって「内容が簡単」だと考えてはいけない。報告資料は、説明のために簡単に記載されていることがほとんどである。
「簡潔に報告」されても、そのさらに裏があるのではないかと想定しておくべきであるし、実際に私はそのようにしている。
o08usyu7231.hatenablog.com
3.ハラスメントを禁止する
ソフトウェア不具合を出すと市場やお客様、関連部門に迷惑がかかる。迷惑を受けた側が、何をやっても良いかというとそれは違う。
「顧客のほうが立場が上だ。」と未だに勘違いしている人がいるが、優越的な関係を背景にしてはいけないし、「不具合を出した」ことの弱みや不利な状況に漬け込み、パワハラ等の悪質行為な及ぶのはもってのほかである。もちろん「不具合を出した」企業や部門は迅速に、真摯に、誠実に対応を進めなければならないことは前提である。
o08usyu7231.hatenablog.com
不具合報告から話が逸れるが、ペナルティで業務を増やすのもいかがなものかと思う。顧客からソフトウェア不具合発生企業へ、ソフトウェアのチェックリストを渡して
「これに沿って検証せよ！」
という依頼をする事例があったが、ソフトウェア品質検証のために本当に必要なことであれば問題ない。
しかし、ただでさえ業務負荷が高く疲弊している人に対して、ペナルティや嫌がらせのような意味合いで行うことがあれば、かえって逆効果だ。負荷が増え、更に疲弊し、更にミスが増えるリスクを意識しておくべきである。人間としてあるべき姿が問われている。また、「過大な要求」はパワハラ行為にもあたり、パワハラ６類型の１つである。
話を戻そう。責めても何も良いことはない。建設的な意見や協力が必要だ。他社の不具合事例から何か学ぶことすらあるだろう。
4.労働環境に配慮する
ソフトウェア不具合に対しては、技術、プロセスに関する原因を分析した上で、再発防止が必要である。
再発防止というと、技術やプロセスについてのものがほとんどであるが、労働環境に関する原因、再発防止も忘れてはならない。
- スケジュールに余裕があったか？
- 作業者の負担に配慮したか？
- 十分なコンディションで業務にあたったか？
労働環境のことを語り出すと
- 「言い訳」
- 「甘い」
- 「なめるな」
などと、パワハラ発言をする人間が一定割合いる。
ソフトウェア不具合発生の部分が、最もクローズアップされ、吊し上げられるのだが、本質の問題は更に前段にあり、その結果ソフトウェア不具合発生に至るケースが多い。ソフトウェア不具合が発生したという、目に見える『点』だけを吊るし上げ「ソフトウェア開発をしている人間は、もっとしっかりせえよ！」等と言い放ったところで、何の解決にも改善にもならないのである。『点』ではなく『前段』すべてに着目すべきなのである。
現実、余裕のないスケジュールや心理面から、長時間労働やパワハラ等劣悪な労働環境の結果、疲弊し、ミスが増え、不十分な検証の結果、不具合発生となって表面化した可能性を考慮できていないことが少なからずある。ソフトウェアエンジニアに圧力をかけるのではなく、状況を理解し、いたわり、ステークホルダ全体で改善する、このような高い視座が（ソフトウェア以外の部門も含めて）管理職に求められる。
o08usyu7231.hatenablog.com
o08usyu7231.hatenablog.com
ソフトウェア不具合再発防止に労務面のことを述べると、一時的に揉めたが、結果としては正しいことを証明した事例がある。
o08usyu7231.hatenablog.com
ミスが許されない業務については、心身ともに健康な状態を維持できる良い労働環境の提供は絶対である。ソフトウェア開発に限った話ではない。例えば、医療現場はその筆頭と言える。
o08usyu7231.hatenablog.com
まとめ
ソフトウェア不具合を発生・流出させた企業や部門は、迅速に、真摯に、誠実に対応を進めなければならないことは言うまでもない。もちろん、発生・流出させてはいけない。発生・流出させてしまった場合でも、事実をわかりやすく説明し、再発防止の検討等、するべきことは多くある。
一方、ソフトウェア不具合報告を受ける側は横柄な態度をとりがちだ。そのようなことがあってはいけない。立場は色々あるが共通して言えることは、「人間対人間」だ。
ソフトウェア不具合を許容せよと言っているわけではないが、ソフトウェア開発は簡単ではないことを知っておくべきである。これをよくわかっている企業と、そうでない企業で、大きく分かれるのではないかと思っている。あとは、労働環境や労務トラブルの観点も入れ、ステークホルダ全体で改善することだ。
o08usyu7231.hatenablog.com
