なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのか - Qiita

はじめに ソフトウェアプロジェクトには不思議な性質があります。現状のスケジュールに課題を感じて、短くするために人員を投下しても、なかなか思い通りに短くならない。それどころか悪化してしまうことがあります。場合によってはプロジェクト自体が破綻して失敗してしまうことすらあります。 今回は、このようなソフトウェアプロジェクトに潜む直感に反する性質を数理的なモデルを介して理解していく試みです。ある種の思考実験としてお楽しみください。 宣伝 Qiitaさんとコラボ企画でアドベントカレンダーをつくりました。 DXをめちゃくちゃ改善した話を募集しています。 https://qiita.com/advent-calendar/2021/dx-improvement 10人の妊婦がいても1ヶ月で一人の子供は生まれない これは誰かの技術力やプロジェクトマネジメント力に欠陥があるのではなく、「人月の神話」で有名な

[tpircs]

ふわっとしたタイトルなのにゴリゴリした内容で素晴らしい。理解してかどうかわからんけど、人数は増やさずに残業させまくったほうが効率が良いということで、残業が蔓延するってことが起きている気もする。

[flont]

各モジュールが完全に分離されていれば分業できるけど、完全に分離するほど詳細化できてるならもうそれは実装なので

[masatomo-m]

コミュニケーションパスの数を増やしすぎないようにするため、小チームのまとまりみたいにするという手も良くやられるよね。ただ、その場合ハブになる人に負荷が集中するのと、その人の能力が低いと全てが終わる

[multipleminorityidentities]

能力の差が埋まらなくて、実際プロジェクトを回してるのは少数でその人たちがデスマなんてのもザラ。

[JULY]

「人月の神話」以来、ずっと指摘されていることだけど、上に立つ人になかなか理解してもらえない問題。定性的には知っていても、ここまで定量的に解説しているのは見たことがなかった。

[pavlocat]

うまくいってるチーム→少人数で少なくともリーダが超優秀（そしてメンバーもだいたい優秀）

[MasaMura]

スキルが低い要員は、コミュニケーションコスト、管理コストが上がるので、マイナスにしかならない。日本のPGを半数に削減して、残り半数にもっと良い給与を払っても生産はマイナスならない。

[BOOOOOOOON]

とにかく人手不足の業界なので増やすこともままならないケースが増えてきた

[isawo81]

プロジェクトの序盤で何を作る・作らないの決断ができる人がほしい

[remonoil]

お客は人増やして（予定上は）早くしたいし上司も人増やして金稼ぎたい。コスパなんぞ誰も求めていないのである

[razokulover]

デッドラインでやってたやつか

[simomm]

ソフトウェアプロジェクトの工期は工数の三乗根に比例。コミュニケーションコストの小さい少人数に分割できるほどコストパフォーマンスが良くなる。

[sonots]

改めて。リソースヒストグラム、有効工数

[kiririmode]

工数・工期モデルの理論的説明とコミュニケーションコストのような人数依存のコストがもたらす影響

[tyoro1210]

つまり みずほ銀行はどんな感じになりますか / 『闘うプログラマー』読み返したくなりますね

[samu_i]

なぜ、車の台数を増やしたのに滞りなく荷物が配られないのか（ふしぎだー

[tetsu040e]

腑に落ちる

[for-my-internet-demo]

属人化のメリットというか見ないで済んでるとこというか

[masappo_bookmarks]

“門外漢”

[rasterson]

結構説得力のある説明だが、本当に理解して欲しい層に届くかどうかが問題ですね。気合で何とかなると思っている層の存在をどうするか。　分割や段階的に開発する以外に、半完成部品の組み合わせという方法も良さそう

[rin51]

「人月の神話」などでふんわりとは知ってたけど、こうやって定量化されていたんだ

[t-wada]

スケールメリットが必要なら、コミュニケーションコストの低い組織とプロダクトの実現が重要。コストパフォーマンスが必要なら、大人数の大型プロジェクトではなく小プロジェクトに分解しながら進めることが重要。

[snow8-yuki]

"定数2.7"　つまりeでは？

[rdrk]

人月の神話とかで常識だと思って思考停止してたが、これだと企業が何も考えずにプログラマを採用しまくると利益率が下がるのかなって思った。

[atsushifx]

一対一のコミュニケーションだからパスはnC2、よってO(n^2)。プロジェクトをサブプロジェクトに分けたり、Slack,GitHubのようなツールを使って一対多のコミュニケーションを増やすのが常道。

[indication]

三乗根って、どうやって電卓で計算するん🤔

[OrionB312]

後で読む

[udongerge]

頭からケツまで手順の決まってる作業なら、人員を注ぐほど効率は上がるだろう。クリエイティブな分野ではそうはいかない。

[shinji]

数字(数式)あって助かる。参考にする。

[alpon]

IPA PMの過去問で、1人でやったら1人月の案件を2人でやったらX人月になることとするって前提が書いてあって、1.3-1.4くらいかなと思ったら1.7とかだったのが強烈に残ってる。

[a-hamahama]

ソフトウェアプロジェクトの工期は工数の三乗根に比例する

[fukken]

プログラミングというかシステム開発は本質的に「設計作業」で、しかも毎回新しい設計なのよな（使い回しに制約がないので、同じシステムを複数回作ることはない）。製造業の延長で考えるとうまくいかない。

[evolist]

人数いるけど子供のサッカーみたいなPJな。で、できるやつからやめていくという。

[vbamacro]

パワハラ高圧的な人間が1人でもいると、すべてのパフォーマンスが劣化するけどね

[nekosann_08]

なんだかんだ1つのものを複数人で作り上げようとするとバンドメンバーくらいの規模感が丁度良いよね。

[nebos]

“人数規模を拡大するにつれて、コミュニケーションコストの方が人数を追加するメリットよりも大きくなってしまうため、プロジェクトの拡大には上限がある”

[kirakking]

データを視覚化することで説得力倍増。

[vjaPj]

〇〇人月と考えてたら、落とし穴にハマる。単純な掛け算ではプロジェクトは回らない。感覚では分かっていても、グラフで見せられるとその違いがよくわかる。

[rryu]

要は元々人数が増やせるようにプロジェクトが設計されていないと増やせない訳で、建築関係で人が増やせるのは設計上同時に割り当てられる最大値まで割り当ててないからだと思う。

[tomoya5]

ハードもなんだよなあ