「仮想化」をキーワードに情報インフラの世界を考察します。

デスマーチのコストを負担しているのは・・・

»

オルタナブロガーの吉川さんのところで、デスマーチのコスト負担の話が出ていました。

大量のリソースをつぎ込んで炎上プロジェクトを鎮火させるのはいいが、そこでつぎ込まれたリソースのコストは一体だれが負担しているのか、もしかすると最初から見積もりに入っていたのではないか?という疑問が外から見ると感じられるようです。

結論から言いましょう。ケースバイケースですが、最初から余分に予算を積むことがあります。これを一般的にはコンティンジェンシー予算と呼びますね。

コンティンジェンシーという単語の意味通り、不測の事態に備えて予算を多めに確保するのですが、これがプロジェクトのコスト削減で真っ先に目をつけられるモノであったりもします。

ですが、これを削るとスケジュールに遅延が発生したときに泣きを見るんですよね。多くの場合、SIer側の持ち出しが発生してプロジェクトが赤字になります。もちろん、スケジュール遅延の原因がどちらの非によるか次第で、双方が負担する赤字額は増減しますけど。

ちなみに個人的な意見ですが、無理やりであっても最終的にプロジェクトを終えることができるというのは、ベンダーを選択する大きな基準のひとつだと思います。経営側の視点で考えると、多少出費が増えてもスケジュール通りに事を進めることの方が経営を予測し易いですし、対外的な影響を考えてもメリットは大きいのではないでしょうか。

まあ、そもそも無理のないプランをベンダーとクライアントの双方で握っていれば、こんな事態には発展しないんですがね。最後に苦労するのはいつも現場の人間なので、クライアント及びベンダーの経営層は常に現場の環境を気遣ってほしいと思います。

Comment(5)

コメント

ねこまっしぐら

素人考えな意見ですが。
デスマーチって結局は、「8/31に夏休みの課題を徹夜で終わらせる」事と同じなんですよね。
リスクを減らすという観点では、その為の予算や人員を取っておくのは勿論悪くないですが、始めからそれを見越したスケジュールや人員構成を立てるのはどうかなと。
デスマーチ要員を確保しておく余裕があるなら(これは吉川さんの所で出てきた話ですが)、その人員を最初から当てて、スケジュール通りどころか、予定より早く終わらせる位の心構えで望むべきですよね。
まぁデスマーチに入る時点でマネジメント力を疑う訳ですが。
ところで、デスマーチが頻繁に起こるような会社の上層部を含む社員の方って、子供に夏休みの課題の取り組み方に対してどのように話すんでしょうね。

ねこまっしぐらさんの意見は正論ではありますが、現状での業界での人手不足、人件費によるベンダサイドの財務状況の悪化、その他もろもろを考えると、机上の空論にしか過ぎませんね。

 現実には受注のために値引き合戦が行われ、結局黒字を出せないプロジェクトを受注しないといけなくなるということにそもそも問題があるわけで。

 顧客もこれだけの要員、費用がかかります、納期はどうしてもこうなります、と言っても納得してくれません。

 デスマーチは受注の段階、ベンダの要員不足というか経営上の理由で要員を増やしようがないという現実から、最初から定められているのが現場の現実です。

 要員をあとから追加しているのは、要員に余裕があるから追加しているのではなくて、別の仕事を本来している人間を納期を守るためにしかたなく廻しているのが現実です。納期を守れないことで損害賠償を請求されることも多いですから。当然廻されたエンジニアが担当しているプロジェクトへの影響も免れません。

 ユーザから受注して他のインテグレータなどに製造をまる投げするような、業界慣習もデスマーチの要因になっています。

 私はこれまでの経験から、そもそもシステム開発の現場ではマネージメントは不可能だと私は結論づけています。

皆様、コメントありがとうございます。

いざという時のために余力を残すくらいなら、最初から全力でリソースをつぎ込めという言葉、非常に良く分かります。おそらく、サービスリリースが早ければ早いほど良い、という状況のプロジェクトにはねこまっしぐらさんの仰るとおりだと私も思います。

一方で、本文の最後の方に書いたのですが、「スケジュール通り」にサービスをリリースする必要があるプロジェクトもありますよね。

例えば、財務経理システムのように、期の切り替わりでしかリリースできないシステムの場合、リソースを大量投入して前倒しで構築しても、結局遊休期間が発生してしまいます。

その上、リリース時までベンダーの要員を確保しておかねばなりませんから、余計にコストが発生する可能性もあったりします。一度人員をリリースすると、同じメンバーを再召集するのは不可能というのが実情なので、ベンダーはその条件を断ると思われます。

ベンダーの都合も無視できないというのは、既におおやまさんが述べていることに通じる部分でしょう。

他にも、社外との調整やプレスリリースなどが関係してきても、予定を前倒してリリースすることは難しいようです。


おおやまさんが最後に述べている「システム開発の現場はマネジメントが不可能」という部分について、その言わんとしていることは私にも伝わってくるのですが、状況を改善するための打ち手はあると思うのです。

ステークホルダーが非協力的であったり各自の都合しか考えていなかったりということはよくある事ですが、「今、これをやらなければ、これだけの損失やデメリットが発生する」ということを理解してもらえれば、デメリットの大きさ次第で協力的になることもよくあります。

それでも協力を得られないときは、それによって発生する損失を相手に被ってもらうというのはどうですか?

吉川です。
 こちらこそ私のエントリーにトラックバックを頂きましてありがとうございました。
 その後いろいろと考えましたが、とりあえず今日のエントリーで再度この話題に触りました。
 業界が未成熟なのは分かるし、デスマーチの原因はSIerだけの問題ではないことも理解しています。またこの業界では優秀な方とそうでない人の差が100倍以上つくこともあり、そんな優秀な方は数えるほどしかいない事も・・・
 それでも日々仕事をしていて今のSIer(自分の勤める会社も含めて)のやり方には納得できかねることが沢山あります。
 時間がかかることも分かっていますがせめて私がこの業界にいる間にはもうちょっとマシになって欲しい。そう願っています。

コメントありがとうございます。吉川さんが関係されているプロジェクトも色々おありのようですね。

これでもプロジェクト管理の方法論は数年前と比べても随分普及してきたように思えます。それも業界の人間が現状に危機感を覚え、PIMBOKをはじめとするプロジェクトに関する考え方を啓蒙してきたからなのでしょう。

きっと数年後にはもっと良い環境になっていると私も信じています。

コメントを投稿する