人月の神話や見積もりの感想
人月という見積もり最大の欠点は、ソフトウェア開発には人と月は交換性はないということです。
一人一年って言いますと、365人１日で完了できるという結論が出ますが、それは不可能です。どんなに妊婦がいたとしても、九ヶ月かからないと出産できない。だから神話のように聞こえます
大学二年生のとき、あるスタートアップ企業にインターンをやっていました。全社約 15人で、開発は四人しかいませんでした。
スタートアップの特徴というか、プロダクトをデプロイしユーザーにアピールする必要があり、開発スピードがどちら言うと速いほうだと思います。もちろんアジャイル開発も毎週やっています。そこでいろんなソフトウェア開発手法など学んだし、エンジニア必読の本「人月の神話」も何回でも読みました。
なぜ「人月の神話」そういう変なタイトルになっていますか？人月で見積もりするには、神話のように聞こえるからです。
いつも見積もりについて変な予感があります。自分が約束したスケジュールをもちろん守りたいけど、スペックなど何もない段階で正確に見積もりできないのが確かです。しかし、ソフトウェアの本質そいうことです。新しいシステムには必ず未知のエリアがあり、着手する前に誰も気づいてくれないことが多いです。
開発してバグを発見し、それを直し、また他のどころにバグを発見し、インフラを考え直すケースもよくあります。それはスケジュールに計算できないし始めてからそれをすべて把握するのも無理だと思います。
そして、自分を出したスケジュールを守るため、品質のないコード書き、他の同僚も引きずり込んで更に混乱になることが多いでしょう。
人月の神話はこう書いてあります。
もしシェフさんが約束した通りに料理を出してくれないなら、選択は２つしかない：
- 待つ
- 生で食べる
ソフトウェアも同じで、バグだらけのシステムを使うか待つかだけです。もちろん強火してて半分焦げ半分生の料理を出せますが、それは更に悪くなっていますね（それとも良いかな）。
ソフトウェア開発がうまく行かない理由
人月の神話によると、ソフトウェア開発がうまく行かない理由はいくつありますが、ほどんどの理由は、スケジュールをうまく把握していないということだそうです。原因は：
- 見積もりの技術は成熟ではない。そして、すべてのスケジュールは必ず順調に行けると想定しているからだ
- 時間と人は切り替えると想定して見積もりするからだ
- 自分が出したスケジュールに自信がないからだ
- スケジュールを間に合わせるために人を増やすからだ
見積もりの段階で着手できないから、全ての状況を把握するのは難しいし、開発するにはいくつの段階がある。発想、実装、検証など、うまく行かないケースが必ず出る。例えば想像していないバグ、処理漏れのケース、依存性など最初から考えにくいです。我々はあくまても人間で、ミスを犯すのは人間だ。
**人月という見積もり最大の欠点は、ソフトウェア開発には人と月は交換性はないということです。
一人一年って言いますと、365人１日で完了できるという結論が出ますが、それは不可能です。どんなに妊婦がいたとしても、九ヶ月かからないと出産できない。
つまり、人月に適用できる場合は、依存性がない、コミュニケーションする必要ない場合だけ成立します。ソフトウェア開発は依存性がよくあり、単純に人月で計算すると変な結論が出ます。更に人を追加して遅くなる場合もありますね。
新しい人を追加するには、誰かが面倒する必要があります。その場合、二人がゼロもしくは半分になるこの可能性が見積もりに計算していますか？
Seniorエンジニアとjuniorエンジニアとは開発スピードも違うので、同じユニットで計算したらきっとズレがあるでしょう。
そして人が多くなればなるほど、コミュニケーションのコストが膨大に増えるので、それはきっとスケジュールに影響がある。
ほどんどの場合、スケジュールが変な場合が多くて、勝手に人を追加してさらに悪くなって一生終われないままプロジェクトが続ける。まあ、そういうときは自分が頑張って権利をもらい偉い人になるか、退職するしかないかな。
が、いくつの改善方法があります。
- 自分が出したスケジュールを胸を張って守ります：それを言えるためにデータが必要です。
- 時間をかけてテストを書く：早めにテストを書くのもいいですし、とにかくエラーが出れそうなところに時間をかける
- プランニングのタイミングでよく考える：プランニングは、スペックのプランニングではなく、開発者がコード書く前のプランニングです。考えば考えるほど、カバーできるケースが出てくるので、コードを書く前に考える時間を作ってもよい
- コードを書く時間：実際にコード書く時間は、そんなにかからないと思います。プランニングの時間をちゃんと活用してから、考えた上で書いたコードは簡潔になるため、円滑になるでしょう。
実際やってみて、多くの時間はコードレビューにかかる感じがよくします（うちのチームなら）。
なぜかというと、人の慣れ問題とスケジュールに関心するレベルは違うからです。まあ、解決案まだ探しているところですが、それは本に書いてある「外科手術チーム」ところに回答があります。これからも書く予定ですが、この記事を参考しておいてもいい気がします — 「生産性の高い「精鋭チーム」で大規模システムをつくろう」。
本に書いてある「非常に優秀なプロのプログラマは、下手なプログラマの10倍の生産性がある。たとえ、同じ訓練と2年間の経験を経ているとしても」どうやって解読するのか人によるけど、私共感があります。
本に推奨している外科手術チームは執刀医（プログラマー、コード書くし、決断もする）がリードすることで、みんなフォローする形で行く。そしてみんながどんな役割しているのかもちゃんとわかっている、まるで外科手術チームのようです。
あくまても理想的ですが、ほどんどの場合はコード書く、実装する人は権限持っていない、実装したいフローや機能は事業側がNGのようなケースがほどんどだね。
みんな人月の神話を読もう！雑な記事ごめんね。
Discussion