自身がエンジニアチームのマネージャーとしてチームメンバーに何かタスクを任せる場合、極力How、WhatではなくWhyを伝えるようにしています。
How、Whatを伝えた上で対応してもらうことは一見最短ルートを行くように見えますが、本質的な「なぜそれをやるのか？」というWhyが抜けてしまい、「もっと良い方法があるのではないか？」「そもそもそれを本当にやる必要があるのか？」という疑問が欠落してしまい、結果的に余計な工数をかけてしまいます。
例えば、「システムAからシステムBにデータを同期させてほしい」とエンジニアに依頼した場合、さらに言えば「システムAからシステムBにCSVエクスポート＆インポートを使ってデータを同期させてほしい」とHow付きで依頼した場合、大抵エンジニアは依頼された内容通りに遂行してくれます。
これはこれでOKなのですが、Whyを付け加えて、「経営陣向けにシステムAに蓄積されているデータを使ったダッシュボードをシステムBに構築したいから、システムAにシステムBにデータを同期させてほしい」と依頼した場合、結果的にシステムAからシステムBにデータを同期させることになるかもしれませんが、以下のような発想が出てくるかもしれません。
- そもそもダッシュボードという形が適切なのか？もしかすると定期的なメールによるレポート配信でもいいのではないか？
- ダッシュボードを作るのにシステムBは本当に適しているのか？システムCの方がより使い勝手の良いダッシュボードを少ない工数で作れるのではないか？
- ダッシュボードに使うレベルのデータ（集計済みデータ）であれば、実はシステムBに既に存在している。
考える時間は少しプラスされますが、その分実装工数が削減され、トータルでは少ない工数で実現したい内容が達成できるかもしれません。」
当然、エンジニアから依頼者に対してWhyを確認することも大事ですが、状況によってはWhyを聞きづらい場合もあるので、依頼側が意識してWhyを伝えてあげるといいのではないかと思います。