上流工程で成功する人、つまずく人 (技評SE新書 18)

著者 : 荒井玲子

制作 : 新書 

• 技術評論社 (2009年1月24日発売)

作品紹介・あらすじ

誰もがいつかはステップアップを考える「上流工程」。しかし、そこではプログラマーやSEとは異なるスキルが要求されるため、戸惑い、挫折する人も少なくない。どうすれば上流工程で成功できるのか?成功する人とつまずく人の違いはどこにあるのか?ベストセラー『ソフトウェア開発で伸びる人、伸びない人』の著者が、その疑問に答える上流工程の必読書。

感想・レビュー・書評

[kaizenさんの感想 · 2011年12月30日]

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

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

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

[dekadannaさんの感想 · 2018年11月12日]

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

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

[suさんの感想 · 2017年7月2日]

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

[sanochihiさんの感想 · 2017年5月2日]

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

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

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

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

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

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

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

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

＜メモ終わり＞

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

[akiyama924さんの感想 · 2014年7月6日]

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

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

[からべーさんの感想 · 2013年12月23日]

■書名

書名：上流工程で成功する人、つまずく人
著者：荒井 玲子

■概要

誰もがいつかはステップアップを考える「上流工程」。しかし、そ
こではプログラマーやSEとは異なるスキルが要求されるため、戸惑
い、挫折する人も少なくない。どうすれば上流工程で成功できるの
か? 成功する人とつまずく人の違いはどこにあるのか?ベストセラー
『ソフトウェア開発で伸びる人、伸びない人』の著者が、その疑問
に答える上流工程の必読書。
(From amazon)

■感想

読みタイミングが少し遅かった気がします。
内容は、上流工程で必要な事項を、薄くまとめた本という印象です。
「ニーズを拾い上げ、それをフィルタリングして、要件定義が出来
る事」が、上流工程のポイントとし、また、色々な制約の中で、
自分で考える事が重要なスキルだとしています。

言っている事に間違いは無いですが、これを読んだら上記が出来る
のか？と言われれば、答えはNOです。

これらの技術は、こんな薄い本では分かりません。

色々な専門書や実際の現場で失敗をしまくって覚えていくものだと
思います。

実際、現場の制約は現場によって違い、一概にこうすれば出来ると
いうテクニックは上流工程には現状、ないです。

でも、こういう視点を持って上流工程を実施するといいんだなと
分かるだけでも、大分違うと思いますので、簡単な気持ちで読んで
見るといいと思います。

■気になった点

・要望の収集からスコープの確定まで。
　　①要望(ニーズ)の収集
　　②要望のフィルタリング
　　　　実現性、無矛盾性、網羅性の観点で。
　　③要求の仕様化
　　④システムスコープの確定

・フィルタリング済みの要望を、「要求」と呼びます。

・分類力をつけたいなら、思いついてことを線なしの紙に書き出す
　事から始めるといいでしょう。線は優先付をしてしまう効果があ
　るので、避けた方がいい。

・明文化されないものは「知らないもの」

・要求を獲得できる人は、定義が上手です。

・定義力をつける簡単な方法は、辞書を愛読する事です。

・要求を獲得できる人は、相手が何を言いたいのかを考えながら
　話を聴きます。

・あるべき姿と現実とのギャップが「問題」となります。

・要望収集のプロセス
　①どちら(ビジネス/システム)に属する問題なのかを区別する
　②何が問題なのかを獲得する
　③何をしたいのかを獲得する
　④どのようにしたいのかを獲得する
　⑤要望を収集する
　
・問題に対して、どうしたいのかを明確にします。
　問題をすぐに解決したいとは限りません。

・要望のフィルタリングは、実現性、網羅性、無矛盾性の観点より
　実施するとよいです。

・スケジュールは、後ろから引くか、マイルストーンを置いて、
　調整していくのがいい。

・スケジューリングをしない人は、「週」で話をする傾向にあります。

・「とりあえず～～しておく」という考え方は、後にとんでもない
　ことを引き起こします。

・顧客は出来ない事は、出来ないと言われた方が次の手が打てるので
　喜びます。出来ないものを出来るというのは、信頼を失います。

・人間は、自分の知らない事は難しいと考える傾向にあります。

・会議を減らすには、会議の目的、決定権を持っている人物、を考え
　これにこたえられないのであれば、会議を減らす余地があります。

・どの技術はどの問題を解決するために生れたものか理解しましょう。

・制約がありそれを工夫して考えるのが、知識労働者です。

・自分の成果物をいくらで買うか考えてみるとよいでしょう。

[jianmiyouさんの感想 · 2013年2月23日]

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

[furu1972さんの感想 · 2012年10月23日]

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

[miwaさんの感想 · 2009年9月30日]

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

[極楽ぱんだ。さんの感想 · 2009年8月3日]

会社の人からかりる。