こんにちは、辻村です。今回は、エラーメッセージとかエラーについて、ちょっと変わったお願いをされた件について書いてみたいと思います。私の視野が狭いのだと思うのですが、依頼の理由がさっぱりわからないので、もしご存知の方はコメントでもツイッターでもそっと教えてください。バグを登録するときにどうすれば説得しやすいかについても最後に触れます。

エラーメッセージを変えないでと言うお願い

サポートの仕事をしていたころ、「エラーメッセージを読んでないでしょ?」という問い合わせは数多くいただきましたが、不思議な依頼を受けたことがあります｡いわく「バージョンが変わったときにメッセージが変わったので、元に戻して欲しい」という依頼でした。

訴えとしては「エラーメッセージを見て次にどうするかプログラムで決めていたのでメッセージを変えられると動かない」という話なのですが、私は単純なので「え、そういうコードが書けたのだったら、動くように修正できますよね?」と思ってしまうのです。

世の中には、「予算」という厄介な都合があるのは理解しているので、多少の事情は理解できるのですが、バグを登録していただいても元に戻してもらえる確率は低い気がします。

今回は、2つどんなケースを経験したかというお話しして、なぜエラーは変わるのかというお話を少ししたいと思います。そして最後に変更をうまく通すコツみたいなものをお話しします。

ケース1：　異常終了したコマンドの返り値

一つの目のケースは、あるハードウェアをを操作するコマンドの場合です。

例えば、ある処理がエラーになった時の返り値が 16 だったとします。この値をメーカーの都合で 32に変えたりしたわけです。某お客様はこのエラーになる状態を使ってそのときはエラー処理を検出して復旧に努めるようなコードを書いておられたようです。そこで、自分のところのソフトが動かなくなるので元に戻して欲しいとのお願いが来たわけです。

お願いは残念ながら、聞き入れられませんでした。
エラーコードが変わったのは元々あった状況の理解が深まることで、2つのエラー状態が分かり、エラーコードが二つに分かれたことが原因です。元に戻すと、新しく発見されたエラーの状態をちゃんと処理できないという別のバグを発生させてしまうこと、また利用しているお客様が少なかったことからお客様からの依頼は見送らせていただくことになりました。

ケース2：　メッセージを出さなくしてもらいたい

二つ目のケースは、ある依頼をあるシステムに送った時に帰ってくるメッセージについてです。訴えは、「バージョンアップしたら余分なメッセージが帰ってきたので、増えた分を出さなくして欲しい」というものです。

このメッセージ自体はセキュリティの監査の目的で出力していて、見る見ないはユーザーの勝手ですが、出さないとまずいメッセージのものです。

この時は「ユーザーの書いたスクリプトを変更したくない」とはっきり書いてありました。このポイントは大事なので、あとで触れます。

エラーはなぜ変わるか？

ところで、エラーのメッセージやエラーコードはなぜ変わるのでしょう?エラーの処理の方法とかメッセージというのは、時間がたつとエラーの種類や分類が増えたりして変わりがちです。その理由は一般に以下の3つだと思います。

(1) エラーに対する理解が深まり、別々のエラーとして認識される。
(2) デザインが変わり、システムの別の場所で処理されるようになる。
(3) 規格が変わり、それに沿うことを要求される。

(1) は例えて言うなら、「タイヤのパンク」という問題が「タイヤの外側から釘などが刺さったパンク」「劣化によるタイヤのパンク」「タイヤのバルブの緩みによる空気漏れ」などに分かれるようなものです。ソフトウェアを書く際に、すべてのエラーを想定することは無理なため、時間を追って実装されていくことはよくある話です。

(2) はシステムの効率などを考えてデザインされ直したときに、従来と異なるところで、エラーが扱われるようになることです。複雑なソフトウェアは階層に分かれていることが多いですが、処理する階層を変えることでエラー処理が簡単になるための移動などがこれに当たります。

(3) は規格が変わったために動きが分かるというものです。規格に沿って書かなければいけないソフトウェアの場合、規格が変われば動きも変わります。

変更できない大人の事情

世の中のソフトウェアは様々な事情で変更ができません。「変更しようにも、お金も時間もない」という理由から「作った人がいなくてもう誰も分からない」という「薄い氷の上を歩くような運用」をしているシステムまで様々あります｡そう考えると、「商品として出しているのだから、そう簡単に変えてくれるな」という気持ちも分からなくはありません｡「ユーザーの書いたスクリプトを変更したくない」とはっきり書いていらしたお客様もきっと何か事情があったのだと思います。

しかし、程度の差こそあれ、作る側は安易に変えていることは少なくて、しかもどの程度将来の動きを保証するのか分かるようにしていることが多いと思います｡

エラー処理を勝手に変えていいの？

ここでは簡単にエラーの処理を変えたように書いていますが、実際にはそんなにことは簡単ではありません。APIと言われるものも同様ですが、勝手に予告もなしに変えたのでは、上の例みたいに破綻してしまいます。ですから、実際には、どれくらいインターフェースとか返り値とかを保証するかについて言及があります。

例えば、dd コマンドのmanページの最後の方には、こう言及があります。

ATTRIBUTES
     See attributes(7) for descriptions of the following attributes:
     +-----------------------------+-----------------------------+
     |      ATTRIBUTE TYPE         |      ATTRIBUTE VALUE        |
     +-----------------------------+-----------------------------+
     |Availability                 |system/core-os               |
     +-----------------------------+-----------------------------+
     |Interface Stability          |Committed                    |
     +-----------------------------+-----------------------------+
     |Standard                     |See standards(7).            |
     +-----------------------------+-----------------------------+

Interface StabilityにCommitted （日本語では「確実」と訳されているようです）があれば、このインターフェースは将来的にも同様な動きが保証されています。また、逆に何もなければ、将来は変更される可能性があると思っておくと良いと思います。また、Standardのところは規格に沿っていると言うことなので、規格が変われば変更される可能性があります｡いずれにしてもこの場合は、予告なしに変更は考えづらいです。

修正依頼の通し方

修正依頼を通すには、コツがあります。どこかで既にお聞きになったことがあるかもしれませんが、知っておいて損はありません。

(1) 簡潔に、明快に

意外と難しいのがバグをどう説明するかと言うこと。
悪い言い方ですが最初の 3 行位を読んで見放されるバグもあります。
問題の内容を簡潔に、明快に書くのは大事です。
（自分ができているかは棚に上げています。ごめんなさい。）

もし依頼のテンプレートのようなものがあるのであれば、それに従うのも良い方法です。テンプレートは受け取る側の必要な情報を簡潔に書いてあるからです。

(2) 何をして欲しいかはっきりと

「大変だ、大変だ！」と詳細を何十行も書いて、夜中にアメリカの偉い人をたたき起こして大騒ぎすれば問題が解決するわけではありません。何を実現して欲しくて、いつまでにどんな支援が必要かを簡潔にはっきりと書きましょう。特に仕様の修正に結びつきそうなバグであれば、最終目的地とも言える要件がはっきりしないと対応が始まりません。

いつまでに何をして欲しいかをはっきりと書いてください。

(3) 影響の範囲

あなたの依頼している修正は、修正しないことによってどれくらいの影響があるのでしょうか?あなただけが困るのでしょうか?類例や同じようなシステムはありますか?影響の範囲によって直してもらえる順番が変わります。きちんと書いておきましょう。

もっとも、OS やドライバーなどソフトウェアの階層が下がるほど簡単には変更してもらえません。これは、影響の範囲が大きくなるからです。

そうは言っても世の中、大人の事情というのは色々あるわけです。どんな影響があるのかを具体的に書いておきましょう。最後はヒト・モノ・カネの議論になるわけですが、書いておかなければ推し量ってもらうことはできません。

最後に

修正依頼が通ったとしても、通らなかったとしても、それなりの作業は発生します｡恐らくLinuxの開発などでもおなじです。うまくいかなかったとしても、"Thank you for your work!" とか "We appreciate your timely response and effort!" とか伝えてあげてください。本当に助かったなら、"You saved my day!"くらい言ってみましょう｡

もしかすると、回り回ってあなたの修正依頼の優先順位がなぜか上がるかもしれませんよ｡結局お互い人間ですからね｡