2017/06/01 12:03:56
moro
これもなー。 http://bufferings.hatenablog.com/entry/2017/05/31/232529 とあわせて読みたい感ある。
2017/06/01 12:13:22
masa_iwasaki
良い。
2017/06/01 13:29:49
t-wada
"品質と速度についてのトレードオフが意識されるとき、実際には何と何が秤にかけられているのか。それは各個人ではなくプロダクト全体の品質と速度が秤にかけられているのではないか" 良い
2017/06/01 13:31:37
tbpg
"技術力のある人はある程度急いで作ったとしても一定以上の品質のコードを書くし、意図的に品質を落としたとしても速度はあまり上がらない"
2017/06/01 13:37:03
mirai-iro
なるほど
2017/06/01 13:37:38
razokulover
"各個人ではなくプロダクト全体の品質と速度が秤にかけられているのではないか。プロダクトの品質を支えるために必要なメンバーの成長とその成長のために必要なフィードバックや学習の時間が秤にかけられているので"
2017/06/01 13:38:28
luccafort
“各個人ではなくプロダクト全体の品質と速度が秤にかけられているのではないか。 ”なるほど、確かにそういうのはある気がする。個人レベルで品質と速度を天秤にかけることがないとは言わんけども。
2017/06/01 13:47:10
sinsoku
良い話だ
2017/06/01 14:05:41
ledsun
「スピード感のために品質を落とす」は実際は「レビューでのフィードバックと修正の時間を削る」こと説。なるほど
2017/06/01 14:13:10
ikngtty
個人の中では品質と速度のトレードオフはあんまり無い。確かにそう思える。鋭い。
2017/06/01 14:35:41
ka2hik0
ズシッとくる話だなー
2017/06/01 14:55:16
nyasba
まさにこれだなぁ
2017/06/01 15:08:22
otihateten3510
トレードオフが意識されるときは大抵納期、期日が意識されているが、成長云々を意識している会社はよっぽど高尚だと思った
2017/06/01 15:36:39
hush_puppy
クソコードを書く人間にレビューで指示されて、速度も品質も下がったことがある。
2017/06/01 16:04:45
calcs
コードの質は大して落ちなくとも、設計の質は明確に落ちるけどね。適切ではないが実装コストの小さいモンキーパッチだらけになったり。
2017/06/01 16:05:36
sds-page
各々好き勝手に書いて規約が統一されてない保守性最悪のソースが出来上がったりな
2017/06/01 16:27:34
yum1271
個人的にはスピードを持って開発・公開し、追っかけで品質上げていくってのをよくやる。最低限何処までやるの？ってのが難しいわけだけど
2017/06/01 17:02:35
yoiIT
いや、天秤にかけるのは想定されるビジネスインパクトでは？品質を重視してリリースを遅らせた場合にビジネス損出があるのか無いのか。
2017/06/01 17:16:23
kaipu1224
弊社程度だとゴミクズみたいなクソースになる
2017/06/01 17:30:09
shag
その時の収穫だけを考えて土壌の管理を怠ると、有機物が減って土が痩せて収穫物の質が落ちる感あるよね。と、たとえ話しようと思ったら完全に農業の話になった。
2017/06/01 17:37:23
younari
競合されそうな場合は先にリリースしないと負ける時が有るから難しいな。二番煎じってよっぽど優れてないと勝てないんだよね。
2017/06/01 17:40:06
hiroyuki1983
「客」とか「ビジネス」という単語がひとつも出てこないところに違和感を感じた
2017/06/01 17:44:05
miragestlike
腑に落ちた
2017/06/01 17:51:07
hisaju
こういった議論でよく忘れがちなのが、プロダクトは売れなければ続かないってこと。予算と時間軸を把握した上でその時何をするのがベストかを落とし込まないといけないので一概に何が正しいとは言えないと思う
2017/06/01 17:55:49
okinaka
社会人２年目とは思えない視点。
2017/06/01 18:01:47
hiro_curry
効率化のためにはコーディングや設計の時間「以外」を減らせという話。
2017/06/01 18:05:05
yoshikidz
メンバーの成長かー。たしかに成熟度に合わせて深い視点で対峙する点が増えてくるから、納得はするかも。スピード感もって同じことやりまくってたら疲弊する感じはイメージできちゃうわ。新しいことならおもろいけど
2017/06/01 18:10:14
mmmpa
そもそも質を上下させる方法がわからない。(意識的に下げるのめちゃくちゃ難しいのでは)
2017/06/01 18:20:32
sigwyg
Web界隈でいうと、「技術的チャレンジの余地がなく」「延々と要求仕様だけをなる早で納品し続ける」作業はキャリアの無駄なので、優秀な人から離れていきます。 いやだって再就職で評価されないもの。
2017/06/01 18:30:30
carrier_pigeon
よく分かる。属人化が進んである所でにっちもさっちも行かなくなるとか。テスト、リファクタ、ドキュメントをサボって気がつくと手のつけようのないレガシーになるとか。技術が固定化して波に乗れなくなるとか。
2017/06/01 18:45:26
peroon
レビューによりお互いを高め合う
2017/06/01 18:53:12
n-channel
売れるものを作った人が、一番偉いということは揺らがない。たとえ箱の中身がクソでも。
2017/06/01 19:08:32
khtno73
これ「品質」がひとくくりだからアレなんだと思うのよね。
2017/06/01 19:19:00
landi
レビューやフィードバックはある意味そのチーム・会社の文化であって、プロジェクト毎のスケジュールで変動するものではないと思うのだが
2017/06/01 19:19:46
versatile
最近エンジニア界隈はこの手のパワーワードで煽るのが流行しておるわい
2017/06/01 19:28:33
Rishatang
「売上が上がらなければ死ぬ会社vs腕が上がらなければ死ぬエンジニア」の構図。転職先が決まってから不満があったことを告げるエンジニア多いので、この事は会社としても知られた方が双方幸せなのでは
2017/06/01 19:38:31
lovevoiceryu
Web界隈の人はサービスの開発がコーディングだと思っているのか。トレードオフになるのはテストだと思うんだけど。社会的に重要でないものなんてそんなもんなんだろうな。
2017/06/01 19:41:30
yug1224
スピードと品質は両立出来ると思っている
2017/06/01 19:42:44
confusion8
スピードと天秤に掛かるのは機能数と完成度でしょうよ。品質と天秤にかかるのはコスト。
2017/06/01 20:08:04
tick2tack
“実際には完全なトレードオフではないと思っている”　いろいろ興味深い視点が。
2017/06/01 20:30:23
newmind
逆に個人の成長スピードがプロダクトの品質や開発期間に影響を与えかねないってことで、 メンバー選定は非常に大事。
2017/06/01 20:47:10
trade_heaven
でも成長したらやりたい事がある、とかここでは試したい事ができない、とかいって辞めちゃうんでしょ？
2017/06/01 20:51:51
supu6000
トヨタも、品質の上げ過ぎに注意してる。時間もコストも品質もみんな大事！最も大事なのはバランス！！！
2017/06/01 21:03:14
hyphenkorosi
分析仕事をするとき、スピード重視のため、小手先で、分析はそこそこの資料作ると、数はこなせても見る目が養われない。スピード重視は、ビジネスに影響のない、誤字脱字とか罫線のズレを無視することに向けたい
2017/06/01 21:11:59
ryuukakusan
小難しいね
2017/06/01 21:35:24
dgen
開発とかクリエイティブな部門は個人の力量差が出やすいから、それぞれが力量に合ったスピードとクオリティで進められると一番良いんだけどね。
2017/06/01 21:37:32
tiisanaoppai
レビューコストはプロテクトしろ。絶対だ。
2017/06/01 21:38:40
nisisinjuku
記事読んでないが、納品日を守る＝最低限の品質を放置するのは趣味の世界でしか許されないことでは？成長はそういったあたり前の品質保持も含めた業務をベースにしていかないと継続不能になるのではと思うがいかが？
2017/06/01 21:43:31
nymc
ビジネスの展開まで見据えた計画が出来るような信頼できるヤツが言うなら何でも通りますわ
2017/06/01 22:10:24
master-0717
速さと安さと品質の優先度はビジネス環境次第
2017/06/01 22:12:41
kei_0000
コードレビュー実施→技術力UP→品質の高いコードが素早く完成→新機能リリースサイクルが向上→売上利益も向上→みんなハッピー　と簡単にいくケースは少ないかもしれないが、トライする価値はある
2017/06/01 22:20:49
imash
納期守れて要件満たせてバグもほぼないので品質高いッス(スピード感のために拡張性やら柔軟性やら性能とか最低限な感じで、ソースのコメントとか設計書とか色々アレだけど)
2017/06/01 22:24:17
aceraceae
まあ当然で、職人が品質のために時間をかけるというのは本来は当たり前。でも納期絶対主義があるかぎり、やっつけ仕事はなくならないよ。
2017/06/01 22:29:51
khei-fuji
ビジネスチャンスとその後のエンジニア離職率のトレードオフ、か
2017/06/01 22:35:22
z_dogma
スピードのためにコード品質を犠牲にすると将来的な開発スピードが逓減するし、チーム内共有を犠牲にすると属人化しジュニアが育たない（チームとして成長しない）状況になる、だと思うのでややタイトルちぐはぐかも
2017/06/01 23:05:40
takazoom
これ読んでピンと来ないってことは、あんた幸せだよ
2017/06/01 23:06:10
hiroharu-minami
まーたシバキ系自己啓発野郎の小言かよと思ったら全然違ったｗ
2017/06/01 23:39:19
suzuxa
スピード感のために品質の落ちたコードを読まされるということは個人の暗号解読能力が成長させられるということ。もう諦めたい。
2017/06/01 23:48:55
madridNewyork
スピード重視しすぎてドキュメントと昼飯すっ飛ばしてる
2017/06/01 23:59:28
tail_y
“スピード感のために品質を落とすということはチームの成長を諦めるということ”／まあそうだよね、設計できない人増えちゃうよね。
2017/06/02 00:01:54
ikarab
速度≒コストと捉えれば汎化できる
2017/06/02 00:07:04
pzp
コードの品質良くても極悪なビジネスやってるし。品質悪くても成長して世の役に立ってるビジネスはある。
2017/06/02 00:09:07
carrotsword
品質ってそれじゃないんじゃないの・・・
2017/06/02 00:22:13
verda
スピードも行き過ぎると やるべきことをやめることで時短をしはじめるしね
2017/06/02 00:22:27
firebook2016
確かに。
2017/06/02 00:31:23
ustam
「スピード感」が破滅への近道でしかないことを我々は『三匹の子豚』で学んでるはずなんだけどね。 そもそも「感」ってなんだよ「感」って。声に出して「ビューン！」とか言っちゃうの？
2017/06/02 00:32:35
s-tomo
とりあえずは今非常にスピード感があるこのリポジトリ( https://github.com/tootsuite/mastodon/commits/master )に注目したい
2017/06/02 00:49:58
feel-think
物を売って利益を出さないと次はないのだから、そのために何が必要か考えればよいのではないか。
2017/06/02 00:52:15
pero_0104
タイトル泣いた
2017/06/02 00:58:19
yoshiko_pg
“技術力が高くない人が時間をかけて作ったとしてもその人の技術力以上の品質のコードは書けない”
2017/06/02 00:58:53
y_koh
スピード感は速度以外でどうにかできることもあると思う。
2017/06/02 01:06:39
ryu39
品質を落としてスピードを上げる場合のトレードオフは、個人やチームの成長の他にメンテナンス性があると思う。スキルが低い人の場合に顕著。謎な名前の変数、if文だらけの巨大なクラス、テストコードのない実装、等
2017/06/02 01:08:05
babandoned
開発速度を求められるとき、短期的売り上げ機会獲得と市場早期提供による優位性獲得の2種類のケースがあり
2017/06/02 01:59:10
fumisan
プロダクトを作る際にはそのときに持っている技術を消費するのです。 プロダクトの品質をメンバの成長は寄与しません。そうであれば、どんなプロジェクトでももっと研修に行かせているはずです。
2017/06/02 01:59:21
cheapcode
「品質はあげる」「スピードは落とさない」どっちもやらなきゃならないのがプログラマの辛いところだな
2017/06/02 03:57:20
airj12
品質を「作りの筋の良さ」と見るか「不具合の少なさ」と見るかでも感覚違いそう
2017/06/02 07:17:08
yantzn
レビューの時間は削りたくないなー
2017/06/02 07:47:33
uturi
品質を落としても直ぐには分からないしな。じわじわと改修しづらくなり、事故る確率上がるだけ。スピード感を上げた方が短期的な売上は上がる。
2017/06/02 07:52:18
g-yamakei
おしごと
2017/06/02 08:04:49
taguch1
安いうまい早いを延々と要求される職場は長くはいれない。だってつまんないし。
2017/06/02 08:17:07
Dai44
稼げるお金の試算があまり変わらなければ芸術作品ではないのでやりたいこと諦めて工数減らすことはある。でもメンテ性落としたり問い合わせ増やす雑な仕事をすることとは違う。「品質」ってビッグワードなんだな。
2017/06/02 08:55:10
quick_past
アジャイルだとか言いながら無茶な線を引いて、シーケンス図一枚で手当たり次第に実装した挙句、変化する事態に対処とばかりに動かない機能から塞いでいき、要求品質さえ満たせないゴミ作る部署に放り込まれた事ある
2017/06/02 09:01:19
yfujisawa
機能を取るか見た目を取るか問題もあるし、ここで言う品質ってなんだろう？見た目やカタログスペックのためのチケットや、皆が価値を納得できないチケット、ダメな優先順位とかは、商品もチームま毀損する。
2017/06/02 09:02:19
shinosaki
本当にこれ。僕はシステムではないけど。同じ。
2017/06/02 09:04:59
shoma2da
まともなチームがなければプロダクトなんてそもそも作れないから、チームの成長にまずは重点を置きたいな。って最近ちょうど思ってた。
2017/06/02 09:07:50
sai0ias
案件にもよるが、スピード感ってプロトでもいいから見える形にして、そこから改善していこう、っていう思考に近いと思ってる。時間かけて品質低い完成品出すより、早く出して指摘もらって直したほうがいい。
2017/06/02 09:11:00
tak4hir0
スピード感のために品質を落とすということはチームの成長を諦めるということ - ネットの海の片隅で
2017/06/02 09:33:42
tettekete37564
スピード感の名の下に設計をおざなりにするからな。こういったケースで問題なのは先見性の低さである。だからスピードが必要と勘違いする。スタートアップ企業が存在しないライバルに怯えて自滅していくのと似ている
2017/06/02 09:46:00
windish
そうですね。としか言えないので、そうならないためにどうするかを考えたい
2017/06/02 10:00:46
Rela24
この考え方、忘れてしまいそうなのでメモしておく
2017/06/02 10:08:05
kozy4324
例えばバグを埋め込まない「当たり前品質」なのか、UI/UXを作り込む「魅力的品質」なのか、そこズレると不幸せな気がしてる。前者はこの記事に同意で後者はリーンとか考えると状況によるんじゃないかなーと
2017/06/02 10:16:54
dev0000_1
スピード感は若い頃じゃないと身につかないと、アニメーターのおっさんが言っていたよ。
2017/06/02 10:31:29
gimutokenri
まじでこれはこのとおりだと思う。
2017/06/02 14:35:47
koyancya
つらくきびしくなくなるにはどうしたら良いのか -> "現実世界はつらくきびしいので"
2017/06/02 14:57:25
june29
「我々は、成長する存在である」という前提に立つかどうか。
2017/06/02 14:57:45
n314
え、速度優先で品質を意図的に落とすこと割とあるけど…。コピペしたり、この設計は現状と合ってないと思いつつそのまま拡張したり、未使用なものをスルーしたり。CSSとか画像レベルだと未使用なもの放置が多い。
2017/06/02 19:09:27
rjge
“品質と速度についてのトレードオフが意識されるとき、実際には何と何が秤にかけられているのか。 それは各個人ではなくプロダクト全体の品質と速度が秤にかけられているのではないか。”
2017/06/03 10:22:22
aroma_black
"プロダクトの品質を支えるために必要なメンバーの成長とその成長のために必要なフィードバックや学習の時間が秤にかけられているのではないか"
2017/06/03 12:40:27
Nahoo
速さか品質か，個人の問題としてどっちだろうってのはいまだに悩んでるけど，チームとして考えると…なるほどってなる
2017/06/03 16:08:53
braitom
“プロダクトの品質を支えるために必要なメンバーの成長とその成長のために必要なフィードバックや学習の時間が秤にかけられているのではないかと思う。”