最近読み切った本2冊

ちょっと仕事関係のお話＆長編になります。

今お客さん先で取り組んでいるのは、システム刷新。
欧州から名の知れた(自分は知りませんでした)ソフトウェアを
買ってきて、手を入れて使おうとしています。

このソフトウェア、主にサービス契約しているお客様に対して
課金を行うのに使うソフトウェアなのですが、これに
実にいろんな機能を後付け（拡張！？）して、さらにそのシステムごと
最近流行り(？)の「クラウド」で提供し、
同業他社さんに各機能を切り売りしようとしています。
でも、いまのところ当初の計画通りにコトは進んでいません。

なぜか？

上記のような大規模なソフトウェアを作成する場合、
まず当然ながら
「自分たちはこのシステムで一体、何がしたいのか？」
をシッカリ文書にする必要があります。
これを「要件定義」と言います。

この要件定義を元に、実現させる機能を細分化して、
各機能で処理する業務について誰でも分かるような
「業務説明書」を作成してから設計作業を進めます。

ちょっと難しい話になったので、言いたいことを書きます。

こんな大規模なソフトウェアを作成する際、
「データベース(DB)」というソフトウェアを部品として必ず使う必要があります。
このDBは、お客様の大切な情報（データ）を保存しておく基地（ベース）の
ようなソフトウェアです。

このDBを使うには、事前にデータがどういう構造で、いつのタイミングで発生し、
どのデータとどのデータが関係あるか、といった設計作業を
シッカリする必要があります。

ところが、、、

「時間がないから」と言って、要件定義はもちろん
業務の分析もせず、機能は現行システムに詳しい（自社じゃなく協力会社の！）
エンジニアを連れてきて「口頭で」作成担当のエンジニアに伝えているのです。

しかも相手のエンジニアは欧州人。
通訳を介すとはいえ言葉の壁があります。

その結果、DBは増築＆増築を繰り返して

目が回るような設計になってしまいました。

データの名前が同じでも内容（意味）が違うデータだったりするのです。

これでは、ソフトウェアが仮に作成できたとしてもすぐに破綻します。

というか、今の状態は「出来てもいない」状態。
まともに動いていません。
来年早々にサービス開始だというのにこんな状態…。

じゃあ、一体どうしたらいいのか？

もはや誰も大きな声では言えませんが、

　「ちゃんと要件定義から　や　り　直　し」

これをしないと、一般のお客様に大変なご迷惑をおかけすることになります。
当然、信頼頂いた同業他社さんの信頼も一瞬で無くなるでしょう。

一方で自分が出来ることは何か？
と考えたときに
「プログラムとデータベースが好き」→「データベース何とかしたい」
→「そんな文句言うならお前、設計しろよと言われたときに出来るか？」
という質問に辿り着き、大慌てで読み込んだ本がこの2冊。

データベース設計をどのように進めるのか？を解説した本です。

実は、ずーいぶん前に購入して、何度も読むのを挫折した本。

けど800ページ本を読み切った今は違います。しかも日本語の本だし。

読んでみると「基礎講座」「入門」と名がついていますが
内容は結構難しいです。2冊とも中盤辺りから難しい。
けれど、読み応えがありました。

「自分が設計しろって言われたら、こうできないよな…」
と思う部分が多かったです。
もう1度くらい気になったところを読み返し、ちょっと練習問題を解いて
モデリングを身につけようと思います。

ですが、実際「DB再設計してください」なんて言われてません。
というか、この先も言われないかもしれませんね。
言われる前に、この現場から居なくなるかもしれませんし。

けど、たった1回あるか分からないチャンスに対して
十分準備しておくのは悪くないことじゃないっすか？