IT☆ぱらだいす

大抵のプロジェクトではスケジュールにバッファ（余裕）がありません。
どんぶり勘定なスケジュールを立てるその原因とは。

顧客のいいなりになってしまう

ソフト開発会社には、多数の競合他社があります。
お客様にソリューション（業務の問題点のソフトウェアによる解決法）を提案する際に、納期と金額を提示するのですが、お客様から「他社ではもっと短納期で安い提案をされた」と言われ、それと同等の納期と金額に収めようとしてしまうのです。

受注を取りたいため。これが一番の理由ですが。
短納期、低コストのプロジェクトは、それを無理なく運営できるのならいいのですが、無理なプロジェクト運営になりそうな場合手を引くことも大切かもしれません。

なぜなら、そのような無理のあるプロジェクトでは、結局赤字になってしまうからです。
コストを削減するために開発人員を増やせない。でも、この人数では納期に間に合わない。
残業をする。結局人件費が上がる。
しかも、１人が１日に仕事できる時間は決まっているため、結局は納期には間に合わない。

そのようなプロジェクトに手を出して、赤字を出すか。
受注を取らずに、利益がないか。

マイナスよりもゼロの方がマシなのです。

そもそも、お客様は本当のことを言っているのでしょうか？

実は、本当は他社から見積もりをもらっておらず、あなたの会社だけに交渉しているのに、架空の「他社の見積もり」話をしているということもよくあることなのです。

根拠は？

私も数年前、ベンダーの正社員だった頃、２次受け、３次受けなどの企業との交渉によく使ってた手ですから。

「この見積もり高いよ。他ではこれくらいの期間で、この金額でやってくれましたよ」

なんて嘘八百並べてましたからね。

でも実際、この条件を飲む会社ってなかなかないので、ぶっちゃけた話「我が社では、そのような条件ではできませんので、この話はなかったことにしてください」と言われると困るわけで。

もし、お客様が妥協案を提示し始めたら、競合他社はいない、と考えられます。
うまく、こちらの要望もどんどん主張するべきでしょう。

スケジュールにバッファを持たせる

私がプロジェクトの線引きをやってた時は、１機能について、２〜３日のバッファを持たせていました。

大体それくらいのバッファがあって、ギリギリスケジュール通りに１機能の開発が終わるのです。
それは私が１０年間この業界での経験によるものです。
１０年間、ベンダーや契約社員、自営、派遣社員など様々な立場で、様々なプロジェクトに参画して見てきたことなのです。

プログラムを組む際、プログラムのバグが取れずに７時間悩んだ末に解決したということもあり、それを加味してのバッファなのです。

どのレベルのプログラマでも、「仕様書渡されて最後まで順調にコーディングが進み、バグもありませんでした」ということはこの１０年間見たことはありません。

大学院卒のプログラマでも、１週間遅れで、リカバリできずに、他のメンバーに手分けして仕事を手伝ってもらうこともあるのです。

最近のリーダーはこういう不確定要素を考慮せずに、スケジュールを引く方が多く、結果スケジュールが遅れて、上から怒られる。

前記事にも書いたように、３〜４画面の開発を同じ期間に１人で開発しなければならないようなバカみたいなスケジュールを引っ張る。

いいなりになるのではなく交渉も大事

これは単に、「バカ」という言葉で終わらせていいというものではありません。

「指定された金額」「指定された納期」「指定された人数」固定値として、この条件ありきで、スケジュールを変動値としているところが、そもそもの間違いなのです。

納期を動かせないから、スケジュールを詰める。そうすると３画面４画面が同時進行してしまうような、重なりのあるスケジュールになるのです。

結果、プロジェクト後半で、納期を守れないということになり（重なりのあるスケジュールを作った時点で、アラームを出すべき）、大量の人員の投入により赤字になる。

どうすればいいのか

なぜ、プロジェクトの後半になって、アラームをあげるのか。

これは単なる「現実逃避」が原因です。

「怒られる」、「責任を追及される」これが嫌だから、プロジェクト前半には上司やお客様に都合の良い報告しかしない。

プロジェクトリーダーに、「どうしてこうなった」と説明を求めても、「スケジュールがタイトで・・・」とか「プログラマのミスが続いて・・・」とか言うので。

・なぜ問題が発生したときに報告しなかった？
・このスケジュールでできると報告されている。
・プログラマのミスはどのようなものが続いたのか？

と聞くと、目を伏せうつむいて黙ってしまう。

どちらにしろ、プロジェクト後半で怒られて、涙目になるのだから、最初からアラームを出すべきです。
少なくとも、スケジュールを引くときには、問題点が見つかるはずです。

上役とリスクの共有し、上役を上手に使い、動いてもらえれば、少なくとも自分が責任を追及されることもあまりないのです。

金額、納期、人数は「固定値」ではありません。「変動値」なのです。

上役だけではなく、お客様の担当者も巻き込んでこちらサイドに引き込むことができれば、プロジェクトが大変なことになるという、最悪の事態も防げることでしょう。

しかし、これは現実的にできることなのでしょうか？

私が関東で仕事していたときに、プロジェクトが忙しくて、とても回らないときに、リーダーがとった行動は。

会社の次長に相談しに行ったのです。次長といえばなかなか話しかけにくいくらい役職が上の方ですが。

結果、定時頃に次長さんが、ゾロゾロと若い社員を５人くらい引き連れて職場に来ました。

「ねぇねぇ、これだけいたら足りる？まだ足りない？」と笑顔でリーダーに言っていました。

上役によっては、できるでしょうし。
そういう報告を好まない上役もいるでしょう。

プロジェクト成功のために動いてくれる上役がいればいいのですが、いないのならば、とにかく上役にメールでアラームをあげることです。

「私、メールで逐一あげてましたよね？」

そう言える証拠作りも、必要です。