開発者同士を競争させたほうが良い ? 76
ストーリー by reo
その金額に見合う成果が確約できるならば… 部門より
その金額に見合う成果が確約できるならば… 部門より
ある Anonymous Coward 曰く、
本家 /.「Better Development Through Competition?」より。
Derek Sivers 氏がなかなか興味深い「アイデアを現実化するためのプログラマーの雇い方」を提案している。それは「一つ目のプログラミングマイルストーンを達成するまでは複数の開発者を雇い、競争させる」というもの。前提には「成功するもの、失敗するもの、そこそこなもの」があるとの考え方があるとのことで、良いものを見つけ出すための複数雇用にはそれだけの価値があるという。
この考え方は新しいものではなく、30 年前に書かれた Tracy Kidder の「Soul of a New Machine」でも言及されているが、幅広い支持を得ることはなかったとのこと。開発者同士を競争させる「プログラミング合戦」は良い開発モデルたり得るだろうか ? /.er の皆様の考えをお聞かせ願いたい。
局所最大化 (スコア:5, 興味深い)
昔、2チームで競ったことがありました。
最初しばらくは良い意味での競争があって良かったのですが、
しばらくすると、お互いに相手の長所がわかるので、
「相手の長所を真似た上で、少しだけ良くする」戦術が幅をきかせてしまいました。
結果、お互いに極めて局所的な最適化を繰り返し、
妙に同じようにバランスが悪いコードが2つできあがりました。
Re: (スコア:0)
「相手の長所を真似た上で、少しだけ良くする」
最近のIntelの戦略そのものじゃないですか。VIAつぶし、ARM系ベンダー対策のための省電力強化とか。
たぶん潰し合いには向いてる戦略なんだろうなと思いました。
（潰しきった等の理由で）相手がそこそこの期間で変わっていけば長所も変わるので有効かも？
原文読むのが面倒な人へ (スコア:5, 参考になる)
雑談サイトなんで、別にタレコミ文だけ読んで印象で書き込んでも悪くはないけどさ。
元ネタになってるDerek氏のブログはこういう話だよ。
* ナイスなwebサイトのアイディアを持ってるけど、本人はプログラマではなく、プログラマを雇う伝手もない、という人向けのアドバイス。
* まずは自分のアイディアを煮詰めて、最低限必要なとこまで機能を削ろう。それをversion 1.0の目標とする。
* version 1.0が何をすべきなのか、ユースケースも含めて簡潔にまとめよう。
* 自分がイメージする画面遷移を具体的に書き下してみよう。
* version 1.0の機能をさらに複数のマイルストーンに分割しよう。ひとつひとつは1日以下で出来そうなものがいい。
* 最初のマイルストーンを、ひとつの独立したプロジェクトの体裁にしよう。検収要件を明確にするのが肝心。
* そのプロジェクトを、いくつもの求人広告サイトにポストしよう。
* spamっぽいofferを除いた中から、評価なども参考にして複数のofferを選びだし、最初のマイルストーンを作ってもらって報酬を払おう。
* 満足の行くものが出来てこなかったら、プロジェクトの記述をもっと詰めるなどしてまたポストしよう。
* 良いものを作ってくる開発者に巡り会ったら、その人にプロジェクトの全容を明らかにしよう。
こういう前提ならまた議論も違ってくるんじゃない?
Re:原文読むのが面倒な人へ (スコア:1, おもしろおかしい)
> これが出来る時点でプログラマだと思います。
でも
> * version 1.0の機能をさらに複数のマイルストーンに分割しよう。ひとつひとつは1日以下で出来そうなものがいい。
これが出来る時点でプログラマじゃないと思います。
サムスン (スコア:3, 参考になる)
こないだ読んだ「日本『半導体』敗戦」て本に書いてましたが、
サムスンが、まさにその競争をやってるそうな。
２系統どころか５だか８だっけかの結構な数のチームで半導体設計させて、
最も優秀なチームのを実際に製造に回すらしいですよ。
Re:サムスン (スコア:2, すばらしい洞察)
＞２系統どころか５だか８だっけかの結構な数のチームで半導体設計させて、
日本では、5だっけか8だっけかの結構な数の会社に携帯電話を作らせて、
死にものぐるいの競争をさせてるんだとか。
＃シャレになってない。
Re:サムスン (スコア:1)
そこまで多いと、チームが1回まるまる怠けてもバレないのでは。
1を聞いて0を知れ!
Re:サムスン (スコア:1)
チームが5だか8だかある会社でそれはありえないでしょう。
社員の8割が裸で土下座とか……
1を聞いて0を知れ!
競争ではないけれど (スコア:2, 参考になる)
このときの理由は、"API のテスト"。
違うプログラマに API を扱わせることで、API の動作を証明する、というわけです。
それぞれが好き勝手に作ったので、オリジナリティが出て、面白かったですね。
仕事の話なので AC 。
コストは？ (スコア:2, 興味深い)
並列で雇ってペイする効果があればいいんですがね。
個人的には、開発初期は色々なものが変化するので、効果は疑わしいと思います。
時間が許すなら、同じチームにコードを捨てて1から作り直しさせた方が
良い物が作れると思います。
「競争させる」と言えば聞こえはいいけれど (スコア:2, すばらしい洞察)
# ライバルがいることによって能力を発揮する人もいるでしょうけど
# 一人に完全に任せることでより頑張る人もいるでしょうし
# 開発者が全部同じ性格かのように捉えている方法論はあまり好きではありません。
# yes, fly. no, fry.
職場の雰囲気や人間関係によると思う。 (スコア:2, すばらしい洞察)
競争する意義が共有されていて、かつ、楽しめる雰囲気でないと（切磋琢磨出来る環境でないと）
「無駄なことをさせられている感」が蔓延して破綻すると思われます。
コンペ？ (スコア:1, すばらしい洞察)
複数に同一課題を出して、製作者それぞれが複数提出した作品数十点から最も良いモノを使う方式。
でも開発は最低でも数ヶ月単位の長い時間がかかるし、仕事に対しての責任が明確でないと絶対にダレる筈で。
それと何が良いかをどうやって検証するんでしょうかね。
芸術作品ではなく工業製品なので、外観より隠れた欠陥が無いことが重要なのは当然で、全部調べるのは大変ですよね。
そして失敗の原因は設計や打ち合わせ上の問題が多く、ラインだけを複数にしても良い結果は得られないと思います。
仕様を別々の人が作成して完成後お互いがチェックし欠陥がが無いか確認しつつ一本化するのはアリかもしれませんね。
仕様上の問題の洗い出しやメンバーが全体像を把握できますし、後進の教育に役に立つような。
#もっとも実際にやってみると色々問題がでるのでしょうが
Re: (スコア:0)
正常系だけ1,2週間でぱぱっと作って選抜し、あとはそれをみんなで工業製品に仕上げていくのかも
あれ、でも優秀な開発者なら UnitTest で機能もしっかり確認してるだろうから、あとは結合テストだけか？
Re: (スコア:0)
>失敗の原因は設計や打ち合わせ上の問題が多く、ラインだけを複数にしても良い結果は得られない
>仕様を別々の人が作成して完成後お互いがチェックし欠陥がが無いか確認しつつ一本化する
競争するのは、そういうことより遥か上流のプロトタイプや、仕様策定段階以前の話だろう。
仕様を詰めたり欠陥を洗い出す、いわば磨き上げる段階ではもう仕上げるべき形が決まっているべきで、そこに方向性を競う余地などない。
そしてその完成形の修正は後になればなるほど容易ではなくなるから、早い段階で複数の案を競わせて、より良い形を導いておくべきではないか。
短くまとめれば、ＳＥを自称するような無能どもこそ、無駄足を踏むこともいとわず泥のように働けということだ。
はあ？ (スコア:0)
Re:コンペ？ (スコア:2)
対語は「馬車馬のように眠れ」ですね
Re:コンペ？ (スコア:1)
つか、泥ってべつに働いてないよね。
そんなリソースありません (スコア:1, すばらしい洞察)
採用しない開発ラインを抱えられるほど
金も人も時間もないってのがほとんどなのにっ
だれもIntelのような真似はできないわ
お試し開発 (スコア:1)
開発者の能力を見るために、何かを試しに開発させれば良いのでは？
共通のプログラムでやる必要もない事だから、開発モデルにゃならん。
the.ACount
CDC 8600とSTAR-100とCRAY-1 (スコア:1, 参考になる)
結局CDC 8600はキャンセルされ、ソーントンの設計が完成し商品化された。クレイはCDCを辞めクレイリサーチを設立し、CRAY-1の設計に取りかかった。
実アプリではCRAY-1がSTARとその後継機を性能で圧倒し、クレイはまたもや天才の名をほしいままにするのであった。
AKB (スコア:1)
「もし高校野球の女子マネージャーがドラッカーの『マネジメント』を読んだら」にも似たような話があったな。
野球部を3チームにわけて練習成果を競い合わせるってやつ。。。
すぐれた作品を集めるのに、コンテストを開いて互いに競わせた結果、安くいいものが手に入るっていうのはあると思うから、
競わせるという手法は悪くない気がする。
もちろん、罰則やペナルティはナシで。
by rti.
秀吉の一夜城が最初に思い浮かびました (スコア:1)
同じものを作らせる必要はないと思いますがライバルは必要でしょうね。
なんだ (スコア:0)
ジャッジメント (スコア:0)
２：６：２ (スコア:0)
「成功するもの、失敗するもの、そこそこなもの」
これは2:6:2の法則のことかな？
それだったら上２選別しても下２切っても、その2や8の中で2:6:2が発生するんだぞ～
なんでって、そりゃあ日々実感するところだよねぇ？
Intelのケース (スコア:0)
Re:Intelのケース (スコア:1, 参考になる)
かつてはハイパフォーマンスとローパワーの分担であり
今は開発サイクル短縮のための複数ライン化なので
ひとつのターゲットに向けた競争とはちょっと違う。
タブはスペースですかタブですか4ですか8ですかエディタは言語は (スコア:0)
集めたところで無意味な宗教論争ばっかりやるので
時間の無駄でしかありません
Re:タブはスペースですかタブですか4ですか8ですかエディタは言語は (スコア:1)
成果物を比べれば良いだけだから、似たような宗教観を持つグループにわけとけばいいんじゃないすか。
それで、お祈りの時間や食事のタブーも問題無し(違
Re:あの・・・ (スコア:1)
Visual Studio だとタブがスペース4個になったはずです。
VB6はそうでした。今はどうだかわかりませんが
３人寄らばなんとやら (スコア:0)
どうせ同じ人件費をかけるなら
ペアプログラミングのような、相乗効果を狙う手法の方が
よほどいい物が出来そうな気がします。
Re: (スコア:0)
「文殊の知恵」になるか、「いじめが発生」になるか。
{チームの士気|人間関係|モチベーション|組織の文化}次第ですね。
競い合ってお互い伸びるか、足引っ張り合うか・・・
後者が発生しないような組み方をしないと。生存競争にしちゃあまずいと思いますね。
実践しています (スコア:0)
ええ、先日もオフショア先のメンバーに、似たような機能なので二人で相談して作成してください、と作業をお願いしたら、二人とも別々に好き勝手に実装したらしきものを送ってきました。
出来栄え？どちらもクソった（以下自粛
Re: (スコア:0)
クソになったのは彼らのせいではない。あなたのせいだよ。
Re: (スコア:0)
そこまでやるぐらいなら自分でやった方が早いし確実だし。
前提として (スコア:0)
アメリカのように簡単に解雇できる法的環境が必要じゃない？
日本では一旦雇ってしまったら、首にするのも大変だからこういう手は使えないかと。
Re:前提として (スコア:2, 興味深い)
いらない人とよくできる新人を競争させて「君は何年もいるのにこんなのしかできないのか」とネチネチ言って自主退職に追い込む、という手も。
1を聞いて0を知れ!
Re:前提として (スコア:2, すばらしい洞察)
なるほど。開発者2人に同じもの作らせた場合は、自分のではなく相手のをテストするとよさそうですね。
1を聞いて0を知れ!
Re:前提として (スコア:2)
＞一旦雇うと首にするのが大変なんてコトは現実はないよ。
＞バブル以前、造船・繊維・鉄鋼業界が盛大にクビ切り合戦をやってのけたんだけど、
論点がズレてる。あるいは曲解している。
会社が著しい業績悪化で経営破綻もヤムなしとなった時に、労使双方の合意で大幅な解雇が
行われたこともあるのは事実。最近話題になったといえばニッサンか。しかしそれが出来ずに
破綻したＪＡＬのような反面教師もある。トヨタだってある意味同類。業績悪化しても正社員
という聖域はろくに解雇できてない。
で、さらに通常話題にする「解雇が難しい」というのは、通常の経営状態で、
パワハラとかなしに、法律に則って合法的に解雇するのが難しいという話。
「あなたの成果はビリから5番目なので、当社としては必要ないと判断した」と
ある日突然部長が社長からクビを言い渡される心配はまずないのだ。
ちょっと毛並みは違うが (スコア:0)
競争も何も (スコア:0)
下請けが作ったプログラムがヘタレすぎて全部作り直してますが何か？
君だよ君
Re: (スコア:0)
要件も受入基準も明確にしていれば、そんな事にはならない。
状況は途中で分かるし、最悪でも金は払わずに済む。
この業界、管理放棄してる管理者ってかなりいるよね。
君だよ君
Re:競争も何も (スコア:1)
＞要件も受入基準も明確にしていれば、そんな事にはならない。
要件も受入基準も明確にできる人がいなくなって久しいから、
「そんなこと」が毎度のように起こっているだけでは。
「相手の長所を真似た上で、少しだけ良くする」戦術を取ってきた結果、
今や誰かの真似をするばかりで自力で考える能力を持たなくなったのは、
なにも開発者だけではないのだと。
Re: (スコア:0)
Re: (スコア:0)
要求してきやがって、そのせいで四苦八苦して、やっと収めたものをぼろくそに
いう発注元。
アプローチ別に (スコア:0)
それって、後々の持ち駒の幅が広がるだけの話であって、マイルストーン達成には糞の役にも立たないよね？
一応ライバルチームを意識すれば早く仕事進むのか？誤差程度だろ。
倍近い開発費掛けて無理させてまで早く仕上げなきゃいけない仕事なんてある？
つーか、そんな納期を設定した営業のクビを切るのが一番最初だと思うよ。
何を今更のばかばかしい話です (スコア:0)
対外的に余裕がある時は効果が出ても、余裕がなくなってくると効果がなくなり、
挙句の果てに整理統合の際にあちこちで混乱を招いた。
PC-PRxxxxとNMxxxxとかとか。
Re:何を今更のばかばかしい話です (スコア:1)
> かつて、日本企業のそこここで見られた状況ではないでしょうか。
シャープの X1 と MZ とか。
競合はしてませんが、ビジネス向けパソコンのPC-3000シリーズなんてのもあったので、
それを入れたら、パソコンが社内に3ラインもあるというすげー会社でした。
あ、ポケコンのPCも入れれば4ラインか…
Re: (スコア:0)
わかります。