今年の1月から参画していた案件が4月以降の予算を獲得できず、5月からの再起を見込んで4月は予算のないプロジェクトを細々と続けていました。

4月の後半になって5月からも再開できないことになり、一旦は自社に戻るかと思いきや、C++の案件のお話を頂きました。

当初は『名古屋』というワードもなかったため、私のような若輩者が『基本設計』から参画すること以外不安はありませんでした。

この時点では基本設計のうち『DB設計』を担当するとのことでした。

その後、名古屋行きが確定し、案件の詳細を伺ったのですが見積内容に基本設計と『要件定義の一部』という文言がありました。

事前に基本設計に関しての書籍を読んでいた為、「あれ、DB設計するのにまだ要件定義終わってない…」というのがその時の印象です。

これまで行ってきたアジャイル開発のような手法であればそれもまた可能ではありますが、今回の案件はどうやらウォーターフォールによる開発のようでした。

「お客さんと密にやり取りが必要だから名古屋」というのは共感できる範囲ですが、基本設計以前に要件定義が終わっていないのは工程の遅れや継続していくにあたり手戻りが多く発生する、それにつれて燃え上がるというのも覚悟しました。

名古屋での就業がスタートし、最初に頂いた工程表でスケジュールがきついこともわかりました。

それに加えて何より恐ろしかったことが、要件定義の確定前に製造着手まで見込まれていたことです。

さらに、WBS上では私のチームが担当するDB設計は機能設計よりも前に想定されていました。

後に問いただしたところによれば「お願いしている部分はマスタテーブルだから機能設計より先行できる」という考えに基づくとのこと。

結論から言えば、そんなことはありませんでした。もちろんトランザクションテーブルも設計しました。

未確定な要件に振り回され、レビューの度に概要書に記載のない要件未対応を指摘されることになりました。

私が今後今の案件を継続していくかは今週次第ですが、DB設計への手戻りは今後も週単位で発生していくと思われます。

ちなみに、「オブジェクト指向でやったるぜ!」と私みたいに息巻いている方はDB設計の時に必要以上に正規化しない方が無難です。

「Nullは絶対許容しない」という信念で組み立てたら「一目でわかるようにして」と一蹴されました。

結果、下手すると数十カラムがNullのケースもあるテーブル定義になりました。

正規化はする前にお客さんに確認しましょう…いい経験になりました。

DB設計の他にもドキュメントは作成しましたが、そちらはほぼほぼ作業感覚だったのでここでは省略します。

話が少し戻りますが、名古屋に来たからと言って「お客さんと密にやり取り」は出来ませんでした。

システム開発において緊密な連携は必要不可欠ですが、それが必ずしも対面でなくてはいけないかというと、Web会議などの方法がある今の時代なら十分条件だと思われます。

連携するにあたり、双方のスケジュールがどれだけ調整できるものか、だけは知っておかなくてはいけないなと思いました。

現地にいようがリモートだろうが、時間取れなければ一緒ですからね。

時間が取れない場合はいかに合間だけでやり取りが出来るか、だと思われます。

欲しい回答が期日通りに貰えない為に遅れる作業ほど心労に繋がります。

あとは感想になります。

製造であれば設計書あるいは口頭での要望をどう実現していくか、くらいしか考えてきませんでした。

とりあえずやってみる、というスタンスでしょうか。

今回は詳細設計以降までを見据えていろいろと考えることが多かったです。

機能要件を満たすだけならこれだけでいい、非機能要件まで考えればこうした方がいい、ただしこうしてしまうと実装面で工数を取る(あるいは不可能)、であればここは実装可能な別な方法にシフトしよう、それにあたって影響が出る範囲はどこか、このテーブル定義を変えるのであれば他も統一できるか、などなど。

製造ももちろん好きですが、こうした考えを膨らませる仕事も楽しいなぁと感じました。

何よりもこれまで製造で培ってきた経験を設計へと生かすことが出来るわけですからね。

あとはちょっと言葉が悪いかもしれませんがシステムなんて、データをDBに書き込んでそのデータを使う、そこにある程度の業務知識が絡んでくる、だけなんだと実感しました。

新人の頃には気づけなかった感覚です。

ただそれだけのはずなのに、毎回四苦八苦するんですからシステム開発も奥が深いですね。毎日勉強になります。

以上です。

スポンサーリンク