東京生まれ, ラップトップ育ち

テーブル定義とは、デッサンである

データベース設計の中でも、テーブル定義は奥が深い。
よほど素質がある人じゃなければ、習熟には経験が必要だ。

若い頃、僕はテーブル定義が苦手だった。
設計をした後、見返してみてもいまいちそれが正解だと言い切れない、そういう感覚があった。

そうして定義されたテーブルは、時間を置いてみてみても、すっと頭に入ってこない。
定義書を見ないとテーブル定義が思い出せない。

そういうテーブル定義を渡すと、プログラマも混乱しがちだった。

これは、そのテーブル定義が自然じゃないから、だと僕は考えている。

僕に指導されている人はよく聞いていると思うけど、テーブル定義の肝は、いかに事実を正しくデッサンするか、だ。

テーブルはプログラムの変数の置き場じゃない（※）。
たとえばそれが業務システムの中核をなすデータベースなら、業務の動きとデータを、事実をじっと見つめて、自然な形で書き出すことが大事だ。

経験がないと、どうもこれができない。
画面のレイアウトや帳票フォーマット、機能ギミックを考えながらテーブル定義をしてしまいがちなのだ。

画面なんか、どうでもいい。
そんなもん後で考えろ。

すべてのテーブルが、事実と照らして自然かどうか。
これができていないと、後からの仕様変更や機能追加に対して目も当てられない弱さを露呈する。

抽象的な話になってしまったので、少し具体的に。

たとえば”お客様”から”注文”を受ける業務があるとする。
テーブル定義をするとこんな感じのテーブル（エンティティ）を定義するはずだ。
・お客様
・注文（注文日時、お客様ID、お届け先、合計金額、消費税 etc...）
・注文詳細（注文商品、数量、金額）

ここまでは単純な正規化だけでできるので、迷う人は少ない。
だが、あとからクライアントが次のような要望を出してきたらどうだろう。

「注文するお客様の中には卸業者さんがいて、1回の注文で、同じ注文内容で複数のお届け先を簡単に指定できるようにしてほしい」

・・・この話を受けて、まず画面を考えたりしてないだろうか？注文内容確認画面で、配送先編集画面に”配送先を追加する”みたいなボタンを付けて・・・なんて。

そんなのはどうとでもなるので、まずはテーブル定義をどうすべきかを真剣に考えよう。
過去に、このようにテーブル定義をしているケースを実際に見た。

・お客様
・注文
・注文詳細
・同時お届け先

同時お届け先とは、画面で指摘できる第2第3のお届け先だ。

・・・不自然過ぎる。
現在のプログラムをあまり変えないで、あらたに付加したテーブルだけで気軽に帳尻を合わせようとしている設計者の短絡さが伺える。

このテーブル定義の何が悪いのか、とりあえず2つ上げてみる。
- 1. いくら商品構成内容が同じでも、複数のお届け先があるということは、その数だけの複数の別々の”注文”なのだ。それをデッサンできていない。
- 2. 一つ目のお届け先と、2つ目以降のお届け先が別のエンティティになっている。注文者の思惑として指定順になにか意図があったとしても、同一エンティティとすべきなことは疑いようもない。

２もかなーり気持ち悪いが、なにより１が重罪だ。
こんな付け焼き刃テーブルを定義したせいで、”注文件数＝注文エンティティのレコード数”という、ごくシンプルで自然な正義が崩壊してしまった。売上を計上するにも、注文エンティティではなく同時お届け先エンティティに注目しないといけなくなった。
非常に不自然だ。

画面に引っ張られている、もしくはテーブル定義を簡単に済ませようとしている。

この場合正しいテーブル定義はこうだ。

・お客様
・注文
・注文詳細

そう。何も変わっていない。
卸業者なり誰かなりが複数のお届け先を画面で指定できたとしても、データベースは厳然として複数の注文として保存する。

「いやいや、卸業者から見たら1回の注文で5件に配送した、そういうふうに見せる必要があるんですよ！」

もしそう言ってきたとしても、おちつけ。それ、画面の話だろ。
複数の注文をグルーピングすればいいだけだ。
そのグルーピングがエンティティとして重要なのであれば、
・一括配送依頼
などとして、そのidなり依頼番号なりを関連する注文エンティティにもたせてやれ。

画面上の表現なんかのために、エンティティの自然な正義を壊してはいけないんだ。

仕様変更をものともしない、柔軟なシステム設計。
その足腰は、事実を正しくデッサンしたテーブル定義にのみ宿る。

※パフォーマンスチューニングのためのデータベース拡張は、応用の話として別と考えてます。今回はあくまで、必ず抑えておくべき基本の話ってことで。

Skills(結)

遠い昔の、あの沖縄の夜を思い出しながら。
僕はいま、三線の鳴り響く南国とはまったく無縁の、東京コンクリートジャングルにいる。
東京の暑さは、今年も例年と変わらず、全く異常だ。

そういえば一昨年、仕事でひさしぶりに沖縄に行った。
それが、実におよそ15年ぶりの沖縄だった。

あの夜から、もうすぐ20年が経つ。
「俺はスキルしか売らない。だけどお前らは、忠誠心を売って金をもらうんだ！」

自身の若き咆哮は、今もまだ脳裏でこだましている。
こうして20年経った今。僕はその叫び声の延長線にいて、ちゃんとスキルを売る仕事をできているだろうか。
そして本当に、忠誠心は売ってはならないものなのだろうか。

そんなことを考えていた。

プラムザという会社で管理職の番台に上がりながら、現場のエンジニアを見ていてふと思う。

スキルがあるというだけで、それを一方的に売ることなんて、できやしない。
忠誠心という言葉には語弊はあるけど、誰かの役に立ちたい、いうなれば「誠意」があるからこそ、そのスキルに買い手がつくんじゃないか。

僕は今、プラムザのエンジニアのひとりひとりから、そのことを教えてもらっている気がする。

あのあとM弓は商社マンと付き合いだした。
そのままその彼と結婚して、3人の子供の母親になったそうだ。

M弓に、暑中見舞いでも出そうかな。
そう思って思いとどまり、かわりにこの駄文を書いてみた。

-了-

Skills(4)

「全員、就職決まってよかったよね」
2回目の乾杯の後、M弓が店員からゴーヤのチャンプルー的なものを受け取りながらみなに言った。
「ソレニシテモ、オレタチのゼミカラ、スッチーガフタリモデルッテ、マジスゲェヨ」
「結局、金融パートの奴らはほとんど、銀行だったな。」
「あと多いのは、やっぱ商社か。」
「変わり種でひとり官僚もいるな。」
二次会に参加した面々8名ほどで、卒業後のみんなの進路について語り合っていた。
「しかし、我らがゼミ代がシステムエンジニアになるとはなぁ。」
「コンピューター素人のくせにな。」
「そこそこ、うるさいよ。」
そうなのだ。
僕は、今度の春からシステムインテグレーターの企業に就職することが決まっていた。どうしてもシステムエンジニアになりたかった僕は、この夜もひとり得意の絶頂にいた。

スキルを身につけ、手に職を。
それが僕のキャリアプランで、システムエンジニアこそがこれからの時代に最も必要とされる技術職だと信じた上の帰着点だった。

南国にいるという開放感からなのか、それともそれが泡盛だからなのか。
酒が進むうち、なんだか場が荒れてきた。
最初はほんの冗談という感じだったが、次第にそれぞれの進路のネガティブな側面を言い合う形になってきたのだ。

商社マンと銀行マン、どちらが上か。そんな、今思えば他愛のない話だった。商社なんて響きはいいけどどこに飛ばされるかわかったもんじゃない、とか、銀行なんて寮に鮨詰めにされて給料を引き出すことも出来ない、とか。
システムエンジニアという仕事にある意味心酔しきっていた僕は、そんな話を聞いていて、苛立ちを抑えられなかった。

つまり、その商社マンと銀行マンの戦いに、システムエンジニアとして割り込んでしまったのだ。

「俺はスキルしか売らない。だけどお前らは、忠誠心を売って金をもらうんだ！」

その後に何を言ったのかは、もう思い出せない。

一つ確かなことは、この夜、僕は銀行マンと商社マンを敵に回したということだ。
外資系銀行に就職するM弓も含めて。

(結びへ続く)

Skills(3)

昨夜は、そうだ。
現地のR大学とのディベートの後に、教授に連れられてみんなで夕食をしにいった。
分厚いのにやわらかい、絶品ステーキで有名なダイニングレストランだった。

脂がのっているのにすっきりしたステーキの味わい。それと、重厚な木のテーブルを囲む、和気あいあいとしたみんなの表情が思い出せる。
その中で、いつものように調子に乗って軽口を叩いている僕も、しっかりと覚えている。特段、なんにも不穏なことは起こらなかったはずだ。

その後は、そうだ、有志だけでどこかの店に２次会に行った。
どんな店だったか、思い出せない。畳があったような気もするから、和造りの居酒屋だった気もする。

泡盛をたくさん飲んだことは、身体だけじゃなく記憶のイメージにもはっきりと残っている。
どんな雰囲気だったか・・・。

（俺は・・・しか売らない。だけどお前らは・・・）

二日酔いでズキズキと痛む頭のなかで、誰かの声がこだまする。

これは、、、、僕の声だ。
随分と興奮した声だ。なんて言っているのか。

僕はまぶたを閉じで、まっくらな頭の中に反響する怒鳴り声に、耳を傾けた。
すると。

「俺はスキルしか売らない。だけどお前らは、忠誠心を売って金をもらうんだ！」

真っ暗だった頭の中にぱっと電灯がつき、昨夜の居酒屋での、あのギスギスした時間が映し出された。

（続く）

Skills(2)

M弓は僕の問いかけを無視して、女友達の座るテーブルの方へ行ってしまった。
「ちぇっ、なんだってんだよ。」
二日酔いの不快感も手伝って、僕は軽く舌打ちをした。

ちょうどその時、僕と同じく四年のタクが俺の前を通り過ぎようとしたので、声をかけてみた。
「なぁ、タク・・・」
「アア、ナンダーヨ？」
ゼミの中じゃ一番仲のいい男だけに、予想と違う冷たい反応を返されて僕はすこし動揺した。
「いや、俺さ、昨夜なにか変なことしたっけ？」

一瞬の沈黙の後、タクはため息とともに言った。
「ソンナコトモ？ナンデワスレテシマウデスカ、アーナタワァ」

明らかな侮蔑の気持ちが、そう言うタクの瞳に灯っているのを感じた。

一体昨夜、僕は何をしたというのか。

(続く)

Skills(1)

199X年、大学四年の夏。
僕はゼミの沖縄合宿に来ていた。
合宿といっても名ばかりで、実際のところは要するにバカンスだ。

前日夜にしこたま泡盛を飲んで酔いつぶれた僕は、爽やかな明るい朝のテラスカフェに似つかわしくない、二日酔いの体たらくをさらしていた。

この合宿の参加者の中には、同じゼミで同学年の彼女、M弓がいる。
そのM弓が、ホテルの白い階段を降りてきた。黄色いアンサンブルがよく似合っている。
「よぉ、M弓」
だるそうな格好のまま、僕はM弓を見つけて声をかけた。

「・・・知らない。」

普段はとても優しいM弓なのに、今朝はなんだかとても機嫌が悪い。昨夜、なんかあったっけ。
情けないことに、昨夜も僕の海馬は機能を停止していたようで、いっこうに思い出せない。

「なぁ、なんだよ。俺がなんかした？」

(続く)

責任(エピローグ)

今にして思えば。
閉塞的で暗鬱たるあの頃の毎日に、足りていなかったものは、クリエイティビティだけじゃなかった。

責任感だ。

沈むことが定められた船を、沈めないようにする。
それは、途方もなくクリエイティビティの必要なミッションだ。

強い責任意識を持ってその任に当たるならば、そこには大きなやりがいだって生まれていたはずだ。

２５歳の僕には、それだけの能力がなかった。
発想力がなかった。
経験がなかった。
自信がなかった。

なにより、責任感がなかった。
僕の前に辞職した６人のPMがそうだったように。

こないだの日曜日、今度小学生になる長男と梅の花が咲いているのを見つけた。
システムエンジニアになって、19回目の春だ。
つまり、あの課長に辞表を渡してから、15年が経ったということになる。

当時と今の自分を比べるべくもない。
今だからわかることは、当時の僕にはわからないことばかりだ。

それでもあの会社をやめたことは、一つの正解だったと思う。
当時の彼女と酒を飲むことがあるが、よくこんな話をされる（※1）。

あの頃の僕は、毎日毎日、数分後に死にそうな顔をしていた、と。
そういえば、朝のホームで、疲労で足元をふらつかせ、危うく線路に転落しそうになったこともあった。どこかに、無理があったのは確かだ（※2）。

幸せなことに、僕はその次に入社した会社、つまりこのプラムザで、今日に至るまでクリエイティブな仕事をやらせてもらっている。
もやがかっていてはっきりと見えていなかった技術の世界は、今は格段にくっきりと見えている。

でも、心にはずっと十字架を背負ってきた。
責任を放棄してプロジェクトから逃走したという、恥じるべき歴史だ。

しかし、だからこそかえって、今日に至るまでの僕は、”責任感”を大切にすることができた。

覚悟を決め責任を持って挑めば、どんな難しそうな問題でも必ず解決できることを知った。逆に、覚悟を決めず無責任に構えれば、かえって怪我をすることを、体はしっかりと覚えていた。

そういえば前の会社で、僕は先輩や上司たちから、”茶坊主”と呼ばれていた。
由来は、ひょうひょうとしていてとらえどころがなく・・・いや、単に坊主頭だったからだろう。

茶坊主はその坊主頭をなびかせて、プラムザに入社した。
その後、プラムザ内で僕についたあだ名は、茶坊主とはまるで真逆のものだった。

了

※1 当時の彼女とは、今の奥さんです
※2 無理があったのは、昼はサラリーマン、夜はラッパーだったからという説が有力ですが、本稿では著者の恣意により触れていません

責任(後編[4])

ベッドに入っている間だけ、僕は悪夢を見ずにすんだ。
そんなK事業部時代、僕の暗鬱たる毎日にはなにかが欠落していた。

ある夜、僕はその答えに気がついてしまった。
僕の毎日に足りていないもの、それはクリエイティビティだった。

与えられた業務を淡々とこなすだけのほうが楽だし好きだという人は多い。一つの生き方としてそれを否定することは出来ないが、すくなくとも僕はそうじゃなかった。

日々の創意工夫をこらして、自分の能力を存分に活用できる仕事。僕は、そんな仕事が好きだった。
効率的を越えて、効果的に仕事をすることの楽しさを求めていたのだ。
S事業部では、少なからずそういう仕事を任せてもらえていた。

広いオフィスを端から端まで探っても、K事業部にはそういうクリエイティブな仕事がない。僕は自身の胸の内で、そう固く結論づけた。

いつか自分がなりたい背中が、この事業部にはなかった。
そうして僕の瞳には、ある決意が宿るようになった。

小路の梅の匂いが鼻をくすぐる、うららかな小春日和に。

僕は課長のだらしなく丸まった猫背を呼び止めて、そのまま辞表をつきつけた。
要約するならば、「自分の評価が下がるから思いとどまってくれ」、と涙目で訴えるその中年のしまりのない顔を見て、25歳の僕はひどく滑稽で哀れだなと思ったような気がする。

僕はそうして、どうしても入りたかったその会社を結局は自らの意志で飛び出した。
2002年の春だった。

（エピローグへ続く）

責任(後編[3])

K事業部の朝は早く、夜は遅かった。
ちなみにK事業部のKとはすなわち金融のKなのだが、クライアントである銀行の業務が行われている時間帯にシステムを触ることは一切許されない。簡単なリリース作業であっても、その実施は朝5時から朝6時までを厳守するよう定められていた。

朝5時前、人気の全くない薄暗い大手町の駅階段を登る。間もなく現れる威圧的な銀行本店ビルの裏に回り、非常通用門を通ってシステム室に通いつめた。どうしても明るい気分になれなかった。
リリース作業完了後の、行員食堂で飲んだあのコーヒーの味がどうしても思い出せない。

一方、夜が遅いのは、前にも触れたとおりだがダラダラと仕事をする事業部文化のせいだ。
営業や開発チームのメンバーが集まって行う打ち合わせは、決まって夕食後の20時以降だった。
帰宅が22時より前なら、その日は相当にラッキーである。

肝心の業務内容も、予想していたとおりとは言え、私にとっては忍耐を強いるものだらけだった。

まず、日本語力・技術力ともに低そうな人間が書いた、半分はページ稼ぎで占められた分厚い仕様書を理解しないといけない。しかもその大前提として、さらに分厚い金融業務の専門書の内容を理解している必要があった。

そうしてやっとのことで理解した仕様書に、顧客の要望を反映して修正する。
承認枠が多いわりにおざなりな各上長のレビューを通過したその仕様書を携え、私は下のフロアに出向く。

下のフロアには、様々な企業から派遣され常駐しているプログラマたちがひしめき合うように机を並べていた。
その中でちょこんと座って黙々とコーディングをする、小柄なチーフプログラマとのやり取りが、私の任務の一つだった。
「すいません、おまたせしちゃって。こないだお話した件の仕様書、持ってきました。」
30過ぎのチーフプログラマは、眼鏡の奥で鈍く眼光を灯らせながら、立場上クライアントである若造に気を遣いながら応対する。
「ありがとうございます、頂戴しますね。工数見積は今週中くらいでよいですか？」
そう言う彼の背後で黙々とコーディングをしながら、こちらの言動を窺っているチームメンバーの面々も、いずれも私よりずっと年上だった。
「毎度すいません、お見積今日中にほしいんです。」
一日の中で、なんど謝るのだろう。
上のフロアに引き上げていく私の背中には、射るような視線が何本も突き刺さってる気がした。

この時期、私は1行としてソースを読んだ記憶がない。
外注のチーフプログラマーに要望を伝え、そこからヒアリングした所要工数をベースに2.5倍した機械的な見積書をクライアントに提示する。
クライアントから不具合や障害の指摘があれば、それをそのまま下のフロアに伝えに行く。
テスト設計こそ行うが、そのテスト自体はアルバイトメンバーに指示してやらせる。

S事業部時代、私の名刺の肩書はシステムエンジニアだった。異動後、K事業部の私の机の上に置かれた名刺には、大仰にも”金融システムコンサルタント”と書かれていた。

しかしその仕事内容は、ほとんどガキの使いと変わらない。
会社の看板と、一夜漬けの金融業務知識だけで、かろうじてその存在を誇示している。

もちろん、そんな風に思ってしまうのは、私がまだまだ経験の足りない若手だからなのかな、とも考えた。
しかし、同じ課の先輩たちもまた同じような存在でしかなかった。
むしろ、年数とともにそのうすっぺらい役割に慣れきってしまい、卑屈になったり傲慢になったり、独自の進化を遂げている異形体のような人間も少なくなかった。

僕たちは、スキル的にシステムエンジニアと名乗れないから、そして、事業部の採算都合で単価を釣り上げるために、絢爛たる肩書”システムコンサルタント”を名乗っているのだろうか？
どうしてもネガティブに捉えてしまう。

とにかく私のポジションはプロジェクトマネージャーだった。
ソースに触れるどころか読むことすらもない。つぎはぎだらけの設計書は、いまだ理解しきれない、矛盾のように感じる箇所も少なくない。プログラマの操っている技術のことも、なにひとつ理解していない。

・・・この船、そのうち沈むんじゃないか。

プロジェクトマネージャーとは要するに、一朝そのプロジェクトでトラブルが発生したならば、腰を据えて全力対処し、過失があればその責任を一身でかぶるべきポジションだ。
だが、「全員辞めた」という前任者6名は、いずれも引責で辞職したわけではない。プロジェクトマネージャーとしての役割を全うすることなく、そして今回の私に対してもそうだったように、引き継ぎすら行わず放棄してきたのだ。
そうして残されたこのプロジェクトは、まるで少しずつ朽ちて沈みゆく船のように、ただただ漂流しているのだ。

針路もわからぬまま船に揺られる毎日の中で、自分が取るべき航路はこの海では一生見つからないんじゃないかと考えるようになっていった。

責任(後編[2])

入社して2年目の冬。
私は開発チーム付きのインフラエンジニアとして、netscape Application Serverを軸としたWebアプリケーションのインフラ設計、運用設計を行っていた。そんな冬の、まもなく新春を迎えようとしていたある日。

S事業部の事業部長が交代するというニュースが飛び込んできた。部内の情報筋によれば、派閥抗争の末の政変だったそうだ。
もともと派閥に興味がなかった自分には、さほど関心のない話だった。

しかし、続けて伝えられた情報に私は自分の耳を疑ってしまった。
驚くべきことに、私は敗れた派閥の一員であり、排斥は免れられないだろうと知らされたのだ。

1ヶ月もしない内にに通達された人事の内容は、大方の予想通りだった。
敗れた派閥のメンバーはS事業部から一掃され、私もその対象だった。

一枚岩よろしくいきいきと働いているように見えたS事業部も、上層部では大人たちの肚を見せない権力争いがあったのだ。
私は言いようのない脱力感に打ちのめされてしまった。

新しく下された辞令もまた私にとっては無情なもので、転属先はあの忌むべきK事業部だった。
そちらの部長に乞われての配置と言い添えられたが、とてもそれを信じるような気分にはなれなかった。

正直なところ、しばらくの間は失望感に嘆いていた記憶がある。
しかし、これもまた会社人の宿命であると己を納得させ、転属初日までには気持ちを一から作り直した。

そうして迎えた転属の初日、埃の積もったビー玉のような目をした男がやってきて、私の新しい上司だと告げた。
そして、続けざまに伝えたのだ。
「今日からお前、プロジェクトマネージャーな。」

プロジェクトマネージャー。
S事業部時代、自分がプロジェクトマネージャーになるのはまだまだ数年先だと思っていた。
実際、S事業部では最も若いプロジェクトマネージャーでも26歳だったからだ。

当時の私は24歳だった。
私にそんな役割が務まるか。具体的な方法論など教わっていないし、そのための研修カリキュラムも用意されていないようだった。

その日の夕方。
同じ課の先輩にあたる男が、不気味な笑みを浮かべながらなにかとても面白いことのように、耳打ちで教えてくれた。
「お前が引き継いだプロジェクトだけどさ・・・、これまで歴代のPM、6人全員が会社を辞めてるんだぜ」

私がその会社を去るまでの、カウントダウンがゆっくりと始まった。