はじめに
楽楽勤怠開発部でPdM（プロダクトマネージャー）をしている @k0First です。
私は、ラクスが提供する「楽楽勤怠」のプロダクトマネージャー（PdM）として、日々企画・要件定義・開発推進を担当しています。
ラクスは「ITサービスで企業の成長を継続的に支援します」をミッションに掲げ、SaaSプロダクトを通じて企業の業務効率化・生産性向上に貢献する会社です。
私たちラクスが大切にしているのは、「顧客視点で価値を生む機能開発」。
ですが実際の現場では、さまざまなリクエストや要望が飛び交い、目の前の「作るべきもの」に引っ張られてしまうこともあります。
たとえば、
- 事業部からの要望をそのまま実現する
- 競合がやってるから同じ機能を実装する
そんなふうに開発された機能が、結果あまり使われない…という経験、ありませんか？
だからこそ私たち楽楽勤怠開発部では、機能を"なんとなく"で作らないことを大切にしています。
「誰の」「どんな課題を」「なぜ」解決するのか。
これを要件定義の段階でしっかりと見極めることを意識しています。
この記事では、私たち楽楽勤怠開発部が実践している「本当に必要な機能を見極めた上で開発を行うための顧客志向な要件定義」についてご紹介します。
たとえば、
- 事業部からの要望にどう向き合うのか
- デザイナーとどう体験設計を進めるのか
- 開発メンバーにどう“目的”を伝えるのか
こうした具体的な場面を通じて、単なる“仕様決め”にとどまらない、顧客視点に立った「楽楽勤怠開発部流の要件定義」の考え方を紐解いていきます。
- はじめに
- 顧客志向とは何か
- なぜ顧客志向が必要なのか
- 本当に必要な機能を見極めるために大切にしていること
- 「やる」「やらない」を決める基準
- デザイナーも構想段階から巻き込む
- 開発メンバーには「Why」から伝える
- まとめ 「顧客志向な要件定義」は問い続ける姿勢
顧客志向とは何か
「顧客志向」という言葉をよく耳にするものの、「お客様の要望をそのまま実装すること」と誤解されているケースも少なくありません。
たとえば、
- 「勤務表の申請ボタンをもっと大きくしてほしい」
- 「打刻修正の理由欄を必須にしてほしい」
といった要望は一見もっともらしく聞こえますが、実際にはその裏に、
- 「毎月申請漏れが多く、管理者からの催促が発生している」
- 「修正理由が入力されていないことで労務チェックが止まってしまう」
といった、業務上の根本的な困りごとが隠れていることが多くあります。
顧客志向の本質は、"要望に応える"ことではなく、"困りごとの本質を見極めて、最も効果的な解決策を提供すること"です。
この視点に立つことで、「本当に使われる機能」「顧客の期待を超えた価値」を実現することができると私は考えています。
なぜ顧客志向が必要なのか
私たちが開発している「楽楽勤怠」は、全社員が日々の打刻や申請で使い、現場の責任者がそれを確認・修正し、さらに労務担当者が全体を集計・管理するというように、複数の立場のユーザーに横断的に使われるプロダクトです。
この領域の難しさは、単に機能を実装することではなく、
- ITに不慣れな現場の責任者にも、直感的に使える操作性
- 部門や拠点ごとに異なる就業ルールや申請フローへの柔軟な対応
- 毎日発生するリアルタイムな処理と確認作業の効率化
といった、現場の実務に本当にフィットする体験をどう作るかにあります。
そんな中でお客様からの要望をそのまま実現してしまうと──
- 現場で本当に困っていることが解決されなかったり
- 別のユーザーには使いにくい仕様になってしまったり
ということが起こりがちです。
だからこそ私は、限られた開発リソースを本当に役立つ機能改善に使うために、「要望」ではなく「課題」を見極めることを重視しています。
本当に必要な機能を見極めるために大切にしていること
楽楽勤怠開発部が大切にしているのは、「要望」ではなく「課題」にフォーカスする姿勢です。
お客様や事業部から「これが欲しい」と要望が上がってきたとき、PdMが最初にやるべきことは「なぜその機能が必要と感じているのか」を丁寧に聞くことです。
顧客要望を「課題」に翻訳する
楽楽勤怠開発部では、顧客からの要望を直接聞くことはなく、事業部から要望を収集して機能開発を行っています。
その際、事業部には次のような質問を投げかけます。
- なぜこの機能が必要だと感じているのですか？（背景・文脈をヒアリング）
- 今の運用でどんな手間がかかっていますか？（業務フローやオペレーションを理解する）
- この問題が解決されることで、どんな効果が期待できますか？（課題解決の確実性を確認する）
- 現状の代替手段や妥協点は何かありますか？（本当に"今"解決すべき課題かを見極める）
この対話を通じて、お客様が本当に困っていること、解決すべき本質的な課題が明らかになります。
表面的な要望に引っ張られず、「その機能がなぜ必要なのか」を深掘りすることが、顧客志向な要件定義においては非常に重要です。
そうすることで、目的を逸脱した「使われない機能」の開発を防ぐことができます。
顧客価値だけでなく事業価値も考える
要件定義では、お客様のことを考えるだけでなく、事業部との調整も欠かせません。
事業部からは「売上拡大」「顧客獲得」といった目標を実現するための要望が上がってきます。
ここで大切にしているのは、「顧客価値」と「事業価値」の両方を論理的に整理し、合意形成することです。
顧客視点と事業視点を両立させる
楽楽勤怠開発部では、事業部と合意形成をするために、以下の内容を整理しています。
このように、感覚ではなく「数字と論理」で合意形成するようにしています。
最後に、その機能を実装するために必要なリソースと、見込まれるリターンのバランスを検討し、事業部と「もしこれをやるなら、どこに負荷がかかるか」「他の優先タスクにどんな影響が出るか」を具体的に議論します。
開発部と事業部では、それぞれ優先するものが異なるため、合意形成をスムーズに行うには、お互いのことを深く理解していなければなりません。
楽楽勤怠では、開発部と事業部の間に信頼関係が築けていることもあり、お互いの立場を尊重した合意形成ができていると感じます。
「やる」「やらない」を決める基準
すべての要望を実現することはできません。
だからこそ、「やらないと決めること」もPdMの大切な仕事です。
私は以下のような基準で判断しています。
- 顧客にとって価値が高いか
- たくさんの顧客にメリットをもたらすか
- ある一部の顧客にとってしかメリットがないものになっていないか
- 今やるべきなのか
開発リソースは有限です。
「やるべき機能」を見極め、「やらないこと」を決断することこそが、真の顧客志向だと考えています。
こうして、開発ロードマップを作成し、機能開発の優先度を事業部と協議して決めています。
デザイナーも構想段階から巻き込む
楽楽勤怠開発部では、もともとデザイナーを「要件定義フェーズが終わってから参加してもらう」ようなスタンスで開発を進めていました。
ですが、現在では、要件定義の構想段階から積極的に巻き込むことが重要だと考えているため、一緒に要件定義を進めています。
なぜなら、顧客にとって「その機能がどう使われるのか」「どんな体験になるのか」は、仕様書だけでは表現しきれないからです。
体験を一緒に設計する
要件定義の段階で、デザイナーに共有するのは次のような情報です。
-
顧客の課題（なぜこれをやるのか）
-
ユーザーがどんな業務フローの中で使うのか
-
どうすれば迷わず、スムーズに使える体験になるのか
この段階で、PdMである私が頭の中で描いている「理想の顧客体験」を伝え、デザイナーの視点を加えてデザイン設計を行うことが大切です。
例えば、
-
「この動線だと、ユーザーは何を期待してこのボタンを押すのか？」
-
「今の画面構成だと、どこでつまずくリスクがあるか？」
-
「業務の文脈を考えたとき、このタイミングでこの情報が必要か？」
といった様々な観点でディスカッションを重ねます。
コストの大きい開発案件は、ワイヤーフレームを作るところから
開発コストのかかる大きな案件は、まず、デザイナーが作るワイヤーフレーム（下書き）をもとに議論を重ねます。
ここでいうワイヤーフレームは「完成品」として扱うのではなく、
“意思疎通のためのツール”として使うことを意識しています。
-
PdMが考える「この機能で顧客はこう動くはず」という仮説
-
デザイナーが持つ「UXの原則」や「ユーザー心理」の知見
-
これらをPdM、デザイナー、事業部とすり合わせていくプロセス
これが、顧客視点で価値を生む機能開発には欠かせません。
「コストと体験」のバランスも一緒に考える
もちろん、理想的なUI/UXを追い求めるだけでは、開発リソースやスケジュールが追いつかないこともあります。
だからこそ、デザイナーとは「ここは妥協しても良い」「ここは死守したい」という優先順位を共有しながら、“最適な着地点”を一緒に探ります。
これが、楽楽勤怠開発部で実際におこなっている「顧客志向な要件定義」におけるデザイナーとの連携です。
開発メンバーには「Why」から伝える
次に重要なのが、開発メンバーとの連携です。
楽楽勤怠開発部では、開発チームを単なる“実装担当”として扱うことはありません。
PdMがやるべきは、「なぜこの機能を作るのか」を開発メンバーにしっかり伝えることです。
仕様書ではなく、背景と目的から話す
私は開発メンバーに要件を伝える際、必ず次の順番で説明します。
-
背景
「この機能を要望された経緯」「顧客が直面している課題」を説明します。 -
目的
「この機能によって、どんな価値を届けたいのか」「どんな行動変化を期待しているのか」を共有します。 -
要件
そのうえで、「だからこういう仕様にしている」という理由付けをしながら要件を説明します。
これにより、開発メンバーは「言われたものを作る」のではなく、「課題解決のために自分も考える」モードに入ってくれます。
私自身、過去に仕様書だけ渡してしまったことで認識ズレが生じ、開発がやり直しになった苦い経験があります。
その時痛感したのは、「仕様そのもの」よりも「目的・背景」を伝える方が、はるかに重要だということです。
なぜなら、「目的・背景」が伝われば、認識ズレを防ぐだけでなく、私が考えた仕様よりももっと価値のある仕様を開発メンバーが考え付く可能性があるからです。
実際に、開発メンバーから「だったら、こうした方が早くて安全かも」という建設的な提案が自然と出てくるようになりました。
この双方向のコミュニケーションが、結果的により良い顧客体験を実現する近道だと考えています。
開発メンバーからのフィードバックを歓迎する
開発チームからは、仕様に対するさまざまなフィードバックが返ってきます。
-
技術的な実現可能性（もっと簡単な方法があるのでは？）
-
保守性やパフォーマンスへの影響
-
将来的な拡張性
-
セキュリティや障害対応の観点
これらをPdMが受け止め、顧客価値を損なわずに、より良い形にブラッシュアップしていくのが理想の連携です。
仕様変更を恐れない姿勢
「Why」を共有したうえでのフィードバックであれば、仕様を変えることは決して「後戻り」ではありません。
むしろ、開発チームが顧客志向で考えた結果としての改善提案であれば、歓迎すべきことです。
楽楽勤怠開発部では、スクラム開発の中で、こうした対話を通じて「チーム全体で顧客志向を実現する」文化を根付かせていっています。
まとめ 「顧客志向な要件定義」は問い続ける姿勢
ここまで、楽楽勤怠開発部が実践する「顧客志向な要件定義」についてお話ししてきました。
-
お客様の“言ったこと”ではなく、“本質的な課題”を捉える
-
顧客価値と事業価値を両立させ、冷静に優先度を決める
-
やらないことを決め、やるべきことに集中する
-
デザイナーや開発メンバーと“Why”を共有し、一緒に考える
これらは決して特別なことではありません。
重要なのは、
- 本当にこの機能は必要か？
- 顧客にとって価値があるか？
を問い続ける姿勢です。
その積み重ねが、最終的に「使われるプロダクト」「選ばれるプロダクト」につながると、私は信じています。
楽楽勤怠開発部では、これからも愚直に「顧客志向」を追求し、企業の成長を支援するプロダクトを磨き続けていきます。
