Entry

夢見がちな要件定義を現実に引き戻す工事進行基準

2008年04月04日

話題になってるこちらの話。

一般的に日本のシステム開発は要件定義やユーザー企業との契約が明確でなく、開発中の手戻りや期間の超過が多い。開発終了後でないと売り上げや費用が算出できなかった。いわば、正確な見積もりをする前にどんぶり勘定で走り出してしまうプロジェクトが多かったといえる。

(snip)

どんぶり勘定をやめて、開発が始まる前に要件定義を確定、正確なプロジェクトマネジメントを行うことは先進的なSIerにとってはすでに行っていること。しかし、昔ながらのあいまいなビジネスを行っているSIerにとっては痛みが大きいだろう。

デスマーチがなくなる? IT業界に義務付け「工事進行基準」ってなんだ - @IT

なんかですね……燃えるプロジェクトって,もはやどこが悪いんだかさっぱり見当が付かないんですけれど,基本的に言えるのは,次のようなことだと思うんですね。月並みですけど。

  • 発注側(この場合,普通は基幹システムの業務担当)が自社の業務を理解していない。
  • 受注側(この場合,直接お客さんと交渉して要件をまとめるヒト(SIer/基本設計担当))が,手戻り等々に伴う開発の負荷を見積もれない。

さらに加えて,大きな話になっちゃうけれども,日本の企業の場合,暗黙の慣習とかノウハウが業務と結びついていることが多いこともあげられそうです。ある帳票の端っこに,赤字でちょこっと何かを書くと,注文書が注文書でなくなっちゃう(別の帳票として扱われる)……みたいな。で,そういうもんも含めて,(仕事をするのに必要という意味で)「業務」なわけなんですけれど,それを基幹担当が把握できていない(そこまで求めるのも酷なんだけれども)。で,そういうことが後になって判明して,手戻ったときにどうなるかというと,スキーマとロジック全体を見直す……なんてことはできません。注文書スキーマに変なカラムができるんです(赤字で付加したトコロに相当)。

と,そんな具合に,純粋に注文書テーブルとはいえない,なんとも気持ちの悪いスキーマができる……こともある……のだろう……多分……(と,言っておく)。

その一方,ユーザ要件を定義する担当は,技術的に手戻りの負荷を見積もれない。要件的には些細な変更でも,ロジックが大きく変わってしまうことはままあったりします。そゆのを見積もれないもんだから交渉の手札がないわけで(これは交渉する上でひどいディスアドバンテージだと思う),安請合いしてしまう。そもそも,「Java は知ってるけどプログラムを組んだことはありません」とか「C++ ってなんですか?」とかいった向きでも,プロマネはできる(ことになっている)わけで,必ずしも求められてるスキルじゃないんでしょうけどね。

さらに,実装の問題にしてしまうと,基本的な話として,DOA や OOP 的な考え方が身に付いていない(処理を抽象化できない)ってな話があったり……。例えば,カラムをひとつ追加するなんて場合,ちゃんと機能分割して抽象化しておけば,数行の変更で済むはずなのに,半日がかりの作業になっちゃったり……とかとか。

そんなもんで,燃えるプロジェクトの特効薬ってのは,そうそう見つかるもんでもねいんでないかなぁ……とか思ったりします。ただ,工事進行基準的な考え方が要件定義工程をしばることができるなら,そもそもの手戻りが少なくなる可能性は期待できそうです。夢見がちな要件定義を現実に引き戻す……とかいったところか。

Trackback
Trackback URL:
Ads
About
Search This Site
Ads
Categories
Recent Entries
Log Archive
Syndicate This Site
Info.
クリエイティブ・コモンズ・ライセンス
Movable Type 3.36
Valid XHTML 1.1!
Valid CSS!
ブログタイムズ

© 2003-2012 AIAN