夢見がちな要件定義を現実に引き戻す工事進行基準qune夢見がちな要件定義を現実に引き戻す工事進行基準2008/04/04話題になってるこちらの話。一般的に日本のシステム開発は要件定義やユーザー企業との契約が明確でなく、開発中の手戻りや期間の超過が多い。開発終了後でないと売り上げや費用が算出できなかった。正確な見積もりをする前にどんぶり勘定で走り出してしまうプロジェクトが多かったといえる。(snip)どんぶり勘定をやめて、開発が始まる前に要件定義を確定、正確なプロジェクトマネジメントを行うことは先進的なSIerにとってはすでに行っていること。昔ながらのあいまいなビジネスを行っているSIerにとっては痛みが大きいだろう。@ITなんかですね......燃えるプロジェクトって,もはやどこが悪いんだかさっぱり見当が付かないんですけれど,基本的に言えるのは,次のようなことだと思うんですね。発注側(この場合,普通は基幹システムの業務担当)が自社の業務を理解していない。受注側(この場合,直接お客さんと交渉して要件をまとめるヒト(SIer/基本設計担当))が,手戻り等々に伴う開発の負荷を見積もれない。加えて,大きな話になっちゃうけれども,日本の企業の場合,暗黙の慣習とかノウハウが業務と結びついていることが多いこともあげられそうです。ある帳票の端っこに,赤字でちょこっと何かを書くと,注文書が注文書でなくなっちゃう(別の帳票として扱われる)......みたいな。いうもんも含めて,(仕事をするのに必要という意味で)「業務」なわけなんですけれど,それを基幹担当が把握できていない(そこまで求めるのも酷なんだけれども)。いうことが後になって判明して,手戻ったときにどうなるかというと,スキーマとロジック全体を見直す......なんてことはできません。注文書スキーマに変なカラムができるんです(赤字で付加したトコロに相当)。そんな具合に,純粋に注文書テーブルとはいえない,なんとも気持ちの悪いスキーマができる......こともある......のだろう......多分......(と,言っておく)。その一方,ユーザ要件を定義する担当は,技術的に手戻りの負荷を見積もれない。要件的には些細な変更でも,ロジックが大きく変わってしまうことはままあったりします。ゆのを見積もれないもんだから交渉の手札がないわけで(これは交渉する上でひどいディスアドバンテージだと思う),安請合いしてしまう。なんですか?」とかいった向きでも,プロマネはできる(ことになっている)わけで,必ずしも求められてるスキルじゃないんでしょうけどね。的な考え方が身に付いていない(処理を抽象化できない)ってな話があったり......。カラムをひとつ追加するなんて場合,ちゃんと機能分割して抽象化しておけば,数行の変更で済むはずなのに,半日がかりの作業になっちゃったり......とかとか。そんなもんで,燃えるプロジェクトの特効薬ってのは,そうそう見つかるもんでもねいんでないかなぁ......とか思ったりします。工事進行基準的な考え方が要件定義工程をしばることができるなら,そもそもの手戻りが少なくなる可能性は期待できそうです。夢見がちな要件定義を現実に引き戻す......とかいったところか。