ホーム ITCとは? お知らせ・イベント 活動事例紹介 ITCコラム メンバー紹介 会規約 関連リンク
 
検索
メインメニュー
ログイン
ユーザ名:

パスワード:


パスワード紛失
新規登録
  • uchiyamaさんのエントリ配信
  • RSS
  • RDF
  • ATOM

ITCコラム - 要件を決めるのは誰か

ヘッダーナビゲーション

要件を決めるのは誰か2015/03/01 11:33 am

いつの間にか、そういうことになってしまっていて、その渦中にいると、水を差すのも悪い感じがして、本当かなと思っていても、黙っているということがあります。

「要件を決めるのは誰か」というのも、そのひとつで、今は、ユーザということになっている感じがしますが、どうでしょうか。(*)

    (*)SEC BOOK:経営者が参画する要求品質の確保 (以降、SEC)
      (超上流から攻めるIT化の原理原則17ヶ条)
       原理原則[9] 要件定義は発注者の責任である

自分のことなのに、まかせっぱなしでよかったのかいう意味では、昔から、そうだったのかもしれませんし、JUASの「システム開発のトラブルを防止する要求仕様書とは(JUAS2008.9.28)」(以降 JUAS)でも、発注者のかかわりが多いシステムほど成功するという調査結果が発表されていて、発注者のかかわりの重要性が指摘されていますので、原則としては、その通りなのだろうと思います。
それでも、ユーザが要件を決めるのは、やっぱり難しいし、他はどうやっているのと聞かれるし、ベンダには、そこを期待しているのだからといわれるし、期待に応える必要もあるかなと思ってしまうしで、この原則は、わがままな、お客様に苦労したベンダの逆襲というような気もしています。

JUASには、業務システム仕様書の記述レベルという図表も載っており、ユーザとベンダの責任分担という欄には、次のように書かれています。

  レベル−1 ビジネス機能提示
    ユーザ側責任:RFPレベルでベンダ提案書をベースに要求仕様書を明確にしシステム構築
               (要求仕様承認の責任)
    ベンダ側責任:RFPのビジネス機能からTo-Beのあるべき姿のシステム機能を提案
               (納入/契約仕様の実現)
  レベル−2 ビジネスプロセス提示
    ユーザ側責任:既存システム再構築ではビジネスプロセス定義と既存システム仕様提示で発注
               (基本設計承認の責任)
    ベンダ側責任:提示ビジネスプロセスの改革を実現するシステム構築を実現
               (設計、納入品の瑕疵責任)
  レベル−3 業務フロー提示   (省略)
  レベル−4 個別業務処理提示  (省略)
  レベル−5 個別業務処理/データ項目提示  (省略)

ユーザとベンダの、それぞれの責任が書かれていて、レベル−1で、ベンダ側の提案行為にふれています。レベル−1の段階では、ベンダには提案する責任があり、ユーザに、要求仕様の明確化とシステム構築の責任があると読めますが、要求仕様承認の責任となっているので、提案を取り入れて、それを承認することもあるということなのでしょう。

昔、建設業のお客様から「仕様なんて、いくら説明されてもわからない」と言われたことがあります。「家を建てるときに、お客さんは仕様なんて説明されない、プロにまかせている」とも。家を建てるときには、間取りやら壁の色やら台所の設備やらについて納得のいくまで説明を受けてからハンコを押すようなので、実際は説明しているわけですが、多くのサンプルから具体的な組み合わせを示して要望にあうものを選んでもらうという作業になっているので、聞いてもわからないような仕様をダラダラ聞かせることなどないということだったのでしょう。実際に、自分が何をしたいかはわからないことが多いし、とりあえず何ができるかを聞いてからというひとが大多数で、家を建てたいという気持ちになったときに、どんな家を建てたいかは、サンプルをみて予算と相談しながら決めようと思っていて、「どんな家が欲しいですか」と聞かれたたら、とりあえず「友達が我が家のような気がする家」とか答えて、広い居間とか床暖房とかを、工務からの具体的な提案を聞いて決めるようなものです。友達が我が家のような気がするかどうかは、お客様の責任で、広い居間と床暖房を作ることが工務店の責任。

イソップ童話に「3人のレンガ積み職人」という話があります。
旅人が町を通りかかり、働いているひとに、何をしているのかとたずねると、ひとりは「レンガを積んでいます」と答え、ひとりは「壁を作っています」と答え、ひとりは「歴史に残る偉大な大聖堂を作っています」と答えたという話で、一般的には、同じことをしていても目標や知識、心の持ちようで生き方は変わるというのが教訓のようです。これを、SEの役割とか成長の寓話として記憶してしまったので、3人ともレンガ職人であることを忘れて、いつの間にか登場人物が、プログラマと設計者と発注者(職人と親方と牧師)になっていて、この話の最後は、自分のなかではこうなっています。
レンガ職人は、何個レンガを積むかを決めてもらえれば丈夫できれいにレンガを積むことができ、皆に喜ばれています。牧師さんに、何個レンガを積めばいいですかと聞くことはありませんし、どう積むのかを決めてくださいともいいません。

要件を決めるのは、やはりユーザですが、ベンダもしっかりしなければという、野暮な結論でした。

このエントリーの情報

トラックバックping送信用URLを取得する

このエントリーの記録

投稿された内容の著作権はコメントの投稿者に帰属します。

Copyright (c) 2005-2006 IT Coodinator MIYAGIKAI All Rights Reserved.