「プログラミング] 製品DBシステムは、サービスでもあり、プラットフォームでもある

今週になって、「ダウンロード/アップロード時の、任意のレコードフォーマットをどんなふうに、パラメータ化するか(DB化するか)」に取り組んでいる。

ダウンロードするとき、テーブルAの項目A1とテーブルBの項目B1を選べて、条件C1で抽出する、という事をDB化する、ということ。

ダウンロードした後は、値を変更して、アップロードして、更新先のテーブル/項目を、追加更新削除する。更新先のテーブルは、シンプルに1つのケースもあるし、複数テーブルにまたがるケースもある。更新方法も、パラメータ化の範疇だ。

要求仕様書を提出してから後、2ヶ月強かけて要求確認書の作成に付き合って、概要設計までの支援契約として発注したX社から(その後の製作局面を、X社は請負う)、概要設計局面になって、「要求仕様を実現することが(弊社では)できません。1stフェーズでは、ハードコーディングします。パラメータ化は、2ndフェーズ以降で検討します」と、先週末に通達(宣言)された為だ。

発注元が、実現可能な仕様を検討して(決定して)提出することを求める。受注先のX社は(決定された)仕様を実装する、というのだ。ならば、高額な費用を支払っている「支援契約」には、どんな意味があるのか?!という空気が、現場には流れている。


簡単にいえば、データウェアハウスを製作する仕事なのだ。
既存ツールの提案もあってもよいだろう。X社が「できません」といったので、「(これで)できるジャン?!」と、(発注元がX社に)言ってやりたい、ということ。

で、私が作業しているのだ。ムムム〜(~_~;)

実は、もうひとつ意味があるのだ。発注元は、X社の技術力に疑問を持ったので、S社に内密に情報展開した。S社に相談する為にも、実現性の確証を得たいという目的が(発注元には)あるのだ。

ポリシーは決めたよ
「製品DBシステムは、サービスでもあり、プラットフォームでもある」
でもさ〜
私は天才ではないので、普通〜(?)の対応案かもしれないー
今日もこんな時間だ〜(*_*)