読者です 読者をやめる 読者になる 読者になる

大規模プロジェクトをうまく回したいですか?

会社によってそう呼ばれる基準はまちまちですが、
大規模の方がリスクが高くなるのは当然ですね。


「大規模プロジェクトではどうするか」を考えるより、「大規模にしないためにはどうするか」を考えよう - kなんとかの日記



ソースコードの規模もそうですが、
プロジェクトに関わる人員の数にもよると思います。


私の経験上ですが、1人で10人の作業を見ることはできません。
せいぜい5人って所です。
それくらいなら誰が何をしているかを把握することができますし
困っていそうならフォローすることも可能です。


あまりにも管理する対象が多すぎると、誰が何をやっているか把握できず
無駄なことをやっていたり、ともすればサボっていても気づかない状況になります。


で、1人を頂点とした6人体制でグループを作り
グループの数を増やしたり、複数のグループを管理する人を増やしたりして
プロジェクトの規模を大きくしていきます。


それでも、グループ間の情報共有がうまくいかないと回らなくなるので
仕様(変更)を小さくする努力も必要です。


5%しか起こらないケースに対して一生懸命作りこんでも、
何人ありがたがるっちゅうねん!って話です。




実装者が言語や技術的なことを駆使して(無謀だと思われる)仕様通りのものを作るより
要件を満たす為に、という観点で設計しなければならないんだと思います。
(技術的にチープでもユースケースが満たせればそれでいいじゃないですか)



やっぱりプロジェクトを失敗させない為には、大規模にしないことだと思います。
半年で(仕様を知るところから始めて)社内システムをリプレースなんてありえない・・・。



大規模プロジェクトは数字的にもかっこいいので、ギャンブル要素満載ですね。
成功しても失敗しても人が流れていくのは世の常。