こんにちは。SmartHRのESPプロダクト開発本部の栗崎です。2025年6月に入社し、10月よりチーフ1（プレイングマネージャー）を務めています。
本稿では、入社1年目の新米プレイングマネージャーが、経験豊富なスペシャリストがそろうチームで「チーフ」として試行錯誤したプロセスを共有します。私は「このメンバー2の中で、まだ未熟な自分がリーダーをやっていいのか」と不安を抱えながらも、チームと協力しながらチャレンジし、自己成長につなげてきました。その過程をありのままに書くことで、キャリアパスに悩むエンジニアの方や、リーダーの役割に不安がある方の参考になればうれしいです。
目次
チームの状況
チーム構成は以下のとおりです。
- プロダクトエンジニア: 4名
- チーフ（私）: 1名
- メンバー: 3名
- プロダクトオーナー: 1名
プロダクトエンジニア3名は、経験豊富なスペシャリストのメンバーです。 担当プロダクトは以下の2つです。
- 汎用申請
- 2025年6月にリリースしたプロダクトで、社内の稟議や申請・承認業務をペーパーレスで効率化できるプロダクト
- ワークフローミドルウェア
- 他のオプション機能が、申請・承認機能を簡単に組み込めるようにする共通基盤
- 汎用申請もクライアントアプリとして、ワークフローミドルウェアを利用している
なぜチーフをやろうと思ったのか
入社して日が浅い私が、なぜチーフをやろうと思ったのかを振り返ります。
入社以前は、小規模チームのプロジェクトリーダーを担当していました。チームの立ち上げやスクラム開発の導入、目標設定のサポートなどを経験し、一定の成功体験があったため、キャリアとしてもマネジメントスキルを伸ばしたいと考えていました。
入社後、私たちのチームではマネージャー3がチーフを兼務しており、現場のプロダクト開発からは一歩引いた立場でチーム運営をしていました。チームメンバーはプロジェクトマネジメントもできる優秀なプロダクトエンジニアばかりですが、スペシャリスト志向のメンバーが多く、誰がリードするかが明確でない場面もありました。例えば、チームビルディングやリリース後の振り返りは、レトロスペクティブで改善案として挙がってからチームで対応する流れが主で、能動的に「やっていこう」と声を上げる役割が固定されていない状態に感じました。
こうしたチーム状況の中で、チーフ就任の打診をいただいたこともあり、自身のマネジメントキャリアを形成するために挑戦することを決めました。
見えてきたチームの課題
チーフとして活動を始めた2025年10月、チームは6月末に初期リリースを終え、運用フェーズに入っていました。日々のスクラムイベントや運用の中で話題に上がっていた点を整理し、まずは以下の課題の着手から始めました。
運用フローが未整備
問い合わせ対応、アラートのトリアージ、インシデント対応の流れが整っておらず、利用ユーザーが増え、有事の際に混乱する懸念がありました。
スクラムは回っているが、次の改善テーマが見えにくかった
レトロスペクティブで課題発見からの改善案を実践し、PDCA（Plan-Do-Check-Act）は回せている感覚はありました。しかし、あくまでスポットが当たった問題に対処しているだけで、本質的な改善が欠けている感覚がありました。チームとしても、何が真の課題なのかが見えていないこと自体が課題でした。
性質の違う2つのプロダクト目標を計画通りに進められない
「汎用申請」と「ワークフローミドルウェア」という、関与するステークホルダーが異なる2つのプロダクト目標を並行して追う中で、優先度判断が難しくなっていました。一方の推進に集中すると、もう一方が計画通りに進められない状況が生じていました。計画よりも工数がかかっても進めざるを得ない状況もあり、結果として2つのプロダクト目標が計画通りに進められない状態が続いていました。
試行錯誤
ここからは、上記に挙げた課題に対し、どのようにチームで取り組んできたかを紹介します。私は「一人で答えを出さなければ」と力んだ場面もあれば、周囲に頼ることで前に進めた場面もありました。
インシデント対応フローの整備 —— インシデント対応避難訓練の実施
リリース後の運用を見据えると、インシデント対応の際にチームが冷静に動ける状態を作る必要がありました。私は、想定シナリオを作り、ステークホルダーやチームメンバーと一緒にインシデント避難訓練を実施しました。全社のインシデント対応マニュアルに沿って、インシデントチームを組成し、復旧対応だけでなく、関係者への連絡や対外的な情報公開まで含めて通しでシミュレーションしました。
訓練後の振り返りで「手順が複雑なので、いきなり本番だったらテンパっていたと思う。やれてよかった」と言われたのが印象に残っています。後日、実際にインシデントが発生したときも、役割分担と判断の手順を思い出しながら、慌てずに対応できました。
私自身も、そのインシデント対応では指揮官を務めました。全体の状況を把握しつつ、一次調査や復旧対応をメンバーに適切にアサインし、ステークホルダーとのやり取りのハブになりました。結果として、迅速な復旧対応について好評をいただくこともできました。
スクラムの改善 —— スプリントゴールの設定
スクラムのイベント自体は回せていましたが、「今スプリントで何を達成したいのか」が曖昧なままタスクを進めることがありました。その結果、優先度判断が個人に委ねられたり、チームの力が分散したりしていました。
そこで、アジャイルコーチのアドバイスを受け、スプリントゴールを明確に設定するようにしました。抽象度が高くなりすぎないよう、私たちのチームでは以下の判断基準を設けました。
- プロダクトゴールへの進捗を示すものになっているか
- ステークホルダーが関心のある内容か（スプリントレビューで「これを見てください」と自信を持って言えるか）
- チームが集中できるようになっているか（優先度を明確にする）
スプリントゴールを明確にすると、チームとして「いま何を優先するか」の目線が揃いやすくなります。自分のタスクに目処が立ったタイミングで「手伝えそうなことはありますか？」と声が上がったり、達成が難しい場合にプロダクトオーナーとスコープ調整を相談したりと、能動的な動きが増えました。
プロダクト目標の計画実行 —— チームとの目線合わせの重要性
前述の性質の違う2つのプロダクト目標を計画通りに進められない件については、チーフとしての振る舞いに大きな反省がありました。
目標に対し計画通りに進められない状況は、メンバー全員が認知していました。しかし、私は要因分析を自分一人で進め、「見積もりに課題があるのではないか」という仮説のもと、見積もり方法の見直しを独断に近い形で提案しました。
提案自体は受け入れられたものの、メンバーやマネージャーからは「まずは深掘りすべき課題の特定から、みんなを巻き込んでやるべきでは」という意見をもらいました。まさにその通りで、本来は以下のように進めるべきでした。
- 課題の発散をチームメンバーと一緒に行う
- 課題の要因分析をチームメンバーと一緒に行う
個人で課題の分析や提案を行うこと自体は悪くありません。ただ、本質的な改善に向かうためには、まず「課題に対する目線合わせ」をチームで行う工程を飛ばしてはいけなかったのだと痛感しました。
このテーマについては、まだ「改善をやり切った」と言える状態ではありません。だからこそ、次の半期目標を立てるタイミングでは、アジャイルコーチからのアドバイスも活かしながら、単にToDo（やること）を並べるのではなく、アウトカム（顧客に起きてほしい変化）から逆算して、To-Be（あるべき姿）をチームで議論し、目線を合わせたいと考えています。
アウトカムとTo-Beが揃えば、チーム内での選択と集中がしやすくなり、優先度の判断やプロダクトゴールの設定もぶれにくくなるはずです。具体的には、ロードマップや拡張インパクトマッピングを作成し、プロダクトゴールとスプリントゴールを結び直すことで、次のような状態を目指しています。
- プロダクトゴールとスプリントゴールがアウトカム指向になる
- プロダクトバックログアイテムの作成やスプリントでの選定に柔軟性が出る（実現手段の選択肢が増える）
その結果、状況の変化に柔軟に適応しつつ、チームとして納得した優先度で進められる状態を目指していきたいです。
試行錯誤を通じて得た学び
チーフとしての数ヶ月は、単なる「役割の変化」以上に、エンジニアとしての考え方を更新し、リーダーとしての責任を自覚する貴重な機会となりました。
「チーフだから」という気負いからの脱却 —— 期待値のヒアリングと周囲への頼り方
チーフのミッションは「チームの成果の最大化」です。私はチーフに就任直後、「自分が答えを出さなければ」と一人で力んでいました。
メンバーとの1on1で「自分に何を期待しているか」を率直に聞いた際、返ってきたのは「一人で抱えずに、もっとメンバーを頼ってほしい」という言葉でした。経験豊富なメンバーが多いからこそ、積極的に相談し、任せる勇気を持つ。またマネージャーからは「中長期の目線でチームの方向性を言語化し、メンバーの意見を引き出すことが大事」と助言をもらいました。
まだいたらないところは多いですが、チームメンバーを頼りながら、チーム全体の力を最大化させる感覚が少しずつ掴めてきたように思います。
「チームの窓口」としての責任 —— 複雑な情報を整理する
私たちのチームは、チームトポロジーでいうところの「ストリームアラインドチーム」です。プロダクトの価値提供に必要なことは領域を問わず「なんでもやる」のが私たちのスタンスです。
SmartHRでは多くのプロダクトが密接に連携しており、情報の流れが速いです。その中で、私が「チームの窓口」として動くことで、チームが迷わず開発に集中できる環境を目指しました。
情報の交通整理と責任ある回答
スピーディーな情報交換が行われる中で、自チームの担当として責任を持って情報をキャッチし、チーム外への回答や伝達を行うよう心がけました。これにより、個々のメンバーが細かな調整で思考を分断されるのを防ぎ、開発リズムを維持できるよう意識しています。
適切なエスカレーション
チーム内で上がった課題をすべて自分たちだけで抱え込むのではなく、「これは組織として解決すべきだ」と判断したものはマネージャーへ迅速にエスカレーションし、適切なサポートを引き出すことも重要な役割だと学びました。
有事の際の「指揮官」としての振る舞い
この役割が最も試されたのがインシデント対応でした。私はインシデント指揮官として、他職種との連携やステークホルダーとの情報伝達のハブになることに専念しました。実作業は信頼できるメンバーの力を適切に頼ることで、迅速な収束を実現できました。
この経験は、日々のチームメンバーや周囲との信頼関係が形になったものだと感じています。自分の長所を活かしつつ、メンバーの専門性に背中を預ける。その役割分担がうまくハマり、結果として迅速な収束に繋がったことは、チーフとしての自分なりの貢献の形を見つけられた、手応えのある経験でした。
まとめ
入社1年目、しかも自分より経験豊富なスペシャリストが揃うチームで「チーフ」を担うことは、正直に言ってプレッシャーの連続でした。今でも、自分の判断や振る舞いに反省することも多々あります。
しかし、この数ヶ月の試行錯誤を通じて強く感じたのは、「完璧なリーダーを目指すよりも、チームに対して誠実であること」の大切さです。
自分の未熟さを認め、メンバーを頼ること。チームが開発に集中できる環境を整えること。そして一人のエンジニアとして手を動かし続け、自身も成長に努めること。こうした積み重ねが、結果としてチームの信頼を得ることにつながり、私自身の成長にも繋がりました。
エンジニアのキャリアにおいて、マネジメントやリーダーといった役割は、多くの職務があり不安に苛まれることも多いと思います。しかし、自分一人のアウトプットを超えて、チーム全体を主語にして動くことで、個人の力だけでは得られないやりがいや、成長につながるはずです。
私のこのありのままのプロセスが、キャリアパスに悩む方や、新たにリーダーの役割に挑戦しようとしている方の「次の一歩」を踏み出すヒントになれば幸いです。
We Are Hiring!
SmartHR では一緒に SmartHR を作りあげていく仲間を募集中です！
少しでも興味を持っていただけたら、カジュアル面談でざっくばらんにお話ししましょう！
- 各ユニットの戦略と実行に責任を持ち、メンバーのマネジメントを行う役職。ユニットはチームと同じ意味で、組織の最小単位。2〜7名のプロダクトエンジニアで構成され、チーフとメンバーは原則同じチームで働く。参考：SmartHR 開発組織について↩
- スペシャリストのプレイヤーであり、ピープルマネジメントは行わない役職。参考：SmartHR 開発組織について↩
- 各部の戦略と実行に責任を持ち、チーフのマネジメントを行う役職。参考：SmartHR 開発組織について↩
