常駐先で、ORACLEデータベースの管理やってます。ORACLE Platinum10g、データベーススペシャリスト保有してます。データベースの話をメインにしたいです

【小説 演・ジニア】第六話 インフラと業務 その2

»

 プロジェクトはインフラと業務に分かれることが多い。
 インフラはセキュリティ、パフォーマンス、ネットワーク、サーバ構築、保守運用などの非機能要件を中心に担う。
 業務は要件定義、画面設計、プログラミングなどの機能要件を中心に担う。
 システムを無事に納品するという最終目的は同じなのに、業務チームとインフラチームは対立しがちである。
 大きな理由、それはアプローチの仕方が違うからだ。
 例えば、サーバ構築一つとってみてもひと悶着ある。
 インフラチームがサーバ構築するための要件を業務から聞き出す場合を例にとると--

 インフラ「接続ユーザ数はどれくらいでしょうか?」
 業務「お客さんからまだ回答が頂けてないんですよ」
 →これが分からないとメモリサイズを見積もれない。

 インフラ「バッチではどんな処理を行いますか? 処理単位は1営業所単位で行いますか? それとも全営業所をパラレルで行いますか?」
 業務「すいません。まだどんなSQLでやるかも処理方式も決まってません」
 →これが分からないとCPUの数を見積もれない。

 インフラ「各テーブルの最大件数を教えてください」
 業務「すいません。まだお客さんが何年分のデータを持つか決め切れてないみたいです」
 →これが分からないとディスクサイズを見積もれない。

 インフラ「アプリから実行されるSQLはバインド変数でお願いします」
 業務「すいません。それなんですか?」
 →データベースがORACLEの場合、運用開始後、ORA-4031多発。

 こういった情報が定まるのはだいたいプロジェクトも佳境に入った段階である。
 お客さんが中々決め切れない、チーム内での行き違いがあった、設計したけど実現不可能だったから変更するなど、事情はよく分かる。
 が、インフラチームはこの情報が無いとサーバを構築できない。
 かつ、いつまでにサーバを構築しろとスケジュールを引かれているので、それまでに構築を完了させる必要がある。
 ただ、業務チームにだって言い分もスケジュールもある。
 情報が揃っていなくても取りあえずサーバを構築してもらわないとテストが出来ない。
 そこでインフラチームは渋々サーバを作る。
 動かしてみると、やっぱり色々と足りない部分が出て来る。
 CPU、メモリ、ディスク不足。
 そういったことが起きる度に、再設計をし、サーバを止め増強する必要がある。
 作業が増えたインフラチームと、テストが滞った業務チームはこうして仲が悪くなって行くのだった。
 それは、礼奈が派遣されたプロジェクトも例外では無かった。

「うわ! 何ですか、この設計書の山!」

 土日明けに出社すると、礼奈の机の上にはテーブル設計書の束が置かれていた。

「業務チームが休み中に勝手に置いて行ったんでしょう」

 戸田良夫が呆れたように言った。
 紙束の一番上には付箋が貼られている。

<全部で20テーブル作成お願いします。月曜日中によろしく。橋本>

 と書かれている。

「これって今日中ってことですよね......。こっちだって予定があるのに......いきなりこんなに沢山のテーブル追加。さばけませんよね」
「......そうですね」
「橋本さんと話したほうがいいですね。頼まれたら何でもやるなんて思われたら、たまらないですもんね!」

 戸田良夫は何も言わなかった。
 彼にも腹に据えかねるものが有るのだろうか。

「私に任せといてくださいっ!」


---------------------------------------------------------------

 午後一時。
 会議室で、礼奈と戸田良夫は、業務チームのリーダである橋本と向かい合っていた。
 
「うちとしては、この対応をやってもらわないと明日から結合テストを始められないんですよ」

 橋本は唇を尖らせてそう言った。
 卓の上にはテーブル設計書の束が置かれている。
 戸田良夫が一枚を手に取り、こう言った。

「橋本さん、テーブルを作りたいのはやまやまですが、最大レコード件数を頂けないと作れません」
「何で?」
「最大レコード件数が無いと、テーブルサイズが見積もれないんですよ」

 テーブルサイズは最大レコード件数とレコードサイズの掛け算で、そのおおよそを求めるからだ。

「インフラチームとしてはサイズが分からないテーブルを作成することは出来ません」
「そんなの開発環境だから適当でいいよ。本番環境を作るまでには分かるからさ。それでいいだろ」

 と、橋本は業務の立場だけで主張してくる。

「作成するテーブルサイズを積算出来ておかないと、今から追加ディスクの発注が出来ないんですよ。ハードウエアの調達には時間が掛かるんです」

 作成するテーブルのサイズが分かれば、必要なディスクサイズと本数が分かる。

「こっちには関係ない。そっちの事情だろ? とりあえず開発環境だからサっと作ってくれよ」
「テストデータはどれ位をお考えで?」
「まあ、だいたい多くて1万件くらい」

 戸田良夫が電卓で計算し始めた。

「それくらいなら今の開発環境で足りそうです。が、ざっと見て新規に20テーブル作成......これを開発環境に対応するんですよね。明日まで時間をくれませんか?」
「そんなに掛からないよね? DDLなんてテーブル設計書をマクロに読み込んで作るんでしょ。あとはそれを実行するだけじゃん」
「それだけじゃないんですよ。作ったテーブルが設計書通り出来ているか確認する手間もあります」
「そんなのザっとでいいよ」
「いや、何かあったらこっちの責任になりますから」

 と、戸田良夫と橋本は押し問答のようになった。

「分かってくんないかなぁ。業務チームリーダーやってた時はもう少し物分かり良かったですよね。戸田さん」

 戸田良夫のこめかみがピクリと動いた。

「あの時はリーダーだったから、メンバーに嫌われないように気を使ってたんですか? まあ今はデータベース管理者としてインフラチームに守ってもらえるから強気で俺たちに立ち向かってるんでしょ? そりゃあないよなあ。あの時みたいに言うこと聞いてくださいよぉ」 

 いやらしいヌメヌメした笑いを浮かべ、嘲る様に橋本は嫌味を言う。
 戸田良夫のこめかみは更にピクピクと動いた。

「引継ぎも無く抜けたのは申し訳ないと思ってます。ですが、今それは関係無いでしょう」
「関係あるよ。あんたが残していったやりかけの仕事で僕は毎日、本業に手が回らないんだから」
「あの......」

 礼奈がおずおずと割り込んだ。
 さっきまでやり合っていた二人の視線が、彼女に注がれた。

「先週だって何度も私にインデックス作成を依頼して来たじゃないですか。こんなに何度も追加や変更依頼があるなんて、根本的な設計不良があると思うんですけど、そこから見直してくれませんか?」

 礼奈の指摘に、橋本は一瞬固まったがすぐにこうやり返した。

「え? うちって、そちらの作業を圧迫するほど依頼を出してたっけ?」
「出してますよ」
「証拠を見せてくださいよ」

 礼奈は無言で卓の上に一枚の用紙を置いた。

テーブル変更一覧2.png

「先月の業務チームから依頼されたテーブル変更です。少なくとも一日一回。多い日で三回はあります」
「そ、そんなにしたかなあ......?」
「してます。戸田さんが受け付けたテーブル設計書から、この一覧を作りましたから」

 卓の上にドスンと数百ページはある設計書の束を置いた。
 橋本は数秒の沈黙の後、急に笑い出した。

「ははは。こりゃすいませんね。勉強塾の社員から指摘されたら何も言えないや。......と言いたいところだけど、勉強塾さんからの要件がなかなか固まらないから、こうしてテーブル設計もブレるんですよ。そこを分かって頂きたい」

 変更依頼をこれだけしているのは自分たちのせいでは無い、ということをアピールしているかのようだ。
 その時、ガチャリと会議室の扉が開いた。

「遅れてすまん。私も参加させてもらうよ」

 花房部長はそう言うと、橋本の隣に座った。

「しかし、こりゃすごい量だな」

 卓の上に乗せられた設計書の束の上から数ページつまんで、それをペラペラめくりながらそう言った。

「橋本、まだこんなにテーブル設計に追加や変更があるのか?」
「え......ええ。まぁ......」

 橋本はしどろもどろに応えた。

「だってお前、勉強塾からの要件は先月でだいたい固まっただろ? こんなにテーブル変更があるなんてどういうことだよ?」
「いや......まぁ......」

 俯いてしまった橋本に、花房部長は諭すようにこう言った。

「業務の設計でメンバー間で行き違いがあったんだろ? 慣れないメンバーばかりで大変だとは思うけど、そういうのは抱え込まずに早く報告しろ」

 戸田良夫の表情から硬さが抜けて行った。
 反対に橋本は唇を噛んで悔しそうだ。

「戸田」
「はい」
「今回までは業務の依頼を受けてやれ」


---------------------------------------------------------------

 定時後、地下の喫茶店にて。

「花房部長、ありがとうございます」
「いえいえ、困ってる井筒さんにちょっと協力したまでだよ。しかし、色々と考えたみたいだね」
「はい。戸田さんに気に入られるためにどうしたらいいかなって考えたら、今抱えているインフラチームと業務チームの問題を解決することがベストかなと思いました」
「まぁ、そのせいで橋本がちょっと割を食ったみたいな感じになっちゃったな」

 花房部長はニヤリと笑った。
 全てはアドバイスをくれた和弘のお陰だ。
 昨日のショーも気持ちを切り替えることが出来て無事上手く行った。
 彼には今度、ステーキでもご馳走しようと思った。

「結果的に戸田さんが私に良い印象を持ってくれればそれでいいんです......よね?」

 礼奈がそう念を押すと、花房部長は無言で頷いた。

「じゃ、行ってきます」
「おいおい、もう少しゆっくりして行けよ。ケーキがまだ来てない」
「これから飲みに行くんで」

つづく

Comment(2)

コメント

VBA使い

私に良い印象を持って「く」れれば


前職でまだ経験が浅かった時に、情報系DB(Oracle)のデータ設計で、
お客様のシス担は単に元のテキストデータの1行のバイト数×件数で
「これで○○GBのディスクに入るでしょう」と言ってこられ、
それをそのまま持って帰ると、先輩に「列ヘッダなどがあるから、
サイズはもっと増えるよ」と指摘され、そのために件数が少なくなることを
先方に伝えると「今更納得できない」と言われたことがあります。
その時は、ディスクのRaid1 → 5 への変更とか、ベタで保存して
アプリで切り分ける、など焦りながらいろいろ考えたもんです。
(その後まもなく先方のシス担が変わり、その際に件数減を飲んでもらえましたが汗)

湯二

VBA使いさん。


コメントと校正ありがとうございます。


細かいこと考えると、1レコードのバイト数×レコード数ではないでしょうね。
ヘッダのサイズとか型ごとに考慮する必要あるんですよね。
で最後に、ブロックサイズで割り算して切り上げるとか。
ただ、そこまで考えて出した値で見積もりだしても、もらえるディスクが1本あたり50Gとかだったりすると、さんざん考えて出した数値が誤差みたいなもんになってしまうんですよね。
それに実際運用開始すると、見積もった件数よりもデータが全然入って来なかったりとか。


で、ある時から割り切って簡単に計算するようにして、他に時間かけるようにしました。
説明してそれでOKがもらえるプロジェクトに限りますが、そうやるようにしています。
あとはざっくり安全率1.2倍とかしてます。
あくまでプロジェクトのやり方で変えてはいます。

>シス担が変わり

担当が変わって、同じことでも楽になったりしんどくなったり、ほんと、良くありますよね。

コメントを投稿する