4月。新年度が始まると同時に新しいプロジェクトに参画することになった。未経験として始めたプログラマの仕事も3年が経ち、自信がついてきた。

今度のプロジェクトは携帯電話の在庫を管理するシステムを一新するらしい。現在COBOLで書かれているソースをJavaに書き直すようだ。俗に言うリプレイスというやつらしい。

チームメンバーは7名。東京にプロジェクトをまとめるプロジェクトマネージャー(PM)が1人いて、他の6人のメンバーは札幌で開発をする。札幌にも1人プロジェクトリーダー(PL)をおく体制だ。PLは3か月ほど東京に出張に行っていてPMと2人で要件をまとめていたようだ。今月からPLは札幌に戻り開発をまとめる。

哲矢PL「というわけでテツヤです。今月からよろしくお願いします。ではそれぞれ自己紹介をお願いしようかな。」

木場「キバです。開発経験はほぼないですが哲矢PLとは前のプロジェクトで一緒にさせてもらっていました。よろしくお願いします。」

吉富「ヨシトミです。2年くらい経験があります。今まで結構残業が多いプロジェクトにいたので今回はそういうことがないよう頑張ろうと思います。」

無言「ムゴンです。経験は5年くらいっす。よろしくです。」

乙女「オトメです。女性は私一人ですね。経験は1年くらいでまだまだわからないことばかりですがよろしくお願いします。」

原「ハラです。経験は4年くらいです。まぁ仲良く仕事できればと思っていまっす。よろしく！」

半灰「ハンバイです。経験は3年くらいですが未経験入社なので知識はまだまだです。よろしくお願いします。」

まずは現在のシステムのソースコードを読み、設計書を作ることになった。この作業を1か月くらい行い、その後すぐ2か月くらい開発するようだ。3か月後にはリリースというなかなかタイトのプロジェクトだ。

哲矢PLはデータベースの整理をするらしい。というのも既存そのままリプレイスではなく、使っていない機能などは削減してスリム化したいという要望もあり設計と並行して機能の整理も行うようだ。

これが地獄の始まりだった…

解説

リプレイス案件ということでパターンが2つ考えられます。

1つは既存の機能は全てそのままで言語やデータベースを一新するものです。これは既存のものをそのまま書き換えることになります。

もう一つが一新しつつ機能を追加したり削除し、システム改修も一緒に行うものです。こちらの場合機能の選別をするため業務知識が必要になるのですが、ここがきちんとしていないと悲惨なことになります。なぜなら開発者=使用者ではないためどの機能が重要でどの機能が削除対象なのかわからないためです。この辺は要件定義がしっかりしていればいいのですが…。

さて物語ではPLがデータベースの整理から取り掛かりました。機能を一新する場合、どのテーブルにどのカラムを置くなど早い段階で決めておく必要があります。

例えば個人情報テーブルと会社情報テーブルがあったとします。例えば「所属部署」という情報が必要になった場合、情報は個人情報テーブルに置くのか、会社情報テーブルに置くのか、両方に持たせるのか決めておく必要があります。そうしなければ所属部署を使う機能でどのテーブルを見るかわからないためです。この辺が決まっていないと設計書にも起こせないため早めに決める必要があるのです。

つづく

プログラマ物語目次