新機能を作る前に何を確認する？｜顧客要望からすぐ実装せず、事前検証する方法

はじめに

新機能のアイデアが出たとき、

「顧客から欲しいと言われた」
「競合にも似た機能がある」
「既存機能を少し拡張すれば作れそう」

という状況になると、
そのまま仕様を決めて開発へ進みたくなることがあります。

しかし、

課題があることと、
その機能を作るべきことは別です。

たとえば、

• 顧客の困りごとは確認できている
• 欲しい機能についても具体的な要望がある
• 既存機能だけでは一部足りない
• 技術的にも実現できそう

という状態でも、

• 本当にその機能の形が必要なのか
• 既存機能の拡張で足りないか
• 実際の業務で使われるか
• AIや自動化まで必要なのか
• 特定の顧客だけに必要なのか

は、
まだ確認できていないことがあります。

そこで重要になるのが、
「作れるか」を考える前に、「何がまだ分かっていないか」を整理することです。

この記事では、
新機能の本格開発へ進む前に確認したい前提条件と、
実装せずにできる事前検証の進め方を整理します。

「機能が欲しい」と「その機能が必要」は分けて考える

顧客から、

「承認待ちだけ一覧で見たい」

と言われたとします。

これは重要な情報ですが、
この発言だけでは、

承認待ち専用画面を作るべき

とは決まりません。

本当に困っていることは、

• 顧客からの返事待ちを忘れる
• 誰待ちなのか分からなくなる
• 複数案件を横断して確認できない
• メールやチャットを何度も探す

ことかもしれません。

この場合、
解決方法としては、

• 専用画面を作る
• 既存一覧にフィルターを追加する
• 「顧客待ち」という状態を追加する
• AIが候補だけ提示する
• 手動タグで整理する

など、
複数の方法が考えられます。

つまり、
顧客の要望は「課題を知る材料」であって、
そのまま仕様書ではありません。

まず確認したいのは「何が事実で、何が仮説か」

新機能を考えるときは、
最初に情報を分けます。

確認できていること

たとえば、

• 複数顧客が同じ困りごとを話している
• 実際に手作業で対応している
• 特定の確認作業を毎日行っている
• 既存機能では対応できない部分がある

などです。

これは、
発言や実際の行動から確認できる情報です。

一部確認できていること

たとえば、

• モックを見せたら便利と言われた
• 一部の顧客だけ簡易版を使った
• 特定の利用場面では役立った

といった状態です。

可能性は見えていますが、
まだ一般化はできません。

仮説に留まっていること

たとえば、

• 毎日使われる
• AIで自動化すれば便利になる
• 専用画面の方が使いやすい
• 既存手段を使わなくなる
• 継続利用される

といったものです。

ここを混ぜると、

「課題は確認できているから、
この機能も必要なはず」

という飛躍が起こりやすくなります。

既存機能や現在の代替手段も確認する

新機能を作る前には、
顧客が現在どうやって対応しているかも見ます。

たとえば、

• メモへ書く
• TODOに登録する
• Slackで自分にリマインドする
• スプレッドシートへまとめる
• メールを検索する
• 定期的に全案件を確認する

といった方法です。

ここで重要なのは、

代替手段がある
＝新機能は不要

ではないことです。

手作業で対応できていても、

• 更新を忘れる
• 時間がかかる
• 案件数が増えると破綻する
• 情報が分散する

のであれば、
改善余地があります。

一方で、

面倒そう
＝必ず新機能へ移行する

でもありません。

現在の方法で十分な利用者もいるかもしれません。

そのため、

現在の方法で何ができていて、
どこに負担が残っているのか

を確認します。

「既存機能でどこまでできるか」を先に見る

新機能のアイデアが出ると、
新しい画面やデータ構造を考えがちです。

しかし、
既存機能の組み合わせでかなり近いことができる場合があります。

たとえば既存機能に、

• 未決事項一覧
• TODO
• 状態管理
• フィルター
• 元の会話へのリンク

がすでにあるなら、
新機能として必要なのは、

• 分類を一つ追加するだけ
• 横断表示するだけ
• 保存済みフィルターを追加するだけ

かもしれません。

この場合、

新しい専用画面を作る

より先に、
既存機能を使った簡易版で価値を確認することができます。

「使う条件」を整理する

新機能は、
存在するだけでは使われません。

たとえば「今日確認すべき案件一覧」を作るなら、

• 誰が見るのか
• いつ見るのか
• 何をきっかけに見るのか
• 何が表示されていれば判断できるのか
• どんな日は使わないのか

を整理します。

利用場面が確認できているか

たとえば、

• 毎朝案件を確認している
• 週次会議前に全案件を見ている
• 締切前に案件一覧を確認している

という既存行動があるなら、
新機能を差し込む場所が見えます。

逆に、

「便利そうだから使うと思う」

だけでは、
利用場面がまだ曖昧です。

新機能が既存運用へ与える影響も見る

便利な機能を追加しても、
操作や確認場所が増えることで複雑になることがあります。

たとえば、

• 未決事項一覧
• TODO一覧
• 顧客待ち一覧
• 今日の確認一覧

と画面が増えていくと、

結局どこを見ればいいのか分からない

という状態になる可能性があります。

そのため、

• 既存画面と重複しないか
• 確認場所が増えないか
• 新しい入力作業が増えないか
• 既存運用を置き換えるのか補助するのか

も確認します。

本格実装せずに確認できることは多い

新機能の価値を確認するために、
最初からシステムとして作る必要はありません。

手動で代替する

たとえば、
「今日確認した方がよい案件」を表示する機能なら、

人が候補案件を選び、
スプレッドシートへまとめるだけでも検証できます。

重要なのは、

自動で作られたか

ではなく、

その情報が実際の業務で使われたか

だからです。

簡易モックを使う

画面形式を確認したいなら、

• 専用画面
• 既存一覧へのフィルター
• 一覧上での強調表示

を簡易モックで比較できます。

ただし、
まだ機能自体の利用価値が確認できていない段階で、

どのデザインが好きですか？

と聞いても、
本質的な検証にはなりにくくなります。

まず価値、
その後に表示形式です。

「便利そう」ではなく行動を見る

新機能の事前検証では、

「便利そう」
「使いたい」
「あったら助かる」

という発言がよく出ます。

もちろん参考にはなります。

しかし、
実際の利用とは分けて考えます。

見るべきなのは、

• 実際に開いたか
• 最初の確認先として使ったか
• 表示された案件を確認したか
• 候補を追加したか
• 候補を削除したか
• 元の方法へ戻ったか
• 結局すべての案件を見たか

といった行動です。

既存手段が残っても失敗とは限らない

新機能を試したあとも、
既存手段が残ることがあります。

たとえば、

• TODO期限順も使う
• Slackメモも残す
• 重要な日は全案件を見る
• 週次ではリスト外の案件も確認する

といった状態です。

これだけで、

新機能には価値がない

とは言えません。

たとえば確認リストが、

全件確認をなくすための機能

ではなく、

先に見る案件を決めるための機能

として使われている可能性があります。

成功条件を、

既存手段を完全に置き換えたか

だけにすると、
実際の利用価値を見落とすことがあります。

反対事例は「使わない条件」を知る材料になる

たとえば、

顧客Aは、

「重要な日は全部の案件を見る」

顧客Cは、

「期限付きTODOだけなら既存の期限順で十分」

と言っているとします。

これは単純な否定材料ではありません。

Aについては、

• 通常日は確認リスト
• 高リスクな日は全件確認

という使い分けかもしれません。

Cについては、

• 期限付きTODOだけなら既存機能
• 顧客待ちや期限のない未決事項がある日は確認リスト

という条件差かもしれません。

反対事例を見る目的は、

機能を却下することではなく、
どの条件で価値が成立するかを知ること

です。

AIを使うかどうかは後から決める

AI機能を考えていると、

AIで自動判定できるか

から検証したくなります。

しかし、
その前に確認したいことがあります。

たとえば、

「今日確認すべき案件」をAIが選ぶ

機能を考えているなら、

まずは人が正しい候補を選んだ状態で、
そのリスト自体が役立つかを確認します。

役立たないのであれば、
AIの精度を上げても機能価値は生まれません。

自動化は段階的に考える

自動化は、
0か100かではありません。

たとえば、

1. ユーザーが手動で追加する

最も単純です。

2. 単純なルールで候補を出す

たとえば、

• 期限が近い
• 顧客待ち
• 長期間更新されていない

といった条件です。

3. AIが候補を提示する

文脈を見て、

「これは確認対象では？」

と候補だけ出します。

最終判断は利用者です。

4. AIが自動確定する

利用者確認なしで、
確認対象として扱います。

この順番で考えると、

AIを使わなければ成立しないのか

単純ルールで十分なのか

AI候補提示までで十分なのか

を分けられます。

AIの精度だけでは決められない

仮にAIがかなり正しく候補を出せても、

• 見落としたときの影響が大きい
• 誤候補を消す手間が大きい
• 利用者自身が判断したい
• 状態更新を自動化すると混乱する

のであれば、
候補提示型の方が適しているかもしれません。

逆に多少修正があっても、

• これまで全部手作業だった
• 候補があるだけで負担が減る
• 修正が簡単

なら、
十分役立つ可能性があります。

つまり、
AI精度だけでなく、
誤りの影響と修正方法まで見る必要があります。

まず「候補の作り方」を比較する

基本価値が確認できたら、
次に候補生成方法を比較します。

たとえば、

• TODO期限だけ
• TODO期限＋顧客待ち
• 複数条件によるルール
• 人が文脈を見て選んだ候補
• AIによる候補提示

です。

このとき、

• 足りない案件
• 不要な案件
• 利用者が追加した案件
• 利用者が削除した案件

を見ると、
どこまで自動化できそうかが分かります。

表示形式は候補内容を固定して比べる

専用画面とフィルターを比較するときは、
候補生成方法まで変えない方が分かりやすくなります。

同じ案件、
同じ確認理由を使って、

• 専用画面
• 一覧フィルター
• 案件一覧での強調

だけを変えます。

すると、

候補が良かったから使われたのか

UIが良かったから使われたのか

を混ぜにくくなります。

継続利用には「状態管理」も必要になる

確認リストが一度使われても、
継続運用では別の問題が出てきます。

たとえば、

• 確認済みとは何か
• 開いただけで確認済みか
• 対応まで終わったら確認済みか
• 未対応なら翌日も出すか
• 一度消した案件を再表示するか
• 顧客から返事が来たら自動で消すか

といった問題です。

これも、
いきなり自動化する必要はありません。

まず手動で、

• 確認済み
• 持ち越し
• 翌日再表示

を管理して、
実際に必要な状態を確認できます。

事前検証は「全部確認すること」が目的ではない

検証しようとすると、
確認したいことが増えていきます。

しかし、
本格実装前にすべての不確実性を消す必要はありません。

たとえば、
本番環境でしか分からないこともあります。

• 大量データでのAI精度
• 日々変化する情報への追従
• 長期間の継続利用
• 自動状態更新の安定性
• 対象市場全体での利用率

ここまで事前に証明しようとすると、
結局本番機能を作ることになってしまいます。

事前検証で重要なのは、
大きな開発判断を変える不確実性から先に減らすことです。

新機能を作る前の確認順序

整理すると、
次のような順番になります。

1. 顧客課題を確認する

何に困っているのかを見る。

2. 現在の代替手段を見る

今どうやって対応しているかを見る。

3. 既存機能でできることを見る

本当に新機能が必要かを確認する。

4. 確認済みと仮説を分ける

「分かっている」と思い込まない。

5. 手動で機能体験を再現する

本格実装せずに使ってもらう。

6. 発言ではなく利用行動を見る

実際に使われるかを確認する。

7. 反対事例を見る

使われない条件や、
既存手段で十分な条件を見る。

8. 自動化方式を比較する

手動、
単純ルール、
AI候補提示、
自動確定を分ける。

9. 表示形式を比較する

候補内容を固定してUIだけを見る。

10. 状態管理を確認する

確認済み、
持ち越し、
再表示などを整理する。

WorkPaletteで新機能開発前の確認を整理する

WorkPaletteでは、
新機能の検討をいきなり仕様設計へ進めず、
段階を分けて整理できます。

まず「機能要望分析」で、

• 顧客が何を求めているか
• 背景にどんな課題があるか

を整理します。

次に「機能追加判断」で、

• その機能を検討対象として残すか
• 今作るべきか
• 後回しにするか
• 作らないか

を判断します。

その後、
「新機能実装前提条件整理」で、

• 確認できている課題
• 現在の代替手段
• 既存機能でできること
• 利用成立条件
• 仮説に留まること
• 実装前に確認したいこと

を整理します。

さらに「新機能事前検証設計」で、

• どの未確認事項を先に見るか
• 手動で何を再現するか
• どんな利用行動を見るか
• AIをいつ検証するか
• 表示形式をいつ比較するか

を設計します。

流れとしては、

機能要望分析
↓
機能追加判断
↓
新機能実装前提条件整理
↓
新機能事前検証設計

です。

まとめ

新機能を作る前に確認したいのは、

「作れるか」

だけではありません。

重要なのは、

• 本当に解決したい課題は何か
• 顧客要望と課題を分けられているか
• 現在どうやって対応しているか
• 既存機能では足りないのか
• 誰がどの場面で使うのか
• 実際に使われるか
• 既存手段とどう使い分けられるか
• AIや自動化が本当に必要か
• どこまで実装せずに検証できるか

です。

特に、

顧客から要望された
＝実装すべき

課題がある
＝この機能で解決すべき

モックが好評
＝本番でも使われる

手動版が使われた
＝AIで自動化すべき

ではありません。

反対に、
実際の業務で手動版が使われ、
既存行動に変化が出ているのであれば、いつまでも課題確認からやり直す必要もありません。

確認済みのことは前提として残し、
まだ判断を変え得る未確認事項だけを次に検証する。

この考え方が、
新機能を作りすぎず、必要なところにはきちんと開発投資するための基本になります。