【画像】有識者「ソフトウェアは人数少ない方が速く作れるぞ」👈本当? [237216734]
■ このスレッドは過去ログ倉庫に格納されています
人数が多いのが問題なのではなくて、中抜きして何社も挟むのが原因なのでは? 5人で1ヶ月かかるのが、1人なら3ヶ月みたいな感じ そりゃ、規模が大きくなるにつれ人数は多くなるからな。 👩🏿🔧 ムン 👩🏽🦲 ソン 👩🏿💻 ミョン 🪑 ≒ 🙅🏻 ㋚ 🙍🏼 た 🤾🏻♀ ㋞ 💁♀
· そのとおりで、
少人数のものがずらりと並ぶ。
フォトショップは兄弟ふたりが開発した。
1975年にマイクロソフト立ち上げの原動力となったBASICは、
ビル・ゲイツと中高で一緒だったポール・アレン、
そして、
ハーバード大学1年生のモンテ
統 一 教 会 は セ ッ ク ス 教 団 !
日 本 女 性 の 全 財 産 搾 取 & 性 奴 隷 化 !
👵🏻 ハン 🏜 ハク 🏦 チャ 💇🏽♀ @ 💁🏾♂ ㋚ 🐱 た 🍸 ン 🥢 規模によるんじゃない
大規模システムはどうやったって大人数が必要になるし みずほ銀行19年の苦闘…開発費4000億円以上“IT業界のサグラダファミリア”完成までの歴史
ビジネス 更新日:2021/8/24
35万人月、みずほ銀行システム統合の謎
岡部 一詩 日経FinTech 山端 宏実、中田 敦 日経コンピュータ そんなもんソフトウェアによるだろ
極論ゲームソフトなんかめちゃくちゃ多分野な能力いるじゃん システムはそうだろ
あんなもん1000人の凡愚より1人の天才の方が簡潔でまともなものができるわ へー
そうやってcocoaは完成したんだね。
へー・・・( ̄0 ̄) ニコ動改悪改悪で糞になり続けてるけど
なについに自分達はすごいって話始めたの? 数年前にどっか大きな会社が言ってたような
大きくすると引き継ぎや教える時間が増えるから少数のメンバー固定でやったほうがいいみたいな話だったな
その理屈なら大きくても最初からメンバー固定でやりゃええとは思うが抜ける人が出てきたりすんやろね 作るの定義次第だよね
その後の保守やアップデートまで考えると色々大変 それはメンバーがこういう人ばかりでそもそもコミュ力に乏しいからだろう
https://i.imgur.com/PuHVZId.jpg
コミュ力も実力もあるメンバーが集まれば素早く良いものができる 伽藍方式ってやつだな
2000年ごろに話題になってたけど
今のITが一般化した世の中には合わないだろう 50人×10日<<5人×100日
とかそういう話じゃないの? 日本でも自動車工場とかは物凄い人数が効率的に動いてるんだから
ソフトウェアでそれができないとしたらマネージャーが無能なだけだと思うけどな UNIX騒動だな
UNIX板以外はゴミと思い知らされた 特に意地の悪いQA
使わない方法でクリティカルバグしてる?
そんな使い方絶対に絶対にしません
マジ一言も言わず死んでてほしい >>34
5000人×1時間 < 500人×1日 < 50人×10日 < 失敗の壁 < 5人×100日 ソシャゲの立ち上げなんかはそんな感じも多いみたいだよね
メインの人が抜けてソースいじれなくなるとかさ そりゃあ早くは作れるけど
四人で作ったとされる
メジャーパーフェクトクローザーの結果は 他人が書いたコード読むの苦痛だしな
複数人で作るほど全体を把握する人間がいなくなる
一人で作るのが一番効率が高いわ >>21
天才は必要ない
普通のことを普通に作ればいいだけ 納期が無限にあるなら少人数のがいいよ
どう見積もっても納期で終わらんから人沢山使ってるんだろ? >>35
規格のないボルトを3つの工場で作って規格のないナットを3つの工場で作ってそれを組み合わせてみたら案の定動きませんでした、みたいな世界やからね
すると「ほなら工場はひとつでええやろ」みたいな発想になってまうんやろね
つまり規格を決めれる人がいないからこうなるんよ みずほ銀行に喧嘩売ってる?
とんでもねぇ話だなぁこれぇ! 少人数の脳内で共有した仕様が文書化されてないせいで後でトラブルになるパターン >>22
優秀な人間なら少ない方がだよ
あれは優秀じゃない人間がだからあのでき 少人数だと
対してクオリティの高い物はできないのもあるし
その場に寄るんじゃよ
ソシャゲだって人数足りなかった場合
削るに削って粗末物ができるし
アップデートだって考えないと行けない
開発者は其事を判ってるはず ハッカー集団に、PHPしか使えませんって人が混ざったら全体効率は落とす >>52
ディレクションからデバッグまで1人でやってたのがDMMのエロブラゲにあったな 日本だとそんなに優秀な人を簡単に集められないから
人数が増えるほどなんちゃってエンジニアが紛れ込んで足を引っ張ってくる もちろんコードを書くエンジニアだけじゃなくて
その他の工程担当やマネージャーも優秀じゃなきゃだめだけどな xを投入人数とした時の生産性をf(x)とした時lim x→∞f(x)=∞となるのだろうか?
どこかで限界があるような気がする 人月の神話でも外科手術チームのような少数精鋭が良いとされている
そりゃ高度なドメイン知識を暗黙のうちに共有できる方が強いわな 人数増えると余計なマネジメントが増えるし無能も増えるからな
少数精鋭で回すのが一番効率いい 少数精鋭なんて絵に描いた餅は捨てろ
そんな机上の空論で話を進めるからいつまで経ってもまともな組織運用ができねーんだわ ◯人日とかいう気持ち悪い単位使うくせに何言ってんだ 品質だろうが納期だろうが
少人数の魔法使いがテンプレートやマクロを駆使してつくったシステム>>土方集めてつくったシステム
なのは間違いないけど、前者はメンテナンス困難だぞ
Yahooだったかは成長期はゴリゴリにマクロ駆使してLispで作って、
市場に存在感を確立したあとは普通の言語でつくりかえたとかなんとか >>58
添字表記は _{…} で分かり易く書こうね
人数をいくら増やしても、コア部分は少人数で作るし
それを残りに伝えるのには時間が掛かるから
結局、少人数メンバーがほぼ100%完成させるのに要する時間が事実上の最短時間になるだろうね >>64
それアーリープロトタイプをLispで書いて仮運用に持ち込んで
本実装を凡人向けに書き直す話だろ
Lispで運用できるメンバーを複数確保でき後継を育て給料払えるなら、それで行くだろ そもそもLispで書くマクロってそれほぼLisp言語にあるマクロの事だろうな コミュニケーションコストは馬鹿にできないね確かに
相手の意図を理解する、相手に意図を伝えることはとても難しいからな
時間を浪費する最たるものがこのコミュニケーション部分に起因してるのではないかな?
認識のずれが手戻りを生み時間の浪費につながるから
まず顧客⇄seで理解のずれが生じる、seからコーダーに伝えるところでもまた話が捻じ曲がる、出来たものは当然ゴミなのでまた振り出しに戻る…
こういった伝言ゲームで時間を浪費する経験した人は多いだろ
そうなると結局、上流からコーディングまで1人でこなせる少数精鋭で構築するのがいいとなるわな 今大規模システム開発の関わってるけど
開発トップから出てくる資料が酷すぎて笑うしかない
あれを肴に酒が飲めるくらい笑える 管理工数バカにならんからな
でも能力ある奴なんて一握りだから うまく機能を分離出来れば多人数でも効率良いんだろうね
出来てないとダメダメになると思う >>46
その場合でもきちんと管理できる人が必要だな
ソフトウェア開発では普通ではないことが普通に発生するので 一切変更ななく誤解の余地がない完璧な設計を最初に出来たらコミュニケーションコストは大した問題じゃなくなるけど
現実はそうはいかないから関係者が増えれば増えるほど大変なことに X68000版デスブリンガーはジャージ着た天才が
1人でアセンブラーしばいてたわ やっぱりシステム開発規模の限界ってあるよね
システム界のバベルの塔は神の怒りを買う前に自己崩壊しそう バカは理解しないでコピペでものを作るからバグだらけになる 「家は少人数の方が早く作れるよ」
「はい、できた(犬小屋)」
こういうことでしょ バカは作れないとかなんとか言ってる人がいるが、大規模化すればするほど可読化が大事じゃないの
何でも人のせいかよ 巨大なシステムほど熟練者が少数精鋭で作るべき。
未熟な間は小さなシステムを数人で作って経験を積んでからでかいシステムに携わらないと。 うむ、これはそう
大きなシステムほど精鋭だけの少数でやるべき 基本どの仕事でも言えるな
売上とか規模を求めるなら役割細分化して量増やして人増ややして
結果今多くの企業が陥ってる状況になる 単価100万の派遣2人より安くい金額で優秀なフリーランス一人雇った方が効率いいのは当たり前
集めるのが大変だが 俺の説はみずほ銀行はファイヤーしたいSEを年収1億で3年間中抜きなしで300人雇えば完成すると思ってる。 >>81
大規模な開発で可視化重視すると可視化されたどうでもいい細かい情報が積み上がって誰も全体像を把握できなくなる ■ このスレッドは過去ログ倉庫に格納されています