ユーザー要件を聞き出すときの特殊に見えるが、実は良くある例。ここでは考え方を説明したいので、システム構築外の例を元にする。それは一通のメールからはじまった。
当方が勤務している事業所のビルが「東京都環境確保条例の対象となっているビル」か否か分かりませんでしょうか、という内容だ。どうやら「広報」から「総務」に問い合わせが来て、そのビルに勤務しているこっちに質問が来たらしい。
これをユーザー要望のようなものだと考えていてほしい。多分このビルを管理しているところに聞きに行けばなんか分かるかな？と考えたが、システム屋の習性として、イマジネーションを働かせた。「はい、そうです／いいえ、ちがいます」の回答がもらえればいいが、「その東京都環境確保条例の対象ってなあに？」と聞かれるかもしれない。ならば備えをしておく必要がある。
で、事前調査。サーチエンジンって便利だわあ。東京都環境確保条例はいくつかの規程があって、廃棄物を出す工場に適用される規程もあるし、一般ビルに適用する規程もある。全部は読まなかったが、対象となるのはこれかな？と当たりを付けて「条例の第１９条にある「特定建築物」のことでしょうか」と問い合わせをしてきた人に確認してみた。回答はピント外れ。どこそこのURLを参照してくれ、というものであった。Webページを見ると2001年10月1日から敷地面積3000平方メートル以上の土地改変をする場合は、土壌の調査・対策が必要という内容だ。このビルが出来たのは20世紀だから対象外だろうなあ。
これで「このビル出来たのは昭和の時代だから当然対象外ですよ」と回答して終わればよいのだが、システム屋は気を利かせる。こういった場合、だいたいユーザー要件は間違っている。質問文がいい加減なうえに、回答すら出来ずURLを見ろと言うことは、ユーザー側も要件が分かっていないと言うことだ。特殊なケースではない。制度対応などの場合ありがちだ。広報から私まで３人の人間を経由しているのも気になる。だいいち、なぜ当たり前のことを聞く？
そもそも聞くとするなら、ビルの家賃の支払事務を行っている部署に、家賃の支払先に聞いてもらうのが筋で（たまたま座っている人が回答できるかどうかは偶然に頼る）、それが分からないということは質問者に正常な判断能力はないということである。というわけで、多少調べておくことにした。
この東京都環境確保条例、2005年3月31日に改訂され「建築物環境計画書制度の強化」がうたわれている。この流れで質問が来ていると考えるのが自然だ。しかしこれを「広報」が気にするのもちょっと想像しにくい。
ところが「地球温暖化対策計画書制度」というものもこの条例で定められているそうだ。要するに排出二酸化炭素を削減する計画を立てて公表しろ、というもの。これなら広報が気にするのも分かる。ただしこの計画書は「事業所」を対象としている。「ビル」が対象ではない。しかし質問があのとおりいい加減だ、勘違いしている可能性は高い。それに条例自体「建物」を対象としているのか「事業所」を対象としているのか不明確だ。字面を見れば「事業所」だが、大規模テナントの場合は店子が計画書を作り建物のオーナーが提出する計画書に添付しろと書かれている。たまたま蛍光灯を交換に来てくれた人に質問、このビルは「地球温暖化対策計画書」提出対象ですか？「はい」と即答。実施計画と実現施策と計画策定後に判明した問題点まで教えてくれた。ここまで意識してくれているのなら間違いはない。このビルは「東京都環境確保条例」で定められた「地球温暖化対策計画書」提出義務のある事業所を抱えるビルである。
というわけで、システム屋としての事前調査はおしまい（こういうことを考えなければならないから、システム開発には時間とコストがかかるのだ）。でも「そっちの要件は、ようするにこういうことですね」などと正直に問い返してはいけない。先方は要件を分かっていなかったのだ。判断は出来ない。が、つい「ああ、そうです」と言いそうではないか。ここで、もし要件内容が違っていたらどうするんだ。こっちに責任が押しつけられるかもしれない。たまたま座っている人に回答できるかどうか分からないまま聞いてきたのだ。間違ったら自分の責任だ、という意識は皆無であろう。それに逆ギレされると困る。（おかげでどれだけ被害を被ったか。）
まあ、また聞かれたら「先日の件ですが、やっぱり分かりませんでした、地球温暖化対策でなんか計画書出せと言われたのかなとは思ったんですが」くらいのことは言っておこう。ユーザーの要件定義はユーザーがやるものである。しかし、システム側にとっても苦労の多く、かつ熟練の要る業務である。あ、人脈も大事よ。「地球温暖化対策計画書」のことは自分では気づかなかった。ぼやいていたら、それを耳にした人が調べて教えてくれたのです。
ユーザーは分かっていて要件を述べているわけではありません。また分かって述べているつもりでも用語が正しいとは限りません。この人は何を言っているのかと疑わないと駄目です。古典的な例ではこれ。「１ヶ月が30日ある場合の処理は・・・」と言われた場合、「それは4,6,9,11月のことですか」と問わなければ駄目です。「小の月」のつもりで使って２月を忘れていることもあります。また、1,3,5,7,8,10,12月も30日はあります。コンピュータ言語にそのまま変換すると、２月を除く11ヶ月が全て処理対象になります。
こんなのもあったなあ。サブシステム間の受渡データの仕様書に「（予め、定義された）項目長に足りない場合はブランクを詰める」。C/S系のシステムの仕様だけど、元メインフレーマーは「ブランクを詰める」を瞬間的に「ブランクサプライ」と英訳し「項目はブランクを足して固定長にするのだな」と判断。書いた方は項目長を実際のデータに合わせて短くすると書いたつもり。当然議論の内容はなんとなくすれ違い、やや険悪なムードに。
予め誤解のリスクに気がついていたので口を出した。「この項目って固定長なんですか？可変長なんですか？C/S系は可変長が普通だけど、ここだけ読むと固定長に見えるよ」と言うとその場は収まった。（実際には、仕様が出てくるのが遅い、と不満を感じていそうな当方側の連中に、そりゃ仕様書の書き方が悪いよな、と書いた方も思うようにし向けてガス抜きをしてもらったわけだが。）
システム開発のテキストのつもりでぼちぼち書いている文章の一つ。「闘わないプログラマ」で要件を類推する苦労話がUPされたので、親近感を持ち、これだけ先にアップします。コンピュータネタ、目次へ