スケジュール
業務システム構築の場では、多くの場合、スケジュール通りに物事を進めることは実はあまり重要でなかったりする。
シスラムの構築プロジェクトが開始すると、構築に必要な作業(タスク)の洗い出しが行われ、各タスクを遂行する人(リソース)と期間(スケジュール)が決められる。各タスクの終了の積み重ねがシステムを形にして行くのだが、リソースがタスクを終了するために費した期間の合計とその他必要となるソフトやハードの購入費用がシスラム構築費用となる。当り前のことを書いているのだが、コスト意識を持ってシステム構築に従事している人は少ないので、そう言われてみればそうねぐらいの意識でしかない。
しかし、プロマネは違う。予算内で予定通りの納期にカットオーバーさせることが一般的に重要視されるので、コスト発生要因と納期遅延要因を撤底的に削減する。すなわち、リソースを増やさず、スケジュールを守らせる。ところが、このスケジュールを守らせるのは容易ではない。システム構築プロジェクトはプロジェクト開始時には予想することができない不確定要素が多く、規模が大きくなるほど不確定要素が増大し、タスクが予定通り終了することはまずない。これはプロマネが神様であったとしても、プロジェクトの参加者が人間である限り、どうあがいても避けられない。スケジュールを十分余分にとっていたとしても必ず遅れる。人間はスケジュール通りか、スケジュールより遅れるかのどちらかの方法でしか仕事をしないため、それに不確定要素が加わって必ず期限を守れなくなるからだ。幻想を抱いていけない。プロジェクトは必ず遅延する。先に述べた通り、プロマネが神様であってもだ。
ちょっと待って。スケジュール通りに終わったプロジェクトを知っているよと言うかもしれない。そういうプロジェクトがあった場合は、それはスケジュールを守るために他の何かを必ず犠牲にしているはずだ。その犠牲とは、リソースの増員による予算オーバーであったり、品質の低下であったりする。当初予定していた予算と人数で、当初の仕様を満たすシステムをスケジュール通りに構築することは絶対に不可能だ。断言してもいい。
スケジュールが遅れるこを避けるには、先に述べた通り予算を増額するか品質を落とすしかない。無能なプロマネはスケジュールが遅れそうになるとこう言うだろう。とにかく頑張って遅れをとり戻してくれと。リソースを補充して遅延分を取り戻すことは予算の増額につながり、スポンサーの低抗が大きいため、担当者に何とかしてくれと頼むしか方法がないのだ。そして、お願いされた担当者には、品質を落とすか逃げだすことぐらいしか道は残されていない。
システムに重要な3つの要素である納期、品質、コストをすべて守ることは不可能であり、必ずどれかを犠牲にすることになる。恐らくほぼすべてのプロマネは、納期、コストを優先し、品質を落とすだろう。いわゆる手抜き工事だ。で、結局どうなるか。リリース後にトラブルが頻発し、トラブルシューティングにさらなるコストと期間を費すのだ。
トラブルシューテクングには、トラブルを発生させている原因を取り除くデバッグ作業と、トラブルから作成された不正データを修復するリカバリー作業がある。そのうち、前者のデバッグ作業はシステムの品質を向上させる効果があるため、リソースとコストをかける価値はあるし、そもそも予定していたシステム機能に必要であったはずの投資だ。しかし、後者のリカバリー作業は全く意味のない投資となる。
業務システムを作るときは、外部との連携など納期が非常に重要な場合を除き、最重要視するのは品質だ。納期が多少ずれても影響が少ない場合が多いし、スケジュールが重要でないとすると、コストの増減は品質の良し悪し以外には変動しないからだ。そこで、品質を最重要視した構築手法を採用してはどうか。例えば、構築を外部に発注する場合は、要望している品質を達成できる納期を自身に決めてもらい、納期までに要望している品質を達成できなかった場合は品質をクリアするまで無償で対応させるなどのペナルティを課す。内部のリソースを使用する場合には、手を抜けない納期を設定し、納期までに要求した品質を達成できない場合は、その人の評価を下げる。などなど・・・。
と、大変長々と書いてはみたものの、システム利用者もスポンサーも、システムを使い始めるまでは、納期とコストにこだわるんだよね。品質にうるさくなるのは稼動後に実際に使い始めてからだ。だから、私は今日も担当者にお願いしている。何とか頑張って間に合わせてよ、とね。
シスラムの構築プロジェクトが開始すると、構築に必要な作業(タスク)の洗い出しが行われ、各タスクを遂行する人(リソース)と期間(スケジュール)が決められる。各タスクの終了の積み重ねがシステムを形にして行くのだが、リソースがタスクを終了するために費した期間の合計とその他必要となるソフトやハードの購入費用がシスラム構築費用となる。当り前のことを書いているのだが、コスト意識を持ってシステム構築に従事している人は少ないので、そう言われてみればそうねぐらいの意識でしかない。
しかし、プロマネは違う。予算内で予定通りの納期にカットオーバーさせることが一般的に重要視されるので、コスト発生要因と納期遅延要因を撤底的に削減する。すなわち、リソースを増やさず、スケジュールを守らせる。ところが、このスケジュールを守らせるのは容易ではない。システム構築プロジェクトはプロジェクト開始時には予想することができない不確定要素が多く、規模が大きくなるほど不確定要素が増大し、タスクが予定通り終了することはまずない。これはプロマネが神様であったとしても、プロジェクトの参加者が人間である限り、どうあがいても避けられない。スケジュールを十分余分にとっていたとしても必ず遅れる。人間はスケジュール通りか、スケジュールより遅れるかのどちらかの方法でしか仕事をしないため、それに不確定要素が加わって必ず期限を守れなくなるからだ。幻想を抱いていけない。プロジェクトは必ず遅延する。先に述べた通り、プロマネが神様であってもだ。
ちょっと待って。スケジュール通りに終わったプロジェクトを知っているよと言うかもしれない。そういうプロジェクトがあった場合は、それはスケジュールを守るために他の何かを必ず犠牲にしているはずだ。その犠牲とは、リソースの増員による予算オーバーであったり、品質の低下であったりする。当初予定していた予算と人数で、当初の仕様を満たすシステムをスケジュール通りに構築することは絶対に不可能だ。断言してもいい。
スケジュールが遅れるこを避けるには、先に述べた通り予算を増額するか品質を落とすしかない。無能なプロマネはスケジュールが遅れそうになるとこう言うだろう。とにかく頑張って遅れをとり戻してくれと。リソースを補充して遅延分を取り戻すことは予算の増額につながり、スポンサーの低抗が大きいため、担当者に何とかしてくれと頼むしか方法がないのだ。そして、お願いされた担当者には、品質を落とすか逃げだすことぐらいしか道は残されていない。
システムに重要な3つの要素である納期、品質、コストをすべて守ることは不可能であり、必ずどれかを犠牲にすることになる。恐らくほぼすべてのプロマネは、納期、コストを優先し、品質を落とすだろう。いわゆる手抜き工事だ。で、結局どうなるか。リリース後にトラブルが頻発し、トラブルシューティングにさらなるコストと期間を費すのだ。
トラブルシューテクングには、トラブルを発生させている原因を取り除くデバッグ作業と、トラブルから作成された不正データを修復するリカバリー作業がある。そのうち、前者のデバッグ作業はシステムの品質を向上させる効果があるため、リソースとコストをかける価値はあるし、そもそも予定していたシステム機能に必要であったはずの投資だ。しかし、後者のリカバリー作業は全く意味のない投資となる。
業務システムを作るときは、外部との連携など納期が非常に重要な場合を除き、最重要視するのは品質だ。納期が多少ずれても影響が少ない場合が多いし、スケジュールが重要でないとすると、コストの増減は品質の良し悪し以外には変動しないからだ。そこで、品質を最重要視した構築手法を採用してはどうか。例えば、構築を外部に発注する場合は、要望している品質を達成できる納期を自身に決めてもらい、納期までに要望している品質を達成できなかった場合は品質をクリアするまで無償で対応させるなどのペナルティを課す。内部のリソースを使用する場合には、手を抜けない納期を設定し、納期までに要求した品質を達成できない場合は、その人の評価を下げる。などなど・・・。
と、大変長々と書いてはみたものの、システム利用者もスポンサーも、システムを使い始めるまでは、納期とコストにこだわるんだよね。品質にうるさくなるのは稼動後に実際に使い始めてからだ。だから、私は今日も担当者にお願いしている。何とか頑張って間に合わせてよ、とね。