＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
ソフトウェアハウスとの付き合い方
| 投稿者 | 投稿内容 | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-11-28 02:56
嫌味とかではなく，お話の内容，いちいち御尤もです． 確かに，一般的には書き込まれたような 悲しい場面に遭遇した記憶が自分にもあります． その意味で，front-end と back-end を「切り離したい」という お気持ちはよく理解できました． ほろりん様の書き込みで改めて気がつきましたが， programing 担当が細かく分けられていて， それぞれの unit 間の調整がうまいこといっていないこともあるのでしょうね． その場合もやはり，開発を取り仕切っている SE さんに依拠する問題と言えますね． つまり，開発現場の段階でどれだけ誠実であっても， 成績を気にする営業部署が間にあったり 単なる「まとめ役」に堕している SE が壁になることもおおいにあり得ると．．． この辺は如何でしょう？ -> きくじろう様 「仕様変更の頻発」とともに気になるところです． | ||||||||||||||||
|
投稿日時: 2004-11-29 11:04
前のスレで、再度（基本）設計なりをきちんとドキュメント化しておいたほうが早いですよ．．．というようなアドバイスがあったと思うのですが．．． 文面からしか判断できないので、実際にはどうなのかわかりませんが、この文面を見る限り 今起こっている「不具合」について分析・分類がきちんとできていないように思われます。 まずひとことで「バグ」と言っても、プログラミングのバグなのか、設計のバグなのかと いうことがきっちりと区別する事が必要です。内部設計が悪い為の不具合とプログラムの 単純バグと同じように扱ってはいけません。（責任問題は後で考えましょう。） もし、内部・外部に関わらず設計バグが判明した場合、その部分の先のテストは 止めないといけません。それが、なし崩しにすべてをテスト（検証）している為、 「ひとつの不具合を直しても別のところを直せばまた別の不具合が発生する」というよ うな状態になっているように思えます。 きちんと、不具合が見つかればそれがどのレベルでどこに原因があるかを押さえてから、 まず設計を直さなければならないのか、コードのみを直せば良いのかを吟味してから 改修にあたらないといつまでたっても終わりませんよ。 って、これは開発側でやるべきことなんですが、それがわからなくなるぐらい混乱し てしまっているのではないかと。
予算が少ないときって、単価の高い会社は使えないってことだけでは？（要件の半分だけ とか次期に回すということが可能なら別ですが） それ以外では、私の場合、予算が厳しい場合、持ち帰りは避け、常駐型にしますね。 少なくとも私が発注側担当者であれば、開発側のＳＥはすぐ横の席で作業させます。 コミュニケーション等、会議や打合せなんて悠長な事言ってられないので、日頃から 内容についての細かい話をします。なんと言っても設計のやり直し等「工程の戻り」 が一番費用が発生しますから。 | ||||||||||||||||
|
投稿日時: 2004-11-29 11:35
「現場は悪くない」って言う方、気持ちはよーく分かりますが
せっかく書いたコードなら気持ちよく使って欲しいじゃないですか？ 開発元の中での犯人探しはきくじろうさんのような発注側の人には関係ないことですし。。。 プロジェクトが泥沼化する前に立ち止まるべき時点や判断って難しいところですよね。 個人的に大事だと思うのは「正確な進捗報告」です。 どのくらい信憑性があります？（ほとんど０だったり？） | ||||||||||||||||
|
投稿日時: 2004-11-29 20:54
はい、お腹立ちはごもっともでしょう。 また、その様子では、まったくもって状況が改善されていないのも推察いたします。 私が気にしているのは、 「このプロジェクトの方向性が見えない （会社としての判断も）」 という点です。 もう 1年も遅れているんですよね？ このままですと、きくじろう さんの会社も IR 情報を修正しなければならないかもしれませんよ？ このあたりの記事は、参考になりますでしょうか。 ・ 「動かないコンピュータ」からは脱出できない，陥らないことが重要 （IT Pro さんより） | ||||||||||||||||
|
投稿日時: 2004-11-30 08:53
沢山のアドバイスを頂きまして重ね重ね感謝いたします。
これについては、ちょっと違いますね。先方の部門長レベルの話になっていますので、担当営業は殆ど顔を出しませんし、ＳＥの指示と管理サイクルが的確に行われていないのはほぼ明確だからです。 仕様変更については、明らかな帳票や画面の追加、項目の追加は無くは無いですが、 最も多いパターンは、こうです。 仕様が作成される→レビューの結果誤りを指摘→仕様に反映 （誤りが多いことから、既出の仕様への修正が漏れてしまう） 他の仕様ができる→元の仕様との辻褄が合わないことを指摘→仕様に反映 （この反映がもれる、又はフィードバックされない、確認できない） を繰り返していることは確かですね。 つまり、基本仕様という拠り所が無いので、システムとしての統一が取れず、プロジェクトとして無茶苦茶な状況になってしまった。
結合テストが終わった段階で、基本設計書を作らせ（順序が逆ですが）、詳細設計書を見直させ、それを精査しました。 それでも仕様の不一致が山ほど出ており、修正の要求は出しているものの、相変わらず、目先の対応とテストスケジュール消化だけに没頭しており、テストの品質は果たして大丈夫なのか、問題が解消されているとは到底思えないのです。
私も同感です。進捗報告が的確でないと打つべき手も打てない。 どうもマネージャーはその件数だけを見て動向を把握しているふしがある。虚偽の進捗報告を受け、件数が減れば落ち着いた、なぜそうした問題が起こるのかを根本的に解決しようとする姿勢が見えないんですね。 なんだか、赤提灯みたいな書き込みになってしまいました。すいません。
おっしゃる通りですね。私もバグを発見するという目先のことにとらわれすぎている気もします。 教えて頂いたＵＲＬの記事、大変参考になりました。 動かないコンピュータからは脱出できない．．．．重い言葉ですね。 冷静にここまでの状況なのか、とくと考えて見たいと思います。 | ||||||||||||||||
|
投稿日時: 2004-11-30 10:25
お分かりのとおり順番が逆です。明らかに手戻りがでてますし、工数の無駄が多いです。 これは作成の前にやるべきでした。 もし、ソフトハウスが作成の前に基本仕様書をもってこなかったらソフトハウスの落ち度です。 作成の前に最終的な仕様確認をしなかったわけです。 確認前に見込みで作成にかかることもよくありますが、それでも「後で確認」するよりはソフトハウスに被害が少ないはずです。 また、その「最終的な仕様確認」で作成されたものが顧客と現場の目標になるわけですが、これをしないでいるということは間違った目標のままつっぱしってるということです。 SEが自分の見込みで仕様を作成し現場に下ろし、顧客には最終確認を取らなかったという構図が見えます。 これではSEの現場の管理能力もうたがわざるを得ません。 [ メッセージ編集済み 編集者: ほろりん 編集日時 2004-11-30 10:29 ] | ||||||||||||||||
|
投稿日時: 2004-11-30 11:49
文書を整備した、ということなので、この状態からはもう脱却したんですよね？
文書のレビュー結果がPGに行き届いてないんでしょうね。レビュー結果を確実にプログラムおよび試験項目(これが重要!)に反映するためにどういうことを行ったかを説明してもらってはいかがでしょうか。 文書が完成した(仕様がある程度FIXした)にも関わらず受け入れ試験でNGになるのは、試験のやり方に問題があるかと思います。受け入れ試験で見つけるのは要求定義のミスであり、それ以外のミスはそれまでの試験で見つける必要があります。 試験はできるだけ自動化し、自動化した試験から始める、面倒な試験は後回しにはするけど全て通す、ということをすれば受け入れ試験にNGになることはほとんどないかと。 それでも受け入れ試験がNGになるようであれば、試験内容を見直すことは必須です。 テストの品質が不安なのであれば、どういう試験をしているのか確認してはいかがでしょうか。きくじろうさんが、問題が解消されているとは思えないのにそのままにしていることも問題だと思いますよ。たぶんSEもPGもモチベーションはかなり下がってるでしょうから、試験は適当にすまそう、となってしまうと思います。これが常習化していると、絶対に内部からの改善は起こりません。(短期的には)楽ですから。 試験で発生した不具合は全て報告してもらい、分析しましょう。(分析は非常に重要です) ここでの分析というのは、上がってきた不具合に対し、 ・プログラム上の問題点(どこがどういう理由で想定外の動作になったのか)は何か ・プロジェクト上の問題点(なぜそういうコードになってしまったのか)は何か ・類似不具合はないか ・類似不具合を探すためにどういうアクションを取ったか ・同じ不具合がないことを保証するためにどういう試験を追加したか ・今後、同じ原因で不具合が発生しないようにどうするか を調べれば良い、と思います。 そして一番重要なのが、この分析を実際の成果物に生かす、ということです。実際、分析はしたけど対策が実施されていない、という報告書は山ほどあります。対策が夢物語になっている報告書はつき返しましょうね。 長くなりましたが要約すると、 文書ができた⇒文書を理解してもらいプログラムと試験項目に反映してもらう⇒試験を行う⇒試験でNGになったら、なぜNGになったかを分析し同じ不具合が発生しないよう対策を施す⇒対策が行われたことを確認する という流れを作りましょう、ということです。 こういったことは普通は相手方のPMなり品質保証担当者がやることですが、そういう体制になってないのできくじろうさんがやる/やらせるしかないように思います。 残念ながら、現段階で「ここからここは相手の仕事なのにできていない」と作業範囲を主張したところで相手方の体制が変わらないのであれば(成果物も変わらないので)、主張するだけ時間の無駄です。なんとか自分でやる/やらせることをお勧めします。 | ||||||||||||||||
|
投稿日時: 2004-11-30 12:17
普通、ここまで大きいプロジェクトだと不具合管理票ぐらいありそうなものですがどうなんでしょうねぇ。なんかこれさえないような悪い予感が。
もうやっておられるかもしれませんが、手はじめにきくじろうさん自身の不具合管理票を作成されることをお勧めします。 EXECLとかに発生した不具合の日付、タイトル、不具合や指摘の内容、対処内容、対処日とか書いて表にしておく。 で、これを送りつける。 ＃解決したものは一旦クローズする。修正の関連でおきたものは別件としてまた起こすことをお勧めします。でないと同じタイトルのまま不具合の中身がどんどん変質していく件が増えます。 あと、レビューの内容は本当は受注側が議事録にしないとならないのですがどうなんでしょうか？ レビューの後、相手が正確に理解したか確認は取れてるのでしょうか? #実は先のEXECLはこれの代わりでもあります。 [ メッセージ編集済み 編集者: ほろりん 編集日時 2004-11-30 12:28 ] | ||||||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.