WBSをもとにした予算を立てよ

東証で、システム障害が起こり、売買ができなくなる事態が発生しました。8月には、ジャスダックでもシステム障害で、同様の事態となりました。
最初ニュースを聞いたとき、やはり、「どこが作ったシステム化?」という疑問がすぐに浮かびましたが、名前を公表された富士通さんには、同情します。
別に富士通さんの肩を持つわけではありませんが、この対応に相当の費用をかけなければならない事態に追い込まれていると推測します。
どんなに完璧なシステム構築をしても、100%バグのないシステムは存在しません。あらゆるテストを行なっても、稼動後に、想定外のものが出てきます。
重要なことは、バグの原因を作った者を特定することではなく、障害が起こったときに、どう対応するか、予め計画しておくことです。これは、リスク管理の一部でもあります。
リスク管理については、後日書くとして、今回は、予算作成です。


予算作成には、ボトムアップ方式とトップダウン方式の2つあります。
トップダウン方式は、立上げフェーズなどで、まだ詳細が分かっていない段階で、どれだけかかるか分からない状況の中、概算予算を立てる場合に使用します。
今は、プロジェクトの詳細計画を作成していますので、このトップダウン方式ではなく、ボトムアップ方式を使用します。
当然、ボトムアップするということは、その基準になるものがなければなりません。それが、WBSです。
つくづく思うのですが、IT業界で作る見積、予算は、なぜ、WBSに基づいたものになっていないのでしょうか。前にも書きましたが、ベンダーからの見積の大半が「システム構築一式」などと、ユーザに詳細が分からないような書き方になっています。
ユーザ企業は、ベンダーからの見積にその他必要経費を加え、さらにコンティンジェンシーを加え、予算としています。これも、考えようでは、ボトムアップ方式なのですが。
もし、あなたがベンダーの担当者で、お客様から予算を20%削ってくれと依頼されたらどう対応しますか?
「じゃあ、テストフェーズを丸ごと削りましょう。テストは、お客様自身で行なってください。」このように答えますか?
論外です!
もし、このような答えをするベンダーがいたら、即刻退場してもらいましょう。
東証のように、稼動後システム障害が起こる確率が高くなります。
「スケジュールを見直し、期間を短縮できるかどうか検討します。」と答えるのがまず最初の対応でしょう。
スケジュール短縮ができなければ、次は、
「これとこの作業は、お客様でお願いします。そうすれば、予算を20%削減することができます。」
これでもダメな場合は、いよいよスコープの見直しです。「これとこの機能をはずしましょう。はずしても、最終的にお客様がやりたいことは実現できるはずです。」
このような対応ができるためには、予算も、WBSを元に積み上げで作成していなければなりません。
何度もいいますが、予算の元となるのは、WBSです。
今のIT業界の価格体系は、SEの人月単価です。そうすると、予算を削るためには、SE1人削るというような対応しかできません。
残ったメンバーに作業のしわ寄せが来ます。残業をしなければ、プロジェクトが完了しない事態となります。こうなれば、メンバーの士気も低下する。生産性が落ちる。また、スケジュールが遅延する…などと悪循環に陥る可能性が高くなります。
どこのサービス業界でも、明朗会計です。作業ごとに、標準料金が決められています。作業の積み上げが即、予算の積み上げとなります。WBSの考え方そのものです。
人月単価が便利な所は、作業ごとの積み上げが必要ないことです。SEをプロジェクトに張り付かせると、終了までの期間が分かれば、後は数字が出てくる。
これでは、女工哀史ならず、SE哀史の状況が続くばかりです。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

*