未経験のデータベース構築に挑戦:システム開発プロジェクトの現場から(3)(2/2 ページ)
開発現場は日々の仕事の場であるとともに、学びの場でもある。先輩エンジニアが過去に直面した困難の数々、そこから学んだスキルや考え方を紹介する。
1つの提案をきっかけに、データベースの構築を担当
いよいよテスト環境を構築するという段階になって、私はプロジェクトリーダーにこう提案しました。
「データベースを実装するスクリプトを自動的に生成するツールがあります。この機会に導入しませんか。便利だし、何らかのツールがないと、膨大な設計情報を管理しきれませんよ。私ならそのツールの使い方は分かるので、よろしければ全般的に作業を引き受けましょう」。前のプロジェクトで活用されていたツールを、このプロジェクトでも導入しようという提案でした。
「本当にあなたが管理できるの?」といぶかしがられましたが、「大丈夫です。どうしても困ったら、Oracleに詳しいエキスパートに相談します」と主張して押し通しました。
こうして「ツールの担当者」という立場を得た私は、それを足掛かりとして徐々にデータベース自体の設計・管理の領域へと手を広げていきました。
データベースの構築には、命名規約に始まり、サイジング、パフォーマンスチューニングなどさまざまな知識が必要です。実務と並行してそれらの学習を進め、知識を習得していきました。机上で学習したことを実機で試行しながら最適解を探っていくプロセスはとても楽しく、やりがいのあるものでした。
時にはエキスパートの手を借りながら、最終的には大きなトラブルもなく、データベース環境を構築・提供することができました。気付いてみると、DBA(データベースアドミニストレータ)としての知識が自然と身に付いており、プロジェクトの合間に挑戦した「ORACLE MASTER Gold」(現ORACLE MASTER Silver)にもすんなりと合格することができました。
旧システムの解析作業にも携わる
こうしてデータベースに詳しくなり、仕事ぶりも認められてきたことから、私は主要なロジックを新システムでどう実装するかを検討するプロセスに関与できることになりました。
新しいシステムの仕様を決めるとき、旧システムのロジックを把握することは不可欠です。ところがこのプロジェクトでは、旧システムに関するドキュメントがまったくといっていいほど存在せず、仕様を知っている人も皆無でした。
しかたなく、旧システム(オフコン)のライブラリの構造やソースコードを読み解きながら、仕様を探るというアプローチを採らざるを得ませんでした。上級のSEさんがそういった解析作業を行い、私がVisual BasicとOracleという新しい環境でどう実装するか考えるというように、二人三脚で設計を進めていくことになったのです。
当然、一筋縄ではいかず、夜通し作業を進めることもしばしばでした。皆さんも経験があると思いますが、期日が迫っている中、追い詰められた状況で夜中に仕事をしていると、妙にテンションが上がってきて、おかしくもないものが妙におかしく感じられたりします。
夜中に静まりかえったオフィスで、COBOLのソースコードを解読しながら、なぜか2人してケタケタと笑っている姿は、はたから見ている人がいれば不気味だったに違いありません。いまとなってはいい思い出ですが、「あのとき救急車を呼ばれなくてよかったな」とも考えてしまいます。
契約時のスコープ設定は重要だ
私たちは1つ1つ解析作業を繰り返しながら、大変な時間と労力をかけて、ひとまず作業をやり遂げました。しかし、そのような作業は当初の見積もりに含まれておらず、プロジェクトの収益に小さくない影響を与えました。また、解析しきれなかったロジックが原因となって不具合が発生し、プロジェクトとして責任を問われるという事態にもつながってしまいました。
契約時に作業範囲が明確に取り決められていなかったため、結果的に「全部請け負います」という形になってしまい、こういった解析作業にも責任を負うことになってしまったのです。あらかじめ必要な工数とリスクを網羅的に見積もり、契約時に作業範囲を明確に定めておくことは非常に重要だと、このとき強く感じました。
周囲の環境を利用することの大切さ
このようにいろいろとあったプロジェクトでしたが、後半には「棚卸領域」でチームリーダーを任され、要件定義や、チームメンバーとベンダの管理を担当することができました。
アサインされた当初は苦労したものの、データベース管理という担当者のいないポジションにスキルの足りない状態ながらも立候補し、学習しながら役目をやり遂げ、周囲に認められることによって、当初決めていた目標をある程度達成することができたといえます。
こうした経験から私は、その時々の自分の環境と偶然を最大限に生かすことの大切さを学びました。
しかし、自分にとって一番の財産となったのは、苦楽を共にした仲間との信頼関係と思い出かもしれません。いま思い返してみると、そんな気がします。
筆者紹介
アクセンチュア・テクノロジー・ソリューションズ
稲井紀茂
1972年生まれ。神戸生まれの大阪育ち。大阪でプログラマ、システムエンジニアとして約7年を過ごした後、2003年にアクセンチュア・テクノロジー・ソリューションズに入社し上京。主に流通業・製造業の販売管理・SCM系システムの構築に携わり、現在に至る。
- 文書ドリブン開発 テスト文書編
- 文書ドリブン開発 詳細設計文書編
- 文書ドリブン開発 DB設計文書編
- 基本設計文書の質を下げる「4つの心理バイアス」
- 本当は楽しいドキュメント作成
- 新人(3年目)、プロジェクトで「忍耐」を学ぶ
- 新人、集合研修で「伝説」を作る
- 新人(3年目)、先輩デビューで「最悪の振る舞い」
- 新人、アーキテクチャチームで「運命の出会い」
- 1人チームで悩む新人。「この作業って意味あるの?」
- 現場デビューのお供はビジュアル多用の報告書
- 大規模プロジェクトでは「同じ言葉を、同じ意味で」
- 「バッファ込み」の工数がスケジュール遅延の原因
- 運用って、あまりいいイメージはなかったけれど
- 最強チームで挑んだ、「40時間でデータ移行」の壁
- 障害対応とチューニングの危うい関係
- オフショアなんて、怖くない
- 3プロジェクト同時にリード! どう乗り切る?
- この案件、ぜひ新しいテクノロジでやりましょう!
- 初めてのトラブル対応。これで直ると思ったのに!
- 「できるか!」な設計書に、どう立ち向かう?
- 専門用語で「カッコよく」話すのは簡単だけど
- メンバーとの仕様打ち合わせは海を越えて
- 定まらない要件、ユーザーからのむちゃな要求
- 未経験のデータベース構築に挑戦
- セットアップ全国行脚で九州弁に大苦戦
- 試行錯誤で分かったスパゲッティコード撃退法
Copyright © ITmedia, Inc. All Rights Reserved.