- Amazon.co.jp ・本 (352ページ)
- / ISBN・EAN: 9784478065792
感想・レビュー・書評
-
物語仕立てで読みやすい。ストーリー形式で問題定期と解決策が示される為、未経験の人にとってはとても読みやすく、勉強になる本だと感じた。
ただし、作中でも記載されていたが、あくまで参考書であって、教科書ではない。
ITは新しいことばかりなので、日々情報収集や勉強が大事だと痛感した。詳細をみるコメント0件をすべて表示 -
日頃のベンダー管理がうまくできていないと感じていたので、業務改善の参考にしたいと読んでみた。
ストーリーは置いておいて、物語仕立てなので、それぞれの立場でどう考えており、どんなことに気を付ければ良いかが、分かりやすく学べた。
特に自社内のリスクも含めて、ユーザーと共有することについて、考えさせられた。
言っても意味がないし、聞いてもらえないだろうと諦めてしまったことを思い出した。
このように、教科書に載っていないような、他人の失敗を疑似体験できる良い本だと感じた。 -
とあるシステムを市民開発することになり、PJメンバー間の認識ズレが気になっていたところに、参考にしようと手にとりました。読みやすくするためのストーリー展開に古さを感じましたが、押さえるべき要点が理解しやすく書かれていると思いました。
-
・要件定義
要件定義は業務要件定義(発注者作)とシステム要件定義(ベンダー作)がある。
業務要件定義とは、、
アズイズトゥービーを描くことで、どんな嬉しさがあるか?どんな懸念があるか?本当にやりたいことが実現できそうか?を整理する。★
システム化を考えるのはこれらの整理ができたあと。費用対効果が明確に得られる部分のみに絞る。範囲はあとから決める。
システム要件定義とは、、
機能要件、非機能要件を書くこと。
・スタートでは、2つ確認する。
①社内合意のために、社内関係者の感情と期待、懸念を整理すること。+②要件の必要性、十分性をチェックすること。
②は、要件定義で確認すべきことは、プロジェクトの目的と合っているか?目的を達成できる要素が過不足なく揃っているか?
・プロジェクト管理は、進捗管理、課題管理、リスク管理をすること。変更を振り返りできるようにする。スケジュールや要望が変わってヤバいと思った時点で追加提案する。
・
・
・・・・・・・・・・
-
本書は自分の会社や組織にシステムを導入しようとしている、システム担当者やプロジェクトマネージャーに向けて書かれています。小説のようなストーリー仕立てで、営業から新しいシステム作成の担当に抜擢された主人公と、外部のコンサルタントが協力して問題を解決していく中で何が大事なことなのかを学んでいけます。ストーリー自体は面白かったですし、著者が言いたい「システムの開発は、発注者とベンダの協業であるという」こともよく分かりました。システム企画に初めて関わる私のような立場であれば、最初の本としてはオススメだと思います。
-
要件定義過程において必要なポイントをストーリー形式で解説。先回りしてのリスク管理とリスクをユーザーとベンダで共有できる仕組みが必要。ベンダ側の注意点として気をつけなければいけないのは、合意なく成果物の開発に着手すること。成果物は随時合意することが重要。ユーザーのPJ目的に照らして、本件を超えた全社的な目標を頭に入れつつ会話をすることが+αに繋がるか。
-
めっちゃ面白い。プロマネの仕事やりたくなる。業務ベースで起こりうる問題をストーリー仕立てで提示していて読みやすい。
71/100 -
タイトルがイケてないけど結構本質ついてる気がする
-
☆信州大学附属図書館の所蔵はこちらです☆
http://www-lib.shinshu-u.ac.jp/opc/recordID/catalog.bib/BB23959489