2017/06/01 00:31:30
nihonbuson
"1. 最初の開発をやってた人がマネージャとかになる 2. 「僕がやってたころは、もっと開発スピード速かったんだけどな」とか言ってる。" これな。後から入ってきた人にとってはただただ困る言葉。
2017/06/01 00:37:27
m-matsuoka
いきなりIN-OUTの関係を固定してしまうメソッドを作るのはまずい。入金だけ・ジュース出すだけの２つinterfaceを作り、さらにその２つを関連付けるinterfaceを作り、interfaceの関係を試行錯誤する。テストを青にするのはその後
2017/06/01 00:49:35
endo_5501
“最初の開発をやってた人がマネージャとかになる 「僕がやってたころは、もっと開発スピード速かったんだけどな」とか言ってる。”
2017/06/01 01:08:37
kantei3
おー。
2017/06/01 01:38:46
shimooka
『変化(発見)に対応し続ける』の『発見』がキモな気がした。どう発見・認識するか？と言うか、それに気付くか。
2017/06/01 02:01:47
papiro
まさに自分たちのことのように見えてならない残念無念
2017/06/01 02:18:37
turanukimaru
変化は発見するものじゃない。予測するものなんだ。特に増えるものを予測しよう。この例で言えば、コーラを買うから、他の商品は増えますか？別の価格が増えますか？と聞く。増えるとわかってるものは準備できる。
2017/06/01 04:00:16
vanbraam
単純なコードを使った実験が面白い;MVP(Minimal Viable Product)とは何か,という問にもつながりそう.個人的には「ちゃんと設計するが,MVPとして何を_やらないか_を予めはっきり決める」というアプローチを取りたいと思う
2017/06/01 05:18:52
sysjojo
どっちにしても後から入った人は楽できない定め、な気がするのは私だけ？ 自分が作ったもののリファクタリングする勇気は出ても、人が作ったもののリファクタリングする勇気は出ないかもしれん...
2017/06/01 05:43:40
ta_so_ka_re
これに絶望してPGをやめました
2017/06/01 05:56:27
fumisan
じゃあどうすればよかったのところで、本当は、モブが機能を増やしたり複雑に しようとするところを止める人が必要だった、ということなんでしょうねぇ。
2017/06/01 06:28:10
a-know
へー、「モブプロ」。“POはしきりに「聞いてくれていいよ」と言ってはくれてたけど、でも自分から「このプロダクトをチームと一緒に良くしたい！」という気持ちは見えなかったなぁｗ”
2017/06/01 07:10:36
warauashi
プロジェクトの成功または失敗はPO(PM)の腕次第
2017/06/01 07:12:59
ledsun
プログラマー側は自身のリファクタリング力を信じて、最初に抽象を作り込まない。プロダクトオーナーは、つけようと思っている機能を最初に話す（あとで変えても良い）。かな？
2017/06/01 07:44:46
kyon_mm
よくわからないけれど、1時間でプロジェクトの縮図になるほど、このメンバーは凄腕だったのだろうか。それともビジョン共有も期待の確認も振り返りもないままに始めるのが普通だっていいたいのだろうか。
2017/06/01 08:01:47
swimming_pooh
POがモブに入ってるのがなぜ大事かを教えてもらった！
2017/06/01 08:05:37
minemuracoffee
“誰も知らない新しいものを作るときは「全員の知識を持ち寄って、変化(発見)に対応し続ける」というのができたら良いのかなーって思った。”
2017/06/01 08:06:41
ka2hik0
モブプロかー
2017/06/01 08:07:55
hacktk
"何かに気づいたときに、それを元に全体をリファクタリングする。できるようにしておく。" これが大事で、かつ難しいことだよね。
2017/06/01 08:08:48
uturi
開発ではよくある話。結果論であれば「こういう設計にしておけば良かった」と言えるんだが、開発が進むほど設計からの見直しは難しくなるよな。
2017/06/01 08:18:24
mogemura
アジャイルでやるなら要件のストーリーがありそうなところ。ストーリーから想像できない場合はずっとそんな感じになるんじゃないかな。
2017/06/01 08:31:42
katzchang
養殖の課題設定の限界ぽい
2017/06/01 08:38:10
Soudai
僕の過去と思うところのある話だった
2017/06/01 08:40:54
thesecret3
どうにもならんよな。数量に小数点があるとか、まとめ買いがお得とか、会員制で価格が複数とか、登録時にコードがないとか、同じ商品でコードが変わるとか、いろいろあるんだよな。
2017/06/01 08:41:41
k1take
技術的負債が生まれる瞬間を見れる良い例。対策は、ファジーな感じだけど今後どう要件追加されそうか予想しながら作る、ってとこかな。
2017/06/01 08:48:55
Rinta
「そのあいだなのかなー？」そう思う。全てはトレードオフ。その塩梅が難しい。
2017/06/01 08:54:17
kz78
あまり最初から拡張性を考え過ぎると、誰もつかってない機能を延々とメンテするはめになるからねぇ…。／id:turanukimaru 世の中、予測してた機能が増えなくて、予測してない機能が増える。（この例だとドルがみたいな
2017/06/01 08:54:17
wordi
自販機についてを詰めなかったのが原因っぽい、これがゲームだと自販機はミミックにしたい的な事もあるし
2017/06/01 08:54:20
kuchitama
ほんとこれは、どこにいっても、どんなプロジェクトでも突き当たるなー。バランス感難しい。開発視点だけじゃなく、ビジネス視点も必要になる場合があるから、ほんと難しい。
2017/06/01 08:55:50
otihateten3510
概念モデルを把握した上で設計し、可変性を保つように作り込んでいくのが最適だと思う（凝集度、結合度に気をつけ疎結合にする。規模が大きい程メリット大）POは割と関係なく、どちみち設計はエンジニアの領分になる
2017/06/01 08:56:30
jaguarsan
TDDとKISSの組み合わせがその場しのぎの実装になりやすいってはよく知られていて、だからこそリファクタリング重要。リファクタリングで壊れるならテストの品質が良くない。
2017/06/01 08:58:23
fk_2000
昆虫が卵を産んで幼虫になってサナギになり成虫になるだけでなくて、遺伝子的なフレームを次の世代に引き継げるような構造がグランドデザイン化できたらなー
2017/06/01 09:00:58
akulog
リファクタリングしよう
2017/06/01 09:02:49
az1za
「動いている部分には極力触るなの精神」をなくすだけでだいぶ違うと思う
2017/06/01 09:04:44
htbman
要件の解釈が雑。100円を入れるから引数を100にしたんだろうけど、であれば101や99のときのテストを書くべきだし、そんなテストが必要なのはなにか臭うぞとなる。考えるべきところを飛ばして早いと言っているだけ
2017/06/01 09:06:15
yo_waka
development
2017/06/01 09:07:42
mnat44
あれ？前の会社の話？という感じだった
2017/06/01 09:18:36
Chocolat520
"本来、少しの変更で対応できそうなことが、その複雑さのためにすごく時間がかかるようになってしまう。"　すごくわかる
2017/06/01 09:22:13
rgfx
ドメインエキスパートｴ…／やーでも色々いいエントリですよ。我が身を振り返るのに。
2017/06/01 09:22:27
heron214
実はこの場合分けが結構大変。webとかアプリなら取り敢えずえいって出しちゃえるけど、ハードが絡んでくるとそうもいかないよね
2017/06/01 09:25:17
lalala360
作り直す前提のプロトタイプで始めるのはどうでしょう
2017/06/01 09:27:40
sonots
「そのあいだ」を取るには、今後の拡張を考えはするけど、実装まではしないのがコツ。つまり、今後の拡張へのリファクタリングをしやすい構造にはしておくけど、過度な汎化実装はまだやらない。
2017/06/01 09:30:12
youfokk
最初の要件の工数と、最後の要件の工数かけ離れてるのはどうしたんだろう
2017/06/01 09:33:58
shoota-dev
チーム開発と設計、汎用化と抽象化の縮図が思考ベースで進んでて非常に面白い
2017/06/01 09:34:20
vimtaku
解くべきドメインの見極めの話だと思うけど
2017/06/01 09:34:34
bushimichi
とてもよくわかる。実感のこもったレビューだなこれは。適切な解を見つけるだけで時間がかかるのでどうしても遅くなる。
2017/06/01 09:35:17
chinpokomon_master
POは自販機という機械がどういう仕組みで動いているかを勉強すべきで、開発者は自販機というビジネスがどういう仕組みで成り立っているかを勉強すべき。問題はお互いが自分の得意なことしか知らないこと。
2017/06/01 09:38:09
YaSuYuKi
この問題は長年研究されており、対応策も研究されている。学んでから考えるべきこと
2017/06/01 09:38:50
ohbarye
ウッ / “本来、少しの変更で対応できそうなことが、その複雑さのためにすごく時間がかかるようになってしまう。”
2017/06/01 09:42:37
sakidatsumono
最初のテストコードを見た瞬間あかんやつやと思った
2017/06/01 09:42:46
fuji_haruka
機能が追加されるたびにすべてを1から作り直す
2017/06/01 09:48:24
syunnchang
ドメイン駆動で掘り下げたほうが結果的に速度はかわらなさそう
2017/06/01 09:51:47
pokochinista
まずは現在わかってる内容を素直にオブジェクトに落とし込むだけでもだいぶ違うような。
2017/06/01 09:52:07
kyrie_leison
とてもわかる。私も同じように悩んだとき、教わったのが「ものごとの本質を捉える、今ある知識で、今あるものだけを。余計な未来予測はしない」だった。初心を忘れずがんばっていきたい
2017/06/01 10:01:59
masatomo-m
開発者側からのヒアリング不足に見える。機能面の仕様だけじゃなくてビジネスロジックやそのプログラムがカバーしたいビジネスドメインまで理解しに行ってPOと相談するという力が足りていない。SE力的なやつ
2017/06/01 10:08:29
civitaspo
だんだん開発スピードが遅くなっていくのをどうやってとめたら良かったんだろう？ - Mitsuyuki.Shiiba
2017/06/01 10:13:07
tekoratto
先ず技術者はある程度興味のある仕事(ここで嘘付くとロクなことにならない)をやるべき>自販機とは何か〜 Intel4004の嶋正利氏だって、アプリ部署から設計開発部署に異動させてもらってから花開いた(´・ω・｀)
2017/06/01 10:14:12
naopr
ほんとこれなーほんとこれなー
2017/06/01 10:14:17
su_zu_ki_1010
“誰も知らない新しいものを作るときは「全員の知識を持ち寄って、変化(発見)に対応し続ける」というのができたら良い”という結論が出てると思うんだけど、はてぶは全然違う方面をつついてるように見える。
2017/06/01 10:15:31
t-murachi
もう初手から0円でもマイナス10億円でもコーラが手に入る実装作っておいて何言ってくれちゃってるの…(´･ω･`) 早けりゃいいって問題じゃないでしょ(´･ω･`)
2017/06/01 10:17:29
shin1x1
いい素振り / こういうイベント良いなあ
2017/06/01 10:17:47
hdampty7
面白い実験。結局、PGがどれくらい意思決定の場に参加できるかなんだよね。会議の雰囲気とか最高権者の考え方とかが分かると、最終的な実装をどっちにするか的な２択ケースでかなり参考になる。
2017/06/01 10:23:03
hisaichi5518
いい話です
2017/06/01 10:23:33
yuya_ryuno
業務フロー把握→要件定義をきっちりしないと、設計を固めることができないことがよくわかったでしょう。
2017/06/01 10:26:12
hiroomi
対応方法はいろいろあるとして、何したか、認識のマッの形成なんだろうな。
2017/06/01 10:30:42
houyhnhm
調査や分析ステップは重要で、将来的な拡張機能もどこまで折り込むか考える必要はある。／リグレッションテストを実装しておいて、初期版は結果の担保だけにしちゃうとか。
2017/06/01 10:32:15
hazakurakeita
コードファーストで行き当たりばったりでしかクラス構造を考えられないからこうなる。モデリングすれば改善される。
2017/06/01 10:35:50
sds-page
リリース間際に客に見せたら追加要求てんこ盛りで爆死するヤツ。最初に要件定義をしっかりしておいてプログラムに影響が大きい追加仕様は断るかペナルティとしてガッツリ追加料金を取るしかない
2017/06/01 10:36:39
voidy21
アキネイター式開発
2017/06/01 10:39:37
wata88
結局、自販機は作れたのかな
2017/06/01 10:44:05
kawa-_-kawa
深い洞察。んーどうしたら良かったのか判らない。
2017/06/01 10:51:49
zentarou
「架空の自販機」って時点でどこまでやるべきか決まらなくて死ぬでしょ。お題がクソ。
2017/06/01 10:51:56
subaru9878
よくぞ書いてくれたという感じ
2017/06/01 10:58:08
masayoshinym
“これも必要かもしれない、これも今入れておかないといけない、とかでどんどん仕様が膨らんでいく だいぶ時間をかけてできあがったけど、ほとんどの機能が使われない”これ一番つらい。
2017/06/01 10:59:51
versatile
KISS 制約
2017/06/01 11:00:03
kuniku
世の中は「リファクタリング」というが、それよりも　「作っては捨て」「作って捨て」「全部作り直す」が吉である。数年前の技術が残っているとも限らない。
2017/06/01 11:03:11
tail_y
“動いている部分には極力触るなの精神で、if文で分岐を追加して新機能対応をする。 その結果、例えば「在庫を減らす」という処理が散らばってしまい、バグを埋め込んでしまう。”／この部分、超重要な話だと思う
2017/06/01 11:03:42
tyru
新しい概念が出てきたら再設計しないとダメという話だと思う。再設計の結果、修正は軽微という事もあるだろうし
2017/06/01 11:08:25
n314
当たり機能とかキャンセル機能とか値段変更機能とか売上履歴機能とか外税切り替え機能とかも、普通の機能と言えば普通の機能なんだよなあ…。それを見越して柔軟に作るか？と言われるとたぶんやらない。
2017/06/01 11:09:35
masaquid
“TDDBC”
2017/06/01 11:12:17
patorash
そのドメインの常識的な部分をいかに要件として抽出するかってのが、最初は肝心だよなぁ〜。当事者も当たり前すぎて気付かないってことは多々ある。
2017/06/01 11:13:06
dco0901
上流工程は積み上げていった方がやりやすいけど、下流工程は最初から全部決まっていたほうがやりやすい性質があると思う。それぞれの妥協点を合わせた手法がアジャイルだったりするのかな。
2017/06/01 11:13:55
kitamati
お題：コーヒーも追加しましょう。あったか〜いとつめた〜い、あとNull〜いも。
2017/06/01 11:14:05
yajamon
暗黙知がこぼれ出た瞬間だ。DDD取り組みをおっぱじめるタイミングでは！！ /“「ふつー自販機ならあるやろー」”
2017/06/01 11:14:30
koyancya
『オブジェクト指向設計実践ガイド』の前半がそういった話になってた
2017/06/01 11:14:44
tbpg
何かを試すためのお題的なものは現実のコンテキスト的な制約がなくなるので、そういうのも含めて試すといいんですかね。ストーリーも含めたお題。（それはそれでモブプロ試行のためのコストとしては高い気もする）
2017/06/01 11:22:24
yuzutas0
同意。具体的には、イテレーション毎に計画会議を【全員で】やるのが大事だと思う。分担したがる病を卒業しないと。> “「全員の知識を持ち寄って、変化(発見)に対応し続ける」”
2017/06/01 11:27:56
s99e209
システムの規模が大きくなれるほど機能間のバランスを取るのは難しくなるので大抵のプロダクトでは開発スピードは遅くなるので、お客さんとそれの認識合わせする必要はありますよね。
2017/06/01 11:28:24
k_wo
“だんだん開発スピードが遅くなっていくのをどうやってとめたら良かったんだろう？”
2017/06/01 11:33:01
rjge
今すぐ増えなくても今後増える可能性があるかどうかを開発時に考えておくと対応しやすくなると思う。本当にその可能性があり得るかはPOに確認してもいいわけだし。その判断が覆ることも間々あるがそれはそれ。
2017/06/01 11:39:17
sippo_des
僕らは、「自販機」というものが何をできるものなのかを知らない状態で開発を始めて、要望を満たすものを急いで作る。 次の要望くらいまでは大丈夫なんだけど、だんだん開発スピードが遅くなってくる。
2017/06/01 11:42:28
dgen
受注時に詳細まで決まっていれば問題無いんだろうけど、発注側が把握していないから追加注文がくる問題。そんな不透明な仕事を請ける営業も然り。つまり開発内部の問題ではない。
2017/06/01 11:45:51
ryun_ryun
そのための業務設計が重要なんだけど、実際問題ユーザー企業でも自社の業務を把握できていない社員は多数いて、結局まともな設計ができないまま開発しちゃうんだよね。そしてSIerの責任と押し付けて来て泥沼化する。
2017/06/01 11:45:54
potato777
サービスの価値考える、ドメインについて学ぶ、将来の可能性考える、実装は本当に必要になるまでしない。これらを考えた上で、わけの分からない仕様は弾くし、チームが理解できるCJMとかUXとか共有する。
2017/06/01 11:49:53
kasei_san
“新機能を追加するのに、使われていない機能のテストもしないといけなくて、スピードがあがらない” → 典型的な役割分担ができていないコードなのでは...?
2017/06/01 11:53:20
kenzy_n
はなればなれになった顧客との完成イメージを再確認
2017/06/01 11:55:57
rryu
最初に100円以外の時に何が起きるのか、コーラは自動選択なのかを確認しなかったのが失敗の原因だと思う。
2017/06/01 12:02:50
eirun
この場合自販機を取り巻く要望や文化を何処かでドキュメント化してチームで共有すべきで、それは上の役割でしょ。抱え込みすぎる善意の人ほど疲れて離職しちゃうわけで……疲れないようにするのも才能だからお大事に
2017/06/01 12:03:07
moro
わかるわー。そこでリファクタリングするための自動テストであったりするんだけど、まあ難しいですな。僕も「注意深く変化に対応し続ける」音楽性が好きです。
2017/06/01 12:06:48
Nagise
検討するけど実装はしない、リファクタリングしやすくしておく、みたいな言葉で語りにくいテクニックはあることはあるが表現しにくくてしょうがない
2017/06/01 12:11:43
tlync
ユーザーストーリーを洗い出して、ユーザーストーリーマッピングで MVP 決める、ユビキタス言語抽出してドメインモデルが持つ情報、振舞、関連を整理する、これだけでも大分変わりそう
2017/06/01 12:14:05
reachout
まず業務知識が必要では
2017/06/01 12:16:38
ku__ra__ge
拡張性のある設計をするにしても「どこを拡張できるようにするか」は決定しなければならない。その決定に必要なのは業務知識である。
2017/06/01 12:18:12
tokoroten999
普通に業務設計・分析と要件定義が足りないって話なのでは。その状態で開発完了してもプロダクト稼働後の工数考えたら総体的には開発速度が遅いって話になると思う
2017/06/01 12:24:39
hiro_curry
これくらい要件の変化が発生したら、どこかで作り直さないといけないんだろうな。／やっぱり在庫の概念が出てきたタイミングかな。お金を飲み物に変換する機械が、商品を売買する機械に変わった瞬間。
2017/06/01 12:25:46
gnagaoka
“200円でコーラが2本買えること”ー＞ 「それは出来ません、運用で回避してください」と解答するのが正解です。
2017/06/01 12:26:04
taji_hiro
わかりやすい例。 しょっぱなダメだとずっとダメ。
2017/06/01 12:26:09
a_suenami
これはいい話。TDDの提唱する「テストをグリーンにする最低限のコードだけを書く」と「アーキテクチャ的な無駄が最小限になるように設計する」は本質的に反するし、書いてある通り、その間をうまく攻めるしかない感
2017/06/01 12:27:22
azihsoyn
わかりやすい。必要な時にちゃんとリファクタしないと腐っていくんだよね
2017/06/01 12:28:29
Yagokoro
すごい無能感あふれるコードだな。
2017/06/01 12:36:27
mangakoji
ブックマークを削除する コメントを編集する なくて、そのためのAJAXでありXPなんだけどな。日本は未だに人月退治すら始まってない。20年遅れてる。ウォーターフォールこそスーツの神話だが、皆飲み込まれてしまった
2017/06/01 12:37:00
masfj
プロダクトオーナーの真の要望は何なのかを見出さないといけないので設計より前の段階の話ではないかなぁ
2017/06/01 12:37:43
kiyo_hiko
限界効用が減ってくのしかたなさそう
2017/06/01 12:38:13
koogawa
関係ないけど、ビールの在庫が減らないの最高だと思った
2017/06/01 12:40:42
sekirei-9
開発の進め方に対する問題提起としては面白い。コードのレベルが低すぎて批判を招いてるようだけれど…。
2017/06/01 12:41:08
takhasegawa
“動いている部分には極力触るなの精神” て、なんのためのテストコードなのか。
2017/06/01 12:43:12
rti7743
最初からゲームのルールが全部わかっていれば話は早いんだけど、ゲームのルールが後出しで判明していくから困る。
2017/06/01 12:45:17
wonodas
というよりアプリケーション知識を勉強して要求の分析とプロダクトが果たす役割を洗い出すとこから始めればええんやで
2017/06/01 12:46:33
mochi-ha
C言語とかその他基本知識しかないけど、ソースに違和感があった。そっちが気になって内容が入ってこなかった。
2017/06/01 12:50:58
masaru_b_cl
コード書き始める前のTODO作成がないのと、1.Red→2.Green→3.Refactoringの3が抜けてるからかなぁ
2017/06/01 12:51:04
qmanothe
自販機だから誰でも拡張性の想像はつくが、これが現実では特殊なドメインの話であることがほとんど。
2017/06/01 12:51:26
motchang
YAGNIヤグニと唱える。
2017/06/01 12:52:14
Makots
示唆に富む話
2017/06/01 12:54:22
at_yasu
いい話
2017/06/01 12:59:51
swordaq
YAGNI,DRYを守る前提で、テストコードの質を上げておけばリファクタリングしやすくなる、というところからスタートで（これが1番難しいかもしれないけど）その上で、要望と要件は分けて実装してく。
2017/06/01 13:01:06
luccafort
どのくらい抽象化するか？どのくらい汎用性をもたせるか？が本当にすごく難しい。この辺の勘所がうまいひとはエンジニアとしてレベルが高いという印象がある。どうやって鍛えてるんだ…。
2017/06/01 13:03:23
lifeisadog
うちの会社では基本的に顧客が言う実装は無視することにしている。顧客は業務のプロだけどシステム設計のプロではないからだ
2017/06/01 13:05:05
ans42
企画とかすっ飛ばして、いきなり思いつきで要件定義するのか。
2017/06/01 13:17:07
fukken
正しい設計などというものはなく、「どのような変化を想定するか」で設計は決まるので、その部分の予測をしない限り設計などできない。if分岐とポリモーフィズムにも一長一短がある。
2017/06/01 13:19:31
securecat
一番最初に、コーラがどこからやって来るのかに言及しないのが謎。自販機が何かを知らなかったとしても、コーラがどこからやって来るのかには言及できるはず。100円からコーラを錬成するんじゃないんだから。
2017/06/01 13:23:14
okbm
ええ話
2017/06/01 13:25:47
Soraneko
テスト？🤔
2017/06/01 13:37:24
mikage014
現実だと1ヶ月でも1週間でもいいから現場に足突っ込んでくると良かった。真の要件は会議室ではなく現場にある。言葉にすると伝わらない肌感覚もある。
2017/06/01 13:44:37
dagama
モブプロってのが何を目的にしてるのかわからないけど、脳死コーダーが適当にコード書くとプロジェクトが壊滅するということは実証できたな
2017/06/01 14:02:11
hiro_87g
わかりやすい
2017/06/01 14:08:29
ravelll
"だから、何かに気づいたときに、それを元に全体をリファクタリングする。できるようにしておく。というのが大切なのかなって思った。"
2017/06/01 14:12:51
moons
100円入れたらコーラがでる自販機で200円入れてオレンジジュース出すにはどう操作をするつもりなんだろう
2017/06/01 14:21:10
celaeno_w
これが比喩でなくて本当のストーリーなら、爆速だとかいう「１００円でコーラ売る」の実装時点で、「１００円」が判定されてないし、「売る」も適当なんだから、そりゃそうなるでしょとしか。最初から実装できてない
2017/06/01 14:22:12
takashiski
冒頭から「100円を入れるとコーラがでる」と要件からボタンの存在が消えてる＆100円以外を入れた場合のテストがないということに気づけた
2017/06/01 14:27:24
towerman
「自販機」というものを知ろうとするからうまくいかない。「自販機の利用者」を正しく理解する。そうすれば正しい設計に近づけるし、関係者とも意思疎通しやすくなる。
2017/06/01 14:31:45
umai_bow
例え話なのにコードについてグチグチ言ってる人はなんなんだ。あとXPって結局スペシャリストじゃないとできないでしょ。
2017/06/01 14:48:04
ccoo_nick
動いてる所は触らないの精神はプロジェクトを動かなくする
2017/06/01 14:57:48
Nfm4yxnW8
"自分から「このプロダクトをチームと一緒に良くしたい！」という気持ちは見えなかったなぁｗ" むしろ開発側の能力不足を感じてしまった。プロジェクト変わっても同じ失敗しそう。
2017/06/01 15:00:39
sin20xx
気持ちはわかるし、その感覚は正しいと僕は思う。"あたりまえだろ"という暗黙の了解は必要だけど、それは経験や信頼というものを積み上げてからだと思うし、実開発では不要な機能は実装しない方が実際良い場合が多い
2017/06/01 15:03:24
jhanx
いい記事だなぁ
2017/06/01 15:10:53
kozo002
最後まで木を見て森を見ずだな
2017/06/01 15:29:28
dev0000_1
受託だと、要件定義・設計不足のまま、実装に流れ込んで爆死するって当たり前すぎるのだけど。
2017/06/01 15:34:42
kemononeko
出だしからやばい
2017/06/01 15:35:53
wazly
実装は上からガンガン指示が来るけど、その逆方向のベクトルとなる抽象化は開発者が積極的にやらないと。そういう指示ができる人がチームにいないとどんどん取り返しがつかなくなってくる
2017/06/01 15:48:27
jinjor
TDDをよく分かってないコメントが付いてる。
2017/06/01 15:52:35
drylemon
作ろうとしていたのが「何をするためのもの」なのかが不明なまま進んでいる。この場合はPOから聞きだす必要があったと思うのだけど、ヒアリング(要件定義、設計)にどのくらい掛けて良いのかも分からない構成で違和感
2017/06/01 16:02:46
napsucks
極端な例を挙げてわかりやすくしてるけど、実際よくあることだと思う。自販機なら誰でも知ってるから100円以外でも商品出るなんてありえねーと即わかるけど他の実装では往々にしてこの手の泥縄が。
2017/06/01 16:09:24
hiroyuki1983
魔法の言葉教えたろか？　「運用でカバーしてください」
2017/06/01 16:25:21
s-tomo
オレンジジュース対応した直後にリファクタリングして最初のコードは捨ててしまうべきだった。さっきコーラ書いたばかりなのに？当然捨てるべきだ。ここで捨てられない奴が後でコードを捨てられる訳がないだろう。
2017/06/01 16:34:51
inumax21
(´・ω・｀)
2017/06/01 16:41:47
bk246
勇気をもってリファクタリング
2017/06/01 16:52:57
s-kic
Red→Green→Refactoringのサイクルが崩れてた？リファクタリングの対象はプロダクトとテスト両方だから少なくともコードが取っ散らかるということはなくなると思うんだけど…
2017/06/01 16:57:07
unhappychoice
たいていの場合 Red Green Refactoring の Refactoringをサボりがちだから身動き取りづらくなるのであって、その習慣さえあれば汎用な設計を最初に用意することや、大規模なRefactoringなんてものの必要性は大きくならないはず
2017/06/01 17:32:43
nozipperar
リファクタリングはいいぞ　かなり速くなる
2017/06/01 17:45:10
hisaju
誰のために何を作るかを理解しないままコード書いちゃダメだよね。手法以前の話。
2017/06/01 17:48:21
leiqunni
だから「自販機」がどうゆうものか知っている経験者が優遇されるのですね。
2017/06/01 18:01:52
j-st
大事
2017/06/01 18:18:45
jun_ya
ゲーム開発では企画の人が何を言わんとしてるのかを読み取る謎の「ちょうのうりょく」が必要でそれは「けいけん」で備わるのだ。無駄に30年開発現場でやってるとちょうのうりょくの飛ばし合いがみれてたのしいよ！
2017/06/01 18:30:42
cad-san
TDDのテストの捉え方が変な気がする。設計をドライブするテストだから、満たすべき仕様を考えず、要望だけテストケースに突っ込んでも漏れがでるよ。それじゃ設計してないのと変わらないよ。
2017/06/01 18:47:47
DustOfHuman
適宜リファクタリング、YAGNIな空気を作れば「ギョームチシキ」なんてものの需要はある程度は下がるのでは(ジョーシキのすり合せみたいなのは必要として)　まぁ難しいなあと
2017/06/01 18:53:06
ryo_ryoo_ryooo
この要件以外なにも満たさないコード書ける人は、めっちゃできる人に違いない。普通の人は要件以外の関係ないコードまで書いてしまう。
2017/06/01 19:25:43
chintaro3
最初に予算の概念が無いのがまずマズい（暗黙知として有るんだろうけど）。10万円の仕事と10億円の仕事では何もかもが違う。
2017/06/01 19:34:56
satokumakuma
何はともあれこれじゃないか？ “それと「自販機」というものを知って、早く小さくブレイクスルーを起こすために、POはもっと中から発言をすると良さそうかなー。”
2017/06/01 19:42:21
kojette
リファクタリングやねー。そして、自分が欲しいものを自分で作るのが一番楽だ。
2017/06/01 20:15:59
daibutsuda
#TDD
2017/06/01 20:36:35
snowlong
これを上から目線で語れるのは開発をやったことない奴か天才のどちらか
2017/06/01 20:42:53
shuuuuuny
自販機
2017/06/01 20:44:35
sakichi33
だから最初のヒアリング大事。そもそも自販機って言っただけで「缶ジュースの自販機」となってるのがアウト。切符もあるし新聞もあるし冷凍食品を温めて出すやつもある。その辺をつつきながら仕様確認しよう。
2017/06/01 20:44:35
Dicco
これは面白い。
2017/06/01 20:57:07
hase_done
動いている部分も都度作り変える
2017/06/01 21:19:13
hogetahogeko
コメントが参考になる
2017/06/01 21:31:18
damedom
プログラミング教育で教えるべきはコードの書き方というよりも、こういった概念を実装に落として行くときのジレンマだと思う
2017/06/01 21:56:51
lb501
アップルとMSの違いのようだ。アップルはとにかく捨てる。MSは互換性を大事にすることでセキュリティパッチは多くなる。(今は違うかも)
2017/06/01 22:24:00
lazex
全体的に置き換えると綺麗になるし修正し易いものになるのに、今動いてるとこは絶対に書き換えたくないと言う人のせいでどんどんグチャグチャなヒドイものができあがるんだよね。ムリな増設ほどコストかかってるのに
2017/06/01 22:38:29
ngsw
本旨とずれるかもしれないが「実装者はどうデザインしたいか」なるものは案外重要なのかもしれないなと思ったし「動いてるからいいでしょ」よりは「このパターンは明示的に実装してません」の方が嬉しかったりとか。
2017/06/01 22:42:44
fops
完成後に仕様変更を何度もしたらそりゃ炎上するよ
2017/06/02 00:21:03
TETOS
バグは最悪直せばいい。最悪なのはほとんど使われていない癖エンハンス困難なクソ設計のクソ機能。
2017/06/02 00:25:33
Kuichi
"自販機"という大抵の人は知っているものならいざ知らず、開発案件で作るものってオーダーメイド品だから、そもそも完璧な要件定義は無理だよなあ、って思う。都度リファクタリングしかないのかも。
2017/06/02 02:04:36
tekimen
関わっている業務のドメイン知識とプログラミングの知識とのバランスだろうか。
2017/06/02 03:37:17
toritori0318
このプロセス、エンジニアなら大抵通る道な気がする
2017/06/02 11:05:43
ryota-murakami
実例に具体的なサンプルコードを提示しているエントリは認識のズレから正じるWebの不毛な議論を避け、建設的な議論を齎す貴重な存在だと思う。
2017/06/02 14:12:00
mather314
やってることはTDDで、このモブプロで開発している「価値」が単機能のレベルになってませんかね…？五月雨で要求が出てくる開発じゃなくて目的の共有とバックログの優先度付けをして何を作るか見通しを立てるべき。
2017/06/02 17:16:29
risouf
根本的にはゴールイメージが共有されていないことが問題のように見える
2017/06/02 17:48:46
tettekete37564
もの凄いあるある感。結局マネジメントと同様､最初にステークホルダーとアクティビティーを全部集めてゴールを共有することが大事。
2017/06/02 20:21:48
nisisinjuku
未来に起こることを予見して備える。仕様整理してから着手。クライアントの話をよく聞きその近辺に潜む闇を認識し潰しこんでおくこと。だいたいそんなんでなんとかなると思うのですが、開発は早くなるかは知らない。
2017/06/02 21:42:22
niship_0822
変化の速度よりも「変更容易性の確保」か。
2017/06/03 10:51:14
uxlayman
闇が深すぎる。自販機ってお金を入れてボタン押すんやろ。なんでその2つが入力にならんの
2017/06/03 11:49:39
AKIY
要件を確認して整理するとか、業務を理解するとか、スコープについて折衝するとか、そういう開発手法以外の要素が欠落していないか。やり方はスクラムでもダメなウォーターフォールと本質的に同じ。
2017/06/03 13:21:40
kita-tuba
だんだん開発スピードが遅くなっていくのをどうやってとめたら良かったんだろう？
2017/06/04 12:10:47
hoozuki37
こうやって開発速度どころかバグ対応すら硬直化したクソ設計が未だにでかい顔で居座っている業界、他にもありますよね（製造業とか）
2017/06/04 19:24:29
teruyastar
物語の始まり「スイッチ」と結末「取り出し口」だけ把握して、物語途中の追加キャラ「お金」「種類」「在庫」で話膨らませ。物語矛盾(if文)を極力減らすためキャラごとに章完結しておいて物語が結末いけばOKみたいな?