キャリア20年超。ずっとプログラマで生き延びている女のコラム。

砂漠の国の王子はいかにして船出をするか

»

 わたしは開発現場で黙々とコードを書いてることがほとんどで、あまりお客さまと顔を合わせることがないんですが、要件定義のために客先にでかけた経験も少しはあります。

 で、お客さまから処理の流れを聞きながら「あっ、砂漠の国の王子様が船出してる」って思うことが結構あります。

 「砂漠の国の王子様が船出する」ってなんのこっちゃ、とお思いでしょうが、わたしが高校生のときに読んだ氷室冴子先生の『少女小説家は死なない!』っていうコメディ小説がありまして、売れない少女小説家が書いた小説に「そして、フラーゼは海に船出した」という一文があって、それを読んだ主人公の女の子が、十行前に「砂漠に囲まれた陸の孤島のような国」と描写されていた国にいた王子様がどうやって海に船出するんだ、とツッコミを入れる、というエピソードがあったんですよ。

 これは、売れない小説家の書く小説がなんで売れないのか、という理由を示しているくだりなんですが、これが妙にわたしの頭の中に残ってて、以来、前後のつじつまがあわない、みたいな意味で「砂漠の国の王子様が船出した!」って呪文を心の中で唱えてるんですね。

 「砂漠の国の王子様が船出した」という情報はそんなに不自然さがないのに、その前に「王子様がいたのが砂漠に囲まれた陸の孤島のような国」という情報とつなげると、途端に不自然になります。だけど、間に「砂漠の国の王子様が海に面する国にでかけた」という情報さえあれば、不自然ではなくなるわけで、つまり問題は、情報が足りない、の一言に尽きるんです。

 お客さまは慣れ親しんだ業務のことを、省略して話してしまうことがままあるんですね。まあ、王子様が港にいるんだから、その間に移動イベントが発生しているのは当然であって、そんなことをわざわざ話す必要はない、と考えるのも無理はありません。けれど、お客さまにとっての「常識」と開発側にとっての「常識」が食い違っている、というのは業務系開発ではよくある話です。それでもって、小説なら「読者のご想像にお任せします」ができますが、プログラムはそうはいきません。足りない情報はすべて埋めなければいけないのです。

 しかし、お客さまに向かって「いつ王子様は海に面した国に移動したんだヨ!」などというツッコミは入れられないので、わたしは「やはり砂漠の国の王子様ですから、港までの移動にはラクダを使ったんですかね。それだと時間がかかりそうで大変ですね」とか、適当なことを言ってみることにしています。適当だけどわりと具体的なことを言うのがコツです。それくらい具体的な返事を期待しているんだよ、というアピールになります。やりすぎると、ただの適当な人になりますけど。

 これでYESが返ってくれば手元の資料にそれを書き込むだけですし、「いや、移動呪文で一瞬ですよ」とかいう答えがかえってきたら、「なるほど呪文ですか、それは便利ですね。主にどのような呪文をお使いですか?」とたたみかければ「ああ、そういう情報も必要なんですね。今度、うちの魔法使いにきいておきます」ということになって、穏便に情報が収集できたりします。

 ところで、こういう問題で最悪なのは、誰も王子様の港までの移動方法に思いを馳せることなく、実装フェーズに突入してしまった場合です。

 渡された仕様書は「港で王子様を待つ」でシナリオがはじまっていて、それを信じてコードを書いたら、いつまでたってもイベントが発生せず、結合試験フェーズに至ってようやく誰かが「なんで王子様を船に乗せてくれないんだ!」と怒鳴り込んできて、「だって、王子様が港に来てません」としか答えられない、という土壇場でのちゃぶ台返しになります。

 そういったトラブルは、時折、お客様に報告しないといけないレベルの問題に発展し、お金を握ってる偉い人が開発現場まで出張ってきて、「それはテレポートさせちゃいかんのか?」とか言い出して、「すみません。それは世界観が違うので一緒にするのはムリがありまして……」とプロジェクトマネージャさんが平謝りして、「魔法と超能力を混ぜて成功した例を耳にしたことがあるんだが」「それをは特殊例でして、一般的には……」などという噛み合わない会話を傍で聞きながら、「今さら、そこまで話が戻るの?」と戦慄したり。

 そんな悲劇を生む、要件のすり抜けというのは、どうして誰も気付かなかった、という単純なことから、そんなこと言われないと分からないよ、って感じの企業固有のお約束事まで、レベルはいろいろですが、まあ、意外とあるあるな出来事です(←もしかしたらわたしがよくぶち当たってるだけかもしれん)。

 そんな出来事に遭遇するたびにわたしは、人間ていうのは想像力でいろんなものを補って思考しているんだなあ、としみじみと考えます。お客さま側も開発側も、それぞれの想像力で補った完成予想図を描いていて、それを完全一致させるなんて、どだい無理な話なんでしょうけど、近づける努力を惜しむとどちらも不幸になります。

 目の前にある情報だけで物事を判断している人なんてまずいないですし、かといって、目の前にある情報だけでしか物事を判断できない人は、仕事で使いものにならなかったりします。どこからがしっかりした情報で、どこからが推測した情報なのかを、自分の中できっちり整理できて、不足している情報を的確にあぶりだせるのが、優秀な情報処理技術者といえるのかもしれません。

 それにしても、これからわたしは何回、「砂漠の国の王子様が船出した!」と心の中で叫ぶのかなあ、とか考えると…… いや…… きっと大丈夫だ……。

Comment(6)

コメント

仲澤@失業者

自分の場合は
「それは風桶なので詳細が必要ですね」
・・・(前提と結論の関係がわかりません)等と言いますね(笑)。

ちなみに「風が吹けば桶屋がもうかる」仕組みとは、
大風->砂埃発生->眼病増加->失明増加
->盲目の三味線演奏家増加->三味線需要増加
->猫減少->鼠増加->桶を鼠がかじり破損増加->桶需要増加。

だそうです。
以外に知らない人が多いので、これを説明すると場がなごみます(vv)/~。

仲澤@失業者

以外=>意外 orz.

ひでみ

こんばんわです。ひでみです。


仲澤@失業者さん

ああ、単純に「風が吹けば桶屋がもうかる」と表現すればよかったんですね。
なぜそれを思いつかなかったんだろう……。

ところで私、「風が吹けば桶屋がもうかる」ってずっと、風が吹く⇒砂やら埃やらをかぶって汚れる⇒みんなが銭湯にいく⇒桶の需要が伸びる、だと思ってました。
もっとステップ数多かった! てか、意外とダークだった!


fugaさん

わざわざ、文章の書き方講座のサイトを教えてくださるとは、よっぽど私の文章が読みづらかったんでしょうか?
私なりに読みやすい文章になるよう心がけているつもりでしたが、まったく成果があがっていないようで、穴を掘ってでも入りたい心境です。

育野

「何が言いたいのかわからん」「なんでそうなるのかわからん」と
よく言われる身としては耳が痛い話です.

こうなってしまう原因は,
(1)他者への想像力の不足
(2)自分の経験や知識は万人に共通,との思い込み
(3)自分のコミュニケーション能力に対する過信
(4)「行間を読む」能力が評価される風潮
の合わせ技にあると,私は考えます.

(1)+(2)=語るべき前提をすっ飛ばして話を始め
(1)+(3)=言った事(あるいは言ってない事まで)が100%伝わったと勘違いし
(4)=聞き手が前提を確認することがはばかられ,結果として語り手が自分の言動の不備に気づかない
or聞き手に指摘されても相手の能力不足で片付け,伝え方が改善されない

#これを防ごうと,前提を確認しながら話したり思考のステップを細かく伝えたりすると
#「話が長い/くどい」と言われる…orz

ひでみ

こんばんわです。ひでみです。


育野さん。

おっしゃること、本当にその通りだと思います。
用語の定義から話し始めたりすると、「前置きはいいから」とか言われたり……。

それに、話を細かくしすぎると、全体像がよくわからなくなってきて、混乱を招く場合もあったりするので、細かくすればいい、というものでもないのが困りものです。

「伝わらないのはあたりまえなんだよ! だから、双方ともに努力しようよ!」っていう前提で話ができれば、いろんなストレスが減るんじゃないかなあ、とか思うんですが、どうすればそういう状況になれるのかが、かいもく見当がつきません(苦笑)。

コメントを投稿する