重要な言い換え

　ユーザが話したことを、システム化するのがSEの仕事ですが、ユーザが言ったことは、適宜、言い換えなければならない。私は SE の業務理解、設計能力に最も必要な能力は「どれだけ言い換えられるか」ではないかと考えています。

受注のない売上はない！

　ユーザは自分の言葉でしか話してくれません。ですからユーザ特有の言い回しがあります。

　たとえば、「今のシステムは必ず受注入力しないといけないけれど、『受注のない売上がある』ので本当に不便で困っている」というようなことを言います。

　これをユーザの言葉をそのまま受け取って、受注データがない売上データを許すシステムに改良する（新規に作る）なんてことを……。まあ、実際に見たことがありますから、そういう対応をする人もいるのでしょう。

　ユーザの言葉をよく聴けば、単純に手作業なら「受注書を書かない売上がある」と言ってる訳で、システム的には「受注入力をしないで、いきなり売上を入力したい」と言ってるに過ぎません。

　ユーザの「受注のない売上がある」という言葉は「受注と同時に売上が発生する取引がある」と言い換えて受け取るべきです。

　この程度で間違うSEは今は少ないと思いますが、例えば、「直送」という取引形態がありますが、これは「入庫と出庫が同時に発生した」と言い換えることができますでしょうか。

　いずれの場合も、言い換えることは、その瞬間は複雑になるような気がします。実際に単機能でみれば複雑になるでしょう。

　しかし、受注データがない売上データが存在すれば、そのシステム全体では、受注データに関するあらゆる処理の仕様書に「受注データがないときには売上データのxxxを参照すること」という一文が入りますから、システム全体では大変なロスが起きます。「受注のない売上がある」とその言葉の通りシステム化しても、当然、動くものを作ることは可能ですから、絶対に間違っているとは言えません。

　しかし、この言い換えができないとシステム全体の複雑さは複利で効いて、まるでトイチの闇金で金を借りたかのように、後工程が複雑になってしまいます。

　KISS（Keep It Simple, Stupid）！システム設計は KISS（Keep It Simple, Stupid）の原則を守るべきです。しかし、シンプルにするのは目先だけではないのです。

言い換えは悪いか？

　言い換えなくても、絶対に間違っているとは言えないため「ユーザが言った！」ということを強弁する人もいます。そういう「ユーザが言った！」と強弁して押し切ろうとする人は、私には単に意地を張っているのか、そう信じているのか実際には分かっていません。

　もし、悪いと考えている人がいるならば冷静に考えて欲しいのですが、ほぼすべての企業で日常的に言い換えながら行っている業務があるので、少し考えてみてください。その業務とは？

　　　　　　こ
　　　　　　
　　　　　　こ
　　　　　　
　　　　　　は
　　　　　　
　　　　　　考
　　　　　　
　　　　　　え
　　　　　　
　　　　　　る
　　　　　　
　　　　　　時
　　　　　　
　　　　　　間
　　　　　　
　　　　　　で
　　　　　　
　　　　　　す
　　　　　　
　　　　　　。

　そう、複式簿記です。私でも「日商簿記3級ぐらいは取ってね」って言うのですから、SEの中に資格取得者も多いのでは？

　例えば、交通費精算するときに申請するのは、ほぼ単式簿記の形式でしょう。しかし、企業の経理は複式簿記で行われるため、経理担当者が、必ず、借方・貸方に仕分け（つまり、言い換え）を行っています。

　もちろん、単式簿記で経理処理ができないかというとできます。お小遣い帳も、家計簿も、なぜか日本の自治体のほとんどが単式簿記ですから、「できる」「できない」で言えばできます。新人君が経理システムとかやると「なんでこんな面倒なことを……」って言いますけれど、社会人経験が数年も経てば単式簿記じゃダメだということは分かるでしょう。

　逆にいうと「言い換えはダメ！」って考え方は「単式簿記でできる！」って考え方と同じです。

　確かに、データの発生時点では単式簿記の方が処理は単純です。しかし、その後の処理はとんでもなく複雑になります。一方、複式簿記はデータの発生時点で「仕分け」という面倒な処理が発生します。しかし、その後の処理は、単式簿記に比べたら非常に単純になります。

　システム全体で KISS の原則を守るには、実際、いろんな場面で「単式簿記」を「複式簿記」にするような言い換えが必要なのですが、未知の問題に直面する現場で、常にそれができるとは限りません。

　言い換えができずにシステム全体（後工程）が複雑になることをを何とか避けるには、

　１．複雑さはデータが発生時点で吸収する。

　２．それで漏れてしまったときは「xxxがないときは〜〜」と仕様書に書かなければならないときに、そのデータが生まれる処理に戻って吸収できないか検討する。

　以上の２つを心がけていけば KISSの原則に近づくでしょう。２番目は適応に躊躇することが多いけれど……。躊躇せずに、気づいたときに直した方が、トータルとしては良いことが多いです。

　余談ですが、複式簿記が発明されていなかったら私はその言い換えをできたか（複式簿記にできたか）？思いついても相当ケンカすることになっただろうな〜。「できる」「できない」なんてクソみたいな議論で、できるから良いならシステムなんて要らない。どちらが効率的かが議論の対象だけれど、なかなかそうはならないね〜。