こんにちは、SmartHRのスキル・資格・研修＆学習管理サービスの開発チームでチーフ1（プレイングマネージャー）を務めているkiitaです。
2024年11月にチーフに就任し、1年以上が経ちました。マネジメント未経験のまま手探りで進んできましたが、いまになって「チーフの仕事って、こういうことだったんだな」と少しずつ言語化できるようになってきました。
今現在は、チーフを引き受けてよかった！と思っています。しかし最初に打診を受けた時は、正直迷いもありました。
迷った理由のひとつは、タイミングの早さです。打診を受けたのは入社して8ヶ月ほど経った頃でした。いずれマネジメントもやってみたいと思ってはいたものの、漠然と「3年くらい経ってからなのかな」と想像していたので、予想よりだいぶ早かったなという印象がありました。
それに加えて、前任のチーフが「ロードマップ作り、PMとの仕様調整、実装、1on1でのコーチング」を一通りこなしているのを見ていたので、自分が同じレベルで動けるイメージが持てなかった、というのも迷いの大きな理由でした。
それでも引き受けたのは、2つの材料があったからです。ひとつは、前任からの「今のチームをよく知っている人がチーフになったほうがいい」という言葉です。たしかに、メンバーからすれば、コンテキストを知っている人がチーフになるほうが安心できるはずです。それなら自分にも提供できる価値がある、と判断しました。もうひとつは、「やったことがないという理由だけで断ることはしない」という、以前から持っている自分の価値観です。
この記事では、就任当時の自分が抱えていた3つの問いに、いまの自分がそれに答える形で、この1年を振り返ります。マネジメントロールに踏み出すかどうかで迷っている方の参考になれば幸いです。
「チーフの仕事」とは何だったか？ ── 決まった型はなく、状況に応じて判断する仕事だった
1年前の自分は、「チーフの仕事って、具体的に何をすればいいんだ？」と漠然と不安に思っていました。いまの自分の答えは、「決まった型はなく、状況に応じて自分で判断する仕事」というものです。
就任の前後で一番大きく変わったのは、ほかでもない、この「チーフの仕事」に対するイメージでした。
最初のイメージ：ある程度確立されたやり方があって、それを習得するものだと思っていた
最初は、「前任がある程度確立したやり方をしているはずだから、自分はそれを引き継いでいくのだろう」と考えていました。チーフの役割は固まっていて、やり方も決まっていて、それを覚えて実践していくイメージです。
この前提が崩れたのは、就任後1〜2ヶ月ほど経った頃でした。前任にとっても手探りの末に作ってきたやり方だったこと、そして「チーフのやり方」は人ごと・状況ごとに最適解が変わるものだということが、徐々に見えてきました。
気づき：自分で判断するしかない場面の連続だった
「自分で判断するしかない」と感じた場面は、正式に就任する前からいくつか出てきました。
たとえば、担当プロダクトが運用フェーズに入るタイミング。運用フェーズとは、新規機能の開発を止めて、既存のお客様向けの維持・管理を主にする状態です。これに伴って開発体制は縮小し、チームごと別のプロダクトに合流するケースもあれば、チームが解散になる可能性もあります。
この方針が伝えられたのは、チーフ就任を承諾してすぐの2024年11月末頃でした。チームとしても組織としても、「運用フェーズに入ることは決まったが、メンバーの行き先はまだ決まっていない」という状況は初めてでした。何に気をつけるべきか、メンバーにどう伝えるか、といった判断材料を誰かが持っているわけではなく、自分で考えるしかありませんでした。
もう一例として挙げられるのが、デザイナーやPMといった他職種との協業の動き方です。前任がチーフだった頃、スコープや仕様の調整は前任がデザイナーやPMと先に済ませてくれていました。自分を含むメンバーは、基本的にはそれを理解して実装すれば回るようになっていたのです。ただ、自分が同じように動くのはどうも難しそうだと感じたため、「それならメンバーの力を借りるしかない」「メンバーの意見や考えをいかに引き出し、仕様に反映していくか」という考え方に切り替えました。具体的には、PRD（プロダクト要求仕様書）を読んで設計に入る前に懸念事項やアイデアの発散会を行う、たたきは自分が作ってメンバーからフィードバックをもらう、といったやり方で、自分の動き方を組み立て直していきました。
いまの答え：決まった型はなく、自分で考えて判断する仕事
こういった経験を通じて、同じやり方をしても同じ結果にはならないし、自分は前任とは違う人間なのだから、そうであれば、自分は何をするのがチームの成果最大化につながるのかを自分で考えるしかない、と気づきました。
プロダクト・ビジネス・チームの状況、メンバーのスキルや志向、自分自身の得意不得意、取り巻く環境。これらを材料にして、状況に応じて自分で判断する。それが、いまの自分が捉えている「チーフの仕事」の中身です。
「チームの成果を最大化する」とは、どういうことか？ ── チーム共通ミッションを立ててみて、わかったこと
1年前の自分は、「チームの成果を最大化するって、結局どういうことなんだ？」と困っていました。いまの自分の答えは、「チームが最も重要な課題にフォーカスして動ける状態を作ること」というものに、少しずつ近づきつつあります。
最初の状態：「チームの成果を最大化する」が、よくわからなかった
社内の新任チーフ向けの資料には、チーフの役割として「チームの成果を最大化する」と記載されています。1on1や評価といったマネジメントの道具も、すべては「チームの成果を最大化していくための手段」だとされています。
ただ、就任当初の自分にとって、その「チームの成果を最大化する」が具体的に何を意味するのかは、正直よくわかっていませんでした。
きっかけ：マネージャーからの「チーム共通ミッション」の提案
2025年下期のタイミングで、自分が所属しているチームは、チームごと別のプロダクトの開発に合流する形での異動が決まっていました。新しいプロダクトの状況も読みづらく、メンバーごとの個人ミッションを立てるのが現実的に難しい時期でした。
そんな中、当時のマネージャーから「個々のメンバーではなく、チーム共通のミッションを立ててみたらどうか」という提案を受けて、なるほど、そういうやり方もあるのか、とやってみることにしました。
具体的には、「いま担当しているプロダクトの機能改善をやりきる」「いま担当しているプロダクトを別チームへスムーズに引き継ぐ」「次に合流するプロダクトの開発体制を立ち上げる」という3軸をチーム共通ミッションとして立てて、それぞれに達成水準を設定し、メンバー全員がこのチーム共通ミッションをそのまま自分のミッションとして追いかける形にしました。
いまの答え：「最大化する」の輪郭が、少し見えてきた
期が終わってメンバーから話を聞いてみると、「いつもの個人ミッションよりも動きやすかった」というフィードバックが返ってきました。
詳しく聞いてみると、これまでは「個人ミッションに入っているから、これをやらなきゃ」が動機の中心になることが多かったところ、今期はチーム共通ミッションがあったことで、プロダクト・組織・チームとしていまやるべきと思ったことに、自然と手を動かせていたようでした。それが結果的にミッション達成にもつながっていた、というのが、おおむねの理由のようでした。
逆に、個人ミッションだけで動いていると、期中に状況が変わって本当に優先すべきことが見えてきても、当初のミッションに引きずられて優先度判断に困る、ということが起こりがちです。チーム共通ミッションは、その点でうまく機能していたようでした。
もちろん、それまでの個人ミッションの立て方や、自分のサポートの仕方が良くなかったという要素も大いにあると思います。それでも、チーム共通のミッションというアウトプットを作り、それを個人ミッションや評価にも組み込むようにすれば、メンバーがフォーカスして動ける状態を結果として作ることができる、と実感できました。
「チームの成果を最大化する」が具体的に何を指すのか、最初は何もわからなかった状態から、たまたま提案に乗ってひとつ試したことで、その輪郭が少しだけ見えてきました。
「チーフとして何をすればいいかわからない」は問題か？ ── 問題ではない。それを自力で解くことがチーフの仕事
1年前の自分は、「チーフとして何をすればいいかわからない」ことに焦りを感じていました。いまの自分の答えは、「焦らなくていい、その問いを自力で解くプロセスそのものがチーフの仕事」というものです。
最初の状態：個人ミッションの設定で、何を立てればいいかわからなかった
就任して最初に困ったことのひとつが、自分自身の個人ミッションの設定でした。
SmartHRのチーフは、自分の個人ミッションのなかに、マネジメントに関する目標をひとつは設定することになっています。ただ、就任したばかりの自分にとっては、「マネジメントに関するミッション」と言われても、どんな粒度で、どんな方向性のミッションを立てればいいのかが、まったくピンときませんでした。
その時点では自分なりに考えてミッションを設定したものの、いま振り返ってみると、チームに対して特別良い影響を与えられるミッションとは到底言えないものでした。
気づき：「期初に答えを出そう」としたこと自体が、無理筋だった
なぜうまくいかなかったのか。そのヒントをくれたのは、社内のチーフ向けマネジメント研修で出てきた言葉でした。
問題を正確に定義することは、問題を解くことと同じぐらい重要だ。
最初のミッション設定でうまくいかなかったのは、期初の段階で「チームの成果を最大化するには〇〇をすれば良い」という答えを無理に出そうとしていたからではないか、と気づいたのです。
期初の時点では、チームのどこに本当に課題があるのか、どこを動かせばチームが前に進むのかが、まだ見えていません。見えていない状態のまま「答え」を仮置きしても、それが的を射ているかどうかは運でしかない。本来は、答えを出す前に「いまチームにとっての問題は何なのか」を見極めることに、もっと時間をかけるべきでした。
「何をすればいいかわからない」と感じていたのは、実は「答え」の欠如ではなく、その前段にある「問題の定義」ができていなかったから、ということです。
いまの答え：答えを導き出せること自体が、チーフとしての成長ステップ
ここまでを踏まえて、1年前の「チーフとして何をすればいいかわからない」と悩んでいた自分に伝えるとしたら、「それは問題ではなく、解消を急がなくていい」と伝えます。
「チームにとってのいまの問題は何か」を考え、それに対する打ち手を自分なりに導き出す。このプロセスを回せるようになること自体が、チーフとしての大事な成長ステップだ、というのがいまの自分の捉え方です。
もし当時に戻れるなら、まず課題の特定に十分な時間をかけると思います。たとえば「チームの成果最大化のボトルネックを特定する」を中間目標に設定する、チームで振り返りを行ってメンバーが感じている問題を引き出す、といったやり方が考えられます。
まとめ：1年やった結論 ── 引き受けてよかった
冒頭にも書きましたが、いまの自分は「あの時チーフを引き受けてよかった」と心から思っています。理由は主に2つあります。
まず、チームにとっていま何が一番大事かを自分の頭で見極め、それを実行に移していくという仕事そのものに、やりがいを感じているためです。簡単ではない分、面白いとも感じます。
そして、これができるようになれば、今後どんな組織でも活かせるポータブルスキルになる、と感じています。特定のプロダクトや組織でしか使えない知識ではなく、「いまここで何をやるべきか」を自分で考え抜いて実行する力そのものなので、長い目で見ても腐らないスキルだと思います。
あくまでひとりのチーフの感想にすぎませんが、マネジメントロールに踏み出すかどうかで迷っている方の、参考になればうれしいです。
We Are Hiring!
SmartHRでは、プロダクトエンジニア（PdE）をポジション問わず募集しています。
この記事を読んで「PdEとしてキャリアを広げてみたい」「もう少し話を聞いてみたい」と思った方は、カジュアル面談からでもお気軽にお声がけください。
- 各ユニットの戦略と実行に責任を持ち、メンバーのマネジメントを行う役職。ユニットはチームと同じ意味で、組織の最小単位。2〜7名のプロダクトエンジニアで構成され、チーフとメンバーは原則同じチームで働く。参考：SmartHR 開発組織について↩
