要件定義のセオリーと実践方法がこれ1冊でしっかりわかる教科書 の商品レビュー
要件定義をしっかりできず、プロジェクトの進行がうまくいかないことが多いので読んでみた。 やっぱり、まずはしっかり業務を理解することが大事だし、ただただ顧客の要望をそのまま対応するのは違うのだろうなと思った。 顧客が言語化できない、隠れた要求までくみ取れるなら、それが一番いいのだ...
要件定義をしっかりできず、プロジェクトの進行がうまくいかないことが多いので読んでみた。 やっぱり、まずはしっかり業務を理解することが大事だし、ただただ顧客の要望をそのまま対応するのは違うのだろうなと思った。 顧客が言語化できない、隠れた要求までくみ取れるなら、それが一番いいのだろうと思う。自分には難しいけど…。 後、業務知識(いわゆる、ドメイン知識)は、チームメンバーには共有する必要があるのだろうなと。部下に仕様や設計書だけ示して作成はできても、どういうふうに使われるか分かってないのだろうなと思うことはあるけど、業務を伝えられてないのだからそりゃ分からないよなと。
Posted by
このシリーズなんかしっくりこないんだよな とりあえず他の要件定義、Se系の本読んでからもう一周しようか コンサル本も併せて読んだら良い感じになりそう
Posted by
要件定義について分かりやすくまとめられている。 特に以下は参考になった。 1 ・システムライフサイクルの絵 2 ・対象範囲を共有するためにエコシステムマップを作る 3 ・情報の一覧化整理 ・BABOKの検証チェックリスト 4 ・要件定義は具体的な施策まで示さない ・一覧化と整理方...
要件定義について分かりやすくまとめられている。 特に以下は参考になった。 1 ・システムライフサイクルの絵 2 ・対象範囲を共有するためにエコシステムマップを作る 3 ・情報の一覧化整理 ・BABOKの検証チェックリスト 4 ・要件定義は具体的な施策まで示さない ・一覧化と整理方法 5 ・IPA非機能要求グレード 6 ・決定事項の明文化 ・要求のライフサイクル管理
Posted by
基本的なことが描かれているなという印象. だけど,書いてあることがわかることとできることは違うしその基本の中で漏れているものがないかを振り返ることができる. よほどの熟練者でない限り要件定義に携わる人は持っておいて損しない一冊ではないだろうか. ======== どこまでやれ...
基本的なことが描かれているなという印象. だけど,書いてあることがわかることとできることは違うしその基本の中で漏れているものがないかを振り返ることができる. よほどの熟練者でない限り要件定義に携わる人は持っておいて損しない一冊ではないだろうか. ======== どこまでやればいい? →システム規模が見積もれる具体性 →設計工程の作業が進められる詳細度 衝突が発生しがちなシーン 優先順位付、作業開始・終了判定、合意・承認 作業の取り決め やるべしことは何か いつ、誰がやるか 合意と承認 の違い 関係者間と握る→合意 最終責任者の受け入れ、文書化された合意内容の凍結→承認 会議→開催目的(共有、最終決裁etc) ジャッジのための基準を作る。 優先順位付 MoSCoW must should could 余裕があれば可能 won’t 今回は不要 何がどの程度できていれば作業開始可能・終了可能かをチェックリスト化して事前合意 p67 p99 検証のチェックリスト 文書の検証→品質、妥当性 前者:基本的な日本語、表記の統一、言葉の定義... 後者:要件と事業目標との結びつきを確認するもの ユーザ主体、事業目標まで遡って確認できることが重要、達成効果を測定可能な数値で示す
Posted by
きれいにまとまってかつ網羅的に説明がされてあって分かりやすくい良書でした。 以前とある開発案件紹介サイトのエンジニア評価欄で発注側はセキュリティに関する当たり前のことが満たされていなかったと低評価されたエンジニアが要件で言われてないことを後で要求されたと反論してる案件を目にしまし...
きれいにまとまってかつ網羅的に説明がされてあって分かりやすくい良書でした。 以前とある開発案件紹介サイトのエンジニア評価欄で発注側はセキュリティに関する当たり前のことが満たされていなかったと低評価されたエンジニアが要件で言われてないことを後で要求されたと反論してる案件を目にしました。 この本では要件定義ではベンダー側がユーザー側に隠れた要求を引き出すべきとあるので、悪いのはエンジニア側であるように思います。 さしずめ、このエンジニアは相手からの要求さえ満たせれば問題ないと考えていたのでしょう。 この本を読むことで自分がそういうエンジニアにならないための指標本にもなったと思います。 さらにサンプルなども載っていて、自分で定義書を書く際のヒントにもなりそうです。 こういう本に早く巡り会いたかったと思いました。
Posted by
目標・目的を共有して企画→要件定義→設計→開発→運用の繰り返しは、システムに寄らない場合でも事業あるいは個人の普遍的な取り組みに思えました。関わる人が多い場合は、段階ごとの合意形成が肝心であることも理解できました。
Posted by
Posted by
要件定義のこの類の本は少ない気がする。 内容は基本的なことが多いが、個人商店になりがちな要件定義について網羅的に書かれており、気付くことが多い。
Posted by
今後顧客に対してヒアリングしていく上で知識を整理できる良い本だった。 あとがきに「顧客に対して継続的にアドバイス・コンサルしていくような関係が求められていくだろう」という言及があった。 これからも広がっていくであろうクラウドインフラは、アップデートが頻繁なので、常に最新情報を持...
今後顧客に対してヒアリングしていく上で知識を整理できる良い本だった。 あとがきに「顧客に対して継続的にアドバイス・コンサルしていくような関係が求められていくだろう」という言及があった。 これからも広がっていくであろうクラウドインフラは、アップデートが頻繁なので、常に最新情報を持ち情報提供し続けられるベンダーは価値を出しやすいのではと感じている。 この本には、顧客と良い関係を保っていくための方法が体系的にまとめられているので、一読をすすめる。
Posted by
これまで読んだ要件定義と名の付く本の中では最高のものでした。 要件定義についての網羅感があるのと、各方法論の解説に加え、要件定義書のサンプルまで用意されているので、かなり経験が浅くても、この本に従うことで良い要件定義が出来そうなイメージが湧きました。 さらに、ユーザとの要件定義の...
これまで読んだ要件定義と名の付く本の中では最高のものでした。 要件定義についての網羅感があるのと、各方法論の解説に加え、要件定義書のサンプルまで用意されているので、かなり経験が浅くても、この本に従うことで良い要件定義が出来そうなイメージが湧きました。 さらに、ユーザとの要件定義の進め方・会議の仕方などの解説や、事業会社の決裁のされ方についての解説など、要件定義の手前の話も充実していて、それなりに経験を積んだ自分にとっても有益な内容でした。 これは経験の浅いITエンジニアにおすすめしたい一冊。
Posted by
- 1
