ロバ売りの親子の苦悩

 ロバ売りの親子とは

あまりよくは覚えてないのですが、ざっとストーリーを紹介します。

ある貧乏な親子が飼っていたロバを売るために市場に出かけました。

道中、通りかかったある人はいいました。「なんで愚かな事をしているのだ。2人ともロバに乗らずに歩いているなんて。」それを聞いた2人は、子供をロバに乗せる事にしました。すると、今度は別の人が通りかかり、「なんて親不孝な子供なんだ。こんな年老いた親を歩かせて自分はロバに乗っているなんて。」

それを聞いた2人は、親をロバに乗せました。するとまた別の人が通りかかり、「なんて可愛そうな事をする親だ。こんな幼い子供を歩かせるなんて。」それを聞いた2人は、2人でロバに乗りました。するとまた別の人が通りかかり、「なんて可愛そうな事をするんだ。こんな小さなロバに2人も乗っているなんて。」

最後に2人はロバの足を縛り、天秤棒で吊るして運ぼうとしましたが、ロバは暴れそのまま川に落ちて死んでしまいました。

この物語では、親子は通りすがりの人の無責任な意見に流され、最終的にロバを失うという損失を負ってしまったのです。

この話で注目すべき点は2つ。まず、全ての状況において全ての人間にとって都合がいい事はあり得ないという事です。さらにこの話の場合、ロバの都合も考慮してしまったため、ますます全てに都合の良い場面が起こりえなくなってしまいました。

この話のポイントを表にしてみましょう。

メリット デメリット
2人とも歩く 親子、ロバともに同じ負担になる。 ロバに楽をさせてしまう。
子供がロバに乗る 子供が楽ができる。 親の負担が大きくなる。
親がロバに乗る 親が楽ができる。 子供の負担が大きくなる。
2人ともロバに乗る 親子とも楽ができる。 ロバの負担が大きくなる。
ロバを天秤棒でかつぐ 親子の負担が平等になり、ロバにも楽をさせない。 ロバが暴れてしまい運送が困難。

通りすがりの人はデメリットをまず批判します。そして、デメリットを解消するように親子に詰め寄るわけですが、1つのデメリットを解消するたびメリットを失い、また新たなデメリットが発生します。

プログラマーは、しばしばロバ売りの親子になります。コンピューターソフトというものは、全ての人にとって都合の良い操作性はなく、1つ操作性を改善すると別の面で使い勝手が悪くなります。しかしながら、ユーザーはまずデメリットを指摘し、改善を求めてきます。

もし、家を建てたとして、完成後に希望と違う箇所があったとします。ある程度の作り直しはできるでしょうが、根本的に設計から見直す事はできません。たとえば、トイレを洋式から和式にしろというのは完成後も可能でしょうが、完成後に階段をエレベーターに変えろというのは無理です。

ところがソフトウェアというものは、物理的に何かを作るのと違い、やり直し、作り直しが何度もできます。したがって、ある程度要求どおりに作り直しをする事ができます。例えば、消費税は全て税込みで扱うハズだった要求仕様が、完成してから「あ、やっぱり外税もあったわ」とか「非課税品も扱うわ」と言われ、泣く泣くテーブルから作り直しになる場合がしばしばあります。それはソフトウェアというものの優れた性質の1つですが、そのためにロバ売りの親子状態に陥る可能性が高くなります。ここではロバ売りの親子にならないための対策を学びましょう。

 クレームの無限ループ

・入力時におけるクレーム

たとえば、こんな入力をする業務ソフトがあったとします。

この場合、まず品名を入力、つづいて数量、単価をいれ、金額は自動計算されて、次の行へといくでしょう。ところが、ある人はいいました。「数量を入れない場合に、いちいち単価を聞いてくるのはおかしい。数量が空欄ならば単価も空欄に決まっている」と。

という事なので、数量をもし入れなかった場合は、単価の入力は飛ばして直接金額入力になるように作ったとします。この仕様で、一見便利なように見えますが、実はものすごく不便です。もし、数量も単価も不要なのに間違えて入れてしまった際に、品名や数量をバックスペースで消していったとします。すると、数量が空欄となり、単価を空欄にしようにも、カーソルがワープしてしまって、単価を消すことができないのです。

じゃあ、数量が空欄なら単価は強制的に空欄にすべきでしょうか。すると、もし数量を間違って空欄にしてしまうと、せっかく前に入れた単価が空欄になってしまうのです。とくに、単価を商品マスターから自動で読み込む場合、マスターに入った単価が消えてしまうのです。

じゃあ、数量が空欄なら単価は強制的に空欄で、数量が入力されたら復活させるべきでしょうか。しかし、実際には単価は商品マスターから読むだけでなく、手で修正する事もあります。これでは、せっかく手で直した単価が、デフォルトに戻ってしまうのです。

じゃあ、数量が空欄ならば、単価は裏でメモリには取るが、表示だけ空欄にすべきでしょうか。しかし、単価が出たり出なかったりするのは、見ていて非常に煩わしいです。っていうか、十中八九「バグだ」といわれます。

そういうわけで、数量が空欄ならば、単価の入力を飛ばすというアルゴリズムは、入力ミスをしない人が使えば問題ないのですが、人間誰しも入力ミスはするもので、入力ミスをすると訂正困難なソフトになってしまいます。であれば、むしろ単価は常に変更可能とし、変更しない場合はenterキー等でその都度入力を飛ばす方が総合的に見てメリットが高いという事になります。

・印刷時におけるクレーム

この伝票をプリントアウトする際に、このように商品名を印刷したとします。


これだけなら、特に問題があるようには見えません。しかし、もし商品名が短かった場合の事を考えてください。


見てのとおり、左に寄りすぎていて格好悪いです。こんな印刷をしたら即クレームになります。品名というのは、


このように、左に若干の余裕をもって印刷しなければ見づらくなってしまいます。が、しかし、これでもし長い商品名があった場合、

文字が枠からはみ出てしまいます。文字が枠からはみ出てしまうと、クレームどころの話ではありません。下手すると、取引先が納入を受け付けてくれない(早い話が売れない)事があります。

この際にまず言われるのは、「印字がズレている」です。つまり、左側に余裕があるばっかりに、右側がはみ出ていると「これははみ出ているのではなく、ズレているのだ」と認識されるわけです。というわけで、長い商品名は、枠ギリギリでも枠に入れないといけません。しかし、「もし商品名が長かったらギリギリにつめて印刷する」なんてアルゴリズムにしてしまうと、商品が複数あった場合に困ります。



見ておとおり、文字の印刷開始位置がデコボコになってしまい、見栄えが非常に悪くなります。この際に言われる事は「印刷位置が時折ズレてしまう。」です。つまり誰がどうみてもバグです。

・バグっぽい挙動はバグ

昔、「ぎゅわんぶらあ自己中心派」という麻雀のゲームがありました。その中で店野真澄太(みせのますた)というキャラがいて、彼は振り込んでしまったり負けてしまった場合に(他のキャラは怒ったり泣いたりするのに)、「人生オワタ\(^o^)/」のようなポーズをして開き直るわけですが、これを見てある人は言いました。「なんでこの人は、負けてるのに笑う絵が表示されるんだ?」と。そして彼は言いました。「これはバグだ」と。

私は、負けてもニコニコしてる(というか、もう笑うしかない)というのが店野真澄太というキャラの特徴だと思っていたのですが、おそらく同様の問い合わせは多かったものと思われます。結局、負けてニコニコしてるのはPC8801SRで、後のPC9801版は泣いてる絵になりました。

ギコナビという2ちゃんねるブラウザのFAQに、「各スレッドが100件までしか表示されなくなったなんつーバグだ」というのがありますが、これは誤って100というボタンを押してしまったために起こった現象です。また、アウトルックエクスプレスにはルール処理というのがあるのですが、複数の条件に合致した場合は上に表示されたルールが優先されるはずが、下のルールの方が有効になってしまったりします。これも最初は「なんつーバグだ」と思ったのですが、実際には複数の条件に合致させないために「およびルール処理を中止する」という設定が必要だったのでした。

マイクロソフト製品のような有名どころのソフトであれば、誤解を招きそうな箇所は色々な書籍や本で解説がなされ、「これは不具合ではない」という事が公になるでしょう。しかしながら、中小の1企業で作られたソフトでは、作り手の発言力は極めて弱いものです。先のロバ売りの親子の例でいくと、親子は通りすがりの人間ではなく、逆らえない立場の人間に「親がロバに乗りなさい」とか「子供がロバに乗りなさい」と指示されているのと同じです。

顧客(依頼者)の発言は逆らえないとはいえ、話し合いで理解してもらう事ができます。伝票の印刷例でいくと、文字がはみ出しているのを見て「印字がズレている」と言われた場合、文字数が短い場合の例を印刷して見せて、「短い場合にはこうなってしまいますよ」と次げることです。

そして、下記の場合のどれにするかを、顧客と相談して決めてもらいます。

(1)文字が左によりすぎるのをあきらめる。
(2)文字が途中で切れてしまう場合がある事をあきらめる。
(3)文字がデコボコになる可能性がある事をあきらめる。

 転ばぬ先のiniファイル

どのような入力、印刷にもどこかに欠点がある事は話し合いではなかなか伝わりません。そんな時は、実際に使って見せてあげる事で交渉がスムーズになる場合があります。全ての例を提示し、この中のどれが良いかを選択してもらいます。

そのために、事前にINIファイルというものを作っておきます。これは、default.iniという名前のテキストファイルで、デフォルトの動作状況を記述しておくファイルです。

#商品名の印刷方法
injimode=0 # 0:はみ出して印刷する 1:枠の大きさでカットする 2:改行する
hinmeimargin=0 # 商品名の印刷位置の左マージン
#数量の入力を省略した場合
tankamode=0 # 0:マスターの単価を表示 1:単価欄を削除 2:ユーザーに尋ねる

.iniファイルはプログラマー側でフォーマットを決めておきます。例えば、先頭が#で始まる行はコメントとか、#記号があればそこから改行コードまではコメント、みたいにです。iniファイルとしたのは、ユーザー側で間違って変更してしまわないように配慮するためです。iniファイルの変更はメニューには入れず、プログラマーや担当業者などが直接テキストエディタで編集します。

はみ出した場合に文字を途中で切るか、はみ出しを無視して枠の外に印刷するかというのは、最初の取り決めで以後変更はしない事がほとんどですので、ユーザーが誤って変更して思わぬクレームになる事は避けたほうが良いでしょう。

 ここで最も要求される能力は"交渉力"

プログラマーの苦悩として「伝言ゲーム」というのがあります。これは、末端のプログラマーとエンドユーザー、末端のプログラマーとプロジェクトを統括している人間との距離が遠い場合です。遠い場合でも、交渉担当となる方が、事情を理解してくれる人だと助かります。特にプログラマーは私のように交渉ごとが大の苦手であるケースが多く、逆に間に一人仲介者が入ることによって、交渉がスムーズに進む場合があります。

しかし、中にはそうでないケースが多々あります。大企業などでは新人を外注との仲介役に当ててくる場合もあります。この場合、とにかく上から言われた事(「おかしいです」という言葉)を延々と言い続けてきますし、『その指示に従った結果、新たな問題が発生しますが、いかがいたしますか?』といった質問には答えてくれません。ひたすら「おかしいです」「おかしいです」と言われ続けます。そういう場合、なんとかして仲介人を説得するか、あるいは責任者をひっぱりだす方法を考えなければなりません。

ロバ売りの親子がロバを死なせずに済むためには、通りすがりの人に対して、その指示に従うとどのようなデメリットが生ずるかを説明できるかどうかにかかってきます。


戻る