お疲れ様です！
アドプラットフォーム事業部でユニットマネージャー（以下UM）をしています、23卒の伊藤です。
エンジニアの業務に加えて、7月よりユニットのマネジメント業務や組織の運営を任せていただいております。
私が担当しているユニットは技術改善チームの中の一組織というロールを持っており、とあるプロダクトの技術改善業務を主に取り組んでいます。
今回は、入りたてのエンジニアが新卒から今まででプロジェクトマネジメントまわりで取り組んだこと・学んだことについてお話しできればと思います。
マネジメントに興味のあるエンジニアの方の参考となれば幸いです！
なぜマネジメントの道へ？
きっかけは、11月に今後のキャリアについて考える研修に参加したことでした。
この研修ではまず、今まで業務を通じて楽しかったこと、やってよかったことを出しました。
成功体験やポジティブに感じた場面を抽象化し、自分が業務中に大切にしていること上位3つを洗い出しました。
私が挙げたキーワードは「他愛性」「達成」「共創」です。
次に、配属されてからこれまでにできるようになったことを整理しました。
アドプラットフォーム事業部のエンジニアは、配属直後はコードの読み書きが主な業務となります。
日々の業務を通じて得たスキルや考え方について大別し、まとめました。
これらを上長と共有し、上長が期待していることを加味した上で、今後のキャリアについて相談・すり合わせを行いました！
その結果として、上長からUMという道についてご提示いただいたこともあり、マネジメントの道への関心が高まりました。
当時のUMはスクラムマスターやプロジェクトマネジメント、ピープルマネジメントを中心に活動していましたが、自分の今後のキャリアとしては技術的な知見も活かした新しいUM像を目指していくことにしました！
取り組み
研修以降は自分のキャリアを見据えて、プロジェクトをリードする動きを行っていくようになりました。
初めてのプロジェクトリード：プロジェクトA（11月〜2月）
キャリアの研修で自分の今後について考えているなか、チームでは新しくプロジェクトがはじまりました。
内容としては、今まで進めていたプロジェクトを再定義するようなもので、既存プロジェクトをより高速化する提案をさせていただいていたことがきっかけとなりました。
同時に、新しいプロジェクトをリードする動きを任せていただき、プロジェクトの進め方の策定や進捗管理・設計を担当しました。
前に動いていたプロジェクトの課題に対して共通認識があったことに加えて、自分が発信していた内容へご理解をいただいていたこと、やってみようとチームが温かく迎えてくれたこともあり、事前にチームで実現したいことの認識は合っていました。
そこで次に設計を行うことになり、私がファシリテートをする機会をいただきました。
当時、スクラムイベント以外の会議について初めてのファシリテーションでした。
アーキテクチャの設計についても明確であったため、スピード重視でとりあえず会議の時間だけを設定させていただきました。
しかし、そこで初めての失敗がありました。
初めての失敗：設計をどう進めていくかがわからない
深く考えずに会議だけを設定した新米リーダーの私は、ゴールだけを明確にした状態で、設計の際に具体的に何を話すかについて何も考えていませんでした。 会議中頭が真っ白になってしまい、シニアのメンバーの方と相談し（ほぼ丸投げし）た結果、まず以下をやることにしました。
- 具体的に達成したいこと・やってみたいことの発散とすり合わせ
- すり合わせた内容を実現するための必要事項出し
結果として設計はうまくいきましたが、ここで初めて私は会議の準備やファシリテーションの重要性について痛感しました。
具体的には以下のことを学ぶことができました。
- 設計時に効果的なもの
- 期待値やアイデアのすり合わせ
- 実現可能性と優先順位の判断
- 準備不足の会議を設定することのリスク（プロジェクトマネジメントの重要性）
その後、上長とともにタスク化やゼロベース見積もりを行い、開発を始めました。
プロジェクトの進行は順調
プロジェクトの進行自体には大きな問題はありませんでした。 振り返ってみると、成功要因としては以下があったかなと思います。
- 何をやるか明確にしている + 期待値を合わせている
- それぞれが何をやるかについてブレずにいった
- 進捗管理がしやすかった
- チーム内でのコミュニケーションはもちろん、営業の方やPdMと連携しやすい体制となっていた
プロジェクト完了後、影響があるエンジニア全員を集め、プロジェクトの成果についての共有会を実施しました。
この取り組みでは、よりよい会議となることを強く意識して進行等を自分で決めました！
初めての成功：プロジェクト共有会の実施
プロジェクト共有会の目的は、影響があるエンジニア全員にプロジェクト成果を共有することでした。 具体的な目的は以下のように決めました。
- プロジェクトの見込み効果や設計、その後の運用方法を知ってもらう
- プロジェクトによる影響・効果のすり合わせ
- フィードバックをいただき、改善サイクルを回す
共有会自体があまり実績のない取り組みで、時にはチームメンバーと壁打ちをしながらやり方を模索しました。
そのなかで特にうまくいった取り組みは次のとおりです！
- 自由な発言を引き出すため、Slackで「実況スレ」を作成した
- 参加人数が多かったため
- 伝えたい内容に強弱をつけ、資料・口頭双方において内容にメリハリを与えるよう心がけた
- 共有内容が多かったため
結果として、共有会は良い形で開催できました！
ここで試行錯誤できたことは特に印象的でしたし、この経験は今後に大きく繋がったと思います！
プロジェクトAを振り返ってみて
ここまで深くプロジェクトに携わったのは初めてで、影響範囲や巻き込んだ人数も大きく、一年目からこのような経験ができたのは貴重だったと思います。
いろいろ大変なことはありましたが、総じて楽しむことができ、キャリアの研修で出した価値観とズレがない事を再確認できました！
リード部分が大きく：プロジェクトB（3〜5月）
その後小さなプロジェクトを上長と相談しながらリードさせていただき、次のプロジェクトではプロジェクトマネジメントの多くを任せていただきました。
もちろん、技術的な知見が必要な場面ではチームメンバーに、プロジェクトを管理する上でわからないことがあれば上長に相談をさせていただきました。
やったこととしては以下となります。
プロジェクトBを通して、所属しているチームでの基本的なプロジェクトの進行について携わり、学ぶことができました。
うまくいったこと
うまくいったと思う点は3つあります。
- 強い意識をもって会議の準備ができた
- 挑戦を奨励できた
- 技術的な挑戦
- SWIFTメソッドの実施
- 振り返りを行い次のプロジェクトで意識したいことを洗い出せた
特に1つ目についてはプロジェクトAでの失敗をもとに、会議は準備が一番大事ということを強く意識していました。
会議ごとに、会議のゴール（Outcome）や参加者に求める姿勢（Role）を定義し、やること（Agenda）やルール（Rule）を決めました。
いわゆるOARRです。
会議のフレームワークなどプロジェクトマネジメントについて更に知りたいと思えるようになったことも、前プロジェクトで失敗して良かったところだと思います！
失敗したこと
一方で、失敗したと思う箇所は主に2点ありました。
- プロジェクトの定義が見返されずにアップデートがされなかったため、プロジェクトがぶれた
- 想定より開発が伸びているにも関わらず、他の優先度の高いプロジェクトを優先する選択肢を全く意識していなかった
これらのことについてプロジェクトの振り返りでメンバーに改めて共有し、学び・アクションにつなげることができました！
独り立ち：プロジェクトC（5月〜）
プロジェクトCについては、自らが裁量を持ってプロジェクトをリードしています。
本プロジェクトは、開発者向けの新機能を作成するといったもので、MVP開発により進行をしています。
具体的には下図のような感じです。
このプロジェクトは、他プロジェクトとの優先度も加味してPhase 1完了後に一時停止することとしました。
しかし、MVP開発でプロジェクトを進める選択肢をとったことで新機能がすでに使える状態となっており（価値を提供できている）、一旦止める選択肢を取れた点についてはうまくいったと思っています。
他にうまくいった点はいくつかありました。
- 会議の進め方の選択肢をたくさん増やせた
- チームメンバーに合った会議のあり方を模索できた
- プロジェクトの定義を振り返り、再定義する機会を定期的に入れている
- 価値を最大化するために、機能検証をお願いするチームと柔軟に連携することができた
プロジェクトを進めるにあたり、関係者との密な連携の重要性を再認識しました。
一方、相手が知っていそうなこと・知らなそうなことを意識した上で会議中に何を伝えるべきかを絞るべきだった、ということを改めて学ぶことができました。
今までの取り組みを踏まえて
以上の取り組みから学べたことは多くありました。
苦労したこと
プロジェクトをリードする中で苦労したこととしては
- 会議を主催する上での進行が難しかった
- 想定外のことへのアドリブ力を試される場面が多かった
- プロジェクトの進め方を変更する必要があった
- 発言が相手に伝わらなかった
- 想定外のタスクがでた
- 個人としてたくさんタスクを抱えた
といったことがありました。
悩む場面・どうしようか考える場面は数多くあり、日頃経験したことから学びをできるだけ取りこぼさないようにしました。
日頃から経験したことをKPTのフレームワークでアウトプットし、アクションを起こすことで改善サイクルを回し、同じような場面でパフォーマンスを最大化するような工夫をしました。
また、一人で抱え込まず、壁打ちや1on1等で人と相談することは私にとってとても効果的でした。
人に伝えるステップを踏むために言語化というアウトプット作業が入るため、頭が整理されたことが要因としてあるかなと思っています。
学び・得られたもの
学んだことについては大きく2つに大別できます。
プロジェクトの進行について
まずプロジェクトをリードするにあたり、プロジェクトマネジメントのノウハウを含めプロジェクトの進行のしかたについて学ぶことができました。
また、配属当初と比べ、チームが抱えるプロジェクトに対する解像度が上がり、当事者意識が備わったことも大きな成果であると思います。
コミュニケーションや会議の準備に大きくコストをかける
また、プロジェクトを進めるにあたり他の方を巻き込むことが多く、コミュニケーションや会議の準備に大きくコストをかける大切さを学びました。
具体的には、以下のことを意識するようになりました。
- 会議の設計
- 期待値のすり合わせ
- 相手が持っている知識・メンタルモデルを想像する
- 少しでも認識のズレ感を覚えたら認識合わせをする
同時に、日々の行動を振り返り改善サイクルを回すことを強く意識するようになりました。
現在の取り組み
UMとして、テクニカルマネジメントやプロジェクトマネジメント、ピープルマネジメントなどを通してユニットのパフォーマンスを最大化させていきたいと思っています。
背中で魅せるタイプのマネージャーではなく、
- ユニットメンバーと肩を組みながらナビゲートを交え伴走する
- 場面に応じて変革型リーダーシップを発揮する
ようなマネージャー像を目指しています。
このようなUM像を目指すにあたり、業務の中で大きく感じている課題は主に3つあります。
- メンバーの様子を見ていたりと、意思決定力が弱い
- コミュニケーション時に付加情報を与えすぎて、一番伝えたいことが薄れる
- 関心ごとが多くなりすぎる
小さなことからコツコツと、日々の経験から改善サイクルを回し、上記の課題を解決しつつ自分が目指すUM像に近づけたらなと思います！
最後に
本記事では、新米エンジニアが直近でプロジェクトをリード・マネジメントした体験談と乗り越え方、学んだことについてまとめました。
プロジェクトマネジメントに携わっている・興味がある方にとってワクワクするような記事となっていれば嬉しいです。
