If you shrink your log file, and it regrows, then the database needed that space, so stop shrinking the database - because each time you do that, and it regrows, SQL will furher fragment the file and that will increase the inefficiency. It also takes CPU effort to "grow" the file, which will mean that the application slows down (and, usually, file will grow through user activity, so that slow-down will happen at a busy time for users).
If you are using Full Recovery Model? then increase the frequency of Log backups.
Look at the log backups from the last few days, is there a particular time fo day when the log backups are biggest? What is happening at that time? For us the biggest log backups are during database maintenance (e.g. index rebuilds), and we increase the frequency of Log backups to every 2 minutes during that data maintenance.
P.S. I wouldn't call, what you have described, as "Tuning" but rather "Housekeeping" or "Maintenance"
No, that's fine, its just that repeatedly shrinking the file is a performance issue, and I recommend avoiding it as a Best Practice.