TOP＞プロジェクト管理＞ はじめに

踊るエンジニア 〜システム開発現場の風景 第２回：徹夜と謝罪の下流工程 著者：ビーブレイクシステムズ  鹿取 裕樹   2005/3/25

1   2  3  次のページ

はじめに

要件定義レベルの誤りを修正するためのコストは、要件定義段階で誤りを発見した場合を1とすると、コーディング段階で10、ユーザテスト段階で30から70、稼動段階で40から1000にもなるという調査結果があります。    システムはユーザのビジネスを強化するためのものであり、そのためにシステムがユーザに対して提供すべき機能を、要件定義をとおして決めていきます。完成したシステムがいくら多機能で高性能であっても、それがユーザのビジネスに適合していなければ意味がありません。    苦労したとしても、完成させたシステムがカットオーバーして、お客様に新しいシステムのおかげで助かった、といわれた時はエンジニアとして最高の喜びを感じます。しかし逆に、使いづらい、あの機能は結局使っていない、といわれた時は自分の力不足を悔い、お客様に対して申し訳ない気持ちになります。    後者にならないためには、要件定義の段階でユーザから真のニーズを引き出し、システムとして整合性のある形にしていく必要があります。しかし残念ながら、世の中のプロジェクトはその要件定義に欠陥を含んでいることがよくあるため、それが後の工程に大きな影響を及ぼすという事態が、ままあります。    またプロジェクトは複数の工程の積み重ねで成り立っており、次工程の作業は前工程の成果物に基づいて行われていきます。要件定義・設計といった上流工程における欠陥は、冒頭に述べたように下流工程になればなるほど修正に大きなコストがかかるようになります。そして、その欠陥を直すことになった人には悲惨な日々が待っているのです。    今回は上流工程の誤りが下流工程におよぼす「しわ寄せ」をテーマに、筆者が経験したあるプロジェクトを紹介します。

プロジェクトの概要

今回のプロジェクトで開発するのは商社向けのBtoBシステムで、商社顧客企業はWebブラウザでBtoBシステムにログインします。BtoBユーザ向けの機能は表1、商社担当者向けの機能は表2のとおりの機能を求められました。また、使用するシステム構成は図1のとおりです。

発注 見積 購入履歴からのリピート発注 注文状況照会 担当営業者への問い合わせ 在庫照会

表1：BtoBユーザ向けの機能

売上データの分析 顧客からの問い合わせに対する返答

表2：商社の担当者向けの機能

図1：システム構図

相当数のアクセスが見込まれましたが、サーバにはLinux、WebコンテナにはTomcatを用いていました。BtoBシステムは基幹システムと連携しており、マスタデータ、トランザクションデータは基幹システムで保持していました。また、売上データの分析でレポート出力にPOIというオープンソースのライブラリを使用しました。    プロジェクトの体制は図2のとおり、複数の会社による開発チームでした。ある程度の規模のプロジェクトであれば、よく見られる体制です。要件フェーズと、それ以降で関与する会社が異なり、筆者は開発フェーズから参画しました。この体制が今回の問題の原因の1つでした。

図2：プロジェクト体制

スケジュールは全体で6ヶ月になり、内訳は要件定義1.5ヶ月、設計0.5ヶ月、実装3ヶ月、テスト1ヶ月でした（図3）。実装フェーズの途中から私が参画したことから察しがつくように、スケジュールは遅延していました。私の参画時点で2週間程度遅れており、初日からフル稼働で実装を行うことになりました。

図3：スケジュール

1   2  3  次のページ

著者プロフィール 株式会社ビーブレイクシステムズ  鹿取 裕樹 オープン系ITコンサルタント。SAPジャパン社にて、ERP導入コンサルティングを行い、そのユーザ企業の現場でJava及びオープンソースの躍動を感じ、それらに興味を持つ。その後、会社を設立。オープンソース及びJavaを用いたシステム提案活動を行い現在に至る。専門分野はSAP R/3と連携するWEBシステムのコンサルティング。

INDEX 第2回：徹夜と謝罪の下流工程 はじめに   仕様変更   発覚した欠陥

踊るエンジニア 〜システム開発現場の風景 第1回 初心者SEと最初のプロジェクト 第2回 徹夜と謝罪の下流工程 第3回 消された案件とチームの事件 第4回 新人とエンジニアのプライド 第5回 彼女の悲鳴は聞こえない 第6回 怒鳴りこみ・すれ違いと真実 第7回 タイムリミットは10日間 第8回 さらば愛しきプロジェクトマネージャー 第9回 標準化に消えたプロジェクトマネージャーの信念 第10回 エンジニアよ、永遠になれ