目次
記憶
ここ2回、
システム開発をやっていた時の
安全率のことを書きました。
一応、リンクを。
書いてて、一つ思い出したことがあったので、
今日はそのことを。
若さゆえの過ち？
恥ずかしい失敗の記憶ですが。
工程の変更
僕は、
「工程を組み替える」っていうのが理解できなかったんです。
システム開発は、
計画を立てて、プロジェクトのメンバーで
その計画に沿って実行していきます。
たいていの場合、
計画通りには進まず、遅延が発生します。
その遅延は、
プロジェクトの進捗報告会議で、
上司や、時にはお客さまにも報告しないといけません。
当然遅れているので、
その対策も報告しないといけないのですが、
当時の僕に考えられる対策は
「残業して回復させます」
「休日出勤をして、遅れを取り戻します」
稼働時間を増やす対策ばかりでした。
「みんな頑張れ！」って。
2，3日の遅れならこれで何とかなるんですが、
1、2週間の遅れになると、
「それでは取り戻せないだろう？」
って指摘を受けることになります。
もうこうなると、
対策を応えられません。
この時間、「何とか早くすぎないかなー」って
だんまりになってやりすごそうとした記憶。
頭の中が真っ白で、何も言えませんでしたから。
ベストの計画
計画を立てる段階で、
ベストの計画を立てているわけです。
そのベストの計画で発生した遅延です。
「どうやって取り戻すの？」
って聞かれても、さっぱり。
遅れを取り戻すように計画を組み替えるなんて、
ベスト以上の計画を考えることと同じ。
「そんないい計画があるなら、
最初からその計画でやってます。」
本気でそう考えてましたので、
残業や休日出勤以外の対策は思いつきませんでした。
振りかえるとわかることですが、僕が立てていた計画は、
・目一杯やらないとうまくいかない計画
・すべてがうまくいったら納期に間に合う計画
もちろん、これはベストの計画ではありません。
メンバーに
目いっぱい頑張ってもらえるように計画すべきですが、
管理者は
どこかに余裕を持たせた計画を立てないといけません。
それはまぁ、今だから言えること。
こういう過去の経験が、
安全率を高めにとるという考え方につながっています。
まあ、無駄な体験ではなかったのですが、
でも、あの、針のムシロの進捗会議、
もう経験したくはありませんし、
誰にも経験してほしくもありません。
どこかに余裕を、安全率を取っときましょう。