回答編集履歴
16
テキスト修正
test
CHANGED
@@ -2,7 +2,7 @@
|
|
2
2
|
|
3
3
|
|
4
4
|
|
5
|
-
他の状況をもっと知らないと、どっがいいとは言えないのですが、
|
5
|
+
他の状況をもっと知らないと、どっちがいいとは言えないのですが、
|
6
6
|
|
7
7
|
自分が同じ選択肢で悩み、多少工数に余裕があるのなら
|
8
8
|
|
15
テキスト修正
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
テキスト修正
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
テキスト修正
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
テキスト修正
test
CHANGED
@@ -74,9 +74,9 @@
|
|
74
74
|
|
75
75
|
> 【案1】と【案2】で迷っていて、【案1】だとほぼ瞬殺で終わるけど、
|
76
76
|
|
77
|
-
> 【案2】だとこれだけ時間がかかる。ただ
|
77
|
+
> 【案2】だとこれだけ時間がかかる。ただここで多少時間かけてでも
|
78
78
|
|
79
|
-
> 「締め」に対する業務からの色々な要望に応えられる。
|
79
|
+
> 【案2】で設計、開発したら、今後「締め」に対する業務からの色々な要望に応えられる。
|
80
80
|
|
81
81
|
> 色々な要望として想像しているのは・・・の時や・・・の場合、とかとか。
|
82
82
|
|
11
テキスト修正
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
|
-
という
|
85
|
+
という相談を、業務側の担当者に持ちかけます。そうすると、結果的に【案1】で
|
84
86
|
|
85
87
|
やることになったとしても、業務側から、
|
86
88
|
|
10
テキスト修正
test
CHANGED
@@ -18,7 +18,7 @@
|
|
18
18
|
|
19
19
|
- いったん締めたものを差し戻して伝票内容を変更し、再度締めができるようにして欲しい。
|
20
20
|
|
21
|
-
- その際にも差し戻し処理や、再度の締めをしたユーザー
|
21
|
+
- その際にも差し戻し処理や、再度の締めをしたユーザーとその日時も分かるようにして欲しい。
|
22
22
|
|
23
23
|
といった要望が業務側から出てきそうですし、逆に要望が出てこない
|
24
24
|
|
9
テキスト修正
test
CHANGED
@@ -40,9 +40,9 @@
|
|
40
40
|
|
41
41
|
はっきりさせることができます。
|
42
42
|
|
43
|
-
また、ある
|
43
|
+
また、ある「仕入れ」にひもづく「締めの履歴」をリストすることで、
|
44
44
|
|
45
|
-
業務の改善が図れるという状況があるなら、
|
45
|
+
業務の改善が図れるという状況があるならば、迷わず【案2】です。
|
46
46
|
|
47
47
|
|
48
48
|
|
8
テキスト修正
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
テキスト修正
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】だとこれだけ時間がかかる。ただ【案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
テキスト修正
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
テキスト追加
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
テキスト修正
test
CHANGED
@@ -32,9 +32,13 @@
|
|
32
32
|
|
33
33
|
どん増えて巨大なテーブルになる)な予感がするのですが、【案2】だと、
|
34
34
|
|
35
|
-
業務システムとして、「締め」を
|
35
|
+
業務システムとして、「締め」あるいは「締めるという業務」を、「仕入れ」
|
36
36
|
|
37
|
+
とは別の1つのエンティティ(または、モデル)として扱うことを、
|
38
|
+
|
39
|
+
(複数の開発者がいるのでしたら、チームの認識としても、)
|
40
|
+
|
37
|
-
|
41
|
+
はっきりさせることができます。
|
38
42
|
|
39
43
|
|
40
44
|
|
3
テキスト修正
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】
|
33
|
+
どん増えて巨大なテーブルになる)な予感がするのですが、【案2】だと、
|
34
34
|
|
35
|
+
業務システムとして、「締め」を1つのエンティティ(または、モデル)
|
36
|
+
|
35
|
-
|
37
|
+
として扱うということがはっきりします。
|
36
38
|
|
37
39
|
|
38
40
|
|
39
|
-
とはいえ、「締め」機能のリリースまでにどれくらいの工数を
|
41
|
+
とはいえ、「締め」機能のリリースまでにどれくらいの工数をもらえるのか
|
40
42
|
|
41
|
-
|
43
|
+
にもよります。【案2】だとテーブル1個増やすので、それに対するモデル
|
42
44
|
|
43
|
-
|
45
|
+
やロジック、必要ならばビューも新しくひと揃え書くことになり、ひと手間
|
44
46
|
|
45
|
-
|
47
|
+
ありますからね。
|
46
48
|
|
47
49
|
|
48
50
|
|
49
51
|
思いつくのは、以上です。
|
52
|
+
|
53
|
+
参考になれば幸いです。
|
2
テキスト修正
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
テキスト修正
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
|
|