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

これまでに数十件の要求定義と要件定義を手がけてきましたが、私のアプローチは独自の発展を遂げてきました。今回は、その経験から得た知見と、従来の手法との比較について共有したいと思います。

実践的な要求定義アプローチ

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

このプロセスでは、SWOT分析などの手法も積極的に活用しています。時には分析の結果、ITシステムの導入自体が不要だという結論に至ることもあります。そのような場合は、現状の運用改善を提案するなど、コンサルティング的な側面も持ち合わせています。

デジタル化の現実的判断：実例から学ぶ

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

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

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

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

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

要件定義における実務的アプローチ

要件定義においても、必要に応じてヒアリングを実施します。要求定義同様、要件の整理と評価を行いますが、ここでは企業規模や運営規模（目標売上やアクセス数など）に応じた適切な性能目標の設定に重点を置きます。特に運営コストを優先し、システム構成から運用方法までを綿密に検討します。

文書化においては、UMLのユースケース図やシーケンス図、アクティビティ図を活用します。また、ワイヤーフレームの代替としてステートマシン図やコンポーネント図なども使用し、要件を可視化していきます。

経営者視点からの考察

これらの検討を行う際、私は常に自身がシステムを導入する立場だったらどうかを考えます。エンジニアでありながら、長年の経営者としての経験を持ち、現在は経営コンサルタントとしても活動している経験が、この視点を可能にしています。

経営者にとって最も重要なのはコストパフォーマンスです。営業的には可能な限り機能を盛り込み、金額を引き上げることが会社への貢献と考えられがちですが、そのような短絡的なアプローチは持続可能ではありません。

不動産業界との類似性と教訓

実は、システム開発業界は不動産業界と似た構図を持っています。私は宅建士の資格を持ち、マンションデベロッパーでの勤務経験もありますが、そこで目の当たりにした金銭と欲望、虚偽に満ちた世界との類似性を感じることがあります。システム開発と不動産は価格帯が似ており、そのため営業スタイルも似通ってくるのかもしれません。

クライアント中心のアプローチ

このような経験から、私は企業の予算や事業規模を十分に考慮した要求定義と要件定義を心がけています。特に、私のクライアントの多くがエンドユーザーであることから、エンジニアには見えにくい部分にも重点を置いています。

今後の展望：AIとの協働

最近の2年間は、さらなる視点の拡大のためにAIを活用しています。ただし、AIの提案を鵜呑みにすることは避け、一つの人格として扱っています。人間が間違いを犯すように、AIも完璧ではないという認識のもと、その意見を参考程度に位置づけています。

現在は個人で業務を行っているため、この手法を他者に教える必要性はありませんが、この経験をブログなどで発信することで、若手エンジニアの参考になればと考えています。要求定義と要件定義は、技術的な側面だけでなく、ビジネスの本質を理解することが重要だからです。