＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
プロジェクトの納期遅延について
| 投稿者 | 投稿内容 | ||||
|---|---|---|---|---|---|
|
投稿日時: 2004-09-07 19:26
その通りかもしれません。 バグが出続ける理由を尋ねても、非常にバグの発生を甘く見ており、テスト要員を増員して収束させるという対策しか採ってこなかった。 どうして出続けるかを自分たちで探すよりも、どうしたら収束することを信用して貰えるか？というスタンスで尋ねてくるから困るんです。 そういう意味では、当初から常に受身の体勢で、 ソフト会社としては、そのほうがリスクは少ないのでしょうが、 社内の打ち合わせでも、一切発言しないのです。 言われたことはできるだけやるが、自分からは物申さない姿勢なんですね。 無い袖は振れない状態かもしれません。 | ||||
|
投稿日時: 2004-09-07 19:39
こんばんは。
何のアドバイスもできませんが、 なんか気になるんですが、 きくじろうさんは どういう基準であるいは方法でその逝っちゃってる？ソフト屋さんを 選ばれたんですか？ 納得して選んだのではないですか？ _________________ | ||||
|
投稿日時: 2004-09-08 08:36
おっしゃる通りです。私が選んだので、社内で大騒ぎできないのが悩みの種です。 選考理由はあるのですが、ここで挙げてしまいますと会社名が特定できてしまいそうなので敢えて挙げないことにします。 予算が足りなかったことだけは言えます。 | ||||
|
投稿日時: 2004-09-08 09:28
最初に戻ってしまうかもしれませんが．．． 客観的に見て「バグ」というのはどのようなバグなんですか？ 設計書には書ききれないような常識的なレベル？SYNTAXとか日付のチェックとか．．． それとも設計書そのものが曖昧な為に違う解釈の処理を作成されているとか．．． 前者ならもうテストで潰すしかないかもしれませんね。今となっては．．． 後者であれば、許容できる最大遅延の範囲内でもう一度設計書を精査（ないならば作る） ことをされたほうがよろしいかと思います。きくじろうさんのほうで設計書の元になる 要件書等を精査して（作成して）それを元に．．． ってほとんどリセット状態ですが、結果的にはトータルでは早くなるかもしれませんよ。 | ||||
|
投稿日時: 2004-09-08 09:41
非常に気になるんですが、
きくじろうさんは >私が選んだので、社内で大騒ぎできないのが悩みの種 とおっしゃっていますが、 リース機器の賃貸料など、会社としての損害も出てきますし、 一連を拝読したところ御上司様もこの状態をご存知のなんですから、 大騒ぎとはいかないまでも、現在の焦げ付き状態 （どこまで出来ていてどこまで出来ていないか、 自社は何を要求していて、相手はそれに対してどうしているか） をオープンにしちゃって、部署内に助け（知恵と協力）を 求めたほうが良いのじゃないですか？ ひとりで設計仕様をチェックしていても苦しいですよ。 ひとりでメーカーの背中を叩いていても苦しいですし。 …それでは納期を遅らせているメーカーに対してどう行うか、 という問題も部署の雰囲気にかかっちゃうんですけど。 もし、社内ではもうオープンにしちゃっていて、 そのうえでここで知恵を募っているのでしたらごめんなさい。 | ||||
|
投稿日時: 2004-09-08 13:41
長々とお付き合いいただいて感謝しております。
項目のエラーチェック漏れとか、仕様に書ききれない常識レベルなら時間が解決 してくれるとは思うのですが、今上がってきているバグが、ＳＥのレベルに起因 するように思える内部設計の漏れ、バグのように思えるのでこの先は思いやられ るのです。 例えば、このＤＢのこの列の意味が、税抜きとか値引を含んだものだとか、そう したことがどうも仕様の徹底がされていないようなバグなんですね。 また、例外処理のロジックもあまり考えてないようで、ある事象が発生するとそ こしか見ていないような直し方をしていることの繰り返しなんです。 止む無く仕様書の見直しをしてはいるんですが、目的を本当に理解してやってい るのかどうか疑わしいところです。 うえつきさんのおっしゃるように、 ここまで来ると自分一人で抱え込む状態ではないので、オープンにはしています が、何分にもシステム要員が何人もいるような体制ではありませんので、種を蒔 いた管理者の立場である自分が、発注者の側でやるべきことだろうかと思いつつ、 内部設計書のチェックをしております。 愚痴になってしまいすいません。 | ||||
|
投稿日時: 2004-09-08 15:01
ども、がるです。
前回の書き込みでも特に反応がなかったので蛇足かなぁ、とは 思ったのですが :-P
わりと多くのプロジェクトで問題になる話かと思います。 で、これまた多くの場合双方が「相手が主導権を握ってくれる」ことを 想定して共倒れ、と。 どちらが主導権をとるにしても、それなりに双方の言い分があります (より正確には「相手に主導権を擦り付けるため」の言い分)。 そのあたりは、今からでもいいので明確にしておいたほうが 後々らくだと思います。 で、以降ちょいと話がそれますが。 http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=14636&forum=15&0 で、「「SEが業界に精通している」必要があるか？」というスレッドを 立てました。 一時期この話で盛り上がりつつあり、且つ私も興味があったので、 スレッドからそれないように、別に立てた次第です。 よろしければご意見などいただければ、と思います。 | ||||
|
投稿日時: 2004-09-08 15:18
多分、開発はウォーターフォール型で進められているのですよね？（それを前提に します。） 今さら言ってもしかたないのですがあえて言いますと。 基本的なＤＢ項目や扱い、意味等でこのような食い違いが出るというのは、設計 時点でのレビューが不十分またはやっていないとしか思えないのですよ。 オブジェクト指向であれ何であれ、基本項目の意味とか定義というのは早い段階 で決められていなければいけないものですから。ユーザー（きくじろうさん）と 開発者とのレビューで認識合わせをやっておく必要がありましたね。 例外処理に関しては、業務的な例外とシステム例外とで少し変わりますが、どち らにしてもどこかで明確な処理は定義されている必要があります。これもレビュー でわかります。システム例外に関してはきっちりとした会社では、品質チェック という品管のチェック工程でも指摘されます。たいてい複数回の機会があって、 設計ドキュメントでのチェックとテスト仕様書やテスト内容のチェックというと ころで大抵は指摘されます。（でも細かい部分は抜けとか出ますけどね。） やはり、「やるべき事をやっていない」というのが原因で、一番のところは レビュー不足でしょうね。これは開発側にも重大な責任はありますが、きくじろう さん側にも全く責任が無いというわけでは無いと思われますので．．． この際、規模がどれくらいかわかりませんが、可能なら１、２週間でも缶詰状態に して、説明＆レビュー（きくじろうさんが説明→開発者が設計書をチェック修正・ 作成→開発者が設計書をきくじろうさんに説明）というのを徹底的に繰り返して みることですね。その後でプログラムがそのまま修正で可能か、全面再作成にな るのかということです。（極論で言えば、全面再作成でもそこで完成した設計書 をベースであればプログラミングを他社に発注するということまで考えても良い かもしれません。） 第三者の協力とかもわかりますが、とにかく完成形というのは現段階ではきくじ ろうさんの頭の中にしか無い状態でしょうから、きくじろうさんにしかそれを伝 えることができないはずです。 まぁ、地獄の日々となるかもしれませんが、賠償や責任とかの問題は後で何とでもなる と思いますので、とにかくまともなものをカットオーバーできるようにがんばって ください。 ＃ ってそれでもダメな場合は．．．（爆）しかない？ | ||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.