超高速な開発ができるわけ Yakst

2017/08/09 15:32:51

k1LoW

これなー。。。

2017/08/09 17:00:22

cu39

「複雑なシステムは、動き始めた後にそれを解明するよりも、作る方が簡単である」

2017/08/09 17:55:13

versatile

これな、、、

2017/08/09 18:28:49

tsz

これな…

2017/08/09 19:26:47

tofu-kun

なるほど

2017/08/09 19:52:36

okbm

“10倍の生産性で開発するべき時と、チーム開発すべき時があるということです。真剣に開発したい時には、10倍の生産性で開発する開発者は邪魔になります。そういった時には、この記事に書かれた提案のことを考えてみ

2017/08/09 20:34:16

suginoy

“複雑なシステムは、動き始めた後にそれを解明するよりも、作る方が簡単であるということを表しています。”

2017/08/09 21:21:46

lbtmplz

“あなたは合成化学者でDNAを内部から変えることができるのに、彼らは外科医であり皮膚に切り込みを入れて触ったこともない臓器を傷つけないように手術する必要があると考えればよいのです”

2017/08/09 22:07:05

vanbraam

"他の人の10倍の生産性で動ける開発者と状況の組み合わせが本当にあり得るということを知っておきましょう。そしてそういう状況はスケールしないということを知っておきましょう"

2017/08/09 22:07:27

moyacab

"複雑なシステムは、動き始めた後にそれを解明するよりも、作る方が簡単である" だから、一緒に作る必要がある。

2017/08/09 23:08:56

motchang

いい話だ。人月の神話に通じるものもある。

2017/08/09 23:12:30

masterq

"10倍の生産性で開発するべき時と、チーム開発すべき時があるということです"

2017/08/09 23:26:49

nisisinjuku

メモメモ

2017/08/09 23:35:18

tbpg

"「〜なだけ(just)」「簡単(easy)」「明白(obvious)」「単に(simple)」「分かりやすい(straightforward)」といった単語は辞書から消してしまいましょう。これらの単語には背景が必要で、その背景を理解している人などいないのです"

2017/08/09 23:52:03

ono_matope

"Braitenbergはこれを、「下りの発明、登りの分析の法則(Law of Downhill Invention, Uphill Analysis)」と呼んでいます。複雑なシステムは、動き始めた後にそれを解明するよりも、作る方が簡単であると" だよね。

2017/08/09 23:53:50

dev-masahiro

緒先輩方が案件から抜けて、システム生き字引になってしまったワイが読むべき記事や。運用地獄から抜け出せ

2017/08/09 23:54:14

joint1

　うんうん

2017/08/09 23:58:26

hyperpeppy

これはその開発者本人だけでなく、その上のリーダー達にも知ってほしい。その開発者が出してきた見積もりそのままで機能改修を外部に発注するんだから…

2017/08/10 00:00:47

hatest

自分ではホワイトボックスでも、他の人はブラックボックスに見えるということを意識して仕事しろ

2017/08/10 00:18:12

synbizmix

超高速な開発ができるわけ | Yakst @yakstcomさんから

2017/08/10 00:24:05

hush_puppy

なるほど。ポール・グレアムが言っていたことの裏側か。 http://www.aoky.net/articles/paul_graham/head.htm

2017/08/10 01:26:01

sonota88

「真剣に開発したい時には、10倍の生産性で開発する開発者は邪魔になります。」

2017/08/10 01:26:53

psfactory

超高速な開発ができるわけ | Yakst

2017/08/10 02:16:42

tick2tack

"「下りの発明、登りの分析の法則(Law of Downhill Invention, Uphill Analysis)」と呼んでいます。複雑なシステムは、動き始めた後にそれを解明するよりも、作る方が簡単であるということを表しています。"　作り直したくなる理由

2017/08/10 02:18:45

sgo2

受け売りだけど、コードを書くのは1回だけだが読むのは何度も繰り返す。また機械はどんなコードでも読み取ってくれるから、人間に読ませる事に注力した方がいい。

2017/08/10 03:46:32

keijak

わかる。たとえ個の生産性が圧倒的に高かったとしても、チーム全体を育てる方に時間を使ってもらった方がリスクヘッジの面で良い。

2017/08/10 06:15:49

fumisan

日本人ぽくない文章だなぁと思ったら。なるほど

2017/08/10 07:14:06

yamak

これわかるわ。10倍の生産性を持つが非協力的なチームメンバの存在によって、チームの心理的安全性が最悪になって生産性が低い状況に今まさになってる

2017/08/10 07:28:11

turanukimaru

思い通りにできるなら生産性は10倍にもなるが、思いなんてものは結局個人のものだから全体ではそんなにならない。テストを書くのはお勧め。テストコードはサンプルコードとしても機能するから。

2017/08/10 07:52:30

nokogiring

開発に関わるすべての人に呼んで欲しい名文。

2017/08/10 08:05:12

madridNewyork

わかりやすく言語化されてる

2017/08/10 08:30:13

k1take

「10倍の生産性で開発するべき時と、チーム開発すべき時がある。真剣に開発したい時には、10倍の生産性で開発する開発者は邪魔になります」凄腕ハッカーは高速開発できるが、他人に理解不能なコードになりがちかも

2017/08/10 08:31:16

iTaro

“10倍の生産性で開発するべき時と、チーム開発すべき時があるということです” 1度10倍の生産性で開発する快感を知ると、チーム開発が嫌になる罠。俺はもっとできるはずという充足感のない日々に惑わされた過去

2017/08/10 08:35:38

yantzn

なるほどな… 意識しよっ

2017/08/10 08:58:49

tksthdnr

わかっちゃいるけど難しいやつ

2017/08/10 09:06:30

perl-o-pal

知識のシェアって目的ならペアプロじゃなくてもコードレビューとかで良いような気がするが、まあペアプロの方がより良いのかな。

2017/08/10 09:07:14

vndn

『あなたがそのシステムに熱中しているその人なら、「〜なだけ(just)」「簡単(easy)」「明白(obvious)」「単に(simple)」「分かりやすい(straightforward)」といった単語は辞書から消してしまいましょう。』

2017/08/10 09:09:37

atwata

わかる。システムってのは超属人的なもの

2017/08/10 09:22:39

sds-page

最新技術についてこれないおっちゃんにも優しくしよう

2017/08/10 09:22:44

rolw

そのうちAIが全部やってくれる時代になるっしょ。

2017/08/10 09:32:30

Eiichiro

自戒しておこう。

2017/08/10 09:36:37

tinsep19

いま成長して、問題となっているような場面になったので、自分が抜けたチームで作り直してもらいたい。そうすれば下りは発明を彼らに経験させられるだろうか？

2017/08/10 09:42:01

otihateten3510

こういう理想論で何か解決した気になってるエントリーが大っ嫌いだ。皆できないから困ってる。あと「超高速な開発ができるわけ」の解になってない。トレードオフの片方の重要性を主張してるだけ。

2017/08/10 10:08:29

higed

テストを書いてください。テストは、意図せず何かを壊してしまうことを恐れている人が、今からやろうとしていることを試す方法です。

2017/08/10 10:49:10

heavenward

わかりみとつらみが同時に襲ってくる良記事

2017/08/10 11:04:56

tanority

いい話

2017/08/10 11:07:19

hiroponz

分かる

2017/08/10 12:15:06

natu3kan

いろんな人が長時間つづける必要のある仕事であっても、問題が発生しないかぎり属人化しがちなので、他の人が出来るように手間かけて共通化したりマニュアル化するのは大事（実際は時間とコストの都合で属人化する）

2017/08/10 12:36:51

gnt

狭義に限らない話。あと「超高速な開発ができるわけ」は書いてある。「『10倍の生産性』は属人にしてコミュニケーションコストを払ってないことの引き換え(なので、ある場面では超高速な開発は避けるべき悪)」

2017/08/10 12:46:18

adrlife2343

生き字引みたいな人に出し惜しみされると本当辛い。自分が一番貢献しているって顔して、一番罪深いんだよなぁ。うまく賞賛して引き出してチームのものにするプロセス大事。

2017/08/10 13:12:06

lenore

歳を取ると昔自分が作ったものも記憶が薄れてしまうから、そういう意味でもテスト作成＆解りやすいアウトプット必要

2017/08/10 13:37:28

uskey

技術力というハードルなのかプロダクトへの理解というハードルなのか、現場でやっているとまともに判断出来なくなりがちなので心に留めたい

2017/08/10 14:24:17

rjge

“多くの場合、既に誰かが書いたシステムを触る必要があります(「誰か」は「数ヶ月あるいは数年前の自分」の可能性もあります)” 数ヶ月前の自分なんて他人同然どころか他人以上に理解できん存在だからな…

2017/08/10 14:52:29

aq2bq

めっちゃわかる。うすうす心配してることが明快に文書化されている。

2017/08/10 15:32:59

zaki1010

これは重要なのにあんまり意識してなかった…。

2017/08/10 16:07:25

lucifer_af

「他の人の10倍の生産性で動ける開発者と状況の組み合わせが本当にあり得るということを知っておきましょう。そしてそういう状況はスケールしないということを知っておきましょう」

2017/08/10 18:03:50

daikiueda

“「下りの発明、登りの分析の法則(Law of Downhill Invention, Uphill Analysis)」と呼んでいます。複雑なシステムは、動き始めた後にそれを解明するよりも、作る方が簡単である”

2017/08/11 04:48:04

garage-kid

552

2017/08/12 09:01:59

lorenz_sys

正に自分はこのような状況で開発しているがやっぱりそれは続けるべきじゃないと思っていた。この記事の落としどころが自分の考えとまぁ同じだったのでちょっと安心。ただしもうちょっとの間はこの生産性を維持する。

2017/08/12 09:48:01

taky1973

http://www.megamouth.info/entry/2017/08/01/083126 と併読することで生まれるモヤモヤ感

2017/08/12 14:55:21

t2wave

“10倍の生産性で開発するべき時と、チーム開発すべき時があるということです。真剣に開発したい時には、10倍の生産性で開発する開発者は邪魔になります。そういった時には、この記事に書かれた提案のことを考えて”

2017/08/12 23:56:19

sagaraya

“複雑なシステムは、動き始めた後にそれを解明するよりも、作る方が簡単である”

2017/08/13 11:00:29

ohbarye

“他の人の10倍の生産性で動ける開発者と状況の組み合わせが本当にあり得るということを知っておきましょう。そしてそういう状況はスケールしないということを知っておきましょう。”

2017/08/13 14:40:28

oukayuka

わかるわー。とりあえずタイムリミットまでに3を仕組み化したい。5も引き受けようかな。