業務システムの開発ドキュメント標準化 第８回：要求仕様書の標準化プロセス

ソフトウェアライフサイクルプロセス（SLCP）とDUNGEON

「DUNGEON」はソフトウェア開発の各工程において必要とするドキュメント標準を決めて、その具体的なテンプレートを用意したものです。概念的なアプローチとはまったく逆に、アウトプット側から開発プロセスを標準化するという実践的な考え方を重視しています。    これまで7回にわたって、基本設計から詳細設計、プログラミング、単体テスト、結合テスト、総合テストという流れに沿って、各プロセスで必要とするドキュメントの標準化を説明してきました。最終回の今回は、その前段のプロセスである要求分析フェーズのアウトプットについて説明します。    みなさんはSLCPという言葉を知っていますか。SLCPとはSoftware Life Cycle Processの略で、ソフトウェアの開発ライフサイクル、つまりこれまで解説してきた基本設計から総合テストまでの開発工程を指す言葉です。SLCPの代表的なものは30年前に提唱されたウォーターフォールモデルですが、近年ではプロトタイプモデルやスパイラルモデルなども登場し、これらをミックスして採択しているケースもあります。    SLCPは標準化も進められており、国際的には1995年にISO/IEC12207という標準プロセスが作成されました。日本でもこれをもとに「JIS X 0160」という標準プロセスが作られました。そして、ソフトウェア開発における一連のライフサイクルプロセスを可視化し、共通の枠組みを規定した「共通フレーム98 SLCP-JCF98」が策定されています。    図1にSLCP-JCF98体系を示します。共通フレームは主ライフサイクルプロセスと支援ライフサイクルプロセス、組織に関するライフサイクルプロセス、システム監査プロセス、修正プロセスという5つの観点から構成されています。弊社のドキュメント標準化「DUNGEON」は、この中からエンジニアリングの視点として体系化されている「開発プロセス」の部分をベースにしています。SLCP-JCF98はそのままだと開発現場で使うことは難しいので、DUNGEONはこれを具体的かつ実践的な手法としました。 図1：ソフトウェアを中心としたシステムの開発 および取引のための共通フレーム体系1998年版（SLCP-JCF98体系） （画像をクリックするとExcelファイルをダウンロードできます。66.5/KB）

要求分析

システム開発において、「うちの会社は上流工程に強い」というように「上流工程」と「下流工程」という言葉がよく使われます。これまで説明してきた内容では基本設計と詳細設計が上流工程、プログラミングおよび単体テスト、結合テスト、総合テストが下流工程になります。そして、基本設計の前段には要求分析というプロセスがあります。今回はこの要求分析フェーズにおいて、どのような行いからどのようなアウトプットが作成されるのかを見ていきましょう。

SLCP-JCF98の主ライフサイクルプロセス

SLCP-JCF98の主ライフサイクルプロセスは、図2のように6つのプロセスから構成されています。これを見ると、システム開発のプロセスは大きく「企画プロセス」と「開発プロセス」から構成されていることがわかります。上流工程をこの企画プロセスからはじまるものとすると、上流工程の範囲はかなり広いです。    一口に要求分析といっても経営に関する要件、業務的な要件、システム要件、ソフトウェアの機能要件などがあり、求められる結果の種類も異なっています。DUNGEONでは「顧客の要求を把握してシステム要件を確定する」という観点からこれらの要件を1つにまとめ、要求分析書のテンプレートを作成しています。 図2：SLCP-JCF98の6つの主ライフサイクルプロセス

 

IEEE830標準 ソフトウェア要求仕様

要求仕様書の書き方は国際標準でも定義されています。図3はIEEE830で定義されているソフトウェア要求仕様（SRS：Software Requirements Specification）の構成です。標準規約のままだと網羅的で使いにくいので、DUNGEONはこれを参考にしながら実践的な内容のみを取り出し、表1のようなアウトプットを持つ「要求分析書」を標準ドキュメントとして定義しています。 図3：ソフトウェア要求仕様の構成 （IEEE Std. 830-1998, IEEE Recommended Practice for Software Requirements Specification） （画像をクリックするとExcelファイルをダウンロードできます。23.5/KB）

要求概要 システムの目的 現状の課題と改善案 基本要件と優先順位 到達目標 システムの実現手段 システム化の範囲 概略費用 効果（定性／定量） 体制図 概略スケジュール 表1：DUNGEONの「要求分析書」の構成

要求分析プロセスにおいて大変なのはアウトプットを導き出すまでの作業です。漠然とした要求を具体化して整理するために、ヒアリングやブレーンストーミング、問題要因関連図やフィッシュボーンダイアグラム（魚骨図）の作成など様々な手法を使います。ただし、DUNGEONはまずアウトプットを定義するという考え方を優先していますので、現バージョンではそれら過程の作業について触れていません。要求分析の結果は定型フォーム化しにくいので自由記述が主体となりますが、作成上のポイントを以下に説明します。

要求概要

第三者がドキュメントを読む際に、いきなり詳細から記述されていると内容を理解しにくいものです。そのためDUNGEONのドキュメントは、最初に全体を俯瞰（ふかん）できるような概要を書くことを基本としています。要求概要ページでは必要に応じて経営からの要求を記し、それを実現するためのシステム要件、機能要件などの概要を記載します。

システムの目的

はじめにシステムの目的を明確にしておかないと、システム化すべきか否かの判断があいまいになります。要求分析で大切なのは、取り上げることよりも捨てることです。つまり、トップや現場からあげられる様々な要求のうち、目的にかなっていて効果が大きく、現実的なものだけを取捨選択しなければなりません。    要求を吸い上げる段階では、夢物語も含めてできるだけ自由に発言してもらいます。その中から"システムの目的"というフィルターをもとに、ばっさばっさと切り捨ててシステム化の範囲を優先順位づけします。

 

現状の課題と改善策

問題要因関連図やフィッシュボーンダイアグラムなどを使って分析した問題点（課題）と改善策を記述します。要求分析書では、分析作業に使った関連図などはあくまでも参考扱いとし、それらを整理した結果だけを表形式で記述します。    課題をクローズアップするうえで大切なのが目的です。課題は次式のように目的とそれを達成できていない現状のギャップになります。つまり、目的がない限り課題もないのです。そのためにも、目的を明確化することが重要です。 目的 − 現状 ＝ 課題（問題点）    改善策には、運用で解決すべき対策とシステムで解決すべき対策の両方を書きます。大切なのは、なんでもかんでもシステムで解決しようと思わず、運用で対処できるところはシステム化対象外としてもよいということです。

基本要件と優先順位

要件には「絶対必要」「必要と思われる」「あれば便利」などの重要度があります。システム開発の鉄則は「小さく産んで大きく育てる」ことですので、これらのニーズを整理して優先順位づけします。第一フェーズは、優先順位の高いことに絞ってシステム化することにしましょう。

到達目標

システムの目的とは別に目標を定義しておきます。目標は作業時間20%削減とか、ミスの半減というようにできる限り数値化して持ちます。以前は「労使上の問題で要員削減とは書きにくい」とよくいわれましたが、最近ではそれが目標の1つであれば明確に記述してもかまわなくなってきています。また経営データの迅速な取得が可能となり、日数にして5日短縮、作業工数にして40時間／月の削減というような目標もよく使います。    開発側にとっては自分の首を絞めることにもなりかねないのですが、システム的なこともパフォーマンス向上、システムの稼動率アップなどを具体的な数値目標として書きます。

システムの実現手段

ここでは細かなことではなく、どのようなシステムとするかの全体構想を記述します。既存システムのどれを残して何をリプレースするのか、新システムはどういう基盤技術を使いどのような仕組みを持つのか、それによりどのようにして目標を実現できるかなど、新システムの概要がわかる資料を用意します。

システム化の範囲

基本要件と優先順位に沿って、今回のシステム化の対象範囲を定めます。概要でとどめておく場合は、何をやり何をやらないかを箇条書きで要件記述します。大切なのは、やることだけでなく、やらないこともきちんと記述することです。    要求分析作業で出された様々な要望の中から、ニーズが強く実現性の高いものだけがシステム化の対象となります。ユーザは、要求したことはすべてシステム化すると思っていますので、そこで落とされた要望に関しては、運用での対応方法、実現困難なので見送るなどの理由をつけて範囲外としたことを明記します。やる、やらないと明記することにより、レビューによって本当に必要なことが再度絞り込めるのです。    システム化の範囲をより詳細に記述する場合、新システムにおける新しい業務フローとそのフロー上に登場する機能（画面や帳票）の一覧まで作成します。要求分析フェーズは業務要件を確定する作業ですので、本来ならばここまで行う必要があります。しかし、プロジェクトの事情によりこの作業まで踏み込めないことも多いので、本連載では基本設計の項で作成するものとして説明しました。

 

概略費用

要求分析フェーズで重要なのは概略費用を算出することです。意思決定者は、この金額を元にシステム化を行うかどうか、もう少しシステム化範囲を絞って費用削減するかなどの判断を行います。ゴーサインが出ると、予算化してプロジェクトが正式にスタートすることになります。

効果（定性／定量）

システム化を行うかは投資対効果の観点で判断されます。効果には定性効果と定量効果がありますので、それぞれ分けて記述します。定量効果は数値や金額で表すことのできるものです。事務作業時間を年間1000時間短縮、要員3名削減、印刷用紙10000枚削減、年間保守費用400万円削減などの数値効果を金額換算して書き出します。    多くの場合、予想される定量効果だけでは投資対効果のバランスが満足しません。それはシステム化にはお金に直接換算しにくい定性効果が大きいからです。例えば、決算書の作成が10日早まるといえば、どの経営者も喜んでくれるでしょう。    しかし、この効果を金額換算するのは少し難しいでしょう。金額というよりも、企業イメージ向上、投資家に対するサービス向上、経営判断の迅速化という効果が主体だからです。このほかにも、従業員のモチベーション向上、取引先に対するサービス向上、新卒採用時のアピールなどの様々な定性効果が考えられます。

体制図

この段階では、プロジェクトの体制図に担当者まで入れて記述するのは難しいでしょう。プロジェクト成功のためにどの組織がどのように関与するか、コンサルタント会社や開発会社などがどのように関わるかなどを組織主体の体制図とし、プロジェクトのゴーサインが出たときに具体的な担当者を決定してプロジェクトをスタートします。

概略スケジュール

要件定義では納期を決めなければなりません。やるとなったらできるだけ早くというのがユーザの希望でしょうが、実現可能な納期でなければスタート前から失敗プロジェクトとなります。概略スケジュールを書いて、どのくらいの開発期間が必要かを判断し、経営ニーズと照らし合わせて納期を決定します。

まとめ

業務システムの開発効率を高めるために、開発ドキュメントの標準を定める必要性はどの会社も感じている課題です。しかし開発言語や開発手法が多様化し、次々と新しい技術が出現する中で全社的な標準を作成し、それをメンテナンスしていくのはかなり困難な作業です。だからといって何もしないままでは、いつまでたってもソフトウェア業界は旧態依然のままといわれ続けます。    本連載で紹介したように、ソフトウェア開発においても業界標準規約はあります。しかし標準規約は抽象的、網羅的なのでそのままでは現場で使えません。そこで弊社では、実践的なドキュメント標準「DUNGEON」を作成して利用しています。8回の連載で、要求分析から総合テストまでに必要となる一連のドキュメントを紹介しました。これらがみなさんの生産性向上に少しでも参考になることを願っています。