社内SEになりました

社内SEは本当に楽なのか?ユーザー系IT企業とSierとの違いは?これからIT企業への就職や転職を考えている人むけに、ユーザー系IT企業から社内SEに40代で転職した筆者がITエンジニアの仕事内容やプロジェクト管理のノウハウ等をご紹介。

RFPの書き方:機能要求、非機能要求

RFP の書き方の説明です。

第六回は、機能要求と非機能要求の説明です。

1.機能と非機能の違い

新しくシステムを構築する際には、要求定義の中で「機能要求」と「非機能要求」を決めていきます。

「機能要求」は、業務部門の人たちが「システムで実現したいこと」です。

「要求定義書」とか「業務要件定義書」と呼ばれるものの大半は「機能要求」です。新規構築だけでなく、規模の大きい改修の場合にも機能要求の要求定義書は作成することが多いです。

それに対して「非機能要求」は、業務部門の人たちからすると「当たり前に実現されると思っていること」です。

・毎日システムを使いたい
・ボタンを押したら数秒で画面遷移してほしい
・障害が起きてもすぐに復旧させてほしい
・情報漏洩しないようにしてほしい

これらは当たり前のことのように思えますが、システムを構築する際には、一つ一つ決めていく必要があります。

そしてそれらは、コストに直結するものが多いため、システム部門だけではなく、業務部門の人たちと一緒に決めていく必要があります。

通常は新規構築のときのみ実施しますが、大規模な機能追加やハードリプレースなどでも実施する場合があります。

2.機能要求

機能要求は、システムで実現したいことを記載します。

主に対象業務の新旧業務フロー、ビジネスルール、画面・帳票イメージで構成されます。

業務フローは、誰が、いつ、どこで、どんなデバイス(PC?スマフォ?ハンディターミナル?等)で、どんなことをするのか、が分かるように、業務の区切りの単位でフロー化します。特に新の業務フローでは、システム化する範囲とシステム化しない(手作業等)範囲を明確にすることが重要です。

ビジネスルールは、簡単に言えば分岐条件や計算式です。

例えば発注をする際、100万円までは課長の承認で良いけど、100万円を超える場合には部長の承認が必要、といった業務のルールです。このビジネスルールが多ければ多いほど、システムは複雑になります。

機能要求の段階で漏れが多いと見積もりに影響し、プロジェクト開始後に費用でベンダーと揉める原因になります。

画面・帳票イメージは、言葉のとおりですが、とても重要です。

業務部門の人たちは画面や帳票のイメージがないと、なかなか新システムを使って自分たちの業務がどう変わるのかをイメージできません。レイアウトは確定したものでなくて良いので、主要な画面や帳票については一通り作成した方が良いです。

ベンダーも画面・帳票イメージがあると、見積もりのブレも少なくなります。特に帳票がある場合には、一度に出力するページ数や既存プリンターの性能なども明記します。

その他に既存システムとの連携がある場合には、インターフェースのタイミングやレイアウト、データ量などを記載します。

3.非機能要求

非機能については当ブログの「非機能要件」のカテゴリーで詳しく書いているので、ここでは概要を。

非機能要求は費用に直結するものが多いため、業務部門と共同で、過剰でも過小でもない落としどころを見極める必要があります。

また非機能要求の提示が不十分だと、プロジェクト開始後にベンダーと費用で揉めるリスクが高くなるので、しっかりと要求をまとめることが重要です。

【振り返り】

今回は RFP に記載する機能要求と非機能要求の説明でした。次回は提案方法と評価方法の説明です。

①はじめに(用語集や関連資料など)、目的と背景、対応概要、スコープ
②スケジュール、体制、役割分担、作業環境
③工程定義、成果物
④前提条件、制約条件、リスク、課題
⑤機能要求、非機能要求
⑥提案方法、評価方法