＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
ソフトウェアハウスとの付き合い方
| 投稿者 | 投稿内容 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-11-26 02:49
この問題の根本的な原因はカネを渋ったから。
依頼する側に能力がないのであれば、それなりのカネを払え。 IT関係の場合、結局払わせられることになることが多いが。ｗ もちろん何事でも、人（企業）を見る目が必要ってのはわかってるよな？ｗ | ||||||||||||||||||||||||||||
|
投稿日時: 2004-11-26 09:47
いやぁ、きくじろうさん、大変そうですねぇ。
お話を聞く限りでは、そのソフトハウスとは一刻も早く付き合いをやめた方が良いような気がしますね・・ とはいえ、それも難しい状況のようですね。逆に予算を取ることができるのであれば、御社側にきくじろうさんに変わる、プロジェクト管理者を雇い入れるという手もあるのかもしれませんね。 日経ITプロフェッショナルの雑誌などを見ると、なにやら修羅場になったプロジェクトに突如として現れて、スケジュールの立て直しやコミュニケーションの確立などをやるお仕事をされているエンジニアさんがいらっしゃるとのことです。 探してみてはいかがでしょう？ がんばってください！ | ||||||||||||||||||||||||||||
|
投稿日時: 2004-11-26 12:35
もう1年近くも遅れていたんですね…
ゴールデン・ウィーク明けくらいにカットオーバーを迎えられれば、いいですねぇ…（勝手な想像） そういえば、基本設計書って、その後完成したのでしょうか？ 問題が収束しないのは、設計がガタガタだからでしょうね。 別段、コミュニケーションだけに注目が行っているわけではないと思いますが…前回のスレのままだと、私がこんなことを言うのは変に思われるのかな。 大事だと言ったのは、接点が少なければ状況がヤバくなっても察知しにくいですし、思い込みも多分に入りやすくなるでしょう、という意味でした。 ベンダーを変えたりするつもりは、ないんですよね。 （「できない」 って会社から言われちゃったのかな） | ||||||||||||||||||||||||||||
|
投稿日時: 2004-11-26 13:18
こんにちは
あ り ま す。 末端のプログラマはいわれたことをやろうとしますし、やります。 プログラムが出来上がってもっていって、実際のお客さんの話を聞いたら 「そんな話はきいてないよ」という話は山ほど聞きます。 ひとえに中に仲介している営業とかSョとかのおかげです。 最初の話から途中で仕様がどんどん膨らんでいって当初の話とかけはなれて 行くというパターンがあります。 最初の料金のまま、お客さんがあれもいれて、これもいれてとわがままを言い出す。 それ以上は追加仕様なので別料金ですと営業とSョが言えばいいのに力関係で押し切られる。 あとは、途中で思い出しては変更、思い出しては変更。 どんなに最初にいい設計をしていても、接木状態になるのは必然。 品質も上がるわけがない。最初から言ってください。 あと、出来上がる直前に仕様変更。お客さんが「ちょっとの変更でしょ」と 言って押し込もうとする。実際は根本に近い変更で、ひどいと作り直しに近い 変更でどうしようもなくなくなるというパターン。 営業がほいほいとうけてくるとこれも悲惨。 なるべく早くできれは開発期間の最初の1/3の期間の間に、概要設計で一度仕様を固定して、後は別料金ということにしないと、発注側も受諾側の悲惨じゃないでしょか？ 仕様が落ちてる->いれるのに変更。思い出した->変更。これもほしいな。->変更。 設計も試験もやり直し->時間がなくなる->一部設計や試験省略->品質低下 なんてなってませんかね。 この1年でも仕様変更を繰り返してませんか? [ メッセージ編集済み 編集者: ほろりん 編集日時 2004-11-26 13:30 ] | ||||||||||||||||||||||||||||
|
投稿日時: 2004-11-27 23:42
随分と書き込みを頂きまして有難うございます。
煽られているだけかもしれませんが、まさに工数精算的な発想ですね。 さぞかし大企業か大手SIで大プロジェクトを経験されたのでしょうが、 お金を出せばどんなプロジェクトでも成功するんでしょうか？ そうした発想が銀行のシステム統合で失敗を招く原因のように思います。
はゆるさんの仰られたことに対して文句を言っているように聞こえていましたらどうかお許し下さい。設計のミスと管理のミスを棚に上げている先方が腹立たしいだけです。
そういう局面も確かにあります。仕様の膨らみには色々な原因があるかと思います。 あ、こういうのがまさにコミュニケーション不足というのでしょうね。 仕様の食い違い・確認不足はお互いに責任があるとは言えます。 でも要件が曖昧であるならば、それを明確にすることもプロのSEとしての仕事だと思います。曖昧な部分は切り捨てるなりして、動作としての一貫性を保つのはシステムとしての必須要件だと思います。発注したのはプログラミングではなく、システムであり、開発工程の中に要件定義も含まれている訳ですから。 要件を伝えるのは、発注者の責任ですが、内部設計は受注者の責任に他ならないと思います。また、入力した結果、処理できなくなるデータが発生するとか、いう問題は内部設計の漏れの問題だと思うのです。 結局は、何も伝えなくても最低限の行為は行ってくれるソフトハウスを選定すべきとしかいいようがないのかもしれません。 皆さんは、もし予算と開発のマンパワーともに限られているとしたら、業者選定をどのように行われますか？ 開発担当者を見ると言っても、大部分を工程を外注化したり、羊頭狗肉ということもありますしね。 結局は会社の規模と実績に頼るしかないのでしょうか？ | ||||||||||||||||||||||||||||
|
投稿日時: 2004-11-28 00:34
こんばんわ．
自分は別段，きくじろう様を支持するつもりは毛頭ないのですが， やはり「が不足していたから bug が生じる」というのは ちょっと違うと感じます． 「単なる programing」なのであれば， 更にはほろりん様ご指摘のように仕様の変更が相次いだのであれば 「そのとーりでしょ」と受け止められます． ですが，きくじろう様の言葉を引用させていただきますが， system として「如何に動かすか？」を求められて， bug があった，つまり「妙な動きをする」原因を 仕様の把握不足や打ち合わせ／話し合い不足に起因すると認識するのは， ちょっと信じられません． 間に入る SE や sales man が「無理を聞いてきてしまう」のは， ゴリ押しするお客さんの責任ですか？ 「仕様変更です，追加でお金を」といえばよい話では？ それが言えないのは，受注の段階でそれらを条件に盛り込んでないからでは？ あるいは条件が盛り込まれているにもかかわらず引き受けてしまうのは， 引き受けた側に責任があるのでは？ それらを抑制できない sales man や， 状況や工程をどの程度圧迫してしまうか想像すらしない SE は， 単にかわいそうなだけでしょうか？ 少なくともこれまでの書き込みできくじろう様の側が 「度重なる仕様変更」を強要したようには思えませんが， ホントのところ，そのようなことはあるのでしょうか？ -> きくじろう様 それらがない場合でも， > あ り ま す。 なのでしょうか？ -> ほろりん様 そもそも入力によって正しい出力が得られないのは， 状況の問題より system の不出来に起因するとしか考えられないのですが， この考え方は間違ってますでしょうか？ 一度受注しておいて， 「いろいろモノイリなので追加料金です」な話は多いのでしょうか？ -> 秋風様 「この見積もりでこれだけできます」で受注して， 「bug があるから直してね」と頼んだら「じゃ追加でお金払ってね」 ということを仰ってます？ なんとなく，欠陥住宅問題を見る思いだったりしてます． 自分は system 開発に疎いので，率直に疑問を感じてます． できればご教示いただきたく． | ||||||||||||||||||||||||||||
|
投稿日時: 2004-11-28 01:19
選定できることはありえません。 発注側も受注側もエスパーじゃないんですから。双方とも持っている企業文化、業務知識、 常識などが異なるので何が最低限と思っているかは絶対に食い違います。 もしかすると「何も伝えなくても最低限の行為」という文章を私が誤解してるだけかもしれませんが。
お金をだせば成功するという発想に疑問をもつのは同意。しかし、たとえば、 みずほの場合、途中まで開発していたのが、行内の力関係で開発方向が二転三転し途中まで 開発したシステムを放棄して作り直したせいだと聞いています。開発期間の半分まできて、 全部作り直せというのはあんまりです。 トップがふらふらしているからこうなったんで、今回の発注の問題に当てはめるのは間違い。 しいていえば、発注側が途中で(自分のせいなのに)、今までのは全部破棄して納期も延ばさず 作り直せと言ったほうが正しい。 発注側(トップ)が自分で種をまいた形です。 ＃そこでNOといわないSEも悪いとは思うが。でもNOといっても押し切られたろうな。 現場はもう修羅場でしょう。
これは同意。 ＃そこのSョさんたちは議事録を提出してましたか？してなかったら怠慢ですけど。
「入力した結果、処理できなくなるデータが発生」という文章が私はわかりずらかったので、 その解釈で以下の文章が的外れになるかもしれません。 もし、異常入力があったときの動作を外部設計に記述しないという意味だったら、これは非同意。 外部設計は内部設計が漏れなくできる資料でなければならない(と信じています）。 システムをブラックボックスにたとえたとき、その外部から見た振る舞いを記述するのが 外部仕様だと思ってます。ということは、異常入力のあったときの動作も記述すべき。
同意。
微妙。 方針は支持。 発注側と受注側の持っている背景が違う以上、同じものをみても解釈が食い違うことが あるのです。持っている常識も異なります。発注側が当然と思っていて伝えなかったことが、 受注側では当然でなかったりすることもあります。双方ともに曖昧じゃないと思っている のが、実は曖昧だったりします。 だから、曖昧だという認識そのものがない場合があります。 最初から曖昧だったのをほっておいたのなら、おっしゃるとおりそれは受注側の怠慢です。 (追加)一般的な話をしてます。きくじろうさんのケースは実際はどうなっているのをしらない のでわからないが、そこのSEの頭が悪そうな気はする。 [ メッセージ編集済み 編集者: ほろりん 編集日時 2004-11-28 02:47 ] | ||||||||||||||||||||||||||||
|
投稿日時: 2004-11-28 01:52
ちょっと自分のスタンスを。
自分はきくじろうさんのこのケースだけを言ってるのではなくて一般的なケースを言ってます。 で、開発の現場に目を置いた見方をしています。(反則なのかもしれませんが) 私はどちらかといえば、きくじろうさんの場合、SEと営業が無能で、開発現場が混乱している可能性が高いとは考えています。 お客様の立場からすると現場とSEは同じ会社で切り離して考えられないのは理解します。 しかし、自分の議論上、外部設計をするSEと実装をする現場は切り離したい。 ＃だからといって受注側の責任を否定するわけではない。
えーとこの文章はきくじろうさんのケースを言ってるわけですね？ 私は一般的な話で不具合の原因のひとつに「仕様の把握不足や打ち合わせ／話し合い不足に起因」するケースがあるというかんじだったんですが。 kazさんは「仕様の把握不足や打ち合わせ／話し合い不足に起因」するバグが一般的にありえないといいたいわけではないと思うんですが。
無 能。 バ カ。 く そ っ た れ。 ア ホ。● ね。
かわいそうなのは開発現場。
先に述べたとおり一般的な話のつもりで書いた。
あります。というのが正しいのかどうかわからんが、上のレスに書いたように双方の企業文化、 常識、業務知識の量が違う以上、双方がわかったと思い込んでいたもののなかに微妙な食い違いが出るのは防ぎきれない。(一般的な話)
きくじろうさんの場合は自分にはわからない。きくじろうさんの言い分しか書いてないし、 自分がそのシステムの実物をみたわけじゃない。 一般的に言って外部仕様の不出来でなることもありますよ。 [ メッセージ編集済み 編集者: ほろりん 編集日時 2004-11-28 02:50 ] | ||||||||||||||||||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.