TOP＞プロジェクト管理＞ さあ困った 〜突然の仕様変更〜

だからあなたの会社のシステムは動かない 〜システム発注担当者の悩みを解決します〜 第９回： さあ困った 〜その時発注担当者がするべき事は〜 著者：システムクリエイト  田中 徹   2005/1/21

1   2  3  次のページ

さあ困った 〜突然の仕様変更〜

開発会社との打合わせから設計・開発と順調に作業が進めばいいのですが、仕様変更を余儀なくされることや、スケジュールの遅れ、思いがけないトラブルに見舞われることも多くあります。そんなとき、発注担当者や情報システム部にはどのような対応が求められるのでしょうか。そういう事態になったとき、備えておくべき普段の心がけとは何でしょうか。    仕様変更が発生する原因としては、発注側の都合によるもの、開発側の責任に依存するものとがあります。次にそれぞれのケースについて説明をします。

発注側の都合による仕様変更

発注側の都合による仕様変更の原因としては、次の2つが考えられます。

（1）業務に変更があった （2）開発中のプロトタイプ版などを見て、各部署から意見が出た

いずれにしても、実際の業務に合わないシステムや、システムに不満を持ちながら使い続けることは困難なので、開発会社に仕様変更を申し出るしかありません。ユーザーインターフェースのちょっとした修正なら簡単に済む場合も多いですが、機能そのものを修正する場合などは、スケジュールの再考が必要になります。その場合、当然費用も発生します。    まず社内で、「できれば変更したい」という程度なのか、「どうしても変更したい」のか、意見をまとめる必要があります。その結果、どうしても修正する必要があると判断されたならば、開発会社に仕様変更を依頼し、スケジュールの再調整を行います。スケジュールが延びれば費用も掛かりますが、ある程度は仕方ないでしょう。    仕様変更に至った原因が、先に述べた（2）のケースのように、事前に意見調整をしていれば防げたかもしれない、ということもあります。ですがシステムに対する要望の必要性を認識し、今後に活かせれば、決して高い授業料にはならないはずです。    後から仕様変更や修正要望が出ないように、事前に社内で機能についての検討を行うことは難しいかもしれません。しかし、各部署がシステムに対する意識を高め、十分な討論を行う習慣を身につければ、発注側の都合による仕様変更はぐっと減ってくるはずです。

開発会社の責任による仕様変更

開発会社が行った設計に無理があったり、設計評価結果が不十分で、機能を十分に果たせないと判断され、仕様変更を余儀なくされる場合があります。これは当然開発会社の責任において処理されるべきことですが、発注側としてもとるべき対応があります。    まず、失敗の原因調査や説明を求めるのは当然としても、その前にスケジュールが変わってきますから、スケジュールを優先するのか機能を重視するのかを決めなければなりません。責任追及はその後になります。    とりあえず代替案や現行の設計で開発を行い、スケジュールに間に合わせます。その後で仕様変更の箇所について修正する、というのはスケジュール優先の考え方です。　本番開始日に特に強い理由があり、どうしてもその日に立ち上げなければならない場合などは、そうするしか方法がありません。    それとは逆に、「何が何でもスケジュール優先」でなくてもよい場合があります。そういうケースなら、多少時間は掛かりますが、十分な設計をしてもらえばいいのです。しかし発注担当者の多くは、スケジュールを守らせることが重要な仕事であると考え、「何が何でもスケジュール通り」を要求することが多く見られます。    安易にスケジュールの遅れを認めるわけではありませんが、時間を掛けた方がいいものが出来るなら、社内に対して理解を求めることも必要です。    それには常日頃から開発会社に対して、問題が発生したらなるべく早めに報告をさせる、という習慣をつけさせることが重要です。「発生したら」ではなく「発生しそうになったら」というくらいで丁度いいでしょう。そういう関係が築けていて、はじめてスケジュールの再考が意味を持ってくるのではないでしょうか。

発注側・開発会社、どちらの責任でもない場合

こういうケースの代表例が、使用しているツールのバグやOSなどを含む環境が謳い文句通りではない場合です。    データベースの限界範囲内でもオーバーフローを起こしたり、開発言語のバグにより機能を実現出来なかったりします。ある程度は予見できることが開発会社の経験に基づくスキルである、という見方もできますが、予見できなかったからといって開発会社の責任にするわけにはいきません。契約書で謳われている「定めのない事項については、別途協議の上…」ということに該当し、発注側・開発会社で誠意をもって協議するしかありません。    この場合でも、スケジュールを優先するのか機能を優先するのかで、開発会社に求める優先順位が変わってきます。別の章でも触れましたが、こういうときに無駄な時間を費やすことなく開発会社に指示出来ることが、社内体制における発注担当者への権限です。

1   2  3  次のページ

著者プロフィール システムクリエイト有限会社  田中 徹 代表取締役。1963年生まれ。MS-DOS時代から、汎用機−PCでのデータ送受信を行ってのチャート（金融業）、表・グラフ描画（財務系）などのシステム開発を行う。 社内人事管理（勤怠・人材活用）、流通業、制御系の分野や集計業務なども手掛ける。ソフトウェアハウスや大手開発会社まで多数の現場で開発を経験し、33歳で独立。現在は各業種・分野でSEとして、またシステムコンサルタントとして活動中

INDEX 第9回：さあ困った 〜その時発注担当者がするべき事は〜 さあ困った 〜突然の仕様変更〜   さあ困った 〜プロジェクトが中止に〜   本番開始後のトラブル

だからあなたの会社のシステムは動かない 〜システム発注担当者の悩みを解決します〜 第1回 システム発注担当者の苦悩 第2回 システム開発の流れ 第3回 開発形態と開発会社の規模による違い 第4回 見積もりについて 第5回 発注側の体制・社内体制を整える 第6回 発注担当者に必要なもの（1）〜業務知識とIT知識、業務フロー〜 第7回 発注担当者に必要なもの（2）〜社内調整、SEとの付き合い方〜 第8回 そもそもSE、プログラマってどんな人？ 第9回 さあ困った 〜その時発注担当者がするべき事は〜 第10回 本番に向けてのテスト 第11回 先達に学ぶ 〜トラブル事例紹介〜 第12回 よりよいシステムにするために