大手のユーザ企業の場合は継続的にシステム開発案件があります。そして、システム部門はシステム保守や開発などの現場作業は、パートナー会社に委ねているのが一般的です。そのようなシステム部門においては、稼働しているソフトウェアだけではなく、要件定…

要件定義フェーズの成果物はそのままSIベンダーへの見積もり用の資料(RFPなど)になるのが普通です。 このことがまた要件定義の混乱のもとになります。発注者としてのユーザ企業の立場では予算取りがあるので「システム開発費を全額決めてしまいたい」という…

大手ユーザ企業での要件定義は、通常従来その会社が独自に行っていた方式を踏襲するか、もしくは担当者の経験の範囲で独自の方式で行っているのが普通だと思います。また、ユーザ企業のシステム部門で要件定義が難しい場合はSIベンダーがその要件定義から参…

要件定義をスムーズに進めるためにはいくつかの視点が必要がある。上流工程の作業というものは明確な達成点が無いことから、どうしてもスケジュールが延びてしまうことや、成果物の品質が担当者によってばらばらになってしまう傾向がある。これらをうまくコ…

要件定義においてAs-ISとToBeの資料がごちゃ混ぜになっているケースを多く見かける。現状調査などで業務フローをつくりそれをベースに新システムを考えることが多いが、そのAs-Isとして作製した業務フローがいつしかTo-Beの業務フローとして認識されてしまう…

システム開発の上流工程において、よく以下のようなことが強調されている。 ・ゴールを明確にすることが大事だ。 ・システムのビジネス価値を明確にする必要がある。これは私もコンサルティングの場でよく口にするが、本当に重要なことはどこまでそれを突き…