回答編集履歴

16

テキスト修正

2015/05/08 05:38

投稿

jun68ykt
jun68ykt

スコア9058

test CHANGED
@@ -2,7 +2,7 @@
2
2
 
3
3
 
4
4
 
5
- 他の状況をもっと知らないと、どっがいいとは言えないのですが、
5
+ 他の状況をもっと知らないと、どっがいいとは言えないのですが、
6
6
 
7
7
  自分が同じ選択肢で悩み、多少工数に余裕があるのなら
8
8
 

15

テキスト修正

2015/05/08 05:37

投稿

jun68ykt
jun68ykt

スコア9058

test CHANGED
@@ -64,6 +64,12 @@
64
64
 
65
65
  を全部は作らない」というアジャイルの方針に反することにもなります。
66
66
 
67
+ (※「想定できる機能を全部は作らない」のがアジャイルだというのは、
68
+
69
+ 単なる私見です。すみません。そういう主張をどこかのブログか記事で
70
+
71
+ 読んだだけなのですが、けっこう納得したので。)
72
+
67
73
 
68
74
 
69
75
  と、いろいろ考えるべきファクターがありそうなのですが、私なら

14

テキスト修正

2015/05/08 02:49

投稿

jun68ykt
jun68ykt

スコア9058

test CHANGED
@@ -2,13 +2,13 @@
2
2
 
3
3
 
4
4
 
5
- 他の状況を知らないと、どっがいいとは言えないのですが、
5
+ 他の状況をもっと知らないと、どっがいいとは言えないのですが、
6
6
 
7
7
  自分が同じ選択肢で悩み、多少工数に余裕があるのなら
8
8
 
9
9
  【案2】
10
10
 
11
- のほうを選ぶと思います。
11
+ のほうを押す方向で考えると思います。
12
12
 
13
13
 
14
14
 

13

テキスト修正

2015/05/08 02:27

投稿

jun68ykt
jun68ykt

スコア9058

test CHANGED
@@ -50,9 +50,9 @@
50
50
 
51
51
  にもよります。【案2】だとテーブル1個増やすので、それに対するモデル
52
52
 
53
- やロジック、必要ならばビューも新しくひと揃え書くことになり、ひと手間
53
+ やロジック、必要ならばビューもと、新しくひと揃え書くことになり、
54
54
 
55
- すからね。
55
+ ひと手間かかそうですからね。
56
56
 
57
57
 
58
58
 

12

テキスト修正

2015/05/08 02:14

投稿

jun68ykt
jun68ykt

スコア9058

test CHANGED
@@ -74,9 +74,9 @@
74
74
 
75
75
  > 【案1】と【案2】で迷っていて、【案1】だとほぼ瞬殺で終わるけど、
76
76
 
77
- > 【案2】だとこれだけ時間がかかる。ただ【案2】だと、今後
77
+ > 【案2】だとこれだけ時間がかかる。ただここで多少時間かけてでも
78
78
 
79
- > 「締め」に対する業務からの色々な要望に応えられる。
79
+ > 【案2】で設計、開発したら、今後「締め」に対する業務からの色々な要望に応えられる。
80
80
 
81
81
  > 色々な要望として想像しているのは・・・の時や・・・の場合、とかとか。
82
82
 

11

テキスト修正

2015/05/08 02:10

投稿

jun68ykt
jun68ykt

スコア9058

test CHANGED
@@ -76,11 +76,13 @@
76
76
 
77
77
  > 【案2】だとこれだけ時間がかかる。ただ【案2】だと、今後
78
78
 
79
- > 「締め」に対する、あれやこれやの業務からの要望に応えられるのだけど・・・
79
+ > 「締め」に対する業務からの色々な要望に応えられる
80
+
81
+ > 色々な要望として想像しているのは・・・の時や・・・の場合、とかとか。
80
82
 
81
83
 
82
84
 
83
- というを、業務側の担当者に相談します。そうすると、結果的に【案1】で
85
+ という相談を、業務側の担当者に持ちかけます。そうすると、結果的に【案1】で
84
86
 
85
87
  やることになったとしても、業務側から、
86
88
 

10

テキスト修正

2015/05/08 01:50

投稿

jun68ykt
jun68ykt

スコア9058

test CHANGED
@@ -18,7 +18,7 @@
18
18
 
19
19
  - いったん締めたものを差し戻して伝票内容を変更し、再度締めができるようにして欲しい。
20
20
 
21
- - その際にも差し戻し処理や、再度の締めをしたユーザーが誰なも分かるようにして欲しい。
21
+ - その際にも差し戻し処理や、再度の締めをしたユーザーとそ日時も分かるようにして欲しい。
22
22
 
23
23
  といった要望が業務側から出てきそうですし、逆に要望が出てこない
24
24
 

9

テキスト修正

2015/05/08 01:43

投稿

jun68ykt
jun68ykt

スコア9058

test CHANGED
@@ -40,9 +40,9 @@
40
40
 
41
41
  はっきりさせることができます。
42
42
 
43
- また、ある受・発注にひもづく「締めの履歴」をリストすることで、
43
+ また、ある「仕入れ」にひもづく「締めの履歴」をリストすることで、
44
44
 
45
- 業務の改善が図れるという状況があるなら、やはり【案2】です。
45
+ 業務の改善が図れるという状況があるなら迷わず【案2】です。
46
46
 
47
47
 
48
48
 

8

テキスト修正

2015/05/08 01:35

投稿

jun68ykt
jun68ykt

スコア9058

test CHANGED
@@ -39,6 +39,10 @@
39
39
  (複数の開発者がいるのでしたら、チームの認識としても、)
40
40
 
41
41
  はっきりさせることができます。
42
+
43
+ また、ある受・発注にひもづく「締めの履歴」をリストすることで、
44
+
45
+ 業務の改善が図れるという状況があるなら、やはり【案2】です。
42
46
 
43
47
 
44
48
 
@@ -82,13 +86,9 @@
82
86
 
83
87
  「◯◯さんはただ作るだけじゃなくていろいろ業務よりのことも考えてくれて頼もしい」
84
88
 
85
- 的な評判を得ることができたりするのです。
89
+ 的な評判を得ることができたりするのです。老獪かもしれないですが、業務側からの
86
90
 
87
- これってセコいですかね?老獪ですかね?
88
-
89
- でも、業務側からのそういう評判、業務システムの開発やるときには
91
+ そういう評判、業務システムの開発やるときには大事だったりするもので。
90
-
91
- 大事だったりするもので。
92
92
 
93
93
 
94
94
 

7

テキスト修正

2015/05/08 01:34

投稿

jun68ykt
jun68ykt

スコア9058

test CHANGED
@@ -54,7 +54,7 @@
54
54
 
55
55
  最近は、業務システムもアジャイルを取り入れることが多いと聞きますが、
56
56
 
57
- 冒頭に上げたような追加要件が必ず発生するとはいえないという状況
57
+ 冒頭に上げたような追加要件が必ず発生するとはいえないという状況ならば
58
58
 
59
59
  「気を回しすぎて、アレもコレも盛り込む」というのは、「想定できる機能
60
60
 
@@ -66,15 +66,19 @@
66
66
 
67
67
  どうするかというと、こうします。
68
68
 
69
- 【案1】と【案2】で迷っていて、【案1】だとほぼ瞬殺で終わるけど、
70
69
 
71
- 【案2】だとこれだけ時間がかかる。ただ【案2】だと、今後
72
70
 
73
- 「締め」に対する、あれやこれやの業務からの要望に応えられるという話を
71
+ > 【案1】【案2】で迷って【案1】だとほぼ瞬殺で終わるけど、
74
72
 
75
- 業務側の担当者に相談しますそうすると、結果的に【案でやるこ
73
+ > 【案2】だとこれだけ時間がかかるただ【案、今後
76
74
 
75
+ > 「締め」に対する、あれやこれやの業務からの要望に応えられるのだけど・・・
76
+
77
+
78
+
79
+ という話を、業務側の担当者に相談します。そうすると、結果的に【案1】で
80
+
77
- なったとしても、業務側から、
81
+ やることになったとしても、業務側から、
78
82
 
79
83
  「◯◯さんはただ作るだけじゃなくていろいろ業務よりのことも考えてくれて頼もしい」
80
84
 
@@ -82,7 +86,7 @@
82
86
 
83
87
  これってセコいですかね?老獪ですかね?
84
88
 
85
- でもそういう評判、業務システムの開発やるときには
89
+ でも、業務側からのそういう評判、業務システムの開発やるときには
86
90
 
87
91
  大事だったりするもので。
88
92
 

6

テキスト修正

2015/05/08 01:20

投稿

jun68ykt
jun68ykt

スコア9058

test CHANGED
@@ -58,9 +58,33 @@
58
58
 
59
59
  「気を回しすぎて、アレもコレも盛り込む」というのは、「想定できる機能
60
60
 
61
- を全部は作らない」というアジャイルの方針に反することにもなりますし、
61
+ を全部は作らない」というアジャイルの方針に反することにもなります
62
62
 
63
+
64
+
63
- いろいろ考えるべきファクターがありそうです
65
+ と、いろいろ考えるべきファクターがありそうなのですが、私なら
66
+
67
+ どうするかというと、こうします。
68
+
69
+ 【案1】と【案2】で迷っていて、【案1】だとほぼ瞬殺で終わるけど、
70
+
71
+ 【案2】だとこれだけ時間がかかる。ただ【案2】だと、今後
72
+
73
+ 「締め」に対する、あれやこれやの業務からの要望に応えられるという話を、
74
+
75
+ 業務側の担当者に相談します。そうすると、結果的に【案1】でやることに
76
+
77
+ なったとしても、業務側から、
78
+
79
+ 「◯◯さんはただ作るだけじゃなくていろいろ業務よりのことも考えてくれて頼もしい」
80
+
81
+ 的な評判を得ることができたりするのです。
82
+
83
+ これってセコいですかね?老獪ですかね?
84
+
85
+ でもそういう評判、業務システムの開発やるときには
86
+
87
+ 大事だったりするもので。
64
88
 
65
89
 
66
90
 

5

テキスト追加

2015/05/08 01:17

投稿

jun68ykt
jun68ykt

スコア9058

test CHANGED
@@ -52,6 +52,18 @@
52
52
 
53
53
 
54
54
 
55
+ 最近は、業務システムもアジャイルを取り入れることが多いと聞きますが、
56
+
57
+ 冒頭に上げたような追加要件が必ず発生するとはいえないという状況で、
58
+
59
+ 「気を回しすぎて、アレもコレも盛り込む」というのは、「想定できる機能
60
+
61
+ を全部は作らない」というアジャイルの方針に反することにもなりますし、
62
+
63
+ いろいろ考えるべきファクターがありそうです。
64
+
65
+
66
+
55
67
  思いつくのは、以上です。
56
68
 
57
69
  参考になれば幸いです。

4

テキスト修正

2015/05/08 01:09

投稿

jun68ykt
jun68ykt

スコア9058

test CHANGED
@@ -32,9 +32,13 @@
32
32
 
33
33
  どん増えて巨大なテーブルになる)な予感がするのですが、【案2】だと、
34
34
 
35
- 業務システムとして、「締め」を1つのエンティティ(またはモデル)
35
+ 業務システムとして、「締め」あるいは「締めるという業務」を、「仕入れ」
36
36
 
37
+ とは別の1つのエンティティ(または、モデル)として扱うことを、
38
+
39
+ (複数の開発者がいるのでしたら、チームの認識としても、)
40
+
37
- として扱うということがはっりします。
41
+ はっきりさせることがきます。
38
42
 
39
43
 
40
44
 

3

テキスト修正

2015/05/08 01:01

投稿

jun68ykt
jun68ykt

スコア9058

test CHANGED
@@ -20,30 +20,34 @@
20
20
 
21
21
  - その際にも差し戻し処理や、再度の締めをしたユーザーが誰なのかも分かるようにして欲しい。
22
22
 
23
- といった要望が業務側から出てきそうですし、逆に要望が
23
+ といった要望が業務側から出てきそうですし、逆に要望が出てこない
24
24
 
25
- 出てこないのなら、これらを提案することが可能だからです。
25
+ のなら、これらを提案することが可能だからです。
26
26
 
27
27
 
28
28
 
29
- 【案1】だと、このように「締め」に様々な属性を持たせるということに対応するのが
29
+ 【案1】だと、このように「締め」に様々な属性を持たせるということに
30
30
 
31
- 大変になりそう(=仕入れテーブルに「締め」の情報がどんどん増えて巨大なテーブル
31
+ 対応するのが大変になりそう(=仕入れテーブルに「締め」の情報がどん
32
32
 
33
- になる)な予感がするのですが【案2】なら「締め」を1つのエンティティ
33
+ どん増えて巨大なテーブルになる)な予感がするのですが【案2】だと
34
34
 
35
+ 業務システムとして、「締め」を1つのエンティティ(または、モデル)
36
+
35
- (または、モデル)として扱うということがはっきりします。
37
+ として扱うということがはっきりします。
36
38
 
37
39
 
38
40
 
39
- とはいえ、「締め」機能のリリースまでにどれくらいの工数を
41
+ とはいえ、「締め」機能のリリースまでにどれくらいの工数をもらえるのか
40
42
 
41
- もらえるのかにもよります。【案2】だとテーブル1個増やすので、
43
+ にもよります。【案2】だとテーブル1個増やすので、それに対するモデル
42
44
 
43
- それに対するモデルやロジック、必要ならばビューも新しくひと揃え
45
+ やロジック、必要ならばビューも新しくひと揃え書くことになり、ひと手間
44
46
 
45
- 書くことになり、ひと手間ありますからね。
47
+ ありますからね。
46
48
 
47
49
 
48
50
 
49
51
  思いつくのは、以上です。
52
+
53
+ 参考になれば幸いです。

2

テキスト修正

2015/05/08 00:47

投稿

jun68ykt
jun68ykt

スコア9058

test CHANGED
@@ -40,9 +40,9 @@
40
40
 
41
41
  もらえるのかにもよります。【案2】だとテーブル1個増やすので、
42
42
 
43
- それに対するモデルやロジックひと揃え書かないとなりませんから、
43
+ それに対するモデルやロジック、必要ならばビューも新しくひと揃え
44
44
 
45
- ひと手間ありますからね。
45
+ 書くことになり、ひと手間ありますからね。
46
46
 
47
47
 
48
48
 

1

テキスト修正

2015/05/08 00:41

投稿

jun68ykt
jun68ykt

スコア9058

test CHANGED
@@ -26,13 +26,13 @@
26
26
 
27
27
 
28
28
 
29
- 【案1】だと、このように「締め」に様々な属性を持たせるという
29
+ 【案1】だと、このように「締め」に様々な属性を持たせるということに対応するのが
30
30
 
31
- ことに対応するのが大変になりそうな予感がするのと、
31
+ 大変になりそう(=仕入れテーブルに「締め」の情報がどんどん増えて巨大テーブル
32
32
 
33
- 【案2】なら、「締め」を1つのエンティティ(または、モデル)と
33
+ になる)な予感がするのですが【案2】なら、「締め」を1つのエンティティ
34
34
 
35
- して扱うということがはっきりします。
35
+ (または、モデル)として扱うということがはっきりします。
36
36
 
37
37
 
38
38