タグ

要求定義に関するfevnirのブックマーク (4)

  • [Think IT] 第1回:要求定義方法論「MOYA」とは? (1/3)

    最近、システムの要求に関する話題がいろんなメディアで取り上げられています。 「システムをいかに作るか」については、様々なフレームワークや開発プロセスなど、多くの実績や研究が存在しており、かなり充実した状況になりつつあります。 そうなると、次に考えることは「どんなシステムを作るか」ということになります。 いくら品質がよく、性能もよいシステムだとしても「顧客に求められていないシステム」では意味がありません。 とはいっても「どんなシステムを作るか」については、それ程簡単な答えが用意されているわけではありません。「どんなシステムを作ればよいか」という疑問を突き詰めれば「そのシステムに関係する多くの顧客を幸せにするにはどうすればよいか」ということになるのです。 以下のような異なる状況では、それぞれにおける「幸せになることの意味」が違ってきます。つまり同じシステムでも状況によって、顧客が幸せになれるシ

  • http://www.nttdata-moya.jp/index.php

  • ユーザーが欲しいのはシステムではない ― @IT情報マネジメント

    要求定義の不備で大量の仕様変更が発生、プロジェクトは火の車に……。そんな事態を防ぐため、体系化された要求定義の方法論を提供するのが「MOYA」だ。連載では、MOYAの手法を活用して顧客の「隠れた要求」を引き出す方法を解説していく。 お客さまが当に望んでいるもの 「人はドリルが欲しいのではない、穴が開けたいのだ」 この言葉(あるいは似たような言葉)を聞いたことがある方は多いのではないでしょうか。これはニーズについて語られた有名な言葉で、欲しいのは商品ではなく欲求を満たすことであって、商品はその手段であるというものです。 システムを作る際にも、同じことがいえます。 「人はシステムが欲しいのではなく、業務をより良くしたいのだ」 といったところでしょうか。 つまり、こんな機能が欲しいというお客さまの要求(と思われる発言)は、その機能自体が欲しいわけではなく、その機能が提供している何かの価値が欲

    ユーザーが欲しいのはシステムではない ― @IT情報マネジメント
  • 「何のために」を業務部門と常に共有せよ

    最善を尽くしたにもかかわらず、やっと稼働したシステムに対し業務部門は不満を抱くばかり――。こうした状況を引き起こす原因を“あいまいな要求定義”に求めて久しい。だが、要求定義のためのテクニックを身に付けただけでは、状況は一変しない。「何のためにシステムを作るのか」といった根的なゴールを不明確なままに要求定義を急ぐからだ。業務部門とIT部門が一体になり、ゴールを明確にし、かつ共有するための体制作りがますます重要になってきた。 中堅損保会社の日新火災海上保険は2006年11月、契約内容を顧客に説明するための資料を作成する「ご契約内容確認マップ」システムを稼働させた。保険商品の内容が複雑になるなかで、契約時の顧客への説明責任をどう果たすかという経営課題を解決するための期待のシステムだ。 釜中貞彦 情報システム部長は新システムを、「稼働直後から営業部門の満足度は高い。納期も予算も予定通りで、情報シ

    「何のために」を業務部門と常に共有せよ
  • 1