Webシステム開発の要求分析~システムデザインとは?

このQ&Aのポイント
  • Webシステム開発における要求分析の工程からヒヤリング~システムデザインまでの流れとポイントについて教えてください。
  • 要求分析では、お客さんの困りごとや実現したい機能を聞き出し、分析して文書化することが重要です。
  • 業務分析では、ヒヤリングした内容を基に業務フロー図を作成することで業務の流れを明確にします。
回答を見る
  • ベストアンサー

Webシステム開発における 要求分析 ヒヤリング ~ システムデザインについて教えてください。

Webシステム開発における要求分析の工程より ヒヤリング ~ システムデザインについて教えてください。 1.ヒヤリング ヒヤリングとはどのような視点で客さんから何を得ることが大切なのでしょうか? 例えばポイントとしては 「お客さんがこで悩んでいるのか? どこで困っているのか?」 「どういう機能を実現したいのか?」 という点を「文書として記載」 → 「分析」という流れで、 「聞き」 → 「お客さんが求めているサービス(理想)」を書き落としていくことが重要でしょうか? 2.業務分析 業務分析はヒヤリングした内容を基に「業務のはじまり(開始)と終わり(終了)」の流れを業務フロー図に起す作業のことを言うのでしょうか? 3.システムデザイン システムデザインは、業務分析が終了した後に、業務フローを基にデザイナーが各ページを紙芝居風(HTML)を作成することを言うのでしょうか? 頭の中のイメージとしては上記の通りなのですが、実体験がないため、想像の域を出ておりません。 実際に各々の工程では具体的には何をポイントとして、どのような作業を行うものなのでしょうか? 経験者の方がおられましたら教えてください。

質問者が選んだベストアンサー

  • ベストアンサー
  • tmkpp
  • ベストアンサー率58% (37/63)
回答No.1

私の会社での話となりますが・・・ 1 ヒアリング お客さん自身が本当に必要となる要望をつかみきれていない場合が多いので、 本当に求めている物は何か、をつかむようにしてます。 例えば、「インターネットで商品を売りたい!」という要望があった場合、 なぜそういった要望が上がったのか、売上を上げたいのか、コスト削減が目的なのか等々を 探ったりします。 あわせて、インターネットで商品を売りたいのが本当にベストプラクティスなのかも 検討します。 そうやって検討し、お客さんが頭の中で考えている本当の要望をつかむようにしてます。 ちなみにGuno-thisさんが記述されたようなことも、手法の一つとして実施したりします。 他には、ブレストで行う場合もあります。 2 業務分析 現在の業務の分析、及びヒアリングの結果、お客さんが実現したい新業務の 分析を行う工程です。 フロー図は、業務表現の1つの手法となります。 例えば、ECサイトを作りたいといった要望があった場合に 現在の業務フローが  営業マンが電話連絡を受ける  →担当者が電話で応答。伝票を記入  →伝票を社内便で倉庫に送る。  →倉庫にて商品を出荷 という業務フローに対し  ウェブサイトに買物カゴを設置。購入データをサーバに送信  →サーバでデータを受信。倉庫にて伝票を印刷  →倉庫にて商品を出荷 といったように新業務フローを作ったりします (かなり適当な例で申し訳ない・・・) 3 システムデザイン おそらく方式設計のことだと思うのですが・・・ 新業務フローをシステムで実現するために必要となるサーバや ネットワークと言ったリソースの配置を考える工程です。 先の例を実現するためにはサーバは何台必要か、バックアップはどうするかといった システムに必要な方式をデザインしたりします。 Guno-thisさんがおっしゃる紙芝居風のHTMLを作成するのは、 基本設計の外部設計と呼ばれる工程で実施します。 システムの方式が決まった後に実施する工程なので、 もっと後工程で実施となります。 ちなみに、ウォーターフォール開発モデルで使用される 用語は会社によってかなりまちまちなので、上記は とある会社の一例と思ってください。

Guno-this
質問者

お礼

お返事が遅れて申し訳ありませんでした。 ありがとうございます。 tmkppさんの説明とても分り易かったです。 何分、頭の中のイメージで経験がしたことがないものだったので とてもためになりました。 システムデザインは内容を勘違いしていたようで助かりました。 重ねて御礼を申し上げます。

関連するQ&A

  • システム開発における

    システム開発における 問題点の分析について、アドバイス頂きたい事があり 投稿させていただきました。 <経緯> 現在使用している販売管理業務システムを 現行の業務と乖離してきている為内容を修正することとなった。 販売管理システムは、X業務システム、Y業務システム、Z業務システム 3つのサブシステムで構成されていて それぞれの業務に精通したメンバーを割り当てる必要があった。 ところが、かつて現有システムの開発に携わった経験を持ち、 各業務に精通しているメンバはわずか3名であり、 一方Z業務管理システムの構築に必要な特別なスキルを 身につけているのも、この3名だけであった。 結果として、A課長はこの3名をZ業務管理システムの開発に配置し、 X業務管理システム、Y業務管理システムともに、業務には精通しているが 開発スキルは不十分なメンバと開発スキルは十分だが業務の理解は 不十分なメンバの混成チームを編成し、各チームにリーダを配置し、本プロジェクトを開始した。 結合テストが終盤に差しかかる頃、 バグが多発しテストの進捗に影響を与えている状況が露呈した。 結合テスト工程でのバグ原因分析 サブシステム名 設計バグ件数 製造バグ件数 総バグ発生件数 X業務     51     89     140 Y業務     25     137    162 Z業務     2      21     23 全体      75     250    325 結合テスト工程でのバグ原因分析の結果によると、 X業務システム、Y業務システムについて それぞれ問題点を認めることができますが X業務システム、Y業務システムのリーダの立場として、 (1)表3の分析から、不具合を是正するためにどのようなことを行うか。 (2)プロジェクトの初期の段階でどのようなことをすれば根本的に  ここで生じている問題を回避することができたと考えられるか。 上記2点に関して、アドバイスを頂けないでしょうか。 以上。 宜しくお願い申し上げます。

  • 基幹システムの開発方法について教えてください

    システム開発について分からないので教えてください。 今、会社の基幹システムを作り直すという事で、外注業者に依頼をしています。 通常、現行のシステムを理解し、業務を理解し、足りない機能を聞き取りし、追加してくれるのが普通かと思っていましたが、使っている大切な機能が抜けていたり、表示項目が足りなかったりと、今の業務を満たせない内容になっています。外注業者に聞くと、「現行システムは見ていない」とのこと。しかしながらRFPには、現行システムの機能を有す、と記載されています。現行システムの問題点についてはヒアリングは行われたようで、一部表示項目が増えたりはしているようです。 機能の不足等指摘をすると「仕様変更」「仕様追加」と言われ、他の機能を減らすと言われてしまいます。 仕様書もなく、SEが色々な人に直接聞き取りをしているため、何が要件として伝わっているのか分からない状況です。フィードバックもありません。 今後、どのように進めたら良いのか分かりません。どなたか、本来システム開発はどのように進めるのか、今の状況だと今後どのように進めたら良いか教えて頂けませんでしょうか。 社内に常駐しての作業なので、現行システムも問題なく見れますし、聞く人も周囲に多くいます。 変な質問で申し訳ありませんが、どうかよろしくお願いします。

  • システム開発の納品物(ドキュメント)の扱いについて

    システム開発(請負)での納品物(ドキュメント)とは、 A:作業工程内で作成されるものをいうのか、 B:別途金額が発生する制作物なのか、 どのように考えるのが普通なのか、教えてください。 (経緯) Webサイトのシステム開発のリニューアルを行うことになり、 以前開発を依頼した会社に見積りをあげてもらいました。 ※私が会社に就職する前に依頼経験がある会社で、私自身は初の対応の会社です。 PG単価4万円、作業工数:64人日(2人月)、260万の見積りで、 納品物としてはソースコード一式のみ。 それ以外の設計書や定義書などドキュメントは一切なし。 ソースコードのみでは、自社での検収作業が大変なので、 「検収作業を自社で行うためにもせめて設計書をつけて欲しい」と話をしたら、 新しい見積りで、設計の工数が倍になって、320万となっていました。 設計書だけで、40万も違うものかと驚きました。 こちらとしては最初の見積りで「設計」「製造」「テスト」の工程が提示されていたため、 その際に作るであろう設計書をもらえればと考えていましたが、 プロトタイピング開発であるため、設計書に関してはリリース後に 最終的なシステムをもとに書き起こして提出するという流れになるといわれました。 検収で必要としていると伝えたにも関わらず、リリース後に渡すというのも、 よくわからない説明で困りました…。 通常、設計書などは途中工程で作成されるだろうと考えていましたが、 そうではないのでしょうか。 価格を吊り上げるためのやり方に思えて仕方ありません。 これについて、ご意見お願いします。

  • Webシステムの設計で

    あるWebシステムの開発プロジェクトの仕事をやっています。 現在基本設計の段階です。 この仕事は、あるメーカー系の企業から請け負った仕事なんですが、 基本設計工程はその企業がメインで行い、うちの会社は支援として携わることになっています。 詳細設計以降の工程は、うちの会社が全て行います。 基本設計で画面設計をやっているのですが、要員不足、スケジュールの遅れということもあり、 うちの会社がやることになりました。 個人的な考えではありますが、本来はメインとなる請負元企業が行うべきではないかと思っています。 うちがやっているのはたたき台の作成で、最終的にはその企業とレビューの結果が最終形になります。 今までいくつかレビューをやっているのですが、その企業とうちの会社との考えが異なることがよくありました。 そのときに、「業務をわかっていない」とか「設計のスキルが足りない」などと言われたのですが、 私にはそうは思えなくて、ユーザインタフェースなど画面の見せ方に関する考え方の違いが出ているだけだと思うんです。 結局その企業の言う通りにするんですが、それならその企業から「こういう感じで作って」と指示があってもいいと思うんですが、それもありません。 作業のロスをなくすために、できるだけ設計のやり直しは避けたいのですが、その企業に対して、こういう主張をしても大丈夫でしょうか?

  • 業務分析手法について(最近の傾向)

    DFD(Data flow diagram)が昔は業務の流れを分析する上での主流だったように思います。昨今の状況はどうなのでしょうかお教え下さい。 宜しくお願い致します。

  • 方式(技術)よりのSEの仕事内容について

    私はプログラマになりたてのものなのですが方式(技術)系のSEの仕事内容に ついて質問があります。 方式系のSEはお客さんのところへ行ってどんなシステムが作りたい等の要望を ヒアリングする機会は少ないのでしょうか。 設計書等は業務系のSEがお客さんからヒアリングしてきたものを元に設計を進めていくのでしょうか。 業務系SE、方式系SEはどのような役割分担でシステムを構築していくのでしょうか。 また方式系SEは簿記等の業務知識は必要ないのでしょうか

  • システム開発の現状を教えてください。

    表題の通りですが、皆さんの会社でのシステム開発について教えてください。 個人的なご意見でもかまいません。 私の会社は、一応、大手です。 (1)会社の基幹システムを含めシステムを開発する専門の部署があります。 (2)それぞれの部署にも、それなり詳しい人を集めた部署がありセキュリティなど含めて   自部署専用のシステムを作成したりもしています。 (3)それぞれの現場にもエクセルなどに詳しい人がいてそれなりに頑張っています。 上記は、10年ほど前の話です。 (1)は、DOSの時代に発足して、規模はどんどん大きくなりました。 過去のシステムのメンテナンスなどを含めても、開発以外の保守の仕事が殆ど状態です。 開発は、社外に依頼するケースが多いです。 (2)については、部署で温度差がありますが、開発は(1)に依頼するケースが増え 自部署の負担を少なくする傾向があります。 部署によっては、プログラム言語も知らない年配と女子社員で上部から通達の管理しか 行っていない部署もあります。 (3)に至っても同様で、パソコンが一人1台になった時代(10年以上前)は、皆がエクセルや アクセスを一生懸命勉強して、VBAなども独学で勉強したメンバーいたものですが。 今の若手社員は、メールと既に準備されたエクセルシートに入力する作業でストップ 結局、現場のシステム開発レベルが下がった(無くなったも同然) 会社では、パソコンは完全に一人1台、Office Proインストールが標準、ファイルサーバー等も 充実しています。 世の中の流れは、IT開発が身近になり、誰もがIT開発出来たり、要望が増える方向にあると 思っていましたが どうも、当社は、組織が大人になったとでも云うのでしょうか、逆に流れになっています。 最近の事例ですが、取引先から入手したCSVデータを基幹システムに取り込むための エクセルファイルに変換するシステムを(1)の部署に依頼していました。 依頼元の担当者に、エクセルのVBA使えば、簡単に出来ると説明しておきました。 (1)の見積もりは、依頼内容通りVB当たりで取り込みとファイル作成のボタンだけでした。 たぶん、社外に依頼していると思います。 こんなやり取りして見積もりとって稟議起案して、お金を社外に払っている間に、現場で可能な 内容である事に上司も含め気が付かずに事務的に仕事が回っています。 (1)では、評価が上がるので、それで満足しているのではないかと思います。 決して、このような状況が会社の経営方針ではないのですが、 経営管理の隙間で、パソコンを使った改善業務が衰退しているのを危惧しています。 ほかの会社、或いは、システム開発の方のご意見をお聞かせください。

  • ITコンサルの仕事内容と40代からのチェンジ可能?

     何社かのSierを経て社内SEに転職した者です。  最近、システムの件でITコンサルなる方と仕事をさせて頂きましたが、感想としては単なるヒアリングをしただけじゃないかと落胆しております。  コンサルとしてのイメージですが、業務分析と業務改善の請負と思ってます。ITコンサルとなれば、今のシステムの欠点・長所の分析に加え、業務と則しているのかの検討を経て、理想的なシステムの提案をして下さる方というイメージがあります。  ですが、ITコンサルの中には、自社の製品売り込みのために、その製品にあてがった分析をされる方もおり、それだとSEか営業の方でも出来る範囲の仕事でもあると感じた方もいらっしゃいました。  ITコンサルとはどういう仕事をされている方なのでしょうか?。詳細を知りたいです。  また、40代からでもITコンサルは可能でしょうか?。    ちなみにですが、当方請負SEとしてやってきておりましたが、当時は、元々は業務系で無かったがために知識不足で苦労はあり、知らない箇所は、ユーザ側の方や先輩や上司から教わったり、一部お任せしたりという形でやってきました。あまり大きなシステムではなかったのでやれてこれたようです。  ただ、どこの会社さんでも現状システムが追加や変更があり、当時の担当者やベンダもおらず不透明となっているとか、今の業務に合わないので仕様追加の依頼という事が多く、ある種部分的な改善な依頼オンリーでした。  その際、ユーザさんのご意見を元にヒアリングをし、現状のシステム状況の解析や、今でこそ目に見える化なんて言われてますが、10年前から仕様書作成は当然として、現状業務のフロー作成と共にどこを改善すれば効率化が行えるのかを一緒に検討したりもしてきました。操作マニュアルがなければ、作りもしました。  本来、これらの仕事はSEの領分だと思っていただけに、あれ?と感じております。勿論、そこまでしない会社もこれまであったことで、違和感を感じもしたこともありはしました。

  • お客さんの言いなり

    お客さんの言いなり とある開発チームに所属しています。 チームリーダが、お客さんとのヒアリングを実施するのですが、 お客さんの指摘や要求をそのまま、持ち帰ってきます。 その実施を指示されますが、 メンバーの作業計画も無視され、休日もやれなど 無茶ばかりです。 例えば、部分的に了解を貰って先行して進める、優先度を決めて 一部は後工程にする、などメンバーの作業を考えた調整って リーダーするものだと思うのですが・・。 ご意見をお願いします。

  • PM支援で入ったのですが...

    ある企業があるコンサル兼システム会社に4月から仕事を依頼しているのだが、全く進んでいないの支援してほしいとのことで、7月にPM支援の名目で契約を結びました。 実際に入ってみると、ほぼ何もしていない状況でした(直近のスケジュールすらない)。 そのコンサル兼システム会社は、現場へのヒアリングを始めますと言いながら、3か月以上未着手とのことでした。 コンサル兼システム会社へプロジェクトの開始時には体制図・マスタスケジュール・グランドデザインを作り、方針を決めてから現場へのヒアリングをやる旨伝えたら、「今回は状況が特殊なので、そんなやり方は今回しません」と言われてしまいました。 状況が特殊というのは、システム会社の上と当社に依頼した企業の上との間が近しく、またシステム会社の役員が立場的(企業内・企業間の政治的?)に上、ということのようでした。 その為、当社に依頼してきた企業の方もそうせざるを得ない...ということになってしまいました。 ということで、直近で行うのは現場へのヒアリング(このスケジュールもまだ出ていないのですが...)とし、それが全てお終わってからグランドデザインとマスタスケジュールを作りますということになりました。 それにより、私が契約期間(数か月)に実施するタスクは現場へのヒアリングのみということに... そして、マスタスケジュール、グランドデザイン等を作る前には契約が終了しているという状態になってしまいました。 結果、PM支援で実施するような業務がなくなり、私のタスクは現場ヒアリングの立会ということになりました。(現場業務も詳しくないので、発言するようなことはもないのですが...) お金は当初の金額でいただけるとのことですが、やることがないのでどうしようかと。 皆様ならどうしますか? ちなみに、梯子を外された状態になってしまい、大分肩身がせまいのですが...(まぁ、本音ではこっちの方が困ってるのですが)