- ベストアンサー
開発設計（仕様）と使用年数の関係
社内ＳＥをしております。 社内の基幹システムの保守が主な業務です。 その基幹システムの運用が始まって５年目に入るのですがあちこちで不具合がおきております。 その中でもっとも納得がいかないのはデータ件数が増えた（運用により）ために 動かなくなった、というものです。 （具体的に言うとＳＱＬでビューを使いまくっていて、件数が増えたことにより ビューを作成する時点で応答がなくなってしまう） 開発したベンダーに報告しても、 「そんなに件数の多いパターンで納入時に試験できなかった（試験してない）」 「運用して５年もたって不具合を言われても困る（無償では対応できない）」 といった切り返しをされます。 これってどうなんですかね・・・？ いちいち設計のときに何万件のデータでも動くようにしてください、とか 言わないといけなかったんでしょうか。 データ量も他の業界に比べれば全然少ないほうで、むしろこの程度で 動かなくなるなんて不良品じゃないかーって言いたい気持ちがあるのですが・・。 仕様検討の段階で、大量の試験データを用意して納入試験をしなかった弊社、 そしてとりあえず今動けばいいや、という認識でプログラム作成したベンダー、 両社の責任・・・ってことになるのでしょうか・・。
- septem9
- お礼率87% (57/65)
- その他（ITシステム運用・管理）
- 回答数8
- ありがとう数13
- みんなの回答 （8）
- 専門家の回答
質問者が選んだベストアンサー
NO.2、NO.5です。 質問者様のご指摘どおり、近年の開発業務は非常に質が下がっているように思われます。過等競争の結果、値引き合戦になって、それこそ安かろう悪かろうの傾向が強いです。 NO.6の方が言われるようにオープン系のシステムは開発すれば済むものではなく、メンテも含めた運用コストが必要です。近年、この運用コストが経営を圧迫しているという話が多く、社内システム部門ではITILという運用インフラに注目しているようです。ITILの肯否はともかく、企業トップが運用のコストダウンと予防保守に力を入れる時代になってきています。質問者様が言われるように社内トップの方の意識改革がないと、現場が困ったことになります。システムを開発するより、維持運用して行くことに更にコストがかかることを認識しなければ現状は変わらないでしょうね。 開発を依頼するときに、その後のメンテや運用まで含めた設計をしてゆくことが、結局は総コストは安くなります。このことがなかなか理解できないんですね。 ベンダー選定は目先の開発費用の差額ではなく、長い目で見て評価すべきでしょう。業務パートナーくらいの意識で付き合うことも必要だと思います。 質問者様のところがベンダーと同等の開発スキルをお持ちであればきめ細かい要求ができて満足度も上がるんですが、企業体力がないと続けられませんし、そのためにSIerというものがいるわけですし。スキルが無いということが悪いと一概には言えないです。 ベンダー側の意見です。
その他の回答 (7)
- OsieteG00
- ベストアンサー率35% (777/2173)
普通はベンダが聞いてユーザが答えるべき性質ですよね。 ベンダとしてはユーザから要求のあった項目さえ満たしておけば(この場合は納期のみ)よいので、件数までは考慮しなかった可能性があります。気の効いたベンダなら聞き取りしていたでしょうがね。データの想定件数と成長率ぐらいは言っておいたほうがよかったかもしれません。 当初よりの要求仕様の変更ですから、追加費用の発生は仕方がないです。例の2000年問題ですら追加費用は発生していましたからね。 SEの仕事としては ・仕様の聞き取り ・実装のための提案(これはユーザサイドにはできない) →業務を再定義することで業務項目を整理することができる ・足りないチェック項目の網羅
お礼
コメントありがとうございます。 ２０００年問題・・・ありましたね。 ユーザーもベンダーも要件定義書を作る際に９９年までしか対応できないと 考えていた人はいたのでしょうか。 いたとしても問題が発覚する頃には自分は関係ないって考えていたので しょうかね。恐ろしいことです。 ITProのサイトでは、最近のユーザは目先の機能を言うだけ、ベンダーは安い 価格、早い納期で、手間のかかる基盤システムを作らず拡張性の低い 融通の利かないシステムを作ってしまう（正確には作らされる）傾向にある。 そしてユーザもベンダーも全体をマネジメントできずお互いの担当範囲を 勝手に決めた結果、その間にぽっかりと大きな溝ができてしまう、 と警鐘を鳴らしていました。 ユーザは結果だけを見て、あのベンダーは使えないと烙印を押してしまい またベンダーはあんな無茶な注文をしてくるユーザとは仕事をしたくない、と 両者間の溝も深まるばかりです。 これはユーザとベンダーの間をとりもつ社内システム管理者（つまり自分）の 能力が欠けている・・・という事実な気がしてまいりました。
- galluda
- ベストアンサー率35% (440/1242)
がるです。ちろりとコメントからいくつか。 > とりあえず納期に間に合えばよい・・という物差しだけで進んでいたかと思われます。 割合に散見されるパターンですねぇ。ただ、値段が値段だと思われるので、やはり危険だと思います。 > しかし要件定義とはどこまですればいいのでしょうか・・・。 > たとえば４年に１回のうるう年。あれを考慮してくださいといちいち > 書かないといけないのでしょうか。 要件定義は、書くものではなく書かせるものです(笑 で。うるう年程度は「普通に処理すべきもの」ではあるのですが。相手のレベル次第では突っ込みどころですねぇ。 厳密には ・400で割り切れたらうるう年 ・100で割り切れたらうるう年「ではない」 ・４で割り切れたらうるう年 ・上述以外ならうるう年ではない という感じの判定が必要なので。 > 年をまたいだ時に、月の桁が2桁から1桁（2005/12 ⇒ 2006/1 ) になったために異常終了したことがありました。 これは…論外です(苦笑 > やはりシステム開発も「安かろう悪かろう」の世界なのかなと思ってしまいます。 必ずしもそうとは限らないのですが、やはり安いなりの理由がある可能性が。もっとも「高いからといってよいとは限らない」ってのもまたYesで、それはそれで困り者なのですが。 ちなみに。業務システムってのは「保守してメンテして改善して成長していく」ものです。 納品しっぱなしのところは、場合によってはちょっと危険かもしれません。
お礼
再度のコメントありがとうございます。 最後のコメント「保守してメンテして改善して成長していくもの」 これを発注側のシステム管理者、そしてトップの人たちも理解することが 大事ですね。 ・一度作ったものにお金をかけたくない ・高い金を使ってシステム化したのになんでまた金がかかるのか ・結局そうやってシステムに精通してないものをカモにしているのではないか システムに関心のない上層部の人たちは概ねコストが発生するだけの システムに上記のような不安を抱いております。 そこをそうではないことを説明していくことが管理者の努めでもあるわけですね。
- w210
- ベストアンサー率38% (92/238)
NO.2です。回答の補足です。 要件定義書に書いてあることを提供することがベンダーの責任範疇です。書いてあればバンダー側の責任、書いてなければ責任の追求は難しい、ということです。 瑕疵は定義している要件を満たしていないことを意味します。なので、要件定義書がすべてです。ここに書かなければ、開発時に考慮しないし、テストもしません。 こういう解釈になりますが、先の回答者さんの言うように処理件数も聞かずに作るベンダーも問題があります。システム改修または再構築を行うこととして、その費用を値引くという交渉が現実的ではないか、と思います。
お礼
コメントありがとうございます。 要件定義が最重要なのですね。 要件定義というものはユーザとベンダーどちらが作成するものなのでしょうか？
- mii-japan
- ベストアンサー率30% (874/2820)
データ件数は、ユーザ側の指定事項です 両者の責任では有りません、発注側の責任です 5年近く使用できていたのですから、質問者の要求は無理です
お礼
コメントありがとうございます。 そうなるとユーザがシステムに強くない人の場合大変なことになりそうですね。 ユーザがこういうものを作りたい、という希望をひとつひとつ 具体的に落とし込んでいくことがベンダーの仕事だと思うのですが、そこも ユーザがやれってなると、ＳＥはいらなくなってしまうと思います。 データベースの中をのぞいた事もない人に、処理件数を意識して発注すべきと いうのはなかなか厳しいです。
- jikankou
- ベストアンサー率38% (42/108)
データ量が多い少ないは別にして、概算でどの程度 になるかは知らせるべきではなかったのではないで しょうか？（聞かないベンダー側にもプロ意識が足りないと思いますが） データ量というのはソフトウェアを設計・構築する上で重要かと思います。全てのものには限界というものがあるのですから・・・ プロ意識のないベンダーには問題はありますが、無償では受けられないというのは当然でしょう。 最近の事例で言えば東証のシステムです。データー量が許容する範 囲を超えているために取引時間を短縮するという醜態を世界に晒さ してくれましたが、仕様を決定する際にデータ量を概算せず、年々 急増してきた個人投資家の取引量が急増しているにもかかわらず自 体を放置していた東証の責任は重いか個人的には思います。 結論から言えば、私の個人的な意見としては、システムを構築しなおすのに無償で対応できないというのはベンダーの言い分の方が正しいのではないでしょうか？後、テストデーターについてはサンプルさえあれば、量を用意するのは別に難しいことではないことです。（実際のデーターでなくてもかまわないのですから）。後は仕様書にはだいたいの上限のデータ件数について書いてあったかどうかかと思います。書いてあってその用件を満たしていなければ、向こう側は分がわるいでしょうし、書いていなければそちら側の提示しなかったということが問題なのではないでしょうか？データーの件数によって設計も大分かわってくることもあるでしょうから・・・
お礼
コメントありがとうございます。 東証の件もそうですね。問題が起きるまで先送りにし続けた結果があれでしょうか。 弊社の問題も件数が増えて問題が起きた、、、というだけで根本的な原因は 件数が増えたことなのか、それともビューの使い方が悪いのかわかりません。 またその切り分けさえも対応してくれそうにありません。 関係は冷え込むばかりです。 自動車にも定期的に車検をおこなって部品交換などでコストがかかるように システムにも定期的に不具合などを報告し、適度な金額で改修作業をして もらえるような関係を両社間で築くことが大事なのかもしれないですね。
- w210
- ベストアンサー率38% (92/238)
請負開発で発注したと仮定します。 瑕疵担保期間は通常６ヶ月です。（契約書に期間が書かれていればそちらが有効です。）納入後６ヶ月かというと一概には言えません。瑕疵を発見してから６ヶ月ということですので。 ご質問の内容から、大量データ処理時の不具合というのは実に微妙です。瑕疵かどうか？という疑問があります。要件定義書に処理可能件数が書かれていれば問題はありません。書かれていないのなら、しかも５年も経過しているなら、システムの運用限界だというベンダーの主張に分がありそうです。 双方で確認する内容に不備があったことを考えれば、システムを見直すことにして、新システムの開発費の値引きなどで譲歩してもらえる余地はありそうです。運用の限界を感じておられるなら、見直しをする良い機会ではないかと思います。このまま運用を続けると開発コストを上回ってしまい、どんどん勤務時間が長くなると思います。せっかくのシステムも手かせ足かせになってしまいます。
お礼
コメントありがとうございます。 要件定義書を明確にしておかないと、話し合いにならないのですね。 しかし要件定義とはどこまですればいいのでしょうか・・・。 たとえば４年に１回のうるう年。あれを考慮してくださいといちいち 書かないといけないのでしょうか。 現にうるう年ではないのですが、年をまたいだ時に、月の桁が2桁から1桁 （2005/12 ⇒ 2006/1 ) になったために異常終了したことがありました。 2桁の場合しか考慮してなかったようです。こんなことまで自分のパソコンの 時計をすすめて納入時に試験しないといけないのかと思うと、あまりに ユーザ側が不利な気がします。（さすがにこの時は無償で直してもらいましたが） たまたま依頼したベンダーが悪かったのか・・・。 コスト最優先で中小企業に依頼すると大体このような結果になります。 お金をかけて（かけざるをえない状況で）名の知れた大企業に依頼すると ほとんどこういったミスがありません。 会社の規模で判断するのはもちろんいいことではありませんが、 やはりシステム開発も「安かろう悪かろう」の世界なのかなと思ってしまいます。
- galluda
- ベストアンサー率35% (440/1242)
がると申します。 えっと………とりあえず。何のDB使ってるかはわからないのですが、DB設計で「レコード量は何件までを想定」ってのは必ず規定しなければならないものです。 よくこのあたりで「普通」とか「常識的な量」とかいう単語を使うケースがありますが、業種業界状況業績次第でいくらでも可変になります。 ですので「いちいち設計のときに何万件のデータでも動くようにしてください、とか言わないと」いけないものです。もちろんきちんと数値を決めて。 というのが基本ライン。 ただ…件数は「一桁の数万」ラインで動かなくなったんでしょうか？ だとすると…ちょっとあまりにも性能値が低いように思われます(…Accessでそーゆー話を見聞きしたことがあるような。アレは業務に使えるレベルのものじゃないのですが…)。 基本的には数十万の後半から百万単位。次は一千万単位、億単位、のレコードをあつかう場合に、それぞれ、DBMSの選択やらSQLのチューニングやらなにやらが発生してきます。 無償での対応が難しいってのはやむをえない部分だと思うので、せめて「じゃぁ何件まで対応できるように改修できるのか」って部分できちんと詰めるべきかと思われます。
お礼
コメントありがとうございます。 おそらくデータの件数についてはほとんど仕様検討の段階では 話にあがってなかったと思います。 とりあえず納期に間に合えばよい・・という物差しだけで 進んでいたかと思われます。 また問題が発生するまで、件数が増えたらどうなるか？ということに 誰一人考えてなかった・・・ 確認もせずにお金を払ってしまった弊社が悪いのですね。 今後の反省材料とします。
お礼
コメントありがとうございます。 返信が遅くなり申し訳ありません。 ＞質問者様のところがベンダーと同等の開発スキルをお持ちであればきめ細かい ＞要求ができて満足度も上がるんですが、企業体力がないと続けられませんし、 ＞そのためにSIerというものがいるわけですし。スキルが無いということが悪い ＞と一概には言えないです。 うちのトップは管理者（つまり自分）に、このような開発スキルを持っている ことを期待しているように思います。 ユーザーは希望だけを言う、ベンダーがそれを吸い上げる、その関係が 成り立てば管理者の必要性はない。 現状、管理者は社内のためにいるのではなく、ベンダーのために存在している ような感じです。 （乱暴な言い方をしてしまえば、ユーザー側にいる物分かりのいい奴、程度の存在） これはトップの考えもあるかと思いますが、自分自身の仕事のやり方にも 問題がありそうですね・・・。 いろいろと参考になる意見、ありがとうございました。