Dora_PaPa_san's_Pages

アクセスカウンタ

zoom RSS 木村哲「本当に使える 要求定義 改定版」は、若いSEが是非読むといい。

<<   作成日時 : 2015/02/22 06:14   >>

トラックバック 0 / コメント 0

「要求」系の本は結構目を通しているつもりだが、この方は初めて知った。「要求」系の本は、Requirement Engineering的なものから、現場の生活の知恵的なものまで、いろいろなタイプがあるが、木村氏のこの本は、どちらかと言えば現場経験を叩いて比較的すっきりと整理体系化した感じで、「あるある」「そうそう」と同感して、結構全部読んでしまったりする類の本だ。よくできているとおもう。

基幹系と情報系とで、進め方は分けている。 たとえば、基幹系ではワークショップの持ち方などたいへん現実的で、「要求ワークショップ」の教科書的な内容に比して、まさに生活の知恵にあふれている。 情報系では、データ調査の目のつけどころ的な解説がおもしろい。

どれも、「あたりまえのことと」と言ってしまえばその通りなのだが、それが全然できないことが、こういう本の出現する理由なのだろう。 



なかなか示唆に富む例も多い

・「営業が・・・」と一口にいっても、外回りの営業か、内勤のアシスタントかで、要望がちがう。具体的に誰なのかをユーザーリストに書いていくと違いに気づきやすい?

・「プロセス質問(質問の質問)が上手にできる人は、つかんでくる情報が正確である」 ・・・ というのは、質問自体のフィードバックを得ながら核心にせまることができるからだろう。。。。

・「業務フローには2種類ある。「あるがままの姿を描いた業務フロー」と「あるべき姿の業務フロー」である」・・・「ホンネの業務フロー」と「タテマエの業務フロー」 ・・・ たしかに。 ただ、データ中心アプローチなどでは、現状のモデルと目標のモデルと明確に分けているから、こんなことはあり得ないのだが、ただ業務フローを書くと言う方法論では、こんな結果になるかもしれない。

・「要求定義で例外を重視するのは、「例外」として扱われている業務の多くが、実は「本来の業務」になりうるからである」 ・・・ これは、忘れやすい視点だ。 

・「アンケートは凝りだすときりがない。そして、質問数が多いほど得られる結果は分かりにくくなる、という性質である」 ・・・ これも、なかなか言い得て妙の言葉だ。 

・マネジメントがよく使うキーワードはきちんと使おう。 キーワードが入っていないと、ちゃんと理解していないと思われ、無用の追加作業が発生してしまう ・・・ というような趣旨の話したが、これは、全く生活の知恵だ。

・「問題」は数が多ければ多いほどよいと言うのが本書の立場。「100や200ではとてもたりない」

・「要求定義プロセスでは、普段あまり接触のない顔ぶれで行うことが多い。 ホワイトボードを使う方法では、自由で制約のない問題の指摘は難しいことがある」・・・「ワークシートを使って一定時間個人でプリワークをしてもらう。 少なくとも30〜40分以上かける」 ・・・ これも、なかなか、経験に富んでいる言葉だ。 

・「情報ニーズ」は間接的なもので、真の業務ニーズではない。 だから情報提供すればそれで終わりであとは関知とないという・・・・態度は、本来の情報システムに携わる人としては正しくないのだろうと私も思う。

・用語と指標のルールでコスト削減が可能。 ・・・ 仕様確定が楽になる。打合せと確認の工数が減る ・・・ というのは、素晴らしい卓見だとはおもうが、これは、意外に実現が難しいことではないのだろうか。。。




木村哲「本当に使える 要求定義 改定版」(日経BP 2006.10.2)
序章 問題提起
第1章 要求定義を学び直す
第2章 要求定義の手順を知る 基幹系システム編
1.  戦略と目的を確立する
2.  スコープを設定する・・・ビジネス・ユースケース図
3.  対象ユーザーを洗い出す・・・ユーザーリスト
4. 顧客を洗い出す・・・顧客のプロファイリング
5. 現状を把握する・・業務理解、問題の発見、業務フロー、例外の発見、顧客の視点
 ・ヒアリング調査、 ・アンケート調査、 ・ドキュメント調査、 ・現地調査、 ・マネジメント調査、 ・ワークショップ
6. コア問題を洗い出す・・・問題の収束手法
7. 業務を設計する・・・詳細業務フロー、詳細ユースケース図、例外的処理把握
8. 機能要求を特定する・・・BFC、SFC、機能説明
9. 機能を評価する・・・機能評価、プライオリティ付け
10. モックアップを作成する・・・ユーザーインターフェース、操作性、現場の声とフィードバック
11. 非機能要求を洗い出す
 ・可用性要求、 ・環境要求、 ・セキュリティ要求、 ・コンプライアンス要求、 ・システム要求、 ・運用要求、 ・処理パフォーマンス要求、 ・品質要求
12. フィージビリティ・スタディを実施する
13. ドキュメントを整合し仕上げる・・・ミツション/ビジョン、システムの目的、スコープ、ユーザー要求、業務フロー、戦略的課題、機能要求一覧、モックアップ、非機能要求一覧
第3章 要求定義の手順を知る 情報系システム編
1.  戦略と目的を確立する
2.  スコープを設定する・・・ビジネス・ユースケース図
3.  対象ユーザーを洗い出す・・・ユーザーリスト
4. 現状を把握する・・業務パフォーマンスの要求、情報の視点、データの検証
 ・ヒアリング調査、 ・アンケート調査、 ・ドキュメント調査、 ・現地調査、 ・マネジメント調査、 ・データ調査/値調査、 ・ワークショップ
5. 投資効果シナリオの布石 ・・・ ・経営ニーズ、業務ニーズ、情報ニーズを洗い出す
6. CSF/管理指標を洗い出す・・・CSFバランス・スコア・カード
7. 用語BOOK/指標BOOKを作成する・・・用語と指標のルール化
8. データの粒度をそろえる・・・データ収集実現性、データ範囲特定
9. 非機能要求を洗い出す
 ・可用性要求、 ・環境要求、 ・セキュリティ要求、 ・コンプライアンス要求、 ・システム要求、 ・運用要求、 ・処理パフォーマンス要求、 ・品質要求
10. アプリケーション・タイプを判定する・・・ツール要求の明確化
11. ドキュメントを作成する・・・ミツション/ビジョン、システムの目的、スコープ、ユーザー情報、経営/業務/情報ニーズ、マネジメント指標、データ検証の結果、顕在化しにくい要求、ツール選定のガイドライン
第4章 要求定義のトラブルシューティング






SEがはじめて学ぶ会計
日本実業出版社
広川 敬祐

ユーザレビュー:

amazon.co.jpで買う
Amazonアソシエイト by SEがはじめて学ぶ会計 の詳しい情報を見る / ウェブリブログ商品ポータル

【新品】【本】【2500円以上購入で送料無料】上流工程UMLモデリング 業務・要求分析からプログラミングへのモデル化技法 浅海智晴/著
ドラマ楽天市場店
商品情報商品名【新品】【本】【2500円以上購入で送料無料】上流工程UMLモデリング 業務・要求分析

楽天市場 by 【新品】【本】【2500円以上購入で送料無料】上流工程UMLモデリング 業務・要求分析からプログラミングへのモデル化技法 浅海智晴/著 の詳しい情報を見る / ウェブリブログ商品ポータル

テーマ

関連テーマ 一覧


月別リンク

トラックバック(0件)

タイトル (本文) ブログ名/日時

トラックバック用URL help


自分のブログにトラックバック記事作成(会員用) help

タイトル
本 文

コメント(0件)

内 容 ニックネーム/日時

コメントする help

ニックネーム
本 文
木村哲「本当に使える 要求定義 改定版」は、若いSEが是非読むといい。 Dora_PaPa_san's_Pages/BIGLOBEウェブリブログ
文字サイズ:       閉じる