「育てる」ということ
自己紹介
はじめまして、株式会社Sun AsteriskでPMとして働いている松本陶矢です。この記事はSun* Advent Calender 2024 8日目の記事です。Sun*で、スタートアップの企業様がクライアントの開発案件にて、リードのプロジェクトマネージャーとしてプロジェクトワークに従事しています。あとは社内業務としてPM向け新卒研修の運営に関わったり、新卒内定者向けのフォローアップ面談に参加したり、というような人間です。
最近ハマっていることと言いますか、今年の頭から継続していることがあるのでそれをご紹介します。アニポケ（アニメ版ポケモン）の主人公からサトシが卒業したことをふまえ、改めてサトシ時代のアニポケを全話見直しています。この記事の執筆時点だとXY&Zシリーズまで見ています。累計800話ほど、、思い返すと長い道のりでした。ただ11月15日いっぱいでアマプラでの配信が終了したので結構ショックを受けています。12月からU-NEXTで配信が始まっているので乗り換えを検討しています。
今日のお話
さて、アニポケの話はこの辺にしておいて、本題に入ります。そろそろ「若手」「駆け出し」から「ミドル」になっていく中で、プロジェクトで一緒に働く後輩を育てる、という視点を持つ必要に駆られた経験をしたので、その話をご共有できればと思います。
社会人になる前から、部活やバイトといった場面でも、後輩の育成をしてきましたが、社会人生活における「育てる」は全然違う難しさがありました。そんな中で僕としても気づいたことや学んだことがあったのでこの場に記します。
なお、僕は育成のエキスパートでもないし、数多くの優秀なメンバーを輩出してきた敏腕プロデューサーでもなく、育成の難しさに直面したどこにでもいる社会人3年目くらいの人なので、その前提でお読みいただければ幸いです。
まず前提のお話ですが、僕はクライアントワークでシステム開発をしています。システム開発に関わらずどの仕事もそうだとは思いますが、要件が変わった・仕様に齟齬があった・予期せぬ不具合が発生したなど、イレギュラーな対応がそれなりに求められます。
僕が担当しているプロジェクトでは以前から後輩が入っていましたが、後輩に見てもらっている部分でイレギュラーな事象（課題）が起きた時、自分が助けに行くというアクションで進めていました。理由としては、課題解決を最優先としていたからです。課題が発生しているとプロジェクト進行に支障が出るため、なるべくそのタネをなるはや摘んでいました。恥ずかしながら、「後輩が課題解決できるようにサポートする」といったことを考える余裕は持てていなかったです。
ただ、プロジェクト規模が徐々に大きくなり、それに応じて僕に求められることの幅が広がっていく中で、「このままの体制だといつかキャパオーバーになるのでは？」と感じてしまいました。自分一人の体でできることは限られており、自分と同じことができる人・自分よりもできることが多い人を増やしていかないとプロジェクト規模が頭打ちになる。また、自分自身がより大きな仕事をするという意味でも、今自分が行なっている仕事を他の人に任せていくことが求められると考えました。
ということで、同じプロジェクトに入っている後輩を「自分と同じことができる人」に持っていくべく、育てることにチャレンジをすることに決めました。
※今まで育成を放置していたわけでは決してないですが、明確に目標を立てて育成を試みた、という意図です。
まず、どのような状態になれば「成長した」と言えるのか、その状態を達成するために何をすべきなのかを簡単に整理しました。
> どのような状態になれば「育てた」と言えるのか
これはシンプルに「できなかったことができるようになったこと」と定義しました。その上で、
> その状態を達成するために何をすべきなのか
これもシンプルに、「今までやったことないことを任せていく」と定義しました。未経験のことを任せることでできる業務が増えていくというのはもちろん、思考回路がアップデートされ、プロジェクトを進める上で必要な視点が増え、視座が上がっていくからです。
と、シンプルな整理はできたのですが実行するのはなかなか難しい。というのも、行動に移すとなると後輩に負荷をかけることになるので「嫌じゃないかな」「辛くならないかな」と過保護になっている自分がいました。ただ、過保護になっている自分を見た時に「後輩のことを気にかけているようで、実は自分に対する甘えなんじゃないか？」とも思いました。自分と後輩の関係値が悪くなることでプロジェクトの進行に支障は出るかもしれない、という話はありつつ、そもそも嫌われることに対して恐れているのでは？と。ただ、プロジェクトや会社のことを考えた時に、こんな理由で育成を諦めるのはあまりイケてないなと思い、自分自身の殻を破るという意味でも実行に移そう！と腹を括りました。
まずやったことは、そもそも成長したいの？の意思確認です。せっかく仕事をするなら成長したいよな〜と僕は思うのですが、世の中全員がそうとは限らないし、後輩に負荷がかかることにもなるので、ここは丁寧にコミュニケーションを進めました。最初に上で書いているような「プロジェクトを大きくしていく上で〜」の背景を伝え、その上で「今までやったことのない業務を任せていくことになる。負荷がかかるが君の成長にもつながると思うがどうか？」という問いを出しました。そして、「3年後どうなっていたい？」みたいな話を交えつつ、成長したい意思を確認することができました。
次は業務の任せ方を変えていきました。ここはかなり苦戦し、試行錯誤を重ねた部分です。
まずは今まで通り、タスクを切って渡すという部分は変えず、以前よりは粒度の荒い状態でタスクを渡すようにしました。ただこの進め方だと、頭ではダメだと思っていても、イレギュラーが起きたタイミングで介入してしまう。タスク単位で仕事を渡すとなると、後輩がやっていることを自分が全て把握できてしまいます。プロジェクト進行の観点だと健全ではありますが、自分がすぐに介入できる余地が残ります。僕がお節介な性格なこともあり、介入しないように我慢するのは難しいと判断しました。
ということで、タスクを渡すのではなくもっと荒い粒度で仕事を任せることにしました。僕が担当しているプロジェクトではプロジェクト内にサブプロジェクトが幾つか走っているのですが、そのサブプロジェクトの進行を丸っと任せることにしました。サブプロジェクトを任せるタイミングで、「プロジェクト進行で必要なことについて、すべての初動を任せたい。聞きたいことはなんでも聞いていいから、僕は居ないものと思って最初にアクションを取ってほしい。」と伝えました。少し危機感を煽りすぎたかな？と思いつつ、このことを伝えてから「まずは最初に後輩に動いてもらう→業務を進める上でわからないことは僕に聞く→業務を完了させる」というルーティンができ始めました。そして自分が初動を取らないといけない以上、何をどうすべきか・前うまくいかなかったことをどう乗り越えられるかといったことも考えられるようになったのか、後輩の動きも良くなっていきました。業務の質が少しずつ上がっていき、プロジェクトにおいて必要な作業を関係者に確認してそれを推進していくというドライブ力がどんどんついていくのが目に見えました。
業務そのものの質をあげていくことも大事ですが、まずは旗振り役としてプロジェクトを推進するマインドセットを持ち、そのマインドセットを元に行動に移していくことがプロジェクトマネージャーに求められる事と考えています。今回の試みにおいて、後輩に対して上記のようなマイドセットをインストールできたという意味では、成長につながったのではと思います。
最後に
環境が人を変えると言いますが、今回のケースだと本当にそうだなあと実感しています。自分で動かないといけない状況を渡すことで、自律的な動きをするようになったのかな、と思っています。もちろんこのやり方は万能ではないと思いますが、今回は良い方向に転んだと思っています。
今一緒に働いている後輩は12月でプロジェクトを離れるのですが、今回の経験を踏まえて次のプロジェクトでも頑張ってほしいと思います（遠い目）。
さて、明日は大平さんの「Teamで行ったPM勉強会」についての記事です。お楽しみに！