罪と罰（21） 空白の叫び
木曜日、9時ギリギリに出社した私は、武田さんを初めとするKSR案件臨時チーム全員がすでに出社していることを知った。
「おはよう。早いね」私は近くにいた守屋に話しかけたが、守屋は、ボソボソと挨拶を返しただけだった。
「あっちはみんな早めに来たみたいよ」自席に座った私に、カスミさんが挨拶もそこそこに教えてくれた。「私が来たら、もう全員来てたから」
カスミさんは、だいたい8時30分には出社して、お湯を沸かしたり、給湯室や冷蔵庫の掃除をしてくれる。家庭の事情で早めに退社しなければならないので、少しでもそれを埋め合わせようとしているらしい。
「そうですか」
私は礼を言うと、PCが起動するのを待って、勤怠システムで3バカトリオの今朝の勤怠実績をチェックしてみた。3人とも6時出社になっている。
まあ、追い込みだから仕方がないか、と思ってブラウザを閉じようとしたが、ふと気になって昨日の実績を表示させた。3人とも23時以降だ。これは終電ギリギリの時間のはずだ。
進捗を確認してみるか、と立ち上がりかけたとき、武田さんの怒鳴り声が響いた。
「守屋あ、これじゃあダメだって言っただろうがあ！」
何事かとそちらを見ると、血走った目をギラギラ光らせた武田さんが、疲れ切った表情の守屋にプリントアウトを投げつけたところだった。その後ろで、久保さんと木下、足立が無言でキーボードを叩いている。
「なんでシーケンスなんて使うんだ。IDの最大値を取得して、プラス1しろっていっただろうがよ」
守屋は投げつけられたプリントアウトを拾おうともせず、激しい口調で言い返した。
「だって主キーですよ！重複したらエラーになるでしょう」
「だから何だ。エラーが出たら、プラス1すればいいだろう」
「じゃあ、成功するまでぐるぐるループするロジックを書け、ってことですか」
「お前、耳か頭かどっちかが具合悪いのか。さっきからそう言ってるだろう」
「はは」嘲笑とも取れる声だった。「そんな非効率的なことやらなくても、シーケンス使えば、重複は絶対に発生しないじゃないですか」
「欠番が発生する可能性があるだろうが」
内容を知らない私にも、何を言い争っているのか見当はついた。何かのテーブルの主キーを、どのように採番するのか、ということだろう。シーケンスはトランザクション制御の影響を受けないから、重複は発生しない。主キーのように重複できない値に、これを使うのは常套手段だ。一方、シーケンスはロールバックしても、デクリメントされないから、欠番が発生する可能性は確かにある。
「主キーですよ？欠番が出たら何かまずいことでもあるんですか？」
「レポーティング機能で、Excelに吐き出したとき、連番になってなかったら、データの抜けがあるかもしれないって不安になるだろうが」
「なんで主キーなんか出すんですか。意味ない値ですよね。連番が必要なら、吐き出すときにナンバリングすればいいっしょう」
「あ、いや」久保さんが顔を上げた。「お前の担当じゃないけど、出庫管理マスタの主キーを、注文番号の一部に使ってるから、通し番号じゃないとまずいんだ」
「それは逆にまずいんじゃないですか？設計的に」
確かにあまりスマートな設計ではない。そう思った私が口を挟もうとしたとき、武田さんが苛立たしげに手を振った。
「とにかく」武田さんは強引に収拾を図った。「お前は、言われた通りの仕様を書けばいい。それがまずいかどうかは、オレが判断するから」
「時間ないからさ」久保さんも付け加えた。「とにかく仕様書を仕上げようぜ」
守屋は怒りというより、呆れたような顔で武田さんと久保さんを交互に見たが、やがて達観したように肩をすくめた。
「わかりました。じゃあ、そうします。どうせオレには責任ないですしね」
その投げやりな言葉を聞いた武田さんの顔に、さっと怒りが走ったが、言い合いを再開する気はなかったらしく、それ以上何も言わずに座った。2人とも、床に散らばったままのプリントアウトを拾おうともしない。
私が呆れている間に、カスミさんがさっさと立ち上がると、仕様書を拾い上げ、手早く揃えて守屋の机の上に置いた。守屋は驚いたように顔を上げると、恐縮したように礼を言った。
「あ、すみません」
「ほら」カスミさんはカーディガンのポケットから、紙に包んだ何かを出して、守屋に手渡した。「食べて」
「あ、ありがとうございます」
きっと昨日言っていたクッキーなのだろう。カスミさんは、武田さんたち、そして第2開発課のメンバー全員の机を周り、同じ包みを置いていった。席を外している中村課長と五十嵐さんの机の上にも平等に。最後に私にもくれた。
「ありがとうございます」私はちょっと包みを開いてみた。「チョコにしたんですね」
「甘い物の方がいいと思ったから」
「いただきます」
私は小さめのクッキーをつまんで口に放り込んだ。甘さは控えめだが、外がサクッと心地よく、中はホロッとほどけていく。絶妙だ。何をどうやったら、100円ショップで買った材料だけで、カントリーマアムの数倍美味なクッキーが作れるのか謎だ。
見ると全員がありがたくクッキーを賞味している。切れる寸前まで張り詰めていたオフィスの中の空気が、少しなごやかに弛緩したようだ。
カスミさんお手製クッキーの魔法効果が持続したのは、残念ながら午前中だけだった。
私がカスミさんと食堂から戻ってくると、武田さんと守屋が、またもや仕様のことで言い争いを始めていた。今度は、テーブルの正規化についてらしい。
――何をやってるんだ、あいつは。
考えるより先に声が出ていた。
「守屋！ちょっと来い！」
怒りのせいか、90デシベルぐらいの声が出た。おかげで、武田さんも守屋も、口論を中止して、呆気に取られたような顔で私を見た。
「守屋」
少しボリュームを落として、私は、守屋を手招きした。そのまま、オフィスから出る。守屋は素直についてきた。
「何やってんのよ、あんたは」私は怒りをこらえながら詰問した。「いつまで武田さんともめてるの」
「だって正規化が......」
「うるさい」私は一喝した。「あんたのこだわりなんかクソくらえよ。いつまでもそっちで油売ってられたら困るのよ。武田さんの言うことに、何でもハイハイ言っときゃいいでしょうが。さっさと片付けて、こっちに戻って来てくれないかなあ。でないと、温厚なあたしでも、いい加減キレるよ」
「......もうキレてるじゃないですか」
私は守屋を睨み付けた。守屋はしばらく沈黙していたが、やがて口調を変えて話し始めた。
「どうにも、武田さんにはついていけないんです。さっきも、テーブルの正規化を指摘したら、いきなり怒り出して、お前がオレに意見すんのか、って......」
思わずため息が口をついて出た。予想以上に＜ハーモニー＞での成功体験が強烈だったようだ。以前なら武田さんのやり方に不平不満を漏らすことはあっても、ここまで表だって反発することはなかったのだから。
「あんたがそういうことにこだわるのは知ってるけどさ。あんたはヘルプであって、仕様を決定するのは武田さんと久保さんの責任でしょう？その2人が決めたことなら、ぐだぐだ言ってないで従っておきなよ。明らかな仕様洩れとか、設計ミスならともかく、正規化されてないぐらいで、何がどう変わるっての？」
守屋が何か言いかけたが、私は片手を挙げて押しとどめた。
「わかってるって。これが、うちのシステムだったら、徹底的にこだわって結構。自分が正しいと思ったら納得するまで議論すればいいよ。でも、どうせいずれなくなる小さいシステムなんだよ。しかもうちの担当じゃない。そんなのに時間をかける価値はないでしょう」
「よその課のシステムだって、間違ったやり方をしてたら、正すべきなんじゃないですか？」
「あ、そう？」私は冷たく言った。「じゃあ、CS開発部のAS/400システムにも、そういうこと言いに行くわけ？公事開発部は？進行中の案件、全部、設計から実装までチェックして、間違ったやり方をしてるかどうか確認するの？そうすべきだって言いたいわけ？」
「いや、そこまでは......」
「1人の人間が全世界に対して責任を持つことなんかできないし、すべきじゃない。アメコミのヒーローじゃあるまいし。あんたが今やるべきことは、先輩のミスをうだうだと指摘していることじゃなくて、とっととヘルプを終わらせて、こっちの仕事に戻ってくることよ。あんたが、あんたたち3人が必要なのよ」
「......」
「わかったの？」
「......わかりました。ちゃんと納得できたわけじゃないですけど、とにかくわかりました」
「じゃ、さっさと戻って、続きをやってきなさい」私はドアの方を指した。「武田さんにちゃんと謝るのよ」
守屋はうなずいてオフィスに戻っていった。私は廊下に誰もいないのをいいことに、大きなため息をついて壁にもたれた。
私が守屋に言ったことは事実だったが、全てではなかった。KSR案件が、第1開発課の、正確に言うなら武田さんのアピールに過ぎないとわかっている以上、仕様に口出しなどさせておくわけにはいかなかったのだ。
この案件が成功したら功績は残らず第1開発課が持って行くだろう。第2開発課は、せいぜいねぎらいの言葉と、ビール2パックぐらいもらえればいいほうだ。逆にもし、この案件が失敗したら、武田さんは「第2開発課の連中が仕様に口出ししたからだ」などと言い出しかねない。
そういう場合、本来なら中村課長か、五十嵐さんが緩衝材になってくれるはずだ。だが中村課長は武田さんに権限を委譲したまま放置しているし、いつもなら積極的に介入してくる五十嵐さんは、なぜかこの件については消極的だった。まさか、わざと武田さんの失敗を望んでいるわけでもないだろうに。
すっきりしない気分のまま、私は自分の席に戻った。すでに守屋は武田さんと一応の和解を済ませたらしく、一心不乱にキーを叩いている。こちらに背中を向けているため、その表情まではわからなかった。
私の言葉が効いたのかどうか、とにかく守屋は仕様書作成の姿勢を大きく変えたようだ。内容についていちいち思い悩むのをすっぱり止め、とにかく完成させることだけを目指すようになった。その姿勢は他の2人にも伝染したらしく、少なくとも表面上は従順な態度で武田さんの指示に従っていた。そのためか、その日の20:00過ぎには、全ての仕様書が完成していた。
「どうだ」武田さんはぐったりしている3バカトリオに鼻高々で言った。「達成感あるだろ。仕事したー、って感じじゃないか？」
誰も同意しなかったが、武田さんは気にも止めずに、完成した仕様書のプリントアウトの束を、すでに帰宅している五十嵐さんのデスクの上にドンと置いた。
「よし、呑み行くか！」
3バカトリオは顔を見合わせて言葉を探している。また、もめる原因となるような発言が飛び出す前に、私は慌てて立ち上がった。
「あー、武田さん、ちょっとこいつらも疲れているようなんで、今日は早く帰らせてやってもらえませんか」
「あ？だらしないなあ、お前ら」武田さんは顔をしかめたが、すぐにうなずいた。「まあ、いいか。じゃあ、今日は帰れ。また実装の方で手伝ってもらわなきゃならんからな」
3人は私の方に感謝と安堵の表情を向けると、そそくさと退社していった。きっと3人だけで飲みに行って、思い切りグチを言い合うのだろう。うまくストレスを解放してくれるといいのだが。
「箕輪さん」武田さんが近寄って来た。「いろいろ迷惑かけたが、あいつらはいったん返却ってことで。また実装フェーズになったら借りるけどな。そんときはよろしく」
「はい」私はうなずいた。「仕様書はいつ先方に提出するんですか？」
「明日、五十嵐さんチェックがあるから、早ければ明日の午後かな。まあ、もっとも」武田さんは顔をしかめた。「あの人がいろいろ難癖付けてくれば、来週になっちまうかもしれんけどな」
「難癖って......」
「おっと失礼、そっちの課長さんだったよな。でも、言いたいことはわかるだろ。じゃあ、俺たちも今日は帰るから。お先に」
「おつかれさまでした」
武田さんと久保さんが連れ立って退社していった後、私も帰り支度をしながら、ふと五十嵐さんの机の上に置かれている仕様書一式に目をやった。3バカトリオの態度や言動から判断するに、きっと中身はかなりズレたものになっているのだろう。
ちょっと中を見てみるか、とも思ったが、見てしまったら修正したくなるかもしれない。あまりにひどい内容なら、そんなことに3人の工数を使った武田さんに対して、怒りを隠しきれなくなるかもしれない。昼間、守屋がそうだったように。そんなことになるのはゴメンだった。
それにどうせ、五十嵐さんがチェックすれば、技術的な齟齬などは容赦なく指摘するに決まっている。五十嵐さんが冷たい口調で、問題点をひとつひとつ武田さんに浴びせるシーンが目に浮かぶようだった。私は肩をすくめて、そのまま退社した。
私の予想は外れた。
（続く）
この物語はフィクションです。実在する団体名、個人とは一切関係ありません。また、特定の技術・製品の優位性などを主張するものではありません。
コメント
lav
おそらく、五十嵐副部長はこのまま、客に出すのだろうか？
その先にあるもの、、、
いやねー、無粋だが、客が検収不可として、破談とか、、、。
まさかね、、、。
そういえば、、、Ｋ自動車さんって、
某Sさんのいる某S社も下請けじゃなかったっけ？
acb
> 完成した仕様書のプリントアウトの束を、すでに帰宅している五十嵐さんのデスクの上にドンと置いた。
oh...
仕様書の是非云々とかわからないけど、単純に、読みたくないデス
しかも設計書とほとんど（あるいは完全に）同じ内容をソースコードに起こすんでしょ？ タイプライターのお仕事ですか？
やっぱりやりたくないきもち
lav
あ、某S社じゃねえわ。
Thから始まるから某T社か、、、
n
NGはNGだけど武田さんは無視するのか？
それとも同時に他社に設計依頼していたとか？
展開が読めない。
yamada
五十嵐さんなら「よし武田、この通りに作ってみろ 指示はお前が出して構わない」
と言われて全部やらせたあとに崩壊するパターンだな
で、逆切れで五十嵐さんに食って掛かるも結局「お前がほんとうに正しいと思ったからこういう仕様書なんだろうが！それとも何か！いい加減に書いたんか！」的なことを言われるパターンか、
五十嵐さんが自分がいなくなった後のことも考えて、緩衝材にならずに箕輪さんの試練にするかの2択。
まあ箕輪さんはちょっと他人行儀というか状況に流されやすいわな。
なあなあ気質が抜けないというか。
箕輪さんが課長待遇の副課長になるのなら五十嵐さんなら試練を残していくはず。
管理稼業
このまま武田氏の仕様書を持っていって客先で却下されるも、実は五十嵐氏は某社(このコラムではいつもおなじみのあの会社)に依頼して次の仕様書を提出して、お客さんは結局OK、武田氏はユーザーの求めるものを作れなかったということで、判断されるという展開かも？
S
部を立て直す事を請け負った人間が、明らかに会社の損害に繋がるような事ができるのでしょうか？倫理的に問題がありますし、周囲もそれを許さないでしょう。
このままプロジェクトが進むならば、この案件はどうにか終わらせることができると思います。
内部工数が無駄にかかる、保守性が低そう、etc.の問題があり、良くはないですが、良くある話ということで会社では大きな問題にはならないのでは？
変わらない人たちの今ある能力をそのまま活かす、ということも考えると、武田さん達の課はCS開発部に丸ごと異動、というのが妥当な線ではないかと。
将来先細るのが見えている部に異動することが画策されているのならば、以前主人公が昇進するあたりの話で、中村課長が楽しげな雰囲気ではなかったのも分かる気がします。
wwJww
あー、確かに武田さんだけじゃなくて、中村課長がらみでもトラブルが発生しそうな気がしますね。
gems
設計書には目を通さないんじゃ？今回は責任を持ってお客さんにシステムを納品するということを自覚させる目的があるはずなので・・・・
実装はお客さんの子会社がやりますよって話になっていってまぁ修羅場とかか？？
DumbObj
>出庫管理マスタの主キーを、注文番号の一部に使ってるから、通し番号じゃないとまずいんだ
設計のまずさはいいとして、なんで、注文番号の一部に使ってると、欠番が許されないです？
n
> なんで、注文番号の一部に使ってると、欠番が許されないです？
顧客の要件に「注文番号が通し番号になっていること」があれば、その注文番号と直結してしまっている主キーに、欠番を出すのは駄目でしょう。
顧客の要件になければ、欠番を出さないのは武田さんたちのこだわりということになるけど、いくらなんでもそれはないと思いたい。
主キーを注文番号に使う設計がまずいのは、作中でも登場人物が指摘している通り。
私だったら、注文番号と主キーの対応関係を持つテーブルをかませることを考えるかな。
gems
> なんで、注文番号の一部に使ってると、欠番が許されないです？
欠番の注文があると経理のひとたちが、この番号なんでないの？処理漏れ？書類はどこーー？ システム部に問合せだー！！ とワラワラするからw
p
カスミさんだけが癒しや…
DumbObj
なるほど、注文番号の欠番は許さないという顧客要件があるんだろうってことですね。そうだとすると、出庫管理マスタの主キーを注文番号の一部に使うってのは、余計にまずそうですね。
注文番号を発番する時に1対1で結びつく出庫が必要で、さらに、出庫も必ず注文と1対1で結びつく状態をキープしないと、注文番号に欠番が。。。
無理ゲーのような。。。
lav
ナンバリング用のテーブル用意
主キーは代理キー
出庫管理の番号は、注文番号と枝番でユニークキー、かつ出庫管理の注文番号に外部参照制約。
これでいい？
30秒で考えたざっくり案
DumbObj
それでお願いしますと言いたいところですが、注文とは関係のない出庫とか、複数注文の一括出庫とか、業務内容次第じゃないですかね。
AAA
クッキーは10名ほどに配られたとすると･･、
カスミさんのカーディガンのポケットの大きさが気になったり。
dountileof
ワシはジンジャークッキーとやらが食べたひ。
通りすがり
武田さんの気持ちもわかるわぁ。
これは俺のプロジェクトで、俺が責任を取らないといけないんだから、
俺の納得のいく方法でやってくれ。
お前がプロジェクトを任された時は、お前が納得いく方法でやるといい。
というようなことを言ったことがある。
海外エンジニア
守屋、会社辞めそう・・・。というか辞めたほうが幸せになると思う。
技術もわからないのに年功でえらそうにしてるマネージャにイラつくとか、日本で働いてたころの自分の自分を見てるようだ。
へっぽこERPエンジニア
会計監査の世界では、飛び番が無いことが非常に重要なのです。
例えば、入金票をこっそり抜いて横領をしようと思っても、連番で発番されていたら、誰かが不正をした際に気づくことができます。
この手のシステムでは、データを取り消す時もDeleteは決してせず、DelFlgを立てるか、赤伝を切るかが一般的ですね。
あと主キーに伝票№を使って良いかは、ながーい ID（サロゲートキー)派とコード(ナチュラルキー）派の論争がありますので、詳細はそちらに譲るとして。
私から言えることは、ハーモニーのようなデータ構造がFIXしているわけでなく、アジャイル的な開発手法をとるのであれば行ごとにIDを取るほうがテーブル構造の改廃がより自由になって良いでしょう。TwitterのAPIなんかみても、ユーザーマスタは、ユーザーに見えるIDの他にLONG型の主キーがありますしね。
ただ、データ構造が安定し、長期間使われる可能性があるのなら、リレーションが見えにくくなるのを防ぐためにコードを主キーにするほうが正解の確率が高いですね。コード数も少なくて済みますし、ぱっと見でリレーションが分かるぶん、開発効率でもトータルの保守コストとしては安く付く可能性があります。
切羽詰まっている時だからこそ、議論はすべきだと思いますが、何を優先すべきかも分からず、人の意見もろくに聞かないのというのは、守谷くんもまだまだ修行不足ですね。
J
飛び番をなくすのは可能だと思うけど、性能は犠牲になりますよね。
これは主キーにするしないは関係ないように思います。
今回程度のシステムならいいのかもですが、大きなシステムではどうするんでしょうね？
E.C.
「全世界の責任を～」のくだりから察するに、五十嵐さんが黙っているのは、第2開発課の面々がイニシアティブの機能を継承し担えるかを見ているのではないでしょうか。
「予想が外れた」というのは、その点に関する失望が箕輪さんに対して表明される、という展開を示しているのかなと予想します。
nanashi
insert selectでMax + 1でいいんでない?またはlag + 1とか分析関数でも｡
JavaのAtomicIntegerなどの､addAndGetと同様の事が出来ますし｡
まあ武田のようなのはANSIのSQL2003すら知らないでしょうが｡
n
>insert selectでMax + 1でいいんでない?またはlag + 1とか分析関数でも｡
排他のかけ方次第では、複数クライアントから更新されたときアウトですよ。
SQLServerならOUTPUT句でいい。
master
デスマ突入の予感・・・。
DumbObj
人間がバッチ処理していた伝票類に無欠番の連番を使うのは意味があったのかもしれませんが、DBでのみ管理するデータについて、会計監査の不正検出のヒントのためだけに、無欠番の連番を保証する必要性はあまりないような気がするんですけど、どうなんでしょう？
いずれにしろビジネスディシジョンですよね。
同時実行性も犠牲になりますし、テストなどに余計にお金も必要でしょうから。
私が知ってる範囲では、入金の管理番号や注文番号には、欠番のある連番を使ってるケースのほうが多かったです。
通りすがり
DBは苦手でいつも悩む所なので間違っているかもしれないけど、、、
システムが現実の事象の投影である事と使うのは最終的には人間（ユーザアビリティ)って事から、伝票番号が連番である事は重要だと思いますけどね。
現実問題としては書き損じ等で伝票番号も飛びますから、飛んだ場合は、現実世界同様にし損じである事を記録する様にして。
伝票番号がキーであるか否かに関しては確かに重要じゃないでしょう。
結局の所キーにしなくても伝票番号にはユニーク制約かける必要があるから（ロジック設計的にもDBの内部処理的にも）キーにした場合と同じ手間がかかるでしょうし、インデックスも張る必要があるから実行コストもキーとした場合とあんま変わらん気がします。
正規化に関してはパフォーマンスにシビアなシステムの場合は突き詰める必要はあるだろうけど、実際の軽いシステムの場合はやたらと分割する位なら適当な所で切り上げといた方が楽なケース多いですし、そこは武田が正しいのか守屋君が正しいのかは何とも言えない所かと。
〆切当日なら多少アレでも涙を呑むべきなのは確かですが。
＃ ここら辺、途中で気がついても取り返しがきかないのは、
＃ 先に仕様書ガチガチにしてしまう＆WFの手法の致命的欠陥ですね。
＃ まあ、DB設計がふらふら変わるのも困りものですが。
今回の話に出てきた内容「だけ」で言えば、終息部品の在庫管理なんてそんなに可動の高いものではない筈だから、効率が悪くても単純で分かりやすく実装も楽な武田方式（番号取得に成功するまでリトライ）も十分にありでしょう。
効率が気になるなら、
・伝票番号を決める親になるテーブル（伝票マスタとか伝票サマリとか
呼び方は会社によるでしょう）に有効フラグ列を持たせる。
・最初に有効フラグを落した状態でユニークな伝票番号を持った
データを前述のテーブルに生成、コミット。
・以後、トランザクション開始、詳細データ生成、有効フラグオン、コミット。
でいいんじゃね？って思います。
処理失敗の時はし損じになった事を明確にできるし、最初の行確保（＝伝票番号確保）の部分だけ、Webシステムなら実装はどうせJavaかなにかだろうから、シングルトン＋シンクロナイズにしておけば簡単に排他出来ますし。
2回トランザクションかける事になるけど、そこの効率はRDBMSが宜しくやってくれる事に期待です（笑）
DumbObj
欠番が無いほうが人間にとってわかりやすいので良いというのは理解できるのですが、欠番なしを保証するために必要な時間や手間に見合うだけの価値が本当にあるんでしょうか？
自信を持って"ある"と答えられて、かつ、お金も出すユーザーならいいと思うのですが、そういうケースがどのくらいあるのかわかりません。
不正防止の観点だけでいうと、欠番が無くても不正はいくらでもできますよね。通りすがりさんの書いた内容を借りれば、詳細データを削除して有効フラグを落とすだけで、連番を保ちつつ改ざんが可能です。そういう改ざんを防止するには、監査ログを取得するなどの対応がどのみち必要なので、欠番の有無は、DB管理のデータに対する監査目的ではほとんど意味がないような気がします。
欠番なしの発番を実装する場合は、nanashiさんやnさんが書いてるように、適切な分離レベルでinsert select max+1を使うのが第一候補だと思っています。DB側でなくアプリ側で排他制御すると、複雑になりますし、サーバーを増やす場合や受注アプリが増える場合（電話受注のみから、Web受注にも対応するような場合）に危ういです。
aa
「20画面程度」
「生産中止にした何種類かの製品の管理」
「在庫がなくなったら、このシステムもお役ご免」
「11月第1週」から「12月27日が検収日」
という前提なら、守屋君拘りすぎ。
先週の足立君の指摘の方が怖い。そんな仕様書見たくないな～。
lav
aaさん
いやねえ、まさかねえ。
足立君の指摘が怖いのもあるんだけど、
もっと怖いのは自分が実装しないから的な下り。
五十嵐さん、全部責任もてと、実装を武田さん、久保さんに任せる腹づもりじゃ
行き倒れ
ってことは、この仕様書を完成させるだけで既に人材借りて、
さらに夜中までめいっぱいかけてる工数からして、
案件規模に比して大赤字なんじゃないんでしょうか?
その部分まで含めて五十嵐さんは冷たくやり方を見てる気がしますよ(怖)
サルーン
うーん、欠番が許されない仕様なら仕様書書いてる人間が知らないのもどうかと思うし
20画面程度なら正規化必要ないってんであれば、それこそシーケンス使った方が手早く実装出来るじゃないですか。
どうも五十嵐擁護はチグハグな事言ってますね。
サルーン
間違えた
五十嵐→武田 でした
aa
lavさん
私もそんな気がします。
武田さんも業務分析・要件定義に特化すれば、もっと活躍
できると思うのですが・・・。（諦める力も必要。）
サルーンさん
そうそう、シーケンスの方が楽なのに。
（勿論デメリットを考慮した上で。）
なので、私は武田擁護派ではないですよ。
強いて言うなら、「やれやれ」と傍観してる箕輪さん派。
さて、五十嵐さんがどう落とすか。今から楽しみです。
2013年11月20日 (水) 05:13の通りすがり
＞DumbObjさん
確かに横から手を突っ込まれると面倒ですね。
配慮すべき点だったのはご指摘の通りです。
連番が必要か否か、それに意味があるか否かを決めるのは我々ではなく「顧客」です。
仕様合意の段階で実装を見越しての飛び番が出ることの合意、または飛び番でも問題ないことの確認が取れているならば別ですが、詳細設計段階での「システム的に実装が面倒くさいから」、「俺々ルールではこっちの方がかっこいいから」等の理由で安直に現実世界側の運用ルールを変えろとの意見は、武田のやっている事とは別の次元で全く賛同できない主張です。
（誰に対してかは別として、身勝手、という意味では武田の不勉強ゆえのレガシー手法の押しつけも、守屋の実装都合だけでの仕様押しつけも全くの同類です）
その意味で、全伝票が有効となる完全連番が求められるならば私が先に書いた方法もバグ持ちです。
伝票番号が飛んでも良い場合に実際に欠番でも良いのかダミーレコードが必要になるのかは、参照系UIの仕様と実装のバランス（実際には設計者の趣味のレベル）になるので棚上げしておきます。
＞サルーンさん
物語の流れから武田憎しの視点に引っ張れるのは仕方がないのかもしれませんが、正規化に関しては他のシステムがこちらのDBに手を突っ込まない限りは只の内部動作でシステム屋が勝手に決めていい領域、伝票番号の飛びの有無に関しては対顧客の仕様の問題で、属しているレイヤが全く違うのですよ。
（DBが独自設計となっている事から他システムがこちらのDBを直接参照して来ないことが分かります）
確かに「多分」飛び番があっても大丈夫でしょう。
が、それを保証するためにはその伝票に絡む全関連部門の運用ルールと使用システムで問題のないことの確認が必要になります。
相手方の規模やフットワークによりますが、その応答の手間と回答待ちで喰われる時間ってどれ位になると思いますか？
また、それだけの為に動いてくれるお客さんの関連部門の方々の手間は？
顧客仕様に絡む部分は単純な事象であっても現実には単純じゃないのです。
システム刷新時なら、最初に合意とれば良いだけなんですけどね。
DumbObj
通りすがりさんの意見には、ほぼ同意です。
一般論として、欠番を許容しないことの価値はどの程度あるのか？、それに伴って必要となっている複雑性はどの程度のものか？ ということを思考停止せずに考えてみることは、特定のコンテキストにおいて、欠番を許容するように変更するべきかどうかを判断したり、その判断材料を提供したりする時に、役に立つと思ってます。
最終的に意思決定する際には、運用ルールが欠番無しを前提としているかどうか、顧客と事前に合意しているかどうか、プロジェクトスケジュール上議論の余地があるかどうか、といったコンテキストも、当然重要な判断材料ですよね。
今回の話だと、連番の実装方法をどうするかはともかく、出庫管理マスタの主キーを完全な通し番号が要求されている注文番号の一部に使おうとしている点は、致命傷になりかねないので、私なら、守屋くん以上に徹底抗戦しますね。
abk
連番は設計に考慮不足があることのもののたとえであって、問題の本質ではない。
いち技術に対して、ここで熱心に討論することも無いとは思いますが...
まあ話がよこみちスピンするのはいつも通りのご愛嬌というやつですか :-)
DumbObj
ちょっとマジレスし過ぎましたかね。
ただ、個人的には、よこみちスピンも、いろんな人の考え方がわかって面白いです。
回転不足の時は減点しておいてください。