You would need to set up a VPN tunneling connection. I would recommend using OpenVPN - it deals well with dynamic IP addresses and NAT, is secure, relatively easy to configure and has a package in Ubuntu which makes it a faster start. The ubuntu documentation site has a quickstart howto on configuring it. You would obviously need to set up the server part on your rackspace machine and the client part on your office machine.
After this is done and you have tested your connectivity, you would need something called a "reverse proxy setup" where a HTTP service running on your rackspace machine would forward all requests to your office machine webserver and hand the responses back out to the clients. HTTP proxy solutions like squid and popular web server software like apache or nginx support this mode of operation mainly used for load-balancing and caching by admins - but they will support your basic needs very well. If you want a fast setup with the least reading, I'd recommend going with nginx.
Edit: you have to consider the security implications of this setup as well. Do it wrong and you're inviting attackers to your internal network. As a general rule for the security concept, you would have to consider your
192.168.1.15 office server potentially harmful and make sure it can't wreak havoc when taken over by an attacker. Furthermore, you should make sure that your VPN connection does not allow anything but access to port 80 of your internal web server (typically by using iptables rules on your office server) - this way the potential rackspace server hacker would only be able to abuse nothing more but the web service.
Edit #2: technically, it is also possible use a simple port forwarding rule from your rackspace host, but this will have several disadvantages making it a poor choice. For one, you will not be able to do useful IP address logging at your web server as all packets will arrive with the source IP address from your rackspace host and having no further information about the request origin - reverse proxies work around that by adding an X-Forwarded-for (or similar) header to the requests which can be used for the logs. Additionally, you would end up directly exposing your internal webserver to "the evil net" thus significantly widening the attack surface.