要求定義と要件定義：30年の実務から得た実践的アプローチ

これまでに数十件の要求定義と要件定義を手がけてきた。エンジニア、経営者、そして宅建業者として不動産業にも携わる立場から、私のアプローチは独自の発展を遂げてきた。

要求定義の実践

要求定義はヒアリングから始まる。クライアントの要求を丁寧に整理し、客観的な評価を通じて不要な要求を除外する。さらに、必要と思われる要求を追加しながら、開発から運用方法までを包括的に検討し、企画書レベルの提案を作成していく。

このプロセスではSWOT分析などの手法も活用する。時には分析の結果、ITシステムの導入自体が不要だという結論に至ることもある。そのような場合は、現状の運用改善を提案する。営業的には「システムは不要です」と言うのは売上を捨てる行為だが、不要なものを売りつければ信用を失う。経営者にとって最も重要なのはコストパフォーマンスであり、その視点を無視した提案は持続可能ではない。

要件定義でも同様に、企業規模や運営規模に応じた適切な性能目標の設定に重点を置く。UMLのユースケース図やシーケンス図で要件を可視化し、運営コストを最優先にシステム構成から運用方法までを綿密に検討する。

デジタル化の現実的判断

ある具体例を紹介しよう。事業者が高齢、顧客の大半も年配者で、1日の決済回数が20回程度、客単価1,500円の小規模店舗でのキャッシュレス導入の検討だ。一見するとデジタル化の好機に思えるが、実態を詳しく分析する必要がある。

キャッシュレス未対応による機会損失、端末導入による事業者負担の増減、お釣りの小銭管理と端末操作の習熟度比較など、多角的な検討が必要だ。これらを総合的に評価すると、必ずしもキャッシュレス化が生産性向上につながらないケースもある。

私自身、30年来のデジタル推進派だが、アナログの持つ力も軽視できないと考えている。例えば、ある助成金申請では従来の紙ベースでの押印提出が求められている。一見すると非効率に思えるが、応募件数が限られており、応募者のデジタルリテラシーにばらつきがある場合、デジタル化によって却って事務局の運営コストや事業者の応募コストが増加する可能性がある。

実際、別の補助金では電子申請のファイル不備により不採択となったケースが報告されている。紙ベースであればこのようなトラブルは避けられたはずだ。だからと言って、紙ベースに戻せとは全く思わない。現場をよく知る事務局の判断であれば妥当だと思うからだ。

対して現場を全く理解できない某補助金の事務局はなんなんでしょうね。以前のことだが、今話題の某補助金の事務局を請けている会社が、北海道のとある補助金の事務局業務を請けたとき、途中で事務局業務を放棄したために補助事業者が補助金を受け取れず、悲惨な目に遭ったと被害者から話を聞いたことがある。

システム開発と不動産業の共通構造

システム開発業界と不動産業界は、驚くほど似た構造を持っている。私はかつてマンションデベロッパーに勤務し、現在は宅建業者として不動産業を営んでいる。両方の業界に当事者として身を置いてきたからこそ、その類似性が単なる印象論ではないと断言できる。

まず、価格帯が近い。システム開発も不動産取引も、数百万円から数千万円の案件が中心だ。この価格帯では、顧客にとって「人生で数回しかない大きな買い物」になる。一方、売る側にとっては日常業務だ。この経験値の圧倒的な非対称性が、両業界に共通する構造問題の根源にある。

情報の非対称性も深刻だ。不動産では、物件の瑕疵や周辺環境のリスク、将来の資産価値について、業者と顧客の間に巨大な情報格差がある。システム開発でも同じことが起きている。本当に必要な機能は何か、適正な工数はどれくらいか、運用コストはいくらかかるのか。顧客にはほとんど判断材料がない。

その結果、どちらの業界でも「本当に必要なもの」より「売りたいもの」が優先されがちになる。不動産なら、顧客の予算や生活スタイルに合わない物件を押し込む営業。システム開発なら、不要な機能を盛り込んで見積もりを膨らませる営業。手口は違うが、構造は同じだ。

デベロッパー時代に目の当たりにした金銭と欲望、虚偽に満ちた世界は、IT業界の多重下請け構造と驚くほど重なる。元請けが利益を抜き、下請けに丸投げし、品質の責任は曖昧になる。不動産の仲介業者が売主と買主の間で情報を操作するのと、SIerが顧客と開発チームの間で要件を歪めるのは、本質的に同じ行為だ。

だからこそ、私は企業の予算や事業規模を十分に考慮した要求定義と要件定義を心がけている。エンジニアとして技術の実態を知り、宅建業者として不動産の商慣行を知り、経営者としてコストの現実を知る。三つの視点があるからこそ、クライアントにとって本当に必要なものだけを提案できる。クライアントの多くがエンドユーザーであることから、エンジニアには見えにくい部分にも重点を置いている。

要求定義と要件定義は、技術的な側面だけでなく、ビジネスの本質を理解することが重要だ。そしてビジネスの本質とは、結局のところ「相手の立場に立てるかどうか」に尽きる。