プレイングマネージャーになるために。そして自律的なチームとは何か

初めまして。ウェブ開発部のオペレーションチームでエンジニアリングマネージャーをしております。HAと申します。
エンジニアリングマネージャーとして試行錯誤の毎日を過ごしていますが、その中で採用にも関わっております。採用の中で求職者の方から今後のキャリアビジョンをお伺いしているのですが、「プレイングマネージャー」を挙げる方が一定数いらっしゃるなという印象です。
やはりこの業界はプログラミングを始めとした技術が好きという方が多く、そこからは離れたくないという想いを持っているのだと感じます。

しかしながら！プレイングマネージャーとは中々に難しい役割だなと私は思っておりまして、検索すると一部辛い文字がサジェストされます。

これはプレイングマネージャーという文字列でGoogle検索した際にサジェストされた文言を表示した画像です。

私も経験があるのでひじょーーーーーーーーーーーーーーーーに良くわかります。当時の経験というか、エピソードを1つお話しします。

序章

プレイングマネージャーへの挑戦と失敗

2017年頃の話です。まだ前職に所属していた時代の話なのですが、当時プロジェクトリーダーの立場で仕事をしていましたがプロジェクトマネージャーとして一つの案件を対応することになりました。その時私が考えていたことはというと

「ついにプロジェクトマネージャーとしての役割を与えられたようだ」
「んーーー、でも手を動かしていたいしなぁ。手を動かさずにマネジメントとか性に合わん。」
「ってことはプレイングマネージャーってやつか？」
「とりあえず目指してみよう。そうだそれがいい」

ということでした。如何でしょうか。嫌な予感しかしませんね！

実際この案件は私としては失敗としてカウントしています。納期は守り切ったのですが、コストと品質を考えると成功とは言えない状態でした。自分にも作業を入れつつ予定を組んだのですが、日々のマネジメントをこなしつつ自分の作業を行なっていた結果、残業に追われ始めます。
それにより疎かになったのが各種レビューです。難易度の高い箇所の設計レビューが疎かになり、品質の悪いプログラムに繋がり、単体テストフェーズで爆発、というよくある光景を自らが作り出すことになってしまったのでした。。。

このあと私はスクラムマスターやプロジェクトマネージャーの経験を積むことで、プレイングマネージャーというものの難しさを言語化することができるようなりました。今回はそれを語ろうと思います。

プレイングマネージャーの難しさ

プレイングマネージャーで辛い思いをする理由

私もそうでしたが、プレイングマネージャーをやってみて最も辛いと感じるのは残業です。
マネジメント業務に加えて作業を持つのですが、進捗管理やメンバーからの相談、レビューをしていると定時になっていることがよくあります。（ありますよね？）そこから自分にアサインした作業をこなすため、残業を前提とした日々を送ってしまいがちです。これは大変辛い。これを避けるにはマネジメント業務がどのくらいの時間を必要とするのか理解する必要があります。

マネジメント工数とチームの規模感

ここで言うマネジメントとはプロジェクトマネジメントのことを指し、内容はPMBOKに書かれていることを想定しています。
私の感覚ではマネジメント工数は全体工数の15％くらい必要と感じています。この記事を書くにあたりインターネットで検索してみたところ、10〜20%くらいという意見を多く目にしました。となると15％は一般的な数字であると言えそうです。

さて15％というマネジメント工数ですが、6人のメンバーがいると90％のマネジメント工数が 追加で 必要となります。つまりメンバー6人に加え、ほぼ専任のプロジェクトマネージャーが1名必要になるということです。このチームでプレイングマネジメントする場合、手を動かせるのは10％程度ということになりますね。とても少ないというか、手を動かすのは不可能と思った方がいい数字です。

プレイングマネージャーになるために

マネジメントの割合を減らしたい。でも気をつけること

仮にプレイングマネージャーとして半分は手を動かす時間にしたいなら、マネジメント工数を50%に抑えなければなりません。となると自身＋3人の4名チームが限界ということになりそうです。
思ったよりも少ないですよね。実際もっと大人数で案件を行うことが多いのではないでしょうか。その場合、プレイングマネージャーは諦めなければならないのでしょうか。

もっとスケールさせたい！でも気をつけること

4人チームが限界なんて夢がありませんよね。是非ともスケールさせたいし、スケール可能だと私は思っています。でも絶対に気をつけなければならないことがあります。それは マネジメント工数の総量は変わらない ということです。
マネジメントは難しい業務です。片手間でさくっとやろうなって思ってはいけません。10〜20％の工数は絶対に必要な工数なのです。でもそれを減らさないとプレイングマネジメントは出来ません。

自分のマネジメント業務は減らしたい。でもマネジメント工数は減らない。であれば別の人にやって貰うしかありません。ここはメンバーに少しずつ負担して貰うことにしましょう。

マネジメントを負担して貰う

メンバーにマネジメントを負担して貰う　と聞くと、「そんなの無理だよ！」と感じるかもしれません。それはその通りで、メンバーがプロジェクトマネジメントの知識を持っていればそれも可能かもしれませんが、稀な状態だと言えますよね。となるとどうするか。
私は開発プロセスとルールを整えることでマネジメントを委譲することが出来ると考えています。
代表的なものは朝会です。
朝会では進捗共有などを行なって頂いているのではないかと思いますが、共有フォーマットは事前に決めていると思います。私のチームではスクラムに倣い、昨日やったこと、今日やること、困っていること　を共有するのが基本です。このように朝会というプロセスを設け、そこで共有する内容をルールとして定義してしまうことで、マネージャーが状況把握しやすくなるという効果があります。
またマネージャーだけでなくチーム全体で実施することで、困っていることに対するフォローをメンバーがしてくれることもあります。

朝会が無かったらどうでしょうか。まずは一人一人に状況を聞いて周る手間があります。かかる時間は朝会と変わらないかもしれませんが、朝会はテンポよく出来るため多少マネージャーの工数は減らせます。また誰かが困っていることを知った場合、マネージャー自身で対処するか、対処できそうなメンバーに相談する必要があります。朝会なら知ってる人が名乗り出てくれる可能性が高く、マネージャーが考える手間が省けますね。その代わりチームメンバーとしては拘束時間が多少増えてしまいますが、マネージャーのマネジメント工数を減らす代わりにメンバーにマネジメント工数を持ってもらっている状態と言えます。

朝会は代表例ですが、自分たちの組織に合わせてプロセスとルールを整えることで、そのプロセスとルールを守れば、意識しなくてもマネジメントが行われたり、マネージャーの負担が減る状態 を作るのが、プレイングマネージャーが最初にやることだと思いますし、それが出来ていない状態で手を動かそうと思わない方が賢明です。それが出来たら次のステップとして、チームメンバーの技術面・マネジメント面を伸ばしていくことでチームを成熟させます。これにより冒頭で言った10%〜20%のマネジメント工数を、10％に近づけて行きます。これを続けることで自分が手を動かす時間を確保する。これがプレイングマネージャーだと私は考えています。

プレイングマネージャーは魔法戦士

昔プレイしていたロールプレイングゲームに、魔法戦士という職業がありました。
武器を使って闘うのが得意だけど魔法は使えない「戦士」と、その真逆である「魔法使い」という職業があり、それらのいいとこ取りをした職業です。私はプレイングマネージャーって魔法戦士のような役割だと思っています。
この魔法戦士ですがすぐになれるわけではありません。戦士と魔法使いの両方を経験し、両方をある程度習得しなければなれない職業です。プレイングマネージャーも同じで、専任のプロジェクトマネージャー経験があった方が絶対に良いです。

前述したような仕事をするためには、マネジメントの知識をしっかりと持っておき、絶対に押さえなければならないところを把握する必要があります。
プレイングマネージャーを目指す方は、プログラマからプレイングマネージャーになろうと考えている方が多いように感じていますが、最低限プロジェクトマネジメントの学習は必要で、実際の経験があるとより良いと考えています。

△ プログラマー　→　プレイングマネージャー
○ プログラマー　→　プロジェクトマネージャー　→　プレイングマネージャー

私が考えているキャリアパスは上記の通りです。プレイングマネージャーになりたいと思っている方の中には、専任のプロジェクトマネージャーになりたくないという方もいらっしゃると思いますが、一度向き合ってみて欲しいです。案外楽しさのある役割ですよ。

でも諦めることもある・・

プロジェクトは想定外のことがよく起きます。
特に要件の変更があった場合などは計画の見直しが必要で、マネージャーは再計画に集中すべきです。自分でやる予定だった作業をうまく調整できればいいのですが、残業して頑張ることもあるかもしれません。一時的な負荷上昇は覚悟する必要がある役割であることは覚えておきましょう。

自律的なチームを目指す

自律とは、自分の行為を主体的に規制することだそうです。
自律的なチームというと色々な解釈があるとは思いますが、私は 自分たちでマネジメントができるチーム と解釈しており、プレイングマネージャーがマネジメントを委譲しきり、自分がチームの一員になった姿であると考えています。

その理想系の一つがスクラムのチームです。
スクラムではマネージャーという役割がありませんので自分たちでマネジメントを行う必要があります。スクラムガイドにそれが明言されているわけではありませんが、スクラムイベントを正しくこなすとマネジメントが行われている状態になります。前述したプロセスとルールがしっかりと組まれているのですね。

余談ですがスクラムはミーティングが多いという意見をよく耳にします。Googleで「スクラム　ミーティング」と入れると、「多い」がサジェストされてしまいます。これは間違いです。スクラムガイドには各イベントごとの時間が定義されています。以下の通りです。

スプリントの期間が1ヶ月の場合・・

スクラムイベント	必要な時間
プランニング	8時間
デイリースクラム	毎日15分＝全体で5時間
スプリントレビュー	4時間
レトロスペクティブ	3時間

合計すると20時間で、1ヶ月を160時間だとすると工数の割合で言えば12.5%ほどになります。必要なマネジメント工数の範囲内なんですよね。
チームにマネジメントを移譲するとマネジメント工数が膨らむ印象がありますが、実際はそんなことありません。（不慣れなチームだと最初は膨らむかもしれませんが、それは専任のプロジェクトマネージャーを置いても同じです）
堂々と移譲していって問題ありません。