課題解決　事例紹介

要件定義は「必須」ではないが、意外な効用（メリット）も

最近になって、オンラインニュースなどでも「要件定義」という言葉がよく使われるようになってきました。

要件定義とは、平たく言えば、「何をどのようにシステム化するか」を整理することです。

「請求書を発行する際、納品書から自動で転記させたい」というレベルであれば、要件を定義するまでもなく、やるべきことも効果もわかりますが、「特殊な運用をしている複数種類の見積もりを基に、納品書・請求書を作成し、仕入とも連動しつつ経理システムにデータを接続したい・・・」のような範囲に広がってくると、「そもそも何のためにするのか」「どのような効果が期待できるか」「将来かかる費用の見通しはどうか」・・・といった様々な角度から評価をしておかないと、作りっぱなしで修正できないものができかねません。

当社は主にExcelを活用した情報システムを専門としていますが、比較的規模が大きいものが多いことから、要件定義を行う機会が多く、またそれ以前に要件定義をしなかったために失敗した話も散々聞かされてきました。

どんなときでも要件定義をすべきとまでは言いませんが、以下、事例を通じてどんな効用（メリット）があるかをいくつかご紹介します。

 

要件定義の効果　1（本来のDX：競争力強化の実現）

DX（Digital Transformationの略）という言葉も流行していますが、本来の目的は［競争力を向上させる」ことであり、その手段として「業務プロセスの変革」と「デジタル技術の活用」をするものです。

しかし、この種の数文字の漢字に変換できない新概念は、なぜか我が国に入ってくると換骨奪胎されて、手段が目的化する傾向にあります。すなわち、DX＝単なる自動化、コンピュータを使うこと、クラウドサービスを契約すること、意味はわからないけどデジタル化する・・・のようになりつつあります。

要件定義の効用

競争力強化に必要な戦略的視点から要件定義を行えば、

• どこ（誰）に対して競争力を高めるか
• 競争力を高めるために、どうするか（高速化・高付加価値化・低コスト化・・・）
• それを実現するために、どうするか

といった方向性が固まり、その上で、

• 複数部署間にまたがる関連業務を統合して評価できる
• 高速・高精度で処理できるようにするための運用ルール
• どのようなインフラが必要で、今何が不足しているのか整理する
• 今後どのような変更が予想され、どのように対応していくのかを想定しておく
• セキュリティ要件の優先度と、実装方法を検討する

といったことが、事前に考慮できるメリットが生じます。

一般の要件定義ではここまでしないかもしれませんが、筆者の場合、中小企業診断士としての立場もあり、特に断られない限りは、戦略的活用の視点を含めるようにしています。

 

要件定義の効果　2（Webページ・ホームページ作成事例）

ホームページの制作を依頼すると、大抵はデザインの好みや配色について確認する打ち合わせの後、デザイン案（ラフ案）と主要ページの構成図が提示されます。

デザイナーさんが作ったデザインは、大抵の場合美しく、格好よく、見ているだけでも楽しいものです。

ここで、多少好みでリクエストをしたあと1～2ヶ月もすると、完成です。

今時は、制作支援ツールも充実しているので、大抵の場合、デザインには満足できるのではないでしょうか？

要件定義なしでホームページを作った失敗例

ところで、そもそも何のためにホームページを作るのでしょうか？　他社が作っているから？　今時ホームページくらいあった方が良いから？　･･･　目的があいまいなままホームページを作成すると、意味不明なコンテンツ？ができあがります。

例えば、

• ラーメン屋なのに、地図も住所も記載されていない（行きたくても行けない）
• 自社製品は紹介されているが、問い合わせ窓口が明記されていない（取引先開拓にはつながらない）
• 全ページ写真（画像）だけで構成（検索エンジンが見つけられない）
• 物販ページだが、注文は用紙を印刷してFAXしろとある（何のためのWeb環境？）
• ページ更新にhtmlの知識が必要で、3年も経つと廃番商品ばかりの掲載になった（信用問題）

いずれも実際にあった例ですが、要件定義をして「目的」「対象者」「利用者にしてもらいたいこと」などを整理しておけば、ホームページ制作者にも正しくそれが伝わり、顧客増加に貢献できるメリットが生じます。

この時、「当店の味は、近隣他店では得られないｘｘが特長、を積極的にアピールする」「自社製品の特長を整理して、関心をもつバイヤーと商談の機会を増やしたい」といった具体的な競争優位に立てる表現内容にまで踏み込んでおいた方が、「売上に貢献する」といった具体的なメリットを増大できます。

 

要件定義の効果　3（データ分析業務での、BIからの置き換え事例）

N社では、予実データを基に様々な評価を行い、事業投資に役立てることを目的として、BIシステムを導入しました。ところが、実績と予定ではデータの粒度が異なることや、予定データの登録方法が部署ごとに異なっていたことなどから、BIシステムでの処理が複雑になり、1つの分析をするのに2時間もかかっていたそうです。

なぜそのような事態に至ったかについてヒアリングを行ったところ、今やりたいことに加えて将来やりたいことの整理がついていなかったこと、このため無理矢理BIシステムを拡張しようとして複雑化したこと、基のデータが標準化されていなかったので、処理が必要以上に複雑になったこと、部署が時間とともに増えることが考慮されていなかったこと・・・などが浮かび上がってきました。

要件定義により、加工の自由度・柔軟性確保

その後、こうした点を1ヶ月かけて整理し直した結果、データ構造が標準化され、当初想定していた以上に高速かつ自由な分析が可能となっただけでなく、爾後の部署の追加等にも2～3日で対応でき、柔軟さを証明できました。

システムの構成は、データ量（一度に数百万件）を鑑み、前のBI時に件数を考慮せずに構築した反省から、Excel＋DB（データベース）としました。事前に件数などを想定し、性能評価ができるのも、は要件定義のメリットの1つです。

 

要件定義の効果　4（在庫管理業務の、標準化事例）

A社は、スマホ関連グッズを扱うメーカーです。あまりに市場が急成長したことから、限られた人員・空間で膨大な商品在庫を基に、日々増加する多数の発注への対応を迫られていました。

当初受けた相談は、「宅配伝票を自動作成したい」でしたが、そこだけ自動化しても効果が限られることから、在庫管理機能も含めてはどうかと提案し、受け入れて戴きました。

こうして、現地調査を行った結果、商品の在庫方法（置き方・管理手法）から見直すべきとの結論に至り、棚の配置や番号の付け方のルールにも踏み込んで、標準化し直しました。一般の要件定義ではここまでしないかもしれませんが、当社の場合、目的達成のために必要であれば、業務手順や各種標準化の見直しも行っています。

この結果、複数のWebサイトでの販売データを一元管理し、発送すべき商品をまとめて短時間でピックアップし、箱詰め＋配送伝票までを従前の数分の1の時間でできるようになりました。

何よりの効果は、この後何度か拡張対応を図りましたが、設計上織り込んでおいたため、短期間・低コストで対応することができたのは、大きなメリットでした。

 

要件定義しない場合の影響（寓話による説明）

冒頭で「必須ではない」と申し上げましたが、一定規模になると省略したときの影響が大きくなります。

以下、「情報システムの話はわかりづらい」と言われないよう、寓話で説明します。

情報システムの開発は、以下の「職人と機械設計者の協働」によく似ています。

たとえば、ある菓子職人が金平糖をもとに独自の新しいタイプの菓子を発案し、ベトナムの機械会社に量産機械の作成を依頼したとします。
その際、現状のレシピを基に口頭で補足説明し、金平糖を見たことがないという設計者に試作品を2つ渡し、「わからないことがあれば質問して下さい」とだけ伝えます。

すると後日、設計者からは次々と質問が届きます。「粒の表面はツルツルですか？」「混ぜるスピードは毎回一定にしますか？」「味付けは加熱前？それとも後？」「突起の数は33個と38個のどちらが正しい？」。

さらには、「効率を上げるために二倍速で回してもいいですか？」など、一見まっとうな質問の中に、方向違いのものまで混じってきました。

こうしたやり取りが増えるほど、職人も設計側も疲弊します。

そして肝心の「着色材を後から加える」工程の重要性や、「量産といったら1日数千個が常識」といったことは結局どこにも記録されず、肝心の色づけができない、1時間に30個しか作れない、という結果になりかねません。これはまさに“合成の誤謬”です。

システム開発もこれと同じで、業務の背景や意図を十分に共有しないと、期待と結果の間に“見えないズレ”が生じやすくなります。このため、背景・運用・目的をできるだけ当事者の立場から具体的かつ積極的に資料化・ご説明いただくことが、プロジェクト成功の最短経路となります。

 

要件定義の匿名相談

当社は、要件定義のみのサービスも行っています。もちろん、匿名での相談も歓迎です。