手戻りなしの要件定義 実践マニュアル 増補改訂版 の商品レビュー
最近システム開発系の著書ではDevOpsとかアジャイルばかり読み漁っていたが、本当にウォーターフォールモデルではいけないのかというのは今一度よく考えるべき点である。そこで、要件定義の実践マニュアルなるものを選んでみた。著者は日立製作所でSEとして20年活躍されているとのこと。 ...
最近システム開発系の著書ではDevOpsとかアジャイルばかり読み漁っていたが、本当にウォーターフォールモデルではいけないのかというのは今一度よく考えるべき点である。そこで、要件定義の実践マニュアルなるものを選んでみた。著者は日立製作所でSEとして20年活躍されているとのこと。 一通り読んで思ったのは、確かにお金と時間が無際限にあれば方法論として間違っていない気がするが、今時そのような前提は成立しないのだとすると、やはりこのようなシステム開発の進め方ではよいものはできないのではないかと率直に思ってしまった。各成果物としてのドキュメントを見ても、具体的な業務のイメージがわかない。活用部門としてこれらの書類を見せられて漏れがないかと問われても、答えようがなく、手戻りなしとなるようには到底思えない。 一方、このウォーターフォールモデルを前提としてもやはり必要なのはコミュニケーションスキルであり、本書もファシリテーションのスキルについて多くの紙面を割いていることは、興味深い点である。
Posted by
全体のフローから具体的な会議の開催方法などまで全体について書かれた本。どう要件を探して固めていくかが具体的になっている。
Posted by
この本に書かれているようなtoo heavyなプロセスで要件定義してたら、システム出来上がる頃にはビジネス環境変わってそう。というのが率直な感想。 超巨大基幹システムとかを作る場合は、こういうプロセスが必要になるのかも。ただ、その場合も細かく分けてなるべく大きなリリースにならない...
この本に書かれているようなtoo heavyなプロセスで要件定義してたら、システム出来上がる頃にはビジネス環境変わってそう。というのが率直な感想。 超巨大基幹システムとかを作る場合は、こういうプロセスが必要になるのかも。ただ、その場合も細かく分けてなるべく大きなリリースにならないようにすべきだと思う。 既存システム改善における要件定義の進め方は、今やっていることでもあり、参考になった。もらった要望をそのまま鵜呑みにせず、一回噛み砕いてみることは大事だと思う。 5章と6章はヒアリングスキルと、合意形成のスキルということで、要件定義以外の場面でも使えそうだった。 というわけで、最後まで読み終わった。BABOKにちょっと興味が沸いた。
Posted by
- 1