設計の「べからず」を3つほど
設計でやってはいけないことを3つほど。
■ 1．やたらコンボボックスを使うべからず
「手入力したくない」「選択式にしたい」ということを「ドロップダウンで」と表現してしまうユーザーがいます。
それを言葉通り受けて、数十件以上もあるデータのものをコンボボックスで作ってしまう。
こんな設計をして「ユーザーが言ったから」なんてユーザーのせいにするなら技術者は不要です。最低ですね。
コンボボックスは、基本的に不変のデータで数件以外のとき使ってはいけないと覚えましょう。
■ 2．「ない時は×××とする」と仕様書に書くべからず
例えば、請求先、納品書（伝票）送付先、出荷先という入力が必要になるときがある。つまり、請求先は本社で、納品先は大阪支社、商品は神戸工場に納品するというような場合に対応する。という仕様があったとします。
この打ち合わせのときユーザーは、「支店がない顧客について、請求先が未入力のときは納品書送付先に請求すると判断してください」と言うかも知れません。
これをその通りに作るならプロを名乗ってはいけない。
ユーザーが請求先が空白であって欲しいと言ったわけではない。「入力を1回にしたい」ということを言っただけで、システム的にはコピーをすればいい。請求先を空白で設計してしまうとき、詳細設計のあちこちに「請求先コードがない（未入力の）とき納品先コードを表示する」という記述が出現し、仕様書も、ソースコードも、テスト項目も、バグも、大変な量に膨れます。
このぐらいのミスならかわいいものですが、ユーザーが「受注のない売上がある」などと言い出すこともあります。
これを、大騒ぎしてそのままシステム化する人もいます。
しかしこれは、受注がない売上ではなく、受注と同時に売上が成立するので、受注書を書かない売上が存在するということを、ユーザーの言葉で説明したに過ぎません。つまり、売上をいきなり入力したいだけの話です。
技術者としては、受注 → 売上 → 請求 → 入金 というフローの中で、「受注が飛ばされた」と考えるか、「売上と受注が同時に発生した」と考えるかの問題ですが、この言い換えを頭の中で瞬間的にやっているかどうかは、SEの重要な資質だとわたしは考えています。
「受注のない売上がある」というユーザーの言葉を、もし、そのとおり受け取ってしまうと、システム全体では大変複雑な設計になってしまいます。
さすがに、受注と売上のような簡単な例でやってしまうことは普通はないと思いますが、処理フローの途中からスタートすることがあるとき、ユーザーは「受注のない売上がある」というのと似た説明をしますから、実際の現場でも結構見かけるひどい設計です。
これらを防ぐには、キーワードとして「『ない時は×××とする』と仕様書に書くのはおかしい」と直感的に思うようになればよいでしょう。そう仕様書に書かないといけない局面になったときは、データの発生時点の仕様に間違いがないか確認してください。
これは最上流では決まらないけれど、比較的上流工程で決まってしまいます。まぁ、ヘボい上流がやらかしていて、下流から入ると修正できなかったりすることもあります。
■ 3．主キーを複合インデックスにするべからず
これも過去のしがらみで変えれない場合も多いけれど、やってはいけない。
余談ですが、弊社でやっているセミナーの教材は複合インデックスになっている。それは、複雑なSQLを書かなければならないのは、DB設計が悪いからというパターンが多く、説明するには複合インデックスにした方が現場で利用しやすいからです。
複合インデックスが必要なら、主キーの他に別途ユニークインデックスをつければよい話です。
それでも、DB設計はなかなか変えられないので、もし、主キーを複合インデックスにしているときは、せめて順番を変えましょう。
複合インデックスでよく見るパターンで
会社コード（子会社への横展開のため）
商品コード
色コード
更新回数
ってな張り方をしていることがあります。
これを
商品コード
色コード
更新回数
会社コード（子会社への横展開のため）
とするだけで早くなることもよくある。
インデックスは選択性（カーディナリティ）の高いものから付けていくのは基本で、順番が変わってもユニークであることに違いはありません。
まぁ、早くなった機能は、会社コードの条件が抜けているバグの可能性が高く、最近では INDEX SKIP SCAN なんて機能もあるから、あんまり影響ないのかな？
余談ですが、（最近、司馬遼太郎を読み直していて）INDEX SKIP SCAN って最初に見たとき、「そこまでするか～」とびっくりしたのですが、RDBMSのメーカーがこれを実装した背景には、上みたいな失敗をやっているのを見るに見かねたのかな、と思ったり。INDEX SKIP SCAN なんか実装しないで、RDBMSのメーカーがしっかり教育したらどうかと思ったりもする。
今、他人のシステムを直していて本当にイライラしたので（3つとも揃っているので）、愚痴でした。3つともやってしまうSEが設計したら、余程運がよくない限りデスマは避けられません。分かっている人にとっては当たり前すぎる話ですけれど、意外とどれもよく見るパターンなので書いてみました。
特に、上の2つに該当する方は、ユーザの真意がわからずに、言葉をそのまま実現しようとするのですから、素人が作ったのとなんら変わりませんし、1つのプロジェクトで何ヶ所も同じ間違いを繰り返していきますので滅茶苦茶危険で、わたしは見た瞬間にキレてしまう。
相手は「なににそんなに怒っているのか理解できない」というのがよくある。当たり前の基準が違いすぎるのでしょうけれど……。
複合インデックスは、今更、何を言っても変わることはないので、大体あきらめますが。
「ユーザが言ってるのに勝手に変えて……」って文句言ってくるタイプは……、ユーザの真意をプロとしてもう少し考えてください。
コメント
m2
生島さんは子供の頃自分と他人の価値観の違いに悩みませんでした？
自分の意思を通す、他人の意思を理解する、そのためにいろいろ補足しながら考えていかないといけない。
その経験が今に生きていると思います。
普通にコミュニケーションが通じる人だと、そのようなことは考えたこともないし、ここのようにそのようなことが必要と言われてもどうすれば良いのかわからないのでしょうね。
相手の言ったことを疑ったり、その内容から真理を推測する必要など、普通の人にはありませんから。
大人になってから、そのような能力をつけようと思っても無理ですよ。
そういう人が書いた仕様は、しっかりレビューするしかない。
ここの２．の例なんて、我々が見れば一発でおかしいってわかるじゃないですか。
下手にそこそこできる人が客の真意を見抜くことなど無理で、ＫＹなニート君や浮きまくり嬢の中に鍛えればものになる人はいるのでしょう。
saki1208
生島さん、こんばんは。
saki1208です。
なんか、イライラが伝わってきますねw
自分で設計していない場合は特にイライラしますよね。
うちも2は例題通りの内容はあり得ませんが、場合によっては三重苦のシステムも
ありそうです。orz
1については基本的にお客様を説得できなかったケースが多いですかねぇ。
# 開発サイドの気持ち的には余計なポップアップウィンドウを作りたくなくて...
# みたいなこともあるようです。
# 別に最新の技術を使わなくても任意のデータを表示して、任意の項目を返すな
# んて機能は簡単に作れるのに...
2については意味を深く考えておらず本来の内容を理解できていないケースですね。
ある程度は経験則で読めるのでしょうけど、経験則だけに従っていると初めての
表現では読み違えてしまう可能性大です。
# さすがに例題通りはあり得ませんけど。
# 社内/外を問わず何度もレビューを行うのに、間違いが間違いのまま承認されて
# しまったり...
# 内部設計からの請負なんかだと逆提案し難い場合もありますね。
3については多分殆どそうです。
# サロゲートにすると主キーの場合と業務キーの場合とで読み書きの処理が複数
# 必要だからだと考えているのかなぁ...
# もしかして、ミスリードしてますか?
ただ、最近はこんな風に考えるよう努力しています。
他人の作った物を後から批判するのは簡単です。
そのときの背景や制限等もわからないことも多々あります。
自分が設計するとき、物を作るときに同じことを繰り返さないようにしよう、と...
m2さん、どうも。
まぁ、変わってるとは言われ続けましたけどね。
大阪では笑いを取らねばならないので、変わってることはそんなに問題にはならなかったですね。
2.の後半あたりがヤバイですよね。
かなり上流の担当範囲ですけれど、本当にパッと言い換えれる練習をしておかないと、相当なデスマになりますわ。
今後の案件では、更に短納期、低価格になるでしょうから、変われずにデスマに突き落とす可能性のある人を早いうちに淘汰しておかないとまずいですね。それには、どうやったらいいのでしょうね。
saki1208さん、どうも。
まぁ、そのプロジェクトは助けてもね。次やらないようにキツく言っておかないとイカンと思うのですけれど、その注意したときの言葉が、「顧客の言ったとおり…」だったり、「俺は今までこれでやって来た…」だったり、論理的じゃないのです。
私の言い方が馬鹿にされたと取る向きもあるのでしょうが、いい大人が論理的じゃないことで向かってくると、私は「馬鹿にされた！」と取ってしまうので……。
低い成功ラインで、偽りの成功を重ねてきた人たちはある意味かわいそうですが、新人じゃないんだから……。ね～。
ちなみに、三重苦の案件では、そのレベルの人が設計しているわけですから、三重苦では止まらずに、ここには書けないレベルのヒドいことをやっています。とほほほほ……。
saki1208
saki1208です。
やはり、プロという意識が無いんでしょうね。
# 私自身はどうかと、もう少し振り返ってみることにします。
確かに大部分の人は(私も)サラリーマンですが、それで糧を得ているという意識に
欠けているのかなと。
# いっそのこと、経営者と営業だけ社員にして、技術者は全部契約にすればいいか
# もw
m2さん、どうも。
今わかりました。
私は人の話を聞いてないのではなく、客の話は聞けている。
ただ、相手をひとかどの技術者と見たときに、ハードルが自分と同じ高さまであがっている。
中間のハードルって持ってないわ（苦笑）
で、すぐにカチンと来るんでしょうね。
通りすがり
外部仕様（あるいは要求仕様）と内部仕様（あるいは実装仕様）をごっちゃにしてませんか。
～しない（がない）時は～する（である）、というのは立派な外部仕様で、それをユーザインターフェースレベルでどう実現するのか、あるいは、実装仕様をどうするのかは、また別の話です。
通りすがりの理解力のない馬鹿タレにコメントしても仕方がないけども、誰もごっちゃにしてないですよ。
「～しない（がない）時は～する（である）」ではなく、入力は1回にしたいということをユーザの言葉で言っただけに過ぎないのです。
外部仕様としては、自動化するためにシステムがあるのですから、「～しない（がない）時は～自動でコピーする」プロとしてユーザの言葉をしっかり変換してから仕様に落とし込まないといけないのです。
理解力のない人に書いても無駄ですけどね。
放牧民
こんばんは。
通りすがりさんに対する態度が相変わらず・・・というのはさておいて。
2はなるほど、と思いました。(1,3は常々思ってました)
なんとなくは思っていたのですが、うまく言語化できていなかったので。
ありがとうございます。
1のコンボボックスをやたらと使うのは「英語圏の人(英語のサイト)」だとほとんど問題にならないんでしょうね。
タイピングでつつがなく補完できますから。
・それがそのまま日本でも乗ってしまった
・(Web視点で)日本は基本JavaScriptの使えないケータイサイトが強いから、選択項目はコンボボックスが常識化しやすい
・(SI視点で)評価に個人差の出にくい人月商売なので、改善意欲に乏しい
のが、1に拍車をかけているのかなぁ、という感じがしています。
こういう問題は「それが当たり前だ」と思ってると、「え？それ不便じゃないの？」っていう発想自体が存在しないのが難しいな、と思います。
私も、今20年くらい年をとっていたらどうなんだろう、なんて考えるとぞっとするんですよね。
まあ、そんな想像ができるんだから大丈夫だろう・・・と信じてはいますけど。
放牧民さん、どうも。
> 1のコンボボックスをやたらと使うのは「英語圏の人(英語のサイト)」だと
> ほとんど問題にならないんでしょうね。
> タイピングでつつがなく補完できますから。
> ・それがそのまま日本でも乗ってしまった
> ・(Web視点で)日本は基本JavaScriptの使えないケータイサイトが強い
> から、選択項目はコンボボックスが常識化しやすい
> ・(SI視点で)評価に個人差の出にくい人月商売なので、改善意欲に乏しい
なるほど、そういう理由は考えられますね。
でも、私が苦しんでるのを設計したのは、英語圏の人でもないし、Web系をぜんぜんやってない人なんですけどね。
注意したら食って掛かって来るってのはどういうことなんでしょう。
やっぱり、自分の頭で考えてない人は困るな。
Jitta
> このぐらいのミスならかわいいものですが、ユーザーが「受注のない売上がある」などと言い出すこともあります。
う～みゅ～。。。
公共事業と内作しかやってない私は、「受注なしに売り上げがあるのか」と思ってしまいました。そんな私もプロ失格ですか？
> 「ユーザが言ってるのに勝手に変えて……」って文句言ってくるタイプは……、ユーザの真意をプロとしてもう少し考えてください。
賛成。上がそういうことを考えられるプロだったら、まだ前の会社にいたかもしれない。
Jittaさん、どうも。
> 「受注なしに売り上げがあるのか」と思ってしまいました。
> そんな私もプロ失格ですか？
ちゃんとユーザに確認すればいいし、真意を読み取ってあげればよいと思います。
下手なことを言うと、ユーザも意固地になるので、流してもよいレベルですけれど、そのまんま言われたとおり作る人も一杯います。
それで、あとでユーザが気づいて、仕様変更が入って悲惨とか言ってたり……。
議事録を盾に談判をやってたり……。
それはユーザのせいではないと私は思うけれど、それで仕様変更を勝ち取るのがえらいSEらしいですわ。
なんだかわかりません。
士郎
久しぶりに拝見します。
全体を拝見して思ったことは自分にはお客さんとの経験が本当に少ないなと
思い知らされました。みなさんいろいろな経験や失敗をくりかえして
学んでいくでしょうけど、その学ぶ機会があることがすごくうらやましいと
思いました。
士郎さん、おはようございます。
学ぶ機会は重要ですね。
私は、偽装請負だろうが、なんだろうが、燃えている案件を選んで入って来ました。
燃えている案件は、手を挙げたらすぐに上位の仕事を奪えるから、勉強にはもってこいです。
大変だけれど修行ですから。