こんにちは、SmartHRでアジャイルコーチをしている @wassan です。
「目標に書いた機能は全部リリースした。でも、思ったほどユーザーに使われていない。」
プロダクト開発に携わったことのある方なら、一度はこんな経験をしたことがあるのではないでしょうか。SmartHRでも、組織が急速に拡大する中で同じ壁にぶつかりました。
この記事では、その壁をどう乗り越えようとしたか——チーム目標を「To Do（やるべきこと）」から「To Be（ありたい姿）」へ転換する取り組みについて、背景と学びを紹介します。
後半では、実際にパイロットチームとしてワークショップを実践した開発チームのチーフ nomuson にバトンタッチして、現場のリアルな感想をお届けします。
「To Doリスト化」する目標への違和感
SmartHRの目標設定には、組織拡大とともにある傾向が強まっていました。目標が「やるべきことリスト」になってしまうことです。
- 「◯◯機能をリリースする」
- 「◯◯のツールを導入する」
決めたタスクをやり切ることは大切です。しかし、これだけが目標になると、以下のような違和感が出てきます。
- 目的が見えにくくなる： 「何のためにやっているのか」がチーム内で腹落ちしないまま、手を動かし続けてしまう
- リリースしたのに成果が出ない： 目標（リリース）は達成したのに、想定より使われなかったり、手戻りが発生したりする
- 受け身になる： 「やるべきこと」が決まっているので、エンジニアからの改善提案や挑戦の余白が少ない
SmartHRが大切にしているのは、自律的に考え、判断し、行動できるプロダクト組織です。そのためには、目の前のタスク消化だけでなく、「このチームは、どんな価値を生み出そうとしているのか？」を共有できる羅針盤が必要でした。
「何を作るか」ではなく「どんな変化を起こすか」
そこで取り組んだのが、To Do（やるべきこと）ではなく To Be（ありたい姿・変化）にフォーカスしたチーム目標への転換です。
- ユーザーやプロダクトに、どんな変化をもたらしたいのか
- チームとして、どんな状態を実現したいのか
この「ありたい姿」を起点に目標を設計することで、3つの効果を期待しました。
- チームとステークホルダーの意思決定が揃いやすくなる
- 状況変化に応じて、やり方（How）を自律的に変えられる柔軟性が生まれる
- 「自分の仕事がチーム目標にどう貢献しているか」を実感しやすくなる
成果の連鎖を設計する：チーム目標ガイドラインの策定
「ありたい姿を目指す」と言っても、具体的にどう目標に落とし込むのか。この考え方を組織で共有するために「チーム目標ガイドライン」を策定しました。
ガイドラインの核心を一言でまとめると、チームのKey Results（主要な成果指標）を「作ったもの」ではなく「起きた変化」で測る、ということです。
インパクトを実現するまでの成果の連鎖を整理し、「チームが追うべき指標」と「個人が追うべき指標」を分けて定義しました。
| 階層 | 定義 | 目標設定での位置づけ |
|---|---|---|
| インパクト | 最終的な事業成果（売上、顧客獲得、解約率改善など） | チーム共通の Objective： プロダクト全体のOKRと接続した、チームの最上位の目標 |
| アウトカム | インパクトを実現するための「変化」（顧客体験の変化、品質向上、チームの成長など） | チーム共通の Key Results： 単なるリリースではなく「どう変化したか」を指標にする |
| アウトプット | アウトカムを実現するための「成果物」（機能リリース、仕組みの実装など） | 個人の目標： 「何を作るか」は個人の貢献として評価（キャリアラダーを参考に設定） |
| アクティビティ | アウトプットを生むための「活動」（開発作業、調査、議論、学習など） | 個人の行動・プロセス： 日々の行動の質や量（キャリアラダーを参考に設定） |
もっとも重要なポイントは、「機能を作ること（アウトプット）」をチームのKey Resultsにしないという点です。機能リリースは個人の貢献として評価しつつ、チームとしては「その機能によってどんな変化が起きたか」を追いかけます。
「Product」だけじゃない——4Pで成果を多面的にとらえる
では、チームが追うべき「アウトカム（変化）」とは具体的に何でしょうか。
一言でいえば、Product（顧客価値）だけでなく、Project・Platform・Peopleへの投資もチームの正式な成果として認めるということです。エンジニアリングマネージャー界隈で知られる「4P」フレームワークを参考に、Key Resultsを考える切り口を導入しました。
| 軸 | 内容 | 狙い |
|---|---|---|
| Product（顧客価値） | ユーザーの行動変容、体験の向上 | 機能を作ること自体ではなく、ユーザーへの価値を問う |
| Project（プロセス） | 開発効率、予測可能性、スピード | チームの開発プロセスそのものを改善する |
| Platform（技術基盤） | 品質、信頼性、パフォーマンス | 長期的な開発に耐えうる技術的健全性を保つ |
| People（チーム力） | 属人化解消、スキル向上、オンボーディング | 強いチームを作るための人への投資 |
これまで「機能開発（Product）」に偏りがちだったチーム目標に、開発効率や技術基盤、チーム力への取り組みも正式に組み込むことで、エンジニアがより健全に、そして野心的に働ける環境を目指しています。
チームOKRワークショップの実践
ガイドラインを「読むだけ」で終わらせないために、パイロットチームとともにチームOKRワークショップを設計・実施しました。
ワークショップで大切にしたこと
このワークショップには3つの狙いがあります。プロダクトチームとビジネス側のステークホルダーが「ありたい姿」を起点に今期のゴールを語ること。フィーチャー開発と、技術的負債の解消やデリバリー能力向上のバランスをとること。そして対話を通じて、チームとして納得感のあるOKRを作ることです。
進め方
いきなりKey Resultsを考えるのではなく、以下の順序で情報を全員で共有しながら進めました。
- 今期どんな山を登りたいのか（Objective） をチームで確認する
- ユーザーのPain / Gainを洗い出す
- 開発チームの足元（プロセス・技術・チーム力）を棚卸しする
- 前期にリリースしたものが、実際にどう使われているかを振り返る
「顧客の価値」と「チームの現実」を並べて眺めることで、「じゃあ、今期どんな"変化"を起こすべきか？」を4Pの観点で議論できるように設計しました。
実施してみて分かったこと
ここからは、実際に2026年上期のチーム目標をワークショップで策定した、パイロットチームの1つである人事評価チームのプロダクトエンジニアのチーフ、 nomuson にバトンタッチします。
バトンタッチ：現場から見た景色 (nomuson)
こんにちは！ 給与シミュレーション機能などを開発しているタレントマネジメントプロダクトの人事評価チームのプロダクトエンジニアのチーフをやっている nomuson です。 ここからは、今回のワークショップを実際にやってみて、チームに起きた変化や気づきをお伝えします。
ワークショップから得られたこと：目指すべきゴールの共通理解
一番の収穫は、開発している機能が届けられたときのユーザーの行動変容をチーム全員で目線合わせできたことです。
これまでは、開発する機能の単体で解決したい課題を捉えることが多くありました。しかし今回は、PM・PMM・QAEも交え、ユーザーの業務全体の視点で、最も重要なPainとGainを確認し、ユーザーにもたらしたい価値を議論できました。これによって、目指すべきゴールとしてのアウトカムを確認することができました。
一方で、掲げたアウトカムを評価する難しさも露見しました。
担当機能の業務特性上、ユーザーが実際に機能を使う時期がリリース後すぐではないことが多いです。アウトカムの計測指標を定めても、アウトカムを評価できるタイミングがかなり遅れてしまいます。また、中間指標を定めたとしても、アウトカムの仮説を立証するデータとしてその中間指標が正しいかどうか、データをもとにしてプロダクトへの適応を行なっていけるかは未知の領域です。
「4P」の観点の切り口でプロセスに対しても考えることができましたが、1回のワークショップですべてを議論し尽くすことは難しく、プロダクト面の議論で大半を費やしてしまいました。そのため、プロセス面のアウトカムについては、後日テキストベースで補完する必要がありました。
今回のワークショップで掲げたアウトカムは、まずチームとして「目指す方向」の合意を作ることを優先しました。初回から完璧を目指すのではなく、個人目標との接続は次の半期で段階的に進めていきたいと思っています。
今後に向けて
ふたたび wassan です。
nomuson さんのコメントにもあったように、今回の取り組みはまだ道半ばです。それでも、チームとステークホルダーが「To Be（ありたい姿や起こしたい変化）」を起点に、「チームで考え、チームで決め、チームで改善する」というサイクルを回し始められたこと自体が、大きな一歩でした。
実際に、パイロットチームのメンバーにワークショップ後のヒアリングを行ったところ、「チームOKRを考えたことで、チームのありたい姿が明確になった。結果、個人としてもそこにどう貢献すればよいかを考えるようになり、個人目標も立てやすくなった」という声が上がりました。小さな変化ですが、チーム目標が「縛るもの」ではなく「自律的に動くための羅針盤」として機能し始めている兆しだと感じています。
SmartHRでは、プロダクトだけでなく組織のあり方についても試行錯誤を楽しみながら、プロダクト組織の自律性を高める取り組みを続けています。
We Are Hiring!
SmartHRでは、組織づくりも含めて一緒にプロダクトを成長させていく仲間を募集中です！
「機能を作るだけでなく、価値に向き合いたい」「チームの自律性を高める組織開発に興味がある」という方、ぜひカジュアル面談でざっくばらんにお話ししましょう！
