マネージャの在り方若しくは廃止論に反する思い
はじめに
はじめに断っておくとマネージャには担当部門においてる無能なマネージャもいるし、有能なマネージャもいる。これはエンジニアに優秀なエンジニアもいるように、残念なエンジニアもいるのと同じである。ただ、マネージャとエンジニアの比率は1対Nになるから無能なマネージャに当たるエンジニアは総数としては多くなる。
自分に見えていた風景
自分に見えていた風景の話をすると、2011年ごろまで、アジャイル界隈ではアジャイル開発とウォーターフォールの対立を揶揄するようなスライドが散見された。ところが2012年のあたりから風向きが変わった。そんな対立に油を注ぐ暇があるならアジャイルで成果を出すべきだと言ったスライドを見かけるようになると同時に、組織論を語るようになった。
そこで問題になるのはマネージャである。個人的な解釈では、プロジェクトマネージャ＝プロダクトオーナであるから、アジャイル開発の役割に組織のマネージャの残れる場所はない。一方、アジャイル開発の組織はマネージャを廃しておきながら、分業化が進み、エンジニアリングマネージャやVPoEなど、一見組織のマネージャの一部の役割を分掌したロールが登場するようになった。
自分は、成果を得られる手法を選び、目的を達成したいことをファーストに考えているので、その視点から見ていると何をやっているんだとしか思えない。試行錯誤と言えばそれまでだが、結局、アジャイル開発界隈はどうなりたいのだろうかと不思議に思えてならない。
組織と権限
話を脱線するが、上場企業であれば、どの組織にも権限分掌の規程を定めているはずだ。経営、人事、規程制定、事業上の意思決定（予算執行など）を定め、そのとおりに業務を行う。これに基づいて業務を運用しているか監査を行い、違反をすれば是正しなければならない。
権限規程は、組織の構造に応じて権限をデレゲートする。予算執行の承認権限を役員、部長、課長に承認金額を設定し、権限の範囲でオペレーションする。
マネージャ廃止論
話を戻して、アジャイル開発界隈でマネージャを廃止する意見を見かけたとき、この辺りはどうするのかと思ったものだ。
もしかしたら、議論しているアジャイル界隈の人たちは非上場であったり、経営に関与していない、組織の運営に疎いのか、あえてそれをわかっていながら改善したい意図があってそう言っていたのか。
ただ、言葉の強ささはマネージャ不要という方が強いから、そうした意図があったとしてもそれは影に隠れてしまうし、そうした意図は捕捉されたことを見たことはない。
マネージャを廃止したくなる理由
マネージャを廃止したくなる理由のひとつにマネージャの能力不足があるのではないかと思う。エンジニアをマネージャにアサインするとき、エンジニアとして成果を出してマネージャに引き上げられるケースは多いのではないか。
これはエンジニアとして優秀だったから、マネジメントをやらせようというエグゼクティブの意図である。この意思決定をするとき、アサイメントするエンジニアにマネージャの素養を持っているか、マネージャのコンピテンシの観点で評価していないケースがあると、不幸が生まれる。
プレーヤとしては天才だが、監督には向かないというやつだ。天才なプレーヤでそれがそのエンジニアの属人的な優秀さに起因したものだと、自分と同じようにメンバのエンジニアも同等にできると思い、そこを閾値でことを始めるからメンバのエンジニアはついていけない。前提から噛み合わないからコミュニケーションも意思疎通がうまくいくはずがない。
ただ、前述のケースは少なくて、年次でマネージャになったケースの方がエンジニアの被害者が多い。実際、なんでこの人がマネージャになったのかと思うような上司に当たったことが多々ある。マネージャの資質もないのにマネージャをしているし、マネージャのコンピテンシを磨かないから、古臭い、個人の偏った価値観を押し付けられるため、エンジニアとしてついていけないと思ったことは数え始めたらきりがない。端的に言えば、自分も（特定の）マネージャなんていなくなってほしいと何度となく思ったことか。
こうした背景に、マネージャにアサイメントする際のqualifyを審査する制度を持ち合わせていない組織があるのである。ある意味、登用する側の責任に裏書きしているのである。実際、人事制度も候補者にマネージャ教育をして篩をかけるのではなく、任命されてからマネージャとはと教育を行う程度で、ひどい組織はそれもしない。
エンジニア目園で見れば、資質も教育もされないマネージャに何を期待できるのだろうか。そうした背景を知ってしまうと絶望しかない。
権限移譲と成長の機会
マネージャ不要論のひとつに、権限委譲があると思う。これも自分の理解であるし、他でも聞いたりするのでそれほど違和感はないと思うが、役割は人を成長させる。
この役割はロールでも構わないが、権限を与えることでも期待できる。何が言いたいかというと、ロールを伴わないとしても権限の一部を移譲することで委譲された人は成長する機会を手に入れられる。委譲されなければ委譲された範囲で考えることも意思決定することもないからだ。
だから、マネージャは自分の裁量の範囲でエンジニアに権限移譲をすればいいと思っている。実際、自分の担当事業の範囲では、エンジニアに権限移譲を行っており、極論を言えば、承認ワークフローのプロセスだけやっていれば事業は回る。承認ワークフローを残しているのは、権限規程で組織が定めているから移譲できないのである。そこまでやるなら規程を修正し、取締役員会などまで持っていけばいい。マネージャ不要論を主張するなら、現行の組織制度の変更まで面倒を見る覚悟を持っていてほしい。そこまでやっている組織の事例を見たことはないから、その程度なのだろうと思われても仕方がないのではないか。
マネージャとエンジニアの関係
エンジニアはマネージャに気を使って話しかけてくるケースが多い。自分がそこそこの年齢であることもあると思うのだが、こちらとしては偉くもないし、権限規程で持たされている権限はロール上の責任でしかなく、単なる組織の中で演じる役割でしかないと思っている。
それをわかっているエンジニアは気兼ねなく話しかけてくれる。そうした考えを持っているエンジニアとのコミュニケーションの始めはとても早い。いきなり本題から入れる。そうしたエンジニアは権限移譲を好む。裁量を求める代わりに裁量の範囲で責任を取ろうとする。もちろん、最後に謝るのは自分であるから、責任なんて言葉に出さないし、権限を移譲したのは自分であるから、そんなことを微塵も滲ませたりしない。
エンジニアの力量にもよるが、方向性だけ知っていて、マイルストーンに許容の範囲の中で進捗していれば、エンジニアはやりたい放題にしておく。これで結果を出してくれるのでさらに裁量を渡す。そうでないエンジニアには少しずつ経験をしてもらってエンジニアのキャパに応じた移譲を進めればいい。
おしまいに
長々と何を言いたいのかというと、それほど優秀でないマネージャでもマネージャの資質を少しでも持っていて、エンジニアとフラットな役割で、マネージャとしてのミッションを果たそうとしていれば、それなりにエンジニアと楽しくやれるという話である。
フォーカスするのは、組織のミッションの実現であり、日々の業務の中では試行錯誤の連続である。小さな失敗は多いし、ふりかえりをすればもう少しうまくやりたいと思う。こうした取り組みは組織の意思決定の上に成り立つから、他社の事例を持ってきても全く役に立たない。自分の組織の中で実験を繰り返すだけだ。その実験をしたければ、エンジニアも権限を持たなければならないし、そのためにはある程度の責任を負わなければならない。その覚悟を持てば、自分のもやもやとしているマネージャの在り方を実感することができるだろう。
頑張って。
