 |
||||||||||
|
||||||||||
|
前のページ 1 2 3 |
||||||||||
|
||||||||||
| 業務を理解してはじめて要求が認識できる | ||||||||||
|
普通のエンジニアはクライアントから話を聞いているときに「受注状況をリアルタイムに把握したい」といわれたら、それはシステムに関する要求だなと認識して「それなら受注を入力する画面がいるな」と考えます。そのほかにも、「24時間365日で動いてほしい」とか「レスポンスは早い方がよい」とか、そういう情報は要求としてしっかり認識します。 一方で「社長から『在庫を半分に削減しろ』といわれている」といった話を聞いて、果たしてこれを自分が検討すべき要求だと認識しているかというと、必ずしもそうではないように思えます。おそらく、そのような話は自分にはよくわからない分野だし、「クライアントが自分で考えればいい」という先入観があって、頭の中をスッと通り抜けている人も多いのではないでしょうか。 しかし本来は、在庫を半分にするためには業務をよく理解して「今の業務フローでよいのか」「管理方法はこのままでよいのか」「在庫を半分にするために必要な情報が取れているか」など、そういう点を考えてはじめて「それならこういう画面が必要だ」「こういう帳票も作らないと」といったシステムの要求がでてくるべきなのです。 |
||||||||||
| 要求の構造化 | ||||||||||
|
そのような考え方ができないのは、「要求とはそもそも何なのか」という定義を、システム開発者が理解していないからです。そこで必要なのが、要求を構造化して捉えることです。 図3で一番大事なのは「ビジネス価値」「ビジネス要求」「システム要求」の3つの要求で、これらは階層構造で捉えていく必要があります。実はこの3つの要求は、図2の企業経営の要素を三角形とリンクしています。例えば三角形の真ん中に位置していた「戦略」は「ビジネス価値」をあらわします。戦略といっても色々ありますが、ここでいうビジネス価値とは「在庫を半分にする」「納期を半分にする」「売上高を何年後にいくらにする」といった、業務の達成すべき目的（ゴール）にあたるものだと考えてもらえればよいでしょう。  図3：要求開発方法論（Openthology） このビジネス価値は、「受注や生産計画を入力する」「在庫を棚卸しする」といった現場のユーザ1人1人の業務の連鎖によって実現されます。これが「ビジネス要求」といわれるもので、そのビジネス要求を満たすために、どんな機能をシステムは持つべきかが導き出されるわけです。これが「システム要求」です。 このように、「システム要求」の上位目的として「ビジネス要求」があって、さらにその上位に「ビジネス価値」があるわけです。そういう目的と手段のトレーサビリティ（追跡可能性）を追究していかないと、なかなか役に立つ要求はでてきません。そのためにも、図3のような要求の構造を開発者は理解しておく必要があります。 次回は、要求開発を実践するために押さえておきたいポイントをご紹介します。 |
||||||||||
|
前のページ 1 2 3 |
||||||||||
|
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
-
人気記事ランキング
-
-
連載
