やっぱり上野のシンボルはパンダなのか。
こうして外出すると見聞が広がるものだ。(´・ω・`)
超絶大規模システム
しかし、今やっているシステムって規模がもの凄くデカい。
テーブル数が１０００コくらいある。(；´・ω・`)
何でこんなにテーブル数が多いかというと、それだけ大々的に業務を行っている大企業ってことだな。
例えばさ、NTT Docomoと取引する業務があるとするでしょ？
その業務のテーブルは１００コだとする。
これだけでも十分立派なシステムだ。
しかし、そこからさらにauとも取引追加するとするでしょ？
すると、au専用テーブル＋１００個、共通管理テーブル＋２０コだよ。
更にソフトバンクとも取引を開始すると、
ソフトバンク対応テーブル＋１００個。
って感じに増えていくのを２０年３０年とやっていれば１０００コくらいになるわ。
決してＤＢ設計がカスだから１０００コもあるわけではなく、実際それだけ幅広く色々な業務に対応しているんだよね。
これだけの規模になると、要員が全容を記憶するなんて不可能。
もちろん業務をある程度の区切りで分類して、担当の範囲のみ理解するという分業制を敷くんだけど、やっぱりその「区切り」ってのは万全ではない。
「こっちの業務の為にソースを修正したらあっちの業務に影響が……」みたいなことは当然の如く起きる。
だから修正前に影響範囲を調査するんだけど、調査しようにも１０００コ全部なんて調査出来ないから、目星を立てて調べる程度が限界だ。
その後、有識者会議に進むんだけど、その有識者ってのは本当にエキスパートでなければ無理。
３０代そこそこの中堅でも分からない事が多くって、結局部長を引っ張ってくることになる。
そのシステムの仕様を最も詳しく把握しているのは部長であるという、生涯現役でよく頑張っていらっしゃる部長さんだ。
いやぁ、やっぱり大規模システムってのは難しいね。
多少スキルに自身があっても、大規模大人数の前には管理・徹底・継続が出来ないから、それが積み重なるとどうしても歪みが出てくる。
これはもう仕方が無い。
「こうすれば良いじゃん」で解決出来る問題じゃない。
そんな「歪み」と上手に付き合っていくのが僕のような業務系エンジニアの妙技よ。
ただＩＴスキルだけを磨けば務まる仕事じゃない。
ＩＴスキルは当然の嗜みとして習得しつつ、それとは別に円熟の経験で各方面の担当者と話をつけて、正解を手繰り寄せ、修正を決行する。
って、難しい過ぎるわ！！(´×ω×`)
流石の僕でも入って２ヵ月でキャッチアップし切れるもんじゃねえな。(´×ω×`)
キャッチアップには３年は必要だろう。(´×ω×`)
とは言え、分かんないなら分かんないなりの進め方もあって、例えばテーブルのカラムの意味は分かんなくても、そのカラムに一意制約があるかどうかという物理的視点で調査してそれを元に設計ミスを指摘するとかは出来るわけよ。
エキスパートの有識者ですら分からない問題が多い難しいシステムだが、ちゃんとした有識者でなければ務まらないということも無い、という何とも複雑かつ微妙に交差する様々な事象の中に大規模システムというものがある。
頑張り過ぎて疲れ果ててしまわないように息抜きもしつつ、かつ怠慢が過ぎないように身を引き締めつつ、時に戦い、時に誤魔化し、バランス良く色々な問題と向き合い付き合っていく、としか言いようが無い。
大規模システムも人生も単純に整理出来ないもんや。(´・ω・`)
0 件のコメント:
コメントを投稿