システム開発案件の多くは業務の見直しを伴い、要件定義が難しくなっている。利用部門の要望をそのまま受け入れても、真に役立つシステムにならない。「なぜ」という観点で要望を検証し、要件を決めていくことが不可欠だ。要件定義の経験が乏しくても実践できる、基本的な考え方や方法を解説する。
国内市場の成熟による競争の激化、事業活動のグローバル化による顧客ニーズの多様化──。近年、企業を取り巻く環境は、劇的かつ連続的に変化しています。このような環境変化に対応するため、多くの企業には継続的な業務改革が求められています。
一方でITは、仮想化、分散処理といった各分野で革新を重ね、業務の効率化や省力化だけでなく、売り上げ・利益の拡大や顧客満足度の向上といった業務改革の実現手段と位置付けられるようになりました。
このような背景を受け、業務の見直しが必要なシステム開発案件が増加し、要件定義が難しくなると同時に、より重要になっています。
要件定義の従来のやり方は、現行システムの問題とユーザーの要望を把握して、解決策となるシステムの内容を具体化するというもの。このやり方では、後工程で要件の追加や変更が頻発し、多くの手戻り作業が発生しかねません。
多くのケースで決定的に足りないのは、「なぜ」という分析です。後で詳しく解説しますが、「伝票の全文検索機能が欲しい」といった利用部門の要望をそのまま受け入れて開発すると、往々にして役に立つシステムになりません。「なぜ伝票の全文検索機能が欲しいのか？」という観点で要望を検証し、要件を決めていくことが不可欠なのです。
筆者らは、前職の日立製作所に入社して以来、要件定義の標準的な進め方（手法）を開発し、研修などでその手法の普及に取り組んできました。同時に、業務の見直しを伴うシステム開発の要件定義の支援を数多く経験してきました。この連載では、前述した「なぜ」という分析をはじめとして、筆者らが実務経験のなかで培った要件定義の進め方と、そこで必要なスキルを解説していきます。
今回は、要件定義の役割と成果物、必要なスキルを解説します。以降で、架空のITベンダーである日経ITソリューションズに所属する大田さんと一緒に学んでいきましょう。
要件定義で作成する六つの成果物
大田さんは、日経ITソリューションズに勤めるキャリア17年目のSEです。入社以来、製造業、流通業の顧客を担当する製造流通システム部に所属し、多くのシステム開発や保守を担当してきました。2年前からは、BP家電販売を担当しています。同社の主力事業は、親会社であるBP電器工業の製造する冷蔵庫、洗濯機、空調機器などの家電製品を量販店へ卸すことです。
先週、大田さんは、BP家電販売から新しい案件の依頼を受けました。それは、「在庫管理システム再構築」での要件定義です。大田さんはうれしい半面、不安を感じました。これまで自分が中心になって要件定義を担当した経験がなかったからです。
そこで、以前から面識のあった自社の先輩、ビジネスシステム部の工藤さんに相談することにしました。ビジネスシステム部は、要件定義やシステム企画の手法の開発や研修、顧客担当SEからの相談対応を行う超上流工程の専門部署です。工藤さんは、超上流工程のエキスパートとして社内で名の通っている入社23年目のSEです。
大田「今日は時間を割いてくださって、ありがとうございます」
工藤「久しぶりだね。大田くんの活躍は聞いているよ。今日はどんな相談？」
大田「実は、担当しているお客様から、要件定義の依頼を受けました」
工藤「それはよかったじゃないか。指名で依頼されるのは、信頼されている証しだよ」
大田「私は要件定義の経験が乏しいので、うまく進めるコツを教えていただきたいのですが」
工藤「OK。それじゃ、まずは要件定義の成果物を説明しよう」
要件定義とは、システムの設計・実装に先立って決めておくべき事柄を定義することです。
要件定義工程で作成する主な成果物は、（a）システム化方針、（b）解決すべき課題、（c）課題の解決策、（d）新しい業務の仕組み、（e）システム要件、（f）実行計画の六つです。以下に、それぞれの内容を簡単に記します。
（a）システム化方針
システム化の背景・目的、期待成果、制約条件、対象範囲（事業、業務、部署、既存システム）
（b）解決すべき課題
システム化の目的を実現するために解決すべき業務上の課題
（c）課題の解決策
課題を解決するための新しい業務方式（業務プロセス、制度・ルール、組織・体制、職場環境）
（d）新しい業務の仕組み
課題解決策の内容を反映した対象範囲全体の新しい業務方式
（e）システム要件
新しい業務の仕組みで必要なシステムの具体的な内容。機能要件と非機能要件に分かれる
（f）実行計画
システム化を進める作業項目、体制、スケジュール、リソース（費用、設備、機器など）
新規システム開発やシステム再構築では、上記六つの成果物をすべて作成します。ただし小規模な既存システム改善では、六つのうち（a）システム化方針、（c）課題の解決策、（d）新しい業務の仕組みを作成しなくてよい場合があります。そのことについては、本連載の別の回で詳しく説明します。
要望・要件の四つの階層
要件定義の成果物を検討、作成する際には、「要望・要件の四つの階層」を理解しておくことが重要です。それは、(1)経営レベル、(2)業務レベル、(3)仕組みレベル、(4)システムレベルの四つです（図1）。なお本連載では、特定の利用者が解決したいことを「要望」、関係者全体で実現すると決めたことを「要件」と呼びます。
要望・要件というと、真っ先にイメージするのは、システムの具体的な機能、画面、基盤ではないでしょうか。これは、(4)システムレベルの要望・要件であり、それだけでは不十分です。(1)経営レベル、(2)業務レベル、(3)仕組みレベルについても要望を収集し、(4)システムレベルを加えた四つのレベルで構造的に分析した上で、要件として定義する必要があります。ここでは、四つのレベルについて理解してください。
(1)経営レベルは、売り上げ、コスト、利益の改善に関する要望・要件です。法令対応、災害時などの事業継続も、経営レベルです。
(2)業務レベルは、特定業務の品質、生産性、スピードの改善に関する要望・要件。(3)仕組みレベルは、業務の仕組みを構成する「業務プロセス」「システム活用」「組織・体制」「制度・ルール」「職場環境（人材、設備、機器など）」の要望・要件です。
(1)経営レベルの要件と(2)業務レベルの要件は、前述の成果物（a）システム化方針の「背景・目的」「期待成果」という項目に記述します。具体的には、「販売機会ロスを防止する」「在庫コストを削減する」といった経営レベルの改善ポイント、「納期回答を正確かつ迅速に行う」「品切れの際は代替商品を提案する」などの業務レベルの改善ポイントを整理します。
(3)仕組みレベルの要件は、（b）解決すべき課題、（c）課題の解決策、（d）新しい業務の仕組みに分けて記述します。（b）解決すべき課題には、「現時点の正確な在庫状況を確認できるようにする」「在庫のある代替商品を確認できるようにする」のように、現行業務の仕組みの改善ポイントを整理します。（c）課題の解決策には課題に関係する業務の新しい方式を、（d）新しい業務の仕組みには、対象範囲全体の業務方式を「納期回答」「代替品提案」といった業務機能や業務場面別に整理します。
(4)システムレベルの要件は、（e）システム要件に記述します。「特定商品の現時点における在庫状況の表示」「欠品時における在庫のある代替商品の表示」など、新しい業務の仕組みで必要なシステムの内容を具体化します。
要件定義で必要な二つの思考技術
大田「ありがとうございます。要件定義の成果物がよく理解できました」
工藤「成果物を作成するときには、要件の階層を意識することだよ」
大田「はい、意識するようにします。他に気を付けることはありますか？」
工藤「思考技術を理解して、使いこなすことが重要だよ」
大田「思考技術ですか…？」
工藤「そう、目的思考とデザイン思考だ。詳しく説明しよう」
要件定義を進めるには、「要件定義の考え方や進め方に関する知識」「システム化対象とする業種や業務の一般的な知識」「経営層や利用部門とのコミュニケーションスキル」などの知識やスキルが必要になります。そのスキルで特に重要なのが「思考技術」です。
要件定義で必要な思考技術には、「目的思考」と「デザイン思考」の二つがあります（図2）。どちらも、一般的に言われている同名の思考法ではなく、筆者らが考えたものです。以下に、その概要を説明します。
利用部門の要望には、単なる思い付きや特定の利用者だけが求めているものが含まれがちです。そのまま要件にしてシステムを開発すると、ほとんど使われなかったり、効果が出なかったりすることがあります。
目的思考は、そのような不要な要望・要件を排除し、必要あるいは重要な要件に絞り込むスキルです。収集した要望、検討した要件の目的や影響を考え、目的や影響から見た要望・要件の必要性や重要性を評価します。
例えば営業支援システムの開発案件で、利用部門から「営業員のノウハウ（営業活動の進め方や提案書）を共有する」という要望が上がったとします。まず「なぜ？」という観点で目的を確認します。つまり「なぜ営業員のノウハウを共有したいのか」について考えるのです。その結果として、「（営業員によって成績の差が大きい）重点商品の売り上げ、利益を拡大する」といった目的が浮かび上がります。
次に、その目的から見て要望の必要性や重要性を評価します。例えば「重点商品の売り上げ、利益を拡大する」という目的の実現に対して、「営業員の営業活動の進め方や提案書を共有する」という要望が必要かどうか、重要かどうかを考えます。この場合、重要だと判断してよいでしょう。
一方、デザイン思考は、先に目的や影響があり、その実現のために必要あるいは重要な要望・要件が漏れていないかどうかを確認するスキルです。目的や影響を起点に、要望・要件の十分性や網羅性を評価し、抜け漏れがあれば充足します。
営業支援システムの開発案件の例では、「重点商品の売り上げ、利益を拡大する」という目的を実現する上で、「営業員のノウハウを共有する」だけで十分だろうか、網羅しているだろうかと考えます。その結果、「重点商品の提案を支援する専門チームを設置する」も必要だと判断したら、要望・要件を充足します。そして、改めてそれら二つの要望・要件で十分だろうか、網羅しているだろうかと検証します。
このように、目的を実現する上で、十分性や網羅性が高いと判断できるまで要望・要件を充足していきます。
今回説明した目的思考とデザイン思考は、要件定義を進めるための中心的なスキルです。本連載の別の回で、演習を交えてさらに詳しく解説します。
日立コンサルティング マネージングディレクター
日立コンサルティング シニアマネジャー
