【Rails関西】Rails屋からデータモデリングに対する回答

1/20に開かれた第6回RubyOnRails関西へ行ってきた。
場所は神戸電子専門学校。目の前にオランダ館、風見鶏館などの異人館があり、華やかな場所でした。

このたびの発表の中で最も興味を引いた講演が「やさしいRailsの育て方」(by 西和則さん)。
講演内容は、Railsでもテーブル設計をきちんと考えましょう、ということなのだが、それは昨年8月の渡辺さんの指摘に対する回答になっているように思う。

【1】RDBのテーブル設計におけるアンチパターン
Railsをやっていると、例えば、下記のアンチパターンに囚われてしまう。

１・無限ＦＫ地獄や列破綻
　テーブルに他テーブルの外部キーをどんどん持たせると列が増えていく。
　西さんの例では、社員テーブルに派閥1、派閥2のカラムを増やしていた。

２・フラグステータスとバタフライ効果
　「北京で蝶が羽ばたくとニューヨークで嵐が起きる」がその意味だが、「小さな変更による影響の範囲が大きくなる」ことのたとえ。
　西さんは、社員テーブルと企業テーブルに論理削除のカラムがあった場合、フラグが少しだけ変わるだけで表示されなくなる例を持ち出していた。

　テーブルを設計した時、上記のような状況に陥ったことはありませんか？

【2】現在のトレンドは関係テーブル(対照テーブル)を持たせる

アンチパターンに対する対策として、西さんははぶさんの本「楽々ERDレッスン」を参考にして、下記のやり方を紹介していた。

１・対象の独立性
　他テーブルと外部キーを持たないようにする。
　つまり、アイデンティファイアを導入し、イベント系テーブルは関係テーブル(対照テーブル)として作る。
　
２・対象の健全性
　必要最小限で、余分な情報は持たない。
　特にリソース系テーブル。
　
　このやり方を彼らしい例え話で説明していた。

１・アイデンティファイアの意味
　複合キーにわざわざアイデンティファイアを導入するのは違和感があるけれど、これは今のメールアプリのタグ付けに似ていませんか？と。
　つまり、メールボックスにあるメールのデータは地面に全て置いておき、データを組み合わせてタグをつけて関係付けている。
　一昔前のメールアプリは、メールとディレクトリが紐づいていたからわざわざリファイルしていた。
　前者はアイデンティファイア、後者は外部キーで紐づいていたのと同じではないか？と。

２・「この項目は火星に飛ばせるか？」で判断する
　リソース系テーブルのカラムを分けていく基準として「このカラムは火星に飛ばせるか？」で判断しようと彼は言う。
　ドラゴンボールなら、名前・キャラ・生息地・生年月日・パワーなどのうち、生息地は火星に持って行けないから、独立させようとか。

　「第7正規形を作りました！」という内容は面白かった。

【3】Railsのメソッド拡張
　上記の内容は、1:n、n:nの関係をどう表現するか、と言う問題に帰結する。
　そこで、西さんは、Railsのメソッドを拡張していた。Railsのデフォルトになるのだろうか？
(詳細は西さんの発表資料を読んで下さい)

　昨年8月の渡辺さんが、Railsはデータモデリングに弱いのではないか？と発言されていたが、Rails屋さんがそれに対して回答していると言う意味で、価値ある講演だった。

プロジェクト管理心得ノート～XPやアジャイルを言う前に

　最近のアジャイル開発やＸＰの議論を聞くと、原理原則をいかに忠実に実行するか、というよりも、現実のプロジェクトにいかにカスタマイズして結果を出すか、という地に足を付けた議論が多くなっている。

　そんな中で、アジャイル開発の導入に否定的な人たちやそのプロジェクトでは、オブジェクト指向の技術に慣れていないのも原因の一つだろうが、それ以前に、プロジェクトの体制や開発プロセスの進め方というSIerとしてもっと基本的な部分でレベルが低いのではないか、という疑問を最近持っている。

　ふと下記の本を手にした。

　本の内容は、プロジェクトが失敗する事例からその原因と対策を説明している。
　ざっくり書いてみる。

１・プロジェクトの体制そのものに無理がある例：

・プロジェクトリーダーにその資質がない。
・プロジェクトリーダーを補佐する人がいない。
・チームにキーマン(牽引役)がいない。
・スケジュール管理ができていない。
・開発チームに問題児がいる。(顧客に問題児がいる場合もある)
　　そう言えば、ある人は、段取りの下手な開発者を嫌っていた。
　　そういう人がいると彼一人だけの問題ではなく、周りの雰囲気まで悪くなるから、と言っていた。

２・仕様調整で問題が出てくる

・システム構築の実現可能性の担保はどこで取るか？という観点がない設計。
　　枝葉の機能に囚われている、とか、パフォーマンスを考えていない、とか。
　
・仕様＝費用の認識がない。
　　仕様確定のコミットメントに、双方の認識のずれがある。

・顧客とのコミュニケーションギャップ。
　　顧客は自分の業務に忙しくて、業務のヒアリングが中途半端になってしまう。
　　　特にデータ移行、システム切り替えで問題が噴き出す。

　　あるいは、ヒアリング時に顧客の要望を明確に断らなかったために信頼関係に支障をきたす。

　現場を経験したことがある人なら、その事例はあったな、と頷くのではなかろうか？
　SEに技術力はあって当然で、仕様洗い出し・設計プロセスで噴き出した問題点、顧客・元請・下請の3社の利害関係者の調整をいかに制御して、問題を解決して、ゴールまで進めていくか、という政治力の方を求められている。

　XPやアジャイル開発は、上記の問題点に対する対策をいくつか用意している。
　ファシリテーション、イテレーション、計画ゲーム、Simple Is Bestという設計方針、など。
　それらのメソトロジーを使って、顧客・プロジェクトリーダーと掛け合って合意をもらって初めてアジャイル開発を導入できてチームが回転する。
　最近の事例を聞くと、そういう話題を聞く。
　対症療法の一つとして、アジャイル開発を考えた方がいいのではなかろうか？