システム開発における問題点の分析とアドバイス
- システム開発における問題点の分析及びアドバイスをお願いします。
- 現在使用している販売管理業務システムの問題点とその解決策についてアドバイスをお願いします。
- 結合テスト工程でのバグ原因分析結果を踏まえ、不具合を是正する方法や問題の回避策についてアドバイスをお願いします。
- ベストアンサー
システム開発における
システム開発における 問題点の分析について、アドバイス頂きたい事があり 投稿させていただきました。 <経緯> 現在使用している販売管理業務システムを 現行の業務と乖離してきている為内容を修正することとなった。 販売管理システムは、X業務システム、Y業務システム、Z業務システム ３つのサブシステムで構成されていて それぞれの業務に精通したメンバーを割り当てる必要があった。 ところが、かつて現有システムの開発に携わった経験を持ち、 各業務に精通しているメンバはわずか３名であり、 一方Ｚ業務管理システムの構築に必要な特別なスキルを 身につけているのも、この３名だけであった。 結果として、Ａ課長はこの３名をＺ業務管理システムの開発に配置し、 Ｘ業務管理システム、Ｙ業務管理システムともに、業務には精通しているが 開発スキルは不十分なメンバと開発スキルは十分だが業務の理解は 不十分なメンバの混成チームを編成し、各チームにリーダを配置し、本プロジェクトを開始した。 結合テストが終盤に差しかかる頃、 バグが多発しテストの進捗に影響を与えている状況が露呈した。 結合テスト工程でのバグ原因分析 サブシステム名 設計バグ件数 製造バグ件数 総バグ発生件数 Ｘ業務 ５１ ８９ １４０ Ｙ業務 ２５ １３７ １６２ Ｚ業務 ２ ２１ ２３ 全体 ７５ ２５０ ３２５ 結合テスト工程でのバグ原因分析の結果によると、 Ｘ業務システム、Ｙ業務システムについて それぞれ問題点を認めることができますが Ｘ業務システム、Ｙ業務システムのリーダの立場として、 (1)表３の分析から、不具合を是正するためにどのようなことを行うか。 (2)プロジェクトの初期の段階でどのようなことをすれば根本的に ここで生じている問題を回避することができたと考えられるか。 上記２点に関して、アドバイスを頂けないでしょうか。 以上。 宜しくお願い申し上げます。
- eclipse508
- お礼率5% (15/257)
- SE・インフラ・Webエンジニア
- 回答数2
- ありがとう数5
- みんなの回答 （2）
- 専門家の回答
質問者が選んだベストアンサー
(1)に関しては、No.1さんの回答にある様に、Zシステムを 担当した3人のアドバイスをもらって、バグ潰しをするしか 無いと思います。 「結合テストが終盤に差しかかる頃」と言う事なので、残り のテストを継続して全てのバグの洗い出しをするか、中断して テストが終了していないソースを、他のテスト結果のエラーの 傾向から見直す、又は、単体テストからやり直すかは状況次第。 バグ潰しをするの際には、致命的なバグか、軽度のものかに切り 分け、優先順序をつけて作業を行いましょう。 また、どの程度の作業工数が掛かるかを見積もって置きましょう。 でないと、納期がきても客先に「プログラムはできていません。」 「いつ完成するかも判りません。」としか答える事ができなくなって しまいます。 (2) ちゃんとレビューをするというのも重要だと思いますが.... Zシステムに3人全てを投入して、開発のみに専念させたという点にも 問題は有った様に思います。 Zシステムに、業務の理解は不十分だが開発スキルの高いメンバを割り 当てて、業務に精通しているメンバの指示で作業をさせるという事は できなかったんでしょうか？ その3人でなければできない所以外の部分を、極力他のメンバに任し、 一歩引いた所から、X, Y, Zシステム全体を見て指示しながら作業をして いった方が良かったのでは？ 少なくとも、X, Yシステムの設計バグ件数は、もっと少なくできた様に 思います。 ＃3人の業務知識及び、特別なスキルを誰にも伝える事ができなかった ＃事で、この3人がいなくなれば、システムの事が解る人が、今渡こそ ＃誰もいなくなってしまう事になったのではと危惧しています....
その他の回答 (1)
- F2-A
- ベストアンサー率26% (62/232)
開発中の工程については何も書かれていないのでアドバイスになるか分かりませんが、 (1)に関してはとにかくＺ業務を担当した３人にアドバイスを貰ってバグをつぶせとしか言えません。 (2)に関しては基本設計書、詳細設計書を作成した時点でこの案件に関わった人物すべてでレビューをしなかったんでしょうか？ どうみてもＸ、Ｙ業務を担当した方が理解していないまま結合テストまで進んでしまったように思えます。 おそらくＸ、Ｙ業務のレビュー時にＺ業務を担当した３人に確認してさえいればこんなことにはならなかったのではないかと考えられます。 がんばって何とか終わらせてください。 以上。
関連するQ&A
- システム開発について
この業界に入ってまだ、半年足らずの初心者です。 半年の間、画面遷移のテストくらいしか経験したことがないのですが、この度、急にシステム開発の設計のメンバーに入りました。 開発の手法等、全く分からず、UMLなど独学しているのですが、方法論が分からなくて戸惑っています。 どのようなもので学習すれば、効率良く習得できるのでしょうか？ 近道はないのだろうと思いながら、経験以外でいち早くスキルを身につけたいと考えています。 返答お願いします。
- ベストアンサー
- その他([技術者向] コンピューター)
- 業務システムを新規開発、またはASPを利用したい
パソコンのハードウェア修理業をしております。 今のところ、顧客管理はExcelで行っているのですが、件数が 多くなり、関数を多用しているため、かなり動作が重くなっており、 DB化を考えています。 顧客からの相談メールの返信や、修理結果の報告なども、 送信件数が多いため、WEBベースの業務システムを組んで、 管理画面からいくつかのメールテンプレートを選択、 テキストエリアに読み込みして、内容をちょこっと編集して、 送信ボタンで簡単に送信できるようにしたいと思っています。 こういった業務システムを実現したいのですが、こういう仕様は システム開発会社に、新規に作ってもらわないと実現できません でしょうか？ サイボウズの「デヂエ 8 for ASP」など、カスタマイズ可能と書いて いるのですが、使用経験がないため、どこまでカスタマイズできるのか わかりません。 もしこういったシステムを実現できる、良い業務システムのASP などありましたら、教えていただけますと助かります。 個人的には、一からの開発をお願いした方が良いかと思っていますが、 何かアドバイス等もございましたら、ご意見を伺いたいです。
- 締切済み
- その他([技術者向] コンピューター)
- システム開発に関する質問をさせて頂きます。
システム開発に関する質問をさせて頂きます。 テスト項目件数不足、ユーザー機能要件の変更などが 進捗会議に報告されないという問題点があった場合、 このような問題点を事前に顕在化させるために、プロジェクトとして 事前に制定し、尊守を義務づけておくべきである 管理、運営上の手続きにはどのようなものがありますでしょうか？
- ベストアンサー
- SE・インフラ・Webエンジニア
- システム開発からの職種変更について
現在、SIERでシステム開発をしている40歳男です。職位は課長代理 ＝係長（管理職ではない）です。うちの会社では管理職になってい ないと遅い年齢です。しかしながら最近のシステム開発の早さにつ いていけず、年齢とともに体力・精神ともつらくなってます。ずっ とシステム開発で業務の設計、試験、移行などを繰り返して来まし たが最近は情熱が沸きません（やる気がわかない）。 他社へ移るほどスキルもないので、社内で職種を変更してなんとか 定年まで勤めたいと考えています。・・総務、人事、経理、他？ 実際に職種変更などをした方はいらっしゃいますでしょうか？ 経験話、アドバイス等をいただきたいと思います。
- 締切済み
- その他（ビジネス・キャリア）
- 派遣先でシステム開発を行っています。
今6月末出荷に向けての開発が進んでいるのですが、気になることがあります。 すでにバージョン1.0が出荷されていて、今は次のバージョンを開発している最中です。 システムは複数のアプリケーションで成り立っているのですが、そのうちの１つが品質が良くありません。 そのアプリケーションのバグの多さは、バージョン1.0開発段階から何度となく議題に挙がっていました。 私は、あまりにも品質が悪いということで、バグが発覚してからその都度対応するというやり方ではなく、コードレビューを行うなど、もっと根本的な対策が必要ではないかと提案しましたが、度重なる仕様変更もあって時間が足りないという理由で、その案は却下され、派遣先企業のプロジェクト管理者さんも厳しい態度で臨むこともありませんでした。 ただ、バージョン1.0の開発も終わり、時間的にも余裕ができたので、次の開発からは、設計レビュー、コードレビュー、単体テスト仕様書レビュー、単体テストの強化などを取り入れて、バージョン1.0と同じことを繰り返さないようにしましょうということで話がまとまりました。 次のバージョン開発が始まって1ヶ月以上経ち、ちらほらバグも出てきていますが、その内容がデグレードだったり、レビューや単体テストをしっかりしていれば流出を防げるようなものばかりなのです。 こういった状況を見る限り、開発前の約束が守られていないように思えて仕方ないんです。 問題のアプリケーションの開発担当の人は、レビュー実施や単体テスト強化に消極的です。 品質の悪さについての対策ミーティングのときも、言い訳が多く、自分はそんなに悪くないといったような態度に見えます。 品質が悪くて困るのは派遣先の企業さんなので、放っておけばいいことなのかもしれませんが、 ほかの人は遅くまで残ってがんばっているのに、当の本人は時間がないと言っておきながら定時退社。 そんな場面を見ると腹が立つんです。 また、プロジェクト管理者もあきらめているのか、バグを減らするための努力をしているか確認しようとしません。 問題の人も派遣で働いています。フリーランスではなく派遣会社の人です。 これまで何度か対策をしようと提案してきましたが、まだ議題に取り上げるべきなんでしょうか？ それとも、放っておいたほうがいいんでしょうか？ ちなみに、品質の悪さについて積極的に発言するのは私くらいしかいません。
- ベストアンサー
- SE・インフラ・Webエンジニア
- システム開発後のシステムチェックとは
短期のアルバイトを探しているのですが 期間、勤務地、時給等の条件にピッタリの求人があったのですが、その仕事内容がイマイチわかりません。 ■内容 システム開発後のシステムチェックのお仕事 テスト仕様書、試験項目にそって、動作確認、チェックをお願いします。 ■資格 システムテスト作業経験のある方歓迎 ゲームのデバッグみたいなものですか？ 何か専門的な知識、スキルがないとできないような仕事なんでしょうか？
- 締切済み
- アルバイト・パート
- システム連絡表とは？
システム開発は、下記のように流れると聞いたことがあるのですが、 「システム連絡表」とは、何を意味するのでしょうか？ 概要設計書 要件定義書 データベース定義書 基本設計書 基本仕様書 詳細設計書 詳細仕様書 単体テスト仕様書 単体テスト報告書 結合テスト仕様書 結合テスト報告書 総合テスト仕様書 総合テスト報告書 バグ報告書 プロジェクト会議議事録 チーム打ち合わせ議事録 システム連絡表 開発スケジュール予定 開発スケジュール実績 テストスケジュール予定 テストスケジュール実績 進捗報告書
- ベストアンサー
- その他（プログラミング・開発）
- 自社開発システムについての悩み
はじめまして。 70名ほどの小企業にて社内SEをしているものです。 システム担当者は私一人しかいない職場です。 主な仕事内容は、 ・社内のPCメンテナンス、設定保守 ・ヘルプデスク ・既存システムの管理(トラブル時の業者との連絡対応が中心) ・プログラム開発（簡単なツール作成など） ・サーバーの設定管理（メールサーバやDNSサーバはISPに委託） といったものなのですが、 1年ほど前から新たな自社システムの開発を任されています。 会社の基幹業務を行うシステムとなるもので、20名以上の事務職員が常時使用するレベルのものです。(不具合が起こると会社業務に大きな影響を及ぼす) 元々社内SEとして入社したため会社の実業務について知識が無かったことや、 これまでPGの経験があり簡単なツールを何本か作っていたので開発を引き受けた当初は安易な気持ちで考えていました。（作業依頼者が社長なので、曖昧な返答はできなかったということもあります。） しかし、開発を進めていくうちに業務の深さやシステムの規模が相当以上に大きくなることが分かり、自分の技術力ではこのまま運用に向けて進めていけるのか不安になってきました。 何とか実運用にこぎつけても日々のバグ対応や適宜修正依頼が頻繁に発生することは目に見えており、そうなると開発以外の仕事に取り掛かる時間がなくなることも予想されます。 （実際、開発を開始してから１年の間は開発につきっきりの状態で、そのほかの業務が全て後回しになっている状態です） さらに、私が不在時の緊急発生時の不安もあります。 また、感情論になってしまうのですが、 システムを実際に使用する部署のメンバーは我侭で理不尽な人ばかりで、自分達がまるで顧客であるかのような上から目線で物を言ってきて、会議のたびにストレスがたまり、精神的に疲れています。 依頼から１年が経過しそれなりに開発は進んでおり、システムそのものはそれほど高度な開発技術が無くても出来るものなので正直このまま実運用に持っていくことも可能ではあります。 しかし、会社業務の根幹を成すシステムであることを考えると、上で申し上げた諸々の事情もあり、不安で仕方がありません。（納期については、特に絶対期限は指示されていませんが・・・） 自分の見通しの甘さとSEとしての色々な面での能力不足は自覚しております。 そこで今の段階で社長に状況を報告して、 システムの一部を外注に依頼することを提案しようと思っています。 元々外注依頼した時の費用面(導入・保守料金)を理由に自社開発をすることになったのですが、システムの重大性と規模・メンテナンス効率から考えて自社開発(私一人の開発)では厳しく費用面でも結果として割高となってしまうことを伝え、システムの根幹に関わる部分は外注に依頼して、自社開発で対応できそうな部分のみ(出力系など)対応する、という案を提示してみようと思っています。 依頼から１年も経っていることや費用の問題があるため、提案が通るかどうかはかなり難しいです。 自分への評価が下がるのはもちろん、最悪クビになっても仕方ないとは思っています。 （ちなみにその社長はシステムの知識は全くない人なので、SEであればどんなシステムでも個人で作れると思っているようです。） 実は私自身、開発業務はあまり得意分野でなく元々PGメインの会社にいて限界を感じ転職した経緯もあるので、このまま提案が受け入れられなければ開発付けの日々になることが予想され、そうなれば転職も考えている覚悟はあります。 長々と書いてしまいましたが、 社内SEもしくはシステム担当者の方で同じような経験をされた方などおられましたら、 今後の対応方法・身の振り方・提案する際のコツなど何でも良いのでアドバイスいただけるとうれしく思います。
- ベストアンサー
- SE・インフラ・Webエンジニア
- システムを一から開発
うちの会社では参考ソースコードもドキュメントも一切なく、システム開発を一人に完全にお任せしています。確か業務系の小型システムではありますが、打合せから帳票・サーバ構築、開発テスト・保守全部一人でやっています。 死ぬより苦労したんだろうと、みんな自分の技術を死守するため、何重にもパスワードかけいます。問題なのは新人が入ると誰も教えないのです、で新人は自分で教科書を読みながら、システムを作成しますが、JAVAの人もいれば、VBの人もいます、エクセルの関数でなんとかしのぐ人もいます。社内は混乱極まりないのです。 普通の会社でもこんな感じなんですか。どう改善すべきですか?
- ベストアンサー
- SE・インフラ・Webエンジニア
- Webシステム開発における 要求分析 ヒヤリング ～ システムデザインについて教えてください。
Webシステム開発における要求分析の工程より ヒヤリング ～ システムデザインについて教えてください。 1.ヒヤリング ヒヤリングとはどのような視点で客さんから何を得ることが大切なのでしょうか？ 例えばポイントとしては 「お客さんがこで悩んでいるのか？ どこで困っているのか？」 「どういう機能を実現したいのか？」 という点を「文書として記載」 → 「分析」という流れで、 「聞き」 → 「お客さんが求めているサービス（理想）」を書き落としていくことが重要でしょうか？ 2.業務分析 業務分析はヒヤリングした内容を基に「業務のはじまり（開始）と終わり（終了）」の流れを業務フロー図に起す作業のことを言うのでしょうか？ 3.システムデザイン システムデザインは、業務分析が終了した後に、業務フローを基にデザイナーが各ページを紙芝居風（ＨＴＭＬ）を作成することを言うのでしょうか？ 頭の中のイメージとしては上記の通りなのですが、実体験がないため、想像の域を出ておりません。 実際に各々の工程では具体的には何をポイントとして、どのような作業を行うものなのでしょうか？ 経験者の方がおられましたら教えてください。
- ベストアンサー
- その他([技術者向] コンピューター)
