TOP＞プロジェクト管理＞ さあ困った 〜プロジェクトが中止に〜

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

前のページ  1  2   3  次のページ

さあ困った 〜プロジェクトが中止に〜

開発会社も決まり、先方では体制を整えてあとはプロジェクトが始動するのみという状態になったとき、突然こちら側の問題で開発が中止・延期になった場合、どうすればいいのでしょうか。何か保障や賠償をするのでしょうか。

契約書を交わしたかどうか

IT業界に関わらず、一般的に日本のビジネススタイルも、アメリカを見習ってビジネスライクになってきています。とはいえ、やはり契約書の内容・ボリュームではとうていおよびません。「さぁ、いよいよ開発」という段階になっての中止・開発延期というのも決して珍しいことではなく、私自身も経験があり多々耳にします。こういう場合、開発会社に事情を説明した後どういうことが必要になるのでしょうか？何か金銭的に保障すべきなのでしょうか。    法的な見解からではなく、あくまで一般的な慣例としてのお話をします。    まず、発注書を発行したかどうかがポイントになります。業務委託契約書は、あくまで基本的事項を明記したものに過ぎず、案件単位の発注は発注書(注文書)で決まります。発注書を発行していなければ、「事情を説明し期日が決まったら改めて開発をお願いします」という約束で通る場合があります。    発注書を受取る前段階で、SEが担当者からヒアリングし、事前調査を行うことはよくありますが、こんな場合は「無駄になった」ということで納得するはずです。    問題は発注書を先方に渡してからの中止・延期です。この段階ではすでに設計も始まっていますし、必要なプログラマも集めているでしょう。開発側からすると発注側との関係にも影響しますからあまり強いことも言えない、というのが本音ではないでしょうか。おそらく話し合いの結果、設計が終わっている分や設計仕掛中の部分だけは請求することになると思います。    こういうことに慣れている開発会社なら、外部技術者や協力会社を使う場合に、発注元からの注文書を待って下請けに注文書を出す、という順序を必ず守りますから深手を負うことはありません。設計済みのものに対して対価を払う訳ですから、延期になってその時期がきたら有効に使えますので、しっかりしたものを作らせましょう。

延期にしなくていいケースもある

ごく稀ですが、発注側で延期にした方がいいと決定したけれど、よく話を聞いてみたら延期しなくても大丈夫だった、ということがあります。社内の運用ルールが近い将来変わる予定や、取引先の処理待ちでどちらが先になるか分からないなどという場合です。こういうときは「延期して明確になった段階で開発しましょう」となりますが、場合によってはそういう事情を踏まえた設計をすれば済むときもありますので、SEにじっくり相談することをお勧めします。

前のページ  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回 よりよいシステムにするために