DBA is a small acronym but a large role. At various times I have seen a DBA look after
- compute nodes
- installation and configuration of the above
- backups, and testing restores
- DR strategy
- enterprise data integrity
- data security
- data modelling, normalisation and database design
- data tier programing
- performance tuning
- operational availability
- on-call support
.. and others besides. I cannot see any of these disappearing just because Oracle/ SQL Server/ PostgreSQL is replaced by MongoDB/ Cassandra/ CouchDB.
"Oh," but you say, "There's no schema. I don't have to do that modelling & design thing."
"You're deluded," I would reply. If the system is for, say, order processsing (and not order processing and chocolate cake recipies and cataloging selfies etc.), and The Business distinguishes Orders by a 7-digit integer Order Number, and each Order consists of one or more Order Lines (referencing one Product each), then you have a schema. Just because it's enforced in the application layer and not in the DBMS does not make it disappear. And somebody had better be writting those rules down, and confirming them with the users, and communicating them to the test team, and teaching newly-hired employees what they are, and getting them into the end-user documentation, and ensuring old data can still be read by the just-changed application. Just because the rules can be changed in application code alone, rather than application code and DBMS script, does not make any of that stuff any less important.
So, for my two cents' worth, despite its many, many benefits I don't believe this class of software removes any significant task traditionally done by a DBA in the RDBMS world. It may redistribute them onto people holding other job titles, and the tasks may become easier to perform or less intrusive into the SDLC.
As for adding tasks, there is the issue of maintaining compatibility with old data written according to a previous understanding of the business rules. An RDBMS would not have this problem as there is only one acceptable schema at any point in time.