＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
ソフトウェアハウスとの付き合い方
| 投稿者 | 投稿内容 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2005-03-02 22:27
おっしゃられていることの意味が理解しかね、 多忙にかまけて何もレスを入れませんでした。 早く結論を出せ、うだうだといつまでも書くなということですね。 私のコメントが足らなかった分、切迫感がないということなのでしょうか？ 相手ももしかしてこの会議室を見ていないとも限りません。 見てて見ない振りをしてこちらの出方を伺っているかもしれません。 そんな思いもあり、進行中のプロジェクトという性格上、 突っ込んだ内容を書けないこともあること、 駆け引き的な問題もあり、手の内を曝け出すわけにもいかない、 そんな意識が私の文章に中にあり、 そんな印象を持たれたのかも知れませんね。 そんなスタンスが、失礼に思われたらお許し下さい。 | ||||||||
|
投稿日時: 2005-03-03 00:17
るぱんです。
え〜と、攻めたいのではなく、 自分で自分にケリをつけていただきたかったのです。 恐らく思い当たる節が沢山あり、 ドレもどのタイミングも今となっては重要だった。 今となっては何も出来ず仕方がなかったと思います。 そう言う風に考えたのだろうと受け取っています。 でも、次に繰り返さない為に一番何が重要なのかが結論付けられていないと感じました。 あれもコレも大事・・・って言うのもいいんですが、 「一番の肝はココだった・・・。」 と振り返って頂きたかったんです。 客観的に見ることは重要な事です。 進行中のプロジェクトと言うのもわかります。 でも、一番最初のココで先手が打てていたらなぁ・・・。 と言う風に考えた方が次に生きる様な気がします。 そう言うことが言いたかったんです。 火を噴くプロジェクトは あちらこちらで手抜きが起きています。 ただ、全体を見渡せる人がいないので、 「皆一生懸命やってるのに何故かうまくいかない・・・。」 ってなってしまいます。 全部大事なんですが、取っ掛かりを押さえておくと意外と最後まで 行ったりすると考えています。 今回の経験から得たものがご自分の中で明確にまとまっていて欲しいな そう言う風に考えました。 今のタイミングで整理して纏め上げられたら、 次にも生きるし、 今後の展開にも役に立つと思っています。 って、余計なおせっかいでした。ゴメンナサイ。 | ||||||||
|
投稿日時: 2005-04-02 13:51
ゴールの灯火がうっすらと見えてきましたが、まだ予断を許さない状況です。
るぱんさんのせっかくのご指摘を頂いたにも関わらず、中途半端にスレッドを終えてしまうのは、今までこのスレッドを見ていただいた方々に申し訳ないので、随分と遅くなりましたが、返答をさせていただきます。
一言で言ってしまえば、当たり前と言えば当たり前のことで、 経験豊富なプロジェクト管理者の方々にとって見れば、問題外なのかもしれませんが、 「契約に情（なさけ）は無用」といったところでしょうか？ 業者選定のフェーズでは、 リスクヘッジで大手を選ぶという手を取ることもできるでしょうが、 どんな場合でも初めての業者を選ばざるを得ないこともあるわけだし、 大手でも問題外の技術者を持ってくる場合もある、 問題はそうなったときにどうするかという対策になってくるわけです。 それを考えると、情に絆されて、納得のいかない検収印を押してしまった これが全ての失敗の原点になったと思います。 実力のあるソフト会社であれば、 もしたとえ仕様変更があっても、納品時期の問題だけで、その後の品質で挽回すれがよい訳で、しかし、体質的にどうしようもない会社の場合は、どこまで経ってもどうしようもない成果物しか出てこないのです。 それを見極めるには、最初の検収が大切です。 特に立ち上がりの工程で全く駄目な業者は、徹底的に最初の工程（基本設計）でレビューを入れるか、さもなくば、契約打ち切りも可能になります。 こんなことは判りきっているはずで、それもある程度納得して挽回の余地はあると踏んでいたはずなのですが、その部分では自分の判断が甘かったのだろうと思っています。 そういった意味で、今までは業者に恵まれていたケースが多かったということだろうし、 業者選定の重要性もひしひしと感じます。 相変わらず、先方の品質、仕事のやり方は変ってません。その上に、まともに出来もしてないものを平気で検収を求めて泣きを入れてきます。 プロジェクトが立ち上がって落ち着いた状況になりましたら、今後の状況もお知らせするかもしれません。 | ||||||||
|
投稿日時: 2005-04-02 17:21
その大手SIは、 この手の仕事が当初の予定の倍の期間と倍の費用がかかると知っていたから、 既存のものに当てはめるか、 理解に苦しむような高額にすることを選んだのでしょうね。 実際どれくらい難しいシステムなのか私は知りませんけど。 低額や手組（どういう意味？）で引き受けたところは 経験豊富ですごい技術があるか、この手の仕事は未経験なんですよ。 以上推測でした。 | ||||||||
|
投稿日時: 2005-06-04 18:20
システムがなんとか立ち上がりました。
紆余曲折を経ましたが、最悪の事態「動かないコンピュータ」からはなんとか脱却できそうです。 最後のテスト検収は引き伸ばしてカットオーバーの直前で検収印を押しました。 テストはユーザーの仕事という態度がありありと移っており、腹が立って仕方が無かったのですが、耐えに耐えました。 開発マネージャーがバグだらけのモジュールのテストに勤しんでいる私を見て、ヘラヘラ 笑いながら言いました。「テスト大変ですねえ。がんばって下さい」 「こんな平穏なカットオーバーは珍しい」という発言も出ています。 弊社側のテストと基本設計の精査が無ければ、立ち上げることも出来ないシステムであったろうにそのような言い草ができたものです。 本番でトラブルが発生しても謝罪の一言もありません。 （これは契約上は損害責任を負う必要は無いとは思いますが、エンドユーザーに迷惑を掛けており、深夜まで復旧作業に付き合っているにも関わらずです） こんな態度は会社ぐるみの体質としか思えません。 このような会社も上場企業ながら存在するのです。 相変わらず不具合は多発しており、険悪いや緊張感のある関係でここ数ヶ月作業を続けております。 担当ＳＥは、エンドユーザーとの打ち合わせ会議には出席しますが、一言も発言がありません。要望に対する質問も、対応策のアドバイスさえも何もありません。 言われたことしかやらない、自分で責任を持たされるようなことはしない。 これが賢いＳＥの姿勢なのかもしれませんね。勉強になります。 それならそれでよいのですが、ＳＥの単価は払えませんよね。 提案が出来ないならせめて高級ＰＧとして高品質の納得できる成果物を期待します。 この会社の作るソースを誤りなくメンテナンスしてくれる会社がそうそう簡単に見つかるわけではないと思っています。今後は、おそらくこれまでの開発の赤字を埋めるべく法外な見積りを出してくることも予想されます。 ドキュメントを全て出させた後、ＨＷメーカーの紹介を受けて、他の会社と保守契約を結ぶことも少し念頭に置いています。 このように途上で、委託先のソフトウェア会社を替えられた経験のある方はいらっしゃいますか？ | ||||||||
|
投稿日時: 2005-06-05 12:02
ご無沙汰しております。
委託先の変更についてはお答えできないのですが… 契約書の瑕疵保障期間などは、確認しておいた方がよいですね。 月末、半期末など、イベントもまだ残っていると思います。 _________________ はゆる Smile, Smiles make me happy. | ||||||||
|
投稿日時: 2005-06-06 17:22
ついに稼動しましたか。お疲れ様です。 ・・・といってもまだまだこれからのようですね。がんばってください。
※私は開発会社のSEですので、それを念頭にお読みいただけると幸いです。 当事者でさえ苦労したコードを第三者が誤りなくメンテナンスすることは無理なので、 保守会社を変えるのであれば、多少のシステムトラブルは覚悟するしかないと思います。 しかし、この場合は開発会社に任せていてもトラブルが続出しそうなので、 あまり気にしなくても良いかもしれませんね。 私は自分が担当するPJにおいて、開発会社と保守会社を分けたことがあります。 その時は、以下のように対処しました。 ・仕様は本番稼動と共に凍結 ・稼働中のシステムで不具合が発生した場合には瑕疵の範囲で開発会社に直してもらう ただし、仕様に不具合がある場合は、瑕疵の範囲ではないので諦める ・保守会社には凍結した仕様を理解してもらう ・仕様がある程度理解できた時点(規模に対する要員の比率にもよりますが、 2ヶ月ぐらいでしょうか)で開発会社とはオサラバし、保守会社に保守してもらう ・保守会社とは時間いくらで契約し、不具合の改修をしていないときには リファクタリングとそれに合わせたドキュメント整備をしてもらう ・リファクタリング中に気づいた仕様誤りやドキュメント不備を報告してもらい、 それらの対処は別途検討(追加費用を払うかどうかの検討です)する。 ※この「別途検討」がないと保守会社はそれなりのリスクを見積らなければ 割に合わないので、見積がけっこう高額になると思います。 振り返ってみると、私が担当したPJでは、 ・本番稼動後2ヶ月は顧客から追加開発案件の開発が始まらなかった(要求定義に 時間がかかった)ので追加開発時には保守会社が立ち上がるのを待てた ・瑕疵の範囲外の不具合が発生しなかったので、 開発会社に追加開発費を支払う必要がなかった、 など、ある意味ラッキーだったとも言えますが、まあなんとかなりました。 ※付け加えておくと、追加開発案件のスケジュールはある程度見えていましたし、 コードの内容まで押さえていたので、例え顧客から改修の依頼があっても 保守会社の負担にならないようにこちらで方針を決めて改修の指示ができるだろう という見込みがありました。 なお、コードを全て書き直すと膨大な費用がかかるのでは？ と思われるかもしれませんが、設計や試験の仕様がかっちりと決まっていて それらがドキュメント化されているのであれば、 コードの書き換えや試験自体にはさほど時間はかからないものですよ。 | ||||||||
|
投稿日時: 2005-06-07 08:58
カットオーバーできて良かったですね。
個人的にはカットオーバー前に検収がもらえるなんて、「なんて優しい お客様なんでしょう。」と思っちゃいましたけど 
今後ですけど、バグ等のトラブルに関しては瑕疵担保期間であれば開発元 に責任を持って改修させれば良いのですが、契約をもう一度確認しておいた ほうがよいですよ。例えば、基幹系なら年次繰越処理というのがあると思い ますが、これ決算期にしか動かしませんよね？でも６月カットオーバーと すれば、検収はその前にしているのですから、瑕疵担保が半年だと来年３月 に何かあってもすべて有償改修になってしまいます。 それと、カットオーバー後データベース等のチューニングというのは無い のでしょうか？これは委託範囲外？ 他にもメンテナンス的なルーチンワーク等も．．． 保守を別会社に依頼する場合には、作業内容や範囲を明確にしておいた ほうが良いですよ。
規模によって変わりますよ。多い少ないは感覚的なものなので．．． 開発時の設計、プログラミング、テストを考えても、書き換え時設計は 新たにする必要が無くとも、業務レベルまで理解する期間が必要になり ます。（時間は開発時より少ないでしょうけど） プログラミングもソース解析後、コーディングになりますからそれなり に時間がかかります。そしてテストとなるとすべてのソースを書き換えたの であればテストケースは開発時と同じだけ流す必要がある（書き換え方 によってはケース数も変わりますが）のでほぼ同じだけかかります。 こう考えると、開発時（うまく行った場合）の半分かかるとしてそれが 多いか少ないかはまた別ですね。明らかに仕様追加とか、不具合があるという ようなことが無い限り、単に「不安」とか「汚いソース」というよ うなだけでリファクタリングするのはやめたほうが良いですよ。（お金と 期間が十分あるなら良いですが．．．） | ||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.