ClassLab Engineering の Dev チームメンバーが執筆しました。
「入社1年目でプロダクトオーナー？ 早すぎない？」——正直、自分でもそう思いました。
ClassLabに中途入社して3ヶ月目、上司から「このプロダクト、君がオーナーね」と言われたときの率直な感想は「無理では？」でした。前職では5年間バックエンドエンジニアとして開発に専念していて、要件定義すら経験がほとんどなかったからです。
この記事では、入社1年目でプロダクトオーナー（PO）を任され、何に苦しみ、何を学び、今どう考えているかを書きます。「裁量が大きい環境で働きたい」と思っている方に、裁量の裏側にあるリアルを知ってもらえたらと思います。
1. 背景 — なぜ1年目の自分がPOになったのか
ClassLabのエンジニアチームは約10名。ライフライン取次の基幹システムに加え、AI音声研修、コールセンター自動化、不動産テック向けモバイルアプリなど、複数の新規事業を同時に動かしています。
少人数で複数プロダクトを回すということは、1プロダクトに割けるエンジニアは1〜2名ということです。専任のPM/PdMを各プロダクトに置く余裕はありません。
graph LR
subgraph チーム構成
A[エンジニア約10名]
end
subgraph プロダクト
P1[基幹システム
3名]
P2[AI音声研修
2名]
P3[コールセンター自動化
2名]
P4[モバイルアプリ
1名]
P5[社内ツール群
2名]
end
A --> P1
A --> P2
A --> P3
A --> P4
A --> P5
結果として、エンジニアがPOを兼務する体制になります。自分が担当したのは社内向けのAI音声研修プロダクトでした。
なぜ入社3ヶ月の自分だったのか
後から聞いた話ですが、理由は3つあったそうです。
- ドメイン知識のバイアスがない: 既存メンバーは「今までこうだった」という前提に囚われがち。新しい目で見てほしかった
- 前職でのユーザーヒアリング経験: バックエンドエンジニアだったが、社内ツールの要望を直接聞いて改善する経験があった
- やりたいと言った: 入社時の1on1で「上流工程にも関わりたい」と伝えていた
正直、3つ目が一番大きかったと思います。ClassLabでは「やりたい」と言った人に機会が回ってくる文化があります。ただし「放り出される」のとは違います。週次1on1で上司が壁打ち相手になってくれること、Slackで気軽に相談できるチームの雰囲気——そういったサポート体制があった上での「裁量」です。
2. 課題 — PO1年目の3つの壁
壁①: 何を作るかを決められない
エンジニアとして「どう作るか」を考えるのは得意でした。でもPOの仕事は「何を作るか」を決めること。これが想像以上に難しかった。
| エンジニアの思考 | POの思考 |
|---|---|
| この技術で実現できるか？ | この機能はユーザーが本当に必要か？ |
| パフォーマンスは足りるか？ | ROIは合うか？ |
| テストは書けるか？ | リリース順序はどうするか？ |
| コードの保守性は？ | 3ヶ月後にこの機能は使われているか？ |
最初の1ヶ月は、ユーザー（社内の研修チーム）に「何が欲しいですか？」と聞いて、言われたとおりに作ろうとしていました。結果、優先順位のないバックログが30件以上積み上がり、何から手をつけていいかわからなくなりました。（この数字は後にさらに膨れ上がることになります。）
壁②: ステークホルダーとの合意形成
ClassLabでは、プロダクトの方向性をエンジニアだけで決めません。事業部門、研修チーム、経営層——それぞれ期待するものが違います。
- 研修チーム: 「今すぐ使える研修コンテンツがほしい」
- 事業部門: 「研修の効果が数値で見えるようにしてほしい」
- 経営層: 「将来的に外販できるプロダクトにしてほしい」
3者の要望は矛盾こそしないものの、優先順位が全く違う。研修チームは今月の研修に間に合わせたい、経営層は半年後の市場投入を見ている。この間に立って合意を取るのがPOの仕事だと気づくのに、2ヶ月かかりました。
壁③: 自分で手を動かしたくなる衝動
これが一番きつかったです。POとしてバックログ整理や仕様書作成をしているとき、隣でもう1人のエンジニアが実装しているのを見ると、「自分で書いた方が早い」と思ってしまう。
実際に何度か手を出して、自分の実装タスクとPO業務の両方が中途半端になりました。「自分でやった方が品質も高いし早い」——その考え自体は間違っていなかったと思います。でも、自分が実装に入ると仕様の判断が止まり、もう1人のエンジニアが手持ち無沙汰になる。チーム全体で見ると明らかにマイナスでした。
上司との週次1on1でこの悩みを話したとき、「君の仕事はコードを書くことじゃない。チームが正しいものを作れるようにすることだ」と言われ、ハッとしました。この1on1は入社当初から毎週30分、今でも続いています。POとして孤立せずに済んだのは、この定期的なフィードバックの場があったからだと思います。
3. 設計 — 自分なりのPOスタイルを作る
壁にぶつかりながら、3つの打ち手を実行しました。
打ち手①: ユーザーインタビュー週1回の定例化
「何が欲しい？」ではなく、「今、何に困っている？」を聞く形式に変えました。Jobs-to-be-Doneの考え方を参考に、ユーザーの行動と文脈から課題を抽出します。
graph TD
INT[週1インタビュー
研修チーム] --> PAIN[課題の抽出
行動観察+質問]
PAIN --> HYP[仮説立案
この課題はXで解決できる]
HYP --> MVP[最小実装
1-2週間で検証]
MVP --> FB[フィードバック
使ってもらって観察]
FB --> INT
style INT fill:#3b82f6,color:#fff
style MVP fill:#10b981,color:#fff
style FB fill:#f59e0b,color:#fff
この「インタビュー → 仮説 → 最小実装 → フィードバック」のサイクルを2週間で回すようにしたことで、バックログの優先順位が自然と決まるようになりました。
打ち手②: 意思決定ログの公開
ステークホルダーとの合意形成で苦しんだ経験から、すべての意思決定とその理由をNotionに記録して全員に公開する仕組みを作りました。
「なぜこの機能を先にやるのか」「なぜこの機能を見送るのか」を文書化することで、後から「聞いてない」と言われることがなくなりました。副次効果として、自分の思考プロセスが言語化され、判断の質が上がったと感じています。
打ち手③: 実装とPOの時間を明確に分離
月曜〜水曜はPO業務（インタビュー、仕様書、バックログ整理、ステークホルダーMTG）、木曜〜金曜は実装——という時間分割を導入しました。
完全にPO専任になるのではなく、エンジニアとしての手触り感を残すことが、技術的に実現可能な提案をする上で重要だと考えたためです。このバランスは今でも試行錯誤中です。
4. 実装 — 最初の半年でやったこと
成功: AI音声ロールプレイの初期リリース
ユーザーインタビューから見えた最大の課題は「研修のロールプレイ相手がいない」でした。新人オペレーターが電話対応を練習したくても、先輩が忙しくて相手をしてくれない。
ここに絞って最小実装。AIが顧客役を演じ、新人が電話対応を練習できるシステムを2週間で初期版リリース。技術的にはTTS + LLMの組み合わせで、凝ったことはしていません。
大事だったのは「2週間で出す」と決めたこと。完璧を目指すと3ヶ月かかるところを、最小構成でリリースして研修チームに使ってもらい、フィードバックを得る。このサイクルが回り始めてから、プロダクトの方向性が見えてきました。
失敗①: 効果測定の指標を決めずにリリースした
最大の失敗は、リリース後に「効果があったのか」を測る指標を事前に決めていなかったことです。
研修チームからは「使いやすい」というフィードバックをもらいましたが、経営層から「研修効果は数値で出てるの？」と聞かれて答えられませんでした。後付けで指標を設計するハメになり、2週間のロスが発生。
この経験から、リリース前に必ず「何をもって成功とするか」を3つ以内の指標で定義するルールを自分に課しました。AI音声研修では最終的に以下を採用しています。
| 指標 | 目標値 | 計測方法 |
|---|---|---|
| 研修完了率 | 80%以上 | システムログ |
| ロールプレイ練習回数/人/週 | 3回以上 | システムログ |
| 新人の初期対応品質スコア | 研修前比+15pt | QAチームの評価 |
失敗②: 全員の要望を聞きすぎた
もう1つの大きな失敗は、全ステークホルダーの要望を全部バックログに入れてしまったこと。
「研修コンテンツのカスタマイズ機能」「管理者向けダッシュボード」「外部LMS連携」「多言語対応」……気づけばバックログは50件超、それぞれに「誰かが欲しいと言った」理由がある。でも全部作る時間はない。
転機は、上司に「この中で、明日なくなったらユーザーが困るものはどれ？」と聞かれたこと。冷静に考えると、50件中8件しかなかった。残り42件は「あったら嬉しい」レベル。
ここから学んだのは、POの仕事の半分は「作らない」と決めることだということです。バックログに入れるハードルを上げ、「ユーザーが3回以上同じことを言ったら検討する」というルールにしたら、バックログが自然と20件以下に収まるようになりました。
5. 結果 — 1年間の定量・定性データ
| 指標 | 入社時 | 1年後 | 変化 |
|---|---|---|---|
| 担当プロダクト数 | 0 | 1（PO）+ 2（開発参加） | 3プロダクトに関与 |
| ユーザーインタビュー実施数 | 0回 | 42回 | 週1ペース定着 |
| リリースしたMVP数（入社1年間） | 0 | 8回 | 約1.5ヶ月に1回 |
| バックログの平均滞留期間 | 30日超 | 12日 | **-60%** |
| ステークホルダーMTG | なし（都度） | 隔週定例 | 意思決定ログ公開後に定例化 |
定性的な変化
- 思考の幅が広がった: 「どう作るか」だけでなく「なぜ作るか」「誰のために作るか」を考えるようになった
- コミュニケーション力: 技術者以外と話す機会が増え、ビジネス言語で技術を説明する力がついた
- 失敗への耐性: 小さくリリースして失敗するサイクルに慣れた。失敗＝学びのインプット
6. 展望 — 2年目の自分へ
組織として仕組み化したいこと
自分の経験を属人的なものにしたくないと考えています。入社1年目でもPOを務められるオンボーディングの型を作りたい。具体的には:
- PO業務の最初の30日間チェックリスト
- ユーザーインタビューのテンプレート集
- 意思決定ログのフォーマット標準化
エンジニアとしても成長したい
POを経験して改めて思うのは、技術力があるPOは強いということ。「これは技術的に1日で実装できるから今週やろう」という判断ができるのは、エンジニア出身のPOならではの強みです。
2年目はPO業務を続けながら、モバイルアプリ開発（Flutter）にも手を広げる予定です。技術の幅を広げることが、より良いプロダクト判断につながると信じています。
「裁量が大きい」という言葉の裏には、答えのない問題に自分で向き合う覚悟が必要です。でも、それを乗り越えた先に見えるものは、コードを書くだけでは得られない視野の広さでした。
「エンジニアとしてだけでなく、プロダクト全体に関わりたい」——そう思っている方にとって、ClassLabは面白い環境だと思います。
採用情報
ClassLab では一緒に技術的挑戦に取り組むエンジニアを募集しています。
