福井さん

返信ありがとうございます。

> DB設計のテーマでは ８月のRails関西勉強会では、渡辺幸三さんの
> 「アジャイルにデータモデリング」
> で「『簿記３級』は必須。でないと業務システムでは話が通じない。
>   『関数従属性』一番重要... 」
> などの濃いお話がありました。

確かに業務システムの現場では簿記は非常に重視されます。
企業の基幹システム構築の場合、まず会計システムから手を入れるのが
定石ですし、私が新卒で入社したコンサルティングファームでは、内定すると
簿記2級と基本情報処理の両方の資格を入社までにとることを義務付けられて
いました。

私はずっと会計コンポーネント担当だったので、簿記2級でも現場で通用するように
なるには、ずいぶんと時間を要しました。（簿記と経理業務はまた別ですの
で・・・）

業務システムのマーケットにRailsが切り込んでいく最大の障壁は、こうした
業務知識かもしれませんね。

新たな発見をさせていただき、ありがとうございます。

蛇足ながら私が知っている限りでは、だいたい業務システムは以下の手順で
行われていました。

コンセプトデザイン（どういうシステムを何の目的で導入するか、予算、期間）
　↓
業務をヒアリングして『業務フロー図』作成
（帳票の洗い出しはこの段階に行うのが定石）
　↓
業務フロー図をたたき台に、要件のヒアリングをおこない
『要件定義書』を作成。
　↓
『概要設計書』作成
　↓
『詳細設計書』作成（概要と詳細の違いがあいまいでプロジェクトによって混乱多
し）
　↓
プログラム開発
　↓
単体テスト
　↓
結合テスト
　↓
受入テスト（顧客が実施）
　↓
修正箇所は修正
　↓
ユーザトレーニング
　↓
リリース


ざっとこんな流れでした。
業務知識（含む、会計知識）がないと、業務のヒアリングの段階で
業者を変えられてしまいかねません。

ですのでITコンサルタントを入れてしまうのも手ですが、高額な上に、
システムにも業務にも強いコンサルタントというのが非常に少ないので
コンサルタントは吟味に吟味を重ねたほうがいいですね。

コンサルタントの書く設計書ほどの、訳の分からないものはないと、
苦労された方も多いでしょうから・・・・・・

もと同業者として恥ずかしい限りです。


藤澤　太一 / Taichi Fujisawa
mailto:tf@s...
------------------------------------------------------
『Travel on Rails』
Ruby on RailsやWEB2.0、ITエンジニアのワーキングスタイルを語る。
http://rubyonrails.blog47.fc2.com/
------------------------------------------------------
Squaria Co., Ltd.

c-MA3 BLDG. 5F
3-1-35. Motoazabu Minato-ku
Tokyo, 106-0046 JAPAN
+81-3-6439-1888 (Phone)???-????-???? (FAX)
http://www.squaria.net
------------------------------------------------------


-----Original Message-----
From: FUKUI Osamu [mailto:o-fukui@p...]
Sent: Monday, September 18, 2006 7:21 PM
To: rails@r...
Subject: [rails:1660] Re: Ruby on Railsの開発方法論について

福井です。

Date: Mon, 18 Sep 2006 16:18:29 +0900
>藤澤と申します。

はじめまして。

>『Railsの開発方法論を作成しよう』と活動しています。
	：
>開発方法論の作成、標準化に同意いただける方のご協力をお待ちしております。

>『Travel on Rails』
>Ruby on RailsやWEB2.0、ITエンジニアのワーキングスタイルを語る。
>http://rubyonrails.blog47.fc2.com/

なるほど。

「開発方法論」のポイントが違っているのですが、ちょっと
「開発方法論」という言葉に反応します。

Rails Chatで話題になっていた
羽生章洋さんの「Activity Based Datamodel」
http://event.seasar.org/sc2006spring/viewAttachment.do?_pageName_=Materials&
_fileName_=D4.ppt

で論じられているところの「開発方法論」というか「DB設計論」は
興味深いです。
「先に業務プロセスありき」
「帳票から順番に攻める！」
「Activity(活動)とFact(活動で発生した事実)を分けて考える」
   :

DB設計のテーマでは ８月のRails関西勉強会では、渡辺幸三さんの
「アジャイルにデータモデリング」
で「『簿記３級』は必須。でないと業務システムでは話が通じない。
   『関数従属性』一番重要... 」
などの濃いお話がありました。

実装は Railsですすめるとして、設計やプロジェクト管理に新しい
「開発方法論」へのニーズも大きいと思います。

業務システムで、テーブルの数が１００を超えるケースで、本当に
Railsが実用化された（る）事例（苦労）で磨かれてまた進化をとげ
るでしょう。

Rails実装の話題にプラスして 『新しい時代のＤＢ設計論』でも
盛り上がりたいですね。

多:多 が自然で、HABTAMでは、「交差エンティティ」にidをもって管理
できないなら has_many :through で「交差テーブル」を適切に命名
してモデル化するのが普通になるのでしょうし。


--
福井 修 FUKUI Osamu  iR3



--
ML: rails@r...
使い方: http://QuickML.com/



--
ML: rails@r...
使い方: http://QuickML.com/