機能を削る判断基準を理解したあとも、実際に自分のアイデアの機能リストを目の前にすると、「これは削れない気がする」「これも後回しにできそうだけど不安」と、なかなか判断が進まないことがあります。この記事では、実際の仕分け作業を進めるための、具体的な考え方を解説します。
この記事で分かること
機能を削る判断基準そのものは、別記事で解説していますが、実際に手を動かして仕分けを進める段階では、また別のコツが必要になります。この記事では、実際の仕分け作業をスムーズに進めるための、具体的な方法を紹介します。
結論を先に示すと、実際に仕分けを進める際に意識したいのは次の3つです。
- 機能をすべて書き出してから、判断を始める
- 「削れない」と感じた機能に、理由を言葉にしてみる
- 一人で判断せず、他の人の視点を借りる
判断基準（何が「核となる機能」で、何が「後回しにできる機能」か）を知っていることと、実際に自分のリストを目の前にしてその基準を当てはめられることは、まったく別のスキルです。多くの人が「基準は分かったのに、実際にやってみると手が止まる」というギャップにつまずきます。この記事は、そのギャップを埋めるための、実務的な手順に絞って解説します。
なぜ「実際の仕分け作業」に、別のコツが必要なのか
判断基準を知っているだけでは、実際の仕分け作業がスムーズに進むわけではありません。多くの人が、実際にリストを目の前にすると、判断基準を理解していても、感情や思い入れが判断を鈍らせてしまいます。特に、長い時間考えてきたアイデアほど、機能一つひとつへの愛着が強くなり、客観的な判断が難しくなる傾向があります。
これは能力の問題ではなく、構造的に起きる問題です。半年以上そのアイデアを考えてきた人にとって、機能のひとつひとつは「思いついた瞬間の解決したい課題」と結びついています。だからこそ、「この機能は削れる」と頭では分かっていても、「でも、あの時に感じた不便さを解消するために思いついたのに」という感情が判断を鈍らせます。この感情自体は悪いものではありませんが、それだけで機能の優先順位を決めてしまうと、最初のリリースに必要以上の機能が積み重なり、開発コストと期間が膨らむ原因になります。
この記事で紹介する手順は、判断基準そのものではなく、「客観的に判断するための、作業の進め方」に焦点を当てています。基準を知っていても、実際の作業でつまずく人は多いため、両方をあわせて理解しておくことをおすすめします。
手順1：機能をすべて書き出してから、判断を始める
多くの人が、機能を思いついた順に、削るか残すかをその場で判断してしまいます。しかし、この進め方は、後から思いついた機能と、最初に思いついた機能を、公平に比較できないという問題があります。
まずは、思いついている機能をすべて、判断せずにリストアップすることから始めてください。「これは大した機能じゃないから書かなくていい」という自己判断も、この段階では挟まないことがポイントです。すべてを並べてから、初めて優先順位の判断に取りかかることで、より客観的な仕分けができます。
書き出す際の具体的なやり方
紙でもスプレッドシートでも、メモアプリでも構いません。大事なのは「1機能=1行」で書くことです。「顧客管理機能」のような大きなまとまりで書いてしまうと、その中に「検索機能」「タグ付け機能」「エクスポート機能」など、実際には複数の機能が含まれていることに気づけません。粒度が粗いまま仕分けを進めると、「顧客管理機能は削れない」という大雑把な判断になり、本当は後回しにできる細かい機能まで一緒に残ってしまいます。
書き出す際の目安は次のような粒度です。
- 「顧客の名前で検索できる」（○ ちょうどよい粒度）
- 「顧客管理機能」（× 粗すぎる。中に複数の機能が混在している）
- 「検索ボックスに入力すると1文字ごとに候補が絞り込まれる」（× 細かすぎる。実装方法の話になっている）
機能を「ユーザーが何をできるか」という単位で書くと、ちょうどよい粒度になりやすいです。実装の細かい話（アニメーションの有無、ボタンの色など）はこの段階では扱わず、後回しにして構いません。
何個くらい書き出せばいいのか
個人の複業で始める小規模なサービスであれば、10〜30個程度の機能が出てくることが多いです。もし50個を超えるようであれば、粒度が細かすぎる可能性があるので、いくつかをまとめて考えられないか見直してみてください。逆に5個以下しか出てこない場合は、まだアイデアの具体化が浅い可能性があるため、「利用者が実際にどんな操作をするか」を1つずつ想像しながら書き出してみましょう。
手順2：「削れない」と感じた機能に、理由を言葉にしてみる
リストアップした機能の中で、「これは削れない」と感じるものがあれば、その理由を具体的な言葉にしてみてください。「なんとなく必要な気がする」という感覚だけで残すと、後から見返した際に、本当に必要だったのかを判断しづらくなります。
例えば、「顧客の名前で検索できる機能は削れない」と感じた場合、「なぜ削れないのか」を考えてみます。「顧客が増えたら、名前で探せないと使い物にならないから」という理由が明確になれば、それは核となる価値に関わる機能だと判断できます。一方、理由が「あったら便利そうだから」程度であれば、実は後回しにできる機能かもしれません。
「理由の強さ」を見分けるための具体例
理由には強さの違いがあります。以下は、同じ「削れない」という判断に対して、理由の強さが異なる具体例です。
強い理由（核となる機能である可能性が高い）
- 「この機能がないと、そもそもサービスの目的が成立しない」
- 「利用者が最初の1回で使い方が分からず、離脱してしまう」
- 「この機能がないと、代わりに手作業（電話・紙・LINE）でカバーする手間が今より増える」
弱い理由（後回しにできる可能性が高い）
- 「競合サービスにあるから、うちにもないと格好がつかない」
- 「将来的に欲しくなりそうだから、最初から入れておきたい」
- 「作れそうだから、せっかくなら入れておきたい」
- 「自分が過去に別の仕事で欲しかった機能だから」
弱い理由に当てはまる機能は、リリース後に実際の利用者の声を聞いてから追加するかどうかを判断しても遅くありません。逆に強い理由に当てはまる機能を削ってしまうと、サービスとして最低限の役割を果たせなくなる可能性があるため注意が必要です。
理由を書く際に使える質問
「なぜ削れないのか」を考える際、次のような質問を自分に投げかけると、理由が明確になりやすくなります。
- この機能がなかった場合、利用者はどう困るか。具体的な場面を想像できるか
- この機能がなくても、別の手段（手作業・既存ツールの併用）で一時的に代替できないか
- この機能を使うのは、想定する利用者の何割くらいか
- 「あったら嬉しい」と「ないと成立しない」のどちらに近いか
これらの質問に答えていく過程で、「実は代替手段があるから、最初はなくても大丈夫かもしれない」と気づくことがよくあります。
手順3：一人で判断せず、他の人の視点を借りる
自分1人で仕分けを進めていると、思い入れのある機能ほど「削れない」と感じやすくなる傾向があります。可能であれば、身近な人に機能のリストを見せて、「この中で、本当に最初から必要だと思う機能はどれか」を聞いてみることをおすすめします。
第三者の視点は、自分では気づけなかった思い込みに気づかせてくれることがあります。特に、想定する利用者に近い立場の人からの意見は、優先順位づけの参考として価値があります。
誰に聞けばいいか
聞く相手によって、得られる視点が変わります。
- 想定する利用者に近い人：実際に使う場面を想像しやすいため、「あったら便利」と「ないと困る」の違いを直感的に判断してもらいやすい
- 開発の知識がある人（AIや開発会社を含む）：技術的な難易度や、実装コストの観点から意見をもらえる
- 利害関係のない第三者（家族・友人）：思い入れがない分、率直な意見を言いやすい
理想は複数の立場の人に聞くことですが、最初は1人でも構いません。「自分以外の視点を最低1つ入れる」ことが、思い込みに気づくための第一歩です。
聞き方の工夫
ただ機能のリストを見せるだけでは、相手も答えづらいものです。次のように聞き方を工夫すると、より具体的な意見が得られます。
- 「この中で、もし1つしか作れないとしたら、どれを残す？」と極端な状況を仮定して聞く
- 「この機能がなかったら、あなたはこのサービスを使う気になる？」と機能ごとに聞く
- 実際の利用シーンを一緒に想像してもらい、「その場面でこの機能がないとどうなる？」と聞く
こうした聞き方をすると、相手も「なんとなく良さそう」ではなく、具体的な理由をつけて答えてくれるようになります。
仕分けの際に、陥りやすい失敗パターン
実際に仕分けを進める中で、次のような失敗パターンに陥ることがあります。自分がどのパターンに当てはまりやすいかを知っておくと、仕分け作業の途中で軌道修正しやすくなります。
失敗パターン1：全部が「削れない」に分類されてしまう
思い入れが強いアイデアほど、すべての機能が「絶対に必要」に見えてしまうことがあります。この場合、「もしこの機能が全くなかったら、サービスとして成立しないか」を、機能ごとに個別に、厳しく問い直してみてください。
このパターンに陥りやすいのは、特にアイデアを長期間温めてきた人です。「せっかく思いついたのだから」という気持ちが、機能を削ることへの抵抗感を生みます。対処法としては、いったんリストを閉じて1日以上時間を置き、冷静な状態で見直すことが有効です。時間を置くだけで、「これは本当に最初からいるのか」と客観的に見られるようになることがよくあります。
失敗パターン2：削った機能への未練が残り、実装してしまう
一度「後回し」に分類したはずの機能を、実装の途中で「せっかくだから」と組み込んでしまうことがあります。削る判断をしたら、実装が始まる前に、その判断をAIや開発会社にも明確に伝え、範囲を固定することをおすすめします。
このパターンは、仕分けの結果を文書として残していない場合に特に起きやすくなります。「後回しにする」と口頭やその場の記憶だけで判断すると、実装が始まってから「あれ、これも入れられそうだから入れてしまおう」という判断が、誰にも気づかれずに積み重なっていきます。結果として、最初に決めた予算や期間を超えてしまう、いわゆる「スコープの肥大化」が起こります。
失敗パターン3：機能ごとの判断基準がぶれる
リストの前半では厳しく判断していたのに、後半になると疲れてきて「まあこれもいいか」と判断が緩くなってしまうことがあります。特に機能数が多い場合に起きやすい失敗です。
対処法としては、1回の作業で全部を判断しようとせず、10〜15個ごとに休憩を入れる、あるいは日をまたいで数回に分けて仕分けを行うことが有効です。また、判断基準（手順2で使った質問など）を紙に書いて手元に置いておき、常に同じ基準で見返すようにすると、判断のブレを減らせます。
失敗パターン4：機能単位ではなく「テーマ」で丸ごと残してしまう
「予約機能は全部大事」のように、機能群をひとまとめにして「削れない」と判断してしまうケースです。実際には、予約機能の中でも「予約を受け付ける」は核であっても、「予約のキャンセル理由を分析するレポート」は後回しにできることが多いです。手順1で「1機能=1行」の粒度にこだわった意味がここで生きてきます。テーマ単位で判断が止まりそうになったら、いったんそのテーマの中身をさらに分解してから、もう一度個別に問い直してみてください。
専門知識を活かしたツールでの、仕分けの難しさ
専門分野の業務知識を反映したツールでは、専門家である自分自身にとって「当たり前に必要」と感じる機能が多く、仕分けが特に難しくなる傾向があります。この場合、専門知識のない人（想定する利用者に近い立場の人）に、機能リストを見てもらうことが、特に有効な確認方法になります。
専門家の視点だけでは見えない、利用者にとっての優先順位を知ることで、より実態に近い仕分けができます。
例えば、税理士が自分の専門知識を活かして「確定申告の書類作成を支援するツール」を作る場合、税理士本人にとっては「この特例への対応」「あの控除の自動計算」がどれも「当然入れるべき機能」に見えてしまいます。しかし、実際に使う利用者（個人事業主など）にとっては、まず「入力が簡単であること」「結果がすぐに分かること」の方が優先度が高いことが少なくありません。専門知識が深いほど、「業界の常識」と「利用者が本当に困っていること」の間にズレが生まれやすくなるため、意図的に外部の視点を取り入れる必要があります。
仕分けの結果を、文書として残しておく
仕分け作業が終わったら、その結果を簡単な文書として残しておくことをおすすめします。「核となる機能」「後回しの機能」「代替手段で対応する機能」を、それぞれリストにまとめておくと、開発会社やAIに要望を伝える際の資料として、そのまま活用できます。
この文書は、開発の途中で「あれもやってほしい」という要望が出てきた際にも、「これは最初に後回しと決めた機能だ」と冷静に振り返るための基準にもなります。仕分けの結果を記録として残しておくことは、後々の判断のブレを防ぐ効果があります。
こうして仕分けたリストは、その後のPoC（試作）から本番開発へと進む段階でも、そのまま判断材料として使えます。なお、PoCを実際に本番システムへ引き上げる際にどの機能を絞り込むべきかについては、本番化を見据えた機能の絞り込み方でも詳しく解説されている。
文書に含めておきたい項目
シンプルな文書で構いませんが、次の項目を含めておくと、後から見返した際にも判断の経緯が分かりやすくなります。
- 核となる機能：機能名と、削れないと判断した理由（手順2で言葉にした内容）
- 後回しにできる機能：機能名と、後回しにした理由、いつ追加を検討するかの目安（例：利用者が100人を超えたら検討する）
- 代替手段で対応する機能：本来作りたかった機能と、当面どう代替するか（例：自動通知機能の代わりに、最初は手動でメールを送る）
- 仕分けを行った日付：時間が経つと状況が変わることもあるため、いつの判断かを残しておく
この文書はA4用紙1枚程度の分量で十分です。分厚い資料を作る必要はなく、あとで見返して「なぜこの機能を後回しにしたか」を思い出せる程度の情報があれば役に立ちます。
仕分け作業のチェックリスト
実際に仕分けを進める際、次のチェックリストを使うと、この記事で紹介した手順を漏れなく確認できます。
- [ ] 機能を思いついた順にその場で判断せず、まず全部を書き出したか
- [ ] 1機能=1行の粒度で書けているか（大きすぎるまとまりになっていないか）
- [ ] 「削れない」と感じた機能について、理由を具体的な言葉にしたか
- [ ] その理由が「ないと成立しない」に近いか、「あったら便利」に近いかを確認したか
- [ ] 自分以外の視点（想定利用者・第三者・AIや開発会社）を最低1つ取り入れたか
- [ ] 全部が「削れない」に分類されていないか、厳しく問い直したか
- [ ] 判断基準が途中でぶれていないか（疲れて判断が緩くなっていないか）
- [ ] 「テーマ」単位で丸ごと残さず、機能単位まで分解して判断したか
- [ ] 仕分けの結果を、簡単な文書として残したか
- [ ] 後回しにした機能について、開発が始まる前に開発会社やAIに範囲を伝えたか
このチェックリストをすべて満たせなくても構いませんが、特に「文書として残す」項目だけは、後々の判断のブレを防ぐために意識しておくことをおすすめします。
店舗の業務改善ツールで、仕分けを進める際のコツ
店舗の業務改善のためのツールでは、実際に日々の業務を担っているスタッフの視点を借りることが、特に有効な仕分けの方法になります。経営者である自分の視点だけでは気づけない、現場での実際の困りごとや優先順位を、スタッフから聞き出すことで、より実態に合った仕分けができます。
スタッフに機能のリストを見せて、「この中で、実際の業務で一番困っているのはどれか」を聞いてみることをおすすめします。経営者の視点と現場の視点は、必ずしも一致しないことがあるため、両方の視点を踏まえた仕分けが、実際に使われるツールを作る上で重要です。
例えば、経営者は「売上のグラフをきれいに見せる機能」を重視しがちですが、現場のスタッフにとっては「シフトの空き状況が一目で分かる機能」の方が、日々の業務でずっと重要度が高いということがよくあります。経営者目線の「見せたい機能」と、現場目線の「使いたい機能」がズレている場合は、まず現場が困っている機能を核として残し、経営者向けの機能は後回しにする判断も検討する価値があります。
業種別に見る、仕分けの具体例
仕分けの考え方は共通していますが、実際にどう判断すればいいかは、業種やサービスの種類によってイメージしにくいことがあります。ここでは、いくつかの業種を例に、核となる機能と後回しにできる機能の具体的な分け方を紹介します。あくまで一例であり、実際の判断は自分のサービスの状況に合わせて行ってください。
例1：予約管理サービス（美容室・整体院向け）
- 核となる機能：空き時間の確認、予約の受付、予約日時の変更・キャンセル
- 後回しにできる機能：予約履歴からの来店頻度分析、リピート率のグラフ表示、スタッフ別の売上ランキング
- 代替手段で対応する機能：予約のリマインド通知（最初は手動でメールやLINEを送る運用で代替し、利用者が増えてから自動化を検討する）
このケースでは、「予約が取れる・変わる」という最低限の機能がなければサービスとして成立しませんが、分析やランキングといった「経営を助ける機能」は、利用者（店舗側）が実際に使ってみてから欲しくなるものであり、最初から用意する必要性は低いことが多いです。
例2：個人事業主向けの請求書作成サービス
- 核となる機能：請求書の作成、PDFでの出力、取引先の登録
- 後回しにできる機能：複数の通貨への対応、承認フローの多段階化、経費精算との連携
- 代替手段で対応する機能：請求書の自動送付（最初は作成したPDFを自分でメール添付する運用で代替する）
個人事業主が最初に困っているのは「請求書をきれいに、早く作れること」であり、複数通貨や複雑な承認フローは、事業規模が大きくなってから必要になる機能です。最初から対応しようとすると、開発コストが大きく膨らみます。
例3：地域コミュニティ向けの情報共有アプリ
- 核となる機能：投稿の作成・閲覧、コメント、地域ごとの絞り込み表示
- 後回しにできる機能：投稿の自動翻訳、既読管理、通知のカスタマイズ設定
- 代替手段で対応する機能：不適切な投稿の通報機能（最初は運営者が目視で確認する運用で代替する）
コミュニティ系のサービスは「人がある程度集まってから」初めて価値が出てくる機能（自動翻訳、細かい通知設定など）が多く含まれがちです。まずは少人数でも回る核の機能に絞り、利用者が増えてから機能を拡張する方が、開発コストを抑えられます。
これらの例からも分かるように、「核となる機能」に共通しているのは、「その機能がないと、サービスの一番基本的な使い方自体が成立しない」という点です。逆に「後回しにできる機能」は、多くの場合「サービスの利用が進んだ後に、より便利にする・より深く分析する」という役割を担っています。この違いを意識すると、業種が変わっても同じ考え方で仕分けを進められます。
仕分けの精度を上げるための、追加の視点
ここまで紹介した手順とチェックリストで、多くのケースは仕分けを進められますが、さらに精度を上げたい場合に使える、追加の視点をいくつか紹介します。
視点1：機能を「頻度」で並べ替えてみる
利用者がその機能を「どれくらいの頻度で使うか」を想像し、リストを並べ替えてみてください。毎回使う機能ほど核となる可能性が高く、月に1回程度しか使わない機能は後回しにできる可能性が高くなります。頻度という軸を加えるだけで、「なんとなく大事そう」という曖昧な感覚を、具体的な判断基準に変換できます。
視点2：機能を「作る手間」でも見てみる
削れない機能だと判断したものの中に、実は実装の手間が非常に大きいものが混ざっていることがあります。この場合、「核となる価値は保ちつつ、実装の手間を下げる簡易版」を検討できないか考えてみてください。例えば、「AIによる自動分類」が核となる機能だと判断した場合でも、最初は「あらかじめ決めた数種類のカテゴリから手動で選ぶ」という簡易版に置き換えられることがあります。核となる価値（分類できること）を保ったまま、実装コストを下げられる場合は、この簡易版から始めるのも有効な選択です。
視点3：「他社にない機能」を疑ってみる
「これはうちの独自の強みだから、絶対に入れたい」と感じる機能ほど、実は検証されていない仮説であることが少なくありません。独自性の高い機能は、実際に利用者に使われて初めて価値が証明されます。最初のリリースでは、まず基本的な価値（他社と似ていても構わない、当たり前に求められる機能）で利用者に使ってもらい、独自の強みとなる機能は、反応を見ながら早い段階で追加する、という順番を検討する価値があります。
まとめ：仕分けは一度で完璧を目指さなくていい
この記事で紹介した3つの手順――「すべて書き出してから判断する」「理由を言葉にする」「他の人の視点を借りる」――は、どれも一度やれば終わりというものではありません。仕分けの結果は、書き出してみて初めて気づくことも多く、他の人に見せて初めて思い込みに気づくこともあります。1回で完璧な仕分けをしようとせず、まずは大まかに分けてみて、他の人の意見を聞きながら少しずつ精度を上げていく、という進め方をおすすめします。
また、仕分けに時間をかけすぎて、いつまでも開発に着手できないという状態も避けたいところです。この記事のチェックリストを一通り満たせたら、いったんその仕分け結果を確定させ、開発会社やAIとの打ち合わせに進む、という区切りをつけることも大切です。仕分けの目的は「完璧な優先順位を決めること」ではなく、「限られた予算と期間の中で、最初に何を作るべきかを、後から見返しても納得できる形で決めておくこと」にあります。
この記事の次に読みたい記事
機能の仕分けができたら、次は実際に開発会社との打ち合わせで、この仕分けをどう伝えるかを考えてみましょう。あわせて次の記事も参考にしてください。
仕分けを終えたら、開発期に入ってから、最初に開発会社へ連絡するまでにやっておくことや、相見積もりの金額差が2倍以上あったとき、何を疑うべきかも参考になります。
