Close

2017年11月28日

RMS活動報告18&19

こんにちは、うらのです。

ランダムにブログを書く人を選ぶスクリプトが動かず、メンバーに記事を丸投げ頼めなかったので今週は私が担当になりました。ちなみにスクリプトが動かなかった原因はプロキシの設定でした。プロキシヴァァァァァ

というわけで今回はプロジェクト運営の失敗話と、最終的に決まったDBをお披露目(?)したいと思います。

失敗談―予定が狂っ狂ワイパー

5月初旬、新RMSの開発にあたり予定を立ててスケジュールを調整することになりました。ところが…

はじめてなので要件洗い出しにかかる工数がわからない。というか全工程でどれくらいかかるのか経験がないので分からず。。。

データベース設計で詰む。難しい。無限に難しい。講義のデータが正規化出来ない。つらい。

という具合に設計をやっている間に予定が狂っていきました。元々ちゃんとした予定がなかったから狂っていないのかも知れない。

くぅ~疲れましたwこれにてDB設計完結です!―本当の本当に終わり

DB設計は前述の通り工数がわからないのでとりあえず設計しようぜっ☆という勢いで5月中旬から設計をはじめました。時間がかかることは目に見えていたのでDB全体のテーブルの関連から設計して中身を煮詰めていく方法を取りました。全体の設計は3〜5人で、各テーブルは5人で一人1テーブルを担当して設計しました。そしてなんとか6月の終わりにはテーブルの設計が完了しました。その後はシステムバックエンド作成のために人を回してそちらの作業を始めたのでした。

終わったと言ったな。あれは嘘だ。

いや本当はもう完成していたんですが、とりあえずMySQL Workbenchで作ったER図で満足してしまって別の作業を始めていました。ところがDB定義のSQLスクリプトが必要になった時に、WorkbenchのデータからSQLスクリプトをエクスポートしてDBに入れようとしたらなんとエラーを吐き出してしまいました。

仕方がないので1からSQLスクリプトを組んでいったのですが、よく見ると冗長な名前や不要なカラムが見つかったのでそれらを訂正して、先々週にやっと新しいSQLスクリプトが完成しました。南無三。

あとがき

ドキュメントを残して引き継ぎを簡単にすることを主眼に置いて開発していたつもりなのですが、今回振り返ってみてそこまでドキュメントが残っていないのではないか?ということがわかりました。とはいえ全部ドキュメントに残すのはコストが高いのでどこまでドキュメント化するべきか難しいですね。DB構造の詳細と、設計の意図が分かるようなドキュメントは必ず残しておきたいです(前者は既にありますが)。

あとDB設計は2人以上でやろうとすると認識のすり合わせが大変なので、いくら大変でも分割せずに少数で作るべきだと思いました。そこそこの人数を動員して最適な設計が出来るとすればきっとその人はプロです。

DB設計に時間を取られたり、フロントエンドのモックアップがなかなか完成しなかったりと問題は色々ありますが僕が卒業するまでには完成させたいです。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

CAPTCHA