マネジャーが我慢を学ぶことの重要性
Updated Date: 2023/11/05 03:00
先日「パレ・ド・Z〜おいしさの未来〜」という番組を観てて、 料理長の人が仕事終わりに必ず河口沿いのベンチに座ってその日1日を振り返るという場面があった。 その間彼は、その日の出来事（例えばチームメンバーにかけた言葉の正しさ、行動の正しさ、接客や料理の正しさなど）を考えるそうだ。 いち料理人であっても、店を経営し、多くのお客さまに価値を届ける場合は、1人ではなくチームで取り組まなければならないということを知れる良い機会だった。
マネジャーやリーダーは、多くの場合メンバーにフィードバックを与えなければならない。 そしてそれは、良い内容ばかりというわけではない。
悪いことは顕在化しづらい
良くないことは良くない。それを是正しなければならない働きかけは、悪いことを仕方なく続けるよりもっと重要である。 例えば遅延が発生しているプロジェクトの場合、原因を探らなければならないのだが、 その原因が個人タスクの進捗に問題があった場合は、メンバーに対してフィードバックをしなければならない。 でも、人を責めることなく正しい方向へ持っていくには、それなりの工夫が必要である。
そしてなお悪いことに、悪いことは顕在化しづらい。 それは人としての優しさで「ここだけの話」にしたり、そもそも悪いことを言うと迷惑をかけるからというフィルターが掛かったりする。 だいたいの炎上プロジェクトは炎上することが分かっていながらも見積り時に積んだバッファで後半挽回できるってことで後回しにされる。 そしてそれは数字からは見えてこない。
この問題に果敢に取り組むために、シリコンバレー界隈では失敗はすぐに検知することと失敗をすぐに振り返ることをやっている。 いまやシリコンバレー式を体現したNetflixも、失敗を即座に指摘しあい、懺悔する儀式をするそうだ。 さすがに行き過ぎな気もするけど、定期的な振り返りで悪いことをちゃんとあぶり出してそれをみんなに周知させるのは効率が良い。 もちろん、この悪いことの揚げ足をとって、人を批判するようなチームではないことが前提ではあるが。
参考記事：できない社員を首にしないと自分が首に Netflix社員の恐怖
我慢が必要
大体のチームメンバーは失敗する。それはマネジャーからみたプロジェクトやプロダクトの捉え方と、チームメンバーのそれが異なるからだ。 もともとエンジニアだった人がマネジャーになるのであればすぐに分かると思うが、そうでない場合このギャップがなかなか埋まらない事が多い。 大企業のSIなんて特にそうで、現代的な開発現場において、古のプロジェクトマネジメント手法でそれを管理しようとするというのは、 間違いじゃないかもしれないけど様々なギャップをコミュニケーションとツール・ルールで埋めていかなければならない。 そしてそれはマネジャーの主業務である。
エンジニアにマネジメントで重要な指標を説明してもあまり意味がない。それはエンジニアの成果目標でもなければ直接的な評価対象でもないからだ。
彼らの主業務は安定した品質のソフトウェアを開発することである。
つまり、マネジメントはエンジニアが最高の仕事をできるように場を整えるというのも仕事の1つである。
そしてこの仕事はだいたいの場合すぐには結果が見えない。
正しい答えが返ってこなかったり、施策が思うように行かなくとも我慢しよう。
結果は順番に出てくる。エンジニアは自身の行動の結果を突きつけられると、その原因を探る(まるで不具合の原因を特定しているかのように）。
ある程度結果が出るまでは、我慢して管理しないこともマネジャーの仕事である。
我慢が必要な例
僕が出会った「ここは我慢すべきだった」と反省した場面を挙げてみる。 以下ではチームメンバーは全員エンジニアであると仮定する。
- 答えの出ない会議 会議は有限の時間をたくさんの参加者から奪っている。結果が出ないような会議は意味がない。 とりわけ、判断を要するようなものはその場で意思決定すべきだ。 だがちょっとまってほしい。それは誰がやるのだろう。 すくなくともマネジャーは、エンジニアの意見をしっかりまとめておくべきだし、 その内容を自分からではなくエンジニアから発信させるフォローをしなければならない。 でしゃばってすべてを答えてしまったら、エンジニアは「マネジャーさえ居ればいいんだ」と思ってしまうだろう。 この場合、エンジニアから議論を提案してもらう自主性を奪うことになる。
- 長引くリスケ 思うように進まない作業（バグが深淵すぎる、機能が複雑など）で停滞しているエンジニアになんと声を掛けるべきか。 マネジャーは状況を聞いて、的確に次の指示を出すことは可能だ。 でもそれはあくまでプロダクト・プロジェクトを中心に考えた場合の答えである。 エンジニアが必要としていることはなんだろうか。 この場合マネジャーが口を出すべき内容は次のアクションはどうするかに絞ることのほうが有益である。 そうすることで相互に納得・理解した上でエンジニアに能動的に物事を進めてもらうことができる。
- 議論の結論を提示する ある議論（振り返りでも計画会議でもいい）で、マネジャーは持った答えをその場で言うべきではない。 エンジニアは「答えがあるなら別にいいや」となるし、答えに対して議論を進める形になると、 その議論はマネジャーの意見の範疇外に発展しないことが多い。 議論の結論をコントロールするのではなく、議論の方向をコントロールしよう。
自分がマネジャーとして権威を保つことよりチームが自発的になることのほうが重要
我慢すべき例で挙げたように、それぞれの共通点はチームに自発的に行動してもらうことだ。
マネジャーはつい俯瞰的な視野で自らの思想や考えを以て彼らをコントロールしようとしがちだが、 それだと良くも悪くもマネジャーに依存したチームしか作ることができない。
そして、マネジャーの評価はプロジェクトやプロダクトの正しいマネジメントも重要ではあるものの、 チームをいかにマネジメントできたかについてもフォーカスすべきである。 圧倒的に良い数字が出ていようとも、チームが疲弊していたのでは全く意味がない。 これら2つはそれぞれをマネジャーに対する評価軸として考えなければならない。 どちらか片方だけではそのうちチームかプロジェクトのどちらかが破綻する。
まとめ
今回の内容はあくまで僕が考えていることでありベストプラクティスではない。 ただし、自分への自戒を込めて書いている部分も数多くあり、 要するに自分が失敗してきたことを振り返っているので、今後考慮する価値はあるのではないかと思う。
我慢は重要だ。自分が動いたほうが早いという場面は多くあるし、 自分を介してコミュニケーションを取ってもらったほうが管理が楽な面もある。 でも、そうすることでチームの自発性を損なうのは良くない。 楽しい議論も新しい価値観も生まれなくなってしまうし、創造性も失われる。 僕らマネジャーが作るべきは相互の信頼関係と活発な価値創造の場だ。 みんなが楽しく、ハッピーに、意欲的に働ける環境だ。
そのために、マネジャーができることを考えよう。
