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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

http://labo.itsl.jp/

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

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


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


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


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

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

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

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

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

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

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

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

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

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

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

*常に目的を意識して

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

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

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

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

*シンプルな目的定義を

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

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

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

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