要件をうまく伝えるための方法はありますか? - システム開発・導入 - 専門家プロファイル

専門家の皆様へ 専門家プロファイルでは、さまざまなジャンルの専門家を募集しています。
出展をご検討の方はお気軽にご請求ください。

注目のQ&AランキングRSS

対象:システム開発・導入

要件をうまく伝えるための方法はありますか?

法人・ビジネス システム開発・導入 2007/12/13 18:10

システム開発を依頼した際、ユーザー側がどういう使い方をしたいかという「要件」を、開発者の方にうまく伝えることができません。意図をずれなく正確に伝える方法があったら教えてください。

※この質問は、ユーザーの方から事前にいただいたものを、専門家プロファイル が編集して掲載しています。

All About ProFileさん

回答:5件

濱田 崇 専門家

濱田 崇
ITコンサルタント

- good

先ずは業務的な要件、次にシステム的な要件

2007/12/14 12:13 詳細リンク

システムの要件を決定するには

1.業務要件(システムを使って何をどうやりたいのか)
2.システム要件(どのようなシステムが欲しいのか)

の順で固める必用があります。

1.
まず発注前に業務要件を漏れなく洗出し書き出す事です。
これが無ければ方針が無いに等しく、システム要件はグラグラと
揺れ動くものになります。
体裁はどのようなものでも良く、とにかく
「第三者が理解できるよう」「細かく」「網羅的に」「具体的に」
を目指して下さい。

2.
次にシステム要件ですが大抵は発注先のSE(又はコンサルタント)から
ヒアリングを受け一緒に固めていくことになります。
可能であれば発注者側である程度纏めておくと以後の助けとなります。
この、2.では1.の内容が基盤となります。
具体的に作成するものは、ユーザの利用シーン、業務フロー、
画面・帳票イメージと部品の定義、データ項目の洗出し、
画面やサーバに必用な機能の定義 etc...です。


質問の「どうしたら要件をうまく伝えられるか」ですが
発注側にできる事は「 1.をしっかりやる」につきます。
発注側ではどうしようもないけれど重要な事は
「SEやコンサルの技量」です。
良い「SEやコンサル」に当たるかどうかは運任せという
のが現状です。私は第三者のコンサルタントを使う事を
オススメしています(その場合、業務要件とシステム要件を
合わせて協力してもらいましょう)。

発注者は、決してシステム的な知識を勉強する必要は無く、
業務要件の纏めと良いパートナー探し(開発会社や第三者コンサル)に
重点を置いて下さい。

http://labo.itsl.jp/

回答専門家

濱田 崇
濱田 崇
(神奈川県 / ITコンサルタント)
代表取締役
090-6002-4611
※お電話の際は「"プロファイル"を見た」とお伝え下さい。

そのシステムは必要か?見積りは適正か?第三者の立場から助言

「金をかけたのに使えない」これらはシステムを導入した企業からよく聞かれる言葉です。致命的な問題を回避し、高いパフォーマンスが得られるシステムを導入できる手法を書籍でも紹介しています。お陰様で高い評価とご満足を頂いております。

質問やお悩みは解決しましたか?解決していなければ...

※あなたの疑問に専門家が回答します。質問の投稿と閲覧は全て無料です。
井上 みやび子

井上 みやび子
Webエンジニア

- good

「目的」の軸をブラさない事が重要です

2008/04/14 12:26 詳細リンク

要件定義はシステム開発のキモですので、エンジニア側から見ても、ここでうまく要件を拾い出してシステム設計に落とし込めるかというのがいわば「腕の見せ所」です。

ただしシステム規模や開発手法、契約状態により、「誰が主体になって行うか?」という点まで含めて、すでに他の専門家からご意見が出ている通り、方法は色々です。

*常に目的を意識して

要件定義の流れとしては、

1.要件を伝える(書き出す)
2.システムの設計を考える(書き出す)
3.そのシステムで要件が満たせるか検討
4.必要なら修正(=1 に戻る)

を繰り返しますが、実のところ、3の細かい要件を確認時に、個々の機能がきちんと動くと「何だかこれでいいような気がする」という気がしてしまうものです。

設計をしたエンジニアの方は目的を汲み取ったつもりになっていますので、発注者の方は「このシステムで目的が達成できるか?」を、エンジニアに気後れする事なく、冷静に検討して下さい。

*シンプルな目的定義を

しかし、目的があまりにも複雑だったり多岐にわたっていると、担当者の方の判断も非常に難しく、負担になります。
プロジェクトを始める時に、誰でも自分の頭で理解できるシンプルで明確な目的を定め、それをプロジェクトメンバー全員で共有する事が大切です。

*問題は、それが重要かどうかの判断を

実際問題として、いくら伝えても多少の認識の食い違いは必ず残ります。

「思い通りでない」という点が、システムの目的からしてどの程度重要かによって、これも冷静にエンジニア(受注者)側と交渉して下さい。
あまり細かい事にこだわりすぎると、全体の進行がストップしてプロジェクトが頓挫してしまう可能性もあります。


基本的な作業で手抜きをしないこと。

2007/12/14 06:24 詳細リンク

開発するシステムや業務要件によって、細かい点で必要な要素は異なってくると思いますが、基本的な作業が意外に漏れているケースがあります。

**画面は全部つくってますか?

これは結構面倒です。でも重要です。本当の画面ではなくとも、画面設計がきちんと全てされているケースは意外なほど少ないです。PowerPoint上の絵でもかまいませんし、サンプル的な画面(モックアップ)でもかまいません。必ず全画面、全項目をもうらした資料・データを整備することです。

**各画面にひもづく機能をリストしてますか?

各画面資料ごとに、関連する機能を全て洗い出してリスト化する作業が次に重要です。表示項目、表示方法、入力項目、入力方法、アクション等全てです。画面資料と機能資料がそろうことで利用者の視点から見た利用要件がほぼ見えてくるかと思います。

**画面からは見えない部分のフローを整備してますか?

画面に関連する機能を割り出すと、必然的に画面のアクションには関係のない処理がでてきます。この処理の実行場所、方法を精査していきます。

------ずいぶん簡単に書いてしまいましたが、やろうとすると結構重い作業になるはずです。

システム開発の熟練者ばかりそろっているようなプロジェクトであれば、フローと機能一覧で漏れが無くなっていくのかもしれませんが、今時そんなプロジェクトはありません。ユーザーと一体となって同じ認識がもてる資料の工夫が常に必要かと思います。

そのための画面資料と画面に関連する機能資料の整備は重要です。


要件定義が依頼側という線引きを無くせたら・・・

2007/12/14 13:49 詳細リンク

使いやすいシステムが出来上がるためには、要件定義が最も重要で、それがすべてです。
では、要件定義は、だれがやるべき仕事なのか?

開発側も含めて行うべきです。
「要件定義がすべて」ということは、「依頼」とか「請負」とかではなく「共に作る」のです。
(もちろん契約書上、役割分担上、実際は「依頼」「請負」という言葉を使います)


***◇◇◇開発側を要件定義に参加させる際に◇◇◇
システムの対象となる仕事を、既に行っている場合と、これから行う予定である場合とがあります。
どちらの場合も、新たに開発しなければならない「必要」の原点に、開発側の人を触れさせることが、大切であると私は思います。
既に行っている仕事の場合、現在のツールへの「不満」、あるいは、将来生じる「不満」の予測が、これから行う仕事の場合、その「事業計画への思い」その強い理念が「必要」の原点です。それを開発者に話してください。


***◇◇◇開発側の人の見分け方◇◇◇
「開発側が思いを共有・共感できているか」または「よい開発側の人」の見分け方(のひとつ)は、「必要」の原点に触れさせたときの、反応です。
「それならば、このように作ってはだめですよ」
と批判し、
「ここは、こうするべきです。なぜなら〜〜」
と反対意見を話し始める、という疑問視の姿勢があるなら、OKです。


***◇◇◇開発者との要件定義のスタイル例◇◇◇
例えば、依頼側と開発側の代表的な人のみ(2名〜4名)でテーブルに着いた場合ですが、テーブル中央の1枚の真っ白の紙に、鉛筆で画面構成の一部をお互いに書き、
「こういう画面があって、で、このボタンをクリックした時に〜〜」という会話をする時間をたくさん持ちます。これは大切な時間です。この会話の中で、別途用意すべき資料の形も自然に決まります。

逆に、そのような仕事の依頼の仕方、確認・進行の仕方を開発会社が受け入れるかどうか?
というのが、問題になるのかもしれませんね・・・


要件定義はSEの仕事です

2007/12/14 20:50 詳細リンク

はじめまして、株式会社イーイットの細目と申します。

今回の件、「要件」を開発者に正確に伝えたいとのことですが、要件定義とはシステムエンジニアの重要な仕事です。

プログラムの知識がない方が開発者に内容を伝えようにも、プログラムでどのような事が可能であるか、また、プログラムがどのような書き方になるのかが分かっていないと非常に困難な作業となります。

システムエンジニアはプログラムの知識のない方から概要を聞き、プログラム構成を考え、それを文書に落としてプログラマーに依頼します。

プログラム構成を考えた上で開発者側に伝える必要があるのでしたらプログラムの知識は必須です。

それでも、要件定義をされるのでしたら
1.どのようなシステムが作成されたいのか(大まかな定義です)
2.そのシステムを制作する上で、どのような機能が必要なのか
3.その機能を使う際に、どのような形式での使用になるのか
上記3点を重点に置いた上で要件を考えられるだけでも非常に分かりやすくなると思います。
その上で開発者側と話し合ってみて下さい。

株式会社イーイット
細目 江利子
http://www.e-it.ne.jp/

(現在のポイント:-pt このQ&Aは、役に立った!

このQ&Aに類似したQ&A

小規模企業でも業務システムの開発を依頼できる? 専門家プロファイルさん  2008-09-11 11:37 回答3件
大手開発会社と中小規模の開発会社で得意分野は違う? 専門家プロファイルさん  2008-03-21 17:35 回答3件
社内システムの見栄えにこだわるのは無意味ですか? 専門家プロファイルさん  2008-07-24 17:32 回答3件
システム開発、仕様書についてについて。 imotenpuraさん  2011-12-30 04:20 回答2件
専門家に質問する

タイトル必須

(全角30文字)

質問内容必須

(全角1000文字)

カテゴリ必須

ご注意ください

[1]この内容はサイト上に公開されます。

  • ご質問の内容は、回答がついた時点でサイト上に公開されます。
  • 個人や企業を特定できる情報や、他人の権利を侵害するような情報は記載しないでください。

[2]質問には回答がつかないことがあります。

  • 質問の内容や専門家の状況により、回答に時間がかかる場合があります。
気になるキーワードを入力して、必要な情報を検索してください。

表示中のコンテンツに関連する専門家サービスランキング

メール相談

ホームページSEO診断

ホームペーイjの内部SEOに特化したサービス

小菅 太郎

アイナパル

小菅 太郎

(ITコンサルタント)

田川 耕

フードビジネスコンサルタントオフィス シナプス

田川 耕

(飲食店コンサルタント)

平岡 美香

フードコンサルティング株式会社

平岡 美香

(マーケティングプランナー)

メール相談 事業継承、会社売買のお気軽相談
中井 雅祥
(求人とキャリアのコンサルタント)