何を決めるか

機能要件は、「リニューアル後のWebサイトの役割」を機能単位で選定し定義します。思い当たる機能をピックアップして、それぞれを実装対象として採用するかどうかを判断します。

機能要件は後工程の前提条件

機能要件で確定した内容は、以降の工程の前提条件として扱われます。実装対象となる機能を基に必要な工数が算出され、制作・検証・公開までのスケジュールが組まれ、見積が作成されます。

機能要件の成果

機能要件の成果は、各機能において、採用（やること）・見送り（やらないこと）・保留（できないかも）が整理され、関係者間で共有できる状態になっていることです。共有できる状態が整っていることで、後から見返した際に判断の経緯が説明でき、関係者間で認識を共有しつつ次の工程に進むことができます。

1〜2行で判断に使える粒度

ジャッジの軸は、機能を検討するたびに立ち戻る判断基準です。内容は多くなくてよく、1〜2行で確認できる粒度にまとめます。最低限そろえておきたいのは、次の3点です。

長文化させない

ジャッジの軸は、説明のための文章ではなく、判断に使うための基準です。細かい背景説明や前提条件を盛り込みすぎると、確認や判断することがむずかしくなります。短く、すぐに判断できることが重要です。

機能の採否で迷うことが多い場合は、軸そのものを見直します。目的・対象・運用前提のうち、どこが曖昧になっているかを確認し、必要に応じて軸を整え直します。

機能の洗い出し

機能要件の整理は、必要になりそうな機能を広く洗い出すところから始めます。この段階では、実装可否や優先度を気にせず、思いつく機能を機能単位でどんどんピックアップします。要望やアイデアを出し切ることで、検討漏れを防ぎ、必要機能の全体像を把握することができます。

また、ピックアップした機能はどこかに溜め込まず、次の「選定」に速やかに移行します。「洗い出し」と「選定」を分けて進めることで、テンポよく機能要件を整理することができます。

振り分け先

機能のピックアップが終わったら、ジャッジの軸を使って一次選定を行います。この工程では、洗い出した機能を一つずつ確認し、今回の要件として扱うかどうかを整理します。

ここでは機能を次の2つに振り分けます。

一次選定の判定観点

一次選定では、あらかじめ定めたジャッジの軸に照らして機能を選定します。判断に使う基準は、次の3点です。

「やらないこと」が確定すると見えてくるもの

一次選定で「やらないこと」が整理されると、プロジェクト全体の輪郭が明確になります。また、「やること」に振り分けられた機能がなぜ必要なのかが明確になり、判断の背景を説明しやすくなります。

二次選定の箱

一次選定で「やること」に振り分けられた機能は、現実的な条件を基に「できないかも」を整理する二次選定へと進みます。実装の方向性をより具体的にし、機能要件の精度を高めていきます。

「できないかも」の理由ラベル

「できないかも」に分類した機能には、理由をラベルづけします。理由を明示することで、何が判断を止めているのかが見えやすくなります。

「できないかも」の扱い

「できないかも」に分類した機能は、今後の検討事項につなげる可能性があるため記録に残します。リニューアル後の運用フェイズや第2フェーズで再度議題に上がることがあるためです。また、理由ラベルが付いていれば、確認すべき事項が明確になり、再検討の際の判断が進めやすくなります。

やることが増えすぎる

選定での判断が曖昧だと、「やること」に機能が集中します。機能が増えるほど、必要な工数や確認事項も増え、コスト・納期・品質・運用のすべてに影響が出てしまいます。

やらないことが曖昧

「やらないこと」が曖昧だと、検討対象となる機能の範囲が定まらず、同じ議論が繰り返されやすくなります。

できないかもが未ラベル

なぜ判断が保留されたのか分からなくなり、後工程で再調整が必要になる可能性があります。

軸が弱いまま機能を詰める

ジャッジの軸が曖昧なまま進めると、判断が都度ブレ、議論が堂々巡りになりやすくなります。

判断を“形”にする

機能から派生するリスクは、判断を曖昧にせず後から参照できる形として残すことが重要です。特に「やらないこと」をきちんと決めておくと、機能範囲の境界線（ライン）が明確になります。また、「できないかも」は理由ラベルを付けてリニューアル後の検討材料として残すことで、今回の事案と区別することができます。