＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
プロジェクトの納期遅延について
| 投稿者 | 投稿内容 | ||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-09-06 13:14
皆さん アドバイス大変感謝致します。
発注先は中堅といっても上場はしておりますので、まだ体力はあるとは思いますが、 逆に中途半端な対応を繰り返して信用をさらに失い続けているようにも思えます。 下請法の話も頂きましたが、弊社はソフト会社ではありませんので、 これには該当しないのではないかと思います。 確かにソフトも対象で、納品３ヶ月以内に支払という基準があるようですね。 知りませんでした。 こまるのは、はゆるさんのご指摘のように、いろいろなコストは発生しています。 破棄する予定のＨ／Ｗのリース料や保守料などです。 こうした費用だけでも、賠償して欲しい位ですが、難しいのでしょうね。 いっそのこと、さじを投げてくれないかなとも思ったりもしています。 | ||||||||||||||||||||||||
|
投稿日時: 2004-09-06 14:39
匙を投げてくれるのを期待しているうちに、さらに焦げ付きますよ（苦笑）。
たとえ投げてくれたとしても、別の会社さんに引き継ぐ際のオーバヘッドが大きいでしょう（イチからやり直したり、プロジェクト自体がポシャったりするのでなければ）。 どちらがよいとは、一概にはいえないと思います。 それと、会社側は、このプロジェクトの現状を認識しているのでしょうか。 # 認識できるような資料を提示していますか？ 周囲とは相談していますか？ 後になればなるほど、色々な意味で身動きが取れなくなってしまうとも思います… | ||||||||||||||||||||||||
|
投稿日時: 2004-09-06 15:46
これは「まだ検収してないから支払できない」という遅延工作を禁じるためだから、 ちゃんと検収した上で「こんなもん受け取れるかああっ！！」と言って叩き返すのはアリ。 視察に行って「こんな品質で持ってこられちゃ困るよチミー？」とか言うのもアリ。 下請法を勘違いして、納品したらとりえずお金がもらえると思っている請負が 多くて困りますね。品質が悪いなど「下請事業者の責に帰すべき理由」があれば、 いくらでも受領・支払を拒否することはできます。
| ||||||||||||||||||||||||
|
投稿日時: 2004-09-06 16:15
どもです。がると申します。
色々な方から意見が出ているのようなので、きくじろうさん及び きくじろうさんの会社に対して、ちょいと厳しめの視点から。 ちなみに、私は「フリーで独立してSEをやっている」人間ですので、 視点は「開発している」側にある、という想定で読んでいただければ、 と思います。
このあたりの「出来栄え」ってのは、常に難しい問題ですね。 関門としては ・発注者と開発者との間での「設計段階」の意思疎通がどの程度できているか がまずあるので。この基礎段階で失敗すれば、以降のフェーズでの挽回は 限りなく困難になります。 で、悪意ある、或いは少なくとも問題のある開発会社であれば、最終兵器として 「設計段階での意思疎通に問題があるのだからウチだけの問題ではない」と 開き直り、最悪は「そっちがそのように発注したのが悪いんだ」とまで 言ってくるケースがありえます。
スケジュールをどちらが組んだかにもよるのですが。きくじろうさんの会社が 提出した場合は「そもそも無理な計画だったんだ」、開発会社が提示したと しても「そっちが無理な納期を設定したのが悪い」と開き直る可能性があります。 基本的には「細かいスパンで小さな締め切りを作り、早いタイミングで危険を 感知する」ことが重要であるとは思われます。 また、テストに関しては「詳細なテストを行い、テストの結果報告書を提出」 させることを契約書で義務づけておくと、比較的に事故が減ります。
無理なカットオーバーは明らかに「きくじろうさんの会社の損失」になる ので、可能な限り避けたほうがよいと思うのですが。 …品質が悪いことを認めてなお品質が上がらないのであれば、それは「スキルが ないからどうにもならない」か「口先だけでやる気がない」か。いずれにせよ、 事態は比較的に深刻であろうと思われます。 ちなみに「(そもそものスケジュールに無理がある、というあたりを理由として) 人員を増やせば品質が上がる」と持ちかけて金額を吊り上げるケースや(時間が タイトすぎていまさらほかに発注できない、という弱みにつけこむ)、品質が 悪いまま納品して「保守の必要性」を無理やり認識させてそれなりの額の 保守料を請求、保守料で生計を立てている会社、というのもまれに存在 しますので、一応、ご注意のほどを。
ん…まぁ「開発会社が信用できない」のはまぁ当然だと思うのですが。 きくじろうさんの立場が、ってのは微妙に「逆恨み」という気がしないでも ないですがねぇ(苦笑 ただ「会社を選定した基準」ってのを問われる可能性はまぁあるのかなぁ、 と。それに認証をした上司も同罪だとは思うのですが。
あるかないか、でいえば「ある」なのですが、ケースとしてはあまり多くない ケースであるとは思います。 基本的には ・善意をもって根気よく交渉、可能な限り品質を上げて納品をしてもらう なのですが、同時に ・一定ラインを超えて問題が解決しなければ、できるだけ早くその会社と 手を切り、別会社に発注をしなおす ことを視野に入れておいたほうが良いと思います。 正直なところ「ダメなところはダメ」なので、どんなに粘っても「ない袖は 振れない」会社ってのが存在します。 そういう会社とずっとつるんでいても、結局「親亀こけたらみなこけた」状態 で共倒れになるだけなので :-P
今回の場合「スケジュールの度重なる遅延及び(別紙に詳細を記載しての) 品質の致命的なレベルでの欠陥、及び再三の改善交渉にも改善されない 事から、契約の続行が不可能であると判断する」って感じになるんで しょうかねぇ。 とりあえず(契約打ち切りを前提にしちゃってますが)、品質が低い、という 点の具体的な部分を、箇条書きでよいので、きちんとした文面にまとめた ほうが良いと思います。 基本的には 「仕様書(提出された詳細設計の引用、または議事録の引用が望ましい)に は＊＊のように記されているが、**/**納品されたプログラムの挙動を 以下のようにテストしたところ○○となり、仕様書と異なる/機能が十分 に動いていない/仕様が欠落している」 という文章を、問題点のそれぞれについて書いていく、って感じです。 手間はかかりますが、その文章を開発会社にたいして提出して問題点を つぶすもよし、裁判の資料にするもよし、別会社に発注するときの参考資料 として「変なものを作るなよ」と釘をさす材料にするもよし。 大変だとは思うのですが。頑張ってください。 | ||||||||||||||||||||||||
|
投稿日時: 2004-09-06 17:04
企業の電算部で自社システムの開発のお話ですね？
となると完全なエンドユーザー様じゃないですか。 さきほどは「発注側も完璧な仕様を提示していないことが多い」と言いましたけど、 エンドユーザー様となれば話は別です。設計書も受注側が提出しているのでしょう？ たとえ基本設計に確認印を押していたとしても、ある程度は文句を言っていいですよ。 仕様書で規定されていない振る舞いであっても「常識で考えろ！」とか言って OK。 もちろん、現行システムのリース延長費用の請求など損害賠償についても、当然請求 してかまいません。それで、現行システムを継続しようすることで当面問題が発生しない のであれば、開発会社の鞍替えはしないほうがいいです。これからは、無償で徹底的に 働かせたほうがいい。 で、そこまで敵対すると、システム完成後のチョビ変でもすごい費用見積りを出されたり しちゃうので、詳細仕様書・詳細設計所をきっちり仕上げさせて、有償変更だけは 他の会社に出す。もちろん、保守もハードウェア保守だけで、ソフトウェア保守は不要。 発注先も大手なんでしょ？ 品質が低い・上がらないのは、 たぶん子請け・孫請けを使っているからだよ。 大変だとは思いますが、エンドユーザーとして毅然とした態度で臨んでください。 | ||||||||||||||||||||||||
|
投稿日時: 2004-09-06 17:54
まあ、まともなＳＥなら、 エンドユーザーさんが作成した設計書を、 そのまま鵜呑みにすることはしませんね。 でも、民法上は、エンドユーザーだとか、 開発だとか関係なく、全てが対等なので、 あくまでも契約上の問題だけかと思いますが。 
正常なＳＥなら、こういうのって、 それぞれの事象ごとに、その都度、 確認するかとおもうのですが、 きくじろうさんの会社では、そういうご質問を 開発会社から受けたことは無いのでしょうか？ 私には双方のコミュニケ−ションが不足していたように思えるのですが・・・。
これは、そうとも言い切れませんね・・・。
＠ＩＴの記事内でも「外資系コンサルタントのつぶやき」にあるように、 低スキルな大手は実際にありますよ・・・。 それと、子請け・孫請けを理由に低品質でよいなどと言うことが、 通るはずも無いですから、この出来上がってきた品質が、 この会社本来の品質です。 | ||||||||||||||||||||||||
|
投稿日時: 2004-09-06 18:12
皆さん重ね重ねアドバイス頂きまして有難うございます。
作る側の立場として、或いは協力会社への発注をされている立場として同じよう な苦労をされているものとお察しします。 実のところ、私も以前は逆の立場にいた人間です。 似たような立場に立たされた経験も無くはありませんので、開発する立場の苦し みも少しは分っているつもりです。決して逆襲のつもりで接しているわけでもな いのですが。 はゆるさんの言われる通り、こういった状態も包み隠しておいても、 後に行けばいくほど大きな問題になっていきますので、上司にも全て報告済みで 先方の担当役員も挨拶にきて、体制の見直しを約束して帰りました。 プロジェクトというのは、今までうまく回らなかったものが、要員を数名増員し ただけで簡単に立て直せるようなものでないことは皆さんもご承知だと思います。 納期設定は、当方の提示なので最初は苦しかっただろうと思います。 しかし、ＵＴ〜ＭＴが終った段階で大丈夫との報告を受け、品質的にみてそれが 無理ではないかを判断したのは当方です。 受け入れ後、数百件のレベルで不具合が発生しており、その修正の確認のレベル で３分の１位はＮＧで返ってきます。 普通であれば、できないのであれば、その範囲を明確にするとか、運用でカバー する方法を提案するとかの提案があって然るべきだと思います。 実のところ、まだ仕様の保留事項も残っているのです。 ここで検収印を貰わないと要員の手配が出来ないと言われ、止む無く検収印を押 してしまったのが、そもそもの誤りだったのかもしれません。 それを避けるための忠告も相手には伝わらなかったかもしれませんが、幾度とな く行っていますし、対策の報告も受けていますが、結果を見ると、逆に居直りの ような印象を受けるのです。 未記入さんのアドバイスに力づけられました。 今も仕様書のチェックをしているところです。当社独自の仕様ならともかく、常 識的に判断して欲しいという部分までチェックしなくてはいけないのはたまりま せん。でも、最後まで検収印を押さないように、長期戦でいくのが得策のような 気がしてきました。 問題は社内の信用低下と、今まで実施したユーザー教育をまたやり直し、という ところです。 takuさんがおっしゃられるように、コミュニケーションの問題は間違いなくある と思います。仕様の確認を一つ一つ着実に積み重ねなかった結果、不明な仕様の まま、先に進んでしまう、とかいうケースですよね。 でも一番困ったのは、こうしたいんだけど、という問いかけにＳＥさんが黙 り込んでしまい返答が帰ってこないとか、それをこちらから何度も督促しないと しらんぷりされるというケースです。 あと、ＳＥとして当たり前の知識としての実在庫とか帳簿在庫とかの扱いをいち いちどうしましょうと言われたらほとほと疲れてしまいます。 ベンダー選びが非常に重要である、といういい勉強になりました。 | ||||||||||||||||||||||||
|
投稿日時: 2004-09-06 19:54
いや全然対等じゃないですよ。法で保護される順に エンドユーザー > 下請け > 元請け となります。 消費者(エンドユーザー)を保護するための法律がたくさんあるでしょ？ 下請法なんてのは、強者である元請けから弱者である下請けを守るためのものだし。
これには同意。というか大手のほうがスキルが低いことのほうが多いですね。 プログラマを抱えていない、なんちゃって SE だけのところとかあるしね。 「品質が低いのは子請けを使っているからだよ。」というのは、「大手自身が 開発をすれば品質が高くなる」ということを言っているのではなく 「大手自身は開発ができなくて子請け・孫請けに伝言ゲームされているから おのずと品質が低くなる」ということ。 | ||||||||||||||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.