2016年10月04日

なぜエラー表示が必要なのか


初めての方はこちらを「はじめに

ここで言うエラー表示というのはエラーが発生した時にダイアログ等で内容を表示する事を指しています。「何を当たり前な事を?」と思う方もいるかもしれません。しかし少し掘り下げてみると新たな視点でみられるかもしれません。

エラー表示の種類


まずエラー表示の種類を整理して明確にしておきたいと思います。
エラー表示と一概に言っても少なくとも以下の二つには分けられると思います。

一つ目はユーザーの操作ミスなどによるものです。
例えば以下の様に入力が許可されていない内容を入力したような時のものです。
53N020_001.jpg
これはユーザーに向けてのメッセージであり、このソフトウェアはこの様なユーザーの操作ミスは事前に想定していて、仕様として盛り込まれているものです。仕様ですから普通の機能に関する仕様と同様に審査や承認を受けているものになります。

二つ目は内部的なエラーです。
例えば以下の様な感じでプログラムが内部的にファイルを作ろうとしたら予想外のエラーが発生して失敗してしまったような時のものです。
53N020_002.jpg
こちらは先程とは逆に予想外の出来事であって開発中には想定出来ていない事であり、ユーザー向けのメッセージというよりは開発者向けのメッセージです。「どこまでが仕様の範囲か」での定義に従えば仕様は仕様なのですが、設計を始めないと分からない部分もあり、またユーザー向けではないという事から審査が甘くなりがちです。

一つ目のエラー表示はユーザーに向けた仕様そのものであり、ここで対象にするのは二つ目のエラー表示についてです。それをここでは内部エラー表示と呼ぶ事にします。(実際は表示に限りません)

内部エラー表示の目的


そもそも内部エラー表示は何の為に出しているのでしょうか?
先程の説明通り、それは開発者に向けて問題点に関する情報を伝える為です。
それではもう一歩踏み込んで何故伝える必要があるのでしょうか?
幾つか理由は考えられますが最大のものは原因究明の効率の為という事になると思います。
もし内部エラー表示が何もなく「何某かの処理中にエラーが発生した」という情報だけだとしたら、問題の原因究明の為には完全に再現可能な操作パターンを見つけてもらって教えてもらうか、デバッグ出来る環境を現場に持ち込んでその場で調べるかのどちらかになってまうと思われます。いずにせよ多くのパワー(=コスト)がかかる事になります。
もし内部エラー表示で「何の関数でどの様なエラーが発生したのか」だけでも分かればその分原因の可能性を絞り込む事が出来、結果として調査のコストを減らす事が出来ます。

しかし逆に考えると内部エラー表示の主な役割が原因究明の効率の為だとしたら、仮にリリース後の全期間(ここでは保守期間と呼ぶ事にします)で問題点が一切発生しないもしくは数年に一度程度しか発生しないようならば、内部エラー表示の処理は特に入れる必要は無いのではないでしょうか?そんな極めて稀な事柄に対して開発コストを割くのは無駄に思えます。

この例は極端な例ですが、しかし内部エラー表示をどこまで充実されるべきなのかという事は、この例の通りどれ位問題が発生してその時にどれ位のコストがかかるのか、そして内部エラー表示によってどの程度そのコストを削減できるのか、という判断になると思われます。
まとめると
内部エラー表示の開発コスト vs 問題点発生によるコストの削減
の費用対効果という事になります。

次にそれぞれどの様なコストがかかるのかを具体的に見て行きたいと思います。

問題点発生によるコスト


問題点発生時のコストにはまず対応の為に以下の様な作業が直接的に発生するのでそれがそのままコストという事になります。
1.情報収集

現象を把握する為に情報を収集する必要があります。
電話やメール程度で済む話ならば大してコストはかからないかもしれませんが、問題の発生した現場へ行かなければならなくなると距離が遠くなればなる程大きなコストがかかる事になります。
2.原因分析、対応

3.修正(納品)


内部エラー表示は1のコストを削減する為のものと言えます。また今はネットワークによって自動的にアップデートされる事は普通の事ですが、これは3のコストを削減するものと言えます。

直接的な対応のコスト以外に結果として以下の様なコストもかかります。
4.ユーザー等との交渉や調整

5.ユーザーの業務が止まる事に対する対策

ソフトウェアの代わりとして人海戦術でとりあえず凌いだりとか、それもできずに業務が止まってしまえば損害賠償が発生する可能性もあります。特にインフラ等社会的影響が大きくなればなる程その額も大きく成ると思われます。

6.信用の低下

酷い場合にはブランド価値を貶める様な事になるかもしれません。目には見えませんが将来にわたって取引が縮小する可能性がある事を考えると大きな損失と言えるかもしれません。

そして最後に
7.開発日程の遅延

問題点の対応に取り組んだせいで元々取り組んでいたソフトウェアの開発日程が遅れたとすると、そもそも遅れただけでも計画の整合性が取れなくなって様々な調整のコストがかかります。そしてリリース自体が遅れてしまえば商機を逸する等の機会損失もあり得ます。

改めて書き出してみると色々な損失が発生する事が実感できます。一回の問題点の発生でこれだけのコストがかかる可能性があるという事です。問題点の発生によるコストという意味ではリリース後の全保守期間中に発生した全ての問題点にかかるコストの総和という事になります。

開発コスト


一方開発のコストは内部エラーに関しての以下の様な作業でしょうか。
1.一元的な管理部の作成

2.全ての関数に管理部に繋がるエラー処理を埋め込む


エラー処理は全ての関数に共通して統一的な仕組みとして確立する必要がありますから、そういう意味では最下層の部品と言えます。従って汎用的なものを作る必要があるのでその点の難しさがあります。また実際に内部エラー表示させる情報は多ければ多い程有用な訳ですが、その為には部品の機能も多くする必要があり当然コスト(パワー)がよりかかります。

内部エラー表示の充実度が意味するもの


上記の両者のコストの比較から内部エラー表示をどれくらい充実させるかを決める必要があります。単純に考えれば内部エラー表示を充実させる事で問題点発生時のコストが削減される分から、開発コストを差し引いた分が得をする分量という事ですから、理論上はそれが最大になる様に開発コストをかければ良いと言う事になります。しかし実際上の問題として無い袖は振れませんから、そういう開発をする余裕が無ければ結局おざなりな対応になる可能性があります。そうなればそれは目先の利益(開発コストをかけない)を優先して将来の利益(問題点発生時のコストの削減)を失う結果になります。その結果このソフトウェアのライフサイクル全体でのコストは多くなってしまう事になります。
この様な事をなるべく避ける為には、内部エラー表示についてもその他の通常の機能と全く同様の扱いをする事です。内部向けだからとおざなりにするのではなく、ユーザーに対するのと同様に厳しく仕様を審査して、確実に盛り込む為の計画をする必要があります。
そして何よりもそのソフトウェアの責任者が保守期間まで含めた全体でのコストの判断をシビアに行う必要があります。

一覧


メニュー

関連


なぜログやエラー処理の組み込みは苦労するのか


記事を広める



posted by 善 at 21:40 | Comment(0) | TrackBack(0) | 設計 | このブログの読者になる | 更新情報をチェックする
スポンサーリンク
この記事へのコメント
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント:

※ブログオーナーが承認したコメントのみ表示されます。

この記事へのトラックバック