上流工程で成功する人、つまずく人 の商品レビュー

荒井玲子【著】

2018/11/12

ソフトウェア工学でまだうまく扱えていない要求獲得の本。要求仕様書作成に関わる人は一読すると、なにかつかめるものがあると思う。

[private]・要求を獲得出来ない人は、実際に要望を集めてから分類する。
・獲得できる人は、モデルを作ってから収集する。
・無地のノートに手書きしてみる。
・用語の定義は品質につながる。
・相手の視点でモノ見る。これはこういうことでしょうか？
・表では抜ける。モデリングでフィルタリングできるようにする。
・要望はシステムの機能ではなく、エンドユーザーから見たシステムの利用方法
・要望を図で結び要望の矛盾を検出する。
・プロジェクトマネジメントのWBS
・後ろからスケジュールを引く。
・日常的な工夫が、大きなクリエイティビティにつながる。[/private]

2017/07/02

要求は獲得するものであるが、難しい。要求を獲得するプロセスを定義されたことで、難しい理由もわかった。それはビジネススキルの部分であり、意識して取り組んでいかなければならない。

2017/05/02

上流工程でつまずいていたときに社内の書架で目にして、思わず手にとってしまいました（・＿・；）

・要求は確定している
・要求はすでに存在している

要求のモデリング手法に関する研究の多くが、こうしたことを前提にしているが、
現実の場面では、そんな前提が成り立っていることはまずあり得ない。

という著者の洞察から、
確定していない、ユーザー自身も明確には意識していない要求を、
システム開発者がどのように踏み込んでいくことで獲得し、モデリングしていけるかを平易な言葉で書いた本です。

＜以下、参考になったところのメモ＞

・要求を獲得する際には、要求を実現性／網羅性／無矛盾性の観点で検証の上、フィルタリングしていく必要がある。
　多くのプロジェクトで、要求は実現性の観点からしかフィルタリングされておらず、これがプロジェクトの失敗の原因となっている。
　例えば、要求同士が矛盾した状態で設計に入ると、その矛盾が設計の複雑さとなって表れる。

・要求のフィルタリングをする際に、表を使うのはよくない。
　表だと、個々の要求を独立してしか取り扱えない。
　そのため、要求間の関連性という重要な部分を見逃してしまう。

・要求のフィルタリングをうまくできるかどうかは、実は、要求の獲得の段階ですでに決まっている。
　要求を獲得する段階で、要求のカテゴリをきちんと設定しておくこと。
　このことで、網羅性の検証が可能になる。
　（逆に、これをやっていかないと、網羅性の検証ができない。ただ「なんとなく要求がたくさんでてきたから網羅されたかな」となってしまう。）

＜メモ終わり＞

耳が痛すぎて芳一になりそうです＞＜。
プロジェクト始める前に読んでおきたかったです。

2014/07/06

『UMLは手段』の著者が要求獲得（＝要望のフィルタリング）について書いた本です。

事実と筆者の経験が混ざっているので、初級者よりも中級者以上が自らの経験と照らしながら荒井氏の伝えたいメッセージを考えながら読むとよいと思いました。

2013/02/23

「上流工程で成功する人とは何を考え、行動しているのか」を上流工程でつまずく人と比較して書かれています。
既に上流工程を経験されている方は既知の内容かと思いますが、これから上流工程に携わる、若しくは上流工程を目指す方には「何に意識すればいいのか」、「何に意識を持たなくてはいけないのか」が書かれているのでよい本かと思います。

2012/10/23

【内容】
要求定義フェーズでの注意点やプロジェクトマネジメントでの注意点を軽くまとめている。
【得たもの?やってみること】
辞書を買って読もう。
【感想】
そりゃそうだと言う内容で、考えるヒントは書かれているが、すぐに使えるものはなく、正論が書かれているだけ。
参考にはなるが、でどうするの？とは思う。
そこは自分で考えろという主旨なんだろうが、もう少し現実味というか、現場感のある内容がほしかった。

2011/12/30

本書はIT業界における上流工程の本である。
他の業界においては、ITは下流工程で主に使うので、早い話が、下流工程の話である。

業界によっては、上流工程でITを使うところもあるが、それは設計の道具であったり、試作のシミュレーションであったり、その会社の顧客との意思疎通を図るための道具としてである。

IT業界では、なぜ、設計の道具、試作の道具としてITを上流工程で使いこなしていないのだろう。
その疑問に本書は何を答えているだろうか。

2009/10/04

とても勉強になった。ソフトウェア開発を知らないエンドユーザーから要望を収集し、要求を仕様化することの難しさ。ただユーザーが言うことが正しいとばかりに「言われたまま作りました」ではお話にならない。決断力、問題発見力が必要で、ユーザーの希望があるからと言って全て受身で仕事をしている人を知的労働者とは呼ばない。ただの作業者である。また、急に召集される無駄な会議について、著者の意見は厳しい。会議にかかる時間とコストをちゃんと計算してみよ　という。会議資料の配付等の事前準備、その後の議事録の作成、会議の時間、これを全て計算するととてつもない額になる。まさしく今日の会議そのもの！って思った。「いったい何年もいくらかけて、この会議開いてるんだよ！」って言いたくなる。えらい人が20人も出てるんだからすごい金額になるよね。で、実際何ができたんだろう？？ホント不思議だよ。これを無駄と呼ばずに何と呼ぶのか？

2009/10/04

直近のスケジュールしか引けないプロジェクトは失敗に終わる。非知識労働の技術者は自分のスケジュールを立てることはない。何もなければ、と言う様になる。問題解決にプロジェクトメンバを巻き込む。メンバは考える時間を奪われる。プロジェクトをコントロールし、当初立てた計画通り開発を進めることをプロジェクトスコープの維持という。進捗管理ではなくチェックポイントで検証する。

2009/10/04

要求を獲得できる人の必要スキル
・分類力
・定義力
・コミュニケーション力
・技術力
・判断力
・問題発見力

?要望の収集
?要望のフィルタリング
?要求の仕様化
?システムスコープの確定

要求＝フィルタリング済みの要望

フィルタリング
・実用性
・無矛盾性
・網羅性

要望の収集〜フィルタリングにある問題→プロジェクトに現れる症状
・固まらない仕様
・止まらない仕様変更
・止まらない追加仕様
・修正による構造劣化

ボトムアップでは要望収集
?たくさん要望を集めた後、種類わけを行う。

トップダウンの要望収集
?まず問題領域に存在する要素・サービスの型を見分け、それら要素の構造や要素間の関連をモデリングする。
?すべての型をモデリングした後、実際の要望収集を行う。
?モデルにある型から種類を派生させ、その種類に実際の要望を配置していく。

ボトムアップでは要望の抜けが検出できないのでダメ。

コミュニケーション手段ので最も重要なのは「書くこと」。

問題のパターン
・ビジネスに関する問題　
・システムに関する問題

ビジネスに関する問題の原因
・外部要因からくる要望
・ビジネスモデル自体の変更

システムに関する問題の原因
・システムの構造劣化
・属人的な設計と設計書不在

要望収集のプロセス
?どちらに属する問題なのかを区別する。（ビジネスorシステム）
?何が問題なのかを獲得する。
?何をしたいのかを獲得する。
?どのようにしたいのかを獲得する。
?要望を収集する。

エンドユーザが提示した解決方法をそのまま要望として受け取ってはいけない。
他の解決方法を知らないだけかもしれない。

エンドユーザにヒアリングする前に、要望の分類。

フィルタリング - 網羅性
要望収集において、表を使っていると暗黙的要望の抜けを発見することが難しい。
問題領域のモデルを作成する。
データ重視の問題領域であればＤＯＡ。ＵＭＬでビジネスモデリングも有効。

フィルタリング - 無矛盾性
矛盾を検出するには、
要望間の関連図をつくる。（関連する要望を結んでいく）
要求管理を支援するツールもある。

---
非知識労働者の特性
・非計画性
・スコープが維持できない
・他責主義
・その場主義
・不勉強
・ビジネスベーシックの欠如

知識労働者の特性
・計画性がある（後ろからスケジュールを引く）
・知識と技術をバランスよく持つ
・現場主義
・クリエイティブ
・プロ意識