最近、「要件整理」の重要性を取り上げている記事などが目に着きます。
私も以前から仕事で気にしている内容なので、その内容を簡単に整理
してみました。
■例えば、「生産管理システム」構築時の要件整理の場合
私は、製造工場経験者で、実務で忙しい現場や管理業務にコンピュータを
導入するのは意外と難しいことは熟知していると思っています. ．．？
（詳細は割愛）
とは言っても社外の立場から、生産管理システムなどを構築する際は、
対象の固有の業務や現場作業は理解していませんから、関係者から
聞き取り（ヒアリング）し、要件を整理します。
その際、一般的に
・数人の人が使用するシステム
・多数の人が使用するシステムだが、使い方は皆ほぼ同じ
の場合は比較的簡単で、特定の関係者からのヒアリングで要件整理が
できる場合も多いのですが、
・例えば工場全体のシステムのような場合
（複数の人が使用するシステムで、イレギュラー対応も多く、
工場間の連携もある．．．）
のような場合は要注意です。
■ヒアリングによる要件整理の落とし穴
システム化の要求を整理するにあたり、関係者各々の立場での要望、
着目点、スキル、向いているところの見極めが大事かと思います。
例えば
・経営者の立場の人 ・管理者の立場の人 ・実務者の立場の人
・システムをイメージできる人できない人 ・個人的思惑．．？
など、様々な考え方を持った人からのヒアリングには、精度にも限界が
ありますし、関係する人が多くなれば本質が埋没することもあります。
また、方法論を多数決で決めればＯｋというものでもありません。
■まずは、手コンピュータで確認・検討・調整
そもそも、システムの要件整理には、下記内容を押さえていることが
前提条件となります。
�ゞ般格�析 → 今はどのようにしているか、
そして次どのようにしたいのか
�▲轡好謄牴修量榲�を具体的に定義化
�６般灰侫蹇爾寮依�
�ぅぅ譽�ュラー処理等の対応方法検討
�コ堂萍未篦�票のイメージ作成
�Τ堂萍未料犧酳�法
すなわち、業務を整理し事実として積み上げ具体的に検討し、システム
化の目的も含め、これから作る新しいシステムの使い方を机上で検討し
シミュレーションする必要があります。
（具体的なシステム化の課題等は割愛）
■キーワードは、
・要件開発 ・要件整理 ・合意の方法
・開発側とエンドユーザーとの間で、真の合意
でしょうか。
■以下、最近目にした関連記事や雑誌です。
ボーランド社のＡＬＭ製品宣伝記事に下記のような表現がありました。
開発プロジェクトが失敗する原因のトップに、要件の不正確さ、
不完全さ、要件の誤った管理がある。
また、要件の間違いは手戻り作業を引き起こす最大の原因となり、
その割合はプロジェクト全体の開発作業の40％にも及ぶという報告
がある。
問題は、これまでの開発の多くが、開発側とエンドユーザーとの
間で、真の合意が得られぬまま進められてきたことにあるのだ。
雑誌には下記のような特集がありました。
・日経ソフトウェア ２００６年９月・１０月号
「要求は開発するものである」
・日経ＳＹＳＴＥＭＳ ２００６年１１月号（ITproTechメールからの情報）
「特集１ 図解で極める要求定義」
その他、ITproTech メール 2006.10.26[要求定義を極める]から抜粋
・要件定義の方法論を知る
・ＤＯＡ型要件定義の実際 ・日本標準的な作業手順とは？
・非機能要件を見極める
・ヒアリングでは不十分 ・ひな型を使い漏れ防止
・上流工程の問題解決 要求定義編
・要求と機能の関係は？ ・うまく合意するには？
・上流工程の問題解決 仕様変更編
・仕様変更が出たときの「禁句」は？
・上流工程AtoZ
有名な書籍
・「動かないコンピュータ」という書籍は以前から有名
ところで、これらの関連記事を読むのも大変！
開発者からユーザまでわかりやすいものがあると嬉しいですが。。。
■コンピューティングの将来（業務システム）
要件開発とか要件整理の手法に関する標準化が必要かと思います。
この部分はコンピュータの技術から分離できるため、その気になれば
さほど難しくないと思いますが。。。
私も以前から仕事で気にしている内容なので、その内容を簡単に整理
してみました。
■例えば、「生産管理システム」構築時の要件整理の場合
私は、製造工場経験者で、実務で忙しい現場や管理業務にコンピュータを
導入するのは意外と難しいことは熟知していると思っています. ．．？
（詳細は割愛）
とは言っても社外の立場から、生産管理システムなどを構築する際は、
対象の固有の業務や現場作業は理解していませんから、関係者から
聞き取り（ヒアリング）し、要件を整理します。
その際、一般的に
・数人の人が使用するシステム
・多数の人が使用するシステムだが、使い方は皆ほぼ同じ
の場合は比較的簡単で、特定の関係者からのヒアリングで要件整理が
できる場合も多いのですが、
・例えば工場全体のシステムのような場合
（複数の人が使用するシステムで、イレギュラー対応も多く、
工場間の連携もある．．．）
のような場合は要注意です。
■ヒアリングによる要件整理の落とし穴
システム化の要求を整理するにあたり、関係者各々の立場での要望、
着目点、スキル、向いているところの見極めが大事かと思います。
例えば
・経営者の立場の人 ・管理者の立場の人 ・実務者の立場の人
・システムをイメージできる人できない人 ・個人的思惑．．？
など、様々な考え方を持った人からのヒアリングには、精度にも限界が
ありますし、関係する人が多くなれば本質が埋没することもあります。
また、方法論を多数決で決めればＯｋというものでもありません。
■まずは、手コンピュータで確認・検討・調整
そもそも、システムの要件整理には、下記内容を押さえていることが
前提条件となります。
�ゞ般格�析 → 今はどのようにしているか、
そして次どのようにしたいのか
�▲轡好謄牴修量榲�を具体的に定義化
�６般灰侫蹇爾寮依�
�ぅぅ譽�ュラー処理等の対応方法検討
�コ堂萍未篦�票のイメージ作成
�Τ堂萍未料犧酳�法
すなわち、業務を整理し事実として積み上げ具体的に検討し、システム
化の目的も含め、これから作る新しいシステムの使い方を机上で検討し
シミュレーションする必要があります。
（具体的なシステム化の課題等は割愛）
■キーワードは、
・要件開発 ・要件整理 ・合意の方法
・開発側とエンドユーザーとの間で、真の合意
でしょうか。
■以下、最近目にした関連記事や雑誌です。
ボーランド社のＡＬＭ製品宣伝記事に下記のような表現がありました。
開発プロジェクトが失敗する原因のトップに、要件の不正確さ、
不完全さ、要件の誤った管理がある。
また、要件の間違いは手戻り作業を引き起こす最大の原因となり、
その割合はプロジェクト全体の開発作業の40％にも及ぶという報告
がある。
問題は、これまでの開発の多くが、開発側とエンドユーザーとの
間で、真の合意が得られぬまま進められてきたことにあるのだ。
雑誌には下記のような特集がありました。
・日経ソフトウェア ２００６年９月・１０月号
「要求は開発するものである」
・日経ＳＹＳＴＥＭＳ ２００６年１１月号（ITproTechメールからの情報）
「特集１ 図解で極める要求定義」
その他、ITproTech メール 2006.10.26[要求定義を極める]から抜粋
・要件定義の方法論を知る
・ＤＯＡ型要件定義の実際 ・日本標準的な作業手順とは？
・非機能要件を見極める
・ヒアリングでは不十分 ・ひな型を使い漏れ防止
・上流工程の問題解決 要求定義編
・要求と機能の関係は？ ・うまく合意するには？
・上流工程の問題解決 仕様変更編
・仕様変更が出たときの「禁句」は？
・上流工程AtoZ
有名な書籍
・「動かないコンピュータ」という書籍は以前から有名
ところで、これらの関連記事を読むのも大変！
開発者からユーザまでわかりやすいものがあると嬉しいですが。。。
■コンピューティングの将来（業務システム）
要件開発とか要件整理の手法に関する標準化が必要かと思います。
この部分はコンピュータの技術から分離できるため、その気になれば
さほど難しくないと思いますが。。。
トラックバックURL↓
http://afftec.blog72.fc2.com/tb.php/37-19830774
プロフィール
