Will echo what many have already said.
The engine runtime is the fun part, and also mostly easy, unless you go for challenging state-of-the-art tech, or try to maximize performance. Creating the scene management, rendering and lighting, physics integration, possible multithreading etc. This can still take a lot of time (easily a man-year) depending on your expertise and how much features you're going to add.
After you've got the runtime done, the rest is to make the system usable for actual game creation. Up to this point you probably haven't needed to make any concrete decisions on how the game projects made with the engine are structured, how assets are imported and cooked into a build, how the game logic or rules are inserted and how they interact with the runtime, how the world data is represented for processes like precalculated lighting or navigation data creation, and how to make all the workflows usable for the creators. Now you're going to have to make a lot of decisions which influence what kind of games you can make with the system, and how usable it turns out in the end.
It helps if you can handle 3D modelling yourself so you can continuously test from a content creator's point. In reality working on the runtime & tools / workflow will very likely intertwine, I just separated them to illustrate the difference.
You can also decide to limit yourself to just creating a coder-oriented runtime library (compare e.g. to Cocos2D or Ogre), rather than a full-blown game engine (like Unity). It will still be a worthwhile learning experience, but probably not something that's directly useful as a game creation tool. Getting to the full-blown stage will certainly take man-years.