Ryuzee.com

デスマーチを回避するのに大事な“3つのこと – @IT情報マネジメント
より

篠氏は「そのようなケースを想定して、バッファを積んでおくことが重要だ。ケースによってそれが10％なのか、20％なのかは変わってくるが、適切なバッファがあれば仕様変更があっても慌てずに対応できる。
（略）

　まず、要件定義の段階から、頻繁に仕様変更会議を実施。仕様凍結時に、ユーザーの合意をしっかりと得ることが非常に重要だという。そして、そのコミュニケーションをきちんと行っておくことで、その後の仕様変更については、開発者側の設計が問題で発生したのか、それとも業務要件の変更なのかをはっきりさせることができるというのだ。
　
（略）
そして、最後に篠氏が説明するのがPMBOKの重要性だ。

以前に棟梁も嘆いていたけど、どうしてこんなやり方でデスマーチ回避できるのかね？突っ込みどころ満載過ぎてたまらんのだが、

• バッファはあっているのか？間違っているのか？
• そのバッファは余ったら客に返金するの？んなわけ無いか・・・。
• そもそも仕様凍結宣言したところで、業務要件に合わなきゃ、仕様は変えるしかない。
• 仕様変更会議って誰が出るのよ？しかも頻繁に？
• どうせ出席者が大量にいて、長くて決まらない会議なんだよね。
• それより動作するソフトウェアを見せようよ！！
• SIerが追加費用とかスケジュール延期を勝ち得て、最終的にデスマーチにならなかったとしても、それはプロジェクトの成功じゃない。
• プロジェクトの成功は顧客がシステムを作ることでビジネス上の利益を生み出したこと。それに加えてSIerの利益云々。
• 客からしたらシステム投資を決定した時点で費用対効果の見極めとか市場への投入時期とか色々考えているはず。それを守るのは協調関係を組むものとしては当然。
• そして利益の多くはシステムの重要な一部分から作られるって考えたら、重要なところから先に作るべし。
• ところが仕様決めに時間をかけたあげくに作り出すと矛盾が出てきたりして、開発工程にリスク山積みになるんだよね。
• こういうプロジェクトはいつも序盤～中盤：快晴！、中盤～後半：曇り模様、終盤：突然大雨・・・ってなる。

ということで、アジャイルやろうよ！

“デスマーチを味わったことが無い人がデスマーチを語るな”へのコメントはありません。

コメントはありません。是非コメントしてください。

コメントする

Name (required)

Mail (will not be published) (required)

Website

XHTML: 以下のタグが利用可能です: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Trackback