It feels like you are mixing apples with bananas here, or in UX terms - the view with actions.
From a software design point of view, there should be a use-case of 'user edits X'. Users also benefit from the knowledge they are now editing something.
It seems that you are dealing with a very simple scenario here, as you did not mention commit/cancel options; but you did mention validation which could yield a message somewhere. Point being is that editing is more than just entering text, and related controls and messages need their own space, which will become an issue if these always exist next to a text area. Although your system may not need it right now, your suggested implementation will be hard to extend if new requirements arise.
Probably the best example against your idea is a spreadsheet - despite being an array of editable cells, only one cell is editable at a time and only upon explicit user action.
One can also easily predict issues with your solution - what if a user enters text in one text area then scrolls that area out of view? Any key strokes will alter data that is out-of-view.
My recommendation would be to keep the table representing the data, but allow an editor upon click / double click (the former could work if no selection is needed).
Depending on the editor complexity and validation/error feedback, you can choose between: