要求仕様書には、システムに求める機能を列挙しさえすればよいと思っていないだろうか。それでは経営者や供給者にシステムの全体像を伝えられない。求める機能の提示は確かに重要ではあるが、要求仕様を構成するほんの一部にすぎないことを知っておこう。前回(要求仕様書の用途を知り必要事項をもれなく記載する:第2回)、システム取得者側が要求仕様書に記載すべき必須項目とオプション項目を挙げた。今回は、それぞれの項目を詳細に見ていく。要求仕様書は必ずしも取得者側がすべて自力で完成させる必要はない。システムの規模や技術的な難易度によっては、システム供給者側に任せたほうがよい項目もある。「なぜその項目を書く必要があるのか」「どのような点に留意して書くのか」を取得者側が理解しておくことは重要である。要求仕様の必須項目─利用イメージを具体的に描くまず、要求仕様書に必ず記載すべき10項目について述べる(表1)。これらの項目を記述する際は、抽象的な議論にならないよう心がける。日々の業務における問題点、困っていること例)在庫管理業務で入力作業の負荷が高い。システム化の目的・狙いシステム化にかかわる当事者全員が力を集約するには、これから進むべき方向について合意しておくことが不可欠だ。このため、要求仕様書にはまずシステム化の目的や狙いを明記する。「業務プロセスを効率化することでコストダウンを図る」「新商品を投入することで市場を活性化し、収益を増加させる」といったことである。この項目では、目的に加えてシステム化することで得ようとしている効果について触れる。供給者側が、取得者の期待をまっとうできるかどうか検討するための指標になるからだ。効果については、「年間5000万円のコストダウン」「1カ月平均1000円の収益増加」などと具体的な数値目標を設定する。これにより、システムの規模や範囲が見えてくる。この「目的・狙い」の内容が細かすぎると、システム化の全体像が分かりにくくなってしまうので注意したい。コストダウンの内訳や収益増の算出根拠といった詳細に言及する場合は、「期待する効果」というオプション項目を別に設けるとよい。現行の問題点ここではシステム化したい理由や背景を記述し、なぜこのシステムが必要なのかを鮮明にする。自社が現在どのような問題を抱えているかや、何に困っているのかを「○○業務における△△作業の負荷が高い。作業時間は□□時間/月」といった形で具体的に記述する。次に、上で明らかにした問題点をどのように解決するかを記述する。システム化による解決策が有効であるかを論証する。この論証を怠ると、要求仕様書を見て投資判断する経営者に「わざわざシステムを開発しなくても業務運用の工夫で問題を解決できるのではないか」という疑問を感じさせる。解決策の概要は、以下のように記述する。考えられる解決策をすべて列挙し、それら1つひとつがシステム化による解決策かそれとも業務運用による解決策かを整理する。そのうえで、システム化による解決策が最善であると考えられる理由を明らかにする。この項目は経営者や供給者に全体感をつかんでもらうことが目的なので、ここでは概略にとどめる。詳細な内容は後述する「要求内容」で明らかにすればよい。次に、誰がどのようにそのシステムを使うかを明らかにし、システムの具体的なイメージを描く。いった利用者のプロフィールを記述する。そのうえで、その利用者たちがシステムをどのように使うかを明示する。要求すべき機能この項目では、3で提示したものをより具体的な機能に落とし込む。実装イメージを供給者に伝えることが目的であり、要求仕様書のなかで最も重要な項目である。記述する際は、あまり抽象的にならないよう留意し、要求仕様を作成する段階で分かっていることをすべて書くべきである。「クライアントPCを監視する機能」とだけ書くより「クライアントPCの稼働状況を5分おきに確認し、異常を発見したら管理責任者に電子メールで通知する機能」と記述したほうが、要求仕様書を読む経営者や供給者には分かりやすい。実行環境には、「動作環境」と「利用環境」の2つがある。動作環境は、システム開発時のハードウエアや基本ソフトなどインフラ仕様を決定するために必要な情報である。動作環境については、以下のような内容を記述する。システムの種別(基幹系/分散系/Web系)アプリケーションが稼働するOSアプリケーションが稼働するサーバーアプリケーションが利用するDBもう一方の「利用環境」は、稼働を保証するために必要な情報だ。要求仕様書でこの項目を明確に定義しておかないと、出来上がったシステムがWebブラウザのバージョンにより正しく動作しない、クライアントPCでアプリケーション同士の競合が起きる、といった問題が発生する可能性がある。利用環境については、以下のような内容を明確に定義する。システム化範囲についてシステム化の範囲を明確にすることは、既存システムとの整合性をとるほか、ハードウェアスペックやセキュリティ対策を明確化するために不可欠である。ここでは、以下のような内容について記述する。操作要件についてこの項目では、「ユーザーにどのような操作をさせるか」を明らかにする。これにより、供給者にデータ入力や画面参照に関わる機能設計について設計の指針を与えられる。具体的には、以下の内容について記載する。使用条件について要求仕様書にシステムの使用条件を記載することは、ハードウェアやソフトウェア設計の材料となるほかシステム規模を最適化するために役立つ。以下のような内容について記述するとよい。性能要求ここでは、「システムの性能を、どのような条件でどこまで確保してほしいか」を記述する。供給者側は、これに基づき費用と性能のバランスを取り、ハードウェアスペックや本番後の運用案を明確にできる。応答性:通常時と最大人数接続時のそれぞれにつき、許容できる最大応答時間を記載する。複雑な処理や多数のファイルアクセスが必要な画面での応答時間についても明記する。拡張性:利用ユーザー数やシステム利用時間が拡大する見込みについて述べる。これは、将来においてシステム負荷が高まる可能性を供給者に認識させるためである。可用性:システムに障害が発生した場合に生じる業務への影響を提示し、そもそもそのシステムに高い可用性が要求されるのかどうかを記述する。そのうえで、障害発生から復旧までの時間やデータ保存期間、サポート時間に関する取得者側の要求を明らかにする。供給者は、この記述に基づきハードウェア/ソフトウェアの構成や、障害対応体制を決定したりする。目指すべきID起点のゼロトラストとは?未知の脅威をほぼ100%検出/排除。最新「ソフトウェアサプライチェーン攻撃」の手口とその防ぎ方とは?ワークプレイスでの生成AI活用の“現実解”あるべきクライアント環境、求められる要件とは生成AIがビジネスコンテキストを理解し、プロセス改善を提案。10の寿命は残り1年半。人材不足解消の鍵はノーコード活用、データ連携とAI/IoTで真のハイパーオートメーションの実現をDX支援のための先進技術は自社を“実験場”に─データ仮想化や生成AIの意義と効果とは?ハイブリッドワークで浮上した会議の不平等性。Leadersの会員限定公開記事を読むことができます。Libraryもご利用いただけます。目指すべきID起点のゼロトラストとは?未知の脅威をほぼ100%検出/排除。最新「ソフトウェアサプライチェーン攻撃」の手口とその防ぎ方とは?ワークプレイスでの生成AI活用の“現実解”あるべきクライアント環境、求められる要件とは生成AIがビジネスコンテキストを理解し、プロセス改善を提案。10の寿命は残り1年半。人材不足解消の鍵はノーコード活用、データ連携とAI/IoTで真のハイパーオートメーションの実現をDX支援のための先進技術は自社を“実験場”に─データ仮想化や生成AIの意義と効果とは?ハイブリッドワークで浮上した会議の不平等性。脱却し、プロセス変革を遂げるために何をなすべきか。最新動向を中心にプロセスマイニングの実践のさまをお届けする。ご所属のお客様でも、ご所属企業(または団体)におけるIT化を推進されるお立場の方にもお読みいただけます。要求仕様書には、システムに求める機能を列挙しさえすればよいと思っていないだろうか。それでは経営者や供給者にシステムの全体像を伝えられない。求める機能の提示は確かに重要ではあるが、要求仕様を構成するほんの一部にすぎないことを知っておこう。