今重要なのは非機能!?非機能を明確にするには!!#1

今重要なのは非機能!?非機能を明確にするには!!#1

昨今、公共性が高いシステムであれば、天災であっても事業の継続性を求められます。情報の管理責任も厳しく問われるようになり、個人情報が流出すれば組織の信用は失墜します。開発対象のシステムは、そんな時代に稼働するものであると、まずは認識しなければなりません。社会的な要求により必要とされる非機能の明確化をこの記事では紹介したいと思います。

非機能要件が競争優位を制する!

ITを前提として業務を支援する情報システムは、汎用機の昔から繰り返し開発され、「今や成熟期にある」といってよいかもしれません。アプリケーションの基本的な操作パターンは、変わらないものとなりつつあります。例えば、「何かを選択した後→必要事項を入力し→登録(ボタンクリック)する」といった操作のパターンは、 どのアプリケーションでもあまり変わりません。対象ユーザーが従業員であろうと一般コンシューマーであろうと、機能面で差別化を図ることはますます難しくなりつつあります。

そこで昨今では非機能面がサービス全体の価値を決め、競争優位の絶対条件になる、といった事態が生じています。エンタープライズ系システムでは、事業の継続性や情報セキュリティといった確固たる「守り」が、これまで以上に重要になります。ユーザーである社内、関連会社、パート従業員の「働きやすさ」を求める声も高まっています。

また、従来従業員が行っていた操作を、お客様に委ねる例も増えてきました。そういった意味では「攻め」である「ユーザビリティ」が、より重要になってきます。コンシューマー向けシステムでは「非機能要件の重要度が、より高くなった」と言えます。ユーザビリティ、アクセシビリティ、パフォーマンス、セキュリティの強化は絶対条件です。競合に勝つためには、「攻め」を優先しつつ「守り」もおろそかにできません。

具体的には「迅速な処理(操作)」「快適性」「安全性」がポイントになります。「迅速な処理(操作)」は性能(パフォーマンス)、 「快適性」はユーザビリティ、「安全性」はセキュリティに起因します。

なお、ユーザビリティの快適性をここでは、「情報量や見栄えの良さ」による「使い勝手」という意味で使用することとします。セキュリティを確保しつつ、ユーザビリティと性能(パフォーマンス)がトレードオフにならないように、シンプルなUIを心掛け、非機能要件を明確にしていく必要があるのです。筆者は非機能要件を整理する際に、ソフトウェアの品質属性を表わすモデルである「FURPS +」(フープスブラス)と呼ぶ分類法を参考にしています。FURPS +は以下の頭文字です。

Functionality:機能性。画面や帳票など、利用者が扱うUIと処理要求を含みます。

Usability:操作性。使いやすさ。画面の使い勝手や見栄え等を含みます。

Reliability:信頼性。システムの停止要件(停止許容時間)、障害対策(ネットワークやハードウェアの二重化など)を含みます。

Performance : 性能。オンライン処理の応答時間やバッチ処理時間などを含みます。Supportability:保守の容易性。ハードの拡張性や互換性、プログラム保守のしやすさなどを含みます。

+ (Other):上記の分類に当てはまらないもの。主にプロジェクトの制約。例えばハードウエア設置場所等の物理的制約や、特定の要件を満たす操作端末(防爆仕様のハンディターミナルなど)、プログラミング言語の指定、セキュリティ要件等はここに分類されます。非機能要件はこのFURPS +のうち、F(機能性)を除いた「URPS+」が対象となります。また、U(操作性)はコンシューマー向けシステムにおいて重要性が高いので、別途の記事で説明します。

プロセスモデルから抽出

業務観点で表したプロセスモデル(業務フロー図)を作成(例:社員番号・パスワード入力→出勤開始→本日の担当の仕事確認ページ)し、その「業務の流れ」に登場する個々の業務プロセス(例:社員番号・パスワード入力, 出勤開始, 本日の担当の仕事確認ページ)から、必要な非機能要件を洗いだして行きます。再三述べている通り 「わかりやすい」業務フロー図は、開発者とユーザーの共通言語になりえます。

これを機能要件だけでなく非機能要件を明確化するために使わない手はありません。使えるものはどんどん活用しましょう。具体的には、各業務フローの流れと業務プロセスの5W2Hに注目します。5W2Hは、 When (いつ)、Where (どこで)、Who (誰が)、How(どのようにして)、How many(どれくらい)を定義しています。

特に、月次·日次やピーク時の処理件数、新規顧客数、1件当りの処理時間等のHOW many (どれくらい)については、ユーザーから参考情報を聞き取るとともに、現行システムの調査に基づき、新業務プロセスの処理量を想定して、新システムの要件として定義しています。あくまで想定にすぎませんが、非機能要件をまとめる際の参考になります。

またピーク時の処理を想定する際も、5W2Hを基にして行います。特にコンシューマー向けシステムの場合、ビジネス要求に遡って、システム要件として満たすべき非機能要件を想定し、定義していく必要があります。

業務プロセスの5W2Hの抜粋と非機能要件の関係を以下に列挙します。

(1)When:いつ→ 実施タイミング(事前/開始条件を含む)

「24時間随時」―――エンタープライズ系システムの場合、グローバルに展開するシステムであればありうることです。

「24時間随時」―――コンシューマー向けシステムの場合当たり前のことです。主に「信頼性」「保守の容易性」に関係します。

(2)Where:どこで→場所、組織

「事務所」「倉庫」「外出先」―――エンタープライズ系システムの場合、デスクワークだけでなく、倉庫で、外出先で作業することはありうることです。

「場所を問わず」―――コンシューマー向けシステムの場合、当たり前のことです。主に「操作性」「性能」「その他」に関係します。

(3)Who:誰が→担当者、一般ユーザー

「該当部署担当者」「窓口パート社員」「協力関連会社担当者」―――エンタープライズ系システムの場合、社員だけでなくパート社員、そして昨今は協力会社の担当者に機能を開放して使用させるケースも見うけられます。

「一般ユーザー」―――コンシューマー向けシステムの場合、誰がユーザーとなるかわからないのが当たり前のことです。セキュリティに留意する必要があります。主に「操作性」「性能」「その他」に関係します。

 

(4)How:どのようにして→ ユーザーシナリオから抽出した実施要領(制約条件を含む)

ユーザーシナリオ内の文言より「該当システムに入力することにより」―――エンタープライズ系システムの場合、上記、When、Where、Who との組み合わせを考慮する必要があります。主に「操作性」「性能」に関係します。また、基本的な項目入力だけではなく、昨今はAI, IOTを通じてデータ操作を行う場合を想定する必要があります、その場合は、「その他」にも関係します。

ユーザーシナリオ内の文言より「該当UIに入力することにより」―――コンシューマー向けシステムの場合、When、Where、 Whoが広範囲になるため、実施要項も多肢にわたる可能性があります。ペルソナを中心に、想定しうる状況に対応可能とします。入力対象デバイスはPC、スマートフォン等日々増えています。「操作性」「性能」に関係します。

(5) How many:どれくらい→データ量、応答時間も含みます。

「XXX /D」―――エンタープライズ系システムの場合、該当機能の性能の目安になります。業務プロセスの定義では「ユーザー視点」からの数値目標が定義されています。このユーザー視点ともに想定しうる技術視点での数値を想定します。主に「性能」「その他」に関係します。

「XS以内 XXXXX/d」―――コンシューマー向けシステムの場合、応答時間と処理件数の目安になります。「練作性」「性能」「保守の容易性」「その他」に関係します。

非機能・非機能要件の明確化の具体的な手順を次の記事で紹介しています。もしよろしければ続いてお読みください。
→「今重要なのは非機能!?非機能を明確にするには!!#2

テックカテゴリの最新記事