＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
ソフトウェアハウスとの付き合い方
| 投稿者 | 投稿内容 | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-11-22 20:06
「プロジェクトの納期遅延について」のスレッドを書いた者です。
http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=14494&forum=15&40 恥の上塗りのようですが、プロジェクトのその後です。 当初のカットオーバー予定が１ヶ月延び、２ヶ月、、、もうすぐ１年オーバーに届 くような状況です。 体力勝負のような形で今もプロジェクトは続いています。 詳細設計書の見直しということで、ほぼ一通りのチェックを済ませました。 誤字脱字は言うに及ばず、 目次が無いので抜けが分からない 同じ処理をするのにプログラムによって違う処理をしている プログラムのIDが途中から変っていてその修正がもれているため検証も困難、 という状況にあります。 よくこれでプログラム作れるなあと思うような作品もあります。 並行して不具合が山ほど発生しているため、レポートを出していますが、 修正の報告のあったもののうち、１割程が実際には直ってきません。 中には、別の不具合を派生させるケースも増えてきており、発生件数も1000件を数える程になってきています。 仕様書の修正依頼をした分もフィードバックされたりされなかったりで、管理もままなりません。 悪魔のサイクルというのはこのような状態を言うのでしょうね。 悪循環を一旦クリアにするために、仕様の見直しと基本設計のやり直しをした筈なのですが、状況が一向に改善されるどころか、全てやる事が後手後手で手戻りがますます増えていく、この傾向はまだまだ収まらないような気がしています。 詳細設計書の検印を欲しいと盛んに言ってきますが、押す気にはなれません。 テストも日程を消化しているだけで、バグの発生件数もそれほど出ておりません。 明らかに逃げの姿勢に入っています。 最近では、人のアサインが難しくなってきたので、何かを名目にして費用を捻出して欲しいとまで言うようになってきました。 責任者に何度クレームを入れても状況は同じです。 社名を公表したいくらいですが、これがある機種では有名なパッケージを作っているソフトハウスの実態です。 体力勝負で行くところまで行くしかないのでしょうが、このような場合、皆さんならどうしますか？ 言葉は悪いですが、タコ部屋に入れて監禁するべきなのでしょうか？ [ メッセージ編集済み 編集者: きくじろう 編集日時 2004-11-22 20:07 ] | ||||||||||||
|
投稿日時: 2004-11-22 22:21
おお、あの話の続きですか。面白そうだ。
誤字脱字があるということは相当ひどい状況ですね。「誤字脱字くらい…揚げ足とりしなくても」と思う人もいるかもしれませんが、誤字脱字があるまま外へ出てくるということは内部のチームでレビューなどを一切やっていない可能性が高いです。普通 2〜3人が提出予定のドキュメントに目を通せば、ほとんどの誤字脱字を見つけられるはずだけど…。そういう体制も取れない状況なのでしょう。完全に(それぞれの作業が)個人任せになっていて、その人の作った資料に誰も目を通さずに客先(きくじろうさん)に提出しているんだと思います。 組織として誤字脱字ばかりある資料を提出してくるところは本当に要注意。
バージョン管理もしてなければ、退行テストもしていないのでしょう。あぁ、恐ろしや。 | ||||||||||||
|
投稿日時: 2004-11-23 01:47
私も誤字脱字・スペルミスだらけのドキュメントには辟易します。 見直しやスペルチェックくらいしろよ･･･とエンジニアに対して呆れます。 レビューは誤字脱字を探す物ではなく内容を吟味するものと考えているので、 レビューの段階で誤字脱字がひどいのは論外。 話が脱線してしまいましたが、きくじろうさんのような酷いソフトベンダに 当たったことは無いです。品質の悪いソフトに泣かされたことはありますが、 どこも責任を持って対応してくれたので。 最低なソフトベンダに当たらないように神社にお参りするとか・・・ 冗談ではなく、けっこう本気だったりします (^-^ 
| ||||||||||||
|
投稿日時: 2004-11-23 02:06
NAL-6295です。
相当酷いベンダですね。 いっそ、すっぱりそこのベンダとのつきあいをやめて、他のベンダと一からやり直した方が早く完成したりして・・・。 もちろん、このベンダとのやり取りで学んだ事を生かさなくてはいけないけど・・・。 それにしても、不具合発生件数１０００件以上って、万が一全て治ったように見えても、相当品質の低い代物になりそうですね。 体力勝負で頑張って貰っているという事は、それだけベンダ側のモチベーションも集中力も作業効率も低下しているだろうし、それによるミスも多そうだし、品質向上は望めそうもなさそうですね。 許されるなら、うまく行かなかった原因を特定し対処する方法を考えた後、他のベンダと仕切り直しを計ってみては？ | ||||||||||||
|
投稿日時: 2004-11-23 11:09
皆さん、メッセージ頂き有難うございます。
私自身逆の立場でこのような状況に陥りかけたことはありますが、この会社の場合、 体力不足で無い袖が振れない状態になっているようです。 ぶちきれてお引取り願おうと思ったこともありますが、契約破棄することは当社に とっても大きな損害になるため、生かさず殺さず？の状態で受入れのテストを続け ています。既に支払いの大半を済ませており、最後の強硬手段に出てくる可能性も 無いとは言えないからです。 先方のダメージも大きく、ＩＲ情報では業績の下方修正も行っているようで、先方 のモラルも相当に低下しており、品質にそれが現れてきているようです。 このような状態になった時、 ベンダー側の採る方策としては、 ・企業のメンツにかけても総動員体制で最後までやり抜く ・支障の無い範囲で稼動させ、機能追加の名目で予算を取り完成形に近づける ・とにかく納品検収までこぎつけてそそくさと逃げる この何れか（混合形含め）だと思うのです。 発注者側の立場は１つ目を希望しますが、場合によっては２つ目のほうが望ましい 場合もあるかと思っています。 ただしこの会社の場合には無駄な投資になり兼ねませんので受入れられにくいです。 随分とこのプロジェクトでは勉強にはなりましたが、目の前の難題が解決されない ことには正月もゆっくり休んでおれません。 この会議室に来られている大半の方がそうかもしれないですが、ベンダーさん側の 立場としてのご意見がありましたらお聞きしたいです。 | ||||||||||||
|
投稿日時: 2004-11-23 15:11
これは無いでしょう。うちの会社でもデスマーチしているチームがあったりしますが、それはそれ。他のチームの人間を湯水の如く投入してリカバリーに努めるということは まずしないです。会社としては利益を出せる健全なチームを崩したくないでしょう。どうせデスマーチになってしまっているんだから関係者(犠牲者)は少ないほうがいい。利益を考えている会社は、デスマーチに優秀な人材を追加投入するなんてことはしません。
可能なら部分スタートは良い方法だと思います。ただ、追加機能の名目で追加支出をする必要はありません。逃げられないようにソフトウェア保守契約を結び(部分スタートで機能が限られているので初年度の保守費用は通常の半分くらいを要求してよい)、その保守費用だけで、残りの開発を続行させて構いません。費用が出ないと開発要員をアサインできないなどの言い訳を聞く必要はありません。
これだけは防がないといけない。きくじろうさんは、ずいぶんとマメに検収をされているようですが、それでも実際にシステムが動き出せば さまざまな不具合が出てきます。プログラムバグだけでなく業務設計上の不整合とか。そうなったときに、相手に逃げられているとシステム自体がゴミ箱行きになりかねません。ソフトウェア保守契約を結び、安定稼動までの責任をきっちりとらせてください。 | ||||||||||||
|
投稿日時: 2004-11-25 22:29
アドバイスを頂きまして大変感謝いたします。
そうですね。どうもそんな傾向にあります。人員追加したようですが、新人クラスのＰＧを補充した結果、表面的な対応でバグを増やしたり、実情のわからないマネージャーが、実働者の間接業務に掛かる工数を増やしたりして、かえって逆効果を及ぼしているようにも見えます。自分もそんな経験が無いこともないです。
既に既存機のリース料を初めとして、遅延による損害が出ている状態で、出来上がった後なら、機能追加とかなんとか名目が付くのでしょうが、出来てもいないものに対して費用を捻出するのはかなり難航しそうな気がします。 少し前、ＩＢＭの社長が工数精算の発想から脱却しよう云々の発言をしたことがありました。どれだけの工数を掛けたかではなく、どれだけのものが出来るかが重要だと思うのですが。 前回のスレッドで、沢山の方々からご意見を頂きましたが、焦点がコミュニケーションの問題に集まってしまいましたが、私はむしろ、契約の効力とは何か、開発者の責任は何処までか、ひいてはプロジェクト管理のあり方を訴えたかった。 コミュニケーションの問題から発生するのは、仕様が間違っている、つまりAがBになっているという勘違いであって、AなのでBである、BなのでCである、でもAはCになっていない、というのはシステムの設計能力の問題であり、コミュニケーションの問題とすれば、開発者側のコミュニケーションの問題も大だと思います。 現在の委託先もそうなのですが、品質の悪さから問題のすり替えをしているように思えてなりません。 もっとも委託先から言わせれば、品質の悪さを招いたのは、発注者側の仕様把握力の不足だと言いたいところで、これもコミュニケーション不測に起因するものをいうところなのでしょうが。 長くなりましてすいません。 | ||||||||||||
|
投稿日時: 2004-11-25 22:41
こんばんわ．
かなり門外漢ですが，ちょっと気になったので． bug や不具合の原因が仕様の把握不足だったり， communication 不足だったりすることってあるのでしょうか？ 結局「成果が出てない」ように思えますけど， 「もう，いー！」とは行かないのですよね． | ||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.