マネージャーがボッチプロジェクトにジョインした話

こんにちは。第1開発部でマネージャーをしているS.Oです。

ボッチプロジェクトにジョインって何よ？って感じですが、誰もいないプロジェクトに加わりました。肩書詐称を疑われてしまいそうですが、こうなった経緯や思うことを綴っていきたいと思います。

その前に、皆さんの中でマネージャーという役割はどんなイメージでしょうか？世の中には〇〇マネージャーってたくさんあると思いますが、役割イメージってそれぞれ異なりますよね。

まずは、KENTEMの開発部におけるマネージャーについてお話ししたいと思います。

この記事の執筆時点でKENTEMの開発部におけるマネージャーはエンジニアリングマネージャーと呼称されています。

メンバーのマネジメントをするだけでなく、マネージャー自身も1人の開発者としてエンジニアリングに携わります。なので、フルパワーで開発業務をするのは難しくなりますが、マネージャーになっても開発には携わり続けることができます。

一般的にデリバリーに軸足を置くプロダクトマネージャーに対して、エンジニアリングマネージャーはピープルマネジメントに軸足を置くといわれます。弊社でも同様で、人事評価権限があったり、エンジニアの採用に関わったりしています。

私の携わる製品では優先度が高く、なるはやで対応しなければならない要件があり、プロジェクトメンバー総動員で当該要件に着手することになりました。ところが、製品を使っているユーザー様からの要望も多く寄せられてくるので要望対応も定期的にリリースしていく必要があります。

客観的には詰んでいるようにも見えるのですが、そこは「やれる方法を考えよう！」となりました。まずは、「なるはや要件」について考えてみました。

私がプロジェクトを主導して「なるはや」をやるのが一番近道ではあるのですが、目下の課題はプロジェクトメンバーがあまり詳しくなく属人化していることでした。今後の展開も踏まえ、メンバーには私以上に詳しくなって欲しいという思いがありました。

そこで私は過去の知識だけを活かすかたちで要求保持者として「なるはや」に関与することにしました。こうして、要望の対応を私が1人で頑張るという構図ができあがってしまいました。

ではここでプロジェクトメンバーを紹介したいと思います。

プロジェクト開始直後は私の属人化した知識を頼られることもあり、わからないことも多かったため進捗が停滞することもありましたが、徐々にメンバーに知識が蓄積されることで属人化知識に頼ることも少なくなり、自分たちでいろいろ考えてやるようになりました。

そして、なによりもプロジェクト組織の構成が変わったように感じます。

これまでは先輩後輩関係の階層構造になっていましたが、ボッチ後はAさん・Fさんを中心に円環構造になることでコミュニケーションが円滑に進むようになりました。

「なるはや」プロジェクトはまだ道半ばですが、徐々に上手く回り出してきました。回り出すと共に私の関与は少なくなります。これはつまりメンバーの成長なのですが、嬉しいのと寂しいのと半々の感情になってしまいます。

ボッチプロジェクトの進捗ですが、これはこれで安定しない。理由は単純で私が実装できないと進捗しません。役割上、会議や部門の作業は発生してしまうので、実装時間を作り出してこなしていく必要性がありました。

否が応でも時間内でタスクをこなしていくことになりますので、瞬間的に集中して作業を行うというなかなか貴重な経験ができています。とはいえ、タスクが完了できるかどうかは別のお話です。

ボッチになってみて「中」と「外」で気づきがありました。

メンバーの成長 → 全てをメンバーに託して離れてみるのもイイ

己の程度を知れた → 自分一人で出来ることは限られている

いつものメンバーでいつものようにプロジェクトを回すのも良いですが、たまには敢えてボッチることで自他共に得られるモノがあると思います。変えることで見えてくるモノがあります。

「自分がいないと回らないかも？」って考えがちですが、意外と自分のエゴだったりするのかもしれません。

最後まで読んでいただきありがとうございました！この記事が少しでも何かのお役に立てたら幸いです。

下記は記事の執筆時点での弊社コーポレートスローガンです。 KENTEMは様々な拠点において変化を求めてチャレンジする人を求めています。是非下記のリンクからご応募ください。