本棚登録 : 
感想 : 
- Amazon.co.jp ・本 (288ページ)
- / ISBN・EAN: 9784822282912
作品紹介・あらすじ
本書は、厳しいスケジュール上の制約に直面したときに、どのように要求を発見し、吟味し、文書化していくかについて説いている。
感想・レビュー・書評
-
要求マネジメントとは「トリアージ」をすること。優先順位をつけ、適切に妥協し、顧客の望むシステムを作り上げる
●感想
面白い本だった。やはり、本のタイトル・イシュー設定からかなり絞り込まれているだけははる。筆者はさすが大学教授というべきか、要件定義プロセスを抽象化し、読書に取り扱いやすいフレームを提供してくれている。図表が何度も登場し、筆者の言いたいことが伝わりやすい。図表が分かりやすいため、結構軽快に読める。ただ、その図表にオリジナリティがあるので面白い。真似しやすくなる。要件定義プロセスにおける「要求抽出」はその後の設計・開発にかなり影響するため、SEとして、この本を読んでおいてよかった。本棚に保存しておきたい本。
本書にあった、納期を確率で示す「スケジュール対確率グラフ」というアイデアが面白い。これ、実際の開発プロジェクトに導入したいくらいだ。エクセルで、マクロを組んだら、いろいろ使いまわせそう。
●本書を読みながら気になった記述・コト
☆要求は変化する。次々に新しい要求が発生する ※これが、システム開発の本質である
・開発側は、新規で上がってくる要求を適切にトリアージする必要がある。一番危ないのは、「要求を受け入れるが、スケジュール・予算は変わらない」という姿勢だ。これでは、確実にプロジェクトは破綻してしまう
・新規要求を受け入れることは、必ず予算・開発期間の増加をもたらす。それらのリスクを顧客が受容するかどうかを確認しよう
・開発側は、要求のトリアージを行う際に、絶対的な言い方を避けよう。「○○の機能を実装するとすれば、～までに、納品できる確率が80%から30%に下がります」というように言うしかない
＊まとまな開発工数を算出するのは難しい。一番現実的なのは、過去の同規模の開発の結果を参考にすることだ
＊要件定義から開発導入にかけて、一番時間・予算をかけるべきは要求理解
・要求理解に時間、予算をかけたプロジェクトの方が、予算超過が少なかったという研究がある
＊全ての要求に答えることは諦める。全ての要求のうち、60%にまず顧客と合意が得られたら、要求文書を書き始めてよい
・すべての要求を知ることは決してできない
・早く設計に着手すれば、それだけ、新たな要求を発見しやすくなる
＊要求のエラーには大きく分けて3つのエラーがある
・認識のエラー...顧客と開発者間で、実装必要な機能の認識が異なっていた
・トリアージエラー
・仕様エラー
＊顧客との開発プロジェクトにおいては、用語集を作るべし
・プロジェクト上の問題は、単語の認識に齟齬があるところから来ることも多い
＊シーケンス図は、シナリオを表現するための良いツールだ
・モデルツールは、顧客との認識を合わせるのが目的。様々なモデルを多用するのは混乱を招くので注意
＊「ちょうど十分な要求マネジメント」とは、トリアージが行われていることである
・逆に、意識的にトリアージを行っていないなら、要求マネジメントができていない。予算と開発スケジュール、必須機能要件を満たしているかの検証が行えていない。つまり、そのようなプロジェクトは失敗するだろう
＊要求間の関係を見極めよう
・要求には関係性がある。必須依存、作業依存、サブセット依存などがある
2
詳細をみるコメント0件をすべて表示 -
要求マネジメントの全体像をわかりやすく解説している。
そのステップは大きく次の3つだ。
1.要求の導き出し
2.要求のトリアージ
3.要求の仕様化
「トリアージ」という言葉の選び方が秀逸だ。
悠長に要求を吟味していては市場に遅れをとることになるし、あまり時間をかけなさすぎても取り返しのつかない要求の選び方をしてしまう恐れもある。
素早く、しかし、重要なものを選択していく態度をトリアージという言葉でよく表している。
アジャイルの登場を契機に、要求マネジメントに対する誤解も広まってしまったように思う。
悪く言えば「アジャイルだからドキュメントを書かなくていい、とにかくコードを書けばいい」と利用されてしまったきらいがある。
本書ではそれを指摘し、要求マネジメントの重要性を説いている。
本書で述べられる手法は、非常に軽量である。
要求自体は簡素な一文で表現し、リストになっているだけである。
そこに種々の注釈（依存関係やプライオリティ、モデル図やシナリオなど）を付けることで増補として備えている。
すべての要求に等しくドキュメントを付けるのではなく、濃淡をつけている点が良かった。
重要なものとそうでないものを際立たせることは、好ましい管理の仕方に思う。
「相手よりも自分の方が問題をより良く知っていると思ったら、あなた自身が問題の一部である」という一文がある。
要求を整理しようとしている側の視点からは、なぜあの人はトンチンカンなことを言うのだろう？と訝しむこともあるかもしれない。しかし、その人の視点に立つことで見える問題もあるかもしれない。
決めつけず、何がゴールにとって貢献する要求なのかに注目することが肝要だろう。
1
-
邦題より"Just enough requirements management"という原題のほうがわかりやすい。
0
-
ソフトウエアに対する要求仕様についてのみをここまで掘り下げた文献はおそらくないだろう。ソフト開発は、仕様のみで、天国か地獄かが決定されるほど単純ではないが、この著者の言う通りかなりの割合を決定してしまうことは否めない。初めてソフト開発リーダーを引き受ける前にこの本を読んでおけばあんなひどいこと？にはならなかったのに。だが、残念ならが、この本はその時には出版されておらず、どうしようもなかったのだが。将来、開発リーダーをする可能性がある人には、私と同じミスをふせぐために、必読の書といえる。
0
-
原題は"Just Enough Requirements Management"。要求の導き出し／トリアージ／仕様化／変更管理 という四つのカテゴリでまとめられている。仕様化に関しては自然言語を中心に必要に応じて必要なモデルを描くという現実路線で、参考になる点が多い。
0
-
要求トリアージの要求分類は参考になった。顧客が理解できる自然言語を推奨しているが、個人的には、複数視点のモデルで要求の漏れや妥当性を確認は必須だと思った。顧客にモデルを説明するかは別にして。
0
-
要求が変化したり、新たに湧き上がってきたりすることそのものを恐れてはいけないということですね。
問題とは「現実」ではなく「認識」であるっていうのは胸に止めておきたい。
ワインバーグあたりを読んでおかないとちょっと理解に苦しみそうな箇所もちらほらで、一回読んでOKってわけにはいかなそう。
0
高嶋優子の作品
