機能(Function)は、顧客や利用者の要求を満たすために、製品やサービスが果たす働きです。
設計では、特定の部品や技術へ直ちに結び付けず、何を行う必要があるかを抽象的に表します。

仮に、倉庫で荷物の所在を把握する製品を考えるとします。
「QRコードの読み取り装置を置く」は、実現手段の案です。
「荷物を識別する」「位置を記録する」「必要な人へ知らせる」と表せば、異なる技術でも実現できる機能として検討できます。

機能を分解して関係を調べる

荷物の所在を知らせるには、識別や記録に加え、情報を更新する、検索する、結果を表示するといった働きが必要になる場合があります。
全体の目的を、より具体的な機能へ分解します。

分解した機能を一覧にするだけでなく、何が入力され、何が出力され、どの順番でつながるかを考えます。
位置の情報が更新されないなら、検索と表示が正常でも、利用者へ古い場所を伝えてしまいます。
機能間で受け渡す情報や、更新のタイミングも設計の対象です。

必要な働きを明確にしてから、ハードウェア、ソフトウェア、人の作業へ割り当てます。
すべてを自動化する案と、一部を作業者が確認する案では、費用、誤り、運用の条件が異なります。

性能と確認条件を加える

「位置を知らせる」という機能だけでは、設計を評価できません。
どの範囲の荷物を、どの程度の精度で、いつまでに知らせるかを定めます。
これは、機能をどの程度実行するかという性能の要求です。

正常な場合だけでなく、識別できない荷物、通信の停止、誤った登録なども検討します。
機能単体の試験に加え、複数の機能をつないで、利用者が目的を達成できるかを確認します。
機能性設計では、こうした要求と実現手段の対応を扱います。

特徴や便益との関係

フィーチャーは、製品が備える具体的な特徴や解決手段として使われます。
便益は、顧客にとって望ましい結果です。
たとえば自動で位置を登録する仕組みがあれば、荷物を探す時間を減らせるかもしれません。
ただし、仕組みを実装した事実から、その結果が得られるとまでは断定できません。

なお、Functionは、事業や組織の文脈では、設計、営業、製造などの職能や部門を指すこともあります。
機能の分解と組織の分担を混同しないよう、文書では何の働きや集団を指しているかを明確にします。

参考資料