04/11/07 16:55:49
関連サイト
本家
URLﾘﾝｸ(martinfowler.com)
Bliki本家
URLﾘﾝｸ(martinfowler.com)
Bliki翻訳
URLﾘﾝｸ(capsctrl.que.jp)
オブジェクト倶楽部XP関連記事
URLﾘﾝｸ(www.objectclub.jp)
Inversion of Control コンテナと Dependency Injection パターン
URLﾘﾝｸ(www.kakutani.com)
勝手に関連スレ
国産DIコンテナSeaserとくーす その2
ｽﾚﾘﾝｸ(tech板)
オブジェクト指向は難しすぎ
ｽﾚﾘﾝｸ(prog板)
3:仕様書無しさん
04/11/07 17:00:28
2get。
開発の方法論だとか手法だとかどうあるべきかを評価する際のキーワードは「埋没費用」だ。
4:仕様書無しさん
04/11/07 17:30:10
ム板向きかマ板向きなのか・・・
>3
手厳しいな
あとは学習曲線なんてのもそうかな
とりあえず具体的なサンクコストの例を挙げてみて・・・
5:仕様書無しさん
04/11/07 17:40:05
サンクスコ？
6:仕様書無しさん
04/11/07 17:44:03
禿とヒゲの話題もこちらでよろしいでしょうか？
7:仕様書無しさん
04/11/07 17:47:09
ここは、ハゲを隠すのにデコレーターパターンと依存性の注入のどちらがいいか、ということを語るスレですよ。
8:仕様書無しさん
04/11/07 17:52:49
Seasar2スレからコピペ。
51 名前:デフォルトの名無しさん 投稿日:04/10/31 22:00:16
頭髪の話。
URLﾘﾝｸ(martinfowler.com)
URLﾘﾝｸ(www.amazon.co.jp)
Rod Johnson の勝ちだな。
66 名前:デフォルトの名無しさん 投稿日:04/11/01 03:35:17
Fowlerってさ、おでこにマジックで温泉マーク書いたら、
逆さにしても顔にみえそうだよね。
9:仕様書無しさん
04/11/07 17:55:14
Seasar2スレこの辺も必読。
ｽﾚﾘﾝｸ(tech板:200-224番)
10:仕様書無しさん
04/11/07 18:52:47
結論としては
やっぱウォーターフォールモデルに始まりウォーターフォールモデルに終わる。
あとは精々プロトタイピングが有ればOK。
他は行き当たりばったり厨房の言い訳にしか使い道は無い
でFA?
11:仕様書無しさん
04/11/07 19:11:50
世界レベルで>>10のような考えが淘汰されつつあるのだがなー。
末端の末端にまで行き渡るのは、Postウォーターフォールの成功体験を持つ人間が部長や役員レベルに偉くなる10年後くらいかな。
12:仕様書無しさん
04/11/07 19:34:47
Fowlerたん萌えな人って偉い人になりたがらなそうな人が多そうだ。
13:仕様書無しさん
04/11/07 21:46:41
お前等これどう思う？
URLﾘﾝｸ(capsctrl.que.jp)
正直言ってファウラーだから客も聞いてくれるんじゃねえの？
倍のバッファをオープンにするなんて、うちの部長が客んとこに
お願いに行ってもこんな話聞いてもらえないよ。
14:仕様書無しさん
04/11/07 22:22:47
＞13
同意同意。
ここでの契約の問題と、実装面だと永続化の問題、
どれもファウラーの言う事は凄いし面白いと思うけど
まねは出来ないねえ。芸能人みたいなもんだもん。
どうしても現実感がわかないんだよなー。
15:仕様書無しさん
04/11/07 22:48:33
>>13のリンクを読んでみた。
5千万円以上の見積を1億円以上だろ。
どんな顔して提案するんだろうか。ｶﾞｸﾌﾞﾙだ。
そもそもうちにはこんな金額のもの発注がこんわ。
Fowlerﾀｿは髪と引き換えにネ申になったのか…。
16:仕様書無しさん
04/11/07 23:15:58
>>15
しかもさらに5000万円追加だぞ。すげえな。
ERPのプロジェクトを思い出すよ。
一度採用しちゃうと中途半端で稼動できないから
最後まで追加で金を出し続けるしかないって状態。
追加予算を気前良く出せる客でないとこの方法は
使えないと思うんだがどうよ？
17:仕様書無しさん
04/11/07 23:20:05
バッファを食いつぶしたのは客の要求変更のせいだと書いてあるわけなんだが。
18:仕様書無しさん
04/11/07 23:24:19
>>15
見積もりの中身が違うのでは？
ファウラーのいう$50万という見積もりは、
バグに悩まされたり理解不能なことが起きたり
人間関係がこじれたりメンバーがトラックにひかれたり
といった問題が一切発生しない場合の、
完全に理想的なケースの見積もりだと思う。
でも多少はいろいろ起きるだろうからバッファを乗せる。
一方他社では細分化した作業一つ一つにバッファを乗せて
積み上げるから、そのトータルでは最初から$100万以上に
なるってことではないかと。
「クリティカルチェーン」とか参照。
19:仕様書無しさん
04/11/07 23:30:53
> これでもまだオジリナルの見積もりよりも少なかった
って書いあるよ。
「イニシャル1.5億で仕様変更のたびにすったもんだやる手間と追加工数が
出てくけど最初に決まったことは保証する」選択肢と、「イニシャル1億で
仕様変更柔軟に対応してくれるけど最初に決まったことはベストエフォート
でしか保証しない」選択肢があった場合、後者を選んだほうがいいケースは
多々あると思う。
20:仕様書無しさん
04/11/07 23:34:38
要するに客が金を支払い続けることに合意しないといかんわけだ。
よっぽどちゃんとした会社相手でないと使えない方法だと思うがどうか？
21:仕様書無しさん
04/11/07 23:35:46
>>16
> 一度採用しちゃうと中途半端で稼動できないから
> 最後まで追加で金を出し続けるしかないって状態。
Fowler式の場合小規模分割リリースで使える機能から
出してくはずなので、上記のようにはならないことが多いはず。
そうは言ってもどうしても分割リリースできない案件はあると思うが。
22:仕様書無しさん
04/11/07 23:40:36
>>20
>>19の前者のケースでも金(追加工数)は支払い続けることになるでしょ。
23:仕様書無しさん
04/11/07 23:41:01
なあオマエら自分で営業もやってるのか？
うちは営業と開発の連携が悪いしこんな
やり方を通してくる腕があるとも思えん。
夢物語にしか見えないorz
24:仕様書無しさん
04/11/07 23:44:20
>>22
金が尽きたら諦めろ、ってか？
俺はそこまで言えないなー。
いっそそこの会社の情報システム部に
なるほうがいいなじゃないのか？
25:仕様書無しさん
04/11/07 23:52:46
漏れは発注先の選定とかもやってるんだが、Fowler的なやりかたを提案してくる
とこがあったら話を聞いてみたい。
つーか、「最初に決まったことは保証する」とか言っても結局営業が頭下げるのを
保証するだけで、最終的な品質は保証できないベンダーのほうが多数派だし。
26:仕様書無しさん
04/11/07 23:53:57
>>21
ソフトウェアとして動作するのと業務で使える状態になるというのは別だと思うがどうよ。
離れ小島のように各機能が分割リリースされたって使ってもらえないだろうし。
27:仕様書無しさん
04/11/07 23:55:46
>>25
バイヤーとしては予算の上限とかどうなの？
Fowler流提案を締結したとして耐え切れるものなのかな。
金持ってる会社なら大丈夫なんだろうけどさ。
28:仕様書無しさん
04/11/08 00:35:34
>>27
> バイヤーとしては予算の上限とかどうなの？
> Fowler流提案を締結したとして耐え切れるものなのかな。
> 金持ってる会社なら大丈夫なんだろうけどさ。
\50,000,000くらいまでの案件しかハンドリングしたことない若造なんで
話半分に聞いてくれ。
期ごとの予算の確保の時点では要件も全く固まってなければベンダーも
当然決まってない。よって金額はかなり丼勘定になる。
その丼ぎりぎりだったら無理なわけだが、Fowlerのケースはそうじゃ
ないっぽい(もしくは「それしかないんだったらここ削りましょう」って
提案してくれるとか)。
あと最悪の場合は、予算の項目って粗粒度かつ曖昧な書き方をしてるので、
同じ部署内のほかの項目からやりくりすることもできる。
29:仕様書無しさん
04/11/08 00:39:13
Fowlerの有名な主張（？）に
「UMLはスケッチ（コミュニケーションの手段）として使うべきであって、
詳細設計のためにあるのではない」というのがありますが
これについてご意見をお聞きしたいです。
30:仕様書無しさん
04/11/08 00:45:14
>>28
なるほどね。リアルだｗ
ありがとう。すごく参考になる。
そうすると金額はいいとして
納期はどうなんだろうか？
予算って年度でついたりするだろ。
31:仕様書無しさん
04/11/08 00:46:39
UMLをスケッチじゃなく利用できる状況が、
現実にどの程度一般的か考えてみればそのトピックの是非は分かるでしょ。
裏を返すと、MDAやxUMLの技術が進歩するにつれて
その主張はだんだん誤りに近づくということ。
そのあたりが普及してきつつあるのは知ってるでしょ。
UMLにステレオタイプをつけることで、実装をかなり補完することができる。
C#のAttributeやJava5.0のNotationとか。
32:仕様書無しさん
04/11/08 00:52:26
>>31
揚げ足取りスマソ。Annotationだよ。
33:仕様書無しさん
04/11/08 02:23:02
>>29
前提条件出さずに、キャッチｰな部分だけを抜き出されても・・・
34:仕様書無しさん
04/11/08 20:58:29
>>26
芸のない答えですまんが、ケースバイケースだろうね。
「強い依存関係を持つサブシステムAとBのうちAだけを先にリリースして
Bは暫定的に人手で」は考えにくいけど、「コアな機能だけ先にリリースして
オプショナルな機能を漸次追加」は考えられる。
味も素っ気もない基幹業務システムは前者にあてはまりがちだろうし、
機能てんこ盛りのECサイトなんかは後者にあてはまるだろう。
35:仕様書無しさん
04/11/08 21:51:35
>>34
うん、そうするとね、強い依存関係を持つものから先に手をつけて、
それの難易度（仕様変更でもいいや）が高くなかなか完成しないと
いう状態が続くと、途中放棄もありうるんじゃないかと思うんだよ。
だからバッファを設定してというのは一見良いやり方に感じるんだが
何から手をつけるかによってバッファの食い潰し方も変わってくるんじゃ
ないかと思うんだ。そうすると本当は役に立つはずのものが作れたのに
とかそういうことになるんじゃないかな、とか思っちゃうんだよね。
そうすると、先に「こことここだけきっちりやります」と小さく畳んで
固定価格にしてるほうが案外納得してもらえそうな気がするんだよな。
36:仕様書無しさん
04/11/08 23:21:11
makotanの「おめでと～」はこのスレに対するものだろうか、
と気にしてる漏れはこのスレの>>1。
ちなみにmakotanと面識はない。
37:仕様書無しさん
04/11/08 23:23:50
>>36
だれかが歳食ったんだろ。
38:仕様書無しさん
04/11/08 23:27:24
>>37
マジレスするとひが君の誕生日だろうね。
39:仕様書無しさん
04/11/08 23:31:36
このスレとは関係ないな。
40:仕様書無しさん
04/11/08 23:33:49
とりあえずオレンジニュースに出ましたってことで。
41:仕様書無しさん
04/11/08 23:34:59
だから何？ってかんじだなｗ
42:仕様書無しさん
04/11/08 23:56:30
>>30
Fowler型じゃなくても、「××プロジェクトフェーズ2」「××エンハンス
プロジェクト」とかいう名目で次期に予算確保ってパターンがありがち。
43:仕様書無しさん
04/11/09 09:12:55
バッファを使い切らなかった場合は
ちゃんと返金してくれるんだろうか？
だったらいいやり方だと思う。
44:仕様書無しさん
04/11/09 14:36:53
余った場合に返金と、バッファなしで契約して
必要な分だけ追加だと、どっちのほうが発注
しやすいんだろうか。
45:仕様書無しさん
04/11/09 21:08:06
.Net Magazine12月号に「Domain ModelからDataSetへ」なる記事が掲載されてて、
PoEAAのTable Moduleに相当するものが.Net FrameworkのDataSetって説明がされてるんだけど、ホントにそうなの？何となく違う気がするんだけど・・・
この著者のJavaに関する記述は当てにならんので無視するにしても（@ITに「私がJavaからC#に乗り換えた10の理由」なんて記事を書いたことがある）、.Netに関する記述はどうなんだろう。
46:仕様書無しさん
04/11/09 21:29:22
またなんかのキャンペーンの一環？
47:仕様書無しさん
04/11/09 23:45:18
URLﾘﾝｸ(www.atmarkit.co.jp)
> ファウラー: 一括請負契約は、開発を開始する前に相手の要求仕様が
> 完全に理解できている場合にはいい考えですが、実際にはそんな状況に
> ほとんど遭遇したことがありません。
>
> 一同: （笑）。
48:仕様書無しさん
04/11/09 23:54:53
>>43
支払形態によると思われ。
インクリメント単位の支払だと、バッファを使い切らない分は
結果的に払わなくて済むとか。
49:仕様書無しさん
04/11/10 00:31:34
>>45
Eric Evansの『DomainDrivenDesign』を読むといいよ。
そのままが書いてあるから。
ついでにいえば、.Net 以外の、他社による分類についても書いてある。
50:仕様書無しさん
04/11/10 01:20:03
こういう、技術的な話題みたいな板違いのスレッドってこまるんだよね。
ここはネタ隔離板なのに。
51:仕様書無しさん
04/11/11 10:08:16
Bliki翻訳追加。
URLﾘﾝｸ(capsctrl.que.jp)
52:仕様書無しさん
04/11/11 19:09:42
>>50
元々スレ違いで
盛り上がって隔離
されたものですから。
生暖かく見守って
ください。
53:仕様書無しさん
04/11/20 12:31:46
URLﾘﾝｸ(www.tech-arts.co.jp)
URLﾘﾝｸ(martinfowler.com)
☆ ﾁﾝ
☆ ﾁﾝ 〃 ∧＿∧ ／￣￣￣￣￣￣￣
ヽ ＿＿_＼（＼・∀・）＜ アナリシスパターン2まだー?
＼＿／⊂ ⊂＿)＿ ＼＿＿＿＿＿＿＿
／￣￣￣￣￣￣￣／|
| ￣ ￣￣￣￣￣￣:| :|
| .|／
54:仕様書無しさん
04/11/21 12:44:23
Two things that certainly struck me were a couple of Anders Hejlsberg's
indicators of where he is currently thinking about C#. One is to deal
with the infamous impedance mismatch between objects and relational
databases. The other was moving towards type inference to combine the
advantages of static and dynamic typing.
これは「先を越された！」という意味でしょうか？
55:仕様書無しさん
04/11/22 12:24:52
Blikiエントリ追加
URLﾘﾝｸ(martinfowler.com)
URLﾘﾝｸ(martinfowler.com)
56:仕様書無しさん
04/11/22 12:42:57
PofEAAエントリ追加
URLﾘﾝｸ(martinfowler.com)
57:仕様書無しさん
04/11/23 00:10:59
仕事が速いな。
URLﾘﾝｸ(capsctrl.que.jp)
URLﾘﾝｸ(capsctrl.que.jp)
58:仕様書無しさん
04/12/07 23:28:55
Bliki更新。
URLﾘﾝｸ(martinfowler.com)
URLﾘﾝｸ(martinfowler.com)
59:仕様書無しさん
04/12/08 12:13:15
URLﾘﾝｸ(capsctrl.que.jp)
翻訳乙。
diffとgrepができるワードプロセッサが欲しい。
60:仕様書無しさん
04/12/14 12:07:18
アナリシスパターンを長瀬にだけは訳されたくない人の数→1
61:仕様書無しさん
04/12/14 22:18:44
PofEAA邦訳は諦めた方が良いのでしょうか。
62:仕様書無しさん
04/12/14 22:27:04
>>61
URLﾘﾝｸ(patterns-wg.fuka.info.waseda.ac.jp)
> 今回取り上げたパターンとその周辺のパターンについては，
> Patterns of Enterprise Application Architecture(URLﾘﾝｸ(martinfowler.com))を
> ご覧ください。フルで理解するには英語の書籍と格闘する必要がありますが，うわさによると
> 秋に翻訳が出るそうでそれを待つのも吉かもしれません。
誰が訳してるのかな。つーかもう冬なんだが。
63:仕様書無しさん
04/12/14 23:00:57
そうなのよ、秋を待ち遠しく思ってて気がついたら寒くて寒くて。
64:仕様書無しさん
04/12/15 00:01:30
PofEAA邦訳なんて枕にしかならんぞ。あれの存在意義は名称統一に過ぎん。
65:仕様書無しさん
04/12/15 00:48:19
そ、そうなのか・・・背伸びして原著に手を出そうかと思ってた所ですが
うーむ。高いんだよなあ。
66:仕様書無しさん
04/12/15 01:30:11
>>65
漏れは今年のはじめに原著買った。
読後良い買い物をしたと思った。
67:仕様書無しさん
04/12/15 02:46:26
技術系の洋書って初めてなんですけど、
最初に読むにはきついかなあ。
大学卒業以来まとまった長文の英語なんて読んでない。
せいぜいwebとかヘルプ程度、邦訳待ってたのに、ああ困ったもんだ。
68:仕様書無しさん
04/12/15 11:27:13
>>67
パターンカタログだから好きなところから読めるよ。
実は漏れも未読の項目が残ってたりする。
そういう意味では最初に読むには向いてると思う。
69:仕様書無しさん
04/12/15 12:33:29
うおー有難う御座います。
ああやばい買う気マンマンになって来た。
70:仕様書無しさん
04/12/15 22:06:48
今、PofEAAが米国から海を渡って漏れの家へ向かっている。
71:仕様書無しさん
04/12/15 23:58:41
「PofEAAを載せた船が、海賊に襲われた」
「ドウスル ＞」
72:仕様書無しさん
04/12/16 00:45:43
ココロ ツナグ
73:70
04/12/17 20:56:24
PofEAAが無事入国した模様。明日、接触します。
74:仕様書無しさん
04/12/18 01:42:12
URLﾘﾝｸ(martinfowler.com)
Bliki更新。
75:70
04/12/18 22:30:22
ｷﾀ━━(ﾟ∀ﾟ)━━ｯ!!
先日の円高時にamazon.comで注文したのでけっこう安く買えた
76:仕様書無しさん
04/12/20 15:05:59
>>62
>誰が訳してるのかな。つーかもう冬なんだが。
監修は長瀬氏との噂でしたが。
77:仕様書無しさん
04/12/20 15:46:34
>>76
そのニュースで洋書購入に走った人が
結構いるという噂でしたが。
78:仕様書無しさん
05/01/01 11:45:39
PofEAAは2005年の春ごろになるようだ。
URLﾘﾝｸ(capsctrl.que.jp)
79:仕様書無しさん
05/01/07 01:09:13
更新。
URLﾘﾝｸ(martinfowler.com)
80:仕様書無しさん
05/01/08 12:57:50
乙
URLﾘﾝｸ(capsctrl.que.jp)
81:仕様書無しさん
05/01/08 12:58:54
また更新
URLﾘﾝｸ(martinfowler.com)
82:仕様書無しさん
05/01/10 22:33:38
訳
URLﾘﾝｸ(capsctrl.que.jp)
83:仕様書無しさん
05/02/04 23:18:15
保守
本家
URLﾘﾝｸ(martinfowler.com)
URLﾘﾝｸ(martinfowler.com)
URLﾘﾝｸ(martinfowler.com)
訳
URLﾘﾝｸ(capsctrl.que.jp)
84:仕様書無しさん
05/02/15 22:03:10
PofEAAは日本語版は近日発売予定
URLﾘﾝｸ(www.atmarkit.co.jp)
85:仕様書無しさん
05/03/19 23:41:01
でねーな。