この記事はenechain Advent Calendar 2025の1日目の記事です。
はじめに
こんにちは！enechainでエンジニアリングマネージャー(以下、EM)をしているtaniyarnです。 今年もこの季節がやってきましたね！enechain Advent Calendar 2025の記念すべき1日目です！
2025年11月、私は1年間の「見習い期間」を経て、正式にEMを拝命しました。 始まりは2024年10月。 eSquare Liveというプロダクトのリリースと同時に、私はEM見習いという役割になりました。 エンジニアリングマネージャーの4領域の内、ピープルマネジメントを除く、テクノロジーマネジメント、プロジェクトマネジメント、プロダクトマネジメントの領域を引き継ぐ形でのスタートでした。
eSquare Liveは、簡単に言うと株取引のような板画面上で電力の卸取引ができるプラットフォームです。 株取引で銘柄があるように、電力にも様々な商品があります。 商品に対して、注文を出し、価格がマッチングすると約定が成立します。
正直に言うと、この1年は手探りの連続でした。「マネジメントとは何か？」という問いに悩みながら、泥臭く目の前の課題と向き合い続ける毎日でした。 この記事では、そんな1年前の自分、そして同じようなフェーズで悩んでいる方に向けて、当時の自分に伝えたかった3つのことを失敗談を交えながらまとめました。
プロジェクト管理の型を使い分けよう
失敗談
最初の数ヶ月は数週間単位の短期プロジェクトが多く、比較的スムーズに進めることができました。 いくつかのSmall Winを得た私は「EM業は大変って聞いてたけど全然そんなことないな」と余裕をぶっこいていました。
そんな中、enechainのクリアリング基盤である「eClear」の大幅な改修が決定しました。 その改修により、eSquare Liveも実装を大きく変更する必要があり、非常に大きなプロジェクトが動き出すことになります。 eSquare Liveのコアとなる注文・約定ロジックに大きな変更が必要で、プロジェクトの規模感もこれまでとは桁違いに大きなものでした。 また、次に挙げるような様々なチャレンジがありました。
- eClearを開発するチームと依存関係が強いこと
- 要件に未確定な部分が多いこと
- 社内で決められたリリース期限があること
- 社内的にも非常に注目されているプロジェクトであること
いくつかの短期プロジェクトで成功体験を積んでいた私は、この大型プロジェクトも同じような進め方でいけるだろうと高を括っていました。 これまでの進め方と同様に、決まっている仕様に対してタスクを洗い出して、実装を進めていきました。
開発から2ヶ月が経った頃、未だに要件が固まらず、リリースは到底間に合わない状況に陥りました。 重要なプロジェクトであったため、私はかなり精神的にすり減ってしまい、元気が取り柄な私のはずが、メンバーから「最近のたにやんは元気がない」と言われる事態にまでなってしまいました。 リリース日の延期を余儀なくされ、チームメンバーやステークホルダーに多大な迷惑をかけてしまいました。
そんな問題だらけの状況をCTOや先輩EMに相談しました。 アドバイスを受ける中で「リスクを洗い出して、先んじて手を打ち、不確実性を減らすこと」、「大規模プロジェクトではガントチャートやバーンダウンチャートを引き進捗を見える化すること」というプロジェクトの管理手法ができていないことに気づきました。
そこで、教えに沿って、要件の未確定部分を洗い出し、ステークホルダーと合意形成を図ることに注力し、ガントチャートを引いて進捗を可視化しました。
もがきながらも、メンバーのハードワークにも助けられ、なんとか見通しが立ち、感動のリリースを迎えられました。
学びと実践
最も痛感したのは、「開発の粒度やスケールによって、最適な進め方は全く異なる」という事実です。 当初の私は、どんな案件も同じようなフローで回そうとしていました。 プロジェクトは様々な性質を持つため、同じ管理手法で全てをカバーするのは不可能です。
私が最初に担当した大型開発では、この「型」の選択を間違えました。 仕様が固まりきっていない状態で走り出してしまい、タスクの洗い出しが後手に。結果、スケジュールの見通しが立たなくなるという苦い経験をしました。 この経験を通じて、プロジェクトの特性に応じた管理手法を選択し、柔軟に適用することの重要性を学びました。 上手くプロジェクトをマネジメントできていない場合は、選択している「型」が適切かどうか、一度立ち止まって見直してみることをお勧めします。
実際には以下のような使い分けが必要でした。
分類軸: 期間 ~ 短期(数週間) vs 中長期(数ヶ月~半年)
数週間で完了する短期案件では、仕様をスピーディに固め、タスクを分解し、1つずつ迅速に進めることで十分です。 一方で、数ヶ月以上かかる中長期案件では、ガントチャートやバーンダウンチャートによる進捗の可視化と計画の維持が不可欠です。 週単位で進捗をチームに共有し、今のペースで間に合いそうなのか、もし間に合わない場合はどういった打ち手があるのかを常に考え続ける必要があります。
分類軸: 依存関係 ~ 自チーム完結 vs 複数チーム依存
自チームで完結する案件では、ステークホルダーも限られているため、要件の調整コストは低く抑えられます。 他方で、複数チームに依存する案件では、ステークホルダーを明確にし、依存関係の調整を早期かつ継続的に行うことが重要です。 要件がなかなか固まらない場合は、ステークホルダーを集めて合意形成を図ることが最優先となります。 プロジェクト初期段階での握りが甘いと、後々大きな遅延につながることが多いです。
分類軸: 要件の確実性 ~ 未確定要素が少ない vs 未確定要素が多い
要件の未確定要素が少ない場合は、詳細な仕様設計も特段問題なく進められます。 しかし、要件の未確定要素が多い場合は、要件の決定の優先順位付けと管理が必要になってきます。 何が決まっていないのか、どの要件の優先順位が高いのかを明確にしましょう。 データベースで管理し、チームメンバーと定期的に認識を揃え、ここまでは開発可能、ここからは要件が固まり次第対応、という形で進めるといった工夫が求められます。
分類軸: 期限 ~ 期限無し vs 期限有り
期限がない場合は、開発状況を見ながら柔軟にリリース計画を立てることができます。 一方で、期限がある場合は、開発要件の優先度順位付けとリリーススコープの明確化が非常に重要になってきます。 開発を着手する前に、MoSCoW法などを活用し、要件の優先順位付けを行い、リリーススコープを関係者で合意しましょう。 進捗状況を見ながら、必要に応じてスコープを調整することで、遅延リスクを管理します。
徹底的に違和感を拾おう
失敗談
先ほどのプロジェクトの初期時点で、実はメンバーから違和感が上がっていました。 具体的には、以下のような違和感です。
- 仕様がふわっとしたまま実装を進めていないか？
- 要件が固まっていない部分が多すぎないか？
- リリース計画、これ本当に間に合うの？
こうした違和感に対して、私は十分に向き合えておらず、立ち止まることなく「やれることからやっていこう」の精神で突き進んでしまいました。 蓋を開けてみると、それらの違和感は的中しており、要件が固まらないまま開発を進めたことで、大幅な遅延を招いてしまいました。
違和感に対して、もっと早く向き合い、本当に解決できないのかを徹底的に考え抜き、対策を高じていればと強く後悔しました。
学びと実践
EMという役割に就くと、現場の小さな違和感を見逃さずにいることが重要だと感じます。 違和感の背後には何かしらの問題が潜んでいる可能性が高く、こうした問題は時間が経てば経つほど、深刻化することが多いです。
チームが直面している違和感を検知する仕組みを作る
自分が感じている違和感だけではなく、チームメンバーが感じている違和感を常にキャッチアップする仕組みを作ることも重要で、2つの方法を実践しています。
1つ目は、スプリントの終わりにKPT形式でのレトロスペクティブを実施しています。 挙がったKeep、Problemの中で、チームメンバーで投票し、票を多く集めたテーマについて深掘りをします。 Tryを考え、データベースに記録し、次のスプリントで実施することで、継続的な改善を図っています。
2つ目は、1on1ミーティングでのキャッチアップです。 週に一度、各メンバーと1対1で話す時間を設け、レトロスペクティブでは拾いきれない個々の違和感を吸い上げています。 小さな違和感であっても見逃さず、その場で一緒にどうすれば解消されるかを考えています。 また、議事録を用意し、Next Actionを明確にすることで、1on1の効果を最大化するようにしています。
違和感の根本原因を探る
対策を考えるのに、根本原因を考え抜くということが非常に重要です。 前職のトヨタの教えである「5Why(なぜを5回繰り返す)」の考え方が参考になりました。 表面的な違和感を起点に、なぜそれが起きているのかを深掘りし、根本原因を特定します。 例えば、「仕様がふわっとしている」という違和感に対しては、なぜ仕様が明確でないのか、なぜ関係者間で合意が取れていないのかを掘り下げていきます。 そうすることで、問題の本質にたどり着き、適切な対策を講じることができます。
失敗を恐れずに改善を続ける
もう1つ大事なことは、試行錯誤を恐れないことです。 問題に対して明確な対策を講じることが難しい場合もあります。 小さな改善策を試し、その効果を検証するアプローチが有効です。 現状よりは良い状態を目指し、失敗しても良いから工夫を続けることが、最終的には大きな改善に繋がります。
本は課題ベースで読もう
失敗談
EM見習いになりたての頃、何冊かマネジメント関連の本を読みました。 しかし、読んだ内容を実践に落とし込むことができず、本に書いてあることは抽象的かつ理想論で、あまり参考にならないなと感じていまい、読むのをやめてしまいました。
eSquare Liveチームは2つのチームで構成されており、もう1つのチームのEMは非常に経験豊富な先輩EMでした。 2チーム合同でデイリーミーティングやレトロスペクティブなどのイベントを実施している際に、先輩EMの振る舞いや意思決定の質の高さに日々力の差を感じていました。
これは経験の差だと割り切り、自分にはまだまだ時間が必要で、焦る必要はないと自分に言い聞かせていました。
そんな中、先輩EMから2つのフィードバックを受けました。
- EMとして課題解決の引き出しをさらに増やしていくと良い
- 他チームの事例や社外の資料・書籍などからもプラクティスを学んでいくと、さらに成長できる
このフィードバックを受けた時に「マネジメントとは技術である」という言葉を思い出しました。 もちろん経験から学べることはたくさんありますが、経験だけに頼るのではなく、本から学ぶことも重要であり、先輩たちも本から学んだ知識を実践に落とし込んでいるのだと気づきました。
学びと実践
目的を持たずに本を読むのは非効率だと感じました。 体系的に学ぶことも大事ですが、目の前の課題を解消するためのヒントを探す読み方がオススメです。
また、あくまでも本の内容は「処方箋」の1つで、それをどう実践に落とし込み、チームに適用するかは状況次第です。 必要な時に取り出せる引き出しを増やすイメージで、先人の知恵を活用しましょう。
目の前の課題をリストアップする
- 1on1が雑談になってしまう
- プロジェクトが遅延している
- フロントエンドのタスクが特定のメンバーに偏っている
これは私が直面した具体的な課題です。 こうした目の前の課題に対して、具体的な解決策を見つけるために本を読みました。
上記の課題に対しては、具体的なアクションに落とし込み、実践しました。
- 議事録を用意し、事前にメンバーとEMで内容を記載し、Next Actionを決める
- 要件定義の時点でMoSCoW法を用いて優先順位をつけ、リリーススコープを明確化する
- モブプログラミングを導入し、ナレッジ共有とタスクの属人化防止を図る
これらにより以下の効果が得られました
- 1on1での議論が深まり、レトロスペクティブでは拾い切れないメンバーの課題解決に繋がった
- 大型プロジェクトをスケジュールを守って開発完了できるようになった
- フロントエンドのタスクを複数メンバーで対応できるようになり、チームとしての開発速度が向上した
大体自分が抱えている課題は、過去の誰かも経験していることが多いので、本を読むことで解決策のヒントが得られます。 ここで注意しないといけないのは、本の内容をそのまま鵜呑みにせず、自分のチームに合う形でアレンジすることです。 小さく試して、効果を検証して、継続するのか、他の方法を試すのかを判断しましょう。
ただの知識ではなく実践に落とし込もう
本を読んで得た知識を実践に落とし込むためには、アウトプットの機会を設けることが重要です。 私の場合は、読んだ内容をベースに先輩EMと1on1で壁打ちをし、学んだことのアウトプットを実施しています。 抽象的な知識を先輩EMの経験と照らし合わせることで、より実践的な理解を深めることができています。
加えて、本を読むことが苦手な私でも、先輩EMとの約束という強制力が働き、読書の習慣が身に付きました。
おわりに
EM1年目を振り返ると、うまくいったことよりも「知らなかったこと」「できなかったこと」のほうが圧倒的に多かったです。 ただ、泥臭く前に進めていくうちに、どんなに困難な壁であっても、周囲の力を借りながら乗り越えられるという自信がつきました。 また、マネジメントは技術であり、学び続けることで必ず上達するという確信も持てました。
2年目もまた、新しい「わからないこと」に出会うはずです。 一歩一歩の成長を楽しみながら、EM道を歩んでいきたいと思います。 自分の成長がチームの成長に、ひいては会社の成長に繋がることを信じて、これからも挑戦を続けていきたいと思います！
明日はakizhouが、dbt Fusionについての記事を出すので乞うご期待！
enechainでは日本のエネルギー業界をテクノロジーで変革する仲間を募集しています。 絶賛EMも募集中なので、ご興味がある方はTech Recruit Portalからご応募ください！
