ふつーのプログラマです。主に企業内Webシステムの要件定義から保守まで何でもやってる、ふつーのプログラマです。

冷たい方程式(2) まだ基本設計書じゃない

»

 他の会社はどうかしらないが、モリシタ精機では「社内SE」は、「IT関係の何でも屋さん」と同義語である。組織上は、開発グループ、インフラグループと別れていても、その境界は実のところ曖昧そのもの。

 開発グループも「開発」とは関係ない業務に駆り出されることの方が多い。PCやプリンタの設置、Officeソフトやメールクライアント、アンチウィルスソフトなどのインストール、バージョンアップや使い方の説明、プリンタドライバの設定、共有フォルダへのアクセス権の設定、入社/異動/退職にともなうユーザ情報の保守などなど、やることはうんざりするぐらいたくさんある。

 開発グループ本来の仕事であるはずの、社内の業務システムの開発や保守は、トラブル対応を別にすると急務ではないので、「何でも屋さん業務」の合間を縫ってを行うことになる。もっとも、業務システムといっても、新規のシステム開発などはほとんどなく、あっても「歓送迎会の出欠システム」とか「忘年会恒例、抽選システム」とか、PHPなどで数日を費やせばできてしまうような使い捨てシステムばかりだった。

 入社して3年。その間にあたしが新規作成した一番大きなシステムは「全社員通勤経路検索システム」だった。その名の通り、誰がどの路線で通勤しているかを検索できるシステムだ。何のためにこんなものが必要なのかというと、大きな声では言えないが、社員間で通勤定期を貸し借りするためなのだ。社員が外出するときの交通費を少しでも抑制しようという、あまりにもけちくさい目的を知ったときはあきれて言葉が出なかった。もちろん通勤定期の貸し借りは違法なので、会社としては公然と勧めているわけではない。

 そういうシステムは期限はあってないようなものだし、バグで落ちてしまったとしても文句を言う人は少ないので、緊張感がないにもほどがある。のんびりしているのはいいのだけど、このところあたしは、ちょっとした焦りを感じ始めていた。

 ――このままだと、プログラミングのスキルが錆び付いちゃうんじゃないかなあ

 そんな時、勤怠管理システムのリプレースの稟議が通り、開発メンバーに選ばれた。久しぶりのまともな業務システム開発。前の会社では、大きなプロジェクトの歯車の1つでしかなかったから、一から1つのシステムを構築していくという役を与えられて、「エンジニア冥利に尽きるってもんだぜ」と興奮したものだ。同じくプロジェクトメンバーとなった亀井くんも、同じ思いらしかった。

 「なんか一気にモチベーション上がりますねえ」

 あたしのようなSIerからの転職組がほとんどを占める開発グループのメンバーの中で、亀井くんは唯一の新卒採用だった。学生時代にコンピュータ関係のサークルに所属していて、学園祭では占いプログラムとかを作っていたらしい。色白の小太りで、運動不足なのか、たまにPCなどを運んで階段を上っていると、荒い息をついていたりする。JavaもPHPも、サークル時代に独学で勉強したとのことで、開発グループに配属されたのも、その経験を買われたということだろう。

 磯貝課長を交えて、3人で分担を相談した結果、あたしが業務系を、亀井くんは管理系をそれぞれ担当することにした。ただし、属人化を避けるため、亀井くんも業務系の打ち合わせには参加してもらい、逆にあたしも管理系の設計には参加する。

 「で、ぼくは何をすればいいかなあ」

 のんきな口調で磯貝課長が聞いてきた。あたしは、実装以外の雑用全部、とは言わず、できるだけ穏やかに答えた。

 「サーバの手配お願いします。それから、全体のスケジュール管理とか、そういうのを」

 要件定義はゴールデンウィーク明けから開始し、週に一度のペースで人事部や現場の事務担当者と打ち合わせを重ねてきた。もっとも、刷り込まれてしまったのんびり感からは、なかなか脱却することができず、これまでは比較的、ゆったりしたペースでしか進めてこなかった。「まだまだ先は長い」と楽観的に考えていたこともあったし、相変わらず「何でも屋さん業務」に時間を割かなければならなかったためでもある。

 そんな怠惰な毎日は、7月第2週に具体的に外注先が決まったことで一変した。それまでは、どことなく希薄だった現実に、シャープネスが適用されたようなものだ。

 まず磯貝課長の音頭により、サーバ類の手配が行われた。あたしと亀井くんで決めた必要なスペックを参考に、インフラグループが機種選定し、数社から相見積を取って、価格交渉を行った結果、F通のラックサーバ4台の発注が決まった。うち3台が、本番環境用で、Xeon5560プロセッサ×4、12GBメモリ、RAID5で合計2TBのHDD、冗長化電源とまずまずの性能だ。それぞれにAPCのSmart-UPSが接続される。1台がアプリケーションサーバ、2台がDBサーバだ。データベースはOracle Standard Edition。本当ならEnterprise Edition にしたいところだったが、予算を完全にオーバーしてしまうので諦めた。

 残りの1台はファイルサーバも兼ねたテスト用サーバで、ややスペックを落としてある。他のサーバの発注は下期に入ってだけど、テストサーバだけは来月には納品される予定だ。これには、とりあえずOracle  Express Edition をインストールしておくことになった。いずれ、Standard Edition One に載せ替える予定。

 サーバ用のOSとしては、Red Hat Enterprise Linux 6.1が選択された。インフラグループはWindows系OSを推してきたが、なんとか拒否した。あたしも亀井くんも、どちらかといえばLinuxの方が慣れているからだ。

 並行してあたしが取りかかったのは、ホライゾンシステム決定の妥当性を説明する資料の作成だった。

 あたしたちがホライゾンシステムに決定しても、最終的には経営戦略本部の承認を得る必要がある。よほどのブラック企業でもない限りは、最終的には承認されるのだろうけど、新規の取引先が経営戦略本部と経理部、それに法務部によるチェックをパスするには、それなりに面倒な形式を要求される。現場のエンジニアからするとバカバカしい限りだが、会社というのは、そういうものだから仕方がない。そういう部分で手を抜くと、問題が発生したときに責任を取らされることになる。

 あたしは面倒なことはできるだけ磯貝課長に押しつけてしまったので、本社へ何度も足を運んで、役員相手に説明を繰り返すという無駄な時間を過ごすことはなかった。その代わり……

 「その代わり、説明資料は日比野くん、作ってね」磯貝課長は当然のように告げた。「費用的な面なら、ぼく1人でも何とかなるけど、技術的要素については、それなりの裏付けをでっち上げる必要があるでしょ。そんなの、ぼくには無理だからさ」

 ほとんどの役員にはシステム開発経験などないので、根拠の是非を判断することなどできないだろうが、だからといって適当な技術用語を並べておしまい、というわけにはいかない。万が一、資料に記載されている単語を「ちょっとググってみるか」などと思いつくことも、ないとは言えない。

 本音を言えば、「実際にやらせてみないと技術力の判定などできないので、金額面だけで決定しました」と正直に書いて終わりにしたいところだ。が、実行したら選定自体が白紙に戻されかねない。ボーナス査定への悪影響は言うに及ばずだ。

 「わかりました」あたしは諦めて了承した。「作ります」

 「よろしくね。あ、それから、資料できたらぼくにきちんと説明してね。役員の人たちに突っ込まれて答えられなかったら、次は日比野くんが呼び出されることになるよ」

 「……」

 十分にあり得る話だ。あたしは久しぶりに残業をして、説明資料を作成し、磯貝課長にレクチャーし、修正し、課長用のカンペまで作った。ようやく磯貝課長が説明できる自信を付けてくれたのは7月20日。役員のアポを取り、課長が説明に出かけていったのは7月25日。そして、7月31日、ホライゾンシステムが正式に外注先として承認され、取引先コードが経理システムに登録された。

 ほっと一息つけたのは束の間だった。その翌日、ホライゾンシステムの八木社長から電話がかかってきた。八木社長は、正式受注の礼を何度も述べた後、あたしが聞きたくなかったことを言った。

 『それで、10月1日から実装を開始するにあたって、いろいろ詳細を打ち合わせする必要があると思うのですが』

 「確かにそうですね」

 『近いうちに、一度、打ち合わせのお時間をいただけないでしょうか。正確な本数なども知りたいですしね』

 「本数ですか……」

 実のところ、この正確な本数というのがまだ固まってはいなかった。管理系は亀井くんの担当ということで、テーブルの設計を任せてあるのだけど、これまで使い捨てシステムばかり作らされたせいか、いまひとつ勝手がわからないようで、進捗が芳しくなかった。

 一例が部門マスタの設計だった。モリシタ精機の組織は、本部→部→課→グループという階層が基本になっている。それを素直に解釈しすぎた亀井くんが最初に設計したのは、それぞれの階層を別々のテーブルに分ける、という間抜けな構造だった。

Er1

 「ねえ、これ、社員マスタとはどう関連づけるの?」

 あたしの質問に、亀井くんは意外そうな顔で、

 「本部ID、部ID、課ID、グループIDを持たせればいいんじゃないですか?」と答えた。

 ――そりゃ、それでも機能はするだろうけどさ

 「もし、将来、室とかできたら?」

 「室マスタを作って……」

 「社員マスタに室IDを増やす?」あたしは途中からセリフを横取りした。

 「そうです」亀井くんは不安そうな顔をした。「変ですか?」

 「変というか、ムダでしょ」あたしは指摘した。「そもそもだけど、課マスタに部ID持ってるのはなぜ?」

 「その課がどの部の下になるのかを示すためですけど……」

 「うちの課はどうなるのよ」

 「え? あ!」

 亀井くんは愕然となった。ITマネジメント課の上位部門が、部ではなく、経営戦略本部であることに今更ながら気付いたようだ。

 「どうしましょう……」

 途方に暮れた亀井くんに、あたしは、単に部門マスタを1つ作って、単に上位部門IDを持たせればいい、裏紙に構造を走り書きした。

Er2_2

 「あー、なるほど!」亀井くんは、あたしを尊敬のまなざしで見た。「気付きませんでした」

 ――気付けよ

 「職位も同じ要領でね」あたしは念のために言った。「間違っても、部長マスタとか、課長マスタとか作らないで」

 亀井くんがひきつった笑いを浮かべて目をそらしたところを見ると、すでにそのような設計をしたらしい。

 いっそ、あたしが少なくともテーブル設計までは全部やった方がいいんじゃないか、とも思ったものの、磯貝課長に却下された。

 「日比野くんが全部やっちゃうとさ、彼の経験値にならないじゃない。できるだけ任せてやってくれないかな」

 「……わかりました」

 すべて内製で作る業務システムなら、笑い話で済むところだけど、マスタの数によって、ホライゾンシステムに発注する画面数が決まってくるので、亀井くんの成長を待ってばかりもいられない。確実に決定した分から、随時出していくという手もあるけど、それでは先方も開発計画が立てづらいだろうし。

 結局、亀井くんにあと少しだけ時間を与えることにした。ホライゾンシステムさんが実装を開始するのは、10月1日からの予定なので、まだまだ余裕がある、と考えていたのだ。そのため、八木社長からの電話の時点で、テーブル設計書は、決定箇所より未定箇所の方が多いぐらいで、必然的に管理系の画面一覧も空白行ばかりだった。これでは、基本設計書とはいえない。

 「……申し訳ないですが、まだちょっと本数が決まらなくて」あたしは八木社長に謝った。「まだ基本設計をやっている段階なので」

 『ははあ、そうですか』八木社長は困ったような声で答えた。『いえね、そろそろ、10月からの人員をアサインしておきたいんですよ』

 「え、まだ8月なのに、もう10月の人員の確保ですか?」あたしは少し驚いた。「他のお仕事とか……」

 『ええ、今は今でやってるんですが、今のうちにアサインしとかないと、飛び込みで入ってきた仕事に取られてしまうかもしれないので』

 アサインするためには、開発の詳細な情報が欲しい、ということは理解できた。理解できたけど、画面数が決定するのは、もう少し先になりそうだ。穴が空くほどER図を凝視している亀井くんを見ている限りでは、そう判断せざるを得ない。

 「とりあえず、フレームワークとかコーディングルールとかの説明だけでいいでしょうか」

 『そうですね。それも片寄が知りたがっているんですが……』八木社長は少し迷っているようだったが、すぐに答えた。『では、来週あたり、片寄と伺ってよろしいでしょうか』

 「わかりました。じゃあ、日程の候補日は、メールで連絡させていただきますね」

 『はい、お待ちしております』電話の向こうで八木社長がお辞儀をしている姿が目に浮かぶ。『できれば、だいたいの本数だけでも、そのときにわかっていると助かるのですが』

 「……努力してみます」

 受話器を置いたあたしは、ヒマそうに『WEB+DB PRESS』のバックナンバーを読んでいる磯貝課長に、次回の打ち合わせの件を報告した。同席してくれるなら、都合の悪い日時を確認しておこうと思ったのだけど、

 「あ、そう。まあ、ぼくが出る必要もないと思うから、日比野くん、よろしくお願いね」

 と言われただけだった。

 まあ、これぐらいは予想していたので、失望したりはしない。あたしが課長にお願いしたかったのは、しばらくの間だけでも、あたしと亀井くんを「何でも屋さん業務」から免除してもらうことだ。特に亀井くんは若い男子なので、力仕事などに、あたし以上に駆り出されている。それも設計が進まない要因の1つとなっていた。

 「それもそうだね。わかった。ぼくからインフラグループに通知しておくから、日比野くんたちは開発の方に専念していいよ」

 通知されたインフラグループのメンバーたちも、渋々ながら了解してくれた。インフラグループGLの安藤さんなどは、残念そうに言った。

 「今週末、古いUPSを20台ほど廃棄処分にするんで、人手が欲しかったんだけどな。あれは重いから」

 ――そんな仕事をかよわい女性に振るなよ

 とにかく環境は整った。あたしと亀井くんは、それからの1週間を、基本設計書作成に集中することができた。

 (続く)

 この物語はフィクションです。実在する団体名、個人とは一切関係ありません。また、特定の技術・製品の優位性などを主張するものではありません。

Comment(8)

コメント

sa

まだまだ助走ってとこですかね。

この先どうなるか、月曜日が楽しみです。

ハムレット

あららん、要求定義を十分にまとめず、業務領域の分析から概念モデルも作成せずに、いきなりDB設計って、・・・・まずいんじゃない・・・

後で業務フローがスムーズに進まなかったり、性能劣化がすぐ露わになったり、つぎはぎだらけのシステムになる予感。・・・・

くくな

要件定義は5月からやってると、あるので、それなりにまとまってきてはいるんじゃないでしょうか。
内製なので、それほど厳密にする必要もなさそうだし。

elseorand

「テーブル数が減るから」だとか「工数が減るから」だとかで、
考えずに設計しだしている臭いが・・・・

しかもマスタメンテが外注ということは、
このテーブル構成を扱えるか保証もないのに。

へろへろ

サーバ構成がAP1台にDBが2台? OracleだしRACでも組むんだろうか(の、割にはストレージ類がないけど)
それとも、勤怠管理システムといいつつバックに巨大な別処理を抱え込むのか?

部とか課に例外的な属性が増えたらどうするんだろう。
社員マスタ修正するより複雑でしょうに。

nrt

煤さん:

そういう場合は、部に特有の属性を格納するテーブルを定義して、部門レコードに関連付けるのが一般的な手法ではないでしょうか。

個人投資家

既存の勤退システムのDB構成を分析しなくて良いんだろうか?

どうやって既存のシステムからの移行を行う気なのだろうか?

コメントを投稿する